トークン使用量とは何ですか？

Scrapeless Agent Browser は、ウェブベースの AI ワークフロー向けにブラウザーアクセスを提供します。

トークン使用量は、言語モデルが入力として受け取り、出力として生成したテキスト量を、そのモデルが用いる単位で測ったものです。トークンは、単語、単語の一部、句読点、その他のエンコードされたシーケンスを表すことがあります。使用量は処理したボリュームを示すものであり、回答の品質、事実の正確さ、または完了したタスクの数を直接測定するものではありません。

アプリケーション所有者にとってトークン使用量が重要であるのは、コンテキストの制限や消費量を説明するのに役立つためです。短い表示上の回答であっても、その背後には指示、会話履歴、ツールの結果を含む大きなリクエストが存在しうるからです。最終的なレスポンスだけから使用量を推定するのではなく、モデルとのやり取り全体を測定してください。

モデル入力として数えられるもの

入力トークンの使用には、アプリケーションの指示、現在のユーザーからのリクエスト、保持された会話履歴、取得された証拠、およびモデルに提供されたツール定義が含まれる場合があります。正確な計算方法はインターフェースとモデルによって異なります。したがって、ユーザーメッセージの単語数はリクエストの一部だけを示すものにすぎません。

仮想的なリサーチアシスタントが長い商品ページを開く状況を考えてみてください。ブラウザでのデータ転送そのものは、自動的に言語モデルのトークン料金にはなりません。アプリケーションが選択したコンテンツをシリアライズしてモデルに送信した時点で、そのテキストがモデル入力の一部になります。関連する商品セクションだけを送るのに比べて、HTML ドキュメント全体を送信することはコンテキスト領域の面で遥かに高コストになり得ます。

アプリケーションが実際に送信した内容の記録を保持してください。デバッグのために、可能であれば指示部分、会話部分、証拠部分を分けてください。これらのカテゴリを測定するために機密テキストを無期限に保存する必要はありません。集計された長さやスコープ化されたトレースメタデータは、元のすべての文書を保持することなく、どこでリクエストが大きくなったかを特定するのに役立ちます。

出力の使用と可視応答の長さ

出力トークン使用量は、選択されたサービスの計測ルールに基づいてモデル生成を測定します。ユーザーが目にするテキストは、すべての計測カテゴリを必ずしも表していない場合があります。一部のインターフェースでは、推論やその他のモダリティに関する追加の詳細を報告するため、目に見える単語数から合計を推測するのではなく、返される使用状況記録を使用してください。

出力長の制限は、タスクがどれだけのトークンを消費するかの予測ではなく、生成に対する制御です。簡潔な回答の指示は不要な散文を減らせますが、すでに送信された入力を取り除くことはありません。同様に、回答の長さを制限すると、タスクが詳細な説明や構造化された記録を必要とする場合に、完全な結果を出すための十分な余地が残らないことがあります。

仮想的な抽出ジョブにおいて、切り捨てられたレコードと、有効だが短いレコードを区別すること。どちらも出力トークン数が少ない場合がある。前者はタスクに失敗しており、後者はタスクに成功している可能性がある。レコードの完全性と検証を使用状況と併せて管理し、最適化によって有用な回答が、気づかれないまま不完全なものに置き換えられないようにすること。

トークン、単語、コンテキストウィンドウ

トークンはモデル固有の単位であり、単語は人間の言語単位です。固定された単語対トークン比は大まかな推定値であり、言語、句読点、ソースコード、識別子の多いテキストによって変化する可能性があります。異なるトークナイザーは同じ文字列を異なる方法で分割することがあります。精度が重要な場合は、そのモデルに適したトークナイザーとリクエスト形式で測定してください。

元の サブワード表現の研究 小さい単位であれば、まれな語やなじみのない語を表現できることを説明しています。この設計により、長い専門的な名称が必ずしも1トークンになるとは限らない理由が分かります。画面上に表示されるテキストの長さの制限と、モデルのコンテキストの制限は関連する制約ですが、同一のものとして扱うことはできません。

コンテキストウィンドウは、モデルがその文書化されたルールの下でどれだけの情報を考慮できるかを制限する。トークン使用量は消費量を記録し、コンテキスト上限は容量を示す。リクエストは容量に収まっていても、そのほとんどを無関係なテキストに浪費しうる。研究では 長いコンテキスト情報の利用 これは、証拠をウィンドウ内に収めることが、そのモデルがあらゆる関連する文章を信頼できる形で利用することを保証するわけではないことを示している。

エージェントが使用量を急速に蓄積し得る理由

エージェントは最終的な回答を出力する前に、複数回モデルを呼び出すことができます。そのため、タスクレベルのトークン使用量は、1 回の応答ではなく、関連する呼び出しすべての合計になります。各決定には、指示、現在の状態、観測結果を含めることができます。大きな観測結果を繰り返し後続のステップに引き継ぐと、後半のリクエストは初期の質問よりもはるかに大きくなる可能性があります。

モデルの呼び出しとツールの呼び出しは、トレース内で明確に区別してください。ブラウザーアクションには、それ独自の実行コストと結果があります。その結果を読み取る計画呼び出しは、モデルの使用に含まれます。 ライブ Web データ取得ワークフロー ツール層に関する懸念事項です。オーケストレーションは、どの観測結果をモデルのコンテキストに含めるか、そしてそれらをどれくらいの期間保持するかを決定します。

並列エージェントは入力を複製することもあります。各ワーカーが同じ完全なエビデンスパケットを受け取る場合、経過時間が短縮されても、合計使用量が増加する可能性があります。それは独立した作業のためには妥当なトレードオフかもしれませんが、タスク台帳で可視化されるべきです。応答時間だけから効率を判断するのではなく、完了したタスクの品質と総消費量を比較してください。

有用な使用台帳を作成する

有用な使用台帳は、各モデル呼び出しをタスク、モデル構成、目的、報告されたトークンカテゴリ、および結果と関連付けます。プロバイダから返された値は報告どおりに保持し、不足しているフィールドは利用不可としてマークします。存在しない数値をゼロに変換すると、測定が不完全であることを隠しつつ、予算レポートがより正確であるかのように見えてしまいます。

複数のレベルで集計します: 個々の呼び出し、タスク全体、および定義されたレポート期間です。タスクレベルの集計は、エージェントにとって特に有用です。なぜなら、計画や検証の呼び出しが、最終的なひとつの回答の裏に隠れてしまう可能性があるからです。リソースを消費したのであれば、失敗またはキャンセルされた作業も見える状態に保ちます。成功した出力のみのレポートは、運用コストを過小評価します。

利用見積もりと請求対象の消費は、照合が完了するまでは別々のレコードとして扱います。ローカルのトークナイザーによる見積もりは受入れチェックを支援でき、一方でサービスから返される使用量は実行時モニタリングを支援できます。請求では別のカテゴリや調整が適用される場合があります。サービスがより詳細な会計方法を文書化しているときに、1つの生トータルから最終請求書を推測してはいけません。

必要な証拠を残したままムダを減らす

トークン最適化が最もうまく機能するのは、タスクに必要なものを維持しつつ無関係な内容を削除できる場合です。まずは過大なリクエストを精査することから始めます。よくある候補としては、重複した会話ターン、Webページのナビゲーションテキスト、繰り返されるツール説明、現在の質問に答えていない文書などがあります。

抽出と検索を使って、必要な箇所を意図的に選択します。出典識別子と、その箇所を正しく解釈するのに十分な前後のテキストを保持します。条件や例外を落としてしまうような小さすぎる断片は、回答を安くする一方で誤りにもつながり得ます。単にトークン数の減少を改善の証拠とみなすのではなく、圧縮の前後で証拠による裏付けを比較してください。

The effects of irrelevant context は、入力を慎重に選択すべきもうひとつの理由を示しています。コンテキストの削減は、消費量に対する介入であると同時に品質に対する介入にもなり得ますが、結果は何を削除するかに依存します。サマリーも、後の質問で必要となる細部を捨ててしまう可能性があるため、検証が必要です。

ブラウザコストとモデルコストを分けて管理する

ブラウザ基盤とモデル推論は、別々の消費カテゴリです。もし Agent Browser for web interactionsを使用している場合、その作業はモデル呼び出しと並行して追跡しますが、それをトークン使用量という名前に変更してはいけません。最終的な証拠抜粋が短くても、ページによってはブラウザ処理が必要になることがあります。

The Scrapeless pricing options は Scrapeless サービスについて説明しており、一方で推論の会計はモデルプロバイダが決定します。完全なタスクコストのレポートでは、元の単位を維持したうえでこれらのカテゴリを組み合わせることができます。これにより、予算増加を調査する際に、長いブラウザセッションと大きなモデルプロンプトとを区別できます。

仮想的な例として、ページ全体のコンテキストを関連する抜粋に置き換えることで、ブラウザ実行を変えずにモデル入力を削減できる場合があります。逆に、すでに収集済みの文書を再利用することで、モデルに送信するテキストを変えずに収集作業を減らせる場合もあります。これらの介入はワークフローの異なる部分に影響し、その利点も別々に報告されるべきです。

完了した作業を基準に予算を設定する

タスク予算では、想定される消費量が利用可能な枠を超えた場合に何が起きるかを定義する必要があります。情報源セットを絞り込んだり、スコープを小さく依頼したり、明らかに不完全な結果を返したりする選択肢があるかもしれません。こうした振る舞いはアプリケーションロジックで決定し、モデルが予算に関する指示に気づくかどうかだけに依存しない、予測可能な挙動を保ちます。

最適化は、完了した作業に対して評価します: 受理されたレコード、裏付けのある回答、その他のタスク固有の成果などです。使用量とともにレイテンシと失敗率も追跡します。トークンを節約できても、人手での修正作業が2倍になるような構成は、運用上の選択として不適切かもしれません。構成を比較する間は採点基準を安定させ、見かけ上の節約が同じ完了基準を反映しているようにします。

まとめ

トークン使用量は、入力と出力を通じたモデル処理のボリュームを測定します。呼び出しおよびタスクのレベルで追跡し、報告される会計フィールドを使用し、コンテキスト容量と消費を分けて扱います。証拠を慎重に選択することで効率を改善し、そのうえで、より安価なワークフローでも同じタスクを完遂していることを確認します。