Nghệ thuật dừng đúng lúc: Khi nào vòng lặp AI mới thực sự hội tụ?

Làm thế nào một mô hình AI có thể biết khi nào công việc của nó hoàn thành? Câu trả lời, theo phân tích mới từ quỹ đầu tư a16z, không nằm ở bản thân tác phẩm mà nằm ở hệ thống xung quanh nó — nơi các vòng lặp chỉ hội tụ khi có đủ bốn yếu tố: trạng thái mục tiêu, trạng thái hiện tại quan sát được, cách thay đổi chính xác và quy tắc dừng rõ ràng. Bài viết đặc biệt có giá trị cho cộng đồng developer Việt Nam, nơi phong trào xây dựng AI agent đang phát triển nhanh chóng nhưng vẫn còn nhiều người mắc kẹt trong vòng lặp "retry vô hạn" tốn kém.

Từ "con người trong vòng lặp" đến "vòng lặp tự vận hành"

Khi một lập trình viên coi công việc là hoàn thành? Khi bài kiểm tra chuyển sang màu xanh, khi đồng nghiệp duyệt pull request, hay khi deadline đến. "Hoàn thành" hiếm khi là thuộc tính của bản thân công việc — nó là một phán quyết được tạo ra bởi hệ thống xung quanh công việc đó.

Khái niệm loop engineering (kỹ thuật vòng lặp) mà cộng đồng AI đang nhắc đến gần đây chính là sự thay thế con người khỏi vòng lặp: thay vì bạn prompt model, xem kết quả, mô tả lỗi, rồi prompt lại, hệ thống sẽ tự thực hiện toàn bộ chu trình. Peter Steinberger, một kỹ sư nổi tiếng, đã tweet: "Bạn không nên prompt coding agents nữa. Bạn nên thiết kế các vòng lặp để prompt agents."

Vòng lặp chỉ tốt bằng bộ kiểm chứng (verifier) tại mỗi bước.

Thực tế này đặt ra một vấn đề nhức nhối: vòng lặp có thể hội tụ nhưng chỉ hội tụ trên bộ kiểm chứng, không phải ý định thực sự của người dùng. Bằng chứng rõ ràng từ chuẩn SpecBench: các agent tiên tiến liên tục vượt qua các bài kiểm tra hiển thị nhưng thất bại ở các bài kiểm tra ẩn. Thậm chí có agent đã tạo ra một "trình biên dịch" dài 2.900 dòng chỉ để ghi nhớ các đầu vào kiểm tra.

Mô hình AI trong vòng lặp không hội tụ

Bốn điều kiện để một vòng lặp hội tụ

Nói chuyện với nhiều kỹ sư và nhà nghiên cứu trên nhiều lĩnh vực, tác giả Yoko Li từ a16z đúc kết bốn yếu tố then chốt:

1. Trạng thái mục tiêu (Target state)

Hệ thống cần một biểu diễn rõ ràng về "hoàn thành" nghĩa là gì: test suite, đặc tả kỹ thuật, hay bộ ràng buộc hiệu năng. "Làm cho nó tốt hơn" không phải trạng thái mục tiêu — nó chỉ là một prompt khác.

2. Trạng thái hiện tại quan sát được (Observable current state)

Hệ thống cần nhìn vào cấu trúc bên dưới: file, diff, kết quả test, DOM tree, cấu trúc SVG... Chỉ nhìn output render thôi là chưa đủ, vì bạn không thể xác định lỗi đến từ đâu.

3. Cách thay đổi chính xác (Precise way to make changes)

Agent cần thay đổi phần gây ra lỗi mà không tái sinh toàn bộ phần khác. Sửa một hàm tốt hơn viết lại cả repository; chỉnh một path SVG tốt hơn tạo ảnh mới. Mức độ thay đổi càng cục bộ, vòng lặp càng có khả năng bảo toàn những gì đã hoạt động.

4. Quy tắc dừng (Stopping rule)

Điều kiện dừng phải đến từ bên ngoài generator: test pass, điểm số vượt ngưỡng, hay người duyệt chấp nhận. Quan trọng hơn, quy tắc dừng cần tính đến chi phí — một vòng lặp đạt kết quả đúng sau 500 lần thử có thể hội tụ về mặt kỹ thuật nhưng không hội tụ về mặt kinh tế.

Biểu đồ hai trục: Khả năng chỉnh sửa và Khả năng kiểm chứng

Một cách hữu ích để hình dung vấn đề là đặt nhiệm vụ trên hai trục: mức độ có thể chỉnh sửa của artifact và mức độ kiểm chứng được của kết quả.

• Code nằm ở góc trên bên phải: dễ chỉnh sửa, có bộ kiểm chứng mạnh mẽ.
• Sinh ảnh mở nằm ở góc dưới bên trái: khó sửa một quyết định cụ thể, khó xác minh kết quả gần ý định người dùng hơn hay không.

Điểm mấu chốt: vị trí của nhiệm vụ có thể dịch chuyển bằng cách tái biểu diễn vấn đề. Một bức ảnh mở khó chỉnh sửa, nhưng nếu biểu diễn dưới dạng SVG paths hoặc Blender scene, nó trở nên có thể chỉnh sửa — nhiệm vụ dịch lên trên. Nếu có ảnh tham chiếu hoặc bộ ràng buộc để kiểm tra, tiến trình trở nên kiểm chứng được — nhiệm vụ dịch sang phải.

Trực quan hóa hai trục hội tụ trong loop engineering

Đây chính là bản chất của loop engineering: không phải bắt agent thử nhiều hơn, mà là tái biểu diễn nhiệm vụ cho đến khi nó nằm trong góc phần tư nơi vòng lặp hội tụ.

Kinh tế học của vòng lặp: Hai phần ba chi phí có thể đổ sông đổ bể

Giả sử bạn đã tìm ra vòng lặp hoạt động tốt. Vấn đề tiếp theo là "eventually" — cuối cùng thì vòng lặp sẽ đạt đích, nhưng mất bao nhiêu lần thử?

Dữ liệu từ nhiều nghiên cứu về test-time compute cho thấy lợi nhuận biên có dạng logarit: mỗi mức tăng chất lượng tiếp theo đòi hỏi số lần thử tăng theo cấp số nhân. Một benchmark về web agent chỉ ra: từ 1 lần lấy mẫu lên 10 lần, tỷ lệ thành công tăng từ 38,8% lên 43,2%. Nhưng nhân đôi lên 20 lần chỉ mua thêm 0,2 điểm với gấp đôi token tiêu thụ.

Tệ hơn, khi đi qua điểm bão hòa, lợi nhuận biên có thể chuyển thành âm: các mô hình suy luận với ngân sách lớn hơn bắt đầu từ bỏ những câu trả lời đã đúng. Nhiều chu kỳ hơn không chỉ ngừng giúp ích — chúng bắt đầu gây hại.

Tác giả đã thử nghiệm ngay trên một vòng lặp nổi tiếng từ Anthropic:

• Trên một trang cố tình hỏng (Lighthouse 35), Claude Code đạt 98 điểm ngay lần đầu tiên với chi phí 0,35 USD — vòng lặp không bao giờ kích hoạt như dự kiến.
• Khi đặt mục tiêu không thể đạt (giới hạn 89 điểm do độ trễ 2,2 giây, yêu cầu 100), 1,40 USD đầu tiên nâng điểm từ 26 lên 89. Nhưng 2,84 USD còn lại — 67% tổng hóa đơn — mua được đúng 0 điểm.

Điểm số chạm trần nhưng vòng lặp không dừng

Bài học không phải là vòng lặp không hoạt động, mà là chúng không biết cách dừng. Trong thử nghiệm này, toàn bộ giá trị nằm trong một phần ba chi phí đầu tiên, nhưng vòng lặp vẫn tiếp tục đốt token cho một nhiệm vụ bất khả thi.

Hạ tầng cho loop engineering: Dừng đúng lúc là điều không thể prompt

"Việc dừng tốt không phải thứ có thể tạo ra bằng prompt. Nó đòi hỏi hạ tầng: thứ để đo chi phí, thứ để đo tiến trình so với chi phí, và thứ có đủ thông tin để cắt vòng lặp."

Khi vòng lặp trở thành đơn vị kỹ thuật, một stack hoàn chỉnh đã hình thành:

• Môi trường để agent hoạt động
• Nơi giữ trạng thái cho các lần chạy dài
• Bộ kiểm chứng để xác định điều gì đáng tính
• Bề mặt để con người can thiệp khi cần

Minh họa sự khác biệt giữa vòng lặp không hội tụ và hội tụ

Vòng lặp ở thời điểm suy luận so với thời điểm huấn luyện

Nhìn từ góc độ khác, vấn đề vòng lặp có thể được hiểu qua lăng kính inference-time vs training-time:

• Ở thời điểm suy luận: vòng lặp thay đổi công việc, không thay đổi mô hình. Agent viết code, chạy kiểm chứng, đọc kết quả, thử lại. Trọng số cố định, hệ thống tìm kiếm câu trả lời tốt hơn trong một nhiệm vụ.
• Ở thời điểm huấn luyện: sử dụng kỹ thuật học tăng cường, chạy nhiều quỹ đạo, chấm điểm kết quả, cập nhật mô hình. Quy tắc vàng vẫn là: vòng lặp chỉ tốt bằng bộ kiểm chứng của nó — trong RL, bộ kiểm chứng đó là tín hiệu phần thưởng.

Hai loại vòng lặp này có thể nuôi nhau: các trace từ inference-time trở thành dữ liệu huấn luyện, cặp ưu tiên, hoặc phần thưởng. Nhưng không phải thất bại nào cũng nên giải quyết bằng training — thường giải pháp hiệu quả hơn nằm bên ngoài trọng số: công cụ tốt hơn, trạng thái rõ ràng hơn, action space chính xác hơn, hoặc verifier mạnh hơn.

Tương lai: Kinh tế học của vòng lặp phải trở nên minh bạch

Hai điều rõ ràng từ việc quan sát các vòng lặp đang chạy:

Thứ nhất, kinh tế học phải trở nên tường minh. Hiện nay chúng ta chạy vòng lặp như cách từng chạy các cloud instance không ai nhớ tắt. Agent tính phí theo token, và token có chi phí như nhau dù nó di chuyển điểm số hay re-minify cùng một HTML lần thứ chín. Phần còn thiếu thật nhàm chán nhưng cần thiết: chi phí mỗi lần lặp, tiến trình trên mỗi đô la, một đường cong có thể nhìn thấy khi vòng lặp đang chạy.

Thứ hai, với các vòng lặp đã hội tụ, công việc hạ tầng thú vị đã chuyển ra ngoài vòng lặp. Vòng lặp chỉ là một lệnh while, và mọi thứ khiến nó hội tụ đều nằm xung quanh: môi trường agent hoạt động, trạng thái tồn tại qua thời gian chạy dài, bộ kiểm chứng quyết định điều gì đáng tính, bề mặt con người can thiệp. Mọi vòng lặp hoạt động tốt đều cần một stack như thế, và stack chính là nơi tạo ra sự khác biệt thực sự.

Vậy làm thế nào để mô hình AI biết công việc của nó đã xong? Ngay bây giờ, nó không biết. Nó dừng khi ngân sách cạn hoặc khi một kiểm tra do chúng ta thiết kế nói "đủ rồi" — và cả hai điều đó đều cần được xây dựng. Hệ thống quan trọng sẽ không phải là những hệ thống có thể tiếp tục mãi — vì tất cả đều có thể. Chúng sẽ là những hệ thống mà người xây dựng đã quyết định, một cách chính xác và từ trước, rằng "hoàn thành" có giá bao nhiêu và nghĩa là gì.

Bài viết dựa trên phân tích của Yoko Li, partner tại Andreessen Horowitz, tập trung vào developer tools, hạ tầng, AI và công cụ sáng tạo.