Entity Enricher は 2 種類の知識を構造化され検証されたデータに変換します。1 つは大規模言語モデルがすでに知っていること、もう 1 つは自社のアーカイブに未読のまま眠っているもの（PDF ドキュメント、画像、音声録音、Office ファイル）です。抽出されたすべてのオブジェクトには安定したセマンティックアイデンティティが付与されるため、エンリッチメントは単発の結果の山ではなく、一貫した情報システムとして蓄積されます。
LLMは、数十億のドキュメント、データベース、ウェブページをクエリ可能なニューラルネットワークに圧縮した、人間の知識の蒸留物だと考えてください。Entity Enricherは、この知識をお客様のデータモデルに合った構造化された信頼性の高い形式で抽出するためのインターフェースを提供します。さらに、最新のモデルはPDFを読み、画像を見て、音声を聞くこともできるため、同じインターフェースで お客様自身のコンテンツからも構造を抽出できます。つまり、貴社が長年蓄積してきた契約書、レポート、スキャン、録音などです。
すべてのエンリッチメントは、これらのソースの一方または両方を活用します。両者は互いを補完します。モデルは世界知識と推論を提供し、ドキュメントは組織内にしか存在しない事実を提供します。
企業、医薬品、場所、製品、規制に関する公開された事実など、モデルが学習中に習得したあらゆる情報です。識別子(名称やウェブサイト)とスキーマを与えれば、業界、設立年、本社所在地、作用機序といった残りの情報を補完します。ドキュメントは不要です。
データベースに登録されることのなかった知識、すなわち契約書、請求書、検査報告書、スキャンされたフォーム、製品写真、録音された通話。これらをエンリッチメントに添付すると、モデルがその内容から直接スキーマのフィールドを抽出します。手作業の OCR、書き起こし、コピー＆ペーストは不要です。
対応形式と配信モードについてはドキュメント添付ファイルをご覧ください。
スキーマは単なるデータ構造ではなく、人類の集合知、あるいは特定のドキュメントに投げかける形式化された問いです。companyName、industry、headquarters といったプロパティを持つスキーマを定義するとき、あなたは本質的にこう尋ねているのです。「企業の識別子が与えられたら、その名称、事業を営む業界、本社の所在地を教えてほしい」
| スキーマコンセプト | 目的 |
|---|---|
| プロパティ | 抽出したい具体的な事実 |
| 型 | 期待する形式（文字列、数値、オブジェクト、配列） |
| 専門知識ドメイン | どの専門家が回答すべきか（製薬、財務、地理） |
| 検索キー | ナレッジベース内でエンティティを特定するのに役立つ識別子 |
| セマンティックID | 安定した組織スコープのアイデンティティにより、同一の現実世界のオブジェクトが複数のエンリッチメントや他のシステム間で認識されます |
| 保持 | 入力から変更せずにそのまま引き継ぐフィールド |
| 多言語対応 | ご利用のすべての言語で提供されるフィールド — 後付けの翻訳ステップではなく、第一級の機能です |
大規模言語モデルは新しい種類のナレッジベースです。保存されたレコードの完全一致を返す従来のデータベースとは異なり、LLM はコンテキストを理解し、不完全なデータについて推論し、パターンから一般化します。さらに、もはやテキスト専用ではありません。ビジョン対応モデルは画像やスキャンされたページを読み取り、PDF 対応モデルはドキュメント全体を取り込み、音声対応モデルは録音を聞き取ります。
Entity Enricher は複数の LLM を 異なる知識の視点 として扱います。各プロバイダーはそれぞれの強みを持ち、Claude は繊細な推論に優れ、GPT-4 は幅広い知識を持ち、Gemini は多言語の深さを提供し、ローカルの Ollama モデルはデータをプライベートに保ちます。
同じエンリッチメントを複数のプロバイダーで実行することで、信頼度を比較し、複数の専門家からのコンセンサスを集約し、コストと品質のバランスを取ることができます。詳しくはマルチモデルエンリッチメントをご覧ください。
エンリッチメントとは、検索キーを使ってエンティティを識別し、LLMと添付ドキュメントから関連する知識を取得し、スキーマに従ってレスポンスを構造化し、出力が期待される型と一致することを検証し、指定された箇所で元のデータを保持し、最後にアイデンティティを解決——各オブジェクトに安定したセマンティックIDを割り当てる——プロセスです。
{ "name": "Novartis", "website": "novartis.com" }{ "name": "Novartis", "industry": "Pharmaceutical", "foundedYear": 1996, "semantic_id": "cpt_abc123" }すべてのエンリッチメントは独立しています。2回尋ねると、同じ現実の対象が異なる表現で返ってくることがあります。ある日は「Acme Inc.」、次の日は「Acme Incorporated」。薬の副作用は、言語やモデルによって「Headache」「Céphalée」「Cephalalgia」となります。エンリッチされたデータの上に実際に構築するには、同じエンティティを指す安定したハンドルが必要です。
セマンティックIDとは、Entity Enricherがオブジェクトのキーフィールドから割り当てる、組織スコープの識別子で、正確なスペルではなく意味によって照合されます。同じエンティティは、エンリッチメント、モデル、言語、時間をまたいでも同じIDに解決されます。モデルの実行後に自動的に割り当てられ（LLMが作り出すことは決してありません）、どんなオブジェクトにも付与できます。エンティティ全体、ネストされたオブジェクト、リスト内の各項目のいずれにも対応します。
cpt_abc123これこそが、エンリッチメントの流れを、成長させクエリできる情報システムへと変えるものです:
| 使用 | 実現できること |
|---|---|
| 結合キー | エンリッチされたレコードを、データウェアハウス、CRM、マスターデータシステムと照合するための安定したキー |
| 重複排除 | バッチ、モデル、または何年にもわたる文書間で生成された類似の重複を1つのアイデンティティに統合します |
| 統合 | 既知のセマンティックIDを再度渡すと、新しいエンティティを作成する代わりに、すでに追跡しているエンティティに新しい事実が関連付けられます |
| ナレッジグラフ | 複数のrecordから参照されるオブジェクトは1つのノードに集約され、関係性をクエリできるようになります |
解決の仕組み（完全一致キャッシュ、埋め込み、類似度しきい値）についてはセマンティックIDで説明しています。
多くの企業は、構造化されないままのアーカイブを抱えています。契約書やレポートを収めた共有ドライブ、スキャンした紙の書類、メールの添付ファイル、録音された会議などです。そのアーカイブはまさにデータベースです。行と列が与えられなかっただけなのです。添付ファイル（知識ソースとしてのドキュメント）、バッチエンリッチメント（並列処理）、セマンティックID（コーパス全体での重複排除）を組み合わせることで、それを一つのデータベースへと変えられます。
ワークフローの詳細についてはバッチエンリッチメントをご覧ください。
構造化された知識はテキストの中だけに存在するわけではありません。Entity Enricher はアーカイブに実際に含まれる形式を受け入れ、それぞれを読み取れるモデルに振り分けます。
この機能は2つの配信モードで動作します。バイナリモードでは、元のバイト列がそのままモデルに渡されるため、変換で失われるものがありません。テーブルのレイアウト、写真のディテール、話者の言葉まで保持されます。インラインテキストモードでは、アップロード時に一度だけテキストが抽出され、すべてのプロンプトにインライン挿入されるため、モデルの能力を問わずあらゆるモデルで動作します。
機能を考慮したルーティングにより、ファイルは実際に処理できる model にのみ送られます。enrichment の失敗後ではなく、開始前に警告が表示されます。フォーマットとモードの詳細は Document Attachments をご覧ください。
すべての知識が同等ではありません。薬物の作用機序に関する質問は、企業構造に関する質問とは異なるexpertiseを必要とします。expertise domainはschemaのプロパティをLLM内の適切な専門家に振り分け、各ドメインに関連する知識パターンを活性化します。
マルチ expertise domain 戦略を使用する場合、各ドメインは関連する schema プロパティのみを含む専用の LLM 呼び出しを受け取り、出力品質が大幅に向上します。
LLMは誤りを犯すことがあります。Entity Enricher は、エラーを自動的に検出して修正するための複数の品質管理レイヤーを実装しています:
検索キーは、LLMが誤ったエンティティについてハルシネーションを起こすのを防ぎます。次の2つの役割を果たします。
エンリッチメントプロンプトは次の点を強調します:「あなたは、これらの検索キーで識別される特定のエンティティをエンリッチしています。」
検索キーとセマンティックIDはアイデンティティの表裏一体です。検索キーはエンリッチメント中にLLMが適切なエンティティを見つけるのを助けます。セマンティックIDはエンリッチメント後にシステムが依存する永続的なアイデンティティを付与します。
エンリッチメントを開始する前に、任意のプリフライト classificationステップで、entityが実際にschemaの型に一致するかを検証できます。これにより、entityが一致しない場合のハルシネーションを防ぎます。たとえば、Titanが実際には衛星であるにもかかわらず「Planet」schemaに対して「Titan」をエンリッチメントするような場合です。
LLM呼び出しにはコストがかかります。Entity Enricher は、トークン使用量、プロバイダーごとのコスト、エンリッチメントごとのコスト、組織単位の支出を追跡します。これにより、予算のモニタリング、プロバイダーの比較（コスト対品質）、単純なフィールドには安価なモデルを使うといった最適化の判断が可能になります。これは数千件のドキュメントのアーカイブを処理する際に最も重要になります。
| コンポーネント | 概念的な役割 |
|---|---|
| スキーマ | お尋ねになる質問 |
| LLMプロバイダー | 異なる知識の視点 |
| 添付ファイル | ナレッジソースとしてのアーカイブ（PDF、画像、音声、オフィス文書） |
| 検索キー | エンリッチメント中のエンティティ同一性アンカー |
| セマンティックID | エンリッチメント後も変わらない一貫したアイデンティティ — 情報システムの基盤です |
| 専門知識ドメイン | スペシャリストルーティング |
| 戦略 | LLM呼び出しをオーケストレーションする方法 |
| バッチ処理 | アーカイブ規模での並列エンリッチメント |
| 多言語対応 | ご利用のすべての言語で同じ事実を |
| 検証 | 品質保証 |
| 保持 | データ整合性の保護 |