Rozwiązanie problemu tożsamości staje się infrastrukturą AI, a nie czyszczeniem danych

Jakiś czas temu obserwowałem, jak agent AI udzielił pewnej odpowiedzi z całkowicie błahych powodów. Firma miała dwie rekordy dla tego samego klienta korporacyjnego. Jeden z nich zawierał stare nazwy handlowe i kontakt finansowy. Drugi zawierał nową nazwę prawną, którą firma przyjęła po przejęciu, wraz z innym adresem rozliczeniowym. Agent został poproszony o proste pytanie: czy ten rachunek jest w dobrej kondycji? Znalazł jeden rekord, zobaczył brak zaległych faktur i powiedział tak. Zaległe faktury były jednak zapisane pod inną nazwą.

Nic nie było zmyślone. Model rozumował czysto nad danymi, które otrzymał. Dane po prostu opisywały dwa klientów, gdzie w rzeczywistości był tylko jeden. Błąd nie polegał na modelu językowym. Polegał na połączeniu.

Przyszedłem do wniosku, że jest to jeden z najbardziej niedocenianych ryzyk w przedsięwzięciach AI i jeden z najmniej omawianych. Rozmawiamy nieustannie o dokładności modelu, projekcie promtu i zarządzaniu. Mówimy znacznie mniej o tym, czy system naprawdę wie, jaki rzeczywisty klient, dostawca lub konto jest obiektem jego działania. To pytanie ma nazwę. Nazywa się rozwiązaniem problemu tożsamości, a po sześćdziesięciu latach w tle cicho staje się częścią infrastruktury.

Problem zmienił czas

Przez większość swojego życia “czy te dwie rekordy są tym samym podmiotem?” było pytaniem o czyszczenie. Wykonywało się je w partii, według harmonogramu, gdzieś w programie zarządzania danymi, magazynie lub potoku analitycznym. Nigdy nie było idealne, ale było przetrwalne, ponieważ wynik był raportem, który ktoś przeczytał tydzień później. Jeśli dwie rekordy dla tego samego dostawcy nie zostały połączone, wynik wydatków był nieco błędny, analityk zauważył to i poprawił w następnym przebiegu. System miał luz. Czas pochłonął błędy.

Agent AI usuwa ten luz. Zmienia czas pytania z “kiedyś” na “teraz”. Kiedy agent ma zatwierdzić zwrot, przekierować sprawę, zaktualizować profil lub udzielić odpowiedzi na pytanie zgodności, rozwiązany podmiot nie jest już wykorzystywany do raportu. Jest wykorzystywany do działania. Koszt błędnego połączenia przechodzi od liczby, która jest nieco błędna, do czegoś, co dzieje się na świecie, natychmiast i często bez udziału człowieka w pętli, który mógłby to złapać.

To jest zmiana, nad którą warto się zastanowić. Podstawowy problem jest stary i dobrze znany. Co nowe, to fakt, że podłączyliśmy go bezpośrednio do systemów, które działają samodzielnie.

Problem statystyczny z lat 60.

Rozwiązanie problemu tożsamości nie przybyło z dużymi modelami językowymi. Przybyło z kartami perforowanymi. W 1959 roku H. B. Newcombe i jego koledzy opublikowali krótki artykuł w Science na temat automatycznego połączenia rekordów, opisując, jak komputer może zdecydować, czy rekord urodzenia i rekord małżeństwa odnoszą się do tej samej osoby. Dekadę później Ivan Fellegi i Alan Sunter dali tej idei formalną teorię matematyczną, definiując trzy wyniki, które każdy system dopasowania nadal produkuje dzisiaj: połączenie, brak połączenia i możliwe połączenie, które wymaga przeglądu przez osobę.

Istnieje szczegół w tym pochodzeniu, nad którym warto się zastanowić, ponieważ jest to część, którą ludzie najczęściej mylą. Połączenie rekordów nigdy nie było tylko dokładnym dopasowaniem do adresu e-mail lub wspólnego identyfikatora. Od samego początku było to probabilistyczne. Ważyło dowody, że dwie rekordy zgadzają się co do nazwiska, daty, miejsca i produkowało wynik, ponieważ dane wprowadzane przez ludzi są brudne i dokładne klucze zawodzą ciągle. Współczesne rozwiązanie problemu tożsamości nadal działa w ten sposób. Łączy reguły deterministyczne, gdzie wspólny stabilny identyfikator jest decydujący, z probabilistycznym i rozmytym dopasowaniem za pomocą maszynowego uczenia, które radzi sobie z błędami, skrótowcami, przestawionymi polami, skrótowcami i tuzinem małych sposobów, w jaki ta sama osoba lub firma pojawia się inaczej w systemach. Dobra przegląd tego pola śledzi nieprzerwany szlak od tych rekordów z lat 50. do metod klastryzacji i maszynowego uczenia stosowanych obecnie.

Co się naprawdę zmieniło, to kiedy potrzebujemy odpowiedzi. Badacze pisali o rozwiązywaniu podmiotów w czasie zapytania, a nie tylko z wyprzedzeniem, zanim nastąpiła obecna fala AI. Wtedy było to interesujące optymalizowanie. Teraz jest to bliżej wymogu.

Dlaczego agenci robią to w infrastrukturze

Większość systemów AI przedsiębiorstw nie odpowiada z pamięci modelu. Pobierają. Wzorzec popularny jako pobieranie uzupełniające generowanie ma agenta, który pobiera istotny kontekst w momencie pytania i rozumuje nad nim. To jest, ogólnie rzecz biorąc, dobra rzecz. Ugruntowuje odpowiedzi w Twoich danych, a nie w treningu modelu.

Ale niesie to konsekwencję, której łatwo nie zauważyć. Agent dziedziczy wszystko, co krok pobierania mu podaje. Jeśli pobieranie zwraca fragmentarycznego klienta, trzy częściowe rekordy, które nigdy nie były połączone, agent będzie rozumował o trzech klientach. Jeśli pobieranie zwraca błędnie połączonego, dwie różne firmy scalone w jeden profil, agent będzie rozumował o jednym. Ambigualność już siedząca w Twoich systemach źródłowych jest przekazywana prosto i przedstawiana modelowi jako ustalony fakt. Model nie ma sposobu, aby wiedzieć, że połączenie było błędne, tak jak Ty, czytając ładne podsumowanie rekordów, których nigdy nie widziałeś.

Więc rozwiązanie problemu tożsamości nie może być pomyślane jako coś, co się wydarza raz na kwartał i ląduje w oddzielnej tabeli. Podmiot musi być złożony, gdy dane są pobierane, a bieżący widok rozwiązania musi być dostępny w momencie, gdy agent pyta. To jest zależność czasu wykonywania. Zachowuje się bardziej jak baza danych lub usługa uwierzytelniania niż jak okresowy projekt czyszczenia danych i musi być zaprojektowane, monitorowane i zaufane w ten sam sposób, w jaki traktujesz każdy inny system, który Twoja aplikacja wywołuje w czasie rzeczywistym.

Przerwa gotowości, której nikt nie nazywa precyzyjnie

Przemysł już czuje, że coś brakuje. Indeks gotowości AI 2025 Cisco wykazał, że 83 procent organizacji planuje wdrożyć autonomiczne agenty, podczas gdy tylko około jednej trzeciej czuje, że ich infrastruktura jest naprawdę gotowa do nich, a tylko około jednej czwartej czuje, że są wyposażone w kontrolę i zarządzanie tym, co ci agenci naprawdę robią. Najnowsze badanie stanu AI McKinsey opisuje podobną lukę z innego kierunku: około 88 procent organizacji używa AI w co najmniej jednej funkcji, a jednak większość z nich nie rozszerzyła go na całe przedsiębiorstwo.

Gdy ludzie wyjaśniają tę lukę, tendencja jest taka, że sięgają po dwa słowa: jakość danych i zarządzanie. Obie są ważne i żadna nie jest opcjonalna. Ale jest węższe pytanie ukryte pod nimi, które czyste, dobrze zarządzane dane nie odpowiedzą same z siebie. Czy system może powiedzieć, jaki rzeczywisty podmiot dany rekord odnosi, we wszystkich miejscach, w których ten rekord żyje, teraz? Można trzymać dane wysokiej jakości w każdym indywidualnym systemie i nadal zawieść ten test, ponieważ awaria nie mieszka wewnątrz jednego systemu. Mieszka w przestrzeniach między nimi, gdzie ten sam klient nosi trzy nieco różne twarze.

Co sprawdzić, zanim pozwolisz agentowi działać

Jeśli traktujesz rozwiązanie problemu tożsamości jako infrastrukturę, możesz ją sprawdzić jak infrastrukturę. Tryby awarii operacyjnej są szczegółowe i możliwe do przetestowania: podziały tożsamości, które powinny być jednym, fałszywe połączenia rekordów, które powinny pozostać oddzielne, przestarzałe reguły przetrwania, które nadal promują zastąpiony adres, brakujące trwałe identyfikatory, agenci dziedziczący niejasność systemu źródłowego, jak gdyby była to ustalona prawda.

Praktyczny test gotowości nie wymaga nowego modelu ani nowej kategorii dostawców. Zbierz zestaw podstawowych faktów o podmiotach, których naprawdę rozumiesz. Prześlij go przez tę samą ścieżkę pobierania, którą używa Twój agent, a nie oddzielną czystą kopię zbudowaną na potrzeby demo. Następnie zmierzyć rzeczy, które naprawdę decydują o wynikach: ile fałszywych połączeń i fałszywych podziałów, jak system radzi sobie z prawdziwą niejasnością, gdzie jego progi ufności się znajdują, kiedy eskaluje do człowieka zamiast zgadywać i jak czysto przenosi do Twoich istniejących kontroli danych i zarządzania. Jeśli zespół nie może odpowiedzieć na te pytania, agent działa na tożsamości, którą nie może zweryfikować, a zaufanie do jego wyjścia jest mylne.

Żadne z tego nie zastępuje zarządzania danymi, zarządzania, platform danych klienta, magazynu. Odpowiadają one na inne pytania i pozostają konieczne. Zarządzanie decyduje, co agent jest upoważniony do zrobienia. Rozwiązanie problemu tożsamości decyduje, kto lub co to robi. Pierwsze jest dojrzałe w większości dużych organizacji. Drugie jest warstwą, której wiele z nich zaraz odkryje, że potrzebują obok niego, w czasie rzeczywistym, w momencie, gdy pozwolą agentowi działać, a nie tylko doradzać.

Agent, którego obserwowałem, nie potrzebował mądrzejszego modelu. Potrzebował wiedzy, że dwie nazwy to jeden klient, zanim mógł brzmieć pewnie. Gdy dajemy tym systemom prawdziwą władzę do działania, ta cicha, sześćdziesięcioletnia dyscyplina przestaje być czyszczeniem i zaczyna być nośna.