De fleste virksomheder, der spørger til AI, har allerede software, der virker. Et ERP, et sagssystem, en portal, en lagerapplikation og mange års data i dem. Spørgsmålet er sjældent, om der skal bygges noget nyt. Det handler om AI i eksisterende software: at få noget nyttigt ind i det, der allerede kører, uden at bygge om og uden at sætte kvartalet på spil.
Det er et langt smallere og langt mere håndterbart problem end “at indføre AI”. Sådan griber vi det an.
Hovedpointer
- Tag udgangspunkt i en beslutning, nogen træffer igen og igen, ikke i en model eller et værktøj.
- Fire mønstre dækker det meste nyttige arbejde i eksisterende systemer: opslag, klassificering, udkast og udtræk.
- Den svære del er næsten aldrig modellen. Det er jeres data og integrationen omkring dem.
- I har næsten helt sikkert ikke brug for at træne jeres egen model.
- Design ud fra, at den tager fejl. Alt, der handler uden gennemsyn, skal have en måde at fange fejl på.
- Den første funktion skal være lille nok til at gå i luften på uger og målbar nok til at kunne bedømmes.
Start med en beslutning, ikke med en model
De projekter, der ikke fører nogen steder hen, starter med teknologien: nogen vil bruge AI og leder derefter efter et sted at placere det. De projekter, der virker, starter med en konkret, gentagen beslutning, som et menneske i dag træffer ved at læse noget.
Hvilket team skal denne sag til. Er denne faktura en dublet. Hvad aftalte vi med denne kunde sidst. Hvilke af disse 400 ansøgninger matcher kravet. Hver af dem er afgrænset, sker hele tiden og har et rigtigt svar, man kan efterprøve. Netop den sidste egenskab gør det muligt at bygge, fordi man kan se, om funktionen virker.
Hvis ingen kan beskrive beslutningen i én sætning, er det for tidligt at bygge noget.
Fire mønstre for AI i eksisterende software
Opslag i jeres eget indhold
At besvare spørgsmål ud fra jeres egne dokumenter, politikker, sager eller produktdata. Modellen leverer sproget, jeres indhold leverer fakta, og hvert svar henviser til, hvor det kommer fra. Det er det mest almindelige nyttige mønster i en virksomhed, der har samlet meget skriftligt materiale, og det kræver ikke, at man ændrer det system, der opbevarer det.
Klassificering og routing
At læse en indkommende post og afgøre, hvad det er: hvilken kø, hvilken prioritet, hvilken kategori, hvilket team. Det erstatter en regelmotor, der er vokset til hundredvis af betingelser, som ingen tør røre. Det er let at evaluere, fordi I har historik, der viser, hvor tingene faktisk endte.
Udkast
At producere en første version, som et menneske redigerer: et svar, et resumé af en lang tråd, en beskrivelse, et afsnit i en rapport. Værdien ligger i de sparede minutter per post ganget med mængden, og mennesket bevarer kontrollen med, hvad der sendes ud.
Udtræk
At hente strukturerede felter ud af ustrukturerede dokumenter. Fakturaer, kontrakter, specifikationer, formularer. Det er det mønster med den klareste økonomiske case i de fleste driftsorganisationer, fordi alternativet er, at nogen taster de samme felter ind hele dagen.
Den svære del er jeres data
Næsten alle AI-projekter, vi har arbejdet på, brugte mere tid på data end på modeller. Ikke fordi data er dårlige, men fordi de er gemt for at drive forretningen, ikke for at blive læst af noget andet.
Poster er spredt over systemer uden fælles identifikator. Den samme kunde optræder på tre måder. Den brugbare tekst ligger i en PDF-vedhæftning frem for i et felt. Adgangsregler findes i applikationslaget, så et udtræk under det omgår stille og roligt de rettigheder, folk regner med.
Intet af det er exotisk, og alt af det tager tid. At få lager- og adgangslaget rigtigt er almindeligt ingeniørarbejde, og det er, hvad vores databaseudviklingstjeneste tager sig af sideløbende med den slags projekter. Budgettér ærligt for det, for det er der, tidsplanen reelt går hen.
Integrationslaget
En AI-funktion, der ligger i et separat værktøj, folk skal huske at åbne, bliver ikke brugt. Værdien opstår ved at placere den, hvor arbejdet allerede foregår: i sagsbilledet, i sagskøen, i ERP-formularen.
Det kræver en ren grænseflade mellem jeres eksisterende applikation og det, der udfører ræsonnementet, med fornuftig adfærd, når modellen er langsom eller utilgængelig. Behandl den som enhver anden ekstern afhængighed, med timeouts, gentagelser og en fallback, der lader folk arbejde videre. Det er almindeligt API-udviklingsarbejde, og at gøre det ordentligt er forskellen på en demo og en funktion. Hvor den omkringliggende applikation også skal have arbejde, hører det under applikationsudviklingstjenester.
Hvad det koster i drift
I modsætning til de fleste funktioner har denne en omkostning per anvendelse, og den bør beregnes, før I binder jer. Tre ting dominerer.
- Mængde. Omkostningen følger, hvor meget tekst der går ind og ud, så en funktion, der bruges på hver eneste post, opfører sig helt anderledes end en, der bruges på undtagelser.
- Kontekstens størrelse. At sende et helt dokument, når et afsnit ville være nok, er den mest almindelige kilde til unødigt forbrug.
- Caching. Gentaget arbejde på stabilt indhold kan ofte genbruges frem for at blive beregnet igen.
Svartid betyder også noget. Et menneske, der venter på skærmen, accepterer et sekund eller to. Et baggrundsjob må gerne tage et minut. Hvilken af delene I bygger, ændrer designet.
Design ud fra at den tager fejl
Disse systemer tager somme tider fejl med stor selvsikkerhed. Det er en egenskab, man designer omkring, ikke en grund til at lade være.
OWASP Top 10 for LLM Applications er et brugbart katalog over, hvordan disse systemer fejler i drift, og NIST AI Risk Management Framework er den reference, de fleste virksomhedsgennemgange skrives op imod. De praktiske regler er enkle. Alt, der går til kunder, gennemses før afsendelse, i hvert fald i starten. Alt, der skriver til et kildesystem, logges med detaljer nok til at rekonstruere, hvad der skete. Hver funktion har en målt træfsikkerhed på et sæt rigtige sager, der er holdt udenfor, og nogen ejer det tal. Sikkerheden vises, så folk ved, hvornår de skal se nærmere efter.
Hvis den eksisterende kodebase gør den slags logning og gennemsyn besværlig at tilføje, er det værd at vide, før I går i gang. En kodeaudit besvarer det hurtigt.
Et fornuftigt første projekt
Vælg én beslutning. Brug rigtige data, ikke en stikprøve. Sæt det i drift hos en lille gruppe, der faktisk udfører arbejdet. Mål mod det, de gjorde før. Giv det nogle uger, ikke et kvartal.
Pointen med det første projekt er ikke funktionen. Det er at finde ud af, hvordan jeres data i virkeligheden ser ud, hvordan integrationen opfører sig, og om de mennesker, der udfører opgaven, finder det nyttigt. Det er formålet med en MVP-udvikling, og det er en langt bedre brug af et første budget end en lang evaluering. Virker det, ved I, hvad nummer to skal være. Teams, der vil have kontinuitet over flere af den slags, sætter typisk et dedikeret udviklingsteam på det frem for at starte forfra hver gang, og vores AI-udviklingstjenester er bygget sådan.
Ofte stillede spørgsmål
Næsten helt sikkert ikke. De almindelige mønstre ovenfor bygges ved at give en eksisterende model adgang til jeres data i det øjeblik, den bliver spurgt, ikke ved træning. Træning bliver relevant i smalle tilfælde med store mængder mærkede eksempler, og det er en langt større forpligtelse. Start uden.
Det afhænger helt af leverandøren og den aftale, I er på, og det er et kontraktuelt spørgsmål frem for et teknisk. Erhvervsniveauerne hos de store leverandører udelukker som regel API-data fra træning. Få det på skrift, og send følsomme data derefter.
Saml et sæt rigtige sager med kendte, korrekte svar, før I bygger, og mål mod det. “God nok” er ikke en universel grænse, det er det, der slår den nuværende proces med acceptabel risiko. Uden det sæt gætter I, og det gør alle andre i lokalet også.
For én afgrænset beslutning på data, I allerede har adgang til, uger frem for måneder. Skal data først samles eller renses, dominerer det arbejde tidsplanen og bør estimeres for sig frem for at blive lagt ind i funktionen.
Bundlinjen
At tilføje AI til software, I allerede kører, er mest af alt almindeligt ingeniørarbejde: en klart defineret beslutning, ren adgang til jeres egne data, en solid integration og en måde at fange fejl på. Vælg én gentagen beslutning, bevis den på rigtige poster, mål den ærligt, og udvid derfra.
Vil I finde ud af, hvilken beslutning i jeres forretning der er den rigtige at starte med, så kontakt os. Vi ser på det, I kører i dag, og hvor det faktisk ville betale sig.
