Xử lý ngữ cảnh dài đang bị cuốn vào cuộc đua thông số giữa các nhà cung cấp mô hình, và con số in trên trang thông số lại là thứ dễ tin nhất trong cả câu chuyện. Nhiều người vẫn tưởng rằng cửa sổ ngữ cảnh (context window) lên tới hàng triệu token nghĩa là cứ ném hết dữ liệu vào rồi kỳ vọng mô hình xử lý hoàn hảo. Con số làm tôi từ bỏ cách nghĩ đó là -85,0: đó là mức điểm phần trăm mà Llama-3.1-8B đánh rơi ở tác vụ tính tổng biến số khi ngữ cảnh dài ra, trong khi mọi dữ liệu nó cần vẫn nằm nguyên trong đầu vào. Thực tế, tăng độ dài ngữ cảnh không hề đi đôi với tăng hiệu quả xử lý, và các kỹ sư hệ thống cần hiểu rõ khái niệm "ngân sách chú ý" (attention budget) để thiết kế agent hiệu quả.
Khi bạn nạp hàng trăm nghìn token, mô hình không "đọc" chúng theo cách chúng ta đọc sách. Mỗi token mới nạp thêm đều bào mòn "ngân sách chú ý", làm loãng tín hiệu cần thiết và đẩy nhiễu lên. Kích thước đầu vào và độ chính xác của phản hồi đánh đổi trực tiếp với nhau, không có cách nào né. Mô hình có thể chấp nhận cửa sổ 1M token nhờ các kỹ thuật nội suy, nhưng khả năng suy luận trên đống dữ liệu đó thường sụt giảm đáng kể ngay khi vượt quá một ngưỡng nhất định, bất kể thông tin bạn cần có nằm rõ ràng trong văn bản hay không.
Vì sao mô hình kém đi khi ngữ cảnh dài ra?
Gốc rễ của sự suy giảm này nằm ngay trong kiến trúc Transformer. Trong cơ chế tự chú ý (self-attention), mọi token phải chú ý đến mọi token khác, tạo ra một mạng lưới quan hệ n². Khi số token (n) tăng lên, số quan hệ ma trận mà mô hình phải tính và phải giữ trong đầu bùng nổ theo hàm bình phương. "Ngân sách chú ý" của các đầu (heads) trong Transformer bị kéo căng quá mức, khiến khả năng nắm bắt các phụ thuộc tầm xa (long-range dependencies) bị suy yếu. Bạn cứ hình dung mình phải giữ tập trung vào một chi tiết nhỏ khi đang đứng giữa sân vận động đầy tiếng hò hét; mô hình cũng đúng cảnh đó khi phải moi bằng chứng cốt lõi ra khỏi đống token "rác" vây quanh.
Dữ liệu huấn luyện cũng tạo ra một định kiến phân phối (distribution bias) cực kỳ nguy hiểm. Hầu hết các mô hình ngôn ngữ lớn (LLM) hiện nay, kể cả những dòng mạnh nhất, đều được huấn luyện chủ yếu trên các chuỗi văn bản ngắn. Vì thế các tham số của mô hình quen với những khối thông tin gọn gàng hơn nhiều. Khi bạn nới rộng ngữ cảnh thông qua các kỹ thuật như nội suy vị trí (position encoding interpolation), bạn thực tế đang bắt mô hình hoạt động ở những dải tần số mà nó chưa từng được tối ưu thực sự trong giai đoạn tiền huấn luyện (pre-training). Cách đó giúp mô hình "chấp nhận" đầu vào dài hơn mà không nổ lỗi hệ thống, nhưng cái giá phải trả là nó mờ dần trong việc định vị chính xác và trong việc nối logic giữa các đoạn văn bản cách xa nhau.
Báo cáo "Context Rot" từ Chroma chỉ ra rằng hiệu suất của mô hình không chỉ giảm ở các tác vụ phức tạp mà ngay cả ở những yêu cầu đơn giản như trích xuất thông tin. Hiện tượng thối rữa ngữ cảnh này cho thấy độ tin cậy của mô hình trở nên không đồng nhất và khó dự đoán khi đầu vào dài ra. Đặc biệt, Claude Sonnet 4 và Opus 4 có xu hướng cực kỳ bảo thủ: chúng từ chối trả lời (refusal) và nói thẳng là không tìm thấy đáp án khi ngữ cảnh quá nhiễu hoặc mơ hồ, trong khi các mô hình GPT lại dễ rơi vào bẫy ảo giác (hallucination), tạo ra một câu trả lời tự tin nhưng sai lệch dựa trên các thông tin gây nhiễu (distractors).
Sự suy yếu này tạo ra một "độ dốc hiệu suất" (performance gradient). Mô hình không sụp đổ ngay tại một mốc token cố định, mà kém dần đều, nên bạn sẽ không có cái mốc rõ ràng nào để bám vào khi đặt hạn mức. Khả năng sử dụng thông tin để suy luận logic bị tổn thương nặng nề hơn nhiều so với khả năng trích xuất văn bản thuần túy. Nghĩa là nếu bạn bắt mô hình đọc một tài liệu 100K token rồi giải toán, khả năng nó làm sai cao hơn hẳn so với khi chỉ yêu cầu nó chép lại một đoạn văn trong chính tài liệu đó, dù cả hai việc đều phải với tới cùng một vùng dữ liệu.
Độ dài ngữ cảnh hiệu dụng khác gì con số nhà cung cấp công bố?
Con số tiếp thị và độ dài ngữ cảnh hiệu dụng là hai chuyện khác nhau, và bạn cần phân biệt rạch ròi. Các nhà cung cấp có thể quảng cáo 128K, 1M hay thậm chí nhiều hơn, nhưng đó chỉ là giới hạn vật lý của cửa sổ đầu vào. Nghiên cứu "Context Length Alone Hurts" cho thấy hiệu suất thực tế của các mô hình hàng đầu hiện nay thường sụt giảm nghiêm trọng rất lâu trước khi chạm tới giới hạn quảng cáo. Llama-3.1-8B là ví dụ điển hình: dù tuyên bố hỗ trợ 128K token, độ chính xác của nó trong các tác vụ suy luận bắt đầu lao dốc ngay khi vượt ngưỡng 30K token, tức là lúc bạn còn chưa dùng hết một phần tư cửa sổ được quảng cáo.
Dưới đây là mức sụt giảm độ chính xác khi tăng ngữ cảnh lên 30.000 token trên các tập dữ liệu chuẩn, tính bằng điểm phần trăm so với mốc không có ngữ cảnh đệm. Không có cột nào trong bảng dưới đây nhẹ nhàng cả:
| Tác vụ | Llama-3.1-8B | Mistral-v0.3-7B |
|---|---|---|
| Variable Summation (VarSum) | -85,0 | -66,0 |
| GSM8K (Toán học) | -12,3 | -34,2 |
| MMLU (QA đa ngành) | -24,2 | -20,3 |
| HumanEval (Lập trình) | -47,6 | -34,8 |
Trên toàn bộ thí nghiệm, mức suy giảm trải dài từ 13,9% đến 85%, và tất cả đều xảy ra khi đầu vào vẫn nằm gọn trong giới hạn mà mô hình công bố.
Số liệu này cho thấy một sự thật phũ phàng: việc xử lý ngữ cảnh dài giống như việc bắt mô hình làm toán trong một căn phòng đầy tiếng hét. Các tác vụ đòi hỏi độ chính xác cao như tính tổng biến số (VarSum) bị ảnh hưởng nặng nề nhất. Ở mức 30K token, Llama-3.1-8B gần như mất hoàn toàn khả năng tính tổng biến số chính xác, dù tất cả các giá trị biến đều nằm trong ngữ cảnh đầu vào. Nhồi token vào cửa sổ ngữ cảnh mà không chọn lọc, vì thế, không phải là một lựa chọn thiết kế trung tính: đó là một sai lầm kỹ thuật.
Độ dốc hiệu suất này diễn ra liên tục chứ không theo bậc. Với Mistral-v0.3-7B, hiệu suất trên MMLU giảm 20,3 điểm phần trăm khi ngữ cảnh dài ra. Trong khi đó, mức giảm 34,8 điểm trên HumanEval cho thấy khả năng lập trình của mô hình bị tổn thương sâu sắc khi cấu trúc mã nguồn bị pha loãng bởi các thông tin không liên quan. Là kỹ sư, bạn không nên thiết kế hệ thống quanh con số tối đa của nhà cung cấp, mà nên thiết kế quanh cái ngưỡng an toàn nơi mô hình còn giữ được độ chính xác bạn chấp nhận được.
Các kiến trúc cũng không chịu đựng như nhau. Trong khi các dòng mô hình đóng (closed-source) có kỹ thuật tối ưu riêng để giữ hiệu suất tốt hơn ở dải ngữ cảnh lớn, các mô hình mã nguồn mở thường đuối sớm hơn nhiều. Điều này có thể do quy trình tinh chỉnh (fine-tuning) trên dữ liệu dài của các mô hình đóng được đầu tư bài bản hơn. Nhưng dù là mô hình nào, quy luật về ngân sách chú ý vẫn nguyên đó: bạn càng nạp nhiều thông tin không liên quan, xác suất mô hình đi sai hướng càng cao.
Truy hồi chính xác hơn đã đủ chưa?
Ngộ nhận phổ biến nhất trong cộng đồng AI là câu này: "Mô hình làm sai ở ngữ cảnh dài vì nó không tìm thấy thông tin (retrieval failure)". Thí nghiệm "Perfect Retrieval" cho thấy điều ngược lại. Trong thử nghiệm này, các nhà nghiên cứu buộc mô hình phải trích xuất (recite) chính xác bằng chứng cần thiết trước khi đưa ra câu trả lời. Kết quả cho thấy ngay cả khi mô hình chép lại đúng từng từ đoạn văn chứa đáp án, nó vẫn có thể giải sai bài toán nếu ngữ cảnh đi kèm quá dài.
Số liệu từ Llama-3.1-8B nói rất rõ: ở mức 30K token, mô hình trích xuất đúng nguyên văn bằng chứng cho 970 trên 1.000 câu hỏi MMLU, tức là nó "thấy" và "đọc" được dữ liệu, nhưng độ chính xác khi giải vẫn giảm 24,2 điểm phần trăm so với khi giải chính bài toán đó ở ngữ cảnh ngắn. Điều này xác nhận rằng vấn đề cốt lõi không nằm ở khả năng truy hồi, mà nằm ở khả năng sử dụng thông tin. Một lượng lớn token nằm trong cửa sổ chú ý đã đủ làm nhiễu quá trình suy luận, khiến mô hình không nối chính xác được các điểm dữ liệu dù chính nó vừa chép chúng ra.
Thậm chí, các token hoàn toàn trung lập cũng gây hại. Thí nghiệm chèn hàng nghìn khoảng trắng (whitespace), loại token vốn không mang ngữ nghĩa nào, vào giữa bằng chứng và câu hỏi vẫn kéo hiệu suất VarSum của Llama-3.1-8B từ 96,0 xuống 48,0. Ngay cả khi bạn dùng kỹ thuật che (masking) để mô hình chỉ chú ý đến các token liên quan, việc tăng khoảng cách vật lý giữa bằng chứng và câu hỏi vẫn làm suy yếu khả năng tính toán. Khoảng cách trong không gian chú ý, tự nó, đã là một khoản chi phí: càng xa thì khả năng giữ logic chặt chẽ dường như càng giảm.
Từ góc nhìn kỹ thuật, điều này có nghĩa là truy hồi chỉ là điều kiện cần chứ không phải điều kiện đủ. Cải thiện RAG để lấy về 20 tài liệu thay vì 5 tài liệu có thể phản tác dụng nếu bạn không kiểm soát được độ nhiễu đi kèm. Ngữ cảnh dài tự nó là một tác nhân gây nhiễu, làm loãng trọng số chú ý (attention weights) vốn nên được tập trung vào các token then chốt. Bài học cho kỹ sư: đừng dừng ở câu hỏi mô hình có "thấy" dữ liệu hay không, mà hãy lo cho việc dữ liệu đó xuất hiện trong một ngữ cảnh gọn nhất có thể.
Khi nào nhồi toàn bộ tài liệu thắng, khi nào truy hồi thắng?
Các nghiên cứu so sánh trực tiếp giữa nhồi toàn bộ ngữ cảnh (Long Context, gọi tắt là LC) và truy hồi tăng cường (Retrieval-Augmented Generation, RAG) không cho ra một người thắng cuộc. Chiến lược nào ăn điểm còn tùy vào cấu trúc của tri thức bạn đang xử lý. LC thường chiếm ưu thế trong các bài toán hỏi đáp dựa trên Wikipedia hoặc tài liệu có tính hệ thống cao. Lý do là LC giúp mô hình giữ được sự mạch lạc (coherence) và nắm được mạch tổng thể của tài liệu, tránh được phần thông tin rơi rụng khi cắt nhỏ tài liệu (chunking) trong RAG.
Ngược lại, RAG lại chiếm ưu thế trong các kịch bản hội thoại và các truy vấn mang tính lọc thông tin từ kho dữ liệu khổng lồ. RAG hoạt động như một bộ lọc nhiễu chủ động. Hội thoại dài vốn đầy thông tin thừa, và truy hồi giúp gạt đám token rác đó ra để chỉ nạp vào mô hình những gì thực sự liên quan. Nghiên cứu cũng chỉ ra rằng hiệu suất của RAG phụ thuộc cực lớn vào độ liên quan của ngữ cảnh (context relevance). Nói cách khác, RAG không miễn nhiễm với chính căn bệnh nó đi chữa: nếu hệ thống của bạn lấy về quá nhiều đoạn văn không liên quan, nó phá khả năng suy luận của mô hình y hệt như khi bạn nhồi ngữ cảnh dài thủ công.
Hiện tượng "lost in the middle", tức là mất tập trung ở khúc giữa, vẫn là cái bẫy chết người với cả LC lẫn RAG. Mô hình có xu hướng chú ý tốt nhất vào các thông tin nằm ở đầu và cuối cửa sổ ngữ cảnh. Nếu bằng chứng quan trọng nhất bị kẹp ở giữa một đống tài liệu nhồi nhét, xác suất mô hình lướt qua nó rất cao. Với các tác vụ đòi hỏi sự tổng hợp thông tin từ nhiều nguồn rải rác, việc sử dụng các kỹ thuật truy hồi nâng cao như xếp hạng lại (re-ranking) để đưa các đoạn quan trọng nhất lên đầu ngữ cảnh gần như là bắt buộc.
Vậy nên hãy chọn LC khi bạn cần mô hình hiểu sâu cấu trúc logic của một tài liệu duy nhất, chẳng hạn một cuốn sách hoặc một file mã nguồn lớn. Hãy chọn RAG khi bạn làm việc với hàng nghìn tài liệu hoặc các cuộc hội thoại dài lê thê, nơi mà việc lọc nhiễu quan trọng hơn việc duy trì sự mạch lạc toàn phần. Và trong mọi trường hợp, hãy luôn cảnh giác với việc nhồi nhét tài liệu không liên quan vào cửa sổ ngữ cảnh, vì đó là con đường ngắn nhất dẫn đến sai sót suy luận.
Cái giá thật của mỗi chiến lược: chi phí, độ trễ, cache
Xử lý ngữ cảnh dài không bao giờ là miễn phí. Cái giá bạn trả là độ trễ (latency) và hóa đơn API, cả hai đều bùng nổ. Mỗi token đầu vào đều kéo theo một loạt phép tính ma trận chú ý. Với một cửa sổ ngữ cảnh rất lớn, thời gian để mô hình trả về token đầu tiên (Time To First Token, TTFT) kéo dài thấy rõ, và người dùng là người ngồi chịu trận. Chi phí tính toán cũng leo theo, nên nếu không có chiến lược tối ưu, nhồi hết mọi thứ vào là cách đốt tiền nhanh nhất mà vẫn tưởng mình đang làm đúng.
Prompt caching là công cụ quan trọng nhất để giảm thiểu cái giá này. Bằng cách đặt các breakpoint cache_control tại system prompt hoặc các khối dữ liệu cố định như hướng dẫn dự án hay đặc tả API, bạn có thể tái sử dụng kết quả tính toán của các lượt request trước. Điều này cực kỳ hữu ích khi kết hợp với tính năng nén (compaction). Kỹ thuật tốt nhất là đặt breakpoint ở cuối system prompt để nó không bị vô hiệu hóa mỗi khi lịch sử hội thoại thay đổi hoặc được nén lại, vì nếu không, mỗi bản tóm tắt mới sinh ra sẽ làm hỏng toàn bộ cache phía trước.
Tuy nhiên, bạn cần lưu ý về chi phí của chính việc nén ngữ cảnh. Tính năng này yêu cầu thêm một bước lấy mẫu (sampling step), tức là mô hình phải tự chạy một lượt để tóm tắt lại chính nó. Bước này tiêu tốn token đầu ra, đóng góp vào giới hạn tốc độ (rate limits) và làm tăng hóa đơn của lần request đó. Bạn có thể theo dõi điều này qua mảng iterations trong phản hồi API, nơi phân biệt rõ lượt "compaction" với lượt "message" cuối cùng.
Còn một đánh đổi nữa về độ trễ, giữa nạp trước và nạp vừa đúng lúc. Cách tiếp cận just-in-time, tức là để agent tự gọi công cụ đọc thêm dữ liệu khi cần, chậm hơn việc nạp sẵn mọi thứ, nhưng đổi lại mô hình không bị chết đuối trong dữ liệu không liên quan. Đừng chỉ nhìn giá mỗi triệu token mà nhà cung cấp đưa ra; hãy cộng cả bước nén, bước truy hồi và thời gian người dùng phải ngồi chờ vào tổng chi phí.
Tóm tắt và nén ngữ cảnh hoạt động ra sao trong tác vụ dài?
Nén ngữ cảnh (compaction) sinh ra cho các hệ thống agent chạy dài hạn. Thay vì cắt phăng các tin nhắn cũ khi hết cửa sổ ngữ cảnh, API tự chạy một quy trình bốn bước: phát hiện ngưỡng token, tạo bản tóm tắt, tạo khối nén (compaction block), rồi tiếp tục phản hồi. Bạn cấu hình ngưỡng kích hoạt qua tham số trigger: mặc định là 150.000 token đầu vào, và giá trị thấp nhất bạn được phép đặt là 50.000 token.
Theo tôi, đây là chỗ nhiều kỹ sư hay vấp: nén ngữ cảnh có thể thất bại khi bạn đang khai báo công cụ. Tài liệu cảnh báo rằng khi request có tools, mô hình thỉnh thoảng gọi một công cụ ngay trong bước tóm tắt nội bộ thay vì viết bản tóm tắt, và bạn nhận về một compaction block với content: null. Cách phòng là dùng tham số instructions để nói thẳng rằng không được gọi công cụ nào trong bước này, chỉ trả lời bằng văn bản. Nhưng hãy nhớ: instructions thay thế hoàn toàn hướng dẫn tóm tắt mặc định chứ không bổ sung vào nó, nên nếu bạn chỉ viết "tập trung vào mã nguồn" thì phần dặn dò giữ lại trạng thái chung và các bước tiếp theo cũng mất luôn.
Ngoài ra, với Claude Fable 5.1 và Claude Mythos 5.1, các khối suy nghĩ (thinking block) nằm trước compaction block không được mang theo sang cửa sổ mới: bản tóm tắt là tất cả những gì mô hình còn giữ lại được về đoạn suy luận đó. Riêng trên Claude Fable 5.1, nếu bạn tự chèn lại các lượt trợ lý cũ sau khối nén, bạn phải bỏ các block thinking và redacted_thinking ra khỏi chúng. Tham số pause_after_compaction cho phép hệ thống dừng lại ngay sau khi sinh bản tóm tắt, đủ để bạn xen vào và tự quyết định giữ lại những gì.
Về phía mã nguồn, bạn bắt buộc phải truyền lại compaction block trong mọi request tiếp theo. Khi API nhận được một compaction block, nó sẽ tự động bỏ qua toàn bộ các block nằm phía trước đó trong lịch sử tin nhắn. Nếu bạn quên truyền khối này, toàn bộ ký ức của agent về đoạn hội thoại trước coi như bị xóa sạch, và hệ thống xóa trong im lặng chứ không báo lỗi gì cho bạn. Logic xử lý tin nhắn phải đủ chắc để chèn và giữ các khối này xuyên suốt phiên làm việc.
Chọn chiến lược nào cho hệ thống của bạn?
Đừng thiết kế hệ thống dựa trên con số triệu token in trên trang thông số. Hãy thiết kế sao cho ngữ cảnh nạp vào mô hình là tập hợp nhỏ nhất các token có tín hiệu cao. Chiến lược tôi ưu tiên luôn là truy hồi trước, giải sau: dùng một bước truy hồi mạnh để biến bài toán ngữ cảnh dài thành bài toán ngữ cảnh ngắn. Bắt mô hình chép lại bằng chứng trước khi giải giúp GPT-4o tăng tối đa 4 điểm phần trăm trên tác vụ QA2 của RULER ở mức 32K token, một mức cải thiện khiêm tốn nhưng ổn định, và nó nằm ngay trên nền một baseline vốn đã rất mạnh.
Tùy quy mô tác vụ, hãy chọn kiến trúc phù hợp:
- Nén ngữ cảnh (compaction): dành cho chatbot và hội thoại kéo dài, nơi chính lịch sử trò chuyện là ngữ cảnh.
- Ghi chú có cấu trúc (structured note-taking): dành cho agent lập trình hoặc nghiên cứu. Agent tự duy trì một file
NOTES.mdchứa trạng thái hiện tại, việc đã xong và bước kế tiếp, rồi đọc lại chính nó sau mỗi lần reset ngữ cảnh. - Sub-agent: dành cho các dự án khổng lồ. Một sub-agent đọc hết phần tài liệu nặng rồi chỉ trả về một bản tóm tắt gọn cho agent chính.
Mục tiêu cuối cùng của context engineering là quản lý sự chú ý của mô hình. Một kỹ sư giỏi không phải là người biết cách nhồi nhiều dữ liệu nhất, mà là người biết cách loại bỏ nhiều dữ liệu nhất mà vẫn giữ được câu trả lời đúng.
Tài liệu tham khảo
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma
- Lost in the Middle: How Language Models Use Long Contexts
- Context Length Alone Hurts LLM Performance Despite Perfect Retrieval
- Long Context vs. RAG for LLMs: An Evaluation and Revisits
- RAG vs. prompt stuffing: Do we still need vector retrieval? — Weights & Biases
- Effective context engineering for AI agents — Anthropic
- Compaction — Claude Platform Docs
- Long context — Gemini API, Google AI for Developers