Entiteettien ratkaisu muuttuu AI-infrastruktuuriksi, ei vain tietojen puhdistukseksi

Olen aikaisemmin nähnyt, kuinka AI-väki antoi varman, väärän vastauksen aivan yksinkertaisesta syystä. Yrityksellä oli kaksi eri rekisteriä samasta asiakkaasta. Toinen rekisteri sisälsi vanhan kauppanimen ja rahoitusyhteyshenkilön, kun taas toisessa rekisterissä oli uusi, oikeudellinen nimi, jonka yritys oli ottanut käyttöön yritysostoksen jälkeen, sekä eri laskutusosoite. Väki kysyi yksinkertaista kysymystä: onko tämä tili hyvällä tolalla? Se löysi yhden rekisterin, ei löytänyt myöhässä olevia laskuja ja sanoi kyllä. Myöhässä olevat laskut olivat kuitenkin toisessa rekisterissä.

Mikään ei ollut “hallusinoitu”. Malli päätteli puhtaan logiikalla annetuista tiedoista. Tiedot vain tapahtuivat kuvaamaan kahta asiakasta, joista yksi oli todellisuudessa yksi. Virhe ei ollut kielimallissa. Se oli liitoksessa.

Olen alkanut ajatella, että tämä on yksi aliarvostetuimmista riskeistä yritysten AI:ssa ja vähiten keskustelluista. Puhumme loputtomasti mallin tarkin ja ohjelmoinnin suunnittelun ja hallinnan tarkkuudesta. Puhumme paljon vähemmän siitä, osaako järjestelmä todella tietää, minkä todellisen asiakkaan, toimittajan tai tilin se toimii. Tämän kysymyksen nimeksi on annettu entiteettien ratkaisu, ja 60 vuoden taustalla se on hiljalleen muuttumassa eläväksi infrastruktuuriksi.

Ongelma muutti aikamuotoa

Suurimman osan työelämästään “ovatko nämä kaksi rekisteriä sama entiteetti?” oli puhdistuskysymys. Sitä ajettiin eräajona, aikataulun mukaan, jossakin master data -hallintaprogramman, varastoinnin tai analytiikka-pipeline- sisällä. Se ei ollut koskaan täydellinen, mutta se oli selviytymiskelpoinen, koska tuloste oli raportti, jonka joku luki seuraavana viikkona. Jos kaksi rekisteriä samasta toimittajasta eivät yhdistyneet, kulutusluku tuli hieman väärä, analyytikko huomasi sen ja se korjattiin seuraavassa suoritukseen. Järjestelmässä oli joustoa. Aika imi virheet.

AI-väki poistaa tämän joustavan. Se muuttaa kysymyksen aikamuodon “myöhemmin” “nyt”. Kun agentti on lähellä hyväksyä hyvitystä, ohjata tapausta, päivittää profiilia tai vastata noudattamiskysymykseen, ratkaistu entiteetti ei enää ruoki raporttia. Se ruokkii toimintaa. Virheellisen liitoksen kustannukset siirtyvät luvusta, joka on hieman väärä, johonkin, joka tapahtuu maailmassa välittömästi ja usein ilman, että ihminen on silmukassa sen pyydystämiseksi.

Tämä on se siirtymä, jonka kanssa on istuttava. Alkuperäinen ongelma on vanha ja hyvin ymmärretty. Uusi asia on, että olemme kytkeneet sen suoraan järjestelmiin, jotka toimivat itsenään.

1960-luvun tilastollinen ongelma

Entiteettien ratkaisu ei saapunut suurten kielimallien kanssa. Se saapui rei’itetyillä korteilla. Vuonna 1959 H. B. Newcombe ja hänen kollegansa julkaisivat lyhyen artikkelin tiede -lehdessä vital -rekisterien automaattisesta linkityksestä, jossa kuvattiin, miten tietokone voisi päättää, viittaavatko syntymärekisteri ja avioliittorekisteri samaan henkilöön. Vuosikymmen myöhemmin Ivan Fellegi ja Alan Sunter antoivat idealle muodollisen matemaattisen teorian, jossa määriteltiin kolme tulosta, joita mikä tahansa vastaavuusjärjestelmä tuottaa edelleen tänään: linkki, ei-linkki ja mahdollinen linkki, jonka henkilön on tarkastettava.

On yksityiskohta siinä periytyvässä, jota on syytä pohtia, koska se on osa, jota ihmiset useimmiten väärin ymmärtävät. Rekisterin linkitys ei ollut koskaan vain tarkka vastaavuus sähköpostiosoitteessa tai jaetussa tunnisteessa. Alusta alkaen se oli todennäköisyysperäinen. Se punnitsi todisteita siitä, että kaksi rekisteriä sopivat sukunimestä, päivämäärästä, paikasta ja tuotti pisteytystä, koska ihmisten syöttämät tiedot ovat sekavia ja tarkat avaimet epäonnistuvat jatkuvasti. Nykyinen entiteettien ratkaisu toimii edelleen samalla tavalla. Se yhdistää deterministisiä sääntöjä, joissa jaettu vakaasti tunniste on ratkaiseva, todennäköisyysperäisellä ja sumealla koneoppimisella, joka sopeutuu kirjoitusvirheisiin, lempinimiin, kenttien transponointiin, lyhenteisiin ja kymmenen pienen tapaan, jolla sama henkilö tai yritys näyttäytyy eri järjestelmissä. Hyvä katsaus alasta jäljittelee katkeamatonta linjaa 1950-luvun elintarvikerekistereistä nykyään käytettyihin ryhmittymiseen ja koneoppimismenetelmiin.

Mitä on todella muuttunut, on se, milloin tarvitsemme vastauksen. Tutkijat kirjoittivat entiteettien ratkaisusta kyselyajan eikä pelkästään etukäteen, kauan ennen nykyistä AI-aaltoa. Silloin se oli mielenkiintoinen optimointi. Nyt se on lähempänä vaatimusta.

Miksi agentit muuttavat sen infrastruktuuriksi

Useimmat yritysten AI-järjestelmät eivät vastaa mallin muistista. Ne noutavat. Hakuaugmentoitu generointi -malli, jota agentti popularisoi, vetää relevantin kontekstin kyseessä olevaan hetkeen ja päättää sen yli. Tämä on kokonaisuutena ottaen hyvä asia. Se perustaa vastaukset tietoihisi eikä mallin koulutukseen.

Se kuitenkin sisältää seuraamuksen, jota on helppo missata. Agentti peri mitä hakuvaiheessa se saa. Jos hakuvaihe palauttaa fragmentoituneen asiakkaan, kolme osittain rekisteriä, jotka eivät koskaan yhdistyneet, agentti päättää kolmesta asiakkaasta. Jos hakuvaihe palauttaa väärän yhdistetyn, kaksi eri yritystä yhdistettyynä yhteen profiiliin, agentti päättää yhdestä. Jo olemassa oleva epävarmuus lähteessä siirretään suoraan ja esitetään mallille vakiintuneena tosiasiana. Mallilla ei ole mitään tapaa tietää, oliko liitos väärä, samoin kuin sinulla ei olisi tapaa tietää, luettaessa siistiä yhteenvetoa rekistereistä, joita et ole koskaan nähnyt.

Joten ratkaisu ei voi olla jälkijunassa, joka ajetaan kerran neljässä neljässä ja laskee erilliseen taulukkoon. Entiteetin on oltava kootettu, kun dataa syötetään, ja sen ratkaistu katsaus on oltava noudettavissa hetkellä, kun agentti kysyy. Tämä on suoritinriippuvuus. Se käyttäytyy enemmän kuin tietokanta tai todennuspalvelu kuin kuin aikataulun mukainen tietojen puhdistusprojekti, ja se on suunniteltava, valvottava ja luotettava samalla tavalla kuin kohdeltava muita järjestelmiä, joita sovelluksesi kutsuu reaaliajassa.

Valmiuskuilu, jota kukaan ei nimennyt tarkasti

Teollisuus jo aavistaa, että jotain puuttuu täältä. Ciscon AI-valmiusindeksi 2025 osoitti, että 83 prosenttia organisaatioista aikoo käyttää itsenäisiä agenteja, kun taas vain noin kolmannes uskoo, että heidän infrastruktuurinsa on todella valmis niille, ja vain noin neljännes uskoo olevansa varustettu hallitsemaan ja ohjaamaan sitä, mitä nämä agentit tekevät. McKinseyn viimeisin AI-tilanne -tutkimus kuvaa samanlaisen aukon toisesta suunnasta: noin 88 prosenttia organisaatioista käyttää nyt AI:ta vähintään yhdessä toiminnossa, mutta useimmat eivät ole skaalanneet sitä koko yrityksessä.

Kun ihmiset selittävät tämän aukon, he usein tarttuvat kahteen sanaan: tietojen laatu ja hallinto. Molemmat ovat tärkeitä, eikä kumpaakaan ole valinnainen. On kuitenkin kapeampi kysymys, joka on piilossa heidän alla: osaako järjestelmä kertoa, mihin todelliseen entiteettiin tietty rekisteri viittaa, kaikissa paikoissa, joissa rekisteri elää, juuri nyt? Voit pitää korkealaatuisia tietoja jokaisessa yksittäisessä järjestelmässä ja silti epäonnistua tässä testissä, koska epäonnistuminen ei asu yksittäisessä järjestelmässä. Se asuu niiden välissä, missä sama asiakas käyttää kolmea hieman erilaista kasvoa.

Mitä tarkistaa ennen kuin annat agentin toimia

Jos kohdeltava entiteettien ratkaisua live-infrastruktuurina, voit tarkastaa sen infrastruktuurina. Toiminnalliset virhemuodot ovat erityisiä ja testattavissa: jaetut identiteetit, jotka pitäisi olla yksi, virheelliset rekisterien yhdistämiset, joita pitäisi pitää erillään, vanhentuneet selviytymissäännöt, jotka edelleen edistävät vanhentunutta osoitetta, puuttuvat pysyvät tunnistimet ja agentit, jotka perivät lähdejärjestelmän epävarmuuden kuin vahvistettua totuutta.

Käytännöllinen valmiustesti ei vaadi uutta mallia tai uutta myyjäluokkaa. Kokoelma perustodisteita entiteeteistä, joita todella ymmärrät. Suorita se saman hakupolun kautta, jonka agenttisi käyttää, ei erillistä puhdasta kappaletta, joka on tehty esittelyyn. Mittaa sitten ne asiat, jotka todella päättävät tuloksia: montako virheellistä yhdistämistä ja virheellistä jakoa, miten järjestelmä käsittelee todellisen epävarmuuden, missä sen luottamuksen kynnykset ovat, milloin se eskaloituu ihmiseen arvaamisen sijaan ja miten siisti se luovuttaa olemassa oleviin master data- ja hallintotoimiin. Jos tiimi ei voi vastata näihin kysymyksiin, agentti toimii identiteetin, jonka se ei voi vahvistaa, ja luottamus sen tulosteeseen on väärä.

Nämä eivät korvaa master data -hallintaa, hallintoa, asiakastietojen alustoja tai varastoa. Nämä vastaavat eri kysymyksiä, ja ne ovat edelleen välttämättömiä. Hallinto päättää, mitä agentti on sallittu tehdä. Entiteettien ratkaisu päättää, kuka tai mitä se tekee. Ensimmäinen on kypsä useimmissa suurissa organisaatioissa. Jälkimmäinen on kerros, jonka monet ovat juuri löytämässä itselleen tarpeelliseksi reaaliajassa, hetkellä, jolloin he antavat agentin toimia neuvonantajan sijaan.

Agentti, jonka tarkkailin, ei tarvinnut fiksumpaa mallia. Se tarvitsi tietää, että kaksi nimeä olivat yksi asiakas ennen kuin se sai kuulostaa varmalta. Kun annamme näille järjestelmille todellisen toimivaltaa toimia, se hiljainen, 60-vuotias tietojen puhdistus muuttuu latakuormasta.