Entity Resolution se stává AI infrastrukturou, ne pouze úklidem dat

Před nějakou dobou jsem sledoval umělou inteligenci, která dávala sebevědomou, ale špatnou odpověď, a to z úplně banálního důvodu. Společnost měla dvě záznamy pro stejného firemního zákazníka. Jeden záznam obsahoval starý obchodní název a finanční kontakt. Druhý záznam obsahoval nový právní název, který společnost přijala po akvizici, a také jiný fakturační adresu. Agent byl požádán o jednoduchou otázku: je tento účet v pořádku? Našel jeden záznam, neviděl žádné překročené faktury, a řekl ano. Překročené faktury byly však uloženy pod jiným názvem.

Nic nebylo halucinováno. Model čistě rozumoval nad daty, která mu byla poskytnuta. Data se prostě náhodou týkala dvou zákazníků, kde ve skutečnosti existoval pouze jeden. Chyba nebyla v jazykovém modelu. Byla v spojení.

Dospěl jsem k názoru, že se jedná o jedno z nejpodceňovanějších rizik v podnikové AI a také o jednu z nejméně diskutovaných otázek. Mluvíme nekonečně o přesnosti modelu, návrhu dotazu a správě. Mluvíme mnohem méně o tom, zda systém skutečně ví, o kterém reálném zákazníkovi, dodavateli nebo účtu jedná. Tato otázka má název. Je to entity resolution, a po šedesáti letech v pozadí se tiše stává součástí živé infrastruktury.

Problém se změnil v čase

Po většinu své pracovní životnosti byla otázka “jsou tyto dva záznamy stejnou entitou?” otázkou úklidu. Běžel jste ji v dávkách, podle plánu, někde uvnitř programu pro správu hlavních dat, skladu nebo analytického potrubí. Nebyla to nikdy dokonalá otázka, ale byla to otázka, se kterou se dalo žít, protože výstupem byla zpráva, kterou někdo četl příští týden. Pokud nebyly dva záznamy pro stejného dodavatele sloučeny, výsledek výdajů byl mírně špatný, analytik si toho všiml a opravil to v příštím běhu. Systém měl volnost. Čas absorboval chyby.

Umělá inteligence odstraňuje tuto volnost. Změňuje časování otázky z “nakonec” na “nyní”. Když agent je na pokraji schválení refundace, směrování případu, aktualizace profilu nebo odpovědi na otázku compliance, vyřešená entita již není pouze krmením dashboardu. Je krmením akce. Náklad špatného spojení se přesouvá z čísla, které je mírně špatné, na něco, co se děje ve světě, okamžitě a často bez lidského zásahu, který by to chytnul.

Šedesátá léta statistického problému

Entity resolution nepřišla s velkými jazykovými modely. Přišla s děrnými kartami. V roce 1959 H. B. Newcombe a jeho kolegové publikovali krátkou práci ve vědeckém časopise o automatickém propojení životních záznamů, popisující, jak počítač může rozhodnout, zda se narození a sňatek týkají stejné osoby. O deset let později Ivan Fellegi a Alan Sunter dali této myšlence formální matematickou teorii, definující tři výsledky, které každý systém pro párování dosud produkuje: spojení, nespojení a možný spojení, který musí být přezkoumán osobou.

Existuje detail v tomto dědictví, na kterém je třeba se zaměřit, protože je to část, kterou lidé nejčastěji špatně pochopí. Record linkage nebyl nikdy pouze exact matching na e-mailové adrese nebo sdíleném ID. Od samého počátku to bylo pravděpodobnostní. Váhání důkazů, že dva záznamy souhlasí se jménem, datem, místem, a produkují skóre, protože lidsky zadaná data jsou špinavá a exact klíče selhávají neustále. Moderní entity resolution stále funguje tímto způsobem. Kombinuje deterministické pravidla, kde sdílený stabilní identifikátor je rozhodující, s pravděpodobnostním a fuzzy machine-learning párováním, které zvládá chyby, přezdívky, transponované pole, zkratky a tucet malých způsobů, jak stejná osoba nebo společnost vypadá jinak v různých systémech. Dobrý přehled tohoto oboru sleduje nepřerušenou linii od těch 50. let životních záznamů až po metody shlukování a strojového učení, které se používají nyní.

Proč agenti mění entity na infrastrukturu

Most podnikových systémů AI neodpovídá z paměti modelu. Načítají. Vzorec popularizovaný jako retrieval-augmented generation má agenta, který načítá relevantní kontext v okamžiku otázky a rozumí nad ním. To je, v rovnováze, dobrá věc. Zakotví odpovědi ve vašich datech, nikoli ve výcviku modelu.

Ale to má důsledky, které jsou snadno přehlédnutelné. Agent zdědí, co mu načítací krok předá. Pokud načítání vrátí fragmentovaného zákazníka, tři částečné záznamy, které nebyly nikdy propojeny, agent bude rozumět třem zákazníkům. Pokud načítání vrátí nesprávně sloučený záznam, dva různé společnosti zkolabované do jednoho profilu, agent bude rozumět jedné. Ambiguity již sedící ve vašich zdrojových systémech jsou předány přímo a prezentovány modelu jako vyřešený fakt. Model nemá žádný způsob, jak vědět, že spojení bylo špatné, stejně jako byste nevěděli, čtete-li stručný souhrn záznamů, které jste nikdy neviděli.

Mezera v připravenosti, kterou nikdo přesně nezmiňuje

Průmysl již cítí, že něco chybí. Index připravenosti AI společnosti Cisco z roku 2025 zjistil, že 83 procent organizací plánuje nasadit autonomní agenty, zatímco pouze asi třetina feels, že jejich infrastruktura je skutečně připravena na ně, a pouze asi čtvrtina feels, že je vybavena k ovládání a správě toho, co tito agenti skutečně dělají. Nejnovější průzkum společnosti McKinsey o stavu AI popisuje podobnou mezeru z opačné strany: asi 88 procent organizací nyní používá AI alespoň v jedné funkci, zatímco většina z nich belum rozšířila AI napříč celou firmou.

Co zkontrolovat, než dovolíte agentovi jednat

Pokud budete považovat entity resolution za živou infrastrukturu, můžete ji zkontrolovat jako infrastrukturu. Operační režimy selhání jsou specifické a testovatelné: rozdělené identity, které by měly být jedna, falešné spojení záznamů, které by měly zůstat oddělené, zastaralé pravidla pro přežití, které stále propagují nahrazenou adresu, chybějící trvalé identifikátory, a agenti, kteří dědí ambiguitu zdrojového systému jako vyřešenou pravdu.

Praktický test připravenosti nevyžaduje nový model nebo novou kategorii dodavatelů. Sestavte sadu entit, které skutečně rozumíte. Projděte ji stejnou cestou načítání, kterou používá váš agent, ne zvláštní čistou kopií postavenou pro demo. Pak změřte věci, které skutečně rozhodují o výsledcích: kolik falešných spojení a falešných rozdělení, jak systém zvládá skutečnou ambiguitu, kde jsou jeho prahové hodnoty, kdy eskaluje na člověka místo hádání a jak čistě předává stávající master data a kontrolní mechanismy. Pokud tým nemůže odpovědět na tyto otázky, agent jedná na základě identity, kterou nemůže ověřit, a důvěra v jeho výstup je špatně umístěna.

Žádné z toho nenahrazuje správu hlavních dat, správu, platformy zákaznických dat nebo sklad. Tyto odpovědi na jiné otázky a zůstávají nezbytné. Správa rozhoduje, co je agentovi dovoleno dělat. Entity resolution rozhoduje, kdo nebo co to dělá. První je zralý ve většině velkých organizací. Druhý je vrstva, kterou mnoho z nich brzy objeví, že potřebují vedle něj, v reálném čase, okamžikem, kdy dovolí agentovi jednat místo poradit.

Agent, kterého jsem sledoval, nepotřeboval chytřejší model. Potřeboval vědět, že dvě jména jsou jeden zákazník, než mohl znít jistě. Když předáváme těmto systémům skutečnou autoritu jednat, ta tichá, šedesátiletá disciplína přestává být úklidem a začíná být nosnou konstrukcí.