Trả lời ngắn: Reflection Loop là vòng agent đánh giá output theo rubric, đối chiếu evidence, ghi defect cụ thể, sửa đúng chỗ rồi kiểm tra phần thay đổi. Reflection chỉ đáng tin khi feedback có tiêu chí và bằng chứng. Nếu model tự chấm bằng cảm giác, vòng lặp có thể làm câu trả lời dài hơn nhưng vẫn sai.

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

  • Reflection khác retry và replan ở đâu.
  • Feedback tốt phải chứa tiêu chí, evidence và defect gì.
  • Cách trace hai vòng sửa một bản cập nhật sự cố giả.
  • Khi nào nên dừng, hỏi người hoặc bỏ reflection.

Lưu ý giáo dục: Reflection trong bài là critique summary có cấu trúc, không phải yêu cầu công khai private chain-of-thought. Ví dụ chỉ dùng log giả. Hệ thật cần giới hạn số vòng, token, quyền, memory và bước có side effect; self-score không thay kiểm thử hay người chịu trách nhiệm.

1. Reflection Loop là gì?

a. Thêm một trạm kiểm trước khi chốt

Bạn viết tin nhắn “API đã hỏng do database” sau khi chỉ nhìn thấy mã API_TIMEOUT. Câu nghe có vẻ hợp lý, nhưng log chưa chứng minh database là nguyên nhân. Nếu gửi luôn, một suy đoán đã biến thành sự thật trên giấy.

Reflection thêm trạm kiểm giữa bản nháp và kết quả cuối. Agent tạo draft, một evaluator chấm draft theo rubric, feedback chỉ ra defect cùng evidence, rồi agent revise và verify phần đã sửa. Rubric là bộ tiêu chí chấm có trước; evaluator là thành phần áp tiêu chí đó.

Hình 1 — Reflection tốt không quay quanh cảm giác của model; rubric và evidence là tâm của vòng.

b. Không phải cứ “tự nghĩ lại” là học

Trong nghiên cứu Reflexion, agent biến feedback thành phản hồi bằng ngôn ngữ, đưa vào episodic memory cho trial sau mà không cập nhật trọng số. Episodic memory là vùng nhớ bài học từ lần thử cụ thể.

Model không được huấn luyện lại và không tự đúng mãi mãi. Nếu feedback sai, memory cũng giữ bài học sai.

c. Reflection, retry và replan

Tiêu chí Retry Replan Reflection
Câu hỏi chính Chạy lại action được không? Đường đi tương lai có cần đổi? Output hiện tại sai ở đâu?
Trigger Lỗi tạm thời Assumption hoặc dependency đổi Draft chưa đạt rubric
Thay đổi Thường giữ action Sửa plan chưa chạy Sửa defect trong output/strategy
Evidence cần Error type, attempt Observation, state, plan version Criterion, evidence, delta

Ví dụ mạng chập chờn thì retry. Workshop hết chỗ thì replan sang candidate khác. Bản tóm tắt bỏ sót thời điểm thì reflection thêm đúng thời điểm và kiểm lại.

2. Một vòng reflection đáng tin cần gì?

a. Rubric phải tồn tại trước critique

Nếu evaluator chỉ nhận lệnh “hãy chê thật kỹ”, feedback dễ thành “chưa sâu”, “cần rõ hơn” hoặc “nên chuyên nghiệp hơn”. Những câu này không chỉ được dòng nào sai và sửa thế nào.

Rubric nên có các tiêu chí quan sát được. Với bản cập nhật sự cố giả, bốn tiêu chí có thể là:

  • Đủ fact: thời điểm, triệu chứng, phạm vi, bước tiếp theo.
  • Grounded: mỗi claim nguyên nhân phải có log hỗ trợ.
  • Actionable: có owner hoặc mốc cập nhật tiếp.
  • Concise: không lặp và không thêm chi tiết ngoài nguồn.

b. Feedback contract năm trường

Hình 2 — Critique Card biến lời chê thành một ticket sửa nhỏ, có bằng chứng và mức độ.

Mỗi feedback item nên có criterion, evidence, defect, fix và severity. Severity giúp ưu tiên lỗi blocking trước lỗi câu chữ. Nếu không có evidence, item phải ghi UNVERIFIED, không được bịa nguồn để lấp ô.

Ví dụ tốt: Grounded | API_TIMEOUT | claim “database hỏng” thiếu nguồn | ghi “root cause đang xác minh” | blocking. Ví dụ kém: Bài chưa hay.

c. Revision phải nhỏ và verify được

Revision delta là phần khác giữa draft trước và sau. Agent nên sửa defect đã nêu, không âm thầm thay goal, policy hoặc dữ liệu nguồn. Sau đó verifier chạy lại assertion liên quan.

Với claim database, assertion là: “Mọi câu nói về root cause có evidence ID không?” Nếu câu mới ghi “đang xác minh”, assertion pass vì nó không khẳng định nguyên nhân chưa biết. Việc draft nghe trôi chảy hơn không phải phép verify.

d. Nguồn feedback mạnh yếu khác nhau

Test, compiler, schema validator, dữ liệu môi trường và human review thường trực tiếp hơn self-critique. LLM evaluator hữu ích với ngôn ngữ, nhưng có thể thiên vị hoặc bỏ lỗi.

Nên ưu tiên external feedback khi có: test pass/fail, source coverage, policy check, diff và constraint. Self-evaluation chỉ là một grader, không phải tòa án cuối cùng.

3. Ví dụ hai vòng: sửa bản cập nhật sự cố

a. Dữ liệu đầu vào giả

Log demo có ba dòng:

  • 10:00 API_TIMEOUT /checkout
  • 10:03 retry_success 62%
  • 10:05 root_cause UNKNOWN

Goal: viết cập nhật tối đa 60 từ cho nhóm vận hành, không gửi thật. Draft v1: “Checkout gián đoạn vì database hỏng. Hệ thống đã ổn định. Đội kỹ thuật đang theo dõi.”

b. Vòng 1: evaluator tìm defect

Evaluator áp rubric và trả hai item blocking:

  1. Grounded: “database hỏng” không có evidence; log ghi UNKNOWN.
  2. Fact completeness: “đã ổn định” mâu thuẫn với retry success mới 62%.

Một item minor là thiếu thời điểm cập nhật tiếp. Feedback không yêu cầu viết lại toàn bộ. Nó khóa hai claim sai và một trường thiếu.

c. Revision v2

Draft v2: “Từ 10:00, checkout gặp timeout. Đến 10:03, 62% lượt retry thành công; dịch vụ chưa được xác nhận ổn định. Root cause đang được xác minh. Nhóm vận hành sẽ cập nhật lúc 10:20.”

Hình 3 — Delta tốt bỏ claim không có nguồn, giữ số từ log và thêm mốc cập nhật kiểm được.

d. Verify và quyết định dừng

Verifier kiểm bốn assertion: đủ timestamp, mọi số khớp log, không bịa root cause, có next update. Cả bốn pass; độ dài dưới 60 từ. Loop dừng ở accepted.

Nếu evaluator tiếp tục đề nghị “thêm cảm xúc” nhưng rubric không có tiêu chí đó, agent không nên sửa. Reflection phục vụ acceptance criteria, không chạy đến khi model hết ý kiến.

4. Lỗi phổ biến, guardrail và điều kiện dừng

a. Bốn kiểu reflection hỏng

  • Vague critique: feedback không có criterion, evidence hoặc dòng bị lỗi.
  • Self-confirmation: cùng model tạo draft rồi tự khen draft đúng.
  • Rewrite drift: revision thay luôn goal, scope hoặc fact đã đúng.
  • Loop polishing: nhiều vòng chỉ đổi từ đồng nghĩa, không tăng pass rate.

Một lỗi nguy hiểm khác là memory poisoning: đưa reflection chưa được verify vào memory dùng lâu dài. Lần sau agent có thể áp “bài học” sai cho nhiều task.

b. Guardrail tối thiểu

  • Rubric version và acceptance test được khóa trước vòng.
  • Evidence item có source ID; thiếu nguồn ghi UNVERIFIED.
  • Chỉ sửa phần failed; facts đã pass được bảo vệ.
  • Max revisions, token/time budget và similarity threshold rõ.
  • Memory write chỉ sau verifier hoặc human approval.
  • Side effect nhạy cảm không được reflection tự cấp quyền.

Guardrail bằng code xác định nên kiểm schema, budget, permission và stop state. Prompt chỉ giải thích hành vi; prompt không thay được access control.

c. Khi nào dừng hoặc hỏi người?

Dừng thành công khi mọi blocking criterion pass. Dừng thất bại khi hết budget, hai revision liên tiếp không tạo delta hữu ích, evaluator lặp cùng defect, hoặc feedback mâu thuẫn với policy.

Chuyển việc cho người khi thiếu dữ liệu chuẩn để đối chiếu, tiêu chí chấm mâu thuẫn hoặc hành động có hậu quả lớn. Theo hướng dẫn về agent của OpenAI, hệ thống cũng nên chuyển cho người khi số lần thất bại chạm ngưỡng đã đặt.

d. Khi nào không cần reflection?

Task một bước có validator xác định thường chỉ cần generate rồi validate. Câu trả lời nhỏ, chi phí thấp có thể sửa trực tiếp từ error. Reflection đáng dùng khi tiêu chí rõ, revision đo được và giá trị tăng lớn hơn độ trễ/token phát sinh.

5. Bài tập 15 phút: điền Critique Card

a. Chuẩn bị

Dùng ba log giả ở mục 3. Viết Draft v1 tối đa 60 từ. Không gửi thông báo thật, không dùng dữ liệu công ty hoặc thông tin cá nhân.

b. Tạo rubric và chấm

Viết bốn tiêu chí: fact completeness, grounded, actionable và concise. Với mỗi lỗi, điền criterion, evidence, defect, fix, severity. Item không có source phải gắn UNVERIFIED.

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

Trường Mẫu
Criterion Grounded
Evidence 10:05 root_cause UNKNOWN
Defect “database hỏng” là claim không có nguồn
Fix “root cause đang được xác minh”
Severity blocking
Verify Không còn claim nguyên nhân chắc chắn

d. Sửa và tự chấm

Tạo Draft v2, rồi trả lời:

  • Mỗi claim có source hoặc được ghi là chưa biết chưa?
  • Delta có sửa đúng failed criterion không?
  • Fact đã đúng có bị đổi ngoài ý muốn không?
  • Revision có thật sự tăng số assertion pass không?
  • Loop có stop state rõ không?

Nếu chỉ thay “hỏng” bằng “gặp vấn đề nghiêm trọng”, defect vẫn còn. Nếu thêm một root cause mới không có log, revision làm rủi ro lớn hơn.

6. Tổng kết: feedback phải tạo delta kiểm được

a. Năm ý chính

  • Reflection Loop chấm draft theo rubric, sửa defect rồi verify delta.
  • Feedback tốt có criterion, evidence, defect, fix và severity.
  • Retry chạy lại action; replan đổi đường đi; reflection sửa output hoặc strategy chưa đạt.
  • External feedback và validator mạnh hơn self-score khi có ground truth.
  • Loop phải có budget, no-progress detector, memory gate và human escalation.

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

  • Vì sao “hãy viết hay hơn” chưa phải feedback tốt?
  • Reflection khác retry và replan thế nào?
  • Draft v1 sai ở hai claim nào?
  • Khi nào reflection phải dừng dù output chưa hoàn hảo?

c. Gợi ý đáp án

Xem gợi ý câu 1Vì câu đó không nêu criterion, evidence, defect hay fix kiểm được. → Xem lại mục 2.
Xem gợi ý câu 2Retry chạy lại action; replan sửa đường đi tương lai; reflection chấm và sửa output/strategy theo rubric. → Xem lại mục 1.
Xem gợi ý câu 3“Database hỏng” không có evidence và “đã ổn định” mâu thuẫn với tỷ lệ retry 62%. → Xem lại mục 3.
Xem gợi ý câu 4Khi hết budget, không còn delta hữu ích, feedback lặp/mâu thuẫn, thiếu ground truth hoặc cần người chịu trách nhiệm. → Xem lại mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Reflection Loop Vòng chấm, góp ý, sửa và kiểm lại output.
Evaluator Thành phần áp rubric để tìm defect.
Rubric Bộ tiêu chí chấm có trước.
Evidence Dữ liệu hoặc nguồn hỗ trợ một nhận định.
Defect Điểm cụ thể không đạt criterion.
Revision delta Phần thay đổi giữa hai draft.
Verifier Phép kiểm revision đã đạt assertion.
External feedback Tín hiệu từ test, tool, môi trường hoặc người.
Episodic memory Bài học lưu từ một trial cụ thể.
Memory poisoning Lưu feedback sai khiến lần sau sai theo.

e. Nguồn tham khảo

f. Học tiếp gì?

Xem lại Planning Agent #34 nếu chưa rõ plan, state và replan. Bài tiếp theo là Self Correction #36: cách biến feedback đã verify thành hành động sửa có giới hạn, rollback và phép kiểm hoàn tất.

Nhắc lại giáo dục: Reflection không biến model thành nguồn sự thật. Rubric, evidence, verifier, guardrail và người chịu trách nhiệm mới quyết định một revision có đáng tin hay không.