Đây là bài thứ hai trong loạt ghi chép về thiết kế tác tử cho tác vụ dài hơi, bắt nguồn từ việc đọc kỹ BEACON (Đại học Chiết Giang, arXiv:2605.06078).
Trong đó, bài đầu tiên lập luận rằng phát hiện vòng lặp không thể nhận ra tác tử đang chững lại, vì sự lặp lại là tín hiệu phía đầu vào còn tiến triển là tín hiệu phía đầu ra. Lập luận đó chỉ đứng vững nếu có thứ để đối chiếu khi đo tiến triển. Bài này nói về thứ đó.
Đặt câu hỏi đúng cách
Câu hỏi không phải “làm sao tác tử biết nó đã hoàn thành một bước”. Mà là “làm sao hệ thống biết tác tử thực sự hoàn thành, thay vì chỉ tuyên bố như vậy.”
Chỉ khác một lớp, nhưng độ đáng tin cậy khác nhau một trời một vực.
Chúng tôi đã có hai nửa nhưng chưa bao giờ nối chúng lại
Khi đọc phần triển khai của chính mình, đây là điều gây ngạc nhiên.
Nửa thứ nhất. Các mốc đã tồn tại trong sản phẩm. Một công cụ duy trì kế hoạch tác vụ bền vững: tác vụ dài được chia nhỏ thế nào và mỗi bước đang ở trạng thái nào — chờ xử lý, đang thực hiện, hoàn tất, bị chặn. Mục đích được nêu là tạo điểm neo tiến độ ổn định cho tác vụ dài. Nhưng một bước trở thành “hoàn tất” bằng cách nào? Mô hình tuyên bố điều đó.
Nửa thứ hai. Sau mỗi lệnh gọi công cụ, hệ thống chủ ghi lại một tập dữ kiện xác định: hàm băm nội dung của tệp có thực sự thay đổi không, mã thoát của lệnh là gì, lệnh có hết thời gian chờ không. Những dữ kiện này được ghi ở phía hệ thống chủ và không bao giờ đi vào ngữ cảnh mô hình, đó chính là lý do chúng không thể bị bịa đặt.
Khoảng trống nằm ở đó. Một dòng nói tôi đã hoàn thành. Dòng kia nói hàm băm của một tệp đã chuyển từ A sang B. Chưa từng có gì đặt chúng cạnh nhau.
Điều còn thiếu không phải cấu trúc dữ liệu, cũng không phải khả năng quan sát. Đó là cầu nối giữa hai phần.
Điều hữu ích nhất trong bài báo không phải công thức
BEACON được biết đến nhiều nhất nhờ hàm lợi thế ở hai thang đo, nhưng phần đáng học hỏi là cách nó định vị bộ phát hiện Φ.
Φ không cần mô hình đã huấn luyện và không cần con người gán nhãn. Nó chỉ đọc các thay đổi trạng thái quan sát được trong phản hồi môi trường: chuyển trạng thái của đồ vật trong ALFWorld (đã nhặt thành công, đã làm nóng xong), chuyển trang trong WebShop, còn trong ScienceWorld nó đơn giản sử dụng tín hiệu mục tiêu con mà môi trường đã phát ra.
Không thêm mô hình, không thêm chi phí lấy mẫu. So với các phương án khác: mô hình phần thưởng quá trình cần gán nhãn tốn kém và có thể bị lách, còn ước lượng giá trị Monte-Carlo cần thêm các lượt triển khai tại mỗi điểm quyết định. Đó là chi phí mà Φ tránh được.
Bất kỳ ai xây dựng sản phẩm tác tử đều có lợi thế mà các bối cảnh trong bài báo không có: lệnh gọi công cụ vốn đã có cấu trúc, với thành công và thất bại rõ ràng. Bài báo phải khai thác tín hiệu từ môi trường. Tín hiệu của chúng ta đã có sẵn.
Ba lớp, nếu bạn định xây dựng
Lớp một: gom bằng chứng xác định vào một luồng. Hoàn toàn không phán đoán ngữ nghĩa, chỉ ghi lại một cách máy móc những thay đổi không thể đảo ngược và có thể xác minh. Hàm băm nội dung tệp đã thay đổi. Một lệnh thoát với mã không. Một lệnh gọi API bên ngoài trả về thành công. Một hàng dữ liệu đã được ghi nhận. Tất cả đều đã tồn tại. Chúng chỉ đang rải rác, chưa bao giờ được gom thành một bản ghi duy nhất về các dữ kiện đã xác lập đến hiện tại.
Lớp hai: nối hai nửa lại. Bước có giá trị cao nhất. Khi mô hình tuyên bố một bước đã hoàn tất, đừng tin suông nữa mà hãy tìm bằng chứng lớp một trong khoảng thời gian đó. Có bằng chứng thì đánh dấu đã xác minh hoàn tất. Không có bằng chứng thì đánh dấu đã tuyên bố hoàn tất. Điều này không ngăn mô hình tuyên bố bất cứ điều gì; nó chỉ phân biệt điều có căn cứ với điều không có căn cứ.
Lớp ba: định nghĩa Φ cho từng loại năng lực. Các tác giả thừa nhận Φ cần kiến thức miền và khái quát hóa kém, nên đừng kỳ vọng một bộ phát hiện dùng chung cho mọi thứ. Tác vụ lập trình theo dõi mã thoát của kiểm thử. Tác vụ phân tích dữ liệu theo dõi tệp đầu ra có được tạo ra không. Tác vụ nhắn tin theo dõi phản hồi API. Lớp này được xây dựng dần, từng năng lực một.
Một tiêu chí chúng tôi bổ sung: tính không thể đảo ngược, không phải tầm quan trọng
Tiêu chí này không có trong bài báo.
Các mốc của BEACON hiệu quả vì chúng đánh dấu những chuyển trạng thái mà bạn không thể quay ngược. Một khi đã có chìa khóa, thế giới đã khác. Vì vậy tiêu chí nên là hành động này có tạo ra tác động bên ngoài không thể đảo ngược hay không, thay vì bước này có quan trọng không.
Không thể đảo ngược: ghi tệp, tạo commit mã, gửi tin nhắn, gọi API trả phí, ghi giao dịch vào cơ sở dữ liệu. Có thể đảo ngược: đọc tệp, tìm kiếm, tải trang, suy nghĩ.
Có hai hệ quả. Có thể quyết định bằng quy tắc máy móc, vì loại hành động đã đủ để xác định — không cần hiểu ngữ nghĩa, và không để lọt tính chủ quan kiểu “mô hình cho rằng bước này quan trọng”. Đồng thời, nó trùng với các điểm khôi phục: tiếp tục từ ranh giới không thể đảo ngược là kiểu tiếp tục duy nhất có ý nghĩa, vì các hành động có thể đảo ngược chỉ cần làm lại.
Hai con số: một để vững tin, một để thận trọng
Con số giúp vững tin đến từ thử nghiệm suy giảm. Bỏ ngẫu nhiên một nửa số mốc mà điểm vẫn đạt 82.8, so với mốc cơ sở 72.8 — cao hơn mười điểm. Chất lượng giảm từ từ, không lao dốc. Với bất kỳ ai đưa tính năng này vào sản phẩm, đó là điều quan trọng: không cần làm Φ hoàn hảo mới dám bật. Bao phủ một nửa đã có lợi.
Con số nhắc phải thận trọng đến từ phép so sánh cách phân đoạn.
| Cách phân đoạn | Điểm | so với đường cơ sở (72.8) |
|---|---|---|
| Chia ngẫu nhiên thành 5 phần | 74.2 | +1.4 |
| Mốc tiến độ thực | 91.4 | +17.2 |
Bài đầu tiên cũng trích các con số này, nhưng ở đây hàm ý trực tiếp hơn. Nếu các mốc được đặt theo trực giác, chúng gần như một phép chia ngẫu nhiên, và công sức bị lãng phí. Các mốc có giá trị chính khi chúng khớp với cấu trúc thực của tác vụ.
Những điểm cần dè dặt
Phụ lục của chính bài báo liệt kê việc tự động khám phá mốc là một bài toán còn bỏ ngỏ. Cả ba bộ đánh giá đều lấy mốc từ quy tắc: đối sánh mẫu phản hồi môi trường, chuyển trang hoặc tín hiệu do môi trường trực tiếp cung cấp. Những bối cảnh thực sự mở — thao tác trình duyệt, tái cấu trúc cơ sở mã, nghiên cứu chuyên sâu — không có sẵn các chuyển trạng thái có thể xác minh như vậy.
Vì thế đây là một mô thức đã được kiểm chứng trong môi trường có cấu trúc, không phải giải pháp có thể bê nguyên sang dùng. Điều giúp nó ứng dụng được trong sản phẩm tác tử là ranh giới có cấu trúc của lệnh gọi công cụ, không phải một câu trả lời mà bài báo đã cung cấp sẵn.
Cạm bẫy còn lại là độ chi tiết. Quá thưa thì chẳng làm được gì; quá dày thì tín hiệu ở cấp đoạn trở thành nhiễu. Trong sản phẩm, đó là độ chi tiết khi phân rã tác vụ, và ở đây có một thuận lợi mà các bối cảnh của bài báo thiếu. Các bước kế hoạch vốn được thiết kế để người dùng đọc, nên độ chi tiết có thể dựa vào việc một người có hiểu được bước đó hay không, thay vì chỉ được tinh chỉnh bằng thuật toán.
Nếu chỉ làm một việc
Hãy làm lớp hai.
Nó rẻ, vì dữ liệu lớp một đã tồn tại và lớp hai chỉ liên kết dữ liệu đó với các tuyên bố của mô hình. Nó có thể được xác minh độc lập, vì tỷ lệ giữa số mốc được xác minh và số mốc được tuyên bố tự nó đã là một chỉ số đáng theo dõi. Và nó là tiền đề cho mọi thứ khác: nếu không có khái niệm mốc đã xác minh, cả phát hiện chững tiến độ trong bài đầu lẫn ranh giới nén ngữ cảnh trong bài tiếp theo đều không có nền tảng.
Nó còn có một đặc tính dễ chịu. Đưa vào sản phẩm không làm thay đổi hành vi nào — mô hình vẫn tuyên bố các bước như trước, chỉ có thêm một dấu đánh dấu. Khi dữ liệu tích lũy đủ, bạn có thể quyết định có can thiệp vào những tuyên bố không kèm bằng chứng hay không.
Bài tiếp theo nói về nén ngữ cảnh: vì sao cắt ở một ngưỡng token ít liên quan đến những gì có thể quên một cách an toàn, đồng thời sửa lại cách mở rộng tự nhiên nhất từ bài này — giả định rằng một khi mốc đã được xác minh, mọi thứ trước đó đều có thể được gộp gọn đi.