/compact là gì? Chống context rot (thối rữa ngữ cảnh) - Claude Code

Thay vì để hệ thống tự ý cắt bỏ dữ liệu khi chạm trần bộ nhớ, lệnh này trao quyền kiểm soát cho bạn: chọn thời điểm nén, và chọn thứ cần giữ lại.

Vấn đề mà /compact trực tiếp xử lý chính là context rot (sự thối rữa ngữ cảnh) — hiện tượng chất lượng phản hồi suy giảm nghiêm trọng khi cửa sổ ngữ cảnh (context window) đầy dần. Bạn sẽ nhận thấy Claude bắt đầu quên các quyết định kiến trúc đã thống nhất trước đó, nhầm lẫn logic xử lý, hoặc đề xuất code mâu thuẫn trực tiếp với các pattern đã thiết lập. Khi "nhiễu" (noise) từ log lỗi và output dư thừa tích tụ, "tín hiệu" (signal) quan trọng bị loãng và biến mất khỏi sự chú ý của mô hình.

Nén ngữ cảnh giúp Claude Code quay lại trạng thái "sạch", giảm gánh nặng tính toán trên mỗi lượt tương tác. Nhưng nếu không biết cách điều khiển quá trình này, bạn sẽ đối mặt với rủi ro mất mát thông tin kỹ thuật tinh vi. Là một kỹ sư, bạn cần hiểu cơ chế nén để giữ cho "cộng sự" AI của mình luôn ở trạng thái tỉnh táo nhất.

"Context rot" là gì và vì sao ngữ cảnh càng dài mô hình càng kém?

Context rot không phải một lỗi lập trình, mà là một giới hạn cố hữu của các mô hình ngôn ngữ lớn (LLM). Khi một phiên kéo dài, Claude bắt đầu xuất hiện những triệu chứng "mệt mỏi kỹ thuật": nó hỏi lại những câu bạn đã trả lời, quên cấu trúc thư mục vừa refactor, hoặc đưa ra các đoạn code phá vỡ pattern logic đã dày công xây dựng.

Nguyên nhân nằm ở cách mô hình xử lý sự chú ý (attention). Hiệu suất của LLM thường đi theo đường cong chữ U (lost-in-the-middle): nó ghi nhớ tốt thông tin ở đầu và cuối ngữ cảnh, nhưng lơ đãng với thông tin ở giữa. Theo dữ liệu từ OpenAI và Chroma, độ chính xác có thể giảm từ 84% xuống chỉ còn khoảng 50% khi cửa sổ ngữ cảnh tiến gần mốc 1M token. Các dòng mô hình Claude suy giảm chậm hơn, nhưng không hề miễn nhiễm.

Trong quá trình làm việc, cửa sổ ngữ cảnh tích tụ hàng ngàn token từ log lỗi terminal, output của công cụ, các nỗ lực thử nghiệm thất bại và những đoạn hội thoại chắp nối. Tất cả tạo thành "nhiễu". Khi nhiễu chiếm ưu thế, các chỉ dẫn quan trọng ban đầu bị đẩy vào "vùng mù" của mô hình, dẫn đến việc Claude ra quyết định thiếu nhất quán và sai sót tăng dần theo số lượng tin nhắn.

Lệnh /compact thực chất làm gì với cuộc hội thoại?

Khi bạn chạy /compact, Claude đọc lại toàn bộ lịch sử hội thoại từ đầu phiên và tạo ra một khối tóm tắt (<summary>) duy nhất. Khối này sau đó thay thế toàn bộ các tin nhắn cũ trong lịch sử.

Kết quả là payload gửi lên API giảm trung bình khoảng 85%. Một phiên đang nặng nề với khoảng 167K token có thể được thu gọn xuống còn khoảng 25K token. Toàn bộ không gian trống được giải phóng trở thành vùng nhớ ngắn hạn mới cho các logic phức tạp tiếp theo.

Điểm khác biệt quan trọng giữa việc bạn tự chạy /compact và để hệ thống tự động nén (auto-compact) nằm ở quyền kiểm soát. Khi chủ động nén, bạn có thể đưa ra "chính sách giữ lại dữ liệu" (retention policy). Ngược lại, khi hệ thống tự kích hoạt vì tràn bộ nhớ, nó tóm tắt một cách "mù quáng", thường ưu tiên các tin nhắn gần nhất và bỏ qua những ràng buộc kiến trúc quan trọng được thiết lập ở đầu phiên.

Khi nào Claude nén: tự động (~83%) và chủ động nén sớm (~60%)?

Mặc định, Claude Code tự động nén khi ngưỡng sử dụng đạt khoảng 83.5% (tương đương 167K/200K token). Nhưng nếu đợi đến ngưỡng này, bạn đã rơi vào "vùng tối" của hiệu suất. Tại 83%, khả năng suy luận của Claude đã bắt đầu suy giảm do áp lực ngữ cảnh, nên bản tóm tắt nó tự tạo ra có thể thiếu sót hoặc sai lệch thông tin quan trọng.

Hãy áp dụng "quy tắc 60%". Tại mốc này, Claude vẫn còn đủ sắc bén để quan sát lại toàn bộ quá trình làm việc và tạo ra bản tóm tắt chính xác nhất. Để quản lý, bạn nên phân chia trạng thái phiên theo các mốc:

• Xanh (0–30%): phiên còn mới, cứ để nó hoạt động tự nhiên.
• Vàng (30–50%): bắt đầu quan sát các điểm dừng nhiệm vụ (task boundary).
• Cam (50–60%): ngưỡng lý tưởng để chạy /compact. Dừng việc bắt đầu feature mới để chuẩn bị nén.
• Đỏ (>60%): vùng nguy hiểm. Đừng bắt đầu bất kỳ đợt refactor phức tạp nào nếu chưa nén.

Nếu bạn dùng model với cửa sổ 1M token, con số phần trăm cần được nhìn lại: 20% của 1 triệu đã là 200K token — đủ để làm loãng mọi logic tinh vi. Đừng để con số 1 triệu đánh lừa; mật độ tín hiệu quan trọng hơn tổng dung lượng.

Nén làm mất những gì — và bẫy "nén dồn" (tóm tắt của tóm tắt)?

Nén là một quá trình "lossy" (có mất mát). Những chi tiết kỹ thuật siêu nhỏ thường là nạn nhân đầu tiên: các thông số chính xác như timeout (30s), kích thước payload tối đa (512KB), hay tên biến cụ thể trong các module phụ. Claude thay thế chúng bằng những cụm từ chung chung như "đã thảo luận về các ràng buộc API".

Rủi ro lớn nhất là "cascading compression" (nén dồn). Nếu bạn nén một phiên lần thứ hai hay thứ ba, Claude thực hiện tóm tắt trên một bản tóm tắt cũ. Thông tin mờ nhạt dần theo lũy kế, giống như photocopy một bản photocopy nhiều lần. Sau vài lần nén dồn, Claude vẫn biết bạn đang làm dự án gì, nhưng những nguyên tắc ngầm định có thể biến mất hoàn toàn.

Ngoài ra, hãy cẩn trọng với các file cấu hình. Có một lỗi hệ thống khiến việc nén đôi khi không bảo toàn tốt nội dung project-context.md hoặc các file CLAUDE.md nằm ở thư mục con (nested). Sau khi nén, các path-scoped rule (quy tắc theo đường dẫn) thường biến mất cho đến khi file đó được đọc lại.