Velge oppgave med fasit
Vi velger én oppgave som har et svar noen kan si er riktig eller galt.
20%
Tjeneste
AI-agenter
En agent er ikke en chatbot på forsiden. Det er et verktøy som gjør én oppgave, med tilgang til det den trenger og ingenting mer, og som sier fra når den er usikker.
- Tidsramme2-8 uker
- PrisFast etter avgrensning
- Dere sitter igjen medVerktøyet, promptene, evalueringssettet og loggen
Oversikt
AI-prosjekter strander sjelden på modellen. De strander når agenten får for stor oppgave, for dårlig grunnlag og svar ingen kan etterprøve. Da blir den prøvd noen ganger og lagt bort. Vi starter med det som mangler: en oppgave med fasit, ekte eksempler å måle mot og en navngitt person hos dere som svarer for feilene.
Vi bygger den motsatte veien. Én oppgave, et datagrunnlag vi vet hva er, og et svar som viser hvor det kommer fra. Agenten får et fast skjema å svare i, og en fasit vi måler den mot. Er oppgaven for uklar til det, sier vi det i stedet for å bygge.
Det den bygges inn i, er sjelden et chattevindu. Oftere er det et steg i en flyt som alt finnes: en e-post fra en kunde som får et svarutkast før noen sender det, en bestilling som sorteres til riktig person, eller et bilde fra befaringen som vurderes etter en fast sjekkliste. Vi bruker det samme mønsteret selv, i verktøyene vi driver studioet med.
Dette inngår
Oppgave og grenser. Vi skriver ned hva agenten skal gjøre, og en egen liste over hva den ikke skal svare på. Lista er en del av leveransen, ikke en fotnote.
Datagrunnlag. Vi kobler den mot dokumentene og systemene oppgaven trenger, og bare dem: via API eller eksport der det finnes, ellers ved at modellen leser skjermbildet. Går ingen av delene, sier vi det når oppgaven velges, ikke etterpå.
Evalueringssett. Ekte eksempler fra deres egen hverdag, med fasit satt av en fagperson hos dere. Det er dette agenten måles mot før noen tar den i bruk.
Godkjenning. Svaret peker på kilden sin, og der en feil koster noe, venter det på et menneske før noe skjer.
Når modellen feiler. Svarer ikke modellen, svarer den for sent eller utenfor skjemaet, tar en håndskrevet regel over, og saken går til den som godkjenner. En navngitt person hos dere får beskjed, så flyten står ikke stille uten at noen vet det.
Kostnadstak. Dere setter et tak på hvor mye agenten kan bruke av modellen i en periode, og vi bygger det inn. Går den seg fast eller får mange saker på én gang, stopper den ved taket til noen hos dere hever det.
Logg. Hver gang agenten spør modellen, lagres hva som gikk inn, hva som kom ut, og om svaret ble godkjent, endret eller avvist. Slik kan et rart svar spores, og et rettet svar kan bli et nytt eksempel i evalueringssettet.
Prosess5 steg
Samle ekte eksempler
Vi henter ekte eksempler fra historikken deres, med fasit fra en fagperson.
40%
Bygge og måle treff
Vi bygger mot eksemplene og måler treff for hver runde.
60%
Menneske i loopen
Vi setter reglene for hva som går gjennom og hva som skal godkjennes.
80%
Drifte der arbeidet skjer
Vi setter agenten inn der arbeidet gjøres, først for en liten gruppe.
100%
Passer for
Passer når
- Dere har én oppgave som gjentar seg, og en fagperson kan si om den ble løst riktig eller galt.
- Dere har historikk å hente eksempler fra: saker, henvendelser, dokumenter eller utkast som alt er ferdige.
- Dere kan sette av en fagperson som setter fasit og godkjenner underveis, ikke bare bestiller.
Passer ikke når
- Dere vil ha en åpen chatbot som svarer kundene på hva som helst.
- Ingen hos dere kan si hva et riktig svar er, eller det finnes ikke historikk å måle mot.
- Oppgaven gjøres sjelden, eller den er så uklar at ingen gjør den på samme måte.
Teknologi
Claude API
Modellen kalles direkte fra koden vi skriver for dere, med tekst eller skjermbilder og bare det oppgaven trenger.
Skjemavalidert JSON med Zod
Hvert svar må passe et skjema vi har bestemt på forhånd, ellers blir det avvist før det når noen.
Deterministisk fallback
Reglene som tar over når modellen ikke svarer, er vanlig kode uten modell i: samme resultat hver gang, og de kan leses, testes og endres.
Postgres
Svar, logg og evalueringssett lagres i en vanlig database dere kan eksportere og flytte, og de som vil, kan spørre den direkte.
Batch API
Mange like oppgaver, som å vurdere en bunke skjermbilder, kjøres samlet i stedet for én og én, uten at noen sitter og venter.
Next.js og TypeScript
Siden der noen godkjenner, og resten av verktøyet rundt agenten, bygges med det samme vi bygger nettsider med.
Eierskap og drift
Kode og innhold
Koden, promptene og lista over hva den ikke skal svare på, er deres og ligger i et kodearkiv dere har tilgang til. Evalueringssett, logg og data kan eksporteres og tas med.
Kontoer og tilganger
Tilgangene agenten bruker, opprettes på deres kontoer med bare det oppgaven trenger, og dere kan trekke dem tilbake selv. Om modellkontoen skal stå på dere eller på oss, avgjøres i avgrensningen.
Drift
Vi hoster agenten og har ansvaret for at den kjører. Dere trenger ikke egne folk til det tekniske, bare en fagperson som godkjenner det som venter og ser over loggen på en egen side.
Løpende kostnad
Driftsavtalen løper ved siden av fastprisen og dekker hosting og drift. Modellbruk og lisenser hos tredjepart kommer i tillegg og følger forbruket, og etter evalueringsrundene får dere et anslag på hva modellbruken vil koste.
Når noe endrer seg
Bytter modellen versjon, eller endrer et system agenten leser fra seg, kjører vi evalueringssettet igjen, og det inngår i driftsavtalen. Dere ser treffandelen før og etter, og er den lavere, retter vi før noe settes i drift.
Vi bruker det selv
Kontrollrommet
Prosesskartet på forsiden lages av modellen ut fra ett selskaps registerdata, i et fast skjema med forslag som passer bransjen. Svarer den ikke i tide eller utenfor skjemaet, vises en håndskrevet katalog for bransjen i stedet.
Tilbudsutkastene
Når vi skriver tilbud, lager modellen et første utkast med innledning og linjer med antall og pris. Utkastet er et utgangspunkt, ikke tilbudet: vi leser og endrer før det sendes.
Lead-pipelinen
Når vi ser på mange nettsider på en gang, vurderer modellen skjermbildet av hver: design, mobil, problemer og et forslag til innsalg. Vurderingen avgjør hvem vi tar kontakt med, og hva vi peker på i første e-post.
Spørsmål og svar
Oppgavens bredde og datagrunnlaget. Én oppgave med ett klart svar og ryddig historikk er rask å bygge. Jo flere unntak, kilder og godkjenningsledd, jo mer skal bygges og måles, og det er det vi avgrenser før prisen settes.
Hvilken oppgave skal den løse?
Beskriv oppgaven, så sier vi om en agent er riktig verktøy, eller om noe enklere gjør jobben.
Fortell oss hva dere trenger