Nén ngữ cảnh (context compaction) là gì và khi nào nên dùng?

Nén ngữ cảnh (context compaction) là kỹ thuật cô đọng toàn bộ lịch sử hội thoại thành một bản tóm tắt có cấu trúc, thay vì để cửa sổ ngữ cảnh (context window) đầy tràn khiến mô hình bắt đầu "quên" hoặc phản hồi chậm chạp.

Đây là cách bạn cứu hệ thống khỏi "chết" độ trễ và cạn kiệt ngân sách khi AI agent phải xử lý những phiên làm việc dài.

Về bản chất, đây là quá trình lọc tín hiệu: loại bỏ những dữ liệu nhiễu và các bước thực hiện trung gian đã hoàn thành, chỉ giữ lại trạng thái nhiệm vụ và các ràng buộc cốt lõi. Nghe qua có vẻ đơn giản, nhưng quyết định "cái gì là nhiễu" mới là chỗ một hệ thống tác nhân sống hoặc chết.

Với tư cách kỹ sư hệ thống, bạn cần hiểu rằng nén ngữ cảnh không đơn thuần là tiết kiệm bộ nhớ: đây là công cụ tối ưu hiệu suất mô hình.

Mục tiêu là duy trì một tập hợp "token tín hiệu cao" (high-signal tokens) trong mọi lần gọi API.

Lịch sử hội thoại dài được cô đọng thành một khối tóm tắt có cấu trúc trong cửa sổ ngữ cảnh

Nén ngữ cảnh là gì?

Về mặt kỹ thuật, nén ngữ cảnh (context compaction) là quá trình chuyển đổi dữ liệu thô (raw history) từ một phiên làm việc dài thành một biểu diễn có cấu trúc, độ trung thực cao (high-fidelity representation). Hãy nghĩ đến cái "hand-off note" một kỹ sư để lại cho người trực ca sau. Không ai dán nguyên hàng nghìn dòng lịch sử chat trên Slack vào đó cả; người ta viết lại các quyết định đã chốt, lý do kỹ thuật đứng sau từng quyết định, và những vấn đề còn treo. Đọc xong là người sau tiếp quản công việc được ngay, khỏi phải lội lại từng dòng dữ liệu cũ.

So sánh nén ngữ cảnh và cắt bỏ: nén giữ lại ràng buộc và trạng thái, cắt bỏ xoá cơ học phần đầu chuỗi

Sự khác biệt cốt lõi giữa nén (compaction) và cắt bỏ (truncation) nằm ở tính bảo toàn ý nghĩa. Cắt bỏ là hành động cơ học: hệ thống chỉ đơn giản là xóa các token ở đầu chuỗi khi vượt giới hạn, và nó thường thổi bay cả các ràng buộc hệ thống hoặc chỉ dẫn quan trọng (system instructions) bạn đã thiết lập từ đầu phiên. Trong khi đó, nén là quá trình chọn lọc dựa trên ngữ nghĩa, nên các thực thể và trạng thái quan trọng vẫn tồn tại trong cửa sổ ngữ cảnh.

Trong kiến trúc tác nhân (agent), nén ngữ cảnh chính là thứ giữ cho "bộ nhớ làm việc" (working memory) còn dùng được. Nó dọn khỏi ngữ cảnh những kết quả công cụ (tool outputs) cồng kềnh đã được xử lý xong, để mô hình dồn toàn bộ sự chú ý (attention) vào các ràng buộc hiện tại (active constraints) và trạng thái mới nhất của nhiệm vụ đang thực hiện.

Vì sao ngữ cảnh dài trở thành vấn đề kỹ thuật?

Khi ngữ cảnh quá dài, hệ thống sẽ gặp hiện tượng mục nát ngữ cảnh (context rot). Dữ liệu thực tế cho thấy độ chính xác của mô hình giảm mạnh từ khoảng 75% xuống còn khoảng 45% khi thông tin quan trọng nằm ở giữa cửa sổ ngữ cảnh (lost-in-the-middle). Việc nhồi nhét quá nhiều dữ liệu không khiến mô hình thông minh hơn mà ngược lại, làm loãng khả năng truy xuất thông tin. Đây là điều phản trực giác nhất với người mới bắt tay vào làm tác nhân: thêm ngữ cảnh vào có thể khiến câu trả lời tệ đi.

Ba cái giá của ngữ cảnh dài: độ chính xác giảm, độ trễ tăng và hoá đơn token leo thang

Vấn đề nghiêm trọng tiếp theo là độ trễ (latency). Với kiến trúc Transformer (nền tảng của các mô hình ngôn ngữ hiện nay), mọi token trong ngữ cảnh đều phải được xử lý lại trên mỗi lượt gọi. Thời gian phản hồi đầu tiên (time to first token) nằm ở mức khoảng 22 giây khi ngữ cảnh dưới 100.000 token, nhưng tăng lên khoảng 76 giây khi vượt ngưỡng 800.000 token. Với các hệ thống AI chạy production, đó là mức độ trễ không ai chấp nhận nổi: nó phá hỏng trải nghiệm người dùng và kéo chậm cả vòng lặp tự động của tác nhân.

Cuối cùng là bài toán kinh tế token (token economics). Cửa sổ ngữ cảnh lớn không đảm bảo mô hình sẽ sử dụng thông tin hiệu quả, nhưng chắc chắn nó ngốn tiền và khiến hóa đơn API của bạn tăng vọt, vì mỗi lượt gọi đều tính phí cho toàn bộ phần lịch sử bạn mang theo. Nén là cách để tìm ra tập hợp token có mật độ thông tin cao nhất với chi phí thấp nhất, thay vì trả tiền đều đặn cho những dữ liệu thô lặp lại chẳng ai đọc tới.

Nén ngữ cảnh hoạt động như thế nào?

Cơ chế nén hiện đại thường được triển khai phía máy chủ (server-side), nghĩa là bạn không phải tự viết lấy vòng lặp tóm tắt cho riêng mình. Khi số lượng token đầu vào (input tokens) đạt ngưỡng kích hoạt (trigger threshold) do bạn cấu hình, hệ thống sẽ tự động thực hiện quy trình nén.

Bốn bước của quy trình nén phía máy chủ: phát hiện ngưỡng, tóm tắt, tạo khối nén và phản hồi

Quy trình kỹ thuật diễn ra theo bốn bước:

Phát hiện: Hệ thống giám sát số lượng token đầu vào chạm ngưỡng (mặc định là 150.000 token).
Tóm tắt: Mô hình tự tạo bản tóm tắt nội dung hội thoại và trạng thái nhiệm vụ hiện tại.
Tạo khối nén: Hệ thống tạo một "khối nén" (compaction block) chứa nội dung tóm tắt này.
Phản hồi: API trả về khối nén ở ngay đầu phản hồi của trợ lý, sau đó tiếp tục hội thoại với ngữ cảnh đã rút gọn.

Một chi tiết rất dễ quên khi triển khai: trong các yêu cầu tiếp theo, chính bạn phải đính kèm khối nén này vào lịch sử tin nhắn. Khi đã có nó, API sẽ tự động bỏ qua các khối nội dung cũ nằm phía trước khối nén, nhờ vậy tải xử lý giảm xuống và tài nguyên cho các lượt gọi sau được dùng gọn hơn.

Các chiến lược nén ngữ cảnh phổ biến

Chiến lược đơn giản nhất là cửa sổ trượt (sliding windows): bạn giữ lại N lượt hội thoại cuối cùng và loại bỏ các lượt cũ đi. Cách này rẻ và nhanh, nhưng nó hỏng theo đúng cái kiểu khó chịu nhất, vì mô hình sẽ dính lỗi "mất trí nhớ kỹ thuật số" (digital amnesia) và quên sạch các chỉ dẫn quan trọng ở đầu phiên nếu chúng trượt ra ngoài cửa sổ.

Ba chiến lược nén ngữ cảnh: cửa sổ trượt, tóm tắt đệ quy và đẩy kết quả công cụ ra ngoài

Tóm tắt đệ quy (recursive summarization) tinh vi hơn một bậc: hệ thống định kỳ tóm tắt lịch sử để giữ lại "cốt truyện" chính. Tuy nhiên, mỗi lần nén chồng lên một bản vốn đã nén, các chi tiết kỹ thuật tinh vi (fine details) lại rụng thêm một ít, y như khi bạn sao chép đi sao chép lại cùng một tệp tin nén.

Chiến lược thứ ba, và theo tôi là chiến lược đáng làm trước tiên, là đẩy kết quả công cụ ra ngoài (tool output offloading). Thay vì giữ toàn bộ kết quả thô, hệ thống ghi dữ liệu này vào bộ nhớ ngoài và chỉ để lại một "con trỏ" (pointer) hoặc bản xem trước ngắn trong ngữ cảnh. Khi cần thông tin chi tiết, tác nhân sẽ sử dụng công cụ để truy xuất lại đúng phần dữ liệu đó, chứ không phải vác cả đống dữ liệu thô theo suốt phiên làm việc.

Nén hoàn nguyên được và nén mất mát

Trong thiết kế hệ thống, bạn nên ưu tiên nén hoàn nguyên được (reversible compaction). Đây là quá trình gỡ thông tin ra khỏi ngữ cảnh nhưng vẫn lưu trữ chúng ở cơ sở dữ liệu vector (vector database) hoặc hệ thống file, để tác nhân có thể "nhớ" lại thông tin thông qua việc truy xuất (retrieval) khi cần. Các kỹ thuật như masking (ẩn dữ liệu) hoặc pruning (cắt tỉa) nên được dùng cạn trước khi bạn nghĩ đến việc xóa vĩnh viễn.

Nén hoàn nguyên được so với nén mất mát: dữ liệu vẫn truy xuất lại được hay bị phá huỷ vĩnh viễn

Nén mất mát (lossy summarization) là phương án cuối cùng, nơi thông tin bị phá hủy vĩnh viễn và chỉ giữ lại ý chính. Nó giống như chuẩn nén JPEG: dung lượng giảm mạnh, nhưng độ sắc nét của dữ liệu chi tiết sẽ biến mất sạch, và không có nút hoàn tác nào cả. Chỉ sử dụng nén mất mát khi cửa sổ thực sự đầy hoặc khi chi phí token đã vượt quá giới hạn ngân sách cho phép.

Trong thực tế, tôi thấy hợp lý nhất là một chiến lược nén đa tầng: nén hoàn nguyên cho các dữ liệu thô từ công cụ, còn nén mất mát chỉ để dành cho lịch sử hội thoại, và chỉ khi không còn lựa chọn nào khác.

Nén, cửa sổ ngữ cảnh lớn hơn và RAG

Đừng lầm tưởng cửa sổ ngữ cảnh lớn (như 1 triệu token) sẽ thay thế được nén. Cửa sổ lớn chỉ tăng trần công suất, nhưng đổi lại nó kéo theo rủi ro về độ trễ và nhiễu thông tin. Nén vẫn cần thiết để điều tiết trạng thái phiên (session state), nhờ đó tác nhân luôn sắc bén.

Kiến trúc phân tầng: RAG cho kiến thức ngoài, cửa sổ lớn cho công suất và nén cho trạng thái phiên

So với RAG (Retrieval-Augmented Generation), nén xử lý một phạm vi khác hẳn. RAG giải quyết kiến thức bên ngoài (external knowledge), trong khi nén quản lý bộ nhớ làm việc (working memory) đang tiến triển của chính tác nhân. Bạn dùng RAG để tìm ra thông tin, và dùng nén để bản ghi của những lần tìm kiếm đó không nhấn chìm khả năng suy luận của mô hình trên kết quả. Nếu bạn đang cân nhắc chọn giữa ba hướng nhồi hết, truy hồi hay nén cho một tải cụ thể, phần so sánh nằm ở bài xử lý ngữ cảnh dài.

Kiến trúc tối ưu là một hệ thống phân tầng: RAG để truy xuất kiến thức, cửa sổ ngữ cảnh lớn để làm công suất dự phòng, và nén để giữ cho trạng thái hội thoại luôn gọn gàng và tiết kiệm chi phí.

Nén sai chỗ thì hỏng những gì?

Nén quá tay là một trong những kiểu lỗi ngữ cảnh khó phát hiện nhất. Rủi ro lớn nhất là các lỗi "vô hình" (invisible failures), và chúng vô hình theo đúng nghĩa đen. Khi nén quá đà, mô hình vẫn trả lời rất trôi chảy và vẫn tự tin y như thường, nhưng thực tế đã quên mất các ràng buộc quan trọng (constraints) đã thống nhất trước đó. Thử nghiệm bằng các bài kiểm tra trí nhớ (memory probes) cho thấy tỷ lệ ghi nhớ thực tế có thể giảm xuống còn 58% sau khi nén, mặc dù điểm chất lượng câu trả lời vẫn đạt 97–99%. Nói cách khác, thứ hỏng trước là trí nhớ, còn giọng văn thì vẫn nguyên vẹn để che đi chuyện đó.

Lỗi vô hình khi nén quá tay: điểm chất lượng câu trả lời vẫn cao trong khi tỷ lệ ghi nhớ sụt xuống

Đặc biệt, trên các dòng mô hình như Claude Fable 5.1 và Claude Mythos 5.1, các khối suy nghĩ (thinking blocks) sẽ không được mang theo sau khi nén. Điều này có nghĩa là mô hình sẽ mất đi toàn bộ quá trình lập luận trước đó và chỉ còn lại bản tóm tắt để bám vào. Nếu bản tóm tắt thiếu sót, mô hình sẽ tự "điền vào chỗ trống", và đó chính là lúc hiện tượng ảo giác (hallucination) xuất hiện.

Cảm giác của bạn khi ngồi chat thử vài lượt không nói lên được điều gì, bởi một phiên ngắn hiếm khi chạm tới ngưỡng kích hoạt nén. Bạn phải thiết lập các bài thử nghiệm (evals) thực tế: cài cắm các sự thật cụ thể ở đầu phiên, chạy cho ngữ cảnh dài ra, rồi kiểm tra xem tác nhân có còn nhớ chúng sau khi bộ nén kích hoạt hay không.

Khi nào nên kích hoạt việc nén?

Với Claude API, ngưỡng tối thiểu để kích hoạt nén phía máy chủ là 50.000 token. Bạn nên kích hoạt nén khi luồng làm việc của tác nhân bắt đầu ngốn quá nhiều token cho các tác vụ lặp lại hoặc cho các kết quả trung gian từ công cụ.

Để tối ưu, hãy sử dụng tham số instructions để ép mô hình phải giữ lại các đoạn mã (code snippets), tên biến hoặc các quyết định kiến trúc then chốt, thay vì để bản tóm tắt mặc định tự quyết cái gì đáng giữ. Còn đây là mẹo kiến trúc tôi thấy ít người chịu làm: hãy đặt một điểm dừng bộ đệm (cache breakpoint) ở ngay cuối prompt hệ thống (system prompt). Điều này đảm bảo prompt hệ thống luôn được cache riêng biệt, giúp tối đa hóa tỷ lệ khớp cache (cache hit rate) ngay cả khi phần tiền tố hội thoại thay đổi do nén.

Một cái bẫy nữa nằm ở hóa đơn: số lượng input_tokens và output_tokens hiển thị ở cấp cao nhất trong báo cáo sử dụng API không bao gồm các token tiêu tốn cho quá trình nén. Muốn biết chính xác chi phí thực tế đã bị tính phí, bạn phải cộng tổng các giá trị trong mảng usage.iterations.

Khi nào nén ngữ cảnh không đáng

Nén ngữ cảnh đôi khi lại là một sai lầm về kinh tế token, và lý do nằm ở cache. Bộ nhớ đệm prompt (prompt caching) chỉ hoạt động khi tiền tố (prefix) của ngữ cảnh không đổi. Khi bạn nén hoặc tóm tắt, bạn làm thay đổi đúng cái tiền tố đó, nên cache mất hiệu lực và bạn phải trả toàn bộ giá cho lượt gọi tiếp theo. Nén chỉ thực sự đáng giá nếu chi phí token được cache vượt ngưỡng 0,55 USD/triệu token. Với các mô hình có giá cache cực rẻ như DeepSeek — nơi mức giá giảm khoảng 50 lần, từ 0,14 USD xuống còn 0,0028 USD mỗi triệu token — việc giữ lại toàn bộ lịch sử thường vừa rẻ hơn vừa chính xác hơn nhiều so với việc nén.

Đừng nén theo mặc định. Trước khi bật nó lên, hãy xác định rõ ràng hệ thống của bạn đang bị nghẽn ở đâu: là giới hạn vật lý của cửa sổ, là hóa đơn token cuối tháng, hay là sự suy giảm chất lượng câu trả lời. Ba chỗ nghẽn đó cần ba cách chữa khác nhau, và chỉ một trong ba cách ấy mang tên nén.