Ngữ cảnh

Mọi agent làm việc trong một cửa sổ ngữ cảnh: bản ghi liên tục về cuộc hội thoại của bạn, các tệp nó đã đọc và đầu ra của mọi công cụ đã chạy. Với tác vụ ngắn, bản ghi đó vẫn nhỏ. Với tác vụ dài, một cuộc rà soát điều tra nhiều bước, một đợt tái cấu trúc lớn, một buổi chiều trao đổi qua lại, nó tăng nhanh, và đó là lúc phần lớn agent âm thầm gặp vấn đề.

Vì sao lượt chạy dài chệch hướng

Khi cửa sổ đầy dần, mô hình mất khả năng truy cập đáng tin cậy vào các chỉ dẫn ban đầu. Nó bắt đầu quên ràng buộc bạn đặt ra từ đầu, dựa vào đầu ra công cụ đã cũ và chệch sang mục tiêu phụ. Điều quan trọng là chất lượng giảm từ lâu trước khi chạm giới hạn token cứng, không phải đúng lúc chạm giới hạn. Agent có thể trông vẫn ổn nhưng đang chạy trên ngữ cảnh không còn giữ được mạch công việc. Tiến thêm một chút, nó không chỉ suy giảm mà còn làm tràn cửa sổ, khiến lệnh gọi thất bại hoàn toàn.

Perch được xây dựng để chạy dài, nên nó coi cửa sổ ngữ cảnh là thứ phải chủ động quản lý trong từng lượt, không phải thứ cứ nạp đầy cho đến khi báo lỗi.

Quy trình thu gọn ngữ cảnh

Trước mỗi lần gọi mô hình, Perch đưa ngữ cảnh làm việc qua một quy trình có thứ tự. Mỗi giai đoạn ít tốn kém hơn và ít làm mất thông tin hơn giai đoạn sau, nên những bước tốn kém, làm mất thông tin chỉ chạy khi các bước rẻ, không mất thông tin chưa đủ.

Thứ nhất: Luôn cắt giảm artifact nặng trước

Lượt chạy dài phình to vì nội dung cồng kềnh, ít giá trị: bản chụp toàn bộ trang trình duyệt và ảnh chụp màn hình của operator. Perch cắt giảm chúng trong mọi lượt, trước cả khi kiểm tra ngân sách. Bản chụp trang được rút xuống những phần có thể thao tác (các điều khiển và cấu trúc mô hình có thể dùng), còn các bản cũ nhất chỉ giữ lại dấu vết ngắn. Ảnh chụp màn hình bị loại bỏ hoặc nén theo trần token cứng. Đây thuần túy là loại bỏ phần dư thừa, nên được thực hiện vô điều kiện. Một bản chụp DOM thô hay ảnh chụp màn hình có thể tốn hơn hàng chục lượt suy luận thực tế, và gần như không bao giờ còn cần thiết sau vài bước.

Thứ hai: Thu gọn nhẹ đầu ra công cụ đã cũ, không gọi mô hình

Nếu lượt chạy vẫn vượt ngân sách, Perch xóa phần nội dung của các kết quả công cụ cũ hơn và giữ nguyên những kết quả gần nhất. Cặp lệnh gọi công cụ và kết quả của nó vẫn nguyên vẹn, chỉ phần nội dung kết quả đã cũ được thay bằng dấu đánh dấu ngắn. Điều này quan trọng nhất với chính loại công việc Perch được xây dựng để xử lý: một lượt điều tra đọc hàng chục tệp và chạy nhiều phép kiểm tra sandbox tích lũy lượng đầu ra công cụ khổng lồ, trong khi mô hình hiếm khi cần văn bản thô của tệp đã đọc hai mươi bước trước, mà chỉ cần kết luận rút ra từ đó. Bước này ít tốn kém, không gọi thêm mô hình và thường giải phóng đủ chỗ để bỏ qua hoàn toàn bước tóm tắt tốn kém. Nó diễn ra âm thầm, vì xóa nội dung công cụ đã cũ là cách tiết kiệm chi phí thường lệ, không phải sự kiện đáng làm gián đoạn bạn.

Thứ ba: Tóm tắt các lượt cũ hơn, chỉ khi vẫn vượt ngân sách

Nếu lượt chạy vẫn vượt ngân sách sau các bước ít tốn kém, và chỉ khi đó, Perch tóm tắt phần hội thoại cũ hơn thành bản ghi gọn về những gì đã diễn ra và đã được quyết định, kết hợp cả bản tóm tắt trước đó, rồi tiếp tục làm việc từ bản ghi này. Đây là bước duy nhất tốn kém và làm mất thông tin, nên chạy cuối. Khi chạy, nó được hiển thị: bản ghi hội thoại đánh dấu thời điểm và báo những gì thay đổi.

Thứ tư: Chốt chặn thực thi giới hạn cứng

Để bảo đảm cuối cùng, Perch kiểm tra kích thước nội dung gửi thực tế theo giới hạn mô hình trước khi gửi, cắt từ các tin nhắn cũ nhất trong khi vẫn giữ lại một lượng tối thiểu các lượt gần đây. Đây là lưới an toàn khiến lỗi tràn không thể xảy ra về mặt cấu trúc: ngay cả trong trường hợp bất thường, yêu cầu đến mô hình luôn vừa giới hạn.

Đo cửa sổ thực tế, không ước đoán

Ước tính token theo số ký tự đếm thiếu một cách có hệ thống đối với nội dung dày đặc: CSV, JSON, mã và các cột số dài. Đó chính là những thứ đầy trong lượt xử lý tài chính hoặc tài liệu. Ước tính đơn giản khiến việc thu gọn kích hoạt muộn hoặc không bao giờ, và nội dung gửi bị tràn. Perch hiệu chỉnh ước tính theo số token prompt thực tế mà nhà cung cấp báo từ lần gọi trước trong cùng lượt chạy, và dùng số đó làm căn cứ cho ngưỡng kích hoạt thu gọn. Việc thu gọn kích hoạt theo kích thước ngữ cảnh thực, không dựa trên ước đoán sai theo đúng hướng gây hại.

Giữ mạch công việc hiện tại

Việc thu gọn không bao giờ đụng đến phần bạn đang làm ngay lúc này. Perch luôn giữ nguyên từng chữ phần cuối gần đây của cuộc hội thoại, với độ dài theo ngân sách token thực tế thay vì số tin nhắn cố định, và giữ lệnh gọi công cụ ghép cặp với kết quả để lịch sử gần đây mạch lạc. Ngữ cảnh cũ được nén; mạch công việc hiện tại được giữ nguyên.

Tuân thủ ngân sách thực của mô hình

Perch thu gọn theo giới hạn ngữ cảnh thực sự áp dụng cho lượt chạy của bạn, kể cả cửa sổ lớn hơn mà cấp cao hơn mở ra, không phải cửa sổ nguyên bản của mô hình nền đang phục vụ lượt đó. Nó cũng nhắm đến ngân sách làm việc thực có khoảng dự phòng thay vì ép sát dưới trần rồi đầy lại ngay bước sau, để mô hình còn chỗ suy nghĩ cho các lượt tiếp theo.

Hiển thị rõ, không âm thầm

Việc thu gọn thực sự là điều bạn có thể thấy. Đồng hồ ngữ cảnh cho biết cửa sổ đã đầy đến đâu, và khi Perch chạy bước tóm tắt, nó đánh dấu thời điểm trong bản ghi hội thoại và báo những gì thay đổi: đã giải phóng bao nhiêu, đã tóm tắt bao nhiêu, bản tóm tắt lớn thế nào và giữ lại bao nhiêu lịch sử gần đây. Bạn không bao giờ phải đoán agent còn giữ được mạch công việc hay không. Các bước nền ít tốn kém diễn ra âm thầm; bước duy nhất làm mất thông tin luôn được hiển thị.

Vì sao điều này quan trọng

Đây là khác biệt giữa agent trình diễn tốt với tác vụ năm bước và agent bạn có thể tin tưởng trong lượt chạy dài có rủi ro cao. Cuộc rà soát điều tra gồm hàng chục lần đọc tệp và kiểm tra sandbox phải bám vào câu hỏi ban đầu suốt quá trình, và không được thất bại giữa chừng vì tràn cửa sổ. Perch giữ công việc dài chính xác và trong giới hạn ngay từ thiết kế, để câu trả lời cuối cùng có cơ sở từ cùng những chỉ dẫn bạn đưa ra lúc đầu.