Trả lời ngắn: Self Correction là quá trình agent nhận lỗi có bằng chứng, khoanh đúng phạm vi, lưu checkpoint, sửa tối thiểu rồi kiểm tra lại. Bản sửa chỉ được nhận khi lỗi cũ đã hết và phần từng đúng vẫn đúng. Nếu thiếu ground truth, hết budget hoặc repair gây regression, agent phải rollback hay hỏi người.

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

  • Self Correction khác reflection, retry và replan ở đâu.
  • Một Correction Ticket cần những trường nào.
  • Cách sửa payload lỗi qua hai attempt mà không sửa lan.
  • Khi nào phải accept, rollback, dừng hoặc hỏi người.

Lưu ý giáo dục: Ví dụ trong bài chỉ dùng JSON và validator giả, không gọi API hay sửa dữ liệu thật. Self-correction không bảo đảm AI đúng và không tự cấp thêm quyền. Hệ production cần validation bằng code, giới hạn attempt, checkpoint có thể phục hồi và human approval cho hành động nhạy cảm.

1. Self Correction là gì?

a. Từ “biết lỗi” đến “sửa lỗi” là hai việc khác nhau

Ở bài trước, Reflection Loop tạo feedback: tiêu chí nào fail, evidence nào chứng minh và defect nằm ở đâu. Nhưng một Critique Card tốt chưa tự biến output thành đúng. Agent còn phải chọn thao tác sửa, bảo vệ phần đã pass, chạy lại phép kiểm và quyết định giữ hay bỏ bản mới.

Đó là Self Correction: phát hiện lỗi, khóa phạm vi, lưu trạng thái, tạo patch, verify rồi accept hoặc rollback. Rollback nghĩa là quay lại checkpoint nếu bản sửa gây hỏng thêm.

Hình 1 — Correction đáng tin có đường quay lại, không chỉ có mũi tên “thử lần nữa”.

b. Model không tự cập nhật trọng số sau mỗi lần sửa

SELF-REFINE cho thấy output có thể được cải thiện qua feedback và refinement mà không cần huấn luyện thêm. Model không vì thế mà học vĩnh viễn; memory lâu dài vẫn cần gate kiểm chứng.

c. Reflection, retry, replan và correction

Cơ chế Trigger Thay đổi chính Phép kiểm
Retry Lỗi tạm thời, action có thể chạy lại Thử lại cùng action Error có biến mất không?
Replan Đường đi hoặc dependency không còn đúng Đổi bước tương lai Plan mới còn đạt goal không?
Reflection Output không đạt rubric Tạo feedback có evidence Defect được mô tả đúng chưa?
Correction Có defect đủ điều kiện sửa Tạo patch trong scope Lỗi cũ hết và không regression?

Ví dụ request bị 429 có thể retry theo backoff. Endpoint bị ngừng thì replan sang nguồn khác. Bản tóm tắt bịa số cần reflection để tìm claim sai, rồi correction mới xóa claim đó và chạy source check lại.

2. Correction contract gồm những gì?

a. Error Packet phải đủ để hành động

Agent không nên sửa từ câu “output có vẻ chưa ổn”. Nó cần Error Packet: failed check, expected, actual, evidence ID và error type. Error type giúp phân biệt lỗi tạm thời, lỗi dữ liệu, lỗi schema, vi phạm policy hay thiếu ground truth.

Nếu schema validator trả price: expected number, received string, evidence đủ cụ thể để sửa kiểu dữ liệu. Nếu evaluator chỉ nói “giá nhìn lạ”, agent chưa được tự đoán giá đúng là bao nhiêu.

b. Correction Ticket sáu trường

Hình 2 — Ticket biến feedback đã verify thành một patch có ranh giới và tiêu chí hoàn tất.

Ticket gồm:

  • Failed check: assertion nào không đạt.
  • Evidence: tool, test hoặc nguồn nào chứng minh.
  • Scope: field, đoạn hay bước nào được phép đổi.
  • Repair: patch dự kiến, ưu tiên nhỏ nhất.
  • Postcondition: điều kiện phải đúng sau sửa.
  • Unchanged assertions: phần đã đúng phải giữ nguyên.

Nếu sửa price nhưng làm mất sku, lỗi schema ban đầu hết mà payload vẫn tệ hơn.

c. Checkpoint và correction scope

Checkpoint là snapshot có thể phục hồi: Draft v1, file trước patch, transaction chưa commit hoặc version dữ liệu. Correction scope giới hạn vùng được đổi. Với output văn bản, scope có thể là một claim. Với JSON, scope là một field. Với code, scope có thể là hàm gây test fail.

Patch càng rộng, xác suất regression càng lớn và càng khó biết thay đổi nào tạo kết quả. “Viết lại toàn bộ” chỉ hợp lý khi defect mang tính cấu trúc và ticket ghi rõ lý do.

d. Postcondition không chỉ chạy lại test cũ

Agent phải chạy failed assertion cũ, unchanged assertions và safety constraints, rồi so delta với scope. Chỉ chạy một test có thể bỏ qua lỗi mới.

3. Ví dụ hai attempt: sửa payload sản phẩm

a. Dữ liệu nguồn giả

Nguồn demo ghi: sku=PEN-01, name=Bút mực xanh, price=199000, stock=12. Không có chứng nhận “thân thiện môi trường”. Goal là tạo JSON hợp schema, không gửi tới hệ thống nào.

Attempt 1 có bốn field:

  • sku: PEN-01
  • name: Bút mực xanh thân thiện môi trường
  • price: chuỗi "199000"
  • stock: số 12

Schema fail vì price là chuỗi. Source check cũng fail vì cụm “thân thiện môi trường” không có evidence.

b. Tạo hai Correction Ticket

Ticket A ghi: failed check=price_type, evidence=validator E_PRICE_TYPE, scope=/price, repair=string→number, postcondition=price là số dương. Ticket B ghi: failed check=source_coverage, evidence=source chỉ có name Bút mực xanh, scope=/name, repair=bỏ claim không nguồn, postcondition=name khớp source.

Unchanged assertions của cả hai là sku và stock không đổi. Agent lưu Attempt 1 làm checkpoint rồi mới patch.

c. Attempt 2 và verify

Attempt 2 giữ sku=PEN-01, stock=12, đổi name về Bút mực xanh và đổi price thành số 199000.

Hình 3 — Verify kiểm lỗi cũ, phần không được đổi và budget trước khi chọn nhánh tiếp theo.

Verifier chạy schema, source coverage và diff scope. Hai failed checks chuyển sang pass; sku, stock giữ nguyên; chỉ /price và /name thay đổi. Kết quả được accepted.

d. Nếu nguồn không có giá đúng thì sao?

Giả sử source chỉ ghi price=UNKNOWN. Agent không được biến chuỗi "199000" thành số chỉ vì thao tác đó làm schema pass. Schema cho biết kiểu mong đợi, không chứng minh giá trị đúng. Ticket phải chuyển thành blocked_missing_ground_truth và hỏi người hoặc nguồn có thẩm quyền.

Đây là ranh giới giữa sửa định dạng và bịa dữ liệu. Một validator pass chưa đủ chứng minh nội dung đúng.

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

a. Năm kiểu correction hỏng

  • Blind retry: tạo lại toàn bộ output nhưng không mang error evidence vào attempt mới.
  • Over-correction: sửa cả những field đã pass.
  • Validator gaming: xóa nội dung khó để test xanh nhưng làm mất goal.
  • Oscillation: attempt chẵn sửa lỗi A gây lỗi B, attempt lẻ sửa B làm A quay lại.
  • Silent side effect: tự ghi database hoặc gửi thông báo trước khi verify.

Một lỗi khác là lấy self-score làm ground truth. Cùng model có thể lặp lại assumption ban đầu và xác nhận chính nó.

b. Accept hay rollback?

Chỉ nhận bản sửa khi lỗi ban đầu đã hết, phần không liên quan giữ nguyên và kiểm tra an toàn đạt. Nếu bản sửa làm hỏng phần cũ hoặc vượt phạm vi, hãy hoàn tác. Cũng cần hoàn tác khi dữ liệu kiểm tra thay đổi giữa chừng hoặc kết quả mới không thể giải thích bằng yêu cầu ban đầu.

Rollback đưa hệ về trạng thái biết rõ và ngăn bản “có vẻ tốt hơn” lan sang bước sau.

c. Correction budget và no-progress detector

Đặt max_attempts, token/time budget và số lần được gọi tool. Theo dõi fingerprint của error. Nếu cùng error lặp hai lần mà delta gần như không đổi, đó là no progress. Nếu error A/B đổi qua lại, đó là oscillation. Cả hai nên dừng trước khi agent đốt thêm chi phí.

d. Khi nào phải hỏi người?

Escalate khi thiếu ground truth, policy xung đột, action khó rollback, quyền cần mở rộng hoặc quyết định mang trách nhiệm pháp lý/tài chính. Hướng dẫn agent của OpenAI xem failure threshold và hành động nhạy cảm là các điểm tự nhiên để human intervention.

Guardrail bằng code phải giữ permission, schema, idempotency và transaction. Prompt không thể thay access control hay backup.

5. Bài tập 15 phút: điền Correction Ticket

a. Chuẩn bị payload giả

Dùng payload Attempt 1 ở mục 3. Copy vào file nháp riêng. Không gọi API, không dùng dữ liệu khách hàng và không ghi đè file quan trọng.

b. Mẫu đối chiếu: điền ticket trước khi sửa

Trường Mẫu đã điền
Failed check price_type
Evidence E_PRICE_TYPE: expected number, received string
Scope Chỉ /price
Repair "199000" → 199000
Postcondition price là số dương
Unchanged sku, name, stock giữ nguyên

Tạo thêm ticket cho claim “thân thiện môi trường”. Nếu không tìm thấy evidence, repair là bỏ claim, không phải tự viết một chứng nhận mới.

c. Lưu checkpoint, patch và verify

Giữ Attempt 1, tạo Attempt 2. So diff và đánh dấu từng assertion:

  • Schema pass chưa?
  • Mọi claim có source chưa?
  • Delta có nằm đúng hai scope không?
  • sku và stock có giữ nguyên không?
  • Có side effect nào đã chạy trước verify không?

d. Tự chấm quyết định cuối

Nếu cả năm câu đều đạt, ghi accepted. Nếu field ngoài scope đổi, ghi rolled_back. Nếu nguồn thiếu giá thật, ghi blocked_missing_ground_truth. Đừng ghi fixed chỉ vì JSON parse được; đó là rủi ro validator gaming.

6. Tổng kết: sửa ít, kiểm đủ, quay lại được

a. Năm ý chính

  • Self Correction biến defect đã có evidence thành repair có giới hạn.
  • Correction Ticket cần failed check, evidence, scope, repair, postcondition và unchanged assertions.
  • Checkpoint cho phép rollback khi patch gây regression hoặc vượt scope.
  • Validator pass không chứng minh dữ liệu đúng nếu ground truth còn thiếu.
  • Loop phải có attempt budget, no-progress detector, safety gate và human escalation.

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

  • Reflection khác Self Correction ở bước nào?
  • Vì sao unchanged assertions cần được kiểm lại?
  • Khi nào đổi "199000" thành 199000 vẫn là sai?
  • Dấu hiệu nào cho biết correction loop phải dừng?

c. Gợi ý đáp án

Xem gợi ý câu 1Reflection tạo feedback có evidence; correction thực thi patch, verify và quyết định accept hay rollback. → Xem lại mục 1.
Xem gợi ý câu 2Vì patch có thể sửa lỗi cũ nhưng làm hỏng phần từng đúng; đó là regression. → Xem lại mục 2.
Xem gợi ý câu 3Khi nguồn không xác nhận giá trị 199000; schema chỉ xác nhận kiểu, không xác nhận sự thật. → Xem lại mục 3.
Xem gợi ý câu 4Khi hết budget, không tiến triển, lỗi dao động, thiếu ground truth, patch vượt scope hoặc action 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
Self Correction Quá trình sửa defect rồi kiểm lại kết quả.
Error Packet Gói lỗi gồm expected, actual, evidence và loại lỗi.
Correction Ticket Hợp đồng mô tả phạm vi và tiêu chí của repair.
Repair Thao tác sửa cụ thể.
Correction scope Vùng duy nhất được phép thay đổi.
Checkpoint Trạng thái có thể quay lại trước khi sửa.
Postcondition Điều kiện phải đúng sau repair.
Regression Lỗi mới làm phần từng đúng trở thành sai.
Rollback Khôi phục checkpoint sau repair không đạt.
Correction budget Giới hạn attempt, token, thời gian hoặc tool call.

e. Nguồn tham khảo

f. Học tiếp gì?

Xem lại Reflection Loop #35 nếu chưa rõ cách tạo feedback có rubric và evidence. Bài tiếp theo là Task Decomposition #37: cách tách một goal lớn thành các subtask có dependency, output contract và acceptance test.

Nhắc lại giáo dục: Self Correction đáng tin nhờ evidence, phạm vi, checkpoint và verifier — không nhờ model tự tin rằng nó đã sửa đúng. Với dữ liệu thiếu hoặc hành động khó hoàn tác, dừng và hỏi người là một kết quả đúng.