Cửa sổ ngữ cảnh chứa 5.000 trang, nhưng mốc bỏ RAG chỉ là 500 trang: FDE phải trả lời khách bằng số đo

Theo Google Cloud, Gemini 1.5 Pro có cửa sổ ngữ cảnh tới 2 triệu token, cỡ 5.000 trang văn bản. Anthropic thì nêu một mốc nhỏ hơn nhiều: kho tri thức dưới 200.000 token, khoảng 500 trang, có thể đưa nguyên vào prompt mà không cần RAG.

Hai con số chênh nhau mười lần. Phần lớn công việc thiết kế hệ thống hỏi đáp tài liệu cho khách, và phần lớn các cuộc tranh luận trong phòng họp, nằm ở khoảng chênh ấy.

Ở site khách, câu hỏi này đến rất sớm. Một trưởng phòng IT vừa đọc tin về context triệu token sẽ hỏi vì sao team bạn còn mất hai tuần dựng chunking, embedding và vector store. Trả lời “RAG là best practice” thì bạn đã thua. Bạn cần nói bằng ba thứ khách hiểu: độ chính xác, độ trễ và hóa đơn.

Cửa sổ rộng không có nghĩa là mô hình đọc kỹ

Bằng chứng mạnh nhất chống lại việc nhét cả kho vào prompt nằm trong bài báo “Lost in the Middle” của Liu và cộng sự, đăng ở TACL 2024. Nhóm tác giả cho thấy hiệu năng giảm rõ rệt khi thông tin cần dùng nằm ở giữa một ngữ cảnh dài, so với khi nó nằm ở đầu hoặc cuối.

Kết quả này đúng cả với những mô hình được thiết kế riêng cho ngữ cảnh dài.

Introl, một công ty hạ tầng AI, rút ra hệ quả thực dụng: doanh nghiệp không thể mặc định rằng “càng nhiều ngữ cảnh càng tốt”. Bạn nên nói thẳng điều này với khách, vì trực giác của họ đang nghiêng về hướng ngược lại.

Thử hình dung một bộ quy tắc bảo hiểm dày 400 trang, với điều khoản loại trừ quan trọng nhất nằm ở trang 200. Nhét cả bộ vào prompt thì điều khoản ấy rơi đúng vào vùng mô hình dễ bỏ sót nhất. Với RAG, đoạn đó được truy xuất lên và đặt sát câu hỏi, tức là ở vị trí mô hình dùng tốt.

Vì thế, việc đầu tiên ở site khách là đo chứ chưa phải chọn kiến trúc. Chèn một câu dữ kiện riêng vào đầu, giữa và cuối tài liệu thật của khách, đặt câu hỏi về nó, rồi đếm xem mô hình trả lời đúng bao nhiêu lần ở mỗi vị trí.

Hóa đơn tăng nhanh hơn số trang

Kể cả khi độ chính xác chấp nhận được, bài toán chi phí vẫn còn đó. IBM giải thích rằng nhu cầu tính toán tăng theo bình phương độ dài chuỗi. Introl nói cùng ý theo cách người làm ngân sách dễ nghe hơn: quan hệ này phi tuyến, ngữ cảnh càng dài thì càng đắt một cách không tương xứng.

Một phép tính giúp thấy rõ hơn. Một prompt RAG gọn khoảng 10.000 token và một prompt nhét cả kho 1 triệu token chênh nhau 100 lần về số token. Nếu áp quy luật bình phương, phần tính toán tương ứng có thể chênh tới 10.000 lần cho cùng một câu hỏi.

Phép tính trên áp nguyên quy luật bình phương cho toàn bộ prompt, nên hãy coi 10.000 lần là mức trần để hình dung, không phải chênh lệch chi phí thực tế trên hóa đơn. Con số này vẫn có ích ở chỗ cho khách thấy hóa đơn không tăng theo số trang mà tăng nhanh hơn thế.

Ngay cả Google, hãng đang bán cửa sổ 2 triệu token, cũng thừa nhận truy vấn ngữ cảnh dài thường làm tăng thời gian xử lý và đòi thêm tài nguyên tính toán. Introl đưa con số cụ thể hơn: ở độ dài ngữ cảnh tối đa, người dùng có thể phải chờ hơn 2 phút trước khi mô hình bắt đầu sinh chữ.

Với khách tự host mô hình, chẳng hạn một ngân hàng buộc phải chạy on-prem, còn một rào cản nữa. Theo Introl, một mô hình 70B tham số với ngữ cảnh 128K cần khoảng 40GB KV cache cho mỗi người dùng. Thử hình dung 50 nhân viên hỏi cùng lúc: riêng KV cache đã cần khoảng 2.000GB bộ nhớ, chưa tính trọng số mô hình.

Vì thế, trong buổi customer discovery, đừng chỉ hỏi kho tài liệu dài bao nhiêu. Hãy hỏi thêm có bao nhiêu người dùng đồng thời, người dùng chịu chờ bao lâu cho một câu trả lời, và hệ thống chạy trên cloud hay trong data center của khách.

Dưới 500 trang, cứ đưa cả kho vào

Những điều trên không có nghĩa là long context vô dụng. Anthropic nói khá thẳng: kho tri thức nhỏ hơn 200.000 token thì có thể đưa toàn bộ vào prompt, không cần RAG. Thứ làm cách này khả thi là prompt caching, theo Anthropic giúp giảm độ trễ hơn 2 lần và giảm chi phí tới 90%.

IBM mô tả cơ chế chung: prompt caching giảm lượng token phải xử lý, chi phí API và độ trễ cho các yêu cầu lặp lại hoặc tương tự nhau. Chữ “lặp lại” là điều kiện then chốt. Caching phát huy tác dụng nhất khi phần tài liệu đứng đầu prompt ít thay đổi, còn câu hỏi thì thay liên tục.

Thử hình dung cuốn sổ tay chính sách nhân sự 300 trang của một công ty, mỗi năm sửa vài lần, mỗi ngày nhận hàng trăm câu hỏi. Đây là trường hợp lý tưởng để đưa cả kho vào prompt và cache lại. Dựng RAG ở đây là bỏ hai tuần giải một bài toán khách không có.

Ngược lại, nếu tài liệu đổi hằng giờ, như bảng giá hay tồn kho, cache sẽ liên tục mất hiệu lực và lợi thế chi phí co lại. Hãy kiểm chứng lập luận này bằng số đo thật trước khi hứa với khách.

Trên mốc ấy, RAG không chết mà được nâng cấp

Giờ hãy lấy một kho 20.000 trang hợp đồng, gấp bốn lần sức chứa khoảng 5.000 trang của cửa sổ 2 triệu token mà Google công bố. Ở quy mô này không còn gì để tranh luận: bắt buộc phải truy xuất.

Câu hỏi lúc này là làm sao truy xuất tốt hơn. Anthropic cho biết kỹ thuật Contextual Embeddings, tức gắn thêm ngữ cảnh của cả tài liệu vào từng chunk trước khi embedding, giảm 35% tỉ lệ truy xuất sót trong top-20 chunk.

Chi tiết dễ bị bỏ qua nhất trong cả cuộc tranh luận nằm ở một giải thích của IBM: nội dung RAG truy xuất về cũng nằm trong cửa sổ ngữ cảnh khi suy luận. RAG và long context không phải hai phe. Chúng chia nhau cùng một ngân sách token.

Đó là lý do Introl khuyến nghị cách tiếp cận lai: kết hợp ngữ cảnh dài với truy xuất để thông tin quan trọng chắc chắn được đưa lên. Cửa sổ lớn cho phép bạn truy xuất rộng tay hơn, đưa vào cả những section đầy đủ thay vì các mẩu vụn. Còn truy xuất thì bảo đảm đoạn quyết định không bị chôn ở giữa.

Quy mô kho tài liệu	Cách làm hợp lý	Rủi ro chính	Việc đầu tiên ở site khách
Dưới 200.000 token (~500 trang)	Đưa cả kho vào prompt, bật prompt caching	Tài liệu đổi liên tục làm cache mất tác dụng	Đo tần suất cập nhật tài liệu và lượng câu hỏi mỗi ngày
200.000 đến 2 triệu token (~500 đến 5.000 trang)	Lai: truy xuất rộng, dùng cửa sổ dài để chứa section đầy đủ	Lost in the middle, chi phí phi tuyến, chờ lâu ở cuối thang	Chạy test chèn dữ kiện ở đầu, giữa, cuối và đo độ trễ
Trên 2 triệu token (trên ~5.000 trang)	RAG bắt buộc, cải thiện truy xuất (vd. Contextual Embeddings)	Truy xuất sót đoạn quyết định	Dựng bộ câu hỏi chuẩn để đo tỉ lệ sót top-20

Bảng trên chỉ là điểm xuất phát. Ranh giới thật phụ thuộc vào số người dùng đồng thời, giới hạn độ trễ và việc khách chạy cloud hay on-prem. Đó là những thứ bạn chỉ biết sau khi ngồi với họ.

Developer Việt nên luyện gì từ cuộc tranh luận này?

Kỹ năng đáng giá nhất ở đây không phải là thuộc API của một vector store nào đó. Đó là khả năng biến câu hỏi “context hay RAG” thành ba con số đo được trên dữ liệu của khách: tỉ lệ trả lời đúng theo vị trí thông tin, độ trễ đến token đầu tiên, và chi phí cho mỗi nghìn câu hỏi.

Hãy tập thói quen đếm token bằng tokenizer thật thay vì ước theo số trang. Mức khoảng 400 token mỗi trang mà cả Google lẫn Anthropic ngầm dùng chỉ là con số xấp xỉ, trong khi tài liệu của khách có thể đầy bảng biểu, mã hợp đồng hay văn bản scan. Ước lệch một bậc ở bước này là chọn sai cả kiến trúc.

Khi đọc JD cho vị trí FDE hay AI engineer, hãy để ý các cụm như retrieval evaluation, latency budget, on-prem deployment. Chúng cho thấy công ty đang vướng đúng bài toán trong bài này.

Trên CV, thay vì ghi “xây chatbot RAG”, hãy viết rằng bạn đã so full-context với RAG trên một kho bao nhiêu trang, đo được những gì, chọn cách nào và vì sao, kèm số đo của chính bạn.

Cửa sổ ngữ cảnh sẽ còn rộng thêm. Nhưng câu hỏi khách trả tiền để bạn trả lời vẫn không đổi: token nào xứng đáng có chỗ trong cửa sổ, và nên đặt ở vị trí nào.