Rezolvarea entităților devine infrastructură de inteligență artificială, nu curățarea datelor

Acum ceva timp, am văzut un agent de inteligență artificială care a dat un răspuns încrezător greșit, dintr-un motiv complet banal. O afacere avea două înregistrări pentru același client corporativ. Una conținea numele comercial vechi și un contact financiar. Cealaltă conținea numele legal nou al companiei, adoptat după o achiziție, împreună cu o adresă de facturare diferită. Agentul a fost întrebat o întrebare simplă: este acest cont în regulă? A găsit o înregistrare, a văzut că nu există facturi restante și a spus da. Facturile restante erau înregistrate sub numele celălalt.

Nimic nu a fost inventat. Modelul a raționat curat pe baza datelor pe care le-a primit. Datele au descris pur și simplu două clienți, unde, în lumea reală, exista unul singur. Greșeala nu a fost în modelul de limbaj. A fost în joncțiune.

Am ajuns să cred că acesta este unul dintre cele mai subestimate riscuri în inteligența artificială enterprise și unul dintre cele mai puțin discutate. Vorbeam în mod constant despre acuratețea modelului, proiectarea promptului și guvernanța. Vorbeam mult mai puțin despre faptul dacă un sistem știe, de fapt, pe care client, furnizor sau cont acționează. Acea întrebare are un nume. Se numește rezolvarea entităților, și după șaizeci de ani în fundal, se transformă în mod tacit într-o piesă de infrastructură vie.

Problema a schimbat timpul

Pentru cea mai mare parte a vieții sale de lucru, “sunt aceste două înregistrări aceeași entitate?” a fost o întrebare de curățare. Ați rulat-o într-un lot, la un anumit interval, undeva într-un program de gestionare a datelor master, un depozit sau o conductă de analiză. Nu a fost niciodată perfect, dar a fost suportabil, pentru că ieșirea a fost un raport pe care cineva l-a citit săptămâna viitoare. Dacă două înregistrări pentru același furnizor nu au fost unite, o cifră de cheltuieli a ieșit ușor greșit, un analist a observat și a fost corectat în următoarea rundă. Sistemul avea o anumită flexibilitate. Timpul a absorbit erorile.

Un agent de inteligență artificială elimină acea flexibilitate. Schimbă timpul întrebării de la “în cele din urmă” la “acum”. Când un agent este pe cale să aprobe o rambursare, să direcționeze un caz, să actualizeze un profil sau să răspundă la o întrebare de conformitate, entitatea rezolvată nu mai alimentează un tablou de bord. Alimentează o acțiune. Costul unei joncțiuni greșite se mută de la o cifră care este ușor incorectă la ceva care se întâmplă în lume, imediat, și adesea fără niciun om în buclă pentru a o prinde.

Acesta este schimbarea care merită să stea. Problema de bază este veche și bine înțeleasă. Ceea ce este nou este că am conectat-o direct la sisteme care acționează singure.

O problemă statistică din anii 1960

Rezolvarea entităților nu a apărut odată cu modelele de limbaj mare. A apărut cu cartele perforate. În 1959, H. B. Newcombe și colegii săi au publicat un scurt articol în revista Science despre legătura automată a înregistrărilor vitale, descriind modul în care un computer poate decide dacă o înregistrare a nașterii și o înregistrare a căsătoriei se referă la aceeași persoană. Un deceniu mai târziu, Ivan Fellegi și Alan Sunter au dat ideii o teorie matematică formală, definind cele trei rezultate pe care orice sistem de potrivire le produce și astăzi: o legătură, o non-legătură și o legătură posibilă care necesită revizuirea unei persoane.

Există un detaliu în acea linie pe care merită să ne oprim, pentru că este partea pe care oamenii o fac cel mai des greșit. Legătura de înregistrare nu a fost niciodată doar o potrivire exactă pe o adresă de e-mail sau un ID partajat. De la început a fost probabilistică. A cântărit probele că două înregistrări au fost de acord cu un nume de familie, o dată, un loc și a produs un scor, pentru că datele introduse de oameni sunt murdare și cheile exacte eșuează constant. Rezolvarea modernă a entităților funcționează încă în acest fel. Combina reguli deterministe, unde un identificator stabil partajat este decisiv, cu potrivirea probabilistică și fuzzy a mașinii de învățare care face față greșelilor de tastare, porecle, câmpuri transpuse, abrevieri și cele douăsprezece moduri mici în care aceeași persoană sau companie apare diferit în sisteme. Un sondaj bun al domeniului urmărește o linie neîntreruptă de la acele înregistrări vitale din anii 1950 la metodele de clustering și de învățare automată utilizate în prezent.

Ce a schimbat cu adevărat este momentul în care avem nevoie de răspuns. Cercetătorii scriau despre rezolvarea entităților la momentul întrebării, și nu doar înainte, cu mult înainte de valul actual de inteligență artificială. Atunci era o optimizare interesantă. Acum este mai aproape de o cerință.

De ce agenții o transformă în infrastructură

Majoritatea sistemelor de inteligență artificială enterprise nu răspund din memoria modelului. Ei recuperează. Modelul popularizat ca generare augmentată de recuperare are un agent care extrage contextul relevant în momentul întrebării și raționează asupra lui. Acesta este, în general, un lucru bun. Acesta fundamentează răspunsurile în datele dvs., și nu în memoria modelului.

Dar are o consecință care este ușor de pierdut din vedere. Agentul moștenește tot ceea ce îi este transmis de pașii de recuperare. Dacă recuperarea returnează o entitate fragmentată, trei înregistrări parțiale care nu au fost niciodată conectate, agentul va raționa despre trei clienți. Dacă recuperarea returnează o fuziune greșită, două companii diferite condensate într-un singur profil, agentul va raționa despre unul. Ambiguitatea care se află deja în sistemele dvs. de sursă este transmisă direct și prezentată modelului ca fapt stabilit. Modelul nu are niciun mod de a ști că joncțiunea a fost greșită, la fel cum nu ați ști, citind un rezumat ordonat de înregistrări pe care nu le-ați văzut niciodată.

Prin urmare, rezolvarea nu poate fi o gândire de după care rulează o dată pe trimestru și aterizează într-o tabelă separată. Entitatea trebuie să fie asamblată atunci când datele sunt introduse, iar vedere curentă rezolvată a acesteia trebuie să fie recuperabilă în momentul în care agentul o întreabă. Acesta este un mod de dependență la momentul rulării. Se comportă mult mai mult ca o bază de date sau un serviciu de autentificare decât ca un proiect de curățare a datelor periodic, și trebuie să fie proiectat, monitorizat și încredințat în același mod în care ați trata orice alt sistem pe care aplicația dvs. îl apelează în timp real.

Gap-ul de pregătire pe care nimeni nu îl numește exact

Industria simte deja că lipsește ceva aici. Indexul de pregătire pentru inteligență artificială Cisco 2025 a constatat că 83% dintre organizații plănuiesc să implementeze agenți autonomi, în timp ce doar aproximativ o treime se simt că infrastructura lor este cu adevărat pregătită pentru ei, și doar aproximativ un sfert se simt echipați pentru a controla și a guverna ceea ce fac acești agenți. Cel mai recent sondaj de stat al inteligenței artificiale McKinsey descrie o gap similară dintr-o altă direcție: aproximativ 88% dintre organizații utilizează inteligență artificială în cel puțin o funcție, dar majoritatea nu au extins-o la nivelul întregii întreprinderi.

Când oamenii explică această gap, tind să ajungă la două cuvinte: calitatea datelor și guvernanța. Ambele contează, și niciuna nu este opțională. Dar există o întrebare mai îngustă care stă sub ele și pe care datele curate și bine guvernate nu o pot răspunde singure. Poate sistemul să spună care entitate din lumea reală se referă la o înregistrare dată, în toate locurile în care acea înregistrare trăiește, chiar acum? Puteți ține date de calitate în fiecare sistem individual și totuși să eșuați în acest test, pentru că eșecul nu trăiește în interiorul vreunui sistem. Trăiește în spațiile dintre ele, unde același client poartă trei fețe ușor diferite.

Ce să verificați înainte de a lăsa un agent să acționeze

Dacă tratați rezolvarea entităților ca infrastructură vie, puteți inspecta-o ca atare. Modurile de eșec operațional sunt specifice și testabile: identități separate care ar trebui să fie una, fuziuni false de înregistrări care ar trebui să rămână separate, reguli de supraviețuire învechite care promovează în continuare o adresă înlocuită, identificatori persistenți lipsă, și agenți care moștenesc ambiguitatea sistemului de sursă ca și cum ar fi adevăr stabilit.

Un test de pregătire practic nu necesită un model nou sau o nouă categorie de furnizori. Asamblați un set de entități de bază pe care le înțelegeți cu adevărat. Rulați-l prin același traseu de recuperare pe care îl utilizează agentul dvs., și nu o copie curată construită pentru demo. Apoi măsurați lucrurile care decid cu adevărat rezultatele: câte fuziuni false și câte divizări false, cum sistemul gestionează ambiguitatea reală, unde se află pragurile de încredere, când escaladează către un om în loc să ghicească, și cum îi transmite în mod curat la controalele dvs. de date master și guvernanță existente. Dacă o echipă nu poate răspunde la aceste întrebări, agentul acționează pe o identitate pe care nu o poate verifica, și încrederea în ieșirile sale este înșelătoare.

Niciuna dintre acestea nu înlocuiește gestionarea datelor master, guvernanța, platformele de date ale clienților sau depozitul. Acestea răspund la întrebări diferite și rămân necesare. Guvernanța decide ce este permis unui agent să facă. Rezolvarea entităților decide cui sau ce îi face. Primul este matur în majoritatea organizațiilor mari. Al doilea este stratul pe care mulți sunt pe cale să descopere că au nevoie lângă el, în timp real, în momentul în care lasă un agent să acționeze, și nu doar să sfătuiască.

Agentul pe care l-am văzut nu a avut nevoie de un model mai deștept. A avut nevoie să știe că două nume erau un client înainte de a fi permis să sune sigur. Pe măsură ce acordăm acestor sisteme autoritate reală de a acționa, acea disciplină liniștită de șaizeci de ani încetează să mai fie curățarea datelor și începe să fie o piesă de susținere.