LLM エンリッチメントでは、請求されるのはトークンです。Entity Enricher は、精度を犠牲にすることなく、課金対象のトークンをできるだけ少なく送信するように作られています。プロンプトキャッシュを中心に、スキーマのスコープ設定、スマートゲーティング、無駄な再試行の削減がそれを支えています。ほとんどは自動的に行われ、追加の設定は一切必要ありません。
すべてのエンリッチメント呼び出しでは、入力トークン（プロンプト、スキーマ、添付されたドキュメント）、出力トークン（構造化された結果）、そして有効な場合はウェブ検索クエリに対して課金されます。最も大きく、最も繰り返される部分は通常入力です。同じシステム指示、スキーマの説明、ソースドキュメントが呼び出しのたびに再送信されます。この共有された入力をキャッシュすることが最大の効果を持つため、最初に扱います。
prompt + schema + attachment。呼び出し間で大きく重複度が高いため、キャッシュとスコープ設定の最優先対象です。
構造化された結果です。各モデルには実際に担当するフィールドのみを求めることで、無駄のない状態を保ちます。
リトライの失敗、レート制限の乱発、誤ったエンティティのエンリッチメント。費用を払うのではなく、事前に排除します。
複数のexpertise domainを対象とするenrichmentを実行すると、同じentityに対して複数のLLM呼び出しが行われます（expertise domainごとに1回）。これらの呼び出しはすべて、同じ冒頭コンテキスト（汎用のシステム指示と、添付したインラインテキストのドキュメント）を共有します。Entity Enricherはこの共有プレフィックスを呼び出し間でバイト単位で完全に同一に保ち、キャッシュ可能としてマークします。これによりproviderはそれを一度だけ保存し、以降のすべての呼び出しで通常の入力価格の約10分の1で再読み込みします。
N 回の呼び出しはそれぞれ、共有コンテキスト全体を入力価格の満額で再送信します。5 つの expertise domain があれば、その大きな共有ブロックの料金を 5 回支払うことになります。
共有ブロックは一度キャッシュに書き込まれ、その後、他の 4 つの呼び出しでは入力価格の約 10% で読み戻されます。expertise、言語、添付ドキュメントが増えるほど、節約額も大きくなります。
プロバイダーのキャッシュは、それを書き込む最初のリクエストが完了した後にのみ読み取り可能になります。すべてのエキスパートドメイン呼び出しが同時に実行されると、いずれもウォームキャッシュを見つけられず、それぞれが冗長に自身のコピーを書き込むことになります。そのため、キャッシュが適用される場合、最初の呼び出しは単独で実行され、キャッシュが伝播するまでの短い時間が確保され、その後にのみ残りの呼び出しが並列で開始されます。これにより、各呼び出しはキャッシュを書き直すコストを支払う代わりに、ウォームキャッシュを読み取ることができます。
Anthropic のモデルは共有の指示を明示的にキャッシュし、添付されたPDFや画像はその場でキャッシュされ、自動プレフィックスキャッシュを備えたプロバイダー（OpenAI、xAI、DeepSeek など）は、同じバイト単位で一致するプレフィックスの恩恵を受けます。キャッシュは、入力が大きい場合 — 多数の専門ドメイン、複数の言語、または添付ドキュメント — に最も効果を発揮します。
コスト計算はキャッシュを考慮します。キャッシュされた入力トークンは model のキャッシュ読み取りレート（入力レートの一部）で課金され、実際に新規のトークンのみが通常価格で課金されます。この節約は理論上だけでなく、コスト分析に直接反映されます。
共有プレフィックスのキャッシュに加えて、Entity Enricherは各呼び出しのうち共有されない部分も縮小します。
各 expertise 呼び出しは、schema 全体ではなく、担当する schema の一部のみを受け取ります。
金融の専門家が規制関連のフィールドを見ることは決してありません。フィールドが少なければ、入出力のトークンも少なくなります。そしてレスポンスはマージ前に自分の担当部分だけに絞り込まれます。
ドキュメントが添付されていて、厳密な構造化出力モードを選択していない場合、フィールド一覧は読み取り可能なプロンプト内にのみ存在します。schema が通信経路上で重複することはありません。
これによりスキーマトークンが完全に削除され、共有プレフィックスが同一に保たれます(そのためキャッシュ効率が向上します)。応答は引き続きクライアント側で検証され、ドリフト時には自動的に自己修正されます。
任意のプリフライト分類は、高コストなマルチモデルエンリッチメントを開始する前に、エンティティが実際にスキーマと一致するかどうかを確認するため、単一の安価で高速なモデルを実行します。「Planet」スキーマに送られた月のような不一致は、複数のプレミアムモデルにわたる完全なエンリッチメントを消費する代わりに、わずか1セント未満で検出されます。
これはノンブロッキングであり（チェックが失敗してもエンリッチメントは続行されます）、キャンセルも可能なため、スキップすると決めたモデルに対して料金が発生し始めることはありません。
検証ラウンドが失敗すると、成果のない全額課金のLLM呼び出しになってしまいます。2つの仕組みにより、再試行を稀で生産的なものに保ちます。
配列であるべきインデックスキー付きオブジェクト、文字列の「null」、不要なエスケープ済み引用符など、LLM出力によくある癖は、検証が実行される前に修正されます。
検証エラーになりかけた多くのケースは自動的に修正されるため、有料の再試行が発生することは一切ありません。
本当に再試行が必要な場合は、正確な検証エラーがmodelにフィードバックされ、その特定の問題を修正できるようになります。
明確で具体的なフィードバックは、曖昧な指示で試行を無駄にするのではなく、次の試行が成功する可能性を高めます。
小規模なスキーマではシングルパスが最も安価です。マルチエキスパティーズは大規模なスキーマ向けに作られており、キャッシュと専門知識ごとのスコープが追加の呼び出しコストを十分に上回ります。それぞれの使い分けについては戦略をご覧ください。
プロバイダーごとの同時実行数の上限により、ジョブがプロバイダーに過度な負荷をかけてレート制限エラーを引き起こすのを防ぎます。そうしたエラーはバックオフと再試行を誘発し、トークンと実時間を無駄にします。抑制された安定的な同時実行のほうが、429エラーと戦うよりも低コストです。
すべてのエンリッチメントは、キャッシュ読み取りを含む実際のトークン数と、その結果として生じるコストを記録します。コストダッシュボードはそれを時系列チャートとモデルごとの内訳に変換するため、支出がどこに向かっているかを正確に把握し、キャッシュとスコープ設定が機能していることを確認できます。表示される価格が請求される価格です。プロバイダーの生のコストとプラットフォームのマークアップは透明に保たれます。