- Mặc dù giới hạn token đầu vào (cửa sổ ngữ cảnh) của các LLM mới nhất đã được mở rộng lên tới hàng triệu, nhưng ngay cả khi đạt điểm cao trên các benchmark truy xuất đơn giản (Needle in a Haystack, NIAH), vẫn tồn tại rõ ràng sự suy giảm hiệu năng trên đầu vào dài trong thực tế
- Nhóm nghiên cứu đã thực hiện nhiều thí nghiệm trên 18 mô hình, và ngay cả khi chỉ kiểm soát yếu tố tăng độ dài đầu vào, sự suy giảm hiệu năng và các mẫu hành vi thiếu nhất quán vẫn được xác nhận lặp đi lặp lại
- Khi độ tương đồng giữa câu hỏi và đáp án giảm, thêm câu gây nhiễu (distractor), hoặc thay đổi cấu trúc của văn bản, tốc độ suy giảm hiệu năng có thể tăng nhanh hoặc thay đổi theo cách khó dự đoán
- Ngay cả việc duy trì ngữ cảnh có cấu trúc (mạch đoạn văn logic) đôi khi cũng ảnh hưởng tiêu cực đến hiệu năng, cho thấy cách sắp xếp và trình bày đầu vào tác động rất lớn đến hiệu năng của LLM
- Ngay cả những tác vụ rất dễ như sao chép văn bản lặp lại cũng bộc lộ giới hạn trong việc tạo ra kết quả nhất quán khi độ dài đầu vào tăng lên, qua đó nhấn mạnh tầm quan trọng của thiết kế ngữ cảnh (context engineering) trong ứng dụng thực tế
Bối cảnh và mục tiêu nghiên cứu
- Gần đây, khi cửa sổ ngữ cảnh của LLM tăng lên tới 1 triệu~10 triệu token, nhận thức rằng “hiệu năng vẫn được bảo đảm” ngay cả với đầu vào dài đã lan rộng
- Các ví dụ tiêu biểu gồm Gemini 1.5 Pro, GPT-4.1, Llama 4
- Benchmark tiêu biểu Needle in a Haystack (NIAH) thực chất chỉ là truy xuất một câu đơn giản, nên không phản ánh đầy đủ sự suy giảm hiệu năng trong các tác vụ phức hợp thực tế như tóm tắt tài liệu dài hay hỏi đáp
- Nghiên cứu này kiểm chứng có hệ thống sự thay đổi hiệu năng bằng cách chỉ điều chỉnh độ dài đầu vào, trong khi giữ nguyên độ khó của tác vụ
Các thí nghiệm chính và kết quả
- Trên 18 LLM hiện đại (Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen, v.v.), nghiên cứu thiết kế tổng cộng 4 loại thí nghiệm:
- Thay đổi độ tương đồng ngữ nghĩa giữa câu hỏi và đáp án (Needle-Question)
- Thêm câu gây nhiễu (distractor)
- Thay đổi chủ đề/cấu trúc của văn bản (haystack)
- Sao chép từ lặp lại (mở rộng đồng thời độ dài đầu vào và đầu ra)
- Trong mọi thí nghiệm, độ dài đầu vào càng tăng thì hiệu năng càng suy giảm mạnh, và đặc biệt mức suy giảm càng lớn khi độ tương đồng ngữ nghĩa thấp hoặc có nhiều câu gây nhiễu
- Độ tương đồng giữa câu hỏi và đáp án càng thấp, tỷ lệ trả lời sai trên đầu vào dài càng tăng vọt
- Chỉ cần thêm một câu gây nhiễu là độ chính xác đã giảm ngay, và khi thêm từ 4 câu trở lên thì hiện tượng nhầm lẫn và ảo giác (hallucination) tăng mạnh tùy theo từng mô hình
- Ví dụ: dòng Claude có xu hướng né tránh bằng cách trả lời “không thể tìm thấy đáp án” thay vì trả lời sai, trong khi dòng GPT tạo ra nhiều câu trả lời sai nhưng rất tự tin hơn
- Một hiện tượng đặc biệt cũng được quan sát thấy: hiệu năng có thể đảo chiều tùy theo cấu trúc văn bản (dòng chảy logic/sắp xếp ngẫu nhiên)
- Với văn bản gốc (Original) giữ nguyên dòng chảy logic, hiệu năng mô hình lại kém hơn
- Với văn bản bị xáo trộn câu (Shuffled), hiệu năng truy xuất lại cao hơn
- Ngay cả trong thí nghiệm sao chép từ lặp lại, khi token đầu vào và đầu ra tăng lên, các mẫu khó đoán như tỷ lệ sai tăng, từ chối thực hiện tác vụ, hoặc sinh ra từ ngẫu nhiên cũng tăng theo
- Ví dụ: sau mốc 2.500~5.000 từ, một số mô hình bắt đầu tăng mạnh các kết quả bất thường như từ chối sao chép hoặc sinh văn bản ngẫu nhiên
LongMemEval: đánh giá hội thoại dài sát thực tế
- Trên benchmark LongMemEval có chứa nhật ký hội thoại thực tế, nghiên cứu so sánh đầu vào tập trung (chỉ gồm phần liên quan đến đáp án) và đầu vào đầy đủ (bao gồm cả ngữ cảnh không liên quan đến đáp án)
- Ở mọi mô hình, đầu vào tập trung đều cho độ chính xác cao hơn nhiều, còn với đầu vào đầy đủ thì việc tự tìm phần liên quan trở thành một tác vụ bổ sung, làm hiệu năng suy giảm đáng kể
- Các mô hình dòng Claude đặc biệt có xu hướng né tránh bằng câu trả lời “không có đáp án” trong những tình huống mơ hồ
Phân tích bổ sung và hàm ý
- Nghiên cứu phân tích chi tiết bằng nhiều biểu đồ về sự khác biệt trong mẫu vận hành nội tại của từng mô hình, như tỷ lệ nhầm lẫn theo từng câu gây nhiễu, độ chính xác vị trí câu trả lời, vị trí sinh ra từ ngẫu nhiên, v.v.
- Trong thí nghiệm sao chép từ lặp lại, có các đặc tính phụ thuộc vị trí như từ đáp án nằm càng gần đầu thì độ chính xác càng cao
- Vì thiết kế ngữ cảnh (sắp xếp thông tin, quản lý dòng chảy logic, v.v.) ảnh hưởng rất lớn đến hiệu năng mô hình, nghiên cứu gợi ý rằng không thể kỳ vọng hiệu năng nhất quán chỉ bằng cách đơn thuần mở rộng ngữ cảnh khi triển khai trong dịch vụ thực tế
Kết luận
- Khả năng xử lý đầu vào dài của LLM không thể được bảo đảm chỉ bằng điểm benchmark, và ngay cả việc tăng độ dài đầu vào trong thực tế cũng có thể dẫn tới suy giảm hiệu năng thiếu nhất quán
- Chỉ đưa thông tin liên quan vào là chưa đủ; cách sắp xếp, cấu trúc, câu gây nhiễu và độ tương đồng đều ảnh hưởng mang tính quyết định đến hiệu năng
- Khi ứng dụng LLM, việc quản lý và thiết kế ngữ cảnh dài (context engineering) là điều bắt buộc
2 bình luận
Bản 2.5 ra cũng khá lâu rồi mà sao lại dùng 1.5
Ý kiến trên Hacker News
Tôi cũng đã có trải nghiệm tương tự. Đặc biệt khi dùng Gemini Pro, nếu cung cấp tham chiếu văn bản dài thì thay vì nhét nhiều tài liệu vào context window cùng lúc, việc tóm tắt từng tài liệu trước rồi đặt câu hỏi, sau đó nếu cần mới cung cấp toàn bộ tài liệu chi tiết theo kiểu RAG hoặc một vòng lặp agent đơn giản, cho ra câu trả lời tốt hơn nhiều. Tương tự, khi dùng Claude Code cùng với Opus hoặc Sonnet, tôi cũng trực tiếp thấy rằng càng xảy ra nhiều lần compaction thì kết quả càng tệ. Tôi không chắc là do chất lượng bản tóm tắt kém đi hay do tỷ trọng dữ liệu ít liên quan trong context window tăng lên, nhưng khi xóa context và bảo nó chỉ đọc lại các file liên quan thôi thì kết quả tốt hơn hẳn, dù những nội dung đó đã được nhắc trong phần tóm tắt trước đó
Gemini bắt đầu sụp đổ về tính nhất quán và năng lực suy luận trước cả khi chạm tới giới hạn context của chat. Dù vậy, theo báo cáo này thì nó vẫn là mô hình tốt nhất trên nhiều phương diện. Kết luận là context engineering vẫn quan trọng, và cách tiếp cận RAG vẫn còn nguyên giá trị
"Compaction" về cơ bản chỉ là rút transcript thành bản tóm tắt đúng không? Nếu vậy thì việc hiệu năng giảm là điều dễ hiểu vì thông tin thực sự bị mất đi. Nhưng đó không phải là context rot. Tín hiệu context rot thật sự xuất hiện khi tiến gần ngưỡng auto-compact. Tôi hiểu vậy có đúng không?
Một coding agent tối ưu có lẽ nên tự động làm quy trình này. Nó sẽ thu thập mã cần thiết, phản hồi MCP, bản đồ repo, v.v., thỉnh thoảng tóm tắt lại, rồi gộp tất cả thành một tin nhắn chat mới chỉ giữ những phần thật sự cần thiết. Tôi đã dùng phong cách này với công cụ aider, và trong những tình huống cần nhiều context thì nó cho hiệu năng tốt hơn hẳn so với workflow agentic hay tự động hóa hơn. Chỉ là khá tốn công
Bạn đã thử NotebookLM chưa? Ứng dụng này chia nhỏ và tóm tắt tài liệu ở hậu trường, rồi cho phép hỏi đáp toàn bộ tài liệu theo dạng chat thông qua RAG
Tôi nhận thấy rằng ở Cursor, càng nói chuyện lâu về một tính năng mới hay thay đổi mã thì kết quả đầu ra càng tệ dần. Kết quả tốt nhất đến khi tôi lập trước các chỉ dẫn và kế hoạch rõ ràng, cụ thể, rồi kéo trực tiếp các file cần sửa vào context prompt
Đi theo luồng "Explore → plan → code → test → commit" hữu ích hơn nhiều. Nếu cần, có thể xóa context ở mỗi bước để tăng hiệu quả
Khi đã gom đủ thông tin cho một tác vụ cụ thể, tôi lưu lại context vào lúc đó. Nếu thấy chất lượng giảm, tôi tóm tắt lại phần việc đã làm tới thời điểm hiện tại rồi nối vào checkpoint trước đó
Hiện tượng này vốn đã được biết đến khá nhiều, nhưng rất ít nơi tài liệu hóa tử tế, nên tôi rất vui khi thấy bài này. Tôi nghĩ tác động thực tế còn lớn hơn mức khó có thể đo dễ dàng bằng benchmark. Những ứng dụng LLM thực sự hữu ích đều đang hoạt động sát giới hạn những gì mô hình có thể làm được. Tức là chúng có ý nghĩa khi phải lần theo context cần "nhảy" logic nhiều lần trong câu hỏi hay tác vụ thực tế. Theo tôi, càng cần nhiều lần "nhảy" logic thì vấn đề context rot càng trở nên nghiêm trọng theo cấp số nhân, vì ở mỗi lần nhảy số thứ cần chú ý lại tăng lên
Nhất định phải có cách cắt bỏ context thật dễ dàng. Nếu tôi có thể tự quản lý toàn bộ cuộc trò chuyện với mô hình, có lẽ tôi sẽ khai thác được hiệu năng tốt hơn nhiều trong một phiên coding cỡ 200 nghìn token. Nhưng thực tế là kể cả dùng instance tốt thì sau khoảng 20 nghìn token mô hình đã bắt đầu cư xử kỳ quặc, rồi cả phiên cũng rot hoàn toàn. Giá mà có thể đơn giản cắt bỏ đoạn đó đi
LLM chạy cục bộ cho phép chỉnh sửa context theo ý muốn, nên nếu bạn sửa luôn phản hồi của LLM thì về sau mô hình có thể tưởng đó là điều nó vốn đã nói. Vì vậy điều này có lợi cho việc dẫn dắt nó theo hướng mong muốn. Ngược lại, mô hình LLM-as-a-service không cung cấp tính năng như vậy vì nó sẽ khiến việc lách kiểm duyệt trở nên dễ hơn
Tôi đã thử yêu cầu: "Này Claude, tôi sắp reset context, hãy tạo cho tôi một prompt để tôi có thể tiếp tục làm việc về sau", rồi xem trước và chỉnh lại prompt mà Claude đề xuất trước khi đưa vào lại
Nếu có thể dễ dàng rollback về checkpoint trước đó thì đó thật sự sẽ là tính năng tuyệt vời nhất
Trong hầu hết các CLI agent, có thể làm việc này bằng lệnh
/compressKhi dùng Claude code, dần dần nó không còn phân biệt được lỗi của chính nó với chỉ thị của tôi. Một khi nó bắt đầu rối thì cách giải quyết là mở phiên mới. Càng về cuối phiên, nó càng lặp cùng một vòng hoặc cứ khăng khăng rằng bài test đã hỏng sẵn nên bỏ qua luôn, dù thực ra nó bị hỏng trong chính phiên này. Có lẽ là do tôi prompt chưa tốt, nhưng dạo này cảm giác như Claude bỗng dưng tụt mất khoảng 30 IQ
Tôi cũng cảm thấy y hệt. Dù đang dùng gói Max, vẫn có lúc hiệu năng tốt và lúc thì không
Việc nghĩ rằng "chắc là prompt và context của mình có vấn đề" mang cảm giác như cả bọn mình đã nội tâm hóa kiểu gaslighting vậy
Đây là một dạng của bài toán truy xuất thông tin, nhưng tôi nghĩ sự suy giảm hiệu năng do thay đổi độ dài context có thể hoạt động khác với các câu trả lời truy xuất đơn thuần. Ví dụ, nó có thể vận hành khác với những câu như “làm sao sửa nút này thành màu đỏ?” hay “các câu ở trên thuộc danh mục nào?”. Một bài báo tôi từng thấy rất ấn tượng là Many-Shot In-Context Learning. Nghiên cứu này cho thấy hiện tượng hiệu năng tăng mạnh khi lấp đầy context bằng các ví dụ. Cuối cùng, với từng bài toán thì vẫn phải trực tiếp thử nghiệm mới biết LLM thay đổi ra sao theo nội dung và độ dài context. Không nên luôn mặc định rằng context càng dài thì hiệu năng càng giảm
Đây là một bài viết rất hay và nhiều insight. Tuy vậy, xét từ góc độ media literacy thì cũng nên lưu ý rằng Chroma là một công ty vector DB
Gần đây tôi đã viết nhiều tiểu thuyết dài bằng Gemini 2.5 Flash, và đúng là có cảm nhận được context rot, nhưng nó xuất hiện muộn hơn nhiều so với bài báo này nêu ra. Trường hợp của tôi là phải qua khoảng 50 nghìn đến 100 nghìn token thì nó mới bắt đầu phớt lờ context ban đầu, ví dụ như ngôn ngữ đầu ra. Có lẽ với các tác vụ phức tạp như sáng tác, hiệu ứng này khó đo hơn hoặc kém rõ ràng hơn. Dù sao thì, chỉ cần thỉnh thoảng chèn lại phần context bị thiếu thì vẫn giữ được mức độ dùng được
Tôi cũng có trải nghiệm tương tự. Trong một dự án, tôi đang phát triển tính năng tìm kiếm transcript video, và độ dài văn bản là cực lớn. Tôi từng nghĩ các mô hình như GPT 4.1 có context window lớn nên sẽ không cần RAG, nhưng hiện tượng kỳ lạ vẫn xảy ra khá thường xuyên, nhất là với các mô hình nhỏ hơn. Có khi nó không trả lời đúng câu hỏi mà chỉ đơn giản tóm tắt toàn bộ nội dung
Báo cáo khá thú vị. Tôi muốn biết liệu có kích thước context được khuyến nghị theo từng mô hình hay không. Tôi cũng muốn biết có cách nào để xác định ngưỡng nào là phù hợp cho use case của mình hay không