Tekoälyalalla on nyt suosittu malli: anna kielimallille työkalut ja anna sen päättää kutsut. Se toimii loistavasti esittelyissä. Tuotannossa se hajoaa.
Atlas Verifiedissä tekoälyagenttimme käyttää yli 100 erikoistyökalua — viranomaisten vaatimustenmukaisuustietokannat, alusseuranta-API:t, pakoteseulontapalvelut, kauppatietopalveluntarjoajat, konttiseurantajärjestelmät ja muut. Jokainen työkalu on olemassa, koska vaatimustenmukaisuusammattilainen tarvitsee kyseisen tietopisteen varmennuspäätökseen. Tekninen haaste ei ole työkalujen rakentaminen. Se on sen varmistaminen, että oikeat työkalut kutsutaan oikeassa järjestyksessä oikeilla syötteillä joka kerta.
Tässä kirjoituksessa eritellään suuren mittakaavan työkalukoordinoinnin käytännön ongelmat ja niiden ratkaisemiseksi kehittämämme tekniset mallit.
Työkalumäärän räjähdysmäisen kasvun ongelma
Kun agentillasi on 5 työkalua, valinta on helppo. Malli lukee kuvaukset, valitsee oikean ja kutsuu sitä. Mutta jotakin rikkoutuu, kun mittakaava ylittää 20, 50 tai 100 työkalua.
Ensimmäinen ongelma on konteksti-ikkuna. Jokainen työkalu tarvitsee kuvauksen, parametrimallin ja käyttöohjeet järjestelmäkehotteessa. 100+ työkalulla kymmeniätuhansia tokeneita on käytetty ennen kuin käyttäjän kysymys edes saapuu kontekstiin. Malli käyttää enemmän aikaa työkaludokumentaation lukemiseen kuin ongelman pohtimiseen.
Toinen ongelma on valinnan tarkkuus. Kielimallit ovat hyviä valitsemaan muutamasta selvästi erilaisesta vaihtoehdosta. Ne ovat huonoja valitsemaan kymmenistä samankaltaisilta kuulostavista työkaluista. Kun useilla pakotetarkistus- ja seulontatyökaluilla on päällekkäisiä nimiä, malli valitsee usein väärän — tai kutsuu useita päällekkäisiä tietoja palauttavia työkaluja.
Kolmas ongelma on kustannus ja viive. Jokainen työkalukuvaus kehotteessa maksaa tokeneita. Jokainen tarpeeton työkalukutsu maksaa ulkoisten palvelujen API-kutsuja, joista moni laskutetaan pyyntökohtaisesti. Agentti, joka kutsuu 8 työkalua, kun 3 riittäisi, on kallis ja hidas.
Miksi staattinen reititys ei toimi
Yksinkertainen ratkaisu on staattinen reititys: käyttäjän kysymyksen mallin tunnistus ja ohjaus ennalta määritettyihin työkalujoukkoihin. ”Tarkista tämä yritys” käynnistää pakoteseulonnan. ”Seuraa tätä konttia” käynnistää alusseurannan. ”Varmenna tämä sertifikaatti” käynnistää USDA-haun.
Tämä rikkoutuu käytännössä heti. Harkitse kysymystä: ”Voitko varmentaa tämän Intiasta saadun luomusertifikaatin?” Staattinen reititin voisi käynnistää USDAn luomutietokantahaun — järkevää. Mutta vaatimustenmukaisuusammattilainen haluaa myös tietää: Onko sertifioija pakotteiden kohteena? Onko kyseisen maan tuotteelle aktiivisia FDA-tuontivaroituksia? Esiintyykö viejä kiellettyjen osapuolten listoissa? Onko ilmoitetussa reitissä kauppapoikkeamia?
Yksi käyttäjän kysymys voi perustellusti vaatia viisi tai useampia työkaluja täysin eri aloilta. Staattinen reititys joko jättää kriittiset tarkistukset tekemättä tai käynnistää liikaa kaikkea, mikä palauttaa kustannus- ja tarkkuusongelmiin.
Kontekstilla on valtava merkitys. ”Kerro minulle tästä yrityksestä” tarkoittaa täysin eri asioita sen mukaan, tarkasteleeko käyttäjä konossementtia, luomusertifikaattia vai käykö hän yleistä tutkimuskeskustelua. Samat neljä sanaa vaativat eri työkalut kussakin kontekstissa.
Kaksikerroksinen arkkitehtuuri: valinta ja suoritus
Ratkaisumme erottaa työkalun valinnan sen suorittamisesta kahdella erillisellä mallikerroksella.
Valintakerros käyttää nopeaa, edullista mallia. Sen ainoa tehtävä on katsoa käyttäjän kysymystä, keskustelukontekstia ja tiivistä saatavilla olevien työkalujen luetteloa ja valita tämän vuorovaikutuksen työkalut. Se ei kutsu niitä — se vain päättää, mitä suoritusmalli saa käyttää.
Valintamalli näkee jokaisesta työkalusta supistetun esityksen: yhden rivin kuvauksen, palautettavat tiedot ja rajoitukset. Tämä on paljon tiiviimpi kuin täydelliset parametrimallit, joten valintamalli voi arvioida kaikki 100+ työkalua törmäämättä kontekstirajoihin. Se valitsee yleensä 8-12 nykyiseen kysymykseen sopivaa työkalua.
Suorituskerros käyttää kyvykkäämpää päättelymallia. Se saa vain valintakerroksen valitsemat työkalut täydellisine parametrimalleineen ja käyttöohjeineen. Koska se työskentelee kohdennetulla työkalujoukolla koko luettelon sijaan, se päättää paremmin, mitä kutsua, missä järjestyksessä ja millä parametreilla.
Erottelulla on mitattavia hyötyjä. Valinta vie sekunnin murto-osan ja maksaa hyvin vähän. Suoritusmalli näkee selkeän, kohdennetun kontekstin ja tekee vähemmän virheitä. Vuorovaikutuskohtaiset työkalukutsut vähenivät merkittävästi arkkitehtuurin käyttöönoton jälkeen.
Ominaisuuspohjainen suodatus
Kaksikerroksisen valinnan lisäksi jokainen järjestelmämme työkalu ilmoittaa kykynsä — tehtävätyypit, jotka se voi suorittaa. Työkalu voi ilmoittaa soveltuvansa vaatimustenmukaisuustarkistuksiin, kauppatietoon, asiakirja-analyysiin tai toimitusseurantaan.
Kun järjestelmä määrittää käyttäjän tarkoituksen, se suodattaa työkaluluettelosta vain vastaavat kyvyt sisältävät työkalut. Valintamalli ei edes näe nykyiseen tehtävätyyppiin kuulumattomia työkaluja.
Tämä on tärkeää hienovaraisesta syystä: kielimallit ovat johdateltavissa. Jos pakoteseulontatyökalu on kontekstissa, malli voi päättää suorittaa pakotetarkistuksen, vaikka käyttäjä kysyy yksinkertaista kuljetusreittikysymystä. Poistamalla epäolennaiset työkalut ennen valintaa poistamme kokonaisen tarpeettomien kutsujen luokan.
Laadun palautesilmukat
Työkalun valinta on vain puolet työstä. Toinen puoli on varmistaa hyödylliset tulokset — ja tietää, mitä tehdä, kun niitä ei saada.
Järjestelmämme arvioi tuloksen laadun jokaisen työkalusuorituksen jälkeen. Yleisiä vikatapoja ovat:
Tyhjät tulokset. Työkalu suoritettiin onnistuneesti mutta ei palauttanut tietoja. Tämä voi tarkoittaa, ettei toimijaa ole tietokannassa (kelvollinen ja informatiivinen havainto) tai että kysely oli huonosti muodostettu (korjattava ja uudelleen kokeiltava ongelma).
Matalan varmuuden osumat. Epätarkka nimihaku palauttaa tuloksia mutta osumapisteet alittavat kynnyksen. Järjestelmän on päätettävä, esitetäänkö ne mahdollisina osumina vai hylätäänkö ne ja kokeillaanko eri hakustrategiaa.
Riittämätön otoskoko. Kauppatietohaku palauttaa tuloksia vain yhdestä lähteestä, vaikka luotettavuus edellyttäisi useiden lähteiden ristiintarkistusta. Järjestelmä tunnistaa aukon ja voi pyytää lisää työkalukutsuja sen täyttämiseksi.
Kun laatutarkistukset epäonnistuvat, järjestelmä palauttaa ohjeet agentin päättelysilmukkaan. Tämä ei ole pelkkä uudelleenyritys — se on ohjattu yritys, joka selittää virheen ja ehdottaa kyselyn uudelleenmuotoilua.
Tulosten asteittainen toimittaminen
Kaupan vaatimustenmukaisuuden varmennus on luonnostaan monivaiheinen. Käyttäjä lataa konossementin ja pyytää agenttia varmentamaan sen. Agentin on tarkistettava lähettäjä pakotelistoista, varmennettava luomusertifiointi, haettava aluksen nykyinen sijainti, tarkistettava raaka-aineen FDA-tuontivaroitukset ja validoitava tulliluokitus. Näiden tarkistusten kestot vaihtelevat.
Sen sijaan, että käyttäjä odottaisi kaikkien tarkistusten valmistumista ennen mitään näyttöä, toimitamme tulokset asteittain. Jokaisen työkalun palautuessa sen tulokset muotoillaan heti ja toimitetaan käyttöliittymään. Käyttäjä näkee ensin pakotetulokset, sitten alustiedot ja luomusertifiointitilan, jokaisen jäsenneltynä korttina heti valmistuttuaan.
Lopullinen yhdistelyvaihe, joka tuottaa kaikki tulokset yhteen sitovan sanallisen yhteenvedon, suoritetaan vasta kaikkien työkalujen valmistuttua.
Automaattinen varmennus: silmukan sulkeminen
Kun asiakirjat käsitellään OCR-putkessamme, poimintajärjestelmä tunnistaa keskeiset tietopisteet — NOP ID -tunnukset, yritysnimet, alustunnisteet, konttinumerot, satamakoodit ja HS-koodit. Jokainen liittyy tiettyihin varmennustyökaluihin.
Sen sijaan, että odottaisimme käyttäjän pyyntöä ”varmenna tämä asiakirja”, järjestelmä laskee varmennusvihjeet etukäteen. Kun käyttäjä avaa asiakirjaa koskevan keskustelun, agentti tietää jo kutsuttavat työkalut ja parametrit. Tämä vähentää varmennusaikaa merkittävästi: agentin ei tarvitse lukea asiakirjaa, tunnistaa toimijoita ja sitten selvittää tarkistuksia. Sillä on jo valmis varmennussuunnitelma.
Periaatteet
Järjestelmän rakentaminen on kiteyttänyt useita periaatteita, joiden uskomme soveltuvan laajasti tekoälyagenttien suunnitteluun:
Erota valinta suorituksesta. Älä tee päättelymallistasi myös reititysmallia. Käytä edullisia nopeita malleja luokitteluun ja kalliita kyvykkäitä malleja päättelyyn.
Vähennä valintoja, lisää tarkkuutta. 10 hyvin sopivasta työkalusta valitseva malli päihittää 100 työkalusta valitsevan joka kerta. Panosta suodatukseen ennen valintaa.
Validoi suorituksen jälkeen, ei vain ennen. Työkalukutsut epäonnistuvat tavoilla, joita et voi ennustaa. Rakenna laadun palautesilmukat, jotka havaitsevat huonot tulokset ja ohjaavat uudelleenyrityksiä.
Toimita jatkuvasti, älä erissä. Käyttäjien tulee nähdä tulokset niiden saapuessa. Asteittainen toimittaminen ei vain paranna käyttökokemusta — se muuttaa perustavasti käyttäjien vuorovaikutusta varmennustietojen kanssa.
Ilmaise tarkoitus selvästi. Älä anna mallin päätellä, miltä ”hyvä” näyttää. Kerro sille. Tavoitesuunnittelu muuttaa avoimen tutkimisen ohjatuksi varmennukseksi.
Atlas Verifiedin tekoälyagentti koordinoi 100+ erikoistunutta varmennustyökalua automatisoidakseen kaupan vaatimustenmukaisuustarkistukset maailmanlaajuisessa toimitusketjussa.