LLM は構造化データを生成する際、もっともらしく見える事実を捏造することがあります。Entity Enricher は 8 層の防御機構を用いて、正確なデータかデータなしのいずれかを保証します。自信ありげな作り話が返ることはありません。
自由なテキストでは、幻覚（ハルシネーション）による文は明らかに曖昧です。構造化された出力では、"founded_year": 1987のような幻覚によるフィールドは信頼できるように見え、正しい値と区別することはほぼ不可能です。これを特に危険なものにする3つの要因があります:
ハルシネーションによるJSON値は、本物とまったく同じに見えます。曖昧な表現も「およそ」もなく、ただきれいで自信ありげな、たまたま間違っているデータ点があるだけです。
必須フィールドは、LLMに知識がない場合でも値を生成させます。モデルは構造に空白を残すのではなく、データを捏造します。
構造化データはデータベース、分析、自動化に直接取り込まれます。誤った値は人による確認を経ずにパイプライン全体へ伝播します。
| パターン | 例 | 原因 |
|---|---|---|
| 自信を持った捏造 | "ceo": "John Smith" | LLMが必須フィールドをもっともらしい名前で埋めます |
| 時系列の混同 | "revenue": "$2.3B" | トレーニングデータのカットオフ、または期間の混同 |
| エンティティの混同 | 会社 A の属性を会社 B に適用 | 重複するトレーニングデータ内の類似した名前 |
| 妥当なデフォルト値 | "employees": 500 | LLMは無知を認めるよりも「妥当な」数値を選びます |
| 捏造された関係 | "subsidiary_of": "Alphabet" | LLMが存在しない関係を推論します |
これらのパターンのいくつかは、モデルではなくスキーマに起因します。revenue のようなプロパティは、通貨、期間、そしてグループ単位かエンティティ単位かという範囲が未確定のままですし、そのエンティティが本来持たない項目の名前を指定すれば、モデルには参照できるものが何もありません。曖昧性チェックはこの両方を検出し、そのプロパティが取り得る解釈を挙げたうえで、そのうち一つだけに絞り込む名前変更または説明を提案します。
Entity Enricher は単一の手法に依存しません。それぞれ異なる障害モードを対象とする 8 つの独立した防御レイヤーを積み重ねています。あるレイヤーがハルシネーションを見逃しても、次のレイヤーが捉えます。
エンリッチメントを開始する前に、高速なLLMがentityがschemaの型に一致するかを分類します。これにより、entity全体のハルシネーションを発生源で防ぎます。
例: 「Planet」スキーマに対する「Titan」は衛星としてフラグが立てられます。エンリッチメントモデルはこのコンテキストを受け取り、惑星固有のフィールドにはnullを使用します。
すべての戦略は LLM に対して「正確かつ保守的であること。値を決して捏造しないこと」と指示します。model はプレースホルダーで埋める代わりに、判定できなかったフィールドを宣言し、それらの宣言は出力において正直な null になります。
これは schema の圧力に直接対処します。schema の圧力は構造化された幻覚の第一の原因です。宣言された不明値は、本物の回答も明確に区別します。model が確信を持って示す 0 はデータですが、宣言された 0 はデータではありません。
スキーマのプロパティは専門ドメインごとにグループ化されます。各 LLM 呼び出しは自身のドメイン内のフィールドのみを参照し、その領域のみに集中するよう指示されます。
スコープが狭いほど、ハルシネーションの余地が減ります。金融の専門家が規制データについて推測することはありません。
キープロパティ（is_key: true が設定されたもの）はプロンプト内で強調表示され、他のフィールドを埋める前にLLMが識別情報に焦点を合わせられるようにします。
これによりモデルが既知の事実に基づくようになり、捏造された詳細へのドリフトが軽減されます。
エンリッチメントの出力は、スキーマの型・形式・構造に照らして検証されます。失敗すると ModelRetry がトリガーされ、該当するエラーが LLM に送り返されて修正されます。修復は外科的で、誤って返された末端の項目だけを再度問い合わせ、回答全体をやり直すことはありません。
1 回のエージェント実行につき、最大 5 回まで自動修正を試みます。(スキーマ生成の自己修正は仕組みが異なり、ステップごとに決定論的なフォールバックを用います。)
preserve: true が設定されたフィールド（ID、SKU、インポート識別子）は、エンリッチメント後に元の入力値に復元されるため、LLM がグラウンドトゥルースのデータを上書きすることはできません。エンリッチメントのリクエストではすべての preserve フィールドに値を指定する必要があるため、null に固定されたり値が捏造されたりすることはありません。
配列内では、エンリッチメントされた項目は key フィールドによって入力項目と照合されます。AIが発見した項目には、捏造された識別子ではなく null が割り当てられます。
同じエンティティを2つ以上の独立したモデルに通し、出力をフィールドごとに比較します。不一致は潜在的なハルシネーションとしてフラグが立てられます。
Claudeが収益を23億ドルと述べ、GPT-4が18億ドルと述べた場合 — その矛盾は検出され、明示されます。
検出された競合は、ルールベースの投票（多数決、中央値、和集合）または、正確性・網羅性・一貫性を評価する専用の LLM arbitration によって解決されます。
各 arbitration の判断には根拠と信頼度が含まれ、競合がどのように解決されたかを完全に透明化します。
基本原則
データの欠落は、誤ったデータよりも常に望ましいものです。すべての層がこの原則を強化しており、システムはもっともらしい捏造を返すのではなく、null を返すように設計されています。