ソートリーダー

エンティティ解決はデータクリーンアップではなくAIインフラストラクチャーになりつつある

mm

ある時、私はAIエージェントが自信を持って間違った答えを出したのを見た。ある企業には、同じ企業顧客に対して2つのレコードがあった。一つは旧社名と財務担当者の連絡先を保持していた。もう一つは、買収後に採用された新社名と別の請求先住所を保持していた。エージェントは、単純な質問「このアカウントは良好な状態ですか?」をされた。エージェントは一つのレコードを見つけ、未払いの請求書がないことを確認し、「はい」と答えた。未払いの請求書は、別の名前の下に記載されていた。

何もが間違っていたわけではなかった。モデルは与えられたデータをきれいに推論した。ただし、データは実際には1つの顧客に対して2つの顧客を記述していた。間違いは言語モデルの中ではなかった。間違いは結合の中にあった。

私は、このことが企業AIにおける最も過小評価されたリスクであり、最も議論されていないリスクであると考えるようになった。私たちは、モデル精度、プロンプト設計、ガバナンスについて無限に話す。ただし、システムが実際にどの実世界の顧客、サプライヤー、またはアカウントに対して行動しているかについてはあまり話さない。その質問には名前がある。それはエンティティ解決と呼ばれ、60年間のバックグラウンドの後、静かにライブインフラストラクチャーになっている。

問題の時制が変わった

そのほとんどの作業期間中、「これら2つのレコードは同じエンティティですか?」という質問はクリーンアップの質問だった。バッチで実行され、スケジュールに従って、マスター データ管理プログラム、ウェアハウス、または分析パイプラインの中で実行された。完全ではなかったが、生存可能だった。出力は次の週に誰かが読むレポートだったからだ。同じサプライヤーの2つのレコードが結合されていなかった場合、支出額が少し間違っていたが、分析者が気づき、次の実行で修正された。システムにはゆとりがあった。時間がエラーを吸収した。

AIエージェントはそのゆとりを取り除く。質問の時制を「最終的に」から「今」に変える。エージェントが返金を承認する、ケースをルーティングする、プロファイルを更新する、またはコンプライアンスの質問に答える前に、解決されたエンティティはダッシュボードにフィードするのではなく、アクションにフィードされる。間違った結合のコストは、少し間違っている数字から、世界ですぐに起こるもの、そして人間がキャッチするためのループがほとんどないものに変わる。

それは座って考える価値のある変化である。根本的な問題は古くから理解されていた。新しいのは、自分で動くシステムにそれを直接接続したことである。

1960年代の統計問題

エンティティ解決は、大規模言語モデルとともに到来しなかった。パンチカードとともに到来した。1959年、H. B. Newcombeと彼の同僚は、バイタルレコードの自動リンクについて、Science誌に短い論文を発表し、コンピューターが誕生レコードと結婚レコードが同じ人物を指しているかどうかを決定する方法を説明した。10年後、Ivan FellegiとAlan Sunterは、正式な数学理論を与え、現在でもマッチングシステムが生成する3つの結果を定義した:リンク、非リンク、レビューが必要な可能性のあるリンク。

その系譜の中で、人々が最も間違えやすい詳細がある。レコードリンクは、電子メールアドレスや共有IDでの完全な一致だけではなかった。初めから確率論的だった。姓、日付、場所での合意の証拠を重み付けし、スコアを生成した。人間が入力したデータは汚く、正確なキーは常に失敗するからである。現代のエンティティ解決もこのように機能する。決定的なルールと確率論的およびファジーなマシンラーニングマッチングを組み合わせ、タイポ、愛称、フィールドの入れ替え、略称、システム間で同じ人物または会社が異なる方法で表示されるさまざまな方法に対処する。フィールドの 調査 は、1950年代のバイタルレコードから現在使用されているクラスタリングとマシンラーニング方法まで、途切れることなく続く線を示している。

実際に変わったのは、答えが必要な時である。研究者は、クエリ時におけるエンティティの解決について、純粋に事前にではなく、現在のAIの波の前に書いていた。そこでは興味深い最適化だった。現在では、ほぼ要件に近い。

エージェントがインフラストラクチャーにする理由

ほとんどの企業AIシステムは、モデルのメモリから答えを出さない。検索する。 検索増強生成 として普及したパターンでは、エージェントは質問の瞬間に関連するコンテキストを取得し、そこで推論する。これは、全体として良いことである。答えをモデルのトレーニングではなく、データに基づいて行うからだ。

しかし、簡単に気づかない結果が伴う。エージェントは検索ステップが渡すものを継承する。検索が断片化された顧客を返す場合、3つの部分レコードが結合されていない場合、エージェントは3つの顧客について推論する。検索が間違った結合のレコードを返す場合、2つの異なる会社が1つのプロファイルにまとめられている場合、エージェントは1つの顧客について推論する。ソースシステムにすでに存在する曖昧さが、モデルに確立された事実として直接渡される。モデルは、読んだことのないレコードの整理された要約を読むのと同じように、間違った結合を知る方法がない。

したがって、解決は、四半期ごとに実行され、別のテーブルに着陸するあとに考えることではない。エンティティは、データが取り込まれるときに組み立てられ、現在の解決済みビューがエージェントが尋ねる瞬間に取得可能でなければならない。実行時依存関係である。これは、データベースや認証サービスよりも、定期的なデータクリーンアッププロジェクトよりも、実行時に設計、監視、信頼されるように扱われるべきである。

誰もが正確に名前を付けてはいない準備完了ギャップ

業界はすでに何かが欠けていることを感じている。シスコの AI Readiness Index 2025 では、83パーセントの組織が自律エージェントを展開することを計画しているが、約3分の1の組織のみがインフラストラクチャがそれらに本当に準備されていると感じており、約4分の1の組織のみがエージェントが実際に何をするかを制御および管理する準備ができていると感じている。マッキンゼーの最新の AIの状態 調査では、88パーセントの組織が現在AIを少なくとも1つの機能で使用しているが、ほとんどの組織がそれを企業全体に拡大していないと説明している。

人々がそのギャップを説明するとき、2つの単語を使用する傾向がある。データ品質とガバナンス。両方とも重要であり、どちらも省略できない。しかし、データ品質とガバナンスだけでは答えられない、より具体的な質問がある。システムは、レコードが実際のエンティティを指しているかどうかを、すべてのレコードが存在する場所で、現在、判断できるか。クリーンで管理されたデータだけではそのテストに答えられない。失敗は、1つのシステムの中に存在しない。システム間の空間にある。同じ顧客が3つの少し異なる顔で現れる場所にある。

エージェントを動作させる前に確認すること

エンティティ解決をライブインフラストラクチャーとして扱うと、インフラストラクチャーとして検査できる。運用上の故障モードは特定され、テスト可能である。分割されたアイデンティティ、レコードの誤った結合、古いサバイバー ルール、不足している永続的な識別子、エージェントがソース システムの曖昧さを解決された事実として継承することである。

実用的な準備テストには、新しいモデルや新しいベンダーカテゴリーは必要ない。真正なエンティティのセットを組み立てる。同じパスをエージェントが使用するパスで実行する。次に、実際の結果を決定するものを測定する。誤った結合と分割の数、真正な曖昧さの取り扱い、信頼性のしきい値、人間にエスカレートするタイミング、既存のマスター データとガバナンス コントロールへのクリーンなハンドオフ。チームがこれらの質問に答えることができない場合、エージェントは検証できないアイデンティティに基づいて行動し、その出力に対する信頼は誤りである。

これは、マスター データ管理、ガバナンス、顧客データ プラットフォーム、ウェアハウスを置き換えるものではない。ガバナンスは、エージェントが何を許可されるかを決定する。エンティティ解決は、誰、または何に対して行うかを決定する。前者はほとんどの大規模組織で成熟している。後者は、多くの組織がすぐに必要になる、リアルタイムの別のレイヤーである。

私が見たエージェントは、より賢いモデルが必要ではなかった。2つの名前が1つの顧客であることを知る必要があった。自信を持って確実であることを主張する前に。私たちがこれらのシステムに実際の権限を与えるにつれて、その静かな60歳の規律はクリーンアップではなく、負荷を支えるものになる。

スティーブン・レンウィックは、Tilores(tilores.io)の共同創設者兼CEOです。Tiloresは、AIとデータチーム向けのAPIを介したリアルタイムエンティティ解決を提供しています。彼は、エンジニアリングとデータリーダーと協力して、断片化されたシステム全体で顧客、サプライヤー、口座のアイデンティティを解決しています。