Der er et populært mønster i AI-branchen lige nu: Giv en sprogmodel adgang til værktøjer, og lad den finde ud af, hvad den skal kalde. Det fungerer fremragende i demoer. Det falder fra hinanden i produktion.
Hos Atlas Verified har vores AI-agent adgang til over 100 specialiserede værktøjer — myndighedsdatabaser til regeloverholdelse, API'er til skibssporing, sanktionsscreeningstjenester, handelsdataudbydere, containersporingssystemer og flere. Hvert værktøj findes, fordi en specialist i regeloverholdelse har brug for netop dette datapunkt for at træffe en verifikationsbeslutning. Den tekniske udfordring er ikke at bygge værktøjerne. Den er at sikre, at de rigtige værktøjer kaldes i den rigtige rækkefølge med de rigtige input, hver eneste gang.
Dette indlæg gennemgår de praktiske problemer med værktøjskoordinering i stor skala og de tekniske mønstre, vi har udviklet for at løse dem.
Problemet med eksplosiv vækst i antallet af værktøjer
Når din agent har 5 værktøjer, er værktøjsvalg trivielt. Modellen læser beskrivelserne af hvert værktøj, vælger det rigtige og kalder det. Men noget går galt, når du vokser ud over 20, 50, 100 værktøjer.
Først er der problemet med kontekstvinduet. Hvert værktøj kræver en beskrivelse, et parameterskema og brugsvejledning i systemprompten. Ved 100+ værktøjer betyder det titusindvis af tokens, der bruges, før brugerens spørgsmål overhovedet kommer ind i konteksten. Modellen bruger mere tid på at læse værktøjsdokumentation end på at tænke over problemet.
For det andet er der problemet med nøjagtigheden af valget. Sprogmodeller er gode til at vælge mellem en håndfuld tydeligt forskellige muligheder. De er dårlige til at vælge mellem snesevis af værktøjer, som lyder ens. Når du har flere værktøjer med overlappende navne til sanktionskontrol og screening, vælger modellen ofte det forkerte — eller kalder flere værktøjer, der returnerer overlappende data.
For det tredje er der problemet med omkostninger og ventetid. Hver værktøjsbeskrivelse i prompten koster tokens. Hvert unødvendigt værktøjskald koster API-kald til eksterne tjenester, hvoraf mange betales pr. forespørgsel. En agent, der kalder 8 værktøjer, når 3 ville være tilstrækkelige, er dyr og langsom.
Hvorfor statisk routing ikke fungerer
Den naive løsning er statisk routing: Find mønstre i brugerens spørgsmål, og send det til forudbestemte værktøjssæt. "Kontrollér denne virksomhed" udløser sanktionsscreening. "Spor denne container" udløser skibssporing. "Verificér dette certifikat" udløser et USDA-opslag.
Dette bryder straks sammen i praksis. Overvej spørgsmålet: "Kan du verificere dette økologiske certifikat fra Indien?" En statisk router kunne udløse et opslag i USDA's økologiske database — rimeligt. Men en specialist i regeloverholdelse vil også vide: Er certificeringsorganet sanktioneret? Er der aktive FDA-importadvarsler for produktet fra det pågældende land? Optræder eksportøren på nogen lister over udelukkede parter? Er der handelsmæssige uregelmæssigheder i den angivne rute?
Et enkelt brugerspørgsmål kan legitimt kræve fem eller flere værktøjer på tværs af helt forskellige områder. Statisk routing overser enten kritiske kontroller eller udløser alt for mange, hvilket bringer os tilbage til problemerne med omkostninger og nøjagtighed.
Kontekst betyder enormt meget. "Fortæl om denne virksomhed" betyder helt forskellige ting, afhængigt af om brugeren ser på et konnossement, et økologisk certifikat eller har en generel researchsamtale. De samme fire ord kræver forskellige værktøjer i hver kontekst.
Arkitektur med to lag: Valg og udførelse
Vores løsning adskiller værktøjsvalg fra værktøjsudførelse ved hjælp af to forskellige modellag.
Valglaget bruger en hurtig, billig model. Dens eneste opgave er at se på brugerens spørgsmål, samtalens kontekst og en kompakt oversigt over tilgængelige værktøjer og derefter vælge, hvilke værktøjer der skal være tilgængelige til netop denne interaktion. Den kalder ikke værktøjerne — den beslutter blot, hvilke udførelsesmodellen skal have adgang til.
Valgmodellen ser en forenklet repræsentation af hvert værktøj: en beskrivelse på én linje, hvilke data det returnerer, og dets begrænsninger. Dette er langt mere kompakt end fulde parameterskemaer, så valgmodellen kan evaluere alle 100+ værktøjer uden at ramme kontekstgrænser. Den vælger typisk 8-12 værktøjer, som er relevante for det aktuelle spørgsmål.
Udførelseslaget bruger en mere kapabel ræsonneringsmodel. Den modtager kun de værktøjer, valglaget valgte, med fulde parameterskemaer og brugsvejledning. Fordi den arbejder med et fokuseret værktøjssæt frem for hele kataloget, træffer den bedre beslutninger om, hvilke værktøjer den skal kalde, i hvilken rækkefølge og med hvilke parametre.
Denne adskillelse har målbare fordele. Valget tager en brøkdel af et sekund og koster meget lidt. Udførelsesmodellen ser en ren, fokuseret kontekst og begår færre fejl. Det samlede antal værktøjskald pr. interaktion faldt betydeligt, efter at vi indførte denne arkitektur.
Filtrering baseret på funktioner
Ud over valget i to lag angiver hvert værktøj i vores system sine funktioner — de typer opgaver, det kan udføre. Et værktøj kan angive, at det er nyttigt til kontrol af regeloverholdelse, handelsindsigt, dokumentanalyse eller forsendelsessporing.
Når systemet fastslår brugerens hensigt, filtrerer det værktøjskataloget, så det kun indeholder værktøjer med tilsvarende funktioner. Valgmodellen ser ikke engang værktøjer, der er irrelevante for den aktuelle opgavetype.
Dette er vigtigt af en subtil grund: Sprogmodeller er påvirkelige. Hvis et sanktionsscreeningsværktøj er i konteksten, kan modellen beslutte at udføre en sanktionskontrol, selv når brugeren stiller et enkelt spørgsmål om skibsruter. Ved at fjerne irrelevante værktøjer før valget eliminerer vi en hel kategori af unødvendige værktøjskald.
Feedbacksløjfer for kvalitet
Værktøjsvalg er kun halvdelen af arbejdet. Den anden halvdel er at sikre, at værktøjerne returnerer nyttige resultater — og at vide, hvad man skal gøre, når de ikke gør det.
Efter hver værktøjsudførelse evaluerer vores system resultatets kvalitet. Almindelige fejltyper omfatter:
Tomme resultater. Værktøjet kørte korrekt, men returnerede ingen data. Dette kan betyde, at virksomheden ikke findes i denne database (et gyldigt og informativt fund), eller at forespørgslen var dårligt udformet (et problem, der bør rettes og forsøges igen).
Matches med lav sikkerhed. En tilnærmet navnesøgning returnerer resultater, men matchscoren ligger under tærsklen. Systemet skal beslutte, om det skal præsentere disse som potentielle matches eller kassere dem og prøve en anden søgestrategi.
Utilstrækkelig stikprøvestørrelse. En forespørgsel om handelsdata returnerer resultater fra kun én datakilde, når flere kilder bør krydskontrolleres for at sikre pålidelighed. Systemet genkender dette hul og kan foranledige yderligere værktøjskald for at udfylde det.
Når kvalitetskontroller mislykkes, indsætter systemet vejledning tilbage i agentens ræsonneringssløjfe. Dette er ikke et simpelt genforsøg — det er et målrettet genforsøg, som forklarer, hvad der gik galt, og foreslår, hvordan forespørgslen kan omformuleres.
Trinvis levering af resultater
Verifikation af handelsregler består i sin natur af flere trin. En bruger uploader et konnossement og beder agenten om at verificere det. Agenten skal kontrollere afsenderen mod sanktionslister, verificere den økologiske certificering, slå skibets aktuelle position op, kontrollere FDA-importadvarsler for råvaren og validere toldklassificeringen. Disse kontroller tager forskellig tid.
I stedet for at lade brugeren vente på, at alle kontroller er færdige, før noget vises, streamer vi resultater gradvist. Når hvert værktøj returnerer, formateres dets resultater straks og leveres til brugerens grænseflade. Brugeren ser sanktionsresultater dukke op, derefter skibsdata og så økologisk certificeringsstatus, hver gengivet som et struktureret kort i det øjeblik, det er klar.
Det endelige syntesetrin, som producerer en sammenhængende opsummering, der forbinder alle resultaterne, køres først, når alle værktøjer er færdige.
Automatisk verifikation: Luk sløjfen
Når dokumenter behandles gennem vores OCR-proces, identificerer udtrækssystemet centrale datapunkter — NOP-id'er, virksomhedsnavne, skibsidentifikatorer, containernumre, havnekoder og HS-koder. Hvert af disse datapunkter knyttes til specifikke verifikationsværktøjer.
I stedet for at vente på, at en bruger spørger "verificér dette dokument", forudberegner systemet verifikationsanvisninger. Når brugeren åbner en samtale om et dokument, ved agenten allerede, hvilke værktøjer den skal kalde, og med hvilke parametre. Dette reducerer tiden til verifikation dramatisk: Agenten behøver ikke læse dokumentet, identificere virksomheder og derefter finde ud af, hvad der skal kontrolleres. Den har allerede en verifikationsplan klar til udførelse.
Principperne
Opbygningen af dette system har tydeliggjort flere principper, som vi mener gælder bredt for udvikling af AI-agenter:
Adskil valg fra udførelse. Lad ikke din ræsonneringsmodel også være din routingmodel. Brug billige, hurtige modeller til klassificering og dyre, kapable modeller til ræsonnering.
Færre valgmuligheder, større nøjagtighed. En model, der vælger mellem 10 veltilpassede værktøjer, klarer sig hver gang bedre end en, der vælger mellem 100 værktøjer. Investér i filtrering før valget.
Validér efter udførelse, ikke kun før. Værktøjskald fejler på måder, du ikke kan forudsige. Opbyg feedbacksløjfer for kvalitet, der opdager dårlige resultater og vejleder genforsøg.
Stream frem for at samle i batches. Brugere bør se resultater, efterhånden som de kommer. Trinvis levering er ikke blot en forbedring af brugeroplevelsen — den ændrer grundlæggende, hvordan brugere interagerer med verifikationsdata.
Gør hensigten eksplicit. Lad ikke modellen udlede, hvordan "godt" ser ud. Fortæl den det. Målplanlægning omdanner åben udforskning til målrettet verifikation.
Atlas Verifieds AI-agent koordinerer 100+ specialiserede verifikationsværktøjer for at automatisere kontrol af handelsregler på tværs af den globale forsyningskæde.