Det finnes et populært mønster i AI-bransjen akkurat nå: gi en språkmodell tilgang til verktøy og la den finne ut hvilke den skal kalle. Det fungerer utmerket i demoer. Det faller fra hverandre i produksjon.
Hos Atlas Verified har AI-agenten vår tilgang til over 100 spesialiserte verktøy — myndighetenes etterlevelsesdatabaser, fartøysporings-API-er, sanksjonsscreeningtjenester, handelsdataleverandører, containersporingssystemer og mer. Hvert verktøy finnes fordi en etterlevelsesfagperson trenger akkurat det datapunktet for å ta en verifiseringsbeslutning. Den tekniske utfordringen er ikke å bygge verktøyene. Det er å sikre at de riktige verktøyene blir kalt, i riktig rekkefølge, med riktige inndata, hver eneste gang.
Dette innlegget forklarer de praktiske problemene ved verktøykoordinering i stor skala og utviklingsmønstrene vi har laget for å løse dem.
Problemet med verktøyeksplosjon
Når agenten din har 5 verktøy, er verktøyvalg trivielt. Modellen leser beskrivelsene for hvert verktøy, velger det riktige og kaller det. Men noe går galt når du skalerer forbi 20, 50, 100 verktøy.
Først er det problemet med kontekstvinduet. Hvert verktøy trenger en beskrivelse, et parameterskjema og bruksveiledning i systeminstruksen. Ved 100+ verktøy er det titusenvis av tokener brukt før brukerens spørsmål engang kommer inn i konteksten. Modellen bruker mer tid på å lese verktøydokumentasjon enn på å tenke på problemet.
For det andre er det problemet med treffsikkerheten i valget. Språkmodeller er gode til å velge mellom en håndfull tydelig forskjellige alternativer. De er dårlige til å velge mellom dusinvis av verktøy som høres like ut. Når du har flere verktøy med overlappende navn for sanksjonskontroller og screening, velger modellen ofte feil — eller kaller flere verktøy som returnerer overlappende data.
For det tredje er det problemet med kostnader og ventetid. Hver verktøybeskrivelse i instruksen koster tokener. Hvert unødvendig verktøykall koster API-kall til eksterne tjenester, og mange av disse betales per forespørsel. En agent som kaller 8 verktøy når 3 ville vært nok, er dyr og langsom.
Hvorfor statisk ruting ikke fungerer
Den naive løsningen er statisk ruting: gjenkjenn mønstre i brukerens spørsmål og rut til forhåndsbestemte verktøysett. «Kontroller dette selskapet» utløser sanksjonsscreening. «Spor denne containeren» utløser fartøysporing. «Verifiser dette sertifikatet» utløser USDA-oppslag.
Dette bryter umiddelbart sammen i praksis. Tenk på spørsmålet: «Kan du verifisere dette økologiske sertifikatet fra India?» En statisk ruter kan utløse oppslag i USDAs økologiske database — rimelig nok. Men en etterlevelsesfagperson vil også vite: Er sertifiseringsorganet sanksjonert? Finnes det aktive FDA-importvarsler for produktet fra det landet? Forekommer eksportøren på noen lister over utestengte parter? Finnes det handelsavvik i den oppgitte ruten?
Ett enkelt brukerspørsmål kan med rette kreve fem eller flere verktøy på tvers av helt forskjellige fagområder. Statisk ruting overser enten kritiske kontroller eller utløser alt for bredt, noe som bringer oss tilbake til problemene med kostnad og nøyaktighet.
Kontekst betyr enormt mye. «Fortell om dette selskapet» betyr helt forskjellige ting avhengig av om brukeren ser på et konnossement, et økologisk sertifikat eller har en generell undersøkelsessamtale. De samme fire ordene krever forskjellige verktøy i hver kontekst.
Tolagsarkitektur: Valg og utførelse
Løsningen vår skiller verktøyvalg fra verktøyutførelse ved å bruke to forskjellige modellag.
Utvalgslaget bruker en rask, rimelig modell. Den eneste oppgaven er å se på brukerens spørsmål, samtalekonteksten og en kompakt oversikt over tilgjengelige verktøy, og deretter velge hvilke verktøy som bør være tilgjengelige for akkurat denne interaksjonen. Det kaller ikke verktøyene — det bestemmer bare hvilke utførelsesmodellen skal ha tilgang til.
Utvalgsmodellen ser en forenklet representasjon av hvert verktøy: en beskrivelse på én linje, hvilke data det returnerer og begrensningene. Dette er langt mer kompakt enn fullstendige parameterskjemaer, så utvalgsmodellen kan vurdere alle 100+ verktøy uten å treffe kontekstgrensene. Den velger vanligvis 8-12 verktøy som er relevante for det aktuelle spørsmålet.
Utførelseslaget bruker en mer kapabel resonneringsmodell. Det mottar bare verktøyene utvalgslaget valgte, med fullstendige parameterskjemaer og bruksveiledning. Fordi det arbeider med et målrettet verktøysett i stedet for hele katalogen, tar det bedre beslutninger om hvilke som skal kalles, i hvilken rekkefølge og med hvilke parametere.
Dette skillet har målbare fordeler. Utvalget tar en brøkdel av et sekund og koster svært lite. Utførelsesmodellen ser en ryddig, fokusert kontekst og gjør færre feil. Det totale antallet verktøykall per interaksjon falt betydelig etter at vi innførte denne arkitekturen.
Filtrering basert på funksjoner
Utover utvalget i to lag erklærer hvert verktøy i systemet vårt hvilke funksjoner det har — hvilke typer oppgaver det kan utføre. Et verktøy kan erklære at det er nyttig for etterlevelseskontroller, handelsinnsikt, dokumentanalyse eller forsendelsessporing.
Når systemet bestemmer brukerens hensikt, filtrerer det verktøykatalogen slik at bare verktøy med samsvarende funksjoner inkluderes. Utvalgsmodellen ser aldri engang verktøy som er irrelevante for den aktuelle oppgavetypen.
Dette er viktig av en subtil grunn: språkmodeller lar seg påvirke. Hvis et sanksjonsscreeningverktøy finnes i konteksten, kan modellen bestemme seg for å utføre en sanksjonskontroll selv når brukeren stiller et enkelt spørsmål om fraktruter. Ved å fjerne irrelevante verktøy før utvalget eliminerer vi en hel klasse unødvendige verktøykall.
Tilbakemeldingssløyfer for kvalitet
Verktøyvalg er bare halve arbeidet. Den andre halvparten er å sikre at verktøyene returnerer nyttige resultater — og vite hva man skal gjøre når de ikke gjør det.
Etter hver verktøyutførelse vurderer systemet vårt resultatkvaliteten. Vanlige feiltilstander inkluderer:
Tomme resultater. Verktøyet kjørte vellykket, men returnerte ingen data. Dette kan bety at virksomheten ikke finnes i den databasen (et gyldig og informativt funn), eller at forespørselen var dårlig utformet (et problem som bør rettes og forsøkes på nytt).
Treff med lav sikkerhet. Et omtrentlig navnesøk returnerer resultater, men treffscoren ligger under terskelen. Systemet må avgjøre om disse skal presenteres som potensielle treff eller forkastes til fordel for en annen søkestrategi.
Utilstrekkelig utvalgsstørrelse. En handelsdataforespørsel returnerer resultater fra bare én datakilde, når flere kilder burde krysskontrolleres for pålitelighet. Systemet gjenkjenner dette gapet og kan be om ytterligere verktøykall for å fylle det.
Når kvalitetskontroller mislykkes, legger systemet veiledning tilbake i agentens resonneringssløyfe. Dette er ikke et enkelt nytt forsøk — det er et styrt nytt forsøk som forklarer hva som gikk galt og foreslår hvordan forespørselen kan omformuleres.
Trinnvis levering av resultater
Verifisering av handelsetterlevelse innebærer naturlig flere trinn. En bruker laster opp et konnossement og ber agenten verifisere det. Agenten må kontrollere avsenderen mot sanksjonslister, verifisere den økologiske sertifiseringen, slå opp fartøyets nåværende posisjon, kontrollere FDAs importvarsler for råvaren og validere tollklassifiseringen. Disse kontrollene tar ulik tid.
I stedet for å la brukeren vente til alle kontrollene er fullført før noe vises, strømmer vi resultatene trinnvis. Når hvert verktøy returnerer, formateres resultatene umiddelbart og leveres til brukergrensesnittet. Brukeren ser sanksjonsresultater, deretter fartøydata og så økologisk sertifiseringsstatus, hver gjengitt som et strukturert kort i det øyeblikket det er klart.
Det siste sammenstillingstrinnet, som lager en fortellende oppsummering som knytter alle resultatene sammen, kjøres først etter at alle verktøy er fullført.
Automatisk verifisering: Lukk sløyfen
Når dokumenter behandles gjennom OCR-pipelinen vår, identifiserer uttrekkssystemet nøkkeldatapunkter — NOP-ID-er, selskapsnavn, fartøyidentifikatorer, containernumre, havnekoder og HS-koder. Hvert av disse datapunktene knyttes til bestemte verifiseringsverktøy.
I stedet for å vente på at en bruker spør «verifiser dette dokumentet», forhåndsberegner systemet verifiseringshint. Når brukeren åpner en samtale om et dokument, vet agenten allerede hvilke verktøy den skal kalle og med hvilke parametere. Dette reduserer tiden til verifisering dramatisk: agenten trenger ikke å lese dokumentet, identifisere virksomheter og deretter finne ut hva som skal kontrolleres. Den har allerede en verifiseringsplan klar til utførelse.
Prinsippene
Å bygge dette systemet har tydeliggjort flere prinsipper som vi mener gjelder bredt for utvikling av AI-agenter:
Skill valg fra utførelse. Ikke la resonneringsmodellen også være rutingsmodellen. Bruk rimelige, raske modeller for klassifisering og dyre, kapable modeller for resonnering.
Reduser valgmulighetene, øk nøyaktigheten. En modell som velger mellom 10 godt tilpassede verktøy, gjør det hver gang bedre enn en som velger mellom 100 verktøy. Invester i filtrering før utvalg.
Valider etter utførelse, ikke bare før. Verktøykall feiler på måter du ikke kan forutse. Bygg kvalitetstilbakemeldingssløyfer som oppdager dårlige resultater og veileder nye forsøk.
Strøm resultater, ikke samle dem i en bunke. Brukerne bør se resultater etter hvert som de kommer. Trinnvis levering er ikke bare en forbedring av brukeropplevelsen — den endrer grunnleggende hvordan brukere samhandler med verifiseringsdata.
Gjør hensikten uttrykkelig. Ikke la modellen utlede hvordan «godt» ser ut. Fortell den det. Målplanlegging omdanner åpen utforsking til målrettet verifisering.
Atlas Verifieds AI-agent koordinerer 100+ spesialiserte verifiseringsverktøy for å automatisere kontroller av handelsetterlevelse gjennom den globale forsyningskjeden.