Một bước agent - 120.000 token: chúng đi đâu và cách chúng tôi khắc phục
Một agent tự động có thể tiêu thụ nhiều token hơn dự kiến do việc gửi lặp lại toàn bộ ngữ cảnh trong mỗi bước của vòng lặp agent. Bài viết mô tả cách Uma Computer phát hiện ra rằng nguyên nhân thực sự không phải là lịch sử hội thoại, mà là chi phí nhân lên của các chỉ dẫn hệ thống, lược đồ công cụ và bộ nhớ, đồng thời trình bày ba tối ưu hóa: chuyển khối lượng sang các công cụ theo yêu cầu, chuyển sang ngân sách ký tự với các điểm đánh dấu cắt rõ ràng và kỳ vọng tốc độ minh bạch.
Các nhà phát triển của Uma Computer, một agent tự động thực hiện các tác vụ như tìm kiếm web, tạo media và cắt video, đã điều tra vì sao một yêu cầu của người dùng tốn 38 credit thay vì chỉ bằng một phần ba con số đó như dự kiến. Dữ liệu tính phí cho thấy có 119.208 prompt token nhưng chỉ 1.018 completion token, nghĩa là model chủ yếu đang đọc chứ không viết. Giả thuyết ban đầu là do lịch sử hội thoại quá dài, nhưng cuộc hội thoại gây vấn đề thực tế chỉ có hai tin nhắn với tổng cộng 530 ký tự. Kết quả đo đạc cho thấy ngữ cảnh (context) mỗi bước là 13.900 token, và với 9 bước thì tổng cộng lên tới khoảng 120.000 token; phần chi phí phụ trội này bị nhân lên theo số bước trong vòng lặp của agent. Ngoài ra, nhà cung cấp dịch vụ luôn dự trù chi phí theo trường hợp xấu nhất bằng cách đặt max_tokens ở mức cao, dẫn đến lỗi HTTP 402 dù số dư tài khoản vẫn đủ. Giải pháp khắc phục bao gồm chuyển phần ngữ cảnh được tải sẵn (preloaded context) sang các công cụ gọi theo yêu cầu (on-demand tools), sử dụng ngân sách ký tự (character budget) có phân mức ưu tiên cùng các dấu hiệu cắt bớt (truncation marker) rõ ràng, và minh bạch hóa kỳ vọng về tốc độ xử lý. Bài viết nhấn mạnh rằng không nên bao giờ âm thầm giấu ngữ cảnh khỏi model, và các tối ưu hóa cần được kiểm chứng trên những trường hợp cụ thể, vì nhóm phát triển suýt tối ưu sai cho một trường hợp mà lịch sử hội thoại hoàn toàn không liên quan.
Nguồn: Habr — хаб ML —
bản gốc