Kimi K3 với cửa sổ ngữ cảnh 1 triệu token có thể thay thế RAG? So sánh chi phí, độ trễ và chất lượng câu trả lời

Khi Kimi K3 ra mắt với cửa sổ ngữ cảnh lên tới một triệu token, câu hỏi mà nhiều kỹ sư AI đặt ra là: "Liệu chúng ta có thể loại bỏ RAG ngay bây giờ hay không?". Một thử nghiệm có kiểm soát, chấm điểm mù trên chính kho văn bản của tác giả, đã mang đến những câu trả lời bất ngờ về chi phí, độ trễ và chất lượng — cùng với đó là cảnh báo về những cạm bẫy kỹ thuật ít người nói tới.

Trong bối cảnh các mô hình ngôn ngữ lớn (LLM) liên tục mở rộng cửa sổ ngữ cảnh, câu hỏi về vai trò của RAG (Retrieval-Augmented Generation) ngày càng trở nên cấp thiết. Thử nghiệm do tác giả Jonathan Schwarz thực hiện không chỉ dừng lại ở việc so sánh điểm số, mà còn hé lộ những bài học xương máu về cách vận hành mô hình suy luận (reasoning model) và chiến lược tối ưu chi phí cho ứng dụng thực tế tại Việt Nam.

Bối cảnh: Sự trỗi dậy của cửa sổ ngữ cảnh siêu lớn

RAG ra đời như một giải pháp cho giới hạn kỹ thuật: các mô hình chỉ có thể xử lý vài nghìn token tại một thời điểm. Khi tài liệu vượt quá khả năng tiếp nhận, hệ thống buộc phải chọn lọc các đoạn văn bản liên quan để đưa vào prompt. Điều này hoạt động hiệu quả nhưng đồng thời bổ sung thêm một thành phần phức tạp: hệ thống nhúng (embedding), cơ sở dữ liệu vector và bộ điều chỉnh (tuner) — tất cả đều cần bảo trì và kiểm tra liên tục.

Sự xuất hiện của Kimi K3 từ Moonshot AI, cùng các mô hình khác có cửa sổ lên tới một triệu token, đã đặt dấu hỏi lớn cho sự tồn tại của RAG. Những lợi ích truyền thống mà RAG thường được viện dẫn như chi phí thấp hơn, độ trễ thấp hơn và nguồn trích dẫn rõ ràng, giờ đây cần được kiểm chứng lại.

Thiết lập thử nghiệm: Một kho văn bản, hai con đường

Thử nghiệm sử dụng chính kho văn bản gồm 32 tệp tin chứa 33 bài viết của tác giả trên Medium và Towards Data Science, tổng cộng 127.068 token (đo bằng tiktoken với bộ mã cl100k_base). Hai luồng xử lý được xây dựng với cùng một hệ thống prompt và cùng một mô hình Kimi K3, chỉ khác nhau ở phần ngữ cảnh được chèn vào.

"Bạn trả lời các câu hỏi về một bộ sưu tập bài viết của một tác giả. Chỉ sử dụng văn bản bài viết được cung cấp. Nếu văn bản không chứa câu trả lời, hãy nói rõ điều đó thay vì đoán. Khi nêu một sự kiện, hãy nêu tên bài viết mà bạn lấy thông tin."

• Luồng RAG: Chia nhỏ các bài viết thành 788 khối (mỗi khối 900 ký tự, chồng lấn 150 ký tự), nhúng bằng mô hình all-MiniLM-L6-v2 và chọn 5 khối tương tự nhất cho mỗi câu hỏi — khoảng 1.200 token mỗi yêu cầu.
• Luồng long-context: Gửi toàn bộ 32 bài viết cùng với mỗi câu hỏi — 127.346 token mỗi yêu cầu, gấp khoảng 100 lần so với RAG.

Một chi tiết quyết định chi phí được tác giả nhấn mạnh: thứ tự của prompt. Kho văn bản luôn được đặt trước câu hỏi, bởi vì bộ nhớ đệm tiền tố (prefix caching) chỉ hoạt động khi phần đầu của tin nhắn giống hệt nhau từng ký tự một. Nếu câu hỏi đứng trước, mọi yêu cầu sẽ là "cache miss" và chi phí tăng vọt từ $0,30 lên $3,00 cho mỗi triệu token nhập vào.

Mô tả thiết lập thử nghiệm và hai luồng xử lý

12 câu hỏi chia theo ba mức độ khó

Để đánh giá toàn diện, tác giả định nghĩa 12 câu hỏi, chia thành ba nhóm:

• Nhóm A (single-fact): Câu trả lời nằm ở một vị trí duy nhất trong một bài viết cụ thể, ví dụ như mô hình nhúng nào đã dùng trong thí nghiệm về kích thước khối (chunk size).
• Nhóm B (cross-article): Câu trả lời cần tổng hợp từ hai hoặc ba nguồn, ví dụ như khuyến nghị khi nào nên dùng RAG và khi nào nên fine-tuning.
• Nhóm C (corpus-wide): Câu trả lời yêu cầu đọc trọn vẹn toàn bộ 32 bài viết, ví dụ như đếm số bài viết có liên kết tới GitHub.

Với nhóm C, kết quả thắng thua gần như đã được định trước: 5 khối văn bản không thể trả lời câu hỏi bao trùm 32 bài viết. Điểm đáng chú ý không phải là RAG thua, mà là RAG thua theo cách nào — liệu nó có thành thật thừa nhận thiếu thông tin, hay sẽ bịa ra câu trả lời một cách thuyết phục.

Mô tả các nhóm câu hỏi

Phương pháp đánh giá: Chấm điểm mù và ba tiêu chí

Thay vì dùng một mô hình LLM khác để chấm điểm, tác giả tự mình đánh giá vì hiểu rõ nhất kho văn bản của mình. Một tập lệnh make_grading_sheet.py trộn ngẫu nhiên các câu trả lời thành cặp "X" và "Y" trong file Excel, không cho biết câu trả lời nào đến từ luồng nào. Chìa khóa được giữ trong một file riêng biệt và chỉ mở sau khi hoàn tất việc chấm điểm.

Mỗi câu trả lời được chấm 0-2 điểm theo ba tiêu chí:

• Độ chính xác (Correctness): Thông tin được đưa ra có đúng hay không?
• Mức độ đầy đủ (Completeness): Câu trả lời có bao quát đầy đủ các khía cạnh của câu hỏi hay không?
• Mức độ bám nguồn (Groundedness): Thông tin có đến từ kho văn bản hay từ kiến thức thế giới của mô hình?

Sự khác biệt giữa tiêu chí đầu tiên và thứ ba là quan trọng nhất. Một câu trả lời có thể "đúng" về mặt thực tế nhưng lại đến từ kiến thức nền của mô hình, chứ không phải từ các bài viết — điều này khiến kết quả đẹp nhưng không chứng minh được điều cần kiểm chứng.

Tiêu chí chấm điểm

Ba sự cố đắt giá trong quá trình chạy thử nghiệm

Phần thú vị nhất của bài viết có lẽ nằm ở những sai lầm kỹ thuật, giúp người đọc hiểu rõ hơn về bản chất của mô hình suy luận:

1. Một nửa câu trả lời trống rỗng nhưng không ai nhận ra

Lần chạy đầu tiên trông hoàn hảo: mọi dòng lệnh đều hiển thị độ trễ và chi phí hợp lý, không có lỗi nào. Tuy nhiên, khi mở file Excel, tác giả phát hiện 12 trên 24 câu trả lời hoàn toàn trống và 3 câu khác bị cắt giữa chừng.

Nguyên nhân: K3 là một mô hình suy luận (reasoning model), tạo ra các bước suy nghĩ nội bộ trước khi trả lời. Tham số max_completion_tokens ban đầu được đặt là 800 — đủ cho một câu trả lời thông thường, nhưng không đủ cho các câu hỏi khó khi mô hình sử dụng toàn bộ 800 token cho việc suy nghĩ.

Bài học: Với mô hình suy luận, max_completion_tokens không phải là giới hạn độ dài câu trả lời mà là "ngân sách suy nghĩ". Một lệnh gọi thất bại vì lý do này vẫn trông thành công về mọi mặt nếu không kiểm tra finish_reason.

2. Cùng một câu hỏi, cùng một ngữ cảnh nhưng kết quả khác nhau

Sau khi nâng giới hạn lên 4.000 token, hầu hết các câu hỏi đều hoạt động. Riêng câu C2 (hỏi về các công cụ được nhắc đến nhiều nhất) gây khó khăn: lần đầu mô hình suy nghĩ hết 3.997 token và không trả lời được, lần chạy thứ hai chỉ dùng 884 token và trả lời hoàn hảo.

Điều này chỉ ra rằng Kimi K3 chỉ cho phép temperature=1, khiến các lần chạy không thể tái lập hoàn toàn. Chi phí cũng chênh lệch đáng kể: $0,0635 cho lần thất bại so với $0,0187 cho lần thành công.

3. Một lần chạy toàn bộ không thể hoàn thành trong một ngày

Đây là điểm vô cùng quan trọng với các nhà phát triển tại Việt Nam khi sử dụng các API mô hình lớn. Luồng long-context cần 1.528.152 token chỉ riêng cho phần nhập liệu của 12 câu hỏi, trong khi hạn mức hàng ngày của gói entry-level là 1.500.000 token. Ngoài ra, bộ nhớ đệm tiền tố không hoạt động ổn định: chỉ 3 trên 8 lần gọi kích hoạt được, với chi phí chênh lệch tới 8 lần ($0,0466 có cache so với $0,3916 không cache).

Kết quả: Long-context toàn thắng về chất lượng nhưng thua xa về chi phí

Sau khi chấm điểm mù và mở khóa dữ liệu, kết quả cho thấy bức tranh hai mặt rõ rệt:

Tiêu chí	RAG	Long-context
Độ chính xác	1,92	2,00
Mức độ đầy đủ	0,83	2,00
Mức độ bám nguồn	2,00	2,00
Tổng chi phí	$0,23	$3,82
Độ trễ trung bình	~35 giây	~111 giây

Long-context trả lời đầy đủ cả 12 câu hỏi, đạt điểm tối đa ở cả ba tiêu chí. Trong khi đó, RAG không bịa thông tin (điểm grounded 2,00) nhưng thiếu hụt nghiêm trọng về độ đầy đủ — tiêu chí kéo toàn bộ điểm xuống. Đối với câu hỏi về số bài viết có link GitHub, RAG trả lời: "Không có đoạn trích nào chứa liên kết tới GitHub" trong khi long-context trả lời chính xác "13 bài viết" kèm danh sách dẫn chứng.

Bảng chấm điểm chi tiết

Sự thất bại của RAG không đến từ khả năng truy xuất mà nhờ vào hệ thống prompt đã được thiết kế cẩn thận: "Nếu văn bản không chứa câu trả lời, hãy nói rõ thay vì đoán". Điều này cho thấy trong các hệ thống RAG, system prompt chính là tấm khiên chống lại sự bịa đặt — một bài học vô cùng giá trị.

Khi nào nên dùng long-context, khi nào nên dùng RAG?

• Với kho văn bản vài chục tài liệu (dưới 20% cửa sổ ngữ cảnh) và tần suất truy vấn thấp: Long-context là lựa chọn tối ưu. Không cần tinh chỉnh chunk size, không cần duy trì vector database, và câu trả lời hoàn chỉnh hơn.
• Với ứng dụng tương tác yêu cầu phản hồi nhanh: RAG vượt trội. Độ trễ trung bình 111 giây của long-context không phù hợp cho trải nghiệm người dùng.
• Với hệ thống phục vụ hàng nghìn lượt truy vấn: Chi phí trở thành yếu tố quyết định. 12 câu hỏi chỉ chênh $3,59 nhưng nhân lên 12.000 câu hỏi sẽ là $3.800 so với $230.

Kết luận: Có thể "bỏ" RAG, nhưng không thể bỏ giám sát

Thử nghiệm kết luận rằng với một kho văn bản cỡ vừa (dưới 1/5 cửa sổ ngữ cảnh) và không được truy vấn thường xuyên, việc bỏ qua RAG hoàn toàn khả thi. Tuy nhiên, điều không thể bỏ qua là việc theo dõi các tham số đi kèm câu trả lời: finish_reason, số token suy nghĩ và tỷ lệ cache hit.

Những gì bạn đọc ở đây chỉ là 24 quan sát, không phải là một bằng chứng tuyệt đối. Kimi K3 chỉ cho phép temperature=1, nên mọi con số chỉ là một mẫu quan sát đơn lẻ. Nhưng sự khác biệt giữa hai luồng đủ lớn để trả lời câu hỏi ban đầu.

Các lỗi gặp phải trong quá trình thử nghiệm — token suy nghĩ tiêu tốn hết ngân sách, bộ nhớ đệm không ổn định, hay hạn mức token hàng ngày — chính là những thông tin quý giá nhất. Chúng nhắc nhở các nhà phát triển rằng việc mở rộng cửa sổ ngữ cảnh không tự động giải quyết được mọi vấn đề kiến trúc, mà còn đặt ra những yêu cầu mới về giám sát chi phí và tối ưu hóa hệ thống, đồng thời mở ra hướng tiếp cận mới đầy tiềm năng cho các ứng dụng xử lý văn bản quy mô vừa tại Việt Nam.