Loop Engineering cho RAG: Nghệ thuật thiết kế vòng lặp để pipeline không bao giờ "quay vòng vô ích"

Trong hệ thống RAG doanh nghiệp, việc truy xuất hay sinh nội dung thất bại là chuyện thường ngày — parser làm phẳng bảng dữ liệu, retrieval trả về sai trang, model gửi JSON không đúng schema, hay API bị timeout. Loop engineering (kỹ thuật vòng lặp) chính là lớp kỷ luật giúp pipeline phát hiện lỗi, điều chỉnh và thử lại trước khi người dùng kịp nhìn thấy kết quả hỏng. Bài viết này mổ xẻ cấu trúc ba điểm kiểm soát của một vòng lặp (trigger, termination, recovery), hai cấp độ vận hành (vòng lặp nhỏ trong khối, vòng lặp lớn xuyên khối) và quy tắc vàng chống "quay vòng vô ích" — thứ đốt token mà không mang lại giá trị.

Loop engineering là lớp thứ ba của ngăn xếp agent

Ba kỷ luật xếp chồng lên một lời gọi LLM. Prompt engineering viết lời gọi: system message, user message, schema. Context engineering chọn nội dung đi vào và đi ra khỏi cửa sổ ngữ cảnh giữa các lần gọi (xem Bài 7bis). Loop engineering quyết định khi nào lời gọi tiếp theo xảy ra, điều gì kích hoạt nó, khi nào vòng lặp dừng, và hệ thống phục hồi thế nào khi có sự cố.

Một prompt được trau chuốt với retrieval sạch sẽ cho câu trả lời đúng trong hầu hết thời gian. Nhưng phần còn lại, lời gọi thất bại theo một trong những cách đã nêu: JSON không hợp lệ, danh sách tự đánh dấu chưa đầy đủ, hay mã lỗi 429 từ giới hạn tốc độ của hệ thống. Loop engineering chính là kỷ luật thiết kế những gì xảy ra tiếp theo.

Một vòng lặp thử lại cùng một hành động trên cùng một lỗi không phải là học hỏi — nó đang quay vòng vô ích.

Giải phẫu một vòng lặp: Ba điểm kiểm soát và một quy tắc

Mỗi vòng lặp, dù nhỏ hay lớn, đều có ba bề mặt kiểm soát cần được thiết kế riêng biệt:

Trigger (Bộ kích hoạt). Điều kiện để lời gọi mới được kích hoạt sau khi lời gọi đầu tiên trả về. Trong trường hợp tài liệu đơn, có ba loại trigger: schema validation thất bại (model tạo JSON bị Pydantic từ chối), câu trả lời mang cờ tự đánh dấu (trường complete_answer_found là false, độ tin cậy dưới 0.6, hoặc model ghi needs_clarification), và lỗi API tạm thời (timeout, mất kết nối, mã 429 hoặc 5xx).

Termination (Điều kiện dừng). Điều kiện vòng lặp dừng lại. Có ba lớp: loop-until-done (dừng khi predicate được thỏa mãn), loop-until-budget (dừng khi hết hạn mức — sáu lần thử, sáu mươi giây đồng hồ), và hard cap (dừng vô điều kiện sau N lần, ví dụ wrapper llm_parse cứng rắn dừng ở lần thứ sáu và ném RuntimeError). Một vòng lặp không có cơ chế kết thúc rõ ràng là lỗi kinh điển được Anthropic Cookbook cảnh báo đầu tiên.

Recovery (Phục hồi). Việc xử lý khi lời gọi thất bại. Thư viện trong loạt bài này sử dụng retry-with-backoff: sáu lần thử, độ trễ 2/4/8/16/32/60 giây cộng thêm jitter, trên danh sách cố định các exception có thể thử lại. Ba giải pháp phong phú hơn cho từng trường hợp: chuyển sang model khác (model 3B thất bại schema, model 7B có thể thành công), chuyển lên người đánh giá (bất kỳ câu trả lời nào dưới 0.6 độ tin cậy với câu hỏi quan trọng), hoặc bỏ qua và trả về kết quả đã tính (batch result mang cả danh sách thành công và thất bại, người tiêu dùng quyết định thử lại sau).

# wrapper LLM của thư viện - retry-with-backoff, được tích hợp vào mọi lời gọi parse
def llm_parse(*, input, text_format, max_retries=6, cache=True, **opts):
    for attempt in range(max_retries):
        try:
            return client.responses.parse(input=input, text_format=text_format)
        except Exception as err:
            if not is_retriable(err):              # timeout/429/5xx retry;
                raise                              # context-length không bao giờ
            if attempt == max_retries - 1:
                raise                              # hard cap -> lan truyền
            delay = _compute_delay(attempt, base=2, cap=60, jitter=0.3,
                                   retry_after=extract_retry_after(err))
            time.sleep(delay)

Sơ đồ ba điểm kiểm soát quanh một lời gọi LLM

Quy tắc chống quay vòng vô ích

Một vòng lặp kích hoạt trigger, thử lại với cùng payload, nhận cùng lỗi, rồi thử lại lần nữa — đó không phải vòng lặp, mà là một cuộc tấn công từ chối dịch vụ vào ngân sách API của công ty. Quy tắc ngăn chặn điều này cực kỳ đơn giản:

Một vòng lặp chỉ nên thử lại khi có điều gì đó đã thay đổi giữa lần thử trước và lần thử sau. Ba thay đổi chính đáng:

• Payload: dispatcher mở rộng phạm vi retrieval (50 dòng thành 200 dòng), prompt hệ thống nhận thêm ràng buộc ("câu trả lời trước không hợp lệ; chỉ tạo JSON khớp schema này, không có văn xuôi xung quanh"), hoặc câu hỏi được viết lại.
• Model: model nhỏ trả về rác, model lớn có cơ hội thứ hai.
• Chiến lược: retrieval từ khóa thất bại, lần thứ hai dùng dense retrieval.

Việc thử lại không thay đổi một trong ba yếu tố trên chính là quay vòng vô ích. Quy tắc triển khai mang tính vận hành: mỗi lần thử lại phải mang một khối trace ghi rõ điều gì đã thay đổi. Nếu khối trace trống, việc thử lại không nên xảy ra. Giới hạn số lần thử ở N nhỏ (thư viện dùng sáu) và ghi nhật ký trường changed-since-last trong mỗi lần lặp.

Hai cấp độ của vòng lặp: Nhỏ trong khối, lớn xuyên khối

Vòng lặp nhỏ (Small loops). Chạy bên trong một khối duy nhất. Document parsing chạy image cascade: lọc ảnh trong trang một cách rẻ, phân loại từng loại, trả tiền cho vision model chỉ để mô tả những tấm đáng đọc. Retrieval dạo xuống mục lục tới đúng tiểu mục cần thiết. Question parsing hỏi một câu làm rõ và học mặc định. Generation thử lại khi JSON thất bại schema, và chạy lại cả retrieval lẫn generation khi danh sách trả về không đầy đủ.

Vòng lặp lớn (Big loops). Xuyên qua nhiều khối. Generation đọc đầu vào của chính mình, quyết định nó không đủ tốt để trả lời, rồi gửi pipeline quay lại một khối trước đó. Trường hợp tài liệu đơn có ba loại: adaptive parsing (generation báo context_structured=false, re-parse trang lỗi bằng parser sâu hơn), reference resolution (generation báo pending_references, orchestrator phân giải con trỏ, re-retrieve vùng đích, sinh lại), và scope feedback (generation báo complete_answer_found=false, mở rộng retrieval).

Vòng lặp nhỏ nằm trong khối, vòng lặp lớn xuyên khối khi generation không tin tưởng đầu vào

Các mẫu đã có trong loạt bài — dưới những cái tên ít hào nhoáng hơn

Nhìn code V1 hiện có với vốn từ vựng loop engineering 2026, hầu hết các nguyên mẫu được đặt tên đã tồn tại trong code, chỉ khác tên gọi:

• Loop-until-done: Vòng lặp kiểm tra tính đầy đủ của danh sách trong Bài 12 V1. Generator trả lời, schema mang cờ complete_answer_found, vòng lặp chạy lại retrieval và generation nếu cờ là false.
• Retry-with-backoff: Wrapper llm_parse của thư viện, sáu lần thử với lịch trình exponential.
• Generate-and-filter: Schema structured-output của Bài 8 V1. LLM trả JSON, Pydantic validator từ chối bất cứ thứ gì không khớp, vòng lặp thử lại khi validation thất bại.
• Classify-and-act: Dispatcher tổng hợp của Bài 13 V1. Câu hỏi đã phân tích mang một hình dạng (single-value, listing, aggregation, comparison), dispatcher định tuyến tới handler tương ứng.
• Feedback-loop-between-bricks: Vòng lặp phản hồi giữa các khối trong Bài 13 V1. Generation đánh dấu phạm vi retrieval không đủ, dispatcher mở rộng, generation chạy lại.

Chưa có trong V1: adversarial verification (một agent riêng cố gắng bác bỏ câu trả lời), tournament pattern (N câu trả lời ứng viên, giám khảo chọn người thắng), loop-until-dry termination (K vòng trống liên tiếp). Đây là phạm vi V4; trường hợp tài liệu đơn hiếm khi cần tới.

Năm nguyên mẫu chính mà trường hợp tài liệu đơn sử dụng, đều đã tồn tại trong loạt bài dưới những cái tên ít nổi bật hơn

Các lỗi thường gặp và cách phòng chống

Ba lỗi phổ biến trong production RAG tài liệu đơn, mỗi lỗi khớp với một quy tắc loop engineering cụ thể:

Vòng lặp vô hạn khi lỗi tạm thời. Lớp retry không có giới hạn cứng. Hệ thống gặp mã 429, vòng lặp thử lại, mã 429 tiếp theo đến trong cửa sổ giới hạn tốc độ, vòng lặp thử lại nữa, ngân sách API cháy suốt đêm. Cách khắc phục: giới hạn cứng số lần thử (thư viện dùng sáu), ném RuntimeError tường minh sau giới hạn, và cảnh báo trong trace store khi chạm mức.

Quay vòng vô ích trên lỗi xác định. Pydantic từ chối đầu ra vì model viết sai tên trường. Vòng lặp thử lại với cùng prompt. Model tạo cùng lỗi chính tả. Sáu lần thử, sáu lần bị từ chối, người dùng thấy RuntimeError. Cách khắc phục: khi retry do lỗi schema, sửa prompt để bao gồm cả thông báo lỗi validator nguyên văn ("câu trả lời trước của bạn thất bại validation với: field_name phải là field_name_actual. Hãy tạo JSON khớp schema chính xác."). Lần thử sau có thông tin mới.

Bỏ qua cờ độ tin cậy. Câu trả lời trả về với confidence = 0.3 và dispatcher chuyển nó tới người dùng mà không đánh dấu gì. Cách khắc phục: dispatcher áp dụng ngưỡng độ tin cậy; câu trả lời có độ tin cậy thấp hoặc được nâng cấp lên một lượt retrieval phong phú hơn, hoặc mang cảnh báo low_confidence tường minh tới người tiêu dùng.

Mỗi vòng lặp trong pipeline tài liệu đơn, nhỏ hay lớn, đều khoác cùng ba bề mặt kiểm soát

Vòng lặp trong vòng lặp: Con người nắm vòng ngoài cùng

Loop engineering được mô tả ở trên chỉ là một vòng lặp: dispatcher gọi, đọc kết quả, quyết định thử lại, dừng khi thỏa mãn. Phóng to ra, có ba vòng lặp chạy ở nhịp khác nhau quanh cùng một hệ thống, mượn khung của Andrew Ng trong thư "Three Key Loops for Building Great Software":

• Vòng lặp trong (inner loop), vài giây đến một phút: Chính là dispatcher. Retry-with-backoff khi gặp mã 502, sinh lại khi schema thất bại, mở rộng anchor set khi complete_answer_found: false. Không có con người, ngân sách có giới hạn, code quyết định.
• Vòng lặp phát triển (dev loop), vài phút đến vài giờ: Kỹ sư đọc audit trail, phát hiện một lớp lỗi, sửa concept_keywords_df, thêm cặp từ đồng nghĩa, siết chặt schema Pydantic, triển khai. Dispatcher chạy phiên bản đã sửa ở lần gọi sau.
• Vòng lặp ngoài (outer loop), vài giờ đến vài tuần: Người dùng sửa một trường được trích xuất sai. Sự sửa chữa rơi vào lớp lưu trữ kèm trích dẫn, trở thành ground truth cho lượt đánh giá tiếp theo, chảy vào concept catalog qua review queue.

Ng's point: Chừng nào con người còn biết điều mà AI không biết, vòng lặp ngoài không thể đóng lại bằng tự động hóa thêm. Đối xử với nó như nhiễu để tối ưu hóa là sai lầm.

Hệ quả cho thiết kế: giữ cho vòng lặp ngoài rẻ cho chuyên gia. Nếu sửa một trường sai mất mười cú click, vòng lặp ngoài gãy và tỷ lệ lỗi của hệ thống ngừng cải thiện. UX refresh-field, hàng đợi review và audit trail giữ cho vòng lặp ngoài đủ nhanh để tăng trưởng kép.

Kết luận

Loop engineering là kỷ luật thứ ba sau prompt engineering và context engineering. Ở phạm vi tài liệu đơn, nó sở hữu bốn nguyên mẫu: retry-with-backoff cho lỗi API tạm thời, generate-and-filter cho việc thử lại khi lỗi schema, loop-until-done cho kiểm tra tính đầy đủ, classify-and-act cho phân nhánh dispatcher. Quy tắc duy nhất phân biệt vòng lặp hữu ích với vòng lặp quay vô ích: mỗi lần thử lại phải thay đổi điều gì đó. Thư viện trong loạt bài này triển khai trực tiếp nguyên mẫu đầu tiên; ba nguyên mẫu còn lại nằm trong dispatcher (Bài 13) và listing schema (Bài 12). Vốn từ vựng 2026 đặt tên cho một kỷ luật mà loạt bài đã thực hành từ 2024.