Cửa sổ ngữ cảnh không biết điều gì vẫn còn đúng — Tôi đã xây một lớp kiểm tra tính hợp lệ

Agent AI có thể nhớ mọi thứ, nhưng không phân biệt được đâu là thông tin đã "chết". Một benchmark thuần Python với hai bộ thực thi quyết định đã chỉ ra rằng, việc kiểm tra tính hợp lệ của dữ liệu trước khi hành động không chỉ giảm lãng phí tài nguyên, mà còn quyết định thành bại của cả nhiệm vụ khi ngân sách có hạn. Kết quả từ 96 cấu hình thử nghiệm đã phủ nhận giả thuyết ban đầu về cấu trúc đồ thị, thay vào đó, kích thước vùng ảnh hưởng mới là yếu tố then chốt.

Vấn đề cốt lõi rất đơn giản: một cửa sổ ngữ cảnh (context window) chỉ ghi nhớ những gì đã xảy ra, nhưng không biết liệu thông tin đó có còn giá trị tại thời điểm hiện tại hay không. Tác giả đã xây dựng hai bộ thực thi quyết định (deterministic executors) làm cùng một công việc. Một bên kiểm tra xem một phụ thuộc còn hợp lệ trước khi hành động, bên còn lại chỉ phát hiện ra khi hành động thất bại. Sự khác biệt nhỏ đó tạo ra những con số rõ rệt trong kết quả đo lường.

Sự hiện diện khác với tính hợp lệ

Hầu hết các cuộc thảo luận về cửa sổ ngữ cảnh tập trung vào không gian. Mọi người lo lắng về việc có quá nhiều ngữ cảnh, không đủ ngữ cảnh, hoặc tải chúng theo sai thứ tự. Đó là những vấn đề thực tế, nhưng không phải là vấn đề đang được nói đến ở đây. Vấn đề này liên quan đến thời gian.

Cửa sổ ngữ cảnh về cơ bản là một bản ghi chép (transcript). Nó ghi lại những gì đã xảy ra theo thứ tự. Một bản ghi chép cho agent biết về quá khứ. Một lớp kiểm tra tính hợp lệ (validity layer) cho agent biết liệu thông tin đó có còn an toàn để sử dụng ngay bây giờ hay không. Một cửa sổ ngữ cảnh bình thường không thể làm công việc thứ hai. Nó không được thiết kế cho mục đích đó.

Mô hình kiểm tra trạng thái dữ liệu ACTIVE, STALE, SUPERSEDED, UNKNOWN

Để làm rõ vấn đề, tác giả đã gán cho mọi dữ liệu trong benchmark một trong bốn trạng thái thay vì chỉ đơn giản là đúng (true) hoặc sai (false):

• ACTIVE: Bằng chứng hiện tại ủng hộ dữ liệu này.
• STALE: Nó từng đúng, nhưng đã có dữ liệu mới hơn.
• SUPERSEDED: Một quan sát mới hơn đã thay thế hoàn toàn dữ liệu cũ.
• UNKNOWN: Không có đủ bằng chứng để khẳng định theo hướng nào.

Trạng thái thứ tư (UNKNOWN) rất quan trọng. Việc tách biệt UNKNOWN khỏi một lỗi hoàn toàn cho phép bộ thực thi có lựa chọn thứ ba: nó có thể xác minh dữ liệu trước khi hành động hoặc trước khi lập kế hoạch mới. Điều này cho phép benchmark đo lường chi phí thực sự của sự không chắc chắn, thay vì coi mọi nghi ngờ là một thất bại cứng.

Vì sao đây không phải là benchmark LLM?

Mọi benchmark mà tác giả xây dựng đều chạy trên Python thuần túy, không gọi API. Lý do rất quan trọng: nếu dùng một LLM thực sự cho bài kiểm tra này, mọi kết quả sẽ cần một chú thích. Nhiệm vụ thất bại là do việc theo dõi trạng thái (thứ đang được kiểm tra) hay do mô hình suy luận sai? Câu lệnh prompt có hơi lệch không? Nhà cung cấp API có một ngày tồi tệ?

Thí nghiệm này chỉ tập trung theo dõi trạng thái, không kiểm tra chất lượng mô hình. Vì vậy, cơ chế được cô lập hoàn toàn. Hai bộ thực thi quyết định không phải là các agent AI mở, mà chỉ là các cỗ máy trạng thái nhỏ. Chúng nhìn vào dữ liệu và quyết định: tiếp tục, xác minh, hay lập kế hoạch mới.

Bộ thực thi cơ bản (Baseline) chỉ chạy bước tiếp theo trong kế hoạch của nó. Nó không mù quáng, nó cuối cùng sẽ tìm ra mọi phụ thuộc hỏng, nhưng phát hiện ra quá muộn — chính xác là khi hành động vấp phải thế giới thực. Bộ thực thi nhận biết tính hợp lệ (Validity-Aware) kiểm tra trạng thái của một phụ thuộc trước khi chạy một bước. Nếu dữ liệu là ACTIVE, nó thực thi. Nếu là SUPERSEDED, nó lập kế hoạch mới ngay lập tức. Nếu là STALE hoặc UNKNOWN, nó dành một bước để xác minh dữ liệu đó trước khi hành động.

Một thiết kế quan trọng khác: benchmark giữ "sự thật cơ bản" (ground truth) hoàn toàn tách biệt với những gì mỗi bộ thực thi đang tin. Không bộ thực thi nào có thể đọc trực tiếp trạng thái thực của thế giới. Thế giới thực chỉ hiện ra khi một bộ thực thi thực sự hành động hoặc trả phí cho một bước xác minh. Sự tách biệt này giúp benchmark trung thực. Nếu bộ thực thi validity-aware có thể nhìn trộm thực tại, nó sẽ thắng mọi lúc. Nhưng nó không thể, và phải tự tìm hiểu.

Kết quả đo lường cụ thể

Năm chỉ số chính được tập trung, trong đó Pre-Failure Work (PFW) là con số quan trọng nhất. Nó đếm số bước chạy sau khi một phụ thuộc hỏng nhưng trước khi hệ thống phát hiện ra. Đây là công việc "đã chết" — lãng phí tài nguyên tính toán vào một kế hoạch đã hết hạn.

So sánh công việc lãng phí giữa Baseline và Validity-Aware Executor

Thí nghiệm 1: Dữ liệu lỗi thời có thực sự gây lãng phí?

Ở một chuỗi bốn bước cơ bản, khi một dữ liệu then chốt thay đổi giá trị chỉ sau một bước: Baseline sử dụng 9 bước, trong khi Validity-Aware chỉ dùng 6. Baseline chạy thêm hai bước trên một kế hoạch đã chết trước khi thất bại ập đến. Điều quan trọng nhất: Validity-Aware không thực hiện bất kỳ công việc "đã chết" nào, trong khi Baseline lãng phí 2 bước. Việc loại bỏ công việc vô ích được tích hợp sẵn trong cơ chế.

Thí nghiệm 2: Kích thước tổn thất, góc nhìn cấu trúc

Tác giả đã phủ nhận giả thuyết ban đầu của mình rằng hình dạng đồ thị (chain, tree, branching) là yếu tố thúc đẩy chi phí lãng phí. Một cuộc khảo sát với 96 cấu hình khác nhau về độ sâu, hệ số nhánh và hệ số hợp nhất cho thấy mọi cấu hình đều tuân theo một công thức duy nhất: Baseline PFW = tổng số nút bị ảnh hưởng - 1. Không có ngoại lệ nào trong số 96 lần chạy.

Trong bộ dữ liệu này, kích thước vùng ảnh hưởng (size) quyết định chi phí, không phải hình dạng (shape). Điều này dẫn đến thí nghiệm thứ ba: liệu có thể cô lập các nhánh để thu nhỏ "bán kính nổ" của một dữ liệu hỏng? Khi tách kế hoạch thành 8 nhánh độc lập, một sự thay đổi dữ liệu chỉ ảnh hưởng 16% kế hoạch thay vì 100%, và chi phí lãng phí giảm từ 49 bước xuống còn 7 bước cố định.

Đồ thị thể hiện mối quan hệ giữa kích thước kế hoạch và số bước lãng phí

Thí nghiệm 4: Khi ngân sách eo hẹp — thất bại hay thành công?

Để chứng minh sự khác biệt không chỉ là vấn đề hiệu quả mà còn là vấn đề sống còn, tác giả đã quét ngân sách bước từ rộng rãi đến chặt chẽ. Kết quả rất rõ ràng:

• Với ngân sách 9 bước: cả hai đều hoàn thành.
• Với ngân sách 6, 7, 8 bước: Baseline thất bại, nhưng Validity-Aware vẫn hoàn thành.
• Với ngân sách 4, 5 bước: cả hai đều thất bại.

Baseline cần trả phí cho hành động lãng phí trước khi nhận ra vấn đề, sau đó lại phải trả phí để phục hồi. Trong khi đó, Validity-Aware không bao giờ làm công việc vô ích, nên có đủ không gian để hoàn thành nhiệm vụ ngay cả khi ngân sách bị cắt giảm. Khi có giới hạn cứng về số lần gọi công cụ, token hay thời gian, một vài bước không cần thiết có thể khiến một nhiệm vụ vốn có thể giải quyết được trở nên thất bại.

Kiểm tra có phải lúc nào cũng đáng giá?

Một thí nghiệm quan trọng khác cho thấy việc kiểm tra tính hợp lệ không phải lúc nào cũng miễn phí. Tác giả đã tạo một trường hợp tín hiệu mơ hồ khiến dữ liệu có vẻ như đã thay đổi nhưng thực tế không phải vậy (false alarm):

• Khi dữ liệu thực sự thay đổi (E1): Baseline mất 7 bước, Validity-Aware mất 6 bước (gồm 1 bước xác minh). Kiểm tra thanh toán cho chính nó.
• Khi có tín hiệu giả (E2): Baseline chỉ mất 3 bước, nhưng Validity-Aware mất 4 bước (gồm 1 bước xác minh). Kiểm tra trở thành chi phí thuần túy.

Thông điệp chính: kiểm tra độ tươi mới của dữ liệu không bao giờ là miễn phí. Câu hỏi kỹ thuật thực sự không phải là "bạn có nên kiểm tra không?", mà là "chi phí kỳ vọng của việc hành động trên dữ liệu lỗi thời có lớn hơn chi phí kiểm tra không?". Câu trả lời phụ thuộc hoàn toàn vào lĩnh vực ứng dụng, không phải vào cơ chế.

Khi nào nên áp dụng điều này?

Việc theo dõi tính hợp lệ không phải là miễn phí, vì vậy bạn nên dùng nó khi:

• Các bước trong kế hoạch đa chặng có chi phí thực sự như gọi công cụ, chi phí API hoặc các tác dụng phụ khó đảo ngược.
• Phiên làm việc kéo dài — khi vài phút hoặc vài giờ trôi qua giữa lúc học một dữ liệu và sử dụng nó.
• Có giới hạn cứng về tài nguyên như token hoặc độ trễ, nơi các bước lãng phí không chỉ làm chậm mà còn khiến cả nhiệm vụ thất bại.

Ngược lại, hãy bỏ qua nó cho các truy vấn một lần, nơi dữ liệu không có thời gian để lỗi thời. Bỏ qua nếu các hành động rẻ và dễ thử lại. Nếu thất bại không tốn kém, thì việc phát hiện muộn cũng không tốn kém. Bỏ qua cho các tác vụ tĩnh khi dữ liệu không bao giờ thay đổi.

Kết luận

Mỗi con số trong bài viết này quay trở lại một ý tưởng đơn giản: ngữ cảnh có lịch sử, nhưng agent cần trạng thái. Một bản ghi chép cho bạn biết điều gì đã xảy ra. Nó thường là một bản ghi chép tuyệt vời — không gì bị mất, không gì bị cắt ngắn, mọi dữ liệu đều ở đúng vị trí. Nhưng đưa ra quyết định đòi hỏi trả lời một câu hỏi hoàn toàn khác: điều gì vẫn còn đúng ngay bây giờ? Một cửa sổ ngữ cảnh không có cơ chế nào để trả lời câu hỏi đó. Nó không bao giờ được thiết kế cho việc đó.

Đó không phải là lời chỉ trích cửa sổ ngữ cảnh. Chúng làm chính xác những gì chúng được tạo ra: giữ mọi thứ đã xảy ra, theo thứ tự, để không gì bị rơi mất. Khoảng trống không nằm ở những gì chúng lưu trữ, mà ở việc liệu hệ thống có theo dõi tính hợp lệ của những gì nó lưu trữ khi thế giới thay đổi. Vấn đề của các AI agent không chỉ là hết ngữ cảnh. Đôi khi lỗi tinh vi hơn lại là điều ngược lại: chúng nhớ một điều gì đó hoàn hảo, rất lâu sau khi điều đó không còn đúng nữa, và không gì trong bản ghi chép bảo chúng ngừng tin tưởng nó.

Thêm ngữ cảnh không giải quyết được điều đó. Một cửa sổ lớn hơn chỉ cho một dữ liệu lỗi thời thêm nhiều bạn đồng hành. Điều thực sự hữu ích là một ý tưởng hệ thống cũ: vô hiệu hóa trạng thái khi nó không còn an toàn để sử dụng, và phát hiện điều đó trước khi hành động thay vì sau khi thất bại.

Toàn bộ mã nguồn, benchmark, các kịch bản và script tái tạo số liệu có thể tìm thấy tại: https://github.com/Emmimal/context-validity-benchmark/