Tác tử của bạn đạt 80% cửa sổ ngữ cảnh. Việc nén được kích hoạt và bỏ các lượt cũ nhất. Mười phút sau, nó đọc lại một tệp đã đọc và hỏi lại một câu đã trả lời.
Ngưỡng đó biết bạn sắp hết chỗ. Nó không biết có thể bỏ gì một cách an toàn.
Đây là bài ghi chép thứ ba trong loạt bài về thiết kế tác tử cho tác vụ dài hạn, xuất phát từ việc đọc kỹ BEACON (Đại học Chiết Giang, arXiv:2605.06078). Bài đầu tiên bàn về phát hiện đình trệ, bài thứ hai bàn về thiết kế mốc tiến độ.
Bắt đầu từ cách triển khai của chính chúng tôi
Orkas là ứng dụng máy tính đa tác tử. Các tác vụ dài là chuyện thường ngày ở đây, nên việc nén xuất hiện hằng ngày. Cách triển khai của chúng tôi kích hoạt theo ngưỡng token, nén khi ngữ cảnh đạt khoảng 80% cửa sổ. Trước khi viết bài này, không ai trong chúng tôi nghĩ điều đó có vấn đề.
Trong thực tế có khoảng ba ranh giới phổ biến: tỷ lệ phần trăm của cửa sổ, số lượt, hoặc để mô hình viết bản tóm tắt bao quát nội dung cũ. Cách của chúng tôi thuộc loại thứ nhất.
Hai cách đầu hoàn toàn không xem xét nội dung. Cách thứ ba có xem, nhưng giao toàn bộ việc quyết định điều gì quan trọng cho mô hình.
Cả ba đều trả lời câu hỏi khi nào tôi buộc phải bỏ bớt thứ gì đó. Câu hỏi bạn thực sự có là có thể bỏ gì một cách an toàn. Cắt tại ngưỡng sẽ loại bỏ nội dung cũ nhất, không phải nội dung ít quan trọng nhất.
Ranh giới mốc tiến độ và giả định bên dưới
Các mốc tiến độ trong bài trước có thể tạo ra ranh giới tốt hơn cả ba cách trên. Nhưng ở đây có một cái bẫy, và bài trước đã trình bày nó hơi quá suôn sẻ.
BEACON chứa một giả định gọi là tính chất Markov của mốc tiến độ. Nói đơn giản: khi bạn đạt một mốc, điều xảy ra tiếp theo chỉ phụ thuộc vào các mục tiêu con còn lại, không phụ thuộc vào cách bạn đến đó. Khi đã có chìa khóa, điều quan trọng là bạn mở cánh cửa nào, không phải bạn tìm thấy chìa khóa ra sao.
Điều đó nghe như một sự cho phép nén: qua một mốc tiến độ, đoạn trước đó có thể được thu gọn lại.
Nhưng đó là giả định, không phải sự thật. Bài báo viết ≈, không phải =, và các tác giả có thảo luận về những trường hợp nó không đúng.
Đủ cho huấn luyện, chưa đủ cho việc nén
Cùng một giả định, hai cách dùng, nhưng độ nghiêm ngặt chênh nhau cả một bậc độ lớn.
Trong huấn luyện, nó chỉ cần đúng về mặt thống kê. Nếu vài chục trong vài nghìn lượt chạy vi phạm giả định, độ chệch sẽ được san bằng khi lấy trung bình. Huấn luyện còn có tín hiệu ở cấp quỹ đạo bên dưới làm lớp dự phòng; loại bỏ lớp đó, ALFWorld giảm từ 91.4 xuống 23.4, thấp hơn nhiều so với không làm gì cả.
Trong việc nén, nó phải đúng ở từng trường hợp, với chính lần chạy trước mắt bạn. Chỉ cần bỏ nhầm một thứ một lần là tác vụ đó hỏng. Không có gì để lấy trung bình.
Vì vậy, việc bài báo dựa vào giả định này không có nghĩa là bạn có thể đưa nó sang việc nén. Hai cách dùng không đòi hỏi cùng một điều ở giả định ấy.
Bốn trường hợp giả định không đúng
Chúng tôi dùng những trường hợp này làm danh sách kiểm tra khi cân nhắc chính sách nén.
1. Kiến thức ngầm tích lũy trong quá trình. Ở một bước đầu nào đó, hệ thống xác lập rằng một API trả về dấu thời gian theo UTC. Điều này không thuộc mốc tiến độ nào, nhưng mọi bước sau đều cần đến.
2. Tài nguyên đã tiêu hao. Ngân sách token, hạn mức lệnh gọi, thời gian còn lại. Một mốc tiến độ không ghi lại tôi đã dùng 60% ngân sách, nhưng con số đó quyết định liệu còn đủ nguồn lực để thử lại hay không.
3. Tác dụng phụ phụ thuộc vào đường đi. Mốc tiến độ ghi đã tái cấu trúc xong. Ngay khi bắt đầu gỡ lỗi, bạn cần biết chính xác năm tệp nào đã được chỉnh sửa.
4. Bản thân mốc tiến độ được mô tả chưa đủ rõ. Đây là trường hợp tệ nhất trong bốn trường hợp. Trong bài báo, một mốc tiến độ là trạng thái môi trường hoàn chỉnh — bạn có chìa khóa hoặc không, không có gì mơ hồ. Một bước trong kế hoạch chỉ là một câu bằng ngôn ngữ tự nhiên. "Hoàn tất làm sạch dữ liệu" còn rất xa mới bao quát được những gì đã xảy ra trong đoạn đó.
Thay vào đó nên giữ lại những gì
Đừng chỉ giữ một bản tóm tắt. Bản tóm tắt do mô hình viết, và mô hình quyết định theo cảm nhận điều gì quan trọng.
Hãy giữ một tập trường cố định do con người chọn. Tối thiểu bốn trường:
- Không gian làm việc hiện có trạng thái ra sao — những tệp nào đã được chỉnh sửa và thành trạng thái nào.
- Còn bao nhiêu ngân sách — token, hạn mức lệnh gọi, thời gian.
- Những gì đã được xác lập — thông tin về UTC và mọi điều tương tự sẽ định hình các quyết định sau.
- Những gì vẫn chưa giải quyết xong — vấn đề từng gây cản trở, đã được xử lý bằng cách đi vòng và có thể quay lại.
Đối chiếu với bốn trường hợp thất bại ở trên, chúng tương ứng từng cặp một. Sự tương ứng đó là cách đơn giản nhất để đánh giá một chính sách nén đã đủ hay chưa.
Một nửa trong số này gần như không tốn gì. Như bài trước đã mô tả, hệ thống chủ đã ghi lại các sự kiện xác định sau mỗi lệnh gọi công cụ: tệp có thực sự được viết lại không, lệnh có thực sự chạy không. Dữ liệu đó được thu thập để xác minh mốc tiến độ, nhưng nó chính là ảnh chụp trạng thái không gian làm việc, nên việc nén có thể chuyển thẳng dữ liệu đó sang mà không cần nhờ mô hình tóm tắt lại.
Nửa khó nằm ở hai trường còn lại. Những gì đã được xác lập và những gì vẫn chưa giải quyết xong hiện chỉ tồn tại nếu mô hình viết chúng ra, và đó chính là lý do chúng là những thứ đầu tiên bị mất khi nén.
Điều này có thể đo lường, không cần tranh luận
Sau khi nén, nếu tác tử đọc lại một tệp đã bị loại khỏi ngữ cảnh hoặc hỏi lại một câu đã có đáp án, giả định đã không đúng với tác vụ đó và bằng chứng nằm ngay đó.
Việc thiết lập đo lường rất đơn giản: lấy giao giữa các đường dẫn tệp được đọc sau thời điểm nén với những đường dẫn đã ghi lại trước đó.
Với con số đó, những loại tác vụ nào có thể nén mạnh và những loại nào không trở thành một truy vấn thay vì một cuộc tranh luận thiết kế. Đây cũng là cách tiếp cận của bài đầu trong loạt này: đo trước, rồi mới thay đổi.
Những điểm cần dè dặt
Chưa có phần nào trong số này được phát hành. Chúng tôi đang ở giai đoạn thiết kế và thiết lập đo lường.
Việc giữ những trường nào và chi tiết đến đâu nên dựa trên dữ liệu về những gì thực sự phải truy xuất lại. Quyết định ngay bây giờ rất dễ dẫn đến quyết định sai.
Và đây chỉ là một trong nhiều cách tiếp cận. Vị trí ranh giới và cách định nghĩa các trường có thể hoàn toàn khác ở một dạng sản phẩm khác. Danh sách kiểm tra bốn trường hợp có thể áp dụng rộng rãi; câu trả lời cụ thể thì không.
Bài tiếp theo và cũng là bài cuối trong loạt này bàn về việc tự đánh giá: vì sao những bài học tác tử chắt lọc được cứ chung chung kiểu "hãy cẩn thận hơn", và một điều thực sự đáng ngạc nhiên về những gì đầu vào của nó có và không có.