Context là pipeline, không phải cửa sổ: dữ liệu tool bị hao hụt trên đường tới model

“LLM agents are judged by two numbers: the size of the context window, and how often the final answer is correct.”

Yuvraj Sehgal, Mahsa Panahandeh, Naser Ezzati-Jivan · 3 tác giả · Brock University and University of Ottawa · 2026 · arXiv:2610.36114

Đo agent bằng cửa sổ context, bạn đang bỏ sót phần output bị cắt

Mở

Nhiều đội đo agent bằng hai con số: cửa sổ context bao lớn, và câu trả lời cuối cùng có đúng không. Hai con số đó bỏ qua một thứ: bao nhiêu phần output của tool bị cắt trước khi model kịp nhìn thấy. Paper này đo thẳng phần bị mất đó trên một agent dùng tool thật, và phần mất lớn hơn nhiều người lường.

Paper này làm gì

Tác giả quan sát một agent chẩn đoán lỗi bằng cách đọc trace của Linux kernel, và đo được rằng qua 720 lần chạy, prompt lớn nhất chỉ dùng 5.75% cửa sổ context. Nhưng tới một phần ba kết quả tool bị cắt trước khi tới model, mọi kết quả bị cắt đều thành JSON hỏng, và nguyên nhân là harness cắt bằng cách chém chuỗi JSON ở độ dài cố định, cách này xoá dữ liệu nằm gần cuối thay vì cắt đều lên mọi phần. Chênh lệch giữa các field cũng rất lớn: một field tới model chỉ ở 4.7% số lượt gọi, trong khi một field thứ hai ngay trong cùng kết quả lại tới model ở 99.3% số lượt gọi, và chẩn đoán của agent lệch đúng theo ranh giới đó. Tác giả dựng pipeline với năm giai đoạn cho context của agent, tái chạy 864 kết quả tool thật, chạy thí nghiệm kiểm soát để tách nguyên nhân, rồi khảo sát bảy agent framework và thấy hai framework cắt output tool theo cách không an toàn tương tự.

Phát hiện chính

  1. Hai con số quen thuộc bỏ qua mức output của tool bị mất trước khi model nhìn thấy. (Both numbers miss a third thing: how much of a tool’s output is lost before the model ever sees it)

  2. Ở 720 lần chạy, prompt lớn nhất chỉ dùng 5.75% cửa sổ context, nhưng một phần ba kết quả tool bị cắt trước khi model nhìn thấy, và mọi kết quả bị cắt đều thành JSON hỏng. (Yet a third of all tool results (3,827 of 11,189) were cut before they reached the model, and every cut result became broken JSON)

  3. Thí nghiệm kiểm soát cho thấy cái cắt dữ liệu hiện ra trước tiên như công việc thừa chứ không phải câu trả lời sai: nhiều hơn 43% số lần gọi tool, hai lần lượng tính toán, và yield giảm từ 0.61 xuống 0.31. (43% more tool calls, twice the computation, and yield falling from 0.61 to 0.31)

Caveat

Hạn chế tác giả nêu rõ: liệu việc mất dữ liệu có thật sự gây ra phần giảm độ chính xác vẫn là câu hỏi mở. Paper chứng minh được cái cắt gây ra công việc thừa và làm mất yield, nhưng chưa đóng được chuỗi nhân quả dẫn tới câu trả lời sai, nên phần đó phải đọc như giả thuyết chưa kiểm chứng xong.

Áp vào 5ac thế nào

Đây là lý do Gbrain nên trả kết quả theo từng đoạn và Hermes cắt tool output theo ranh giới JSON thay vì theo độ dài byte: bản cut trong paper kể trên xoá hết 128 record chứa chứng cứ lỗi chỉ vì chúng nằm ở cuối. Với stack self-hosted, việc cần làm là đối chiếu số record tool trả về với số record thực sự đi vào prompt, thay vì chỉ xem cửa sổ context còn bao nhiêu. Cron quét định kỳ có thể làm phép đối chiếu đó mỗi ngày và báo khi khoảng hụt vượt ngưỡng cho phép. Khi một skill mới thêm tool trả output dài, gate trước khi cho chạy thật nên kiểm luôn cách tool đó bị cắt.

Nguồn