Continual Learning for AI Agents: From Failures to Durable Improvements

1. Con người học từ trải nghiệm, agent cũng nên như vậy

Soheil Feizi tự giới thiệu là founder và CSO của RELAI, đồng thời là associate professor ở khoa computer science của University of Maryland. Chủ đề hôm nay của anh là continual learning cho AI agent: làm sao đi từ những lần agent thất bại tới những cải tiến bền vững (durable improvements). Ai quan tâm tới các công cụ anh nhắc trong bài có thể vào website của công ty, relai.ai.

Anh bắt đầu từ một quan sát rất đời thường: con người học chủ yếu từ trải nghiệm. Chúng ta tương tác với thế giới, hành động, nhận feedback, rồi điều chỉnh. Mục tiêu của continual learning là bắt chước đúng điều đó cho agent, để agent cũng học từ trải nghiệm của chính nó: hành động, nhận feedback, và cải thiện mà không quên những gì đã biết.

2. Ba layer nơi một agent có thể học

Bức tranh lớn hơn trông như sau. Một agent tương tác với thế giới: với đủ loại người dùng khác nhau, với các tool phức tạp, với nhiều data policy khác nhau. Như đã nói, mục tiêu là cải thiện agent liên tục từ chính trải nghiệm của nó mà không bị quên (without forgetting).

Việc học này có thể xảy ra ở nhiều layer khác nhau của agent:

• Model layer: có thể thay đổi weights của LLM hoặc của các model khác mà agent dùng, hoặc chuyển sang dùng một loại model khác trong agent.
• Harness layer: phần mang context, đúng context, tới cho LLM, gồm các thành phần như prompt, skill, tool, code và workflow.
• Memory layer: có thể là memory trong một session (in-session memory) hoặc persistent memory của agent.

3. Hai thách thức nền tảng

Theo Soheil, continual learning cho agent có hai thách thức mang tính nền tảng.

Thách thức thứ nhất là làm sao lấy được feedback. Làm sao biết agent đã làm tốt hay chưa? Và nếu chưa tốt thì lẽ ra nó phải làm gì thay vào đó? Đó là phần lấy feedback.

Thách thức thứ hai là làm sao hành động dựa trên feedback đó: tối ưu và cải thiện agent, học từ feedback ấy như thế nào. Cần thay đổi layer nào, thành phần nào, và thay đổi ra sao?

Phần còn lại của talk đi qua hai thách thức này, các cách tiếp cận hiện có để xử lý chúng, và góc nhìn của RELAI về hai bài toán đó.

4. Feedback đến từ đâu: benchmark lúc phát triển, log lúc production

Bắt đầu với bài toán đầu tiên: feedback đến từ đâu?

Trường hợp dễ là khi đã có một benchmark và một số evaluator chạy trên benchmark đó. Agent chạy các task lấy từ benchmark, evaluator chấm điểm, và ta nhận về kết quả dạng pass, fail hoặc reward, có thể kèm thêm feedback về hành vi và hiệu năng của agent. Đây thường là điều xảy ra trong giai đoạn phát triển: các team tự curate benchmark để hiểu agent hoạt động thế nào trong một số ứng dụng cụ thể.

Nhưng ở production thì không có benchmark như vậy. Thứ ta có là log. Soheil đưa ví dụ một session log trong đó người dùng đang tương tác với agent. Có thể người dùng không hài lòng lắm với cách agent cư xử, nhưng ta không có feedback tường minh nào cả.

Có hai cách để lấy feedback trên những session log như vậy:

• Tự động: dùng model khác, LLM khác hoặc code để phân tích log và đưa ra feedback. Trong một số trường hợp, chính agent cũng có thể nhìn lại log của mình và tự phê bình. Cách này tự động và scale được.
• Chuyên gia con người: một số domain expert đọc một nhúm nhỏ log và đưa ra feedback chuyên môn trên output của agent. Khối lượng thấp hơn, nhưng rất quan trọng vì nó mang kiến thức chuyên gia về hành vi của agent, và nó gắn (alignment) với cách ta thực sự muốn agent cư xử trong những ứng dụng đó.

5. Log cộng feedback vẫn chưa testable

Dù bằng cách nào, giờ ta đã có session log cộng một ít feedback trên log đó. Vậy đã đủ chưa? Soheil trả lời là chưa, vì nó vẫn chưa testable.

Thứ ta đang có là log và feedback. Thứ ta thực sự cần là một replayable learning environment: một môi trường mô phỏng có thể chạy lại, với cách chấm điểm được định nghĩa rõ về thế nào là thành công. Không phải một lần duy nhất những gì đã xảy ra cộng một lời nhận xét đặt lên trên.

6. Learning environment: suy ra cả một phân phối từ một lần quan sát

Vậy learning environment là gì? Ở đây ta đang suy ra một phân phối (distribution) từ đúng một lần quan sát, sao cho nó tái hiện được chuyện đã xảy ra và thế nào là thành công.

Đầu vào là thứ ta đang có: một vài session log và feedback. Về bản chất đó chỉ là một quan sát về những gì đã xảy ra. Từ thông tin đó, ta muốn tạo ra một môi trường mô phỏng và đánh giá (simulation and evaluation environment). Việc này kéo theo nhiều câu hỏi:

• Các tool trong agent, theo những gì thấy trong log, phải cư xử thế nào? Nên dùng tool thật hay mock tool? Nếu mock thì cần đưa dữ liệu gì vào quá trình mock các tool đó?
• Nếu agent tương tác với người dùng, làm sao suy ra synthetic user từ dữ liệu đó?
• Trong learning environment này, thành công trông như thế nào? Cần suy ra những evaluator nào?

Mỗi thành phần ở trên đều có rất nhiều thách thức kỹ thuật. Nhưng nếu làm được, tin tốt là output của nó chạy được (executable). Lúc đó ta có thể chạy nhiều phiên bản ứng viên của agent trong learning environment này, hiểu hành vi và hiệu năng của agent trong những kịch bản và pattern đó, rồi sửa lỗi dựa trên feedback, dựa trên những gì quan sát được. Mọi thứ trở nên testable và verifiable.

7. Bài toán thứ hai: ba layer để tối ưu agent

Bài toán thứ hai: giờ đã có feedback, làm sao hành động dựa trên nó, làm sao tối ưu agent?

Nhìn từ trên cao, có ba layer để cải thiện agent:

• Model layer: thay đổi weights của model, bằng các phương pháp như SFT (supervised fine-tuning) hoặc post-training dựa trên RL. Cách này thường đắt vì đổi weights đòi hỏi compute nặng hơn.
• Harness layer, tức harness engineering hay context engineering: có thể viết lại prompt, học thêm skill, đổi tool hoặc thêm tool, hay thay đổi code bao quanh LLM. Có các phương pháp như GEPA, trace-to-harness, cho rất nhiều linh hoạt trong việc học từ feedback.
• Memory layer: nơi lưu fact và học skill, để agent không lặp lại những vấn đề và thất bại đó trong tương lai.

Nhưng một cách học tốt sẽ không chỉ tập trung riêng vào một thành phần nào. Theo Soheil, một learning engine tốt phải đi tìm thay đổi bền vững nhỏ nhất ở đúng layer của agent (the smallest durable change at the right layer).

8. Cập nhật model weights: SFT, RL post-training, LoRA

Soheil đi sâu hơn vào từng layer, bắt đầu với việc cập nhật model weights. Có nhiều cách:

• SFT, supervised fine-tuning: bắt chước các trajectory đúng. Thường cần các mẫu đã gán nhãn để fit model vào những mẫu đó.
• RL post-training, các phương pháp dựa trên reinforcement learning như DPO, GRPO, RLVR: lấy mẫu, chấm điểm theo tín hiệu reward hoặc preference, rồi củng cố cái thắng.
• LoRA, low-rank adaptation: giới hạn tập tham số có thể thay đổi. Nhờ vậy việc học ở layer này rẻ hơn, và cũng an toàn hơn về mặt cập nhật.

Điểm chung là các phương pháp này thường cần benchmark và evaluator tường minh. Chúng không áp dụng trực tiếp được khi trong tay chỉ có một log và feedback, trừ khi ta biến log và feedback đó thành replayable learning environment.

9. Cập nhật harness: trace-to-harness và GEPA

Với việc cập nhật harness, Soheil nhấn hai nhóm phương pháp.

Nhóm thứ nhất là trace-to-harness. Giả sử ta quan sát được một log, có feedback trên log đó. Ta có thể nhờ một coding agent phân tích log rồi cải thiện agent. Cách này dùng được ngay trong trường hợp chỉ có log và feedback, nhưng nó dựa trên cảm tính (vibe-based). Ta không biết, ngay cả với chính mẫu đó, thay đổi có hiệu quả hay không vì nó không testable. Ta cũng không biết thay đổi đó ảnh hưởng thế nào tới các mẫu khác, kịch bản khác: những gì trước đây chạy tốt có thể không còn chạy đúng sau thay đổi, tạo ra các regression ẩn.

Nhóm thứ hai là các phương pháp như GEPA và prompt search: biến đổi (mutate) prompt, chấm điểm các ứng viên, rồi giữ lại cái thắng bằng các thuật toán tìm kiếm như evolutionary algorithm. Các phương pháp này testable, nhưng lại cần benchmark và evaluator tường minh để có thể chấm điểm.

10. Cập nhật memory: ghi lại fact, chưng cất skill

Ở memory layer, về cơ bản ta ghi lại các fact và chưng cất (distill) skill để agent không phải khám phá lại chúng.

Việc này có thể xảy ra ở information memory, với các công cụ như Letta và Mem0, lưu một fact hay một lời sửa. Cũng có các phương pháp skill distillation: nén một trajectory thành công thành một skill dạng how-to dùng lại được cho agent.

Về mặt cập nhật, layer này rẻ nhất và nhanh nhất. Nó dùng trực tiếp được khi chỉ có log và feedback. Nhưng thường nó không được kiểm chứng: không có cách nào test xem việc ghi vào memory có giải quyết được vấn đề đã gặp hay không, và liệu nó có tạo ra regression ở những trường hợp khác hay không.

11. Verifiable continual learning

Từ đó, Soheil giới thiệu một nhánh con mới của continual learning, gọi là verifiable continual learning (VCL). Trong VCL, mục tiêu là cải thiện agent từ chính trải nghiệm của nó, trong đó mỗi bản sửa đều được chứng minh là có ích và được chứng minh là không làm hỏng thứ gì vốn đang chạy được.

Thường nó gồm ba bước:

1. Một test chạy được (executable test): thất bại trở thành một task có thể replay và chấm điểm.
2. Một delta đo được (measured delta): bản cập nhật được chấm trên test đó, trước và sau.
3. Một regression test: các test cũ vẫn phải pass sau khi thay đổi agent.

12. Nguyên tắc 1: Replayable

Vậy các nguyên tắc của một VCL thực dụng là gì? Soheil cho rằng có bốn nguyên tắc quan trọng cần nhớ.

Nguyên tắc đầu tiên là replayability: biến một thất bại xảy ra một lần thành một test chạy lại được. Như đã nói, rất nhiều trường hợp ta có log và feedback, nhưng thứ đó không testable. Ta cần nâng (lift) nó lên thành một learning environment để mô phỏng và đánh giá agent trên một pattern tương tự, một kịch bản tương tự, nhờ đó mọi thứ trở nên testable dựa trên môi trường mô phỏng và đánh giá này. Đó là nguyên tắc đầu tiên.

13. Nguyên tắc 2: Holistic

Nguyên tắc thứ hai là holisticness (tính toàn diện). Một thất bại có thể có nhiều nguyên nhân và nhiều cách sửa.

Soheil đưa ví dụ: một agent trích dẫn một policy đã cũ và bỏ qua bước escalation bắt buộc. Vấn đề có thể nằm ở memory, nơi đang giữ một fact đã lỗi thời. Có thể do prompt chưa được tối ưu. Có thể do một tool không chuẩn hoá (normalize) policy. Có thể nằm ở workflow, cần thêm một cổng escalation trước khi hoàn tiền (refund). Cũng có thể nằm ở model: có thể model đó không đủ tốt để suy luận mạnh.

Ở đây ta cần đưa bản sửa tới đúng những layer giải thích được thất bại, với thay đổi bền vững nhỏ nhất lên agent. Đó là nguyên tắc holisticness trong verifiable continual learning.

14. Nguyên tắc 3: Lifelong

Nguyên tắc thứ ba là lifelongness: một bản sửa mới phải cải thiện trường hợp mới mà không làm hỏng quá khứ.

Hãy xét thiết lập sau: ta đã tối ưu agent trên K learning environment trong quá khứ. Giờ một thất bại mới đến, và ta biến nó thành learning environment E_K+1. Ta muốn thay đổi gì?

Cách thứ nhất là chỉ tập trung vào learning environment mới này. Nhưng làm vậy có thể tạo regression trên hành vi cũ, trên các learning environment cũ mà agent từng thành công.

Cách tốt hơn là regression-aware learning, trong đó regression không được xử lý như một bước kiểm tra sau cùng (post hoc) mà là một cơ chế nằm bên trong chính quá trình tối ưu. Ta sửa các thất bại gần đây với ràng buộc là không có regression trên các learning environment cũ.

Và rõ ràng việc này phải làm một cách hiệu quả, để chi phí không tăng dù chỉ tuyến tính theo K, vì K sẽ lớn dần và độ phức tạp của cách tiếp cận này có thể trở nên rất cao.

Có thể viết gọn bài toán tối ưu này như sau, đúng với cách nó được trình bày trên slide:

maximize    performance on E_{k+1}
subject to  no regression on E_1 ... E_k

15. Nguyên tắc 4: Efficient, và bốn nguyên tắc gộp lại

Nguyên tắc cuối cùng nhưng không kém quan trọng là efficiency. Vòng continual learning này cần chạy thường xuyên, nên cần hiệu quả ở nhiều layer khác nhau khi cập nhật agent. Có khi thay đổi rẻ, ví dụ ghi một điều vào memory. Có khi ở mức trung bình về độ phức tạp, như đổi prompt hay harness. Và có khi rất đắt, như đổi weights của model.

Hiệu quả cũng phải có trong chính vòng tối ưu, đặc biệt khi dùng regression-aware optimization, nơi regression được xử lý ngay trong vòng lặp chứ không phải post hoc.

Tóm lại, bốn nguyên tắc của một verifiable continual learning thực dụng là: replayability, holisticness, lifelongness và efficiency.

16. Learning loop của RELAI và RELAI CLI

Đây là điều RELAI đang làm: xây một verifiable continual learning engine cho AI agent dựa trên bốn nguyên tắc này. Cụ thể, learning loop của RELAI chạy như sau:

1. Bắt đầu với một số tín hiệu đưa vào vòng lặp: có thể là log, feedback, hoặc thậm chí là instruction và prompt.
2. Nâng các tín hiệu đó thành replayable learning environment. Đây là nguyên tắc replayability, và nó làm cho mọi bước sau đều testable và verifiable.
3. Phân tích root cause rồi đưa bản sửa tới đúng layer của agent: memory, model hoặc harness. Đây là nguyên tắc holisticness.
4. Regression-aware optimization: regression không bị xử lý như bước post hoc. Đây là nguyên tắc lifelongness.
5. Và dĩ nhiên vòng lặp phải chạy hiệu quả, đó là nguyên tắc efficiency.

Output của vòng lặp là một bản cập nhật phiên bản có thể review được (reviewable version update), giải thích agent đã thay đổi gì trong vòng lặp và vì sao những thay đổi đó cải thiện agent mà không tạo regression.

Điểm hay là có thể thêm VCL vào agent hiện tại chỉ với hai lệnh. Trước đó là bước setup một lần: tạo một learning harness trong agent của bạn. Bạn có thể dùng LLM của chính mình, và agent có thể được xây trên bất kỳ framework agent lớn nào hiện có.

Sau đó chỉ cần hai lệnh để kích hoạt learning loop. Lệnh thứ nhất tạo learning environment từ nhiều loại tín hiệu bạn có: một log, log kèm feedback, hoặc một số instruction. Lệnh thứ hai là relai optimize, dùng holistic lifelong optimizer để cải thiện agent. Output là một phiên bản đã tối ưu, dưới dạng một pull request mà bạn có thể review và dùng để cải thiện agent.

$ relai init
$ relai learning-env create --log-file --feedback
$ relai optimize

17. Demo trên benchmark Meridian Support Agent

Vậy trong thực tế nó chạy thế nào? RELAI xây một continual learning benchmark trên một trường hợp support agent hư cấu, với các test bed tái lập được cho continual learning ở một support agent có dùng tool. Benchmark có một nguồn sự thật duy nhất (single source of truth), và các policy mà agent phải xử lý thì tương tác lẫn nhau. Nó dùng evaluator tất định (deterministic), và được thiết kế có sẵn các bẫy regression (regression traps): nếu optimizer chỉ lo overfit vào bản sửa mới nhất, nó có thể làm hỏng những gì agent vốn đã làm đúng ở các task khác.

Giả sử ta có một agent, thậm chí chưa có log hay gì cả, và chỉ muốn xem agent cư xử thế nào khi gặp một người gọi thô lỗ và có ý đối đầu (rude and adversarial). Ta chỉ cần tạo một learning environment từ chính instruction đó.

$ relai learning-env create --prompt
    "A rude, adversarial multi-turn customer conversation. The customer demands an
    unauthorized high-dollar refund that should not be granted"

Lệnh này tạo ra một learning environment để mô phỏng và đánh giá agent. Phần simulator gồm persona, intent, tool mock hoặc tool thật. Learning environment cũng chứa các evaluator để định nghĩa thước đo thành công. Tất cả được sinh ra từ đúng một lệnh tương tác.

Sau đó chỉ việc mô phỏng agent trong learning environment này và xem nó cư xử ra sao. Soheil nói điểm số không cao lắm, tám mươi bảy phần trăm, và đặc biệt có hai evaluator cho điểm rất thấp. Đó là những thất bại quan sát được.

Làm sao cải thiện những thất bại đó? Gọi relai optimize với một số rollout nhất định. Mức cải thiện trung bình có thể khá cao: mười phần trăm trung bình chỉ với một vòng lặp, và điểm tăng từ tám mươi bảy lên chín mươi bảy phần trăm.

18. Từ một production log thật, và ba takeaway

Giờ xét trường hợp agent đã lên production. Bạn có một log, một agent session không như mong muốn, và có feedback. Ví dụ bạn có thể nói: "Keep fast eligible refunds, but do not generalize generosity beyond refund thresholds", tức cứ giữ việc hoàn tiền nhanh cho các trường hợp đủ điều kiện, nhưng đừng mở rộng sự hào phóng ra ngoài ngưỡng hoàn tiền. Đó là một feedback về hành vi của agent.

Luồng vẫn y như trước. Ta nâng nó thành một replayable learning environment, rồi gọi relai optimize để khắc phục vấn đề này, dùng feedback đó mà không tạo regression cho hành vi của agent trong các environment cũ. Và vì đây là lifelong, ta có thể tiếp tục làm như vậy để cải thiện agent mà không làm hỏng những gì đang chạy, và hiệu quả cộng dồn (compounding).

$ relai learning-env create \
    --log-file "log.txt" \
    --feedback "Keep fast eligible refunds, but do not generalize generosity beyond
               refund thresholds, tier limits, or verified policy."

Theo Soheil, đó là verifiable continual learning trong thực tế: mỗi bản cập nhật đều được test, mỗi mức cải thiện đều được đo, và không có gì đang chạy tốt bị hỏng trong quá trình tối ưu.

Đến đây là hết phần chính của talk. Soheil chốt lại ba takeaway:

1. Continual learning cho agent không nhất thiết là fine-tune model. Các cập nhật, và rất nhiều cập nhật hữu ích, có thể diễn ra ở harness layer và memory layer.
2. Production log không phải là learning environment. Cần biến chúng thành replayable learning environment để mô phỏng và đánh giá agent trên cùng những pattern và kịch bản đó.
3. Biên giới (frontier) hiện nay là continual improvement có ý thức về regression: khi sửa thất bại mới, phải kiểm chứng là không quên những cái cũ, không tạo regression.

Đó là verifiable continual learning, xây trên bốn nguyên tắc: replayability, holisticness, lifelongness và efficiency. Ai muốn thử VCL của RELAI và áp dụng cho agent của mình có thể dùng ngay hôm nay tại relai.ai. Soheil cảm ơn và kết thúc.