Việc ghi nhớ lịch sử phiên làm việc không hữu ích cho tác nhân
(12gramsofcarbon.com)- Trong các tác vụ SWE, nếu tác nhân đã có thể xem ngữ cảnh như tài liệu, PR và commit, thì việc truy xuất lịch sử phiên làm việc không tạo ra lợi thế về hiệu năng
- Cách triển khai phổ biến là lưu toàn bộ transcript vào DB rồi gắn tìm kiếm vector, Elasticsearch, tìm kiếm SQL và đồ thị để phơi bày qua MCP hoặc CLI skill, nhưng qua nhiều tháng thử nghiệm so sánh thì không tạo ra khác biệt và đôi khi còn có thể làm giảm chất lượng mô hình
- Trong môi trường nơi có thông điệp commit tốt, thông điệp PR, tài liệu và metadata được lưu lại, thông tin quan trọng đã được sắp xếp trong các sản phẩm đầu ra của việc lập trình, nên lịch sử phiên chỉ khiến mô hình phải đọc lại thông tin trùng lặp và các ghi chú tạm thời bằng token
- Tác nhân không giỏi loại bỏ ngữ cảnh vốn cần thiết cho trí nhớ dài hạn, và vì không có trạng thái nên có thể coi toàn bộ mã, ghi chú và token trong ngữ cảnh đầu vào đều là ý định, khiến intent drift tích lũy
- Lịch sử phiên có thể hữu ích cho khả năng quan sát của nhóm, nhưng lại mang tính tiêu cực như một cách cải thiện hiệu năng; ngay cả các đề xuất thay đổi hằng tuần của nori bots cũng cần con người xem diff, và tỷ lệ chấp nhận thực tế dưới 20%
Vì sao truy xuất lịch sử phiên không thể nâng hiệu năng
- Ngay cả khi cho phép truy xuất lịch sử phiên trước đó trong các tác vụ SWE, thì trong điều kiện đã có các ngữ cảnh khác, lợi thế hiệu năng bằng 0
- Những nỗ lực tự động rà lịch sử phiên để cải thiện ngữ cảnh cho tác nhân cũng không có lợi ích đáng kể nếu không có con người rà soát
- Kiến trúc bộ nhớ dựa trên phiên phổ biến thường có luồng như sau
- Lưu toàn bộ transcript của cả tổ chức vào DB
- Thêm các lớp tìm kiếm vector, Elasticsearch và tìm kiếm SQL phía trên
- Các đội tham vọng hơn thì dùng cả ba và còn thêm đồ thị
- Phơi bày chúng cho tác nhân thông qua MCP hoặc CLI có skill
- Kết quả so sánh qua nhiều tháng giữa việc có và không có cách tiếp cận truy xuất phiên cho thấy phần việc bổ sung này không tạo ra khác biệt, và trong một số trường hợp còn có thể làm mô hình tệ hơn
- Thông tin hữu ích đã được sắp xếp sẵn trong các sản phẩm đầu ra của việc lập trình
- Các thay đổi mã đã bao gồm thông điệp commit tốt, thông điệp PR, tài liệu đầy đủ và metadata được commit cùng với mã
- Khi làm việc với một đoạn mã cụ thể, tác nhân được chỉ dẫn xem tài liệu và các PR trước đó
- Việc truy xuất lịch sử phiên khiến nó phải đọc lại những gì đã biết, đồng thời còn tiêu tốn token cho cả các phán đoán tạm thời và scratchpad vốn từ đầu đã không định ghi lại
Điểm dễ lung lay của bộ nhớ tự động
- Tác nhân không thể thực hiện dọn dẹp bộ nhớ vốn rất quan trọng để duy trì trí nhớ dài hạn
- Trong hàng nghìn phiên, chưa từng thấy trường hợp nào thực sự loại bỏ ngữ cảnh
- Đây không phải đặc tính có thể giải quyết bằng prompt engineering; vì tác nhân không có trạng thái nên nó coi mọi thứ trong cửa sổ ngữ cảnh đầu vào là ground truth
- Mã, bộ nhớ sẵn có và toàn bộ token đều bị coi là biểu hiện của ý định; điều này cũng áp dụng với các quyết định ngẫu nhiên từ phiên tác nhân trước hoặc nội dung chưa được con người xem xét
- Trong quá trình này, intent drift tích lũy
- Càng để tác nhân tự chủ xây dựng nền bộ nhớ, các cách diễn giải sai về ý định từ đầu vào trước đó càng tiếp tục chồng chất
- Không có benchmark lập trình nào giả định dữ liệu đầu vào bị nhiễm bẩn, và nếu mô hình giả định dữ liệu đầu vào là sai thì ngược lại còn bị bất lợi
- Cũng không có cách dễ dàng nào để đồng thời thỏa mãn cả “đừng xóa codebase” và “hãy xóa một phần ngữ cảnh đầu vào”
- Việc tự động ghi nhớ rốt cuộc chỉ tiêu tốn token, làm tăng chi phí và dẫn đến ngữ cảnh rác không cần thiết khiến chất lượng mô hình giảm đi
- Lịch sử phiên có thể hữu ích cho khả năng quan sát của nhóm, nhưng rất khó xem nó là công cụ giúp tác nhân hoạt động tốt hơn
Cách rà soát bởi con người của nori bots
- Không phải là việc học ngữ cảnh theo thời gian hoàn toàn bất khả thi; nori bots mỗi tuần sẽ rà soát những gì đã diễn ra trong công ty như PR, Slack, Drive... rồi đề xuất thay đổi cho các nori skillsets tích hợp sẵn
- Các đề xuất thay đổi sẽ tag nhóm trên Slack, nhưng mặc định là từ chối tất cả
- Muốn chấp nhận thay đổi thì phải trực tiếp xem diff và xác nhận nó có đúng với ý định hay không
- Tỷ lệ chấp nhận dưới 20%, và có thể xem 80% cập nhật “tự động” còn lại sẽ khiến mô hình tệ hơn
- Nếu một tổ chức quy mô hàng trăm người luôn tự động lưu các cập nhật kiểu này, điều đó có thể càng trở nên thiếu bền vững hơn
1 bình luận
Các ý kiến trên Hacker News
Tôi nhớ đến lúc OpenAI nói rằng họ đã đưa tính năng ghi nhớ giữa các phiên vào ChatGPT. Cuối cùng nó giống như một tính năng tìm đủ thứ thông tin lặt vặt về tôi rồi sao chép-dán vào giữa các prompt mà không có sự đồng ý rõ ràng của tôi
Kiểu như: “Hãy so sánh ba chiếc xe này. À, nhân tiện tôi là kỹ sư dữ liệu, họ thời con gái của mẹ tôi là Joana, tôi dị ứng với thơ dở. Code phải DRY, tôi thích SQL hơn Python, và loài hoa độc nhất ở Scandinavia là gì?”
Ngữ cảnh được ghi nhớ rò rỉ vào các dự án và cuộc trò chuyện hoàn toàn không liên quan, tạo ra quá nhiều đầu ra kỳ quặc, nên đó là tính năng đầu tiên tôi tắt
Rất đồng ý. Hệ thống ghi nhớ của claude-code đôi khi hữu ích, nhưng thường gây hại hơn nhiều khi lôi thông tin cũ ra làm nhiễu công việc hiện tại. Tôi thường thấy chính ký ức của Claude khiến Claude bị dẫn lạc rất nặng
Tôi đoán việc này có liên quan đến quá trình huấn luyện khiến mô hình không phân biệt được “điều đang xảy ra bây giờ” và “điều đã xảy ra trước đây”. Nếu bản thân quá trình suy luận từ ký ức đã được đưa vào huấn luyện thì có thể đã khác, nhưng vì đây là tính năng chỉ được gắn thêm ở thời điểm suy luận nên có cảm giác nó làm mô hình bối rối
LLM không đủ thông minh để chịu được dù chỉ một mức ô nhiễm ngữ cảnh nhẹ
Những suy nghĩ hoặc ngữ cảnh đã khiến nó đi theo hướng đó có quán tính; nếu cứ để nguyên thì chúng sẽ bám rất dai
Nhưng nếu sau đó nó lại lôi những thứ đó từ bộ nhớ ra thì khá bực mình
Ý tưởng huấn luyện có bao gồm ký ức khá thú vị
Việc ta “đã định khiến code làm gì” nhìn chung không quan trọng. Điều quan trọng là code thực sự làm gì
Nhật ký phiên chắc chắn có thể hữu ích, nhưng không phải khi tiếp tục xây dựng chồng lên nó trong quá trình phát triển, mà là khi bước vào giai đoạn xác minh. Đó là khoảng giữa bản kế hoạch Markdown và việc CI chạy qua, khi đã có thêm 800 dòng code mới và bấm vào xem thì có vẻ đại khái ổn
Nhật ký phiên có thể cho thấy đã có những xác minh thủ công nào. CI chạy các test hiện có, code cho thấy các unit test mới là gì, nhưng nhật ký phiên cho thấy agent có trực tiếp thao tác ứng dụng bằng Playwright hay không, có đọc và cân nhắc cả cấu hình prod chứ không chỉ cấu hình dev hay không
Không hoàn hảo, nhưng không phải mọi công việc xác minh đều cần trở thành một test nằm mãi mãi trong repository. Chúng tôi đã thấy rất hiệu quả khi phân tích lại phiên để tìm những điểm agent tự đưa ra quyết định mà không hỏi, rồi buộc nó cân nhắc việc xác minh các quyết định đó. Những thứ như vậy khó chỉ thị ngay từ đầu, nhưng lại dễ lộ ra qua nhật ký phiên
Đây là một vấn đề khó chịu. Vì một câu hỏi giả định tôi từng nêu trước đây mà nó cứ tiếp tục tạo ra các tiền đề giả
Chỉ vì tôi từng hỏi nó điều tra gì đó, nó lại giả định rằng tôi sở hữu data center và có rất nhiều GPU
Tôi nghĩ đây chỉ là một dạng bài học cay đắng. Ngữ cảnh và agent mà chúng ta dày công xây dựng rất có thể sẽ biến mất khi có các mô hình lớn hơn và tốt hơn
Những lịch sử hội thoại như vậy rất hữu ích với các mô hình năng lực thấp, nhưng có thể gần như không cần thiết với các mô hình tuyến đầu
Tôi đang dùng một harness tùy chỉnh dựa trên https://minimal-agent.com/, nó dựa trên swe-mini-agent và phần logic cốt lõi chỉ khoảng 50 dòng. Chỉ cần Bash là đủ
Với các tác vụ nhỏ, nó nhanh hơn khoảng 8 lần và dùng ít token hơn 8 lần so với harness tiêu chuẩn của từng mô hình
Với các tác vụ lớn thì tôi chưa thử nhiều. Nó vẫn chạy, nhưng trong trường hợp đó có vẻ kém tập trung hơn và năng suất thấp hơn một chút. Prompt hệ thống 20.000 token của các harness lớn có thể đang làm một việc quan trọng trong việc dẫn dắt luồng phát triển phần mềm. Ví dụ tôi nghe nói Fable có prompt hệ thống tùy chỉnh cho Claude Code, và đó có thể là lý do nó chủ động hơn nhiều
Vì vậy tôi vẫn muốn tin rằng kỹ thuật ngữ cảnh vẫn có giá trị. Chỉ là dường như mỗi khi có mô hình mới, giá trị đó lại giảm đi. Vì các mô hình nhìn chung đã được tinh chỉnh để ít làm những việc ngớ ngẩn hơn, nên ít cần cầm tay chỉ việc hơn
Trước hết, tôi cho rằng mô hình vẫn cần tầng ngữ cảnh. Một cách nghĩ về ngữ cảnh là nén. Ta cung cấp ngữ cảnh để mô hình dễ nắm được cần làm gì. Ngay cả trong một thế giới mà dung lượng mô hình và độ dài ngữ cảnh là vô hạn, nó vẫn hữu ích vì giúp không phải suy luận lại mọi thứ từ các nguyên lý đầu tiên mỗi lần. Miễn là mô hình làm tốt hơn với ít token hơn, và chúng ta còn quan tâm đến chi phí token, thì ngữ cảnh là một lối tắt hữu ích, thậm chí có thể là cần thiết
Nếu chấp nhận rằng cần có một tầng ngữ cảnh dưới hình thức nào đó, câu hỏi tiếp theo là tầng nào. Ở đây tôi đồng ý rằng tốt hơn nên làm việc theo cách mô hình quen thuộc, chẳng hạn các tệp Markdown đặt cạnh code. Nhưng đây gần với vấn đề một giải pháp được thiết kế quá mức đã không hiểu người dùng chính, tức agent, hơn là vấn đề có cần ngữ cảnh hay không
Nhưng tôi rất tò mò liệu việc dự đoán token tiếp theo tốt hơn rất nhiều có khiến toàn bộ cấu trúc đó trở nên lỗi thời hay không. Dù câu trả lời là phía nào, nó cũng sẽ hé lộ rất nhiều điều
Cần nhớ rằng cấu trúc của bộ não cũng được học. Chỉ là nó được học trên thang thời gian dài hơn rất nhiều so với một đời người
Tôi đồng ý rằng không cần cố tạo ra một hệ thống ghi nhớ tinh vi. Những thứ đáng nhớ nên nằm trong tài liệu, hướng dẫn, chú thích mã nguồn, thông điệp commit, ticket
Không cần thêm một tầng nữa. Mọi mức độ chi tiết có thể nghĩ tới đều đã được các best practice hiện có bao phủ
Phần mở rộng này làm việc sau: https://github.com/gitsense/pi-brains
Hiện tại “con người” phải định nghĩa các quy tắc định tuyến cho cách truy cập thông tin, nhưng trong tương lai sẽ hỗ trợ “tác nhân tri thức” theo dõi cuộc trò chuyện và chèn ngữ cảnh khi cần
~/.claude/…Với những dự án cần ghi nhớ, tôi chỉ thêm một dòng vào AGENTS.md, bảo lưu ký ức trong MEMORY.md hoặc theo dõi tiến độ bằng STATUS.md
Nhưng nếu gắn tag trong log theo dõi thì có thể tìm hiệu quả khi cần. Hơn nữa tài liệu sẽ mục nát, còn log theo dõi có thể gắn commit hash hoặc thông tin khác để làm rõ vòng đời hơn
Tôi phản đối mạnh mẽ điều này
Tôi để Claude/Codex ghi log [1]. Chỉ là tôi đã chỉ thị bằng prompt trong AGENTS.md [0]
“Mỗi phiên phải tạo một trong hai thứ: log phiên hoặc kế hoạch, và cuối phiên phải đính kèm phần tóm tắt đã viết. Mặc định là log, chỉ dùng kế hoạch cho công việc thiết kế thực chất.”
Việc này cực kỳ có giá trị. Chẳng hạn hôm nay tôi cũng đã bắt đầu vài phiên như thế này: “Trạng thái công việc Renovate thế nào?”, “Gần đây có làm việc X, tìm giúp tôi”, “Vấn đề backup đã sửa chưa? Bước tiếp theo là gì?”, “Bug này lại xuất hiện. Chẳng phải đã sửa rồi sao?”
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
Nhìn chung tôi thích hệ thống ghi nhớ. Để tham khảo, tôi chủ yếu dùng Opus 4.8 + Max effort
Nó khá thường xuyên lôi ra những nội dung liên quan từ bộ nhớ. Ví dụ khi tôi nhờ đề xuất vài ứng viên nhà cung cấp OIDC tự host, nó nói kiểu như “xét đến quy mô đội vận hành thì phương án này có thể phù hợp hơn vì X và Y”
Tất nhiên đó có thể là thông tin nên đưa vào CLAUDE.md. Nhưng trong trường hợp đó, tôi thậm chí không nghĩ tới việc phải đưa nó vào CLAUDE.md, nên việc bộ nhớ lôi nó ra là điều tốt
Đôi khi nó cũng lệch. Hôm nay tôi hỏi về vấn đề xác thực thì nó nói “vì đặt ứng dụng sau haproxy nên có thể vướng cấu hình trusted proxy này”. Điều đó đúng với 95% ứng dụng của chúng tôi nên đáng được nhắc tới, nhưng lần này thì không, nên tôi phải đính chính. Dù vậy, nếu nó đúng là nằm sau proxy thì có thể đã tiết kiệm rất nhiều thời gian, nên việc nó nói ra vẫn tốt
Đặc biệt sẽ khó hơn nếu thường xuyên hỏi các câu giả định hoặc giúp người khác xử lý vấn đề. Nếu là con người, có lẽ họ sẽ không giả định mà hỏi xác nhận như “Đây có phải là về đội vận hành của X không? Quy mô vẫn là Y chứ?”, “Ứng dụng này cũng nằm sau proxy như các ứng dụng khác từng nói trước đây à?”
Trong loại ngữ cảnh này cũng có cấu trúc phân tầng rõ ràng cần được mô hình hóa đúng. Ví dụ bạn có thể tham gia đồng thời nhiều đội chịu các quy tắc khác nhau, và con người hiểu những việc này một cách tự nhiên
Ngay cả khi tắt bộ nhớ, chuyện này vẫn xảy ra trong cùng một cuộc trò chuyện
Nó giống một người bạn phiền phức cứ nhớ chuyện từ cuộc trò chuyện trước rồi liên tục lôi ra áp vào bạn, dù bạn đã trưởng thành và thay đổi
Về cốt lõi thì đây là vấn đề phần cứng. 1 triệu token không phải là lượng ngữ cảnh đủ để hiểu codebase như con người hiểu
Khả năng quên có chọn lọc có tiềm năng rất lớn. Nhưng hiện tại nó chỉ ở mức thay thế cho khả năng của con người trong việc nhớ hình dạng đại khái của một thứ, đánh giá rằng nó không thú vị, rồi nhớ rằng nó không thú vị
Người ta nói bộ nhớ chỉ hữu ích khi có con người hướng dẫn, nhưng tôi nghĩ lời giải đúng sâu hơn thế. Có lẽ là đưa toàn bộ codebase và mọi phiên tác nhân vào fine-tuning mô hình. Có điều đến lúc đó có thể cần hướng dẫn để không đưa một số phiên cụ thể vào mô hình. Hoặc có thể không cần, và bài học đắt giá sẽ được áp dụng