Token Usage là gì?

Scrapeless Agent Browser cung cấp quyền truy cập trình duyệt cho các quy trình làm việc AI trên web.

Token usage là lượng đầu vào của mô hình và đầu ra được tạo, được đo bằng đơn vị mà mô hình ngôn ngữ sử dụng. Một token có thể biểu diễn một từ, một phần từ, dấu chấm câu, hoặc một chuỗi được mã hoá khác. Usage mô tả khối lượng xử lý; nó không đo trực tiếp chất lượng câu trả lời, độ chính xác thực tế, hoặc số lượng tác vụ đã hoàn thành.

Đối với chủ sở hữu ứng dụng, token usage quan trọng vì nó giúp giải thích giới hạn ngữ cảnh và mức tiêu thụ. Một câu trả lời ngắn mà người dùng thấy có thể đi sau một yêu cầu lớn chứa hướng dẫn, lịch sử hội thoại và kết quả công cụ. Hãy đo toàn bộ tương tác với mô hình thay vì ước lượng usage chỉ từ câu trả lời cuối cùng.

Những gì được tính là đầu vào của mô hình

Token usage của đầu vào có thể bao gồm hướng dẫn của ứng dụng, yêu cầu hiện tại của người dùng, lịch sử hội thoại được giữ lại, bằng chứng được truy xuất, và định nghĩa công cụ cung cấp cho mô hình. Cách tính chính xác phụ thuộc vào giao diện và mô hình. Vì vậy, đếm số từ trong tin nhắn của người dùng chỉ là một phần của bức tranh yêu cầu.

Hãy xem xét một trợ lý nghiên cứu giả định mở một trang sản phẩm dài. Việc truyền tải trang trong trình duyệt tự nó không tự động trở thành chi phí token của mô hình ngôn ngữ. Khi ứng dụng tuần tự hóa nội dung đã chọn và gửi nó tới mô hình, văn bản đó trở thành một phần đầu vào của mô hình. Gửi toàn bộ tài liệu HTML có thể tốn kém về không gian ngữ cảnh hơn nhiều so với chỉ gửi phần sản phẩm liên quan.

Giữ lại bản ghi về những gì ứng dụng của bạn thực sự đã gửi. Để gỡ lỗi, hãy tách phần hướng dẫn, phần hội thoại và phần bằng chứng khi có thể. Bạn không cần lưu trữ văn bản nhạy cảm vô thời hạn để đo các nhóm này. Độ dài tổng hợp và metadata truy vết theo phạm vi có thể giúp xác định chỗ nào một yêu cầu đã phình to mà không phải giữ lại từng tài liệu gốc.

Usage đầu ra và độ dài câu trả lời hiển thị

Token usage của đầu ra đo lường quá trình sinh của mô hình theo quy tắc tính toán của dịch vụ đã chọn. Văn bản mà người dùng nhìn thấy có thể không phản ánh mọi loại mục trong bảng tính usage. Một số giao diện báo cáo thêm chi tiết cho suy luận hoặc các phương thức khác, nên hãy dùng bản ghi usage trả về thay vì cho rằng các từ hiển thị giải thích được toàn bộ.

Giới hạn độ dài đầu ra là các điều khiển cho việc sinh, không phải dự đoán về mức tiêu thụ của một tác vụ. Hướng dẫn trả lời ngắn gọn có thể giảm bớt văn bản không cần thiết, nhưng nó không xoá phần đầu vào đã được gửi. Tương tự, giới hạn một câu trả lời có thể để lại không đủ chỗ cho một kết quả đầy đủ nếu tác vụ đòi hỏi giải thích chi tiết hoặc bản ghi có cấu trúc.

Với một công việc trích xuất giả định, hãy phân biệt giữa một bản ghi bị cắt cụt và một bản ghi ngắn nhưng hợp lệ. Cả hai đều có thể dùng ít token đầu ra. Trường hợp đầu là tác vụ thất bại; trường hợp sau có thể đã thành công. Hãy lưu cả độ đầy đủ và tính hợp lệ của bản ghi cùng với usage để một tối ưu hóa nào đó không âm thầm thay thế các câu trả lời hữu ích bằng những câu trả lời không đầy đủ.

Tokens, từ và cửa sổ ngữ cảnh

Tokens là đơn vị riêng theo mô hình, trong khi từ là đơn vị của ngôn ngữ tự nhiên. Một tỉ lệ cố định từ‑sang‑token chỉ là ước lượng thô và có thể thay đổi theo ngôn ngữ, dấu chấm câu, mã nguồn hoặc văn bản nhiều định danh. Các tokenizer khác nhau có thể tách cùng một chuỗi theo những cách khác nhau. Hãy đo bằng tokenizer và định dạng yêu cầu phù hợp với mô hình của bạn khi độ chính xác là quan trọng.

Bài nghiên cứu gốc về biểu diễn dưới từ (subword representation) giải thích cách các đơn vị nhỏ hơn có thể biểu diễn những từ hiếm hoặc lạ. Thiết kế đó giúp giải thích vì sao một tên kỹ thuật dài không nhất thiết là một token. Giới hạn độ dài văn bản hiển thị và giới hạn ngữ cảnh của mô hình là các ràng buộc có liên quan, nhưng không thể hoán đổi cho nhau.

Một cửa sổ ngữ cảnh giới hạn lượng thông tin mà mô hình có thể xem xét theo các quy tắc được công bố. Bản ghi token usage mô tả mức tiêu thụ; giới hạn ngữ cảnh mô tả dung lượng. Một yêu cầu có thể nằm trong dung lượng nhưng vẫn lãng phí phần lớn cho văn bản không liên quan. Nghiên cứu về việc sử dụng thông tin trong ngữ cảnh dài cho thấy việc nhét bằng chứng vào cửa sổ không chứng minh rằng mô hình sẽ sử dụng một cách đáng tin cậy mọi đoạn liên quan.

Vì sao các agent có thể tích lũy usage rất nhanh

Một agent có thể thực hiện nhiều lần gọi mô hình trước khi tạo ra câu trả lời cuối cùng, nên token usage ở cấp tác vụ là tổng của các lần gọi liên quan chứ không chỉ một câu trả lời. Mỗi quyết định có thể bao gồm hướng dẫn, trạng thái hiện tại và các quan sát. Việc liên tục mang theo các quan sát lớn có thể khiến những yêu cầu về sau lớn hơn nhiều so với câu hỏi ban đầu.

Hãy giữ các lần gọi mô hình tách bạch với các lần gọi công cụ trong bản truy vết. Một hành động trình duyệt có chi phí thực thi và kết quả riêng. Một lần gọi lập kế hoạch đọc kết quả đó sẽ có usage của mô hình. Quy trình thu thập dữ liệu web trực tiếp liên quan đến lớp công cụ đó. Hệ thống điều phối của bạn quyết định quan sát nào trở thành ngữ cảnh của mô hình và chúng được giữ lại bao lâu.

Các agent song song cũng có thể nhân đôi đầu vào. Nếu mỗi worker nhận cùng một gói bằng chứng đầy đủ, tổng usage có thể tăng lên ngay cả khi thời gian xử lý giảm. Đó có thể là đánh đổi hợp lý cho công việc độc lập, nhưng nó cần được thể hiện rõ trong sổ cái tác vụ. Hãy so sánh chất lượng tác vụ đã hoàn thành và tổng mức tiêu thụ thay vì đánh giá hiệu suất chỉ từ thời gian phản hồi.

Xây dựng một sổ cái usage hữu ích

Một sổ cái usage hữu ích liên kết mỗi lần gọi mô hình với một tác vụ, cấu hình mô hình, mục đích, các hạng mục token được báo cáo, và kết quả. Giữ nguyên các giá trị do nhà cung cấp trả về và đánh dấu các trường bị thiếu là không có sẵn. Chuyển một con số vắng mặt thành 0 sẽ làm báo cáo ngân sách của bạn có vẻ chính xác hơn nhưng lại che giấu việc đo lường chưa đầy đủ.

Tổng hợp ở nhiều cấp: cuộc gọi riêng lẻ, tác vụ hoàn chỉnh và một khoảng thời gian báo cáo đã định. Tổng hợp ở cấp tác vụ đặc biệt hữu ích cho các tác nhân vì các cuộc gọi lập kế hoạch và kiểm chứng nếu không sẽ bị ẩn sau một câu trả lời cuối cùng. Giữ phần công việc thất bại hoặc bị hủy hiển thị nếu nó đã tiêu tốn tài nguyên. Báo cáo chỉ dựa trên đầu ra thành công sẽ đánh giá thấp chi phí vận hành.

Xử lý ước tính sử dụng và mức tiêu thụ bị tính phí như các bản ghi riêng biệt cho đến khi được đối soát. Một ước tính tokenizer cục bộ có thể hỗ trợ kiểm tra chấp nhận, trong khi số liệu sử dụng do dịch vụ trả về có thể hỗ trợ giám sát lúc chạy. Hóa đơn có thể áp dụng các danh mục hoặc điều chỉnh riêng. Không suy diễn hóa đơn cuối cùng chỉ từ một tổng số thô khi dịch vụ cung cấp tài liệu về cách hạch toán chi tiết hơn.

Giảm lãng phí mà không loại bỏ bằng chứng cần thiết

Tối ưu hóa token hoạt động tốt nhất khi nó loại bỏ tài liệu không liên quan đồng thời giữ lại những gì tác vụ cần. Bắt đầu bằng cách kiểm tra các yêu cầu có kích thước quá lớn. Các ứng viên phổ biến bao gồm các lượt hội thoại trùng lặp, văn bản điều hướng từ các trang web, mô tả công cụ lặp lại và các tài liệu không trả lời câu hỏi hiện tại.

Sử dụng trích xuất và truy xuất để chọn các đoạn một cách có chủ đích. Giữ lại định danh nguồn và đủ văn bản xung quanh để diễn giải đúng một đoạn trích. Một đoạn nhỏ hơn nhưng làm mất một điều kiện hoặc ngoại lệ có thể khiến câu trả lời vừa rẻ hơn vừa sai. So sánh mức độ hỗ trợ bằng chứng trước và sau khi nén thay vì coi số lượng thấp hơn là bằng chứng đủ cho việc cải thiện.

Từ tác động của ngữ cảnh không liên quan có thêm một lý do nữa để chọn đầu vào cẩn thận. Giảm ngữ cảnh có thể là một biện pháp can thiệp về chất lượng cũng như về mức tiêu thụ, nhưng kết quả phụ thuộc vào những gì bạn loại bỏ. Tóm tắt cũng cần được kiểm tra vì chúng có thể loại bỏ các chi tiết mà một câu hỏi sau này cần đến.

Giữ chi phí trình duyệt và chi phí mô hình tách biệt

Hạ tầng trình duyệt và suy luận mô hình là các danh mục tiêu thụ khác nhau. Nếu bạn sử dụng Agent Browser for web interactions, hãy theo dõi công việc đó song song với các cuộc gọi mô hình mà không đổi tên nó thành sử dụng token. Một trang có thể yêu cầu công việc của trình duyệt ngay cả khi đoạn bằng chứng cuối cùng được trích ra rất ngắn.

Tùy chọn định giá Scrapeless pricing options mô tả các dịch vụ Scrapeless, trong khi nhà cung cấp mô hình của bạn quyết định cách hạch toán suy luận. Một báo cáo chi phí tác vụ hoàn chỉnh có thể kết hợp các danh mục sau khi giữ nguyên đơn vị gốc của chúng. Điều này cho phép bạn phân biệt một phiên trình duyệt dài với một prompt mô hình lớn khi điều tra lý do tăng ngân sách.

Ví dụ giả định, thay thế toàn bộ ngữ cảnh trang bằng một đoạn trích liên quan có thể giảm đầu vào cho mô hình trong khi lượng thực thi của trình duyệt không đổi. Ngược lại, tái sử dụng một tài liệu đã thu thập có thể giảm công việc thu thập mà không thay đổi văn bản gửi đến mô hình. Những biện pháp can thiệp đó ảnh hưởng đến các phần khác nhau của quy trình làm việc và lợi ích của chúng nên được báo cáo riêng.

Đặt ngân sách xoay quanh công việc đã hoàn thành

Một ngân sách tác vụ nên xác định điều gì xảy ra khi mức tiêu thụ dự kiến vượt quá hạn mức khả dụng. Bạn có thể thu hẹp tập nguồn, yêu cầu phạm vi nhỏ hơn hoặc trả về một kết quả rõ ràng là chưa hoàn chỉnh. Quyết định điều này trong logic ứng dụng để hành vi vẫn có thể dự đoán được và không phụ thuộc hoàn toàn vào việc mô hình có chú ý đến chỉ dẫn ngân sách hay không.

Đánh giá các tối ưu hóa dựa trên công việc đã hoàn thành: các bản ghi được chấp nhận, các câu trả lời có bằng chứng hỗ trợ hoặc một kết quả khác cụ thể cho tác vụ. Theo dõi độ trễ và tỷ lệ lỗi cùng với mức sử dụng. Một cấu hình tiết kiệm token nhưng khiến công việc hiệu đính thủ công tăng gấp đôi có thể là một lựa chọn vận hành tệ. Giữ nguyên thang chấm điểm trong khi so sánh các cấu hình để những khoản tiết kiệm rõ ràng phản ánh cùng một tiêu chuẩn hoàn thành.

Kết luận chính

Mức sử dụng token đo lường khối lượng xử lý của mô hình trên các đầu vào và đầu ra. Theo dõi nó ở cấp cuộc gọi và cấp tác vụ, sử dụng các trường hạch toán được báo cáo và giữ riêng biệt dung lượng ngữ cảnh với mức tiêu thụ. Cải thiện hiệu quả bằng cách lựa chọn bằng chứng cẩn thận, sau đó kiểm chứng rằng quy trình làm việc rẻ hơn vẫn hoàn thành cùng một tác vụ.