LLM プロバイダーとモデルを管理し、外部レジストリからモデルを同期し、ヘルスチェックを実行し、独立した課金のために組織ごとの API キーを設定します。
Entity Enricher は幅広い LLM プロバイダーをサポートしています。各プロバイダーは、それぞれ個別の価格、機能、設定を持つ複数のモデルを持つことができます。
多くのチームは、LLMトラフィックを企業向けAIゲートウェイ、リージョナルエンドポイント、または組み込みではないプロバイダー（例: エンタープライズのLiteLLMプロキシ、Cloudflare AI Gateway、Alibaba DashScope（Qwenモデル用））経由でルーティングします。これらは、カスタムベースURLを持つ独自のStandard（OpenAI互換）プロバイダーとして追加します。
acme-openai-gw）。openaiや anthropicのような組み込み名は予約されています。 https://gateway.example.com/v1。このフィールドは、Entity Enricher に組み込みクライアントがないproviderの場合は必須です。 https:// URL である必要があります。SSRF を防ぐため、ループバックおよびプライベートレンジ（localhost、 10.x、 192.168.x）は拒否されます。セルフホストのサーバーはインターネット経由で到達可能でなければなりません。ローカルの Ollama の場合は、専用の Ollama トンネルを使用してください。/v1 プロトコル（チャット補完、/models）に対応している必要があります。 {endpoint}/modelsにプローブを送り、enrichmentを実行する前にキーとベースURLを検証します。各 provider には キーごとの最大同時呼び出し数設定（レート制限のオーバーライド）があります。これは、単一の API キーが並列で実行する LLM 呼び出し数を上限として制限し、そのキーを使用するすべてのフロー、つまり複数 expertise domain の enrichment ファンアウト、classification、arbitration、schema／サンプル生成をカバーします。
これは、プランの最大同時実行ジョブ数の制限とは別のものです。この制限は、組織全体がすべてのプロバイダーにわたって一度に実行するエンリッチメントジョブの数を制限します。
各モデルはその機能を追跡し、モデルセレクターにアイコンとして表示します:
| 機能 | 説明 |
|---|---|
| ビジョン | 画像および視覚的な入力を処理できます |
| ツール呼び出し | 関数呼び出し / ツール利用に対応 |
| 音声入力 | 音声入力を処理できます |
| PDF 入力 | PDF文書を処理できます |
| promptキャッシュ | コスト削減のためのpromptキャッシュに対応 |
| 推論 | 拡張思考／思考連鎖（chain-of-thought）の機能 |
外部レジストリと同期して、モデルの料金を最新の状態に保ちます。同期処理では、新しいモデル、価格変更、削除されたモデルを自動的に検出します。
デフォルトの価格ソースです。実際のAPIモデル名、価格、コンテキスト長、機能を含む、LiteLLMのコミュニティが管理するレジストリをGitHubから取得します。
約30のproviderに対応。表示名、benchmark、生成速度は含まれません。
pricepertoken.com からの代替ソースです。表示名、ベンチマーク（コーディングおよび数学のスコア）、生成速度（1秒あたりのトークン数）が含まれます。
約20のproviderに対応。LiteLLMより豊富なメタデータを提供します。
最小限のヘルスチェックプロンプトを実行して、モデルに到達可能かどうかを事前に検証します。これにより、エンリッチメント中にユーザーがエラーに遭遇する前に、故障したモデルを検出できます。
ヘルスチェックは、すべてのモデル、特定のプロバイダーのモデル、または単一のモデルに対して実行できます。結果は SSE を介してリアルタイムでストリーミングされ、成功／失敗の件数を示すプログレスバーが表示されます。
enrichment呼び出しが「model not found」エラーで失敗すると、繰り返しの失敗を防ぐためにそのmodelは自動的に無効化されます。これは通常のenrichment処理中にリアルタイムで発生します。
| 無効化の理由 | 設定者 | 自動再有効化されましたか？ |
|---|---|---|
| モデルが見つかりません | エンリッチメントエラーまたはヘルスチェック | はい（価格同期または検証による） |
| 同期で削除済み | 料金の同期（モデルが消失しました） | はい（モデルがレジストリに再表示された場合） |
| 手動 | UIの管理者トグル | いいえ（手動での再有効化のみ） |
組織は独自の LLM provider API キーを設定して、請求と使用状況の追跡を個別に行えます。システムは LRU 選択による 2 層のキー解決を使用します:
API Keys ページで設定される organization ごとのキー。provider ごとに複数のキーを持ち、LRU ローテーションに対応します。Fernet で暗号化されます。
管理者が管理するシステム全体のキーです。すべての organization で共有されます。LRU ローテーションによる provider ごとの複数キーにも対応します。
各 enrichment ではどのキーが使用されたかが記録されるため、キーごとにコストを追跡できます。キーにはヘルスチェック対応や使用回数カウンターが含まれ、恒久的な障害（無効なキー、支払いが必要）の場合は自動的に無効化されます。レート制限を受けたキーは一時的にバックオフされ、その間はプール内の他のキーが使用されます。キーの管理方法については API Keys ガイドをご覧ください。
プロバイダーとモデルの設定全体をJSONとしてエクスポートし、バックアップや別インスタンスへの移行に利用できます。インポートは常にアップサートです。既存のプロバイダーとモデルは名前で照合されてその場で更新され、新規のものは追加されます — 削除されるものはありません。
エクスポートにはプロバイダー設定、モデル構成、価格、機能、および正規モデル仕様が含まれますが、API キーは含まれません。API キーは別途保存されます。インポート後は API キーを別途設定してください。システム管理者はグローバルカタログ全体をバックアップします。組織のオーナーは自組織のプロバイダーとモデルのみをエクスポートおよびインポートでき、共有のグローバルカタログはインポートを通じて作成または編集することはできません。