Reflection Agent là gì? #16

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch.

Trả lời ngắn: Reflection Agent là agent dùng feedback có cấu trúc để tìm lỗi trong một artifact, sửa đúng phần có bằng chứng rồi kiểm lại kết quả. Nó không đơn thuần “nghĩ lâu hơn”: mỗi vòng cần tiêu chí, finding, evidence, phạm vi sửa, ngân sách và điều kiện chấp nhận hoặc dừng.

Đọc xong, bạn sẽ hiểu:

• Reflection Agent khác critic, verifier và supervisor ở đâu.
• Cách dựng vòng critique–revise có bằng chứng, ngân sách và điểm dừng.
• Cách sửa lỗi mà không biến phần chưa biết thành một câu trả lời nghe có vẻ chắc chắn.

1. Reflection Agent là gì, và khác “nghĩ lâu hơn” ở đâu?

Giả sử một agent vừa viết xong bản tóm tắt sự cố. Ta bảo nó: “Hãy suy nghĩ kỹ hơn và cải thiện bài.” Agent có thể đổi vài từ, thêm một câu tự tin hoặc làm văn bản trôi chảy hơn. Nhưng không ai biết bản mới đã sửa lỗi gì, dựa vào đâu và có thật sự đúng hơn không.

Một vòng reflection có kiểm soát phải cụ thể hơn. Critique là bản chỉ lỗi gắn với một tiêu chí và bằng chứng. Rubric là bảng tiêu chí dùng để chấm artifact, chẳng hạn: đã phủ đủ nguồn chưa, có giữ nguyên mâu thuẫn không, có vượt quá phạm vi dữ liệu không, và output có đúng schema không. Verifier là phép kiểm tạo tín hiệu quan sát được từ nguồn, tool hoặc test.

Ba thứ này chưa tự động tạo thành Reflection Agent. Critic có thể chỉ ra lỗi nhưng không sửa. Verifier có thể trả pass/fail nhưng không quyết định patch. Reflection Agent nhận những tín hiệu đó, tạo bản sửa và đưa bản mới trở lại phép kiểm.

Vai trò nên được tách rõ:

• Generator tạo draft đầu tiên.
• Critic ghi finding: tiêu chí nào fail, lỗi nằm ở đâu và evidence nào chứng minh.
• Reflection Agent sửa artifact trong phạm vi finding.
• Verifier chạy lại rubric, source check hoặc test.
• Supervisor quyết định có được chạy thêm vòng, dừng hay chuyển người.

Một model có thể đảm nhiệm nhiều vai, nhưng record trách nhiệm phải tách. Hãy hình dung biên tập viên khoanh câu sai, ghi nguồn và yêu cầu sửa đúng đoạn, thay vì chỉ bảo người viết “cố gắng hơn”.

Hình 1 — Critic chỉ ra lỗi, Reflection Agent sửa artifact, verifier kiểm và supervisor giữ quyền dừng.

2. Loop critique–revise–verify hoạt động thế nào?

Một reflection round là một vòng gồm evaluate, critique, patch và re-verify. Patch nghĩa là sửa cục bộ đúng finding đã xác nhận, giống thợ điện sửa đúng ổ cắm hỏng thay vì tự thay toàn bộ dây trong nhà.

Loop có thể viết ngắn như sau:

DRAFT → EVALUATE → CRITIQUE → PATCH → RE-VERIFY

Sau re-verify chỉ có ba hướng hợp lệ:

1. Pass: các tiêu chí bắt buộc đều đạt; artifact được chấp nhận.
2. Next round: còn finding có thể sửa, có evidence và vẫn còn ngân sách.
3. Stop/handoff: thiếu evidence, hết ngân sách, cùng lỗi lặp lại hoặc cần quyền của con người.

Critique record nên có năm trường:

Evidence phải tồn tại độc lập với critique. Test output hoặc source map là evidence; câu “đoạn này có vẻ thiếu thuyết phục” mới chỉ là nhận xét.

Loop cũng cần round budget. Trong bài này, ngân sách là tối đa 2 vòng và no-progress cap là 1. No-progress nghĩa là vòng mới không tạo thay đổi có thể kiểm chứng: cùng finding, cùng evidence và cùng trạng thái vẫn lặp lại. Khi chạm cap, hệ thống dừng hoặc handoff; nó không tiếp tục viết lại cho đến khi vô tình nhận được pass.

Giới hạn ngăn reflection tốn token, thời gian và làm artifact trôi khỏi yêu cầu. Mỗi vòng phải chứng minh delta quan sát được.

Hình 2 — Mỗi vòng phải có criterion, evidence, fix scope và ngân sách; không có evidence mới thì không tạo claim mới.

Reflexion dùng phản hồi bằng lời và bộ nhớ theo lần làm, không cập nhật trọng số model. Self-Refine nghiên cứu vòng tự tạo feedback rồi tinh chỉnh output. CRITIC nhấn mạnh phản hồi từ công cụ. Đây là pattern nghiên cứu, không phải bảo đảm production.

3. Case D0 → D1: sửa ba lỗi mà không bịa phần thiếu

Ta có bốn mẩu dữ liệu giả:

• L1: alert hệ thống xuất hiện lúc 09:02.
• T1: ticket đầu tiên được ghi nhận lúc 09:05.
• L2: service phục hồi lúc 09:07.
• M2: có metric impact nhưng trường scope bị thiếu.

Draft D0 viết: “Sự cố bắt đầu lúc 09:05, ảnh hưởng 2.000 người dùng và phục hồi lúc 09:07.” Câu này fail ba chỗ.

Rubric của chúng ta có bốn tiêu chí:

• Source coverage: mọi timestamp và con số phải có source ID.
• Conflict preservation: hai nguồn nói về hai mốc khác nhau phải được giữ riêng.
• Scope safety: không được mở rộng phạm vi vượt dữ liệu.
• Output schema: mỗi claim cần fact, source và trạng thái xác minh.

Evaluator ghi: D0 bỏ 09:02 và L1; dùng 09:05 làm lúc sự cố bắt đầu dù T1 chỉ là lúc ghi ticket; và nêu “2.000 người dùng” khi M2 thiếu scope.

Reflection Agent không được tự tìm cách “làm cho câu hợp lý”. Nó nhận ba localized patches:

D1 trở thành: “Alert hệ thống xuất hiện lúc 09:02 [L1]; ticket đầu tiên được ghi lúc 09:05 [T1]. Service phục hồi lúc 09:07 [L2]. Phạm vi impact chưa xác minh vì M2 thiếu trường scope.”

Re-verify cho thấy source coverage đạt, hai mốc được giữ, scope không bị bịa và schema đầy đủ. Trạng thái là accepted_with_unknown: artifact được nhận nhưng phần chưa biết vẫn hiển thị.

Hình 3 — D1 sửa lỗi có bằng chứng nhưng giữ impact chưa xác minh, nên được nhận với phần unknown.

Case này cho thấy reflection không nhất thiết làm câu trả lời đầy đủ hơn. Đôi khi kết quả tốt hơn vì nó bớt một claim. Nguyên tắc cần nhớ là: không có evidence mới thì không có claim mới.

4. Sai lầm, giới hạn và rủi ro tự xác nhận

Sai lầm đầu tiên là dùng cùng lời tự nhận xét làm finding lẫn evidence. Đây là self-confirmation. Source check, tool output hoặc test độc lập mạnh hơn.

Sai lầm thứ hai là cho agent sửa cả requirement. Nếu tiêu chí ban đầu yêu cầu mọi con số có nguồn, agent không được đổi tiêu chí thành “con số hợp lý theo ngữ cảnh” để tự tạo pass. Requirement và success criteria nên nằm ngoài phạm vi patch.

Sai lầm thứ ba là không có điểm dừng. Mỗi vòng cần delta: finding nào đổi trạng thái, test nào từ fail thành pass. Cùng lỗi lặp lại mà không có evidence mới thì handoff.

Sai lầm thứ tư là lưu toàn bộ lời tự sự như memory. Episodic memory chỉ cần record quan sát được: error_class=missing_citation, fix=attach_source_id, result=pass; không cần chuỗi suy nghĩ riêng tư.

Reflection có giới hạn. Nếu nguồn đầu vào sai, rubric thiếu tiêu chí, tool hỏng hoặc verifier quá yếu, agent có thể sửa rất chăm chỉ nhưng vẫn sai. Nó cũng không thay thế human review trong quyết định rủi ro cao. Khi thiếu quyền, thiếu dữ liệu hoặc gặp xung đột policy, “dừng và chuyển người” là một kết quả đúng.

Không phải task nào cũng cần reflection. Phép biến đổi deterministic đã có validator và test có thể chỉ cần chạy code rồi báo lỗi.

5. Checklist và bài tập 15 phút

Trước khi bật reflection, hãy kiểm tra:

• Artifact đầu vào có version rõ ràng không?
• Rubric có tiêu chí pass/fail quan sát được không?
• Mỗi finding có evidence độc lập không?
• Agent chỉ được sửa trong fix scope nào?
• Max rounds và no-progress cap là bao nhiêu?
• Requirement, source facts và approval gate có nằm ngoài quyền sửa không?
• Khi nào phải human handoff?
• Record cuối có lưu finding, evidence, patch và result không?

Bài tập dùng spreadsheet hoặc document miễn phí, không gọi API hay agent thật. Dùng D0 ở mục 3.

Trong 3 phút đầu, chép D0 và bốn tiêu chí rubric. Ba phút tiếp theo, đối chiếu từng claim với L1, T1, L2 và M2. Sau đó ghi ba critique records với đủ criterion, finding, evidence, fix scope và severity.

Ba phút kế tiếp, tạo D1 bằng ba patches. Ba phút cuối, re-verify, ghi round 1/2, no-progress 0/1 và accepted_with_unknown.

Mẫu đối chiếu đã điền

Chỉ mở vòng hai khi có finding và evidence mới. Đây là dữ liệu giả; không dùng tiền thật.

6. Tổng kết và bài học tiếp theo

Năm ý chính

• Reflection Agent sửa artifact dựa trên feedback có cấu trúc; nó không chỉ “nghĩ lâu hơn”.
• Critique phải trỏ tới criterion, finding và evidence độc lập.
• Patch nên cục bộ; requirement và source facts không nằm trong quyền sửa.
• Max rounds, no-progress và handoff ngăn loop vô hạn.
• Một kết quả tốt có thể là accepted_with_unknown, không phải câu trả lời đầy đủ giả tạo.

Câu hỏi tự kiểm tra

• Vì sao lời “tôi thấy bản mới đúng hơn” chưa phải evidence?
• Khi nào reflection loop phải stop/handoff?
• Vì sao D1 không được điền lại con số impact?

Gợi ý đáp án

Xem gợi ý câu 1

Vì đó là nhận xét của chính agent; cần source, tool result, test hoặc tín hiệu quan sát độc lập. Xem mục 1–2.

Xem gợi ý câu 2

Khi hết round budget, chạm no-progress, thiếu evidence/quyền hoặc cần quyết định rủi ro cao. Xem mục 2 và 4.

Xem gợi ý câu 3

Vì M2 thiếu scope; không có evidence mới thì không được tạo claim mới. Xem mục 3.

Thuật ngữ cần nhớ

Bài trước, Supervisor Agent #15, giải thích ai giữ state, budget và quyền dừng. Bài tiếp theo, Tool Agent #17, sẽ đi vào cách agent chọn và gọi công cụ trong ranh giới quyền hạn.

Nguồn tham khảo

• Reflexion: Language Agents with Verbal Reinforcement Learning
• Self-Refine: Iterative Refinement with Self-Feedback
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing

Nội dung này phục vụ mục đích giáo dục, không phải lời khuyên đầu tư hoặc tín hiệu giao dịch. Mọi thị trường đều có rủi ro mất vốn.