利益:
- トークン、コンテキストウィンドウ、マルチモーダリティの概念を日常の言語で説明できる能力
- タスクに広範なコンテキストまたはマルチモーダリティが必要かどうかを診断する
- これらの概念がコストやモデルの選択にどのような影響を与えるかを考慮する能力
ここまでで、プロバイダーとモデル タイプについて理解しました。ただし、適切なモデルを選択するには、モデルが「内部」でどのように機能するかを理解することも必要です。なぜなら、価格、容量、可用性の決定はすべて、トークン、コンテキスト ウィンドウ、マルチモダリティという 3 つの中心的な概念に依存しているからです。これらの概念を知らない人は、価格表を読んで「この文書はモデルに適合するだろうか?」と疑問に思うことはできません。質問に答えることができず、視覚的な処理がいつ必要なのかもわかりません。この単元を終了するまでに、これら 3 つの概念を日常の言葉で説明し、仕事に広範なコンテキストが必要か、それともマルチモダリティが必要かを診断し、コストへの影響を考慮できるようになります。
トークン: Word の代わりにモデルによって使用される単位
人工知能モデルはテキストを単語ごとに処理するのではなく、トークンと呼ばれる小さな部分に分割して処理します。トークン。単語、単語の一部、句読点、またはスペースを使用できます。大まかに計算すると、英語の平均トークンは約 4 文字で、100 単語は約 130 ～ 150 トークンになります。トルコ語では、語尾に接尾語があり長い単語があるため、この割合はわずかに高くなる可能性があります。言い換えれば、同じ意味を持つトルコ語のテキストは、英語よりもわずかに多くのトークンを消費します。
これを知ることがなぜ重要なのでしょうか?なぜなら、すべてがトークンで課金され、測定されるからです。モデルに送信するテキスト (入力) とモデルによって生成される応答 (出力) は、別個のトークンとしてカウントされます。請求書とモデルの容量は両方ともトークン単位です。
ヒント: テキストに含まれるトークンの数を概算するには、文字数を 4 で割ります。 4,000 文字の電子メールは約 1,000 トークンに相当します。トルコ語では、安全側を保つために少し高い値を想定します。
コンテキスト ウィンドウ: モデルの「短期記憶」
コンテキスト ウィンドウは、モデルが一度に記憶できるトークンの総量です。入力と出力はこのウィンドウ内に収まる必要があります。一度にテーブルの上に広げられる紙の量のようなものだと考えてください。テーブルに収まらない紙はその瞬間、あなたの視野から外れます。
モデルのコンテキスト ウィンドウが 200,000 トークンの場合、これは約 150,000 ワード、または中型の書籍数冊に相当します。 100 万個のトークンにより、全体としてさらに大きなドキュメントを処理できます。現在の一部の強力なモデル (Claude Opus 4.8 や Sonnet 5 など) は 100 万のトークン コンテキストを提供しますが、軽量モデルのウィンドウは小さいことがよくあります (Haiku 4.5 の 200,000 トークンなど)。
なぜ重要なのでしょうか?ドキュメントがコンテキスト ウィンドウに収まらない場合、モデルはドキュメントをすべて一緒に見ることができないためです。 500 ページの契約全体を 200,000 トークン モデルに与えることはできません。ドキュメントを複数の部分に分割するか (部分間の関係が失われる可能性があります)、より広範なコンテキストを持つモデルを選択します。
注意: コンテキスト ウィンドウが大きいからといって、すべてのドキュメントをそのまま入力するのは賢明ではありません。ウィンドウに投入するトークンが多ければ多いほど、支払う金額も高くなります。場合によっては、モデルが非常に長いテキストの中間の詳細を見逃す可能性があります。多くの場合、機能する部分のみを送信する方が安価で正確です。
コンテキストウィンドウは決定基準です
クエスト
必要なおおよそのコンテキスト
適正レベル
短い電子メールの返信
数百のトークン
軽量
1ページにまとめたもの
数千トークン
ライト/バランスのとれた
40 ページのレポート分析
~30,000 トークン
バランスが取れている/強い
300ページにわたる契約書レビュー
~250,000 トークン
幅広いコンテキストを備えた強力な機能
数百ものドキュメントを一度に処理する
500,000+ トークン
最も広範なコンテキスト
この表は、「どのモデルですか?」という質問に答えます。これは、質問の一部がドキュメント サイズによって直接的に回答されることを示しています。短いジョブのために大規模なコンテキストを備えた高価なモデルを購入するのは無駄です。ウィンドウが小さいモデルは、大きな文書には不向きです。
マルチモダリティ: テキストを超えて
マルチモダリティとは、テキストだけでなく複数の種類のデータ (画像、音声、場合によってはビデオ) を処理するモデルの機能です。ここでの「モーダル」は「データ型」を意味します。マルチモーダルとは「たくさんの種類」という意味です。
- テキスト専用モデル: 書かれたテキストのみを読み書きします。
- マルチモーダル モデル: 請求書の写真を読み取り、グラフ上の傾向を解釈し、手書きのメモを解読し、場合によっては音声録音を文字に起こすことができます。
なぜ重要なのでしょうか?ビジネスの性質上、マルチモダリティが必要になる場合があるためです。請求書の画像から金額を抽出する会計チーム、製品の写真を分類する電子商取引チーム、損傷写真を評価する保険チームは、テキストを読み取るだけのモデルではこの仕事を行うことができません。これらのタスクには視覚処理が不可欠です。
3 つの現実的なケース
ケース 1 — 驚くべきトークンコスト。コンテンツ チームは、各ブログ投稿を作成する際に、モデルに 20 ページの「ブランド ガイド」ドキュメントも送信します。このガイドは約 15,000 トークンです。彼らは毎月 2,000 件の記事を作成します。したがって、ガイドを何度も送信するだけで、3,000 万トークンの入力が必要になります。ガイドを短縮し、該当箇所（約2,000トークン）のみを送付することで入力を7分の1に削減し、請求額を大幅に削減します。
ケース 2 — コンテキスト ウィンドウだけでは十分ではありません。ある法律事務所は、280ページにわたる合併契約書の見直しを希望している。彼らが試した最初のモデルには 200,000 トークンのバインディングがあり、ドキュメントは適合しませんでした。文書がバラバラになると、モデルは最初のセクションの記事が最後のセクションの記事と矛盾していることに気づくことができません。 100万トークンコンテキストを持つモデルに切り替えると、文書全体を読み取り、矛盾を捉えます。ここでは、コンテキスト ウィンドウが精度を直接決定します。
ケース 3 — マルチモダリティは必須です。保険会社は、車両の損傷写真から事前評価を行いたいと考えています。これは、テキストを読み取るだけのモデルでは不可能です。写真を「見る」マルチモーダルなモデルが必要です。マルチモーダルモデルに切り替える際には、写真内の損傷の位置と程度を大まかに分類し、専門家に指示する事前審査システムを確立します。ただし、最終的な決定は人間の専門家が行うと彼らは指摘している。なぜなら、モデルは予備的なスクリーニング ツールであり、最終的な言葉ではないからです。
弱いプロンプト / 強いプロンプト
弱いプロンプト:
この文書を要約してください。 [長すぎる文書が貼り付けられました]
強力なプロンプト:
40 ページの報告書を以下に要約します。まず、レポート内のトークンのおおよその数を推定し、それが典型的なバランスのとれたモデルのコンテキスト ウィンドウ内に収まるかどうかを教えてください。次に、次の形式で要約を提供します: 5 項目の概要 + 3 つの危険な調査結果。レポート内の情報のみを使用してください。不明な部分には「レポートでは不明」とマークしてください。 【報告】
強力なプロンプトはトークンとコンテキストの両方を認識し、出力の形式と検証可能性を制御します。
コピー可能なテンプレート
1. トークンの予測:
次のテキストのトークンのおおよその数を推定し、これを入力コストの観点から解釈します: "[TEXT]"。トルコ語であることを考慮して、少し丸めてください。
2. コンテキストの可用性チェック:
私の仕事は、次のドキュメントを処理することです: 月あたり平均 [PAGES] 個の [QTY] ドキュメント。このサイズにはどのコンテキスト ウィンドウが必要ですか?ライト/バランス/ストロングのどのレベルで十分ですか?解体する必要がある場合、どのようなリスクが生じますか?
3. 多様な診断:
私のワークフロー: [説明]。このストリームにはビジュアル、オーディオ、またはビデオの処理がありますか?その場合、マルチモーダル モデルが必要ですか、それともテキストに変換 (OCR/文字起こし) し、テキスト モデルで解決できますか? 2 つのパスの長所と短所を比較してください。
4. コンテキストの最適化:
リクエストのたびにモデルにドキュメントを送信しますが、そのほとんどは不要です。この文書から[TASK]に実際に必要な部分を抽出するにはどうすればよいですか?入力を削減する 3 つの具体的な方法を提案し、推定されるトークンの節約量を示します。
よくある間違い
- トークンを単語と間違える: トークンは単語とは異なります。請求書と容量は常にトークンで表されるため、言葉で計算すると誤解を招きます。
- コンテキスト ウィンドウが無限であると考える: すべてのモデルには限界があります。ドキュメントが適合していないと、モデルは全体を見ることができません。
- 不必要な大きなコンテキストの使用: 短いジョブのために大きなコンテキストを備えた高価なモデルを購入します。あるいは、要求ごとに膨大な書類に記入し、無駄に支払うこともあります。
- マルチモダリティの想定: すべてのモデルがビジュアルを処理できるわけではありません。視覚的な作業の場合は、モデルがマルチモーダルであることを確認せずに開始します。
- トルコ語のトークン負荷を忘れる: トルコ語のテキストは通常、同じ意味に対してわずかに多くのトークンを消費します。コスト見積もりではこれを無視します。
要約すると
- トークンは、モデルがテキストを処理する小さな単位です。入力と出力は測定され、トークンとして個別に請求されます。
- コンテキスト ウィンドウは、モデルが一度に記憶できるトークンの合計です。ドキュメントのサイズはモデルの選択に直接影響します。
- マルチモダリティとは、ビジュアル/オーディオなどの非テキスト データを処理するモデルの機能です。映像作品には欠かせません。
- これら 3 つの概念は両方とも「どのモデルか?」という質問に関連します。 「料金はいくらですか?」それが質問の基礎となります。
アプリケーションタスク
ビジネスで繰り返し行われる AI タスクを選択します。 1 番目のテンプレート (トークン予測) で、このタスクの一般的な入力に含まれるトークンの数を計算させます。次に、テンプレート 2 (コンテキストの可用性チェック) でどのレベルが十分であるかを判断します。視覚的な仕事をしている場合は、3 番目のテンプレート (マルチモーダル診断) でマルチモーダル モデルが必要かどうかを明確にします。結果として得られたトークンの推定値は、次のユニットのコスト計算に使用されます。
チェックリスト
- [ ] 私はトークンの概念と、テキストに含まれるトークンの数を大まかに見積もる方法を知っています。
- [ ] コンテキスト ウィンドウを「テーブル/メモリ」に例えて説明できます。
- [ ] ドキュメントがモデルに適合するかどうかを評価できます。
- [ ] 複合性が不可欠な場合は診断できます。
- [ ] トルコ語のトークンのオーバーヘッドと不要なコンテキストのコストを考慮します。