Nghệ thuật của vòng lặp kỹ thuật: Làm sao để AI biết khi nào nên dừng lại?

Mỹ | Công nghệ | Ý kiến | Văn hóa | Biểu đồ

Làm thế nào một mô hình AI biết được khi nào công việc của nó đã hoàn thành?

Chà, con người chúng ta biết khi nào công việc của mình hoàn thành bằng cách nào?

Một lập trình viên chờ đợi các bài kiểm thử (test) chuyển sang màu xanh hoặc chờ phản hồi PR từ nhóm của họ. Một nhà thiết kế điều chỉnh bố cục, rời đi, quay lại và quyết định rằng những khiếm khuyết còn sót lại không còn quan trọng nữa. Một người viết nộp bản thảo vì đã đến hạn chót hoặc vì biên tập viên chấp nhận nó, chứ không phải vì văn bản đã đạt đến trạng thái hoàn thiện khách quan nào đó.

"Hoàn thành" hiếm khi là một đặc tính của chính công việc đó. Đó là một đánh giá được tạo ra bởi hệ thống xung quanh công việc. Con người không sở hữu một bộ dò tìm phổ quát cho trạng thái "hoàn thành". Chúng ta dựa vào một tập hợp các tín hiệu như các bài kiểm thử, thông số kỹ thuật, tiền lệ, sự phê duyệt, thời hạn, rủi ro và việc tìm ra điểm lợi nhuận giảm dần. Trong mỗi trường hợp, sự hoàn tất đến từ bên ngoài chính công việc đó.

Một mô hình AI gần như luôn có thể tạo ra một câu trả lời khác.

Nó có thể sửa lại đoạn văn đó lần nữa. Nó có thể thử một cách triển khai khác. Nó có thể tạo ra một hình ảnh khác với nhiều chi tiết hơn, ánh sáng khác biệt và bố cục mạnh mẽ hơn. Nó không cảm thấy mệt mỏi với công việc. Nó không nhận ra, trừ khi chúng ta cung cấp cho nó cách để nhận ra, rằng ba lần sửa đổi gần nhất chỉ làm cho kết quả khác đi chứ không nhất thiết là tốt hơn.

Đây là một phần lý do khiến ý tưởng gần đây về "loop engineering" (kỹ thuật vòng lặp) trở nên hấp dẫn. Thay vì con người đưa ra câu lệnh (prompt) cho mô hình, kiểm tra kết quả, mô tả những gì sai sót và lại đưa ra câu lệnh lần nữa, chúng ta có thể yêu cầu hệ thống tự thực hiện toàn bộ chu trình đó. Con người không còn phải ngồi trong mỗi lượt thực hiện. Tác nhân (agent) tự khám phá công việc, đưa nó cho mô hình, kiểm tra kết quả và quyết định điều gì nên xảy ra tiếp theo.

Peter Steinberger 🦞@steipete

Đây là lời nhắc nhở hàng tháng của bạn rằng bạn không nên trực tiếp đưa câu lệnh cho các tác nhân lập trình nữa. Bạn nên thiết kế các vòng lặp để đưa câu lệnh cho các tác nhân của mình.

6:58 CH · 7 thg 6, 2026 · 8,5 triệu lượt xem

1,8 nghìn lượt trả lời · 1,41 nghìn lượt đăng lại · 19,8 nghìn lượt thích

Tuy nhiên, điểm tinh tế khi viết một vòng lặp là vòng lặp đó chỉ tốt khi bộ xác thực (verifier) ở mỗi bước tốt. Ngay cả trước khi chúng ta bắt đầu nói về kỹ thuật vòng lặp, mọi thứ đã vận hành như một vòng lặp rồi, chỉ là với một công cụ rất đắt đỏ – đó là con người tự đưa câu lệnh và đóng vai trò là bộ xác thực. Khi loại bỏ con người ra khỏi vòng lặp, việc thiết kế những gì cần được xác thực trong mỗi bước trở thành chìa khóa để thúc đẩy trạng thái vòng lặp, và thực tế là rất khó để làm cho chúng hoạt động.

Hãy lấy vòng lặp tác nhân lập trình tiêu chuẩn làm ví dụ: tiếp tục làm việc cho đến khi các bài kiểm thử vượt qua. Nghe có vẻ hoàn toàn có thể xác thực được. Nhưng các bài kiểm thử chỉ là đại diện cho nhiệm vụ. Trong SpecBench, các tác nhân tiên tiến thường xuyên vượt qua các bài kiểm thử hiển thị nhưng lại thất bại ở các bài kiểm thử ẩn (held-out tests) vốn kiểm tra cùng các tính năng đó. Một tác nhân đã tạo ra một "trình biên dịch" dài 2.900 dòng chỉ đơn giản là ghi nhớ các đầu vào kiểm thử. Vòng lặp đã hội tụ, nhưng chỉ trên bộ xác thực, chứ không phải trên ý định của người dùng.

Bộ xác thực không chỉ là điều kiện dừng. Nó còn xác định những gì vòng lặp coi là tiến bộ. Nếu tín hiệu không đầy đủ, vòng lặp có thể trở nên giỏi hơn trong việc vượt qua bài kiểm tra mà không hề giỏi hơn trong việc thực hiện nhiệm vụ.

Kỹ thuật vòng lặp không phải là thực hành việc bắt tác nhân thử lại. Đó là thực hành việc làm cho mỗi chu trình giảm bớt khoảng cách giữa trạng thái hiện tại và trạng thái mong muốn. Một vòng lặp chưa phải là một định hướng.

Những vòng lặp đầu tiên hoạt động tốt là các vòng lặp lập trình. Đây không phải là ngẫu nhiên. Mã nguồn vừa có thể chỉnh sửa vừa có thể thực thi. Một tác nhân có thể thay đổi một hàm, chạy chương trình, đọc lỗi kiểm thử và thử lại. Môi trường trả về một tín hiệu tương đối rõ ràng về những gì đã hỏng. Vòng lặp có cả cách thức chính xác để hành động và một bộ xác thực có thể đo lường tiến độ.

Tôi đã viết về một mô hình tương tự trong việc tạo mã trực quan. Một tệp SVG không chỉ là một hình ảnh; nó chứa các đường dẫn, hình dạng, văn bản, độ dốc và bố cục. Một cảnh trong Blender không chỉ là một bản kết xuất (render); nó chứa hình học, vật liệu, máy quay, khớp nối và các ràng buộc. Những biểu diễn này cung cấp cho tác nhân thứ gì đó mà nó có thể kiểm tra và chỉnh sửa cục bộ. Nếu một đường cong bị sai, hãy thay đổi đường dẫn. Nếu một đối tượng bị đặt sai vị trí, hãy di chuyển đối tượng đó. Tạo phẩm có thể cải thiện qua các lần lặp thay vì bị tạo lại từ đầu.

Nhưng khả năng chỉnh sửa chỉ là một nửa của vấn đề. Trong việc tạo hình ảnh mở, một lần lặp khác thường có nghĩa là tạo ra một mẫu khác và chọn mẫu tốt nhất. Phản hồi mang tính tổng thể, và rất khó để ánh xạ "cái này trông tệ hơn" thành một chỉnh sửa chính xác. Các vòng lặp SVG và Blender có thể hội tụ khi mục tiêu có thể được biểu diễn dưới dạng tham chiếu, hình học, ràng buộc hoặc hành vi chức năng từ một đối tượng có khớp nối. Chúng gặp khó khăn khi mục tiêu chỉ đơn giản là "làm cho nó tốt hơn, với gu thẩm mỹ tốt hơn, nhưng bạn không thể hỏi con người". Các vòng lặp trực quan không phải là không thể. Chúng thường cực kỳ khó xác thực.

Nếu bộ xác thực cung cấp định hướng cho vòng lặp, thì vòng lặp cần gì để hội tụ?

Dựa trên nhiều cuộc trò chuyện với các kỹ sư và nhà nghiên cứu trong nhiều lĩnh vực, tôi nghĩ có bốn yếu tố.

Hệ thống cần một biểu diễn về ý nghĩa của từ "hoàn thành". Đối với mã nguồn, đây có thể là một bộ kiểm thử, một thông số kỹ thuật hoặc một tập hợp các ràng buộc hiệu suất. Đối với SVG, đó có thể là một hình ảnh tham chiếu, kích thước, màu sắc và các quy tắc bố cục. "Làm cho nó tốt hơn" không phải là một trạng thái mục tiêu. Đó chỉ là một câu lệnh khác.

Hệ thống cần kiểm tra những gì đang tồn tại. Và điều đó có thể bao gồm các tệp, tệp diff, kết quả kiểm thử, dấu vết (traces), cây DOM, cấu trúc SVG hoặc đồ thị cảnh Blender. Chỉ riêng đầu ra đã kết xuất thường là không đủ. Hệ thống cũng cần nhìn thấy cấu trúc bên dưới để có thể xác định lỗi đến từ đâu.

Tác nhân cần thay đổi phần chịu trách nhiệm cho lỗi mà không cần tạo lại mọi thứ khác. Thay đổi một hàm tốt hơn là viết lại toàn bộ kho lưu trữ. Chỉnh sửa một đường dẫn SVG tốt hơn là tạo ra một hình ảnh mới. Điều chỉnh một đối tượng trong cảnh Blender tốt hơn là xây dựng lại cảnh từ đầu. Chỉnh sửa 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 tốt.

Trong thực tế, đây là phần mà mọi người gặp khó khăn nhất. Gần như mọi nhà nghiên cứu tôi nói chuyện đều nói cùng một điều: vòng lặp của họ bắt đầu hoạt động khi họ tìm thấy đúng tập hợp các lệnh gọi công cụ và các câu lệnh trung gian. Làm thế nào để bạn khám phá ra các công cụ giúp thúc đẩy vòng lặp một cách có ý nghĩa? Hiện tại, không ai biết trước được. Nó chủ yếu là thử và sai. Điều này dẫn đến một hàm ý không mấy dễ chịu: một vòng lặp được tinh chỉnh cho ngăn xếp (stack) của nó. Các lệnh gọi công cụ giúp một vòng lặp hội tụ trên một cơ sở mã nguồn nhất định sẽ mã hóa các giả định về cơ sở mã đó, và những giả định đó không còn đúng ở nơi khác. Một vòng lặp hiệu quả với người này chỉ là điểm khởi đầu, không phải là sự đảm bảo. Các vòng lặp tùy chỉnh không tự động tổng quát hóa được. Và đây là lý do tại sao chúng ta thấy cả hai mặt của cuộc thảo luận: một số người tìm thấy những vòng lặp kỳ diệu hiệu quả với họ, nhưng những người khác lại thấy rằng khi họ sử dụng các vòng lặp được công bố công khai, chúng hoàn toàn không hoạt động.

Hệ thống cần một điều kiện cho nó biết khi nào cần dừng lại. Điều kiện này nên đến từ bên ngoài bộ tạo: các bài kiểm thử vượt qua, các ràng buộc được thỏa mãn, điểm số vượt qua ngưỡng hoặc người đánh giá phê duyệt kết quả. Điều kiện dừng cũng cần tính đến chi phí – một vòng lặp đạt được câu trả lời đú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ế.

Một cách hữu ích để suy nghĩ về điều này là thông qua hai trục: mức độ có thể chỉnh sửa của tạo phẩm và mức độ có thể xác thực của kết quả.

Mã nguồn thường nằm ở góc trên bên phải. Nó dễ chỉnh sửa và có các bộ xác thực tương đối mạnh. Việc tạo hình ảnh mở thường nằm ở góc dưới bên trái. Hệ thống có thể tạo ra một hình ảnh khác, nhưng nó không thể dễ dàng sửa chữa một quyết định cụ thể hoặc xác thực rằng kết quả gần với ý định của người dùng hơn.

Một đặc tính quan trọng của biểu đồ trên là vị trí của một nhiệm vụ có khả năng thay đổi bằng cách định hình lại vấn đề. Các trục mô tả biểu diễn, không phải chính nhiệm vụ đó. Một hình ảnh mở rất khó chỉnh sửa, nhưng cùng hình ảnh đó, nếu được biểu diễn dưới dạng đường dẫn SVG hoặc cảnh Blender, sẽ trở nên có thể chỉnh sửa — nhiệm vụ di chuyển lên trên. Cung cấp cho nó một hình ảnh tham chiếu hoặc một tập hợp các ràng buộc để kiểm tra, và tiến độ trở nên có thể xác thực, điều này di chuyển nhiệm vụ sang bên phải. Đây là một cách khác để mô tả kỹ thuật vòng lặp: không phải làm cho tác nhân thử lại nhiều hơn, mà là biểu diễn lại nhiệm vụ cho đến khi nó nằm trong góc phần tư nơi các vòng lặp hội tụ.

Tôi đã phỏng vấn các lập trình viên từ nhiều lĩnh vực khác nhau, những người đều đang làm việc với một dạng kỹ thuật vòng lặp nào đó - từ kỹ thuật phần mềm đến các tác vụ sáng tạo, hình ảnh và chỉnh sửa video. Và tôi đã hỏi mỗi người cùng một câu hỏi - làm thế nào bạn biết vòng lặp sẽ hội tụ và cải thiện dần dần?

Câu trả lời là quy trình khám phá một vòng lặp hiệu quả ngày nay đòi hỏi rất nhiều thử và sai. Đó có thể là việc cung cấp các lệnh gọi công cụ phù hợp; hoặc để vòng lặp chạy trong nhiều giờ để xem liệu nó có cải thiện nhiều hơn so với những giờ trước đó không (và liệu đường cong cải thiện có hứa hẹn hay không). Đó có thể là việc đi sâu vào các quy trình làm việc cụ thể mà họ đã chạy trong các môi trường cụ thể và sao chép chính xác điều đó.

Nhưng việc khám phá các vòng lặp có thể hoạt động ở mọi nơi là rất khó, và gần như chúng ta đang cố gắng mã hóa tri thức con người vào chính vòng lặp đó; trước tiên chúng ta phải hiểu sâu sắc điều gì làm cho vòng lặp hoạt động, hoặc tìm những cách sáng tạo để xây dựng một lớp xác thực, trước khi cố gắng tự động hóa nó.

Tuy nhiên, việc tìm ra một vòng lặp chỉ là chi phí ban đầu. Vận hành vòng lặp mới là chi phí chính đi kèm với mọi chu kỳ phát triển.

Vì vậy, giả sử việc thử và sai mang lại kết quả, và bạn đã tìm thấy một vòng lặp hiệu quả. Phiên bản đơn giản nhất của điều này là /goal [điều kiện]. Tiếp tục cho đến khi điều kiện được đáp ứng. Và vòng lặp cuối cùng sẽ đạt được mục tiêu đó.