前回の記事で見たように、関数呼び出しによってもたらされる一貫性は、単に便利な最適化ではなく、不可欠なものです。構造的なエラーを評価ループから除去したところ、標準的なシナリオ（ティア4データセットなど）の結果が劇的に向上しました。

しかし、答えるべき明白な疑問はまだ残っています。

状況が本当に複雑になってきた場合でも、このアプローチは有効でしょうか？

現実世界におけるエンティティ解決が単純なケースで失敗することはめったにありませんが、名前が言語、文化、文字体系、時代、組織の境界を越える場合に失敗します。人が名前ではなく肩書きで言及されている場合、会社名が変更された場合、音訳が一貫していない場合、そして（スペルではなく）文脈だけが言及と現実世界の実体を結びつける唯一の要素である場合、この方法は失敗します。

そこで、このシリーズの最後の記事として、このシステムにいわば究極のチャレンジを課すこととしました。

なぜこれが究極の挑戦なのでしょうか？

以前の評価では、ますます複雑になるデータセットを用いてシステムをテストしました。前回の記事で触れた第4段階に到達する頃には、すでにニックネーム、称号、多言語名、意味的な参照などが混在する状況になっていました。これらのテストにより、アーキテクチャ自体は健全であることが示されましたが、信頼性の問題、特に不正な形式のJSONが原因で、リコールが抑制されていることがわかりました。

関数呼び出しの仕組みが整ったことで、ようやく安定した基盤ができました。そのおかげで、さらに興味深い質問をする機会が得られました。

1つの統一されたパイプラインで 多くの異なる種類のエンティティ解決問題を一度に処理することは可能でしょうか？

究極のチャレンジデータセットは、まさにその側面を徹底的に追求するために設計されました。

このデータセットは、（ニックネームや音訳といった）単一の困難に焦点を当てるのではなく、 50種類以上の異なる課題タイプを組み合わせています。

• 文化的な命名規則。

• タイトルに基づく参照。

• 事業上の関係性と過去の社名変更。

• 多言語および異文字表記での言及。

• 上記のうち複数を組み合わせた複合的な課題。

重要なのは、この試みが特定の狭い用途向けに最適化することではなく、ルールがエンティティごとに変化した場合でも設計パターンが通用するかどうかをテストすることです。

データセットの概要

究極のチャレンジデータセットは以下で構成されます。

• 個人、組織、機関などの50のエンティティ。

• 構造と言語の複雑さが異なる約60本の記事。

• 大きく以下に分類される51種類の異なるチャレンジカテゴリー。

  • 文化的な命名規則。

  • 肩書きと職務上の背景。

  • 事業と組織間の関係。

  • 多言語および音訳の課題。

  • 複合シナリオとエッジケースのシナリオ。

本シリーズの前半で、生成AIを用いてデータセットを作成することは諸刃の剣であることを確認しました。生成AIがなければ十分な規模と多様性を備えたテストデータを収集することは極めて困難になりますが、このモデルは放置すると、物事をあまりにも単純化しすぎる傾向があります。

例えば、初期世代の検証段階で、モデルに「ロシアの大統領」といったフレーズがウラジーミル・プーチンの明示的な別名として含まれていることが判明しました。それは今日では妥当に思えるかもしれませんが、文脈解決能力をテストするという目的を損なうことになります。記事が1990年代のロシアについて論じている場合はどうなるでしょうか？システムは、ハードコードされたエイリアスに頼るのではなく、文脈から正しいエンティティを推論するべきです。

そのため、このデータセットはショートカットが効かないように意図的に設計されています。システムが意味を推測することが想定されている場合、別名は明示的にリスト化されません。記述的なフレーズはエンティティにあらかじめリンクされていません。正確な一致は、単なるローカルテキストだけでなく、記事レベルの文脈によって決まることが多いです。

重要な注意点：本システムは多様なシナリオにおける機能を実証していますが、これはあくまで教育用プロトタイプです。実際の制裁対象組織の監視を扱う本番システムでは、追加の検証、コンプライアンスチェック、監査証跡、および機密性の高いユースケースに対する特別な処理が必要となります。

これらのシナリオが難しい理由

このシリーズの最初の投稿で、単純であいまいな例「新しいSwiftアップデートが登場しました！」を紹介しました。課題は、「Swift」という単語が、文脈によって複数の現実世界の実体として解釈される可能性があることです。この例はより広範な真実、つまり、自然言語は本質的に曖昧であるということを捉えています。

したがって、エンティティ解決は単なる文字列照合の問題ではありません。人間は日常的に、共通の知識、文化的規範、状況的文脈に頼って参照関係を解決していますが、私たちは自分がそうしていることにほとんど気づきません。

よくあるケースをいくつか考えてみましょう。

• 「大統領」という称号は地政学的・時間的な文脈なしには意味がありません。

• 会社名は、記事がいつ書かれたかによって、親会社、子会社、または以前のブランドを指す場合があります。

• 人名は、言語や文化によって、異なる順序、書体、または音訳で表記されることがあります。

• 同じフレーズでも、文脈によって異なる対象を指す場合があり、システムは一致を受け入れるのと同じくらい確信を持って一致を拒否できなければなりません。

これらすべてを適切に処理する単一のルールセットは存在しないため、このプロトタイプは懸念事項を非常に積極的に分離しています。

• Elasticsearchは候補の範囲を効率的かつ分かりやすく絞り込みます。

• LLMは、判断が必要で、それ自体を説明しなければならない場合にのみ使用されます。

• 検索と推論は別個のステップのままです。

課題の種類が多様化するにつれて、この区分けはさらに重要になります。

システムが特別なケースなしに多様性を処理する仕組み

この評価で最も興味深い結果の一つは、変更しなかった点にあります。

• 日本語名に関する特別なロジックは追加していません。

• アラビア語の父称に関するカスタムルールは追加していません。

• ハードコーディングされたマッピングを過去の会社名に追加していません。

その代わりに、このシステムはシリーズ前半で紹介したものと同じ主要要素に依存していました。

• セマンティック検索のためにインデックス化されたコンテキスト強化エンティティ。

• Elasticsearchでのハイブリッド検索（完全検索、エイリアス、セマンティック）。

• 少数の、明確に定義された一致候補セット。

• 関数呼び出しと最小スキーマによって制約されたLLM判断。

これは、システムの柔軟性が、増え続けるルールのコレクションからではなく、表現とアーキテクチャから生まれることを示唆しています。

システムが成功するのは、適切な候補が取得され、LLMが参照が特定のエンティティにマッピングされる（またはされない）理由を説明できる十分なコンテキストがある場合です。

結果：パフォーマンスの概要

究極のチャレンジデータセットにおいて、システムは以下のような全体的な結果を生み出しました。

• 精度：約91％

• 再現率：約86％

• F1スコア：約89%

• LLM合格率：約72％

チャレンジの種類ごとのパフォーマンス

チャレンジの種類ごとに結果を分解すると、強みと限界が明らかになります。

最も優れたパフォーマンス（F1スコア100%）が見られた分野は以下のとおりです。

• 文字体系間の照合（キリル文字、韓国語、中国語の企業名）。

• ヘブライ語のシナリオ（父称、専門職称、宗教称号、音写）。

• 事業階層構造（航空宇宙、多角化製造業、多部門企業）。

• 職業上の肩書き（学術、軍事、政治、宗教）。

• 複数の文字体系を含む日本語シナリオの組み合わせ。

優れたパフォーマンス（F1スコア80～99％）には以下が含まれます。

• 国際的な政治家（98％）。

• 歴史的な名称変更（90%）。

• 複雑なビジネス階層（89％）。

• 日本の企業名（93％）。

• 異言語間の音訳（86％）。

• アラビア語の父称（86％）。

より困難な分野には以下が含まれます。

• 高度な音訳（中国語、韓国語）：0% F1。

• 特定の日本語シナリオ（敬称、名前の順序、表記体系のバリエーション）：約67% F1。

• 一部のアラビア語のシナリオ（会社名、機関の参考文献）：約40％ F1。

ここで重要なのは、なぜシステムがこれらのケースで機能不全に陥ったのかという点です。失敗の原因は、全体的なアプローチが破綻したことではなく、特定のコンポーネントの限界、特に特定の多言語シナリオにおけるセマンティック検索に使用される高密度ベクトルモデルの限界にありました。

検索と判断が明確に分離されているため、パフォーマンスを向上させるためにシステムを書き換える必要はありません。より高性能な多言語埋め込みモデルの採用、エンティティコンテキストの強化、または検索戦略の洗練により、コアアーキテクチャを変更することなく、これらのカテゴリー全体で結果が向上します。

アーキテクチャーの観点から見ると、それが真の成功指標です。

この結果が設計について教えてくれること

シリーズを振り返ると、いくつかのパターンが際立っています。

• 準備は巧みなマッチングよりも重要です。 エンティティに事前にコンテキストを付加することで、後々の曖昧さを劇的に減らすことができます。

• LLMは、レトリバーではなく、判断者として最も価値があります。したがって、検索を求めるよりも、なぜ一致が意味をなすかを説明するよう求めることの方がはるかに強力です。

• 信頼性が精度を実現します。関数呼び出しは、JSONを整理しただけでなく、取得ステップにすでに潜在していた想起を解放しました。

• 一般化は専門化に勝ります。厳選された少数の抽象化によって、独自のロジックを必要とせずに数十種類の課題に対応できました。

これが、プロトタイプが意図的にElasticsearchネイティブであり、LLMの使用方法が意図的に保守的である理由です。目標は検索を置き換えることではなく、意味が重要な状況において、検索を説明可能なものにすることです。

結びに

究極のチャレンジとは、完璧な指標を追い求めることではなく、より根本的な問いに答えることでした。

透明性が高く、検索優先で、LLMを活用したアーキテクチャは、ルールやブラックボックスに陥ることなく、現実世界のエンティティの曖昧さを処理できるでしょうか？

その回答は、この教育用プロトタイプに関しては「はい」ですが、本番環境での強化、コンプライアンス、監視、データの品質に関する明確な注意事項があります。エンティティの一致が行われた理由を正当化する必要のあるシステムを構築している場合、このパターンは真剣に検討する価値があります。このシリーズを通して、エンティティ解決は必ずしも難解なものではないということが伝われば幸いです。適切に関心事を分離することで、それは論理的に考え、測定し、改善できるものになります。

この研究はまた、より広範なアーキテクチャパターンを示唆しています。浮かび上がってくるのは、古典的な検索拡張生成（RAG）の、わずかではあるが重要な進化です。検索結果を直接生成に供給するのではなく、明示的な評価ステップを導入します。LLMはまず、取得された候補を評価し、妥当性を確認するために使用され、承認された結果のみが生成の強化に使用されます。これは、Generation-Augmented Retrieval-Augmented Generation with Evaluation、つまりGARAGEと名付けられるでしょう。うまい頭字語が嫌いな人なんていませんから。

このパターンは、他にどのような用途で活用できるでしょうか？信頼性、透明性、そして論理的な説明を必要とするシステムは、まさにうってつけの候補と言えます。この分野における今後の研究は、今回得られた成果と同様に説得力のあるものとなるはずであり、コミュニティが今後どのような展開を見せるのか、非常に楽しみです。

次のステップ：試してみましょう

究極のチャレンジが実際に動作する様子をご覧になりたいですか？実際の実装、詳細な説明、実践的な例を含む完全なウォークスルーについては、Ultimate Challenge notebookを参照してください。

完全なエンティティ解決パイプラインにより、本番での使用に必要なコアコンセプトとアーキテクチャが示されています。これを基盤に、透明性と説明可能性を維持しながら、ニュース記事を監視し、エンティティの言及を追跡し、どのエンティティがどの記事に登場するのかについての質問に回答するシステムを構築できます。

1. 新しいSwiftアップデートが登場しました！開発者たちは新しい機能を試したがっています。

2. 新しいSwiftアップデートが登場しました！新しいアルバムは来月リリースされます。

この追加されたコンテキストにより、「Swift」という名前を正しいエンティティに解決できるはずです。

前回の投稿では、ウォッチリストを設定し、追加のコンテキストでエンティティを充実させました。上記の例を見ると、リストには少なくとも「Taylor Swift」と「Swift Programming Language」の2つのエンティティが必要です。また、テキストからエンティティの言及を抽出する方法も説明しました。これらの例はどちらも「Swift」を抽出します。これらの材料、強化された監視リスト、抽出されたエンティティが揃ったところで、いよいよショーの主役であるエンティティマッチングを紹介する準備が整いました。

注意：これは、エンティティマッチングの概念を教えるために設計された教育用プロトタイプです。本番システムは、異なる大規模言語モデル（LLM）、カスタムマッチングルール、特殊な判断パイプライン、または複数のマッチング戦略を組み合わせたアンサンブルアプローチを使用する可能性があります。

問題：マッチングが難しい理由

人間の言語とは驚くべきものです。その最も興味深い特性の1つは、その無限の創造性です。無限の数の新しい文を生成し、理解することができます。そうであるなら、エンティティ解決において正確な一致が稀なのも不思議ではありません。作家は可能な限り創造的であろうと努めます。エンティティが言及されるたびにフルネームを書いたり読んだりしなければならないとしたら、かなり面倒です。そのため、厳密な一致は簡単ですが、現実には、より洗練されたエンティティ解決アプローチが必要です。それは、人間の作者の無限の創造性に少なくとも部分的には対応できるほどに堅牢なアプローチであるべきです。そのため、私たちは問題を2つのステップに分けます。まずはElasticsearchを使用して大規模な候補を取得し、次にLLMを使用してそれらの候補が実際に同じ現実世界のエンティティを指しているかどうかを判断します。

解決策：透明性の高いLLM判断による3段階のマッチング

私たちはコンピューターの使い方におけるパラダイムシフトの真っ只中にあります。インターネットの台頭がローカルコンピューティングからグローバルに接続されたネットワークへと私たちを導いたように、生成AIはコンテンツ、コード、情報の作成方法を根本的に変えています。実際、このシリーズに付随する教育プロトタイプは、作者の慎重な指示のもと、LLMを使用してほぼ「バイブコーディング」のみで作成されました。これは、LLMが人間の言語に本来備わっている生産性を実現している、あるいは実現するだろうということと同義ではありませんが、エンティティ解決を支援する強力なリソースが手に入ったことを意味します。

生成AIでよく使うパターンは、Retrieval-Augmented Generation（RAG）です。ここにおいて、取得（retrieval）とは、エンティティ候補を取得すること（回答を生成することではない）を意味し、LLMは一致の評価と説明にのみ使用されます。エンドツーエンドのエンティティ解決についてLLMに支援を依頼することもできますが、これは時間と費用の両面でコストのかかるアプローチです。RAGは、より効率的な方法でLLMにコンテキストを提供することでLLMの作業を支援し、それによってLLMがエンティティ解決を効率的に支援できるようにします。

RAGの取得部分については、再びElasticsearchを利用します。まず、正確な一致、エイリアスとの一致、そしてキーワード検索とセマンティック検索を組み合わせたハイブリッド検索という組み合わせを使用して、潜在的な一致を検索します。一致する可能性のある項目が見つかったら、LLMに送信して判断を仰ぎます。LLMは最終的な一致評価者として機能します。また、LLMにその理由を説明させます。これは他のエンティティ解決システムとの重要な差別化要因です。これらの説明がなければ、エンティティ解決はブラックボックスになります。説明があれば、一致にどんな意味があるのか自分で確認できます。

主な概念：3段階マッチング、ハイブリッド検索、透過的なLLM判断

3段階マッチングとは？このプロジェクトの開始時に、セマンティック検索がシステムの重要な一部になるという仮説を立てましたが、すべての一致にこのような高度な検索が必要なわけではありません。効率的にマッチングを見つけるために、私たちは段階的なアプローチを取ります。まず、キーワード検索で正確な一致を確認します。そのような一致が見つかった場合、作業は完了し、先に進むことができます。完全一致が失敗した場合は、エイリアス一致を使用します。このプロトタイプでは、簡素化のために、キーワードとの完全一致によるエイリアスマッチングも行われています。本番環境では、正規化、翻字ルール、あいまい一致、またはキュレートされたエイリアステーブルを使用してこのステップを拡張する場合があります。それでも最初の2つのステップで一致する可能性のあるものが見つからない場合は、Elasticsearchの逆順位融合（RRF）を使用したハイブリッド検索によるセマンティック検索を導入します。

ハイブリッド検索とは？Elasticsearchでは、セマンティック検索を使用して、コンテキストを考慮した意味のある一致を見つけることができます。Elasticsearchは、ベクトル検索とハイブリッド検索に広く使用されています。セマンティック類似性は意味を理解する上で強力ですが、構造化されたフィルタリング（例えば、時間範囲、場所、または識別子による）の代替にはならず、正確な一致が利用可能な場合は多くの場合不必要です。Elasticsearchは語彙検索で名声を博しており、これはセマンティック検索が適さないタスクに最適です。両方のアプローチを最大限に活用するために、単一のハイブリッドクエリで語彙検索とセマンティック検索を併用します。次に、結果をマージして、RRFを使用して最も一致する可能性が高いものを見つけます。このプロトタイプでは、上位2つの結果が、LLM判定に送信できる潜在的な一致となります。

LLM判定を使用する理由とは？LLMの判断と説明により、システムは曖昧さとコンテキストを透過的に処理できます。これは「the president」のような場合において重要です。コンテキストによって複数のエンティティを指す可能性がありますが、システム内でニックネームや文化的なバリエーションをうまく機能させることもできます。最後に、制裁リストからエンティティを識別するなどのミッションクリティカルなタスクを検討する場合、システムを信頼するために、一致が受け入れられた理由を把握する必要があります。重要なのは、LLMはコーパス全体を検索せず、Elasticsearchによって返された少数の候補のみを評価するということです。

実際の結果：LLM推論によるマッチング

あらゆる自然言語処理タスクにおける大きな課題は、期待される結果が何であるかを示す「答えの鍵」となるゴールデンドキュメントを作成することです。これがなければ、システムがタスクをどの程度うまく実行するかを判断することはほぼ不可能ですが、そのようなドキュメントを作成するのは面倒なプロセスになる可能性があります。エンティティ解決のプロトタイプでは、テストに使用できるデータの設定に生成AIを再度利用しました。

まず、ニックネームや翻字などのいくつかのチャレンジタイプを定義し、次にLLMに、システムにとって徐々に大きく、より困難になる階層化されたデータセットコレクションを作成するように依頼しました。データセットの作成は期待していたほど簡単ではありませんでした。LLMでは、正解を得るのがあまりにも簡単すぎるため、「チート」が行われる傾向が強くなりました。例えば、あるチャレンジタイプは意味的なコンテキストに重点を置いています。このタイプには、「ロシアの作家」を「レフ・トルストイ」に解決することなどが含まれます。LLMは誤って「ロシアの作家」を「レフ・トルストイ」の別名として入力したため、一致を見つけるためのハイブリッド検索の必要性がなくなりました。

このような問題を修正するために何度かリファクタリングを行った結果、5つのデータセット層が使用できるようになりました。第1〜4層は徐々に規模が大きくなり、チャレンジの種類も増えました。第5層は「究極のチャレンジ」データセットで、すべてのチャレンジタイプから最も難しい例で構成されていました。すべてのテストデータは包括的な評価ディレクトリで利用可能です。

プロンプトベースのエンティティ解決アプローチを評価するため、私たちは第4層データセットに注目しました。重要な注意点は、エンティティの一致品質に焦点を当てることができるように、評価が制御された実験として実施されたことです。ウォッチリストデータは事前にコンテキストで強化されており、エンティティは事前に記事から抽出され、評価で抽出精度ではなくマッチングに重点が置かれることが保証されました。これにより、一致品質が分離されます。エンドツーエンドのパフォーマンスは、抽出リコールとエンリッチメント品質にも依存します。

評価データセット

第4層の評価データセットは、システムの機能の包括的なテストを提供します。[1]

• 監視リストのエンティティ：さまざまなタイプ（人、組織、場所）にわたる66個のエンティティ。

• テスト記事：実際のエンティティ解決シナリオを網羅した69件の記事。

• 予想される一致数：すべての記事で206件のエンティティが一致すると予想。

• チャレンジタイプ：エンティティ解決のさまざまな側面をテストする15種類のチャレンジタイプ。

データセットに含まれる課題の種類は以下の通りです。

• ニックネーム： 「ボブ・スミス」→「ロバート・スミス」（7つの記事）。

• 称号と敬称：「Dr. Sarah Williams」→「Sarah Williams」（5つの記事）。

• 意味的文脈： 「ロシアの作家」→「レフ・トルストイ」（8 つの記事）。

• 多言語名：異なる文字での名前の取り扱い（6つの記事）。

• 事業体：会社名のバリエーション（7つの記事）。

• 役員紹介： 「Microsoft CEO」→「Satya Nadella」（5つの記事）。

• 政治指導者：タイトルベースの参考文献（5つの記事）。

• イニシャル： 「J. Smith」→「John Smith」（3つの記事）。

• 名前の順序のバリエーション：さまざまな名前の順序付け規則（3つの記事）。

• 切り捨てられた名前：名前の一部一致（3つの記事）。

• 名前の分割：名前がテキストに分割（3つの記事）。

• スペース/ハイフンの欠落：書式のバリエーション（2つの記事）。

• 翻字：文字間の名前の一致（2つの記事）。

• 複合チャレンジ：1つの記事に複数のチャレンジ（6つの記事）。

• 複雑なビジネス：階層的なビジネス関係（5つの記事）。

プロンプトベースのエンティティ解決がどのように機能したか見てみましょう。

全体的なパフォーマンス

結果は、LLMを活用したマッチ評価には大きな可能性があることを示していますが、重大な信頼性の問題も明らかにしています。各候補ペアはLLMによって評価される必要があるため、構造化された出力の失敗により、検索が適切に機能している場合でも受け入れと呼び出しが抑制される可能性があります。

メトリック

値

精度

83.8%

リコール

62.6％

F1スコア

71.7％

見つかった一致の合計

344

LLM合格率

44.8％

エラー率

30.2%

エラー率の問題

このプロトタイプで最初に行うステップは、Elasticsearchを使用して潜在的な一致ペアを作成することであることを思い出してください。これらの潜在的な一致はそれぞれ、LLMによって評価される必要があります。これらすべての一致を効率的に処理するために、LLM呼び出しをバッチ処理します。これにより、APIのコストと待ち時間が削減されますが、出力に不正な形式のJSONが表示されるリスクも高まります。バッチサイズが大きくなると、JSONはより長く複雑になり、LLMが無効なJSONを生成する可能性が高くなります。これがエラー率30%となる原因です。評価では、リクエストごとに5つの一致のバッチサイズを使用しました。この保守的なバッチサイズでも、JSON解析エラーが発生し、評価結果が大幅に歪んでいます。

次のステップ：LLM統合の最適化

セマンティック検索とLLMによる判断を用いてエンティティをマッチングしたことで、完全なエンティティ解決パイプラインが完成しました。ただし、このアプローチでは、モデルの判断は正しいものの、その出力が使用できない場合に、新たな障害モードが発生します。LLM統合を最適化することで、信頼性とコスト効率を向上させることができます。次の投稿では、エラーとコストを削減しながら構造と型の安全性を保証する構造化出力に関数呼び出しを使用する方法について説明します。

はじめましょう

エンティティマッチングの実際の動作を確認したいですか？実際の実装、詳細な説明、実践的な例を含む完全なウォークスルーについては、エンティティマッチングノートブックを参照してください。このノートブックでは、3段階の検索、RRFを使用したハイブリッド検索、LLMを利用した推論による判断を使用してエンティティを一致させる方法を正確に示します。

注意：これは、概念を教えるために設計された教育用プロトタイプです。本番システムを構築するときは、モデルの選択、コストの最適化、レイテンシ要件、品質検証、エラー処理、監視など、教育に重点を置いたこのプロトタイプではカバーされていない追加の要素を考慮してください。

メモ

1. これらのデータセットは合成されたもので教育用に設計されており、実際の課題に近似していますが、単一の本番ドメインを代表するものではありません。