Orkas Orkas
Trang chủ Blog Kiến trúc
Kiến trúc

Phát hiện vòng lặp không phải phát hiện đình trệ: Nhận diện tác tử loay hoay mà không lặp lại

Orkas có ba cơ chế bảo vệ chống lặp. Không cơ chế nào phát hiện được một mô hình có năng lực nhưng bị đình trệ, vì cả ba đều kiểm tra xem nó có đang lặp lại chính mình hay không — mà một mô hình mắc kẹt thì lại không làm vậy. Đây là điểm mù đó, định nghĩa tiến độ dựa trên đầu ra mà chúng tôi mượn từ BEACON, và những gì chúng tôi định đo lường trước khi thay đổi bất cứ điều gì.

Đây là bài đầu tiên trong loạt ghi chép thiết kế về các tác tử thực hiện nhiệm vụ dài hạn, xuất phát từ việc đọc kỹ BEACON (Đại học Chiết Giang, arXiv:2605.06078).

Để một tác tử hoạt động tốt xuyên suốt nhiệm vụ dài, chúng tôi cho rằng cần làm đúng hai điều:

  • Nó liên tục tiến về mục tiêu. Điều này gồm nén ngữ cảnh (có thể quên điều gì một cách an toàn), thiết kế mốc tiến độ (làm sao biết một bước thực sự hoàn tất) và ngăn đình trệ (khi nó mắc kẹt, phải có thứ nhận ra).
  • Nó có thể tự nhìn lại và cải thiện.

Bài này nói về ngăn đình trệ, vì đó là điều khiến chúng tôi tốn kém nhất.

Tóm tắt ngắn gọn Một tác tử loay hoay mà không lặp lại vẫn cần được phát hiện Orkas có sẵn tính năng phát hiện đình trệ, để một phiên chạy dài báo cho bạn biết nó đã mắc kẹt thay vì âm thầm tiêu hết ngân sách còn lại.
Tải Orkas — miễn phí

Triệu chứng

Chúng tôi nhận được báo cáo từ người dùng, và cũng thấy trong nội bộ: một số nhiệm vụ rất dài ngừng tiến triển giữa chừng.

Nhìn vào nhật ký, tác tử vẫn bận rộn — đọc tệp, tìm kiếm, chạy lệnh, không lúc nào nghỉ. Nhưng nửa giờ sau vẫn chẳng có gì tiến triển.

Giải thích ban đầu của chúng tôi là mất ngữ cảnh: quá trình nén làm mất ghi nhận rằng một hướng đã được thử, nên tác tử lại thử hướng đó. Khi đọc mã cùng với nhật ký, hóa ra đó chỉ là một nửa câu chuyện.

Chúng tôi đã có cơ chế bảo vệ — tới ba tầng

TầngTiêu chíNgưỡng
Lặp lại chính xácTên công cụ + đối số đã chuẩn hóa, giống hệt từng byteLOOP_WARN=3 cảnh báo / LOOP_HARD=5 buộc dừng
Gần trùng lặpGiống hệt ngoại trừ các trường id / dấu thời gian hay thay đổiNEAR_DUP_LOOP_WARN=6 / NEAR_DUP_LOOP_HARD=12
Hội tụ dấu hiệu loay hoay≥2 lần nén và ≥75% ngân sách vòng lặp công cụ đã tiêuSPIN_CONVERGENCE_MIN_COMPACTIONS=2
SPIN_CONVERGENCE_TOOL_LOOP_RATIO=0.75

Chú thích ở tầng thứ ba có nguyên văn như sau: Tín hiệu tổng hợp "có thể đang loay hoay sau khi mất ngữ cảnh". Đã có người thấy trước điều này. Vậy vấn đề chưa bao giờ là không xây dựng gì — mà là thứ chúng tôi xây không phát hiện được nó.

Điểm mù: cả ba đều là bộ phát hiện dựa trên đầu vào

Dấu hiệu nhận dạng mà mọi tầng dựa vào là tên công cụ + đối số đã chuẩn hóa. Điều đó chỉ trả lời đúng một câu hỏi: bạn có đang làm cùng một việc hai lần không?

Nhưng một mô hình có năng lực khi mắc kẹt không lặp lại các lệnh gọi. Nó làm thế này:

đọc tệp A → grep X → đọc lại A với phạm vi dòng khác
  → chạy một lệnh hơi khác → đọc tệp B → grep lần nữa …

Mỗi lệnh gọi có một dấu hiệu nhận dạng riêng. Cả ba tầng đều im lặng. Và trong suốt khoảng đó, số lượng thay đổi trạng thái có thể xác minh bằng không: không tệp nào thực sự được viết lại, không lệnh nào tạo ra kết quả mới, hoàn toàn không có gì không thể đảo ngược xảy ra.

Phát hiện vòng lặp không phải là phát hiện đình trệ. Loại thứ nhất nhìn vào đầu vào. Loại thứ hai phải nhìn vào đầu ra.

Bài báo cung cấp đúng định nghĩa dựa trên đầu ra đó

Phần thưởng trong từng đoạn của BEACON:

r_t = R_ms · γ^(t_k − t)    nếu đoạn kết thúc bằng một mốc tiến độ
    = 0                     nếu không

Một đoạn không kết thúc bằng mốc tiến độ sẽ nhận đúng bằng không, bất kể có bao nhiêu hành động trong đó. Số hành động không bao giờ xuất hiện trong công thức. Đây là cách hình thức hóa rõ ràng nhất cho bận rộn ≠ tiến triển mà chúng tôi từng thấy.

Lớp đường cơ sở còn nghiêm khắc hơn. Đường cơ sở là lợi tức trung bình của nhóm trên mỗi bước , nên một đoạn mất 8 bước trong khi trung bình nhóm là 5 sẽ có toàn bộ giá trị lợi thế bị kéo về phía âm, và mức phạt tăng theo mức vượt quá. Loay hoay không chỉ không được thưởng; nó còn bị phạt chủ động và tương ứng.

Hình 8 của bài báo cho thấy một quỹ đạo thất bại, trong đó hai hành động cuối nhận mức −2.20 giống hệt nhau. Phần đuôi đó — khoảng sau mốc tiến độ cuối cùng mà không bao giờ đạt được mốc tiếp theo — chính là hình dạng toán học của việc loay hoay. Và nó rất phổ biến: các quỹ đạo hoàn thành ít nhất một mục tiêu phụ nhưng thất bại ở nhiệm vụ tổng thể giữ ổn định ở mức 39–47% số mẫu.

Một thử nghiệm loại bỏ thành phần bác bỏ cơ chế kích hoạt theo số bước

Cách phân đoạnĐiểmso với đường cơ sở (72.8)
Chia ngẫu nhiên thành 5 phần74.2+1.4
Mốc tiến độ thực91.4+17.2

Chia theo số bước tùy ý gần như không có giá trị. Chia theo cấu trúc thực có giá trị rất lớn.

Giờ hãy nhìn lại tiêu chí tầng thứ ba của chúng tôi — đã tiêu thụ 75% ngân sách vòng lặp công cụ. Đó là cơ chế kích hoạt theo số bước tùy ý. Nó hỏi bạn đã tiêu bao nhiêu, chứ không phải đã đạt được gì. Cấu trúc đúng phải là:

✗  nếu số bước > N                                 → can thiệp
✓  nếu số bước > N VÀ không có mốc đã xác minh      → can thiệp

Điều kiện thứ hai sẽ không kích hoạt nhầm với một nhiệm vụ thực sự dài nhưng vẫn tiến triển, vì nhiệm vụ như vậy đạt các mốc trên đường đi. Điều kiện thứ nhất thì có.

Còn có một vòng phản hồi khuếch đại

Đặt các hằng số cạnh nhau. Nén được kích hoạt ở 82% cửa sổ ngữ cảnh. Cơ chế hội tụ dấu hiệu loay hoay cần hai lần nén cộng với 75% ngân sách vòng lặp mới kích hoạt.

loay hoay → ngữ cảnh đầy → kích hoạt nén → trạng thái bền vững bị lược bỏ khi tóm tắt
     → suy ra lại những gì đã mất → loay hoay thêm

Bộ phát hiện suy ra việc loay hoay từ quan sát rằng nén đã diễn ra nhiều lần — nhưng nén chính là bước gây mất trí nhớ. Nó đang phát hiện một triệu chứng phía sau, và phải chờ vòng lặp quay đủ hai lần.

Tệ hơn, cách can thiệp của nó là nhắc mô hình bám lại vào trạng thái bền vững. Nếu chính trạng thái đó đã bị lược bỏ khi nén, thì không còn gì để bám lại. Đây là bản vá ở lớp lời nhắc cho một vấn đề ở lớp trạng thái.

Điều chúng tôi đang bổ sung: phát hiện đình trệ dựa trên đầu ra

Một tầng thứ tư, xây từ hai bộ đếm. Cả hai đều được suy ra bằng quy tắc từ những quan sát công cụ mà hệ thống chủ đã ghi lại; không bộ đếm nào cần mô hình phán đoán.

Số bước kể từ mốc tiến độ được xác minh gần nhất. Thước đo tiến độ đơn giản nhất có thể, được dùng trong tiêu chí kết hợp ở trên thay vì dùng riêng.

Các thay đổi trạng thái mới đã loại trùng. Bộ đếm hữu ích hơn trong hai bộ đếm:

  • Một lần đọc tệp có mã băm nội dung trùng với lần đọc trước không phải thông tin mới — đọc lại cùng tệp ở phạm vi dòng khác không làm thay đổi mã băm.
  • Một lệnh có tên, mã thoát và mã băm đầu ra đều trùng với lần chạy trước không phải thông tin mới.
  • Một lần ghi mà mã băm sau bằng mã băm trước nghĩa là thực tế không có gì được ghi.

Bộ đếm này nhắm đúng vào trường hợp mà đối chiếu dấu hiệu nhận dạng bỏ sót: mọi hành động đều khác nhau, lượng thông tin thu được bằng không. Tiêu chí này vận hành theo quy tắc và không cần hiểu ngữ nghĩa.

Sau đó, áp lực nên được duy trì liên tục thay vì chỉ nhắc một lần:

đưa bộ đếm vào ngữ cảnh để mô hình nhìn thấy
  → buộc sửa kế hoạch (thừa nhận hướng này đã bế tắc)
    → hỏi người dùng
      → hủy chạy, nhưng giữ lại các mốc tiến độ đã đạt

Nấc cuối cùng đó rất quan trọng. Nếu phải dừng phiên chạy, nó nên dừng mà vẫn giữ được thành quả — chính là 39–47% tiến độ từng phần mà bài báo đo được là đang bị vứt bỏ.

Điều bài báo không cung cấp

BEACON là một phương pháp huấn luyện. Nó định hình gradient để chính sách được huấn luyện ít có xu hướng đi lan man hơn, nhưng nó không có cơ chế phát hiện hay can thiệp lúc chạy của riêng mình. Nó cung cấp định nghĩa về tiến độ, không phải bộ điều khiển. Ngưỡng, các nấc tăng mức can thiệp và điều kiện hủy chạy là những gì chúng tôi phải thiết kế.

Đường cơ sở trên mỗi bước của nó cũng cần độ dài đoạn trung bình của một nhóm làm tham chiếu. Trong môi trường thực tế, một nhiệm vụ của người dùng thường chỉ chạy đúng một lần, nên không có nhóm nào cả. Phương án thay thế tốt nhất hiện có là thống kê lịch sử của các nhiệm vụ tương tự, vốn nhiễu hơn đáng kể và không có bất kỳ bảo đảm cô lập phương sai nào của bài báo.

Bước đầu tiên là đo lường, không phải sửa

Trước khi thay đổi bất kỳ logic quyết định nào, chúng tôi muốn bổ sung đo lường và trả lời câu hỏi hiện chưa thể trả lời: trong các lần đình trệ xảy ra ở môi trường thực tế, bao nhiêu thuộc loại mất trí nhớ và bao nhiêu thuộc loại không có gradient?

  • Chủ yếu đi kèm với lượng thông tin thu được bằng không trong khi mọi dấu hiệu nhận dạng lệnh gọi đều khác nhau → loại không có gradient. Về cấu trúc, ba tầng hiện có không thể phát hiện, và phát hiện dựa trên đầu ra là cách khắc phục.
  • Chủ yếu đi kèm với đọc lại nội dung đã bị lược bỏ khi nén → loại mất trí nhớ. Điều cần sửa là những gì quá trình nén giữ lại.

Hai kết luận đó đòi hỏi những khoản đầu tư hoàn toàn khác nhau. Đo trước rẻ hơn thiết kế trước, và việc bổ sung đo lường gần như miễn phí vì các quan sát đã có sẵn.

Mọi điều ở trên đều dựa vào một khái niệm mà ghi chép này đã sử dụng nhưng chưa định nghĩa: một mốc tiến độ được xác minh . Ghi chép tiếp theo sẽ nói về điều đó. Vì sao tuyên bố một bước đã hoàn tất không phải bằng chứng rằng nó thực sự hoàn tất, hai nửa nào đã tồn tại trong sản phẩm nhưng chưa từng được kết nối, và một tiêu chí mà bài báo không có: nhìn vào tính không thể đảo ngược, không phải mức độ quan trọng.