Från prompt till produkt: att göra LLM:er till riktiga appar

En prompt som fungerar i en lekstuga är en demo, inte en produkt. Glappet mellan de två är där de flesta AI-projekt tyst dör. Att bygga LLM-applikationer som överlever riktiga användare handlar mindre om smart prompting än demorna antyder, och mycket mer om vanlig mjukvarudisciplin. Vi har levererat tillräckligt många av dessa — Youp, MadaiOps, och nu Linea — för att ha åsikter om vad som faktiskt stänger det glappet. Inget av det är glamoröst.

Fällan är att den första versionen känns färdig. Du klistrar in en smart prompt, modellen returnerar något imponerande, och det är frestande att linda in det i ett gränssnitt och kalla det en lansering. Sedan anländer riktiga användare med inmatningar du aldrig föreställt dig, modellen gör något tvärsäkert fel, och du upptäcker att du inte har något sätt att avgöra om din fix gjorde saker bättre eller sämre. Det här stycket handlar om ställningen som förvandlar den imponerande demon till något du kan köra i produktion och sova gott med om nätterna.

Börja med evalueringar, inte prompter

Det mest hävstångsstarka du kan bygga tidigt är en evalueringsuppsättning. Inte ett benchmark, inte en topplista — en mapp med riktiga inmatningar parade med hur en bra utmatning ser ut. Tjugo exempel slår noll, och femtio kurerade slår tusen skrapade.

Anledningen är enkel. När du väl har evalueringar slutar prompt-arbete vara känsla. Du ändrar en rad, du kör uppsättningen, du ser siffran röra sig. Utan dem är varje justering vidskepelse. Vi har sett team spendera en vecka på att förbättra en prompt bara för att regrediera på fall de löste för månader sedan, eftersom inget mätte de fall de inte tittade på.

Några åsikter vi håller fast vid:

Betygsätt utfall, inte formulering. För allt strukturerat — extraktion, klassificering, dirigering — bekräfta mot det tolkade resultatet, inte mot stränglikhet. För fritt formulerad text går en LLM-som-domare med ett stramt bedömningsschema bra, men validera domaren mot en handfull mänskliga etiketter först, annars mäter du bara en modells smak.
Håll en regressionsfil. Varje produktionsfel blir ett permanent testfall. Det är så din evalueringsuppsättning förblir ärlig — den växer i exakt de riktningar verkligheten trycker på.
Versionshantera dina evalueringar med dina prompter. En prompt utan sin evalueringsuppsättning är en oprövad kodändring.

Om du bygger en enda sak från den här artikeln, bygg denna. Allt nedströms beror på att kunna svara: gjorde det den bättre?

Skyddsräcken är billigare än ursäkter

Modeller misslyckas på sätt som vanlig mjukvara inte gör. De kommer att uppfinna ett API som inte finns, hålla med om en användares felaktiga premiss, eller avge giltigt utseende JSON med ett hallucinerat fält. Skyddsräcken är lagret som fångar detta innan det når en användare eller, värre, ett exekveringssteg.

Tänk i tre positioner.

Skyddsräcken för inmatning avvisar eller sanerar innan modellen körs: screening för prompt-injektion, redigering av personuppgifter, filtrering av irrelevant innehåll.
Skyddsräcken för utmatning validerar det som kommer tillbaka: schemavalidering, kontroll av källförankring, policyfilter.
Skyddsräcken för handlingar sitter mellan modellen och allt med sidoeffekter.

Det tredje är där den verkliga risken bor. I Linea, våra agenter för arbetsflödesautomation, kan modellen föreslå handlingar — anropa ett API, flytta en post, skicka ett meddelande. Förslaget och exekveringen är avsiktligt separata steg. Varje betydande handling passerar genom ett typat kontrakt och en policykontroll innan något körs, och destruktiva eller oåterkalleliga handlingar kräver en uttrycklig bekräftelsegrind. En agent som föreslår fel sak är ett UX-problem du kan iterera på. En agent som gör fel sak är en incident. Håll de två fellägena på motsatta sidor av en hård gräns.

Den åsiktsfulla versionen: validera strukturerad utmatning mot ett schema och gör om vid fel i stället för att lita på att modellen är konsekvent. Och låt aldrig en modells råa utmatning vara det som utlöser en oåterkallelig handling. Sätt en deterministisk kontroll däremellan, alltid.

Budgetera latens och kostnad som funktioner

Latens och kostnad är inte saker du mäter i slutet. De är begränsningar du designar mot från start, eftersom de förändrar arkitekturen, inte bara notan.

Sätt uttryckliga budgetar per användarvänd handling: ett mål för p95-latens och ett kostnadstak per anrop. När de väl är nedskrivna blir designbesluten enklare. Några mönster vi återkommer till gång på gång:

Rätt-dimensionera modellen per steg. De flesta pipelines har ett eller två steg som verkligen behöver frontier-modellen och flera som en mindre, snabbare hanterar bra. Att dirigera enkel klassificering till en billig modell och reservera den dyra för det svåra resonemangssteget är den mest avkastningsstarka optimering som finns, och den förbättrar oftast latensen också.
Streama den första token. För allt konversationsartat domineras upplevd latens av tid-till-första-token. Ett streamat svar som tar fyra sekunder känns bättre än ett blockerande som tar två.
Cacha aggressivt. Prompt-cachning på stabil systemkontext, vanlig resultatcachning på upprepade inmatningar. En betydande andel av produktionstrafiken är nästan-dubbletter.

Avvägningen att hålla i huvudet: större modeller minskar din tekniska ansträngning men höjer din marginalkostnad och latens för alltid. Billigare modeller flyttar arbete till dig — mer prompt-omsorg, fler skyddsräcken, fler evalueringar — men det arbetet är en engångskostnad mot en permanent besparing. För allt med volym, lägg ut den tekniska ansträngningen.

Håll människor i loopen, med avsikt

"Människa i loopen" sägs så ofta att det har slutat betyda något. Gjort väl är det inte en reservutväg för när AI:n misslyckas — det är en designad arbetsfördelning. Frågan är inte om man ska inkludera en människa utan var människans omdöme är värt mer än den latens det lägger till.

Mönstret som tjänat oss bäst är konfidensgrindad eskalering. Systemet hanterar den självsäkra majoriteten automatiskt och dirigerar den osäkra minoriteten till en person, med modellens resonemang bifogat så att människan beslutar på sekunder, inte minuter. I MadaiOps flyter orderoperationer inom normala parametrar igenom; allt avvikande lyfts fram till en operatör med kontext i stället för att exekveras tyst. Granskaren barnpassar inte maskinen. De spenderar sin uppmärksamhet endast där den är knapp och värdefull.

En regel till: instrumentera människans korrigeringar och mata tillbaka dem i din evalueringsuppsättning och dina prompter. Ett människa-i-loopen-system som inte lär sig av sina människor betalar bara dubbelt för samma arbete.

Vet vad du inte ska automatisera

Det svåraste omdömet i denna disciplin är återhållsamhet. Inte varje uppgift bör överlämnas till en modell, och mognad är att veta vilka man ska lämna ifred.

Vårt grova test: automatisera där kostnaden för ett misstag är låg, eller misstaget är lätt att upptäcka och återställa. Utkast, sammanfattning, extraktion, klassificering, dirigering — bra kandidater. Ett felaktigt utkast redigeras; en felaktig sammanfattning fångas vid läsning. Var mycket mer försiktig där fel är dyra, svåra att upptäcka eller oåterkalleliga: allt som flyttar pengar, skickar en oåterkallelig kommunikation, eller fattar ett juridiskt eller medicinskt beslut. Där hör modellen hemma i en assisterande roll — lyfta fram alternativ, skriva utkast för granskning — inte i förarsätet.

Gränsen vi håller: om du inte kan beskriva hur du skulle fånga modellen med fel, är du inte redo att automatisera det steget. Förmågan att upptäcka fel är den verkliga förutsättningen, mer än vad korrekthet är. Ett steg med 95 % korrekthet som du fullständigt kan verifiera är säkrare att leverera än ett med 99 % korrekthet som du inte kan.

Arbetets form

Att förvandla en prompt till en produkt är mestadels den oglamorösa delen: evalueringar så att du kan mäta, skyddsräcken så att fel förblir inkapslade, budgetar så att det förblir snabbt och prisvärt, människor placerade där omdöme spelar roll, och disciplinen att lämna vissa saker oautomatiserade. Modellen är kanske tjugo procent av systemet. De andra åttio procenten är den teknik som gör dess tillfälliga briljans säker att förlita sig på.

Den goda nyheten är att detta är bekant arbete. Det belönar samma instinkter som gör god mjukvara av alla slag: mät innan du ändrar, begränsa din sprängradie, respektera dina användares tid. Modellen är ny. Hantverket är det inte.