Nội dung này phục vụ mục đích giáo dục. Không đưa dữ liệu nhạy cảm hoặc quyền hành động thật vào một vòng AI chưa được kiểm soát.

Trả lời ngắn: Recursive Prompting là cách đưa output hoặc trạng thái của vòng trước vào prompt vòng sau để sửa, chia nhỏ hoặc tiếp tục một tác vụ. Một loop đúng nghĩa cần mục tiêu giữ ổn định, phản hồi có cấu trúc và điều kiện dừng; hỏi tiếp tùy hứng trong đoạn chat dài chưa đủ để gọi là recursive.

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

  • Ba thành phần phân biệt Recursive Prompting với việc hỏi tiếp bình thường.
  • Cách một loop chuyển từ state hiện tại sang bản mới, rồi dừng hoặc quay lại.
  • Vì sao nhiều vòng có thể làm lỗi lớn hơn và cách đặt giới hạn trước khi chạy.

1. Recursive Prompting là gì, và “hỏi tiếp” có đủ không?

a. Một vòng phải mang trạng thái đi tiếp

Giả sử bạn yêu cầu AI tạo agenda họp. Bản đầu thiếu người phụ trách. Bạn chỉ ra lỗi đó, đưa lại agenda hiện tại và yêu cầu sửa nhưng giữ nguyên thời lượng. Bản mới trở thành đầu vào cho vòng kế tiếp.

Phần được mang sang gọi là state, tức trạng thái tối thiểu của công việc: mục tiêu, bản hiện tại, lỗi đã biết, việc còn thiếu và giới hạn vẫn phải giữ.

Mỗi lượt tạo → chấm → quyết định là một iteration, hay một vòng. Vòng kế tiếp không bắt đầu từ số 0; nó nhận state đã cập nhật.

b. Ba thành phần bắt buộc

Một loop recursive có kiểm soát cần:

  1. Mục tiêu hoặc contract ổn định: thế nào là output đúng.
  2. Feedback có cấu trúc: lỗi nào quan sát được, tiêu chí nào chưa đạt.
  3. Stop condition: điều kiện dừng, chẳng hạn đạt 4/4 hoặc hết hai vòng.

“Viết hay hơn đi” thiếu contract và điểm dừng. Microsoft Prompt Engineering Labs minh họa recursive prompting bằng follow-up nối tiếp để mở rộng và định dạng output. Microsoft Prompt Labs

Ở đây, vòng sau phải nhận state hoặc output trước có chủ đích, rồi quyết định theo tiêu chí.

c. Recursive không có nghĩa là càng lặp càng đúng

Feedback sai khiến vòng sau sửa thứ không hỏng. State thiếu hoặc model tự viết–tự chấm cũng làm kết quả lệch.

Kết quả chỉ có thể tốt hơn khi feedback đúng, state đủ và bộ chấm đáng tin.

2. Một vòng Recursive Prompting chạy qua những trạng thái nào?

Hình 1 — Một vòng recursive chỉ có kiểm soát khi mục tiêu giữ nguyên, state được cập nhật và nhánh quay lại có điểm dừng.

a. Flow sáu bước

Một flow dễ dùng:

  1. Khóa contract: mục tiêu, format, ràng buộc và rubric.
  2. Tạo State n: bản hiện tại cộng dữ kiện cần giữ.
  3. Generate: tạo phiên bản ứng viên.
  4. Evaluate: chấm theo rubric.
  5. Decide: đạt thì dừng; chưa đạt thì revise hoặc decompose.
  6. Tạo State n+1: chỉ mang phần cần thiết sang vòng mới.

Evaluator là người, rule hoặc model thực hiện việc chấm. Feedback nên nói “thiếu owner ở mục 2” thay vì “chưa chuyên nghiệp”.

Một state gọn cho agenda có thể là:

Mục tiêu: agenda 30 phút cho 4 người
Bắt buộc: mục tiêu, 3 chủ đề, thời lượng, owner
Bản hiện tại: v0
Lỗi: thiếu owner; tổng thời lượng 35 phút
Việc vòng sau: sửa hai lỗi, không thêm chủ đề
Số vòng còn lại: 2

Nó giống phiếu bàn giao ca: giữ việc đã có, lỗi và giới hạn, không chép cả cuộc chat.

b. Chấm bằng dữ kiện, không bằng cảm giác

Với rubric bốn tiêu chí, mỗi tiêu chí được 0 hoặc 1:

Tiêu chí Đạt khi
Mục tiêu Có một câu nêu kết quả cuộc họp
Cấu trúc Có đúng ba chủ đề
Thời lượng Tổng bằng 30 phút
Owner Mỗi chủ đề có người phụ trách giả

V0 đạt 2/4. Feedback chỉ nêu hai lỗi. V1 đạt 3/4 vì đã có owner nhưng tổng vẫn là 32 phút. V2 đạt 4/4 và dừng.

Nếu v2 lại kém hơn, cần rollback: quay về checkpoint tốt nhất thay vì tiếp tục sửa trên bản tệ. “Bản mới nhất” và “bản tốt nhất” không luôn là một.

c. Điểm dừng là một nhánh thật

Stop condition không phải câu “hãy dừng nếu thấy ổn”. Nó phải kiểm được:

  • đạt toàn bộ tiêu chí bắt buộc;
  • hết max_rounds;
  • hết ngân sách lượt gọi;
  • hai vòng liên tiếp không tăng điểm;
  • evaluator không đủ chắc chắn và cần người duyệt.

Đặt điểm dừng trước khi chạy để giữ state và chi phí trong tầm kiểm soát.

3. Ba pattern recursive và lỗi dễ khuếch đại

Hình 2 — Ba pattern cùng dùng kết quả trước cho bước sau, nhưng khác ở thứ được mang qua vòng và cách quay về mục tiêu cha.

a. Critique → revise

Model tạo bản nháp, evaluator tìm lỗi theo rubric, rồi model sửa đúng lỗi đó. Đây là pattern agenda ở mục 2.

Nó hợp với tài liệu có tiêu chí rõ. Rủi ro lớn nhất là critique mơ hồ hoặc sai. Yêu cầu bằng chứng quan sát được và chạy lại toàn bộ rubric sau khi sửa.

b. Decompose → solve child → return

Một task cha được chia thành task con. Ví dụ, bộ FAQ hỗn hợp được tách thành billing, login và delivery. Mỗi nhóm được xử lý riêng, rồi kết quả quay về task cha để ghép và kiểm trùng.

Đây mới gần nghĩa “recursive” trong khoa học máy tính: cùng một kiểu xử lý có thể áp dụng tiếp cho child quá lớn. Cần max depth, tức độ sâu tối đa. Nếu không, task con lại sinh task cháu mãi.

Maieutic Prompting là một phương pháp nghiên cứu riêng dùng cây giải thích đệ quy rồi suy luận trên quan hệ logic giữa chúng. Nó không phải tên khác của mọi loop sửa tài liệu. Jung và cộng sự, 2022

c. Plan → execute one step → update

Loop giữ mục tiêu lớn và danh sách việc còn lại. Nó chạy một bước, ghi kết quả, rồi cập nhật plan trước khi đi tiếp.

ReCAP nghiên cứu kiểu plan-ahead, thực hiện subtask đầu và đưa parent plan trở lại context khi xử lý phân cấp. Tác giả cũng giới hạn active prompt để kiểm soát chi phí theo độ sâu. ReCAP, 2025

Re3 dùng plan tổng cùng current story state để sinh từng đoạn truyện dài, sau đó rerank và revise theo tính nhất quán. Đây là ví dụ cho thấy state phải giữ cả mục tiêu toàn cục lẫn phần vừa tạo. Re3, 2022

d. Bốn lỗi cần chặn

  1. Context drift: mục tiêu hoặc chi tiết trôi qua nhiều lần tóm tắt.
  2. Error amplification: lỗi cũ được dùng làm nền, khiến lỗi sau lớn hơn.
  3. Loop vô hạn: không có max rounds/depth hoặc ngưỡng đạt không thể đo.
  4. Tự tạo, tự chấm: evaluator lặp thiên lệch của generator.

Giống trò truyền tin, mỗi lần chuyển có thể mất một chi tiết. Cách phòng là giữ contract cố định, state có schema, checkpoint tốt nhất và người duyệt ở nhánh rủi ro.

4. Checklist thiết kế loop không chạy vô hạn

Hình 3 — Hết budget hoặc số vòng là điều kiện dừng thật, không phải lời gợi ý để mô hình tự bỏ qua.

Trước khi chạy, điền đủ:

  1. Goal/contract không đổi là gì?
  2. State mỗi vòng gồm field nào?
  3. Feedback phải kèm bằng chứng nào?
  4. Ai hoặc rule nào là evaluator?
  5. Điểm đạt tối thiểu bao nhiêu?
  6. max_rounds và max_depth là bao nhiêu?
  7. Budget lượt gọi/token/thời gian là bao nhiêu?
  8. Checkpoint tốt nhất lưu ở đâu?
  9. Hành động nào bắt buộc human gate?
  10. Log nào giúp truy lại mỗi vòng?

Không nên dùng loop khi tác vụ một lần có thể giải bằng prompt rõ ràng, không có cách chấm, dữ liệu nhạy cảm chưa được bảo vệ hoặc output có quyền gửi/ghi/chạy tool mà chưa có approval.

Vòng tự động cần quyền tối thiểu. Đừng để một evaluator nói “đạt” là đủ để tự gửi email, sửa database hoặc chạy code production.

5. Bài tập 15 phút: sửa agenda qua tối đa hai vòng

a. Chuẩn bị

Dùng tài liệu hoặc bảng tính miễn phí và chatbot đang có. Tạo dữ liệu giả: nhóm An, Bình, Chi, Dũng; cuộc họp 30 phút; ba chủ đề Tiến độ, Blocker, Việc tiếp theo.

  • 3 phút: viết rubric bốn tiêu chí.
  • 4 phút: tạo v0.
  • 3 phút: chấm và ghi lỗi quan sát được.
  • 3 phút: sửa v1; nếu chưa đạt thì dùng đúng một vòng v2.
  • 2 phút: lưu bản tốt nhất và lý do dừng.

Không dùng lịch, tên, email hoặc nội dung họp thật. Không kích hoạt gửi lời mời.

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

Bản Điểm Lỗi quan sát được Quyết định
v0 2/4 Thiếu owner, tổng 35 phút Sửa
v1 3/4 Có owner, tổng còn 32 phút Sửa lần cuối
v2 4/4 Không lỗi bắt buộc Dừng và lưu

Kết quả mong đợi không phải agenda “hay nhất”. Bạn cần thấy state thay đổi có kiểm soát, feedback bám rubric và loop dừng đúng trần hai vòng.

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

a. Năm ý chính

  • Recursive prompting đưa output hoặc state vòng trước vào prompt vòng sau.
  • Loop có kiểm soát cần contract, feedback, evaluator và stop condition.
  • Ba pattern chính là critique–revise, decompose–return và plan–execute–update.
  • Nhiều vòng có thể gây context drift, error amplification và chi phí tăng.
  • Max rounds, checkpoint, rollback và human gate phải được đặt trước khi tự động hóa.

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

  • Vì sao hỏi tiếp trong chat chưa chắc là Recursive Prompting có kiểm soát?
  • State nên chứa gì?
  • Khi nào phải rollback?
  • Vì sao max rounds phải được đặt trước?

c. Gợi ý đáp án

Xem gợi ý câu 1

Loop cần mang state có chủ đích, chấm theo tiêu chí và có điểm dừng; follow-up tùy hứng thiếu các phần này. Xem lại mục 1.

Xem gợi ý câu 2

State giữ mục tiêu, bản hiện tại, lỗi, việc còn lại và giới hạn cần thiết cho vòng sau. Xem lại mục 2.

Xem gợi ý câu 3

Khi bản mới có điểm thấp hơn hoặc làm hỏng tiêu chí đã đạt, quay về checkpoint tốt nhất. Xem lại mục 2.

Xem gợi ý câu 4

Trần vòng là nhánh dừng máy kiểm được, ngăn loop kéo dài dù evaluator không đạt ngưỡng. Xem lại mục 4.

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

Thuật ngữ Giải thích ngắn
Recursive prompting Dùng state hoặc output trước cho prompt sau.
State Dữ liệu tối thiểu mô tả tình hình hiện tại.
Iteration Một lượt tạo, chấm và quyết định.
Feedback Lỗi hoặc khoảng cách đo được so với tiêu chí.
Evaluator Người, rule hoặc model thực hiện chấm.
Stop condition Quy tắc kiểm được để dừng loop.
Max depth Giới hạn tầng task con.
Context drift Mục tiêu hoặc chi tiết trôi qua nhiều vòng.
Rollback Quay về phiên bản tốt đã lưu.

e. Nguồn tham khảo

f. Học tiếp gì?

Bài trước là Meta Prompting là gì? #1, nơi ta thiết kế prompt và rubric ở tầng cao hơn. Bài tiếp theo là Self-Consistency trong LLM là gì? #3: thay vì sửa một đường qua nhiều vòng, ta lấy nhiều đường giải độc lập rồi tổng hợp theo quy tắc.

Nhắc lại: Nội dung chỉ phục vụ mục đích giáo dục. Loop AI không được tự dùng dữ liệu nhạy cảm hoặc thực hiện hành động bên ngoài khi chưa có quyền tối thiểu, log và người duyệt.