ElasticsearchとLLMによるエンティティ解決（第2部）：LLM判定とセマンティック検索によるエンティティのマッチング

第1部では、ウォッチリストを作成し、エンティティの言及を抽出しました。これで、「言及が実際にどのエンティティを指しているのか」という難しい質問に答える準備ができました。このシリーズの最初のブログの例に戻りましょう。ここでは、エンティティ解決が必要な理由を説明しています。「新しいSwiftアップデートが登場しました！」この見出しにもう少し文脈が添えられていると想像してください。

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によって評価される必要があるため、構造化された出力の失敗により、検索が適切に機能している場合でも受け入れと呼び出しが抑制される可能性があります。

エラー率の問題

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

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

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

はじめましょう

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

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

メモ

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