Trạng thái, không phải lịch sử: ngày năm paper cùng chỉ vào một chỗ hỏng

Vì sao "nối lịch sử" là lỗi cấu trúc chứ không phải lỗi tinh chỉnh

Cách agent hiện tại giữ trí nhớ gần như luôn là: hội thoại là bộ nhớ. Mỗi bước, bạn nối observation + action + reasoning vào cuối. Điều này có một hệ quả toán học ít ai nói ra: prompt ở bước t dài cỡ t, nên tổng token bạn trả tiền trên cả run là O(T²). Chạy 200 bước không đắt gấp đôi chạy 100 bước — nó đắt gấp bốn.

Nhưng chi phí chưa phải phần tệ nhất. Phần tệ hơn là nhiễu tích lũy: mọi ngã rẽ sai, mọi suy luận đã bị bác bỏ, mọi quan sát cũ nay đã lỗi thời — tất cả vẫn nằm nguyên trong context và vẫn tranh giành sự chú ý với sự thật hiện tại. Đây chính là "context poisoning" mà ai chạy agent dài cũng gặp.

Cơ chế, từng bước

Ở mỗi bước, model nhận bộ ba A_t = (P, Σ_t, O_t): P là spec quy trình bất biến (không bao giờ đổi), Σ_t là state JSON hiện tại, O_t là quan sát mới nhất. Model sinh ra ba thứ: chuỗi suy luận R_t, một state patch ΔΣ_t, và hành động a_t. Trạng thái cập nhật bằng merge dictionary: Σ_(t+1) = Σ_t ⊕ ΔΣ_t, trong đó giá trị null nghĩa là xóa key.

Điểm thiết kế sắc nhất nằm ở chữ R_t: suy luận bị vứt bỏ có chủ đích, ngay khi nó đã sinh ra một cập nhật trạng thái hợp lệ. Model được phép nghĩ dài, nhưng không được phép lưu lời nghĩ. Nếu một kết luận quan trọng, nó phải được viết vào state — không thì nó biến mất. Ràng buộc này ép model chưng cất, thay vì tích trữ.

Số liệu đáng nhớ

Bảng cuối là bảng thuyết phục nhất và dễ bị bỏ qua nhất. Nó trả lời đúng câu phản biện hiển nhiên: "thì chỉ là nén context thôi mà". Không phải. Khi ép mọi phương pháp về cùng ngân sách 1.800 token, các cách nén thống kê sập xuống 0.18–0.52, còn state có cấu trúc giữ 0.94. Khác biệt không nằm ở số token — nằm ở chỗ nén thống kê phá vỡ quan hệ phụ thuộc, còn state thì giữ được chúng.

Hạn chế tác giả tự nhận

Giả định lớn nhất là state phải là thống kê đủ (sufficient statistic): mọi thứ cần cho hành động tương lai phải bắt được vào state ngay lúc biết. Cách này gãy khi (a) schema phải khám phá dần trong lúc chạy, (b) một quan sát cũ hóa ra quan trọng nhưng lúc đó không nhận ra, (c) chính nhiệm vụ đòi hỏi lịch sử — audit, truy vết nguồn gốc. Ngoài ra mới chỉ làm single-agent; nhiều agent ghi đồng thời cần ngữ nghĩa giải quyết xung đột. Với model open-weight nhỏ (Gemma-4-31B), 68% lỗi là "ghi đè state quá sớm" — model quên chép lại key cũ khi merge; tác giả khuyến nghị decoding ràng buộc theo grammar.

Cái insight, nói cho thật đơn giản

Hình dung bạn phải đọc một tập hồ sơ 200 trang rồi trả lời một câu hỏi. Nếu bạn đọc xong mới biết câu hỏi hỏi gì, bạn đã đọc 200 trang đó mà không biết cần chú ý cái gì. Biết câu hỏi trước khi đọc thì bạn đọc khác hẳn — dù lượng chữ y hệt.

Transformer nhân quả bị đúng vấn đề này ở cấp cơ chế. Biểu diễn của token thứ 50.000 được tính từ những gì đứng trước nó. Khi model suy luận ra "à, cái mình cần theo dõi là quan hệ cha-con trong đồ thị này", nó đã tính xong biểu diễn cho toàn bộ context rồi. Trace nối phía sau thì đọc được, nhưng nó không thể sửa lại cách phần context phía trước đã được mã hóa. Đưa trace lên trước là để trace điều kiện hóa chính quá trình mã hóa đó.

Số liệu đáng nhớ

Chú ý cột giữa: trace append cũng cải thiện so với lượt một (29,2 → 43,0). Tức là chỉ riêng việc có trace đã có ích. Nhưng nhảy lớn thực sự nằm ở bước từ append sang đặt-trước (43,0 → 81,8) — gần gấp đôi khoảng cải thiện, mà không thêm một token thông tin nào.

Hạn chế

Không miễn phí: cần thêm một lượt inference, nên tăng độ trễ và chi phí token. Nó cũng phá KV-cache reuse trong hội thoại nhiều lượt — vì bạn đang chèn nội dung mới vào đầu prompt, mọi thứ phía sau phải tính lại. Cần truy cập được raw reasoning trace, nên với API chỉ trả đáp án cuối thì không dùng trực tiếp được. Đánh giá gói gọn trong 3 model và 3 họ task, và chưa đụng tới agent nhiều lượt — tức là đúng chỗ nhiều người muốn áp dụng nhất thì chưa có bằng chứng.

Thiết kế: chỗ khiến kết quả này đáng tin

Hệ thống rút mỗi lượt hội thoại thành node có kiểu (Person, Organization, Location, Event, Concept, Artifact, Preference, Goal, Skill) và cạnh có thuộc tính, embedding bằng nomic-embed-text, khử trùng lặp bằng khớp tiêu đề rồi cosine ở ngưỡng 0,92. Truy hồi lấy đúng 5 node gốc (cosine ≥ 0,75), mở rộng BFS 2 hop, trần 15 node.

Con số "5 root" là toàn bộ giá trị của paper này. Nó biến câu hỏi mơ hồ "graph có tốt hơn không" thành câu hỏi trả lời được: với cùng một lượng thứ được lấy ra, cách tổ chức nào cho câu trả lời đúng hơn? Và câu trả lời là: không phải graph.

Module quên hoạt động thế nào

Mỗi node có điểm quan trọng là tổng có trọng số của bốn thành phần: độ mới (bán rã 90 ngày, trọng số 0,35), tần suất truy cập (log-chuẩn hóa, 0,25), độ trung tâm bậc (0,20), và suy giảm theo tuổi lượt (bán rã 1.000 lượt, 0,20). Cứ mỗi 400 lượt, node dưới 0,10 bị cắt cùng các cạnh kề.

Số liệu đáng nhớ

Bảng phân tách theo loại câu hỏi giải thích tại sao, và đó là phần hữu ích nhất. Graph không thua đều — nó thua thảm ở đúng một chỗ: khi câu trả lời đúng là nhớ lại nguyên văn thứ trợ lý đã nói. Quy trình rút trích biến "trợ lý gợi ý quán X vì lý do Y" thành các node thực thể, và bề mặt ngôn ngữ — chính là thứ cần trả lời — bị vứt trong quá trình đó. Ở câu hỏi thời gian, nơi cấu trúc thực sự giúp, graph hòa hoặc nhỉnh hơn.

Hạn chế — tác giả rất thẳng thắn

Họ tự khoanh vùng rõ: kết quả "đặc tả pipeline graph rút-trích này, không phải bộ nhớ dạng graph nói chung". Chỉ một model rút trích (GPT-4o-mini), một benchmark. Không quét siêu tham số — các trọng số retention là "một điểm duy nhất trên đường đánh đổi nén–chất lượng", không phải điểm tối ưu. Không có ablation tách riêng bốn thành phần điểm. Ngân sách chỉ đủ 4 lần chạy đầy đủ ở temperature 0.

Ba lớp

Nền bền vững (𝒫_t): danh tính kiến trúc, bộ nhớ riêng lâu bền, thân thực thi có phiên bản. Đây là "agent" theo nghĩa dọc thời gian. Nền thực thi thay thế được (ℰ_t): bộ suy luận (model), harness điều phối, máy chủ. Bề mặt tương tác thay thế được (𝒮_t): tài khoản chat, API, email, endpoint UI.

Giá trị của cách chia này nằm ở chỗ nó ép ta trả lời một câu ít khi được hỏi rõ ràng: khi bạn đổi model nền, cái gì đáng lẽ phải sống sót? Với hầu hết hệ thống hiện nay, câu trả lời thật là "gần như không gì" — vì trí nhớ, danh tính và code đều lẫn vào harness.

Sáu bước bàn giao

(1) Quiesce & fence: ngừng nhận việc mới, tăng authority epoch, từ chối các lệnh thực thi cũ đang lơ lửng. (2) Checkpoint: chụp phiên bản danh tính, revision của thân, bộ nhớ, trạng thái workflow, con trỏ provider. (3) Validate: kiểm schema, hash, lineage, và năng lực bên đích có đủ không. (4) Bind: phân giải provider và credential đích qua hợp đồng của thân. (5) Rehydrate: cài state riêng một cách nguyên tử, nạp thân và danh tính tách rời nhau, tạo session mới. (6) Verify & resume: chạy kiểm tra liên tục, giành epoch mới, đối soát tác dụng phụ, chạy tiếp việc dở.

Bước 1 và bước 6 là cặp quan trọng nhất, và cũng là chỗ hệ thống tự chế hay hỏng: nếu không có hàng rào epoch, bạn có thể có hai bản sao cùng tưởng mình là bản chính — cả hai đều ghi vào cùng bộ nhớ và cùng gửi tin cho người dùng.

Bằng chứng, và ranh giới của nó

Hạn chế — nên đọc kỹ phần này

Kiến trúc rút ra từ một dòng agent mã nguồn mở còn non. Không có harness suy luận thứ hai được đóng gói để so sánh. Tác giả viết rõ: "chúng tôi chưa chạy ma trận có kiểm soát trên mọi trục, và chưa đo tính liên tục về hành vi". Chưa đo downtime, chi phí, hay gánh nặng vận hành. Và bất biến về "quyền tiếp tục" không ngăn được một bản sao tách rời hoặc độc hại còn giữ credential chưa bị thu hồi — đây là lỗ hổng an ninh tác giả tự nêu, không phải điều tôi suy ra.

Bài toán thật sự là gì

Duy trì một recommender không phải là train một lần rồi xong. Nội dung đổi, hành vi người dùng đổi, các model thượng nguồn đổi — nên các lựa chọn về retrieval, ranking và serving phải được xem lại liên tục. Kỹ sư con người kiểm chứng những thay đổi đó bằng thí nghiệm online, và quy trình đó chậm đến mức nhiều phần hệ thống nằm im không được rà lại trong thời gian dài. Đó mới là chỗ agent chen vào được: không phải làm giỏi hơn người, mà làm thường xuyên hơn người.

Vì sao guardrail mới là phần đáng học

Khi LLM đề xuất chỉnh cấu hình, bộ tối ưu chiếu đề xuất đó lên tập {s : c_t(s) ≤ B} — tập cấu hình nằm trong ngân sách vận hành. Nếu đề xuất đã hợp lệ, nó deploy nguyên. Nếu vượt, bộ tối ưu phân bổ lại tài nguyên giữa các thành phần để về cấu hình khả thi gần nhất. Paper nói rõ: mọi cấu hình phát ra thỏa ràng buộc "by construction".

Đây là chỗ phân vai sạch sẽ và đáng sao chép: LLM lo phần suy luận trên tín hiệu hỗn tạp; công cụ tất định lo phần đảm bảo số học cứng. Ngân sách thay đổi bị chặn cứng chính là lý do thứ này được phép chạy trên production. Không có nó, không ai ký duyệt.

Số liệu đáng nhớ

Con số +0,15% nghe nhỏ, và đây là chỗ dễ đọc sai. Ở quy mô hàng tỉ người dùng, 0,15% watch time là một khoản lớn — và quan trọng hơn, nó đến ở chi phí serving bằng không. Đáng chú ý không kém là chi tiết vòng 2 tiết kiệm hơn vòng 1 tới 44%: vòng lặp cải thiện theo thời gian nhờ bộ nhớ kết quả, dù không có bất kỳ cập nhật trọng số nào.

Hạn chế

Ba điều tác giả tự nêu. (1) Vòng lặp chạy tự động nhưng vẫn dưới giám sát của con người; siết guardrail tự động để giảm giám sát là bước tiếp theo — tức là đây chưa phải tự trị. (2) Cả hai case chỉ hiện thực một lớp quyết định duy nhất: phân bổ tài nguyên có ràng buộc giữa các thành phần. Các đòn bẩy khác về chất chưa thử. (3) Bằng chứng đến từ A/B — vốn đắt và gắn chặt với bối cảnh; cách đánh giá chuẩn hóa cho "agent tối ưu hệ thống" trước khi deploy vẫn là bài toán mở.