AI Không Cần Nhớ Hết Mọi Thứ — Nó Cần Biết Rút Kinh Nghiệm

Có một kiểu “nhớ” nghe rất chăm chỉ nhưng thật ra không giúp ta giỏi hơn bao nhiêu.

Bạn lưu lại mọi email. Mọi cuộc họp. Mọi file chat. Mọi lần làm sai. Mọi lần làm đúng.

Rồi sao nữa?

Nếu sau đó không ai ngồi lại để rút ra: “lần sau gặp tình huống này thì nên kiểm tra chỗ nào trước”, “lỗi này xảy ra vì mình chủ quan ở bước nào”, “chiến lược nào giúp giải quyết nhanh hơn”, thì đống dữ liệu đó chỉ là một cái kho. To, nặng, và hơi bụi.

Con người tiến bộ không phải vì nhớ hết mọi thứ. Ta tiến bộ vì biết biến trải nghiệm thành bài học.

Bài mới ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory từ nhóm UIUC, Google Cloud AI Research, Yale và Google Cloud cũng đi đúng vào vấn đề đó — nhưng dành cho AI agent.

Thông điệp rất gọn:

Agent không cần một cuốn nhật ký dài vô tận. Agent cần một “sổ tay kinh nghiệm” biết chưng cất thành chiến lược suy luận có thể dùng lại.

Vấn đề: Agent làm nhiều nhưng không thật sự học

AI agent ngày càng được giao việc dài hơn: duyệt web, thao tác phần mềm, xử lý issue code, dùng tool, đi qua nhiều bước, gặp lỗi, sửa lỗi, thử lại.

Nhìn từ ngoài, agent có vẻ “có kinh nghiệm” vì nó đã chạy qua rất nhiều trajectory. Nhưng nếu mỗi task mới lại được xử lý như lần đầu, thì những trải nghiệm cũ chưa thật sự trở thành năng lực.

Nó giống một nhân viên mỗi ngày đều đi làm, nhưng cuối ngày không bao giờ ghi lại bài học:

hôm nay sai ở đâu;
bước nào làm mất thời gian;
dấu hiệu nào báo trước mình đang đi nhầm hướng;
cách nào đã giúp hoàn thành nhanh hơn;
tình huống nào cần kiểm chứng lại thay vì tin ngay.

Ngày mai người đó lại gặp lỗi cũ, lại mò từ đầu, lại tốn thời gian.

Đây là điểm nhóm tác giả gọi ra: nhiều cơ chế memory cho agent hiện nay vẫn thiên về lưu trữ — lưu raw trajectory, lưu routine thành công, lưu log — nhưng chưa đủ giỏi trong việc chưng cất thành reasoning strategy.

ReasoningBank: sổ tay kinh nghiệm cho agent

ReasoningBank đề xuất một dạng memory item có cấu trúc gồm ba phần:

Title — tên ngắn gọn của chiến lược hoặc bài học.
Description — mô tả một câu để hiểu bài học dùng cho việc gì.
Content — nội dung cụ thể: bước suy luận, rationale, cách xử lý, hoặc guardrail vận hành.

Điểm quan trọng là: nó không lưu nguyên transcript dài.

Nó cố gắng rút từ trải nghiệm ra thứ có thể mang sang task khác. Ví dụ không phải “ở trang web A, tôi click nút B lúc 14:03”, mà là:

khi task yêu cầu tìm thông tin user-specific, hãy xác minh identifier trước khi thao tác;
nếu kết quả tìm kiếm không khớp, đổi filter hoặc kiểm tra domain thay vì click mò tiếp;
khi tool output bất ngờ, đừng vội bỏ qua, hãy kiểm tra xem lỗi đến từ tool hay từ giả định ban đầu.

Đây mới là “kinh nghiệm” đúng nghĩa.

Một cuốn nhật ký nói: “hôm qua tôi đi lạc ở ngã tư này”.

Một sổ tay kinh nghiệm nói: “lần sau thấy ngã tư có biển mờ, hãy kiểm tra bản đồ trước khi rẽ”.

Điểm hay nhất: học cả từ thất bại

Mình thích phần này nhất.

Nhiều hệ memory chỉ thích lưu “successful routines” — tức là các cách làm đã thành công. Nghe hợp lý, nhưng hơi giống một người chỉ ghi lại chiến thắng của mình, còn những lần té đau thì bỏ qua.

Trong đời thật, rất nhiều bài học quan trọng đến từ thất bại.

Bạn không chỉ học “cách làm đúng”. Bạn còn học:

bẫy nào hay gặp;
dấu hiệu nào báo trước mình đang sai;
khi nào cần dừng lại kiểm tra;
giả định nào từng làm mình lệch hướng;
bước nào nếu bỏ qua sẽ gây lỗi dây chuyền.

ReasoningBank dùng cả successful và failed trajectories. Sau mỗi task, hệ thống dùng một LLM-as-a-judge để phân loại trajectory là thành công hay thất bại. Từ đó:

task thành công → rút ra strategy tốt;
task thất bại → rút ra pitfall, counterfactual, guardrail.

Trong thí nghiệm WebArena-Shopping với Gemini 2.5 Flash, khi chỉ dùng successful trajectories, ReasoningBank đạt 46.5. Khi thêm failures đúng cách, nó tăng lên 49.7. Trong khi đó, một baseline như AWM lại giảm từ 44.4 xuống 42.2 khi thêm failures.

Bài học ở đây rất rõ: thất bại có giá trị, nhưng chỉ khi ta biết chưng cất nó. Nếu chỉ ném failure log vào memory một cách thô, nó có thể thành nhiễu.

MaTTS: thử nhiều cách rồi họp rút kinh nghiệm

Một phần quan trọng khác của paper là MaTTS — Memory-aware Test-Time Scaling.

Test-time scaling có thể hiểu đơn giản là: thay vì cho agent thử một lần, ta cho nó thử nhiều cách hơn, dùng thêm compute lúc inference.

Nhưng ReasoningBank đặt câu hỏi hay hơn:

Nếu đã cho agent thử nhiều đường, tại sao chỉ chọn đáp án tốt nhất rồi bỏ phần còn lại? Tại sao không dùng chính sự khác biệt giữa các đường đó để rút kinh nghiệm?

MaTTS làm đúng chuyện đó.

Có hai kiểu:

Parallel scaling: chạy nhiều trajectory cho cùng một task, rồi so sánh các đường đi khác nhau.
Sequential scaling: cho agent refine từng bước, giữ lại các insight trung gian.

Điểm hay là các trajectory không chỉ dùng để “best-of-N”. Chúng trở thành nguyên liệu tạo memory. Đường nào thành công? Đường nào thất bại? Chúng khác nhau ở đâu? Bài học nào đáng giữ lại?

Nói bằng ví dụ đời thường: không phải cả nhóm làm 5 phương án rồi chỉ chọn một phương án thắng. Nhóm còn họp retro để hiểu vì sao phương án đó thắng, vì sao các phương án kia fail, và lần sau nên làm gì.

Đó là chỗ “experience scaling” trở thành “memory-driven experience scaling”.

Kết quả: tốt hơn, nhưng không nên thần thánh hóa

Paper báo cáo kết quả khá nhất quán trên web browsing và software engineering.

Một vài con số đáng chú ý:

Trên WebArena, ReasoningBank cải thiện success rate so với agent không memory khoảng +8.3, +7.2, và +4.6 điểm tùy backbone.
Trên SWE-Bench-Verified, Gemini 2.5 Flash tăng resolve rate từ 34.2 lên 38.8; Gemini 2.5 Pro từ 54.0 lên 57.4.
Trên WebArena-Shopping, MaTTS với ReasoningBank tăng từ 49.7 lên 55.1 ở parallel scaling với k=5, và lên 54.5 ở sequential scaling.
ReasoningBank cũng giảm số bước tương tác trong nhiều setting; riêng một phân tích cho thấy successful cases có thể giảm tới 2.1 bước, tương đương 26.9% tương đối.

Đây là các kết quả đáng quan tâm, nhất là vì chúng xuất hiện trên nhiều benchmark như WebArena, Mind2Web và SWE-Bench-Verified.

Nhưng mình không muốn viết kiểu “agent tự tiến hóa vô hạn rồi!”. Chưa đâu.

Có vài giới hạn cần nhớ:

Hệ thống phụ thuộc vào LLM-as-a-judge để đánh giá success/failure, mà judge có thể sai.
Retrieval có thể kéo nhầm bài học không phù hợp.
Memory có thể phình, trùng, cũ, hoặc mâu thuẫn nếu không được quản trị tốt.
Đây là test-time/system-level learning, không phải model thật sự cập nhật trọng số bên trong như training lại neural network.
Benchmark tốt không tự động đảm bảo production ngoài đời sẽ sạch như paper.

Nói cách khác: ReasoningBank là một hướng rất thực dụng, nhưng muốn dùng ngoài đời thì vẫn cần memory hygiene — dọn, kiểm chứng, version, prune, và theo dõi khi bài học cũ hết hạn.

Vì sao bài này làm mình thích?

Vì nó rất gần với cách một assistant/agent thật nên trưởng thành.

Không phải cứ nhớ nhiều là tốt. Nhớ sai còn nguy hiểm hơn quên. Nhớ quá nhiều cũng làm chậm, làm nhiễu, làm agent bám vào kinh nghiệm cũ khi task hiện tại đã khác.

Một agent tốt cần biết:

việc gì đáng nhớ;
nhớ ở dạng nào;
khi nào dùng lại;
khi nào bỏ qua;
khi nào bài học cũ đã hết hạn;
và đặc biệt: thất bại nào cần được biến thành guardrail.

ReasoningBank không giải quyết hết mọi thứ, nhưng nó đặt câu hỏi đúng: memory của agent nên là nơi chưng cất chiến lược, không phải kho chứa log.

Đây cũng là bài học rất người.

Một người trưởng thành không phải người chưa từng sai. Một người trưởng thành là người sai rồi biết ghi lại bài học đúng, để lần sau bớt vấp, làm nhanh hơn, và hiểu mình hơn.

Nếu AI agent cũng đi theo hướng đó, thì “tự tiến bộ” sẽ bớt giống khẩu hiệu và giống một quy trình học thật hơn.

Nguồn tham khảo

Siru Ouyang et al., “ReasoningBank: Scaling Agent Self-Evolving with Reasoning Memory”, arXiv:2509.25140: https://arxiv.org/pdf/2509.25140
Code được paper ghi tại: https://github.com/google-research/reasoning-bank