実務での効き方
文脈の長さで生成内容が変わる境目｜1Mと200Kの間に中間がない
「文脈が長いモードのほうがいいのか」を迷っているなら、順番が逆です。先に自分の入力が何トークンかを測ってください。単価は 1 → 3 → 5 → 10 と段階的なのに、文脈は1Mが4つと200Kが1つで中間がありません。200Kに収まるかどうかで、選択肢そのものが決まります。
このサイトはAnthropicの公式サイトではありません。モデルの提供状況・仕様・料金は変わる可能性があるため、実装や契約の前には公式のドキュメントとご自身のアカウント設定を確認してください。
先に結論
- 自分の入力のトークン数を先に測る。トークン数を数えるエンドポイントがあります。「たぶん収まる」で進めると途中で切れます
- 200Kに収まるなら5モード全部が選択肢。収まらないなら1Mの4つから選ぶ。単価より先にこの判定です
- 分割してよいのは、1件ずつ独立して判定できる作業と、入力と出力が1対1で対応する変換だけ。比較や一貫性が要る作業は、分割した時点で目的が達成できなくなります
- 「文脈が足りない」と感じたら、渡すものを減らせないかを先に考える。機械的に判定できる部分をコードで済ませると、モデルに渡す量は桁で減ります
なぜ文脈が生成内容を変えるのか
文脈の長さは「性能」ではなく「1回にどれだけ材料を渡せるか」です。ここが足りないと、次のどちらかが起きます。
- 渡せなかった材料が結論に反映されない。10ファイルのうち6ファイルしか渡せなければ、残り4ファイルの内容は考慮されません
- 分割して渡すことになり、前半の内容が後半に効かなくなる。分けた時点で、横断的な判断ができなくなります
2番目のほうが厄介です。分割しても処理自体は動くので、失敗しているように見えません。出てくる結果は、それぞれの断片としては妥当です。ただ、全体を見渡した判断にはなっていません。
実例を挙げると、複数ページにまたがる重複を見つける作業がこれにあたります。1ページずつ渡すと、どのページも単体では問題なく見えます。重複はページ同士を並べたときにしか現れません。
自分の入力が何トークンか先に測る
「たぶん収まる」で進めると、途中で切れます。先に測ってください。トークン数を数えるエンドポイントがあります。
目安としては、日本語の文章なら文字数と近いか少し多い程度です。ただしこの目安はコードやHTMLでは通用しません。タグ、記号、インデントがそれぞれトークンを消費するので、文字数からの見積もりは大きく外れます。HTMLを大量に読ませる場合は、実際に数えたほうが早いです。
測るときは、入力の全体を対象にしてください。指示文だけでなく、読み込ませるファイル、それまでのやり取り、システム側の指示も全部が入力です。
200Kに収まるかで選択肢が分かれる
| 200Kに収まる | 収まらない | |
|---|---|---|
| 選べるモード | 5つすべて | 1Mの4つ |
| 入力単価の下限 | $1.00 / 1M | $3.00 / 1M |
| できること | 件数の多い単純な処理を安く回せる | 横断的な判断ができる |
この判定を先にやっておくと、モード選びが機械的になります。収まるなら安いほうから試す、収まらないなら1Mの中から選ぶ、というだけです。
収まらない場合の分割のしかた
1Mでも収まらない規模になったら分割することになりますが、分け方で結果が変わります。
分けてよいもの
- 1件ずつ独立して判定できる作業。各ページが基準を満たすかどうか、といった判定です。他のページの内容は要りません
- 決まった形への変換。入力と出力が1対1で対応しているものです
分けてはいけないもの
- 比較が必要な作業。重複の検出、どちらを残すかの判断、全体の中での位置づけ。分けた時点で目的が達成できません
- 一貫性が要る作業。用語を揃える、重複しない見出しを付ける、といったものです。分けると同じ見出しが複数できます
比較が必要なのに規模が大きすぎる場合は、本文そのものではなく、要約や特徴量にしてから渡します。たとえば重複の検出なら、全文を渡す代わりに各ページの特徴を数値にして、数値同士を比べる形にできます。この場合、比べる処理はモデルを通す必要すらありません。
「文脈が足りない」と感じたときは、渡すものを減らせないかを先に考えるほうが安く済みます。
長い入力を使うときの実務的な注意
- 入力側が費用の大半を占めることが多い。1Mに近い入力を毎回投げると、返ってくるのが数百字でも費用は入力側で決まります
- 同じ内容を繰り返し投げるなら、キャッシュの仕組みを確認する。変わらない部分を毎回課金されるのは無駄です
- 応答を一括で待たない。入出力が長くなると、待ち時間の上限に当たって切れることがあります。逐次受け取る形にすると通ります
- 入力に不要なものが混ざっていないか確認する。ログ、生成物、依存パッケージのファイルなどを丸ごと渡していることがあります
最後の点は費用にも精度にも効きます。関係ないファイルが大量に混ざると、判断の材料が薄まります。渡す範囲を絞るのは、節約であると同時に精度の対策でもあります。
実際に効いた例：重複の検出
文脈の使い方で結果が変わった実例を挙げます。10サイト・571ページの中から、内容が似ているページの組を見つける作業です。
最初に考えたのは、全ページの本文をまとめて渡して「似ているものを挙げて」と頼む形でした。ところが571ページ分の本文は1Mに入りません。入ったとしても、571×571の組み合わせを見落としなく比べさせるのは無理があります。
実際に採った形はこうです。
- 本文の比較そのものはコードでやる。各ページを単語の集合にして、集合同士の重なり具合を数値で出します。モデルは通しません
- 閾値を超えた組だけを取り出す。この時点で数百の組に絞られます
- その組についてだけ、どちらを残すかの判断をモデルに渡す。ここは文脈に余裕で収まります
結果として571ページが互いに45%以上重複していることが分かり、対処に進めました。もし1と2をモデルにやらせていたら、費用も時間も桁が変わっていましたし、見落としも出たはずです。
この件から得た指針は、「機械的に判定できる部分はコードでやり、判断が要る部分だけをモデルに渡す」です。文脈が足りないと感じたときは、まずこの切り分けができないかを考えるようにしています。
よくある質問
1Mあれば分割は不要になりますか？
多くの場合は不要になります。ただし1,000ページ規模のサイト全体のような対象は1Mでも入りません。その場合は、渡す前に要約や特徴量へ落とす方向を検討してください。
日本語は英語よりトークンを消費しますか？
一般に多く消費します。文字数からの見積もりは目安にとどめ、実際に数えるエンドポイントで確認してください。
文脈が長いほど精度は上がりますか？
必要な材料が入ることの効果は大きいですが、関係のないものを詰め込むと逆効果です。長さそのものではなく、入っている材料が適切かどうかで決まります。