The real work is before the prompt.
Promptworkshopen som startade för sent
Workshopen var bokad för att förbättra prompts. Det var rubriken i kalendern, med en gladlynt liten trollstavsikon som någon ångrade senare. En grupp chefer, analytiker, operatörer och ingenjörer satt runt ett bord med ett delat dokument. Den aktuella prompten var på skärmen. Den bad en språkmodell att granska kundförfrågningar, identifiera rätt policy, utforma ett svar och flagga risker. Den var artig, strukturerad och mycket längre än någon ville erkänna. Den var inte heller huvudproblemet.
Det första testfallet var en kund som bad om ett undantag efter en försenad leverans. Modellen producerade ett hyfsat svar. Sedan sa någon från drift att källpolicyn på skärmen inte längre var den som teamet använde på fredagar, eftersom en tillfällig transportörsregel hade förlängts två gånger men aldrig slagits samman med huvudpolicysidan. Någon från juridik sa att undantag över ett visst belopp krävde godkännande, men att tröskeln berodde på produktkategori. Ekonomi frågade var goodwillkrediter bokfördes. Support sa att modellens ton var bra, men att kunden skulle ringa igen eftersom svaret inte nämnde den saknade spårningshändelsen. Prompten satt där och såg oskyldig ut.
Inget av dessa problem skulle lösas av ett bättre instruktionsstycke. Modellen kunde inte sluta sig till vilken policysida som var auktoritativ. Den kunde inte veta att en tillfällig regel hade blivit operativ verklighet. Den kunde inte avgöra vem som hade godkännandebefogenhet. Den kunde inte se att den saknade spårningshändelsen var den verkliga orsaken till nästa kontakt. Prompten ombads kompensera för otydligt arbete. Detta är ett vanligt misstag. Människor kommer till prompten med en korg av processmässig otydlighet och ber modellen vara elegant kring den.
Det verkliga arbetet kommer före prompten. Det är arbetet med att namnge uppgiften, definiera gränsen, välja källor, fastställa auktoritet, förbereda exempel, besluta om felvägar, forma utdata, mäta kvalitet och göra korrigering möjlig. Promptande spelar roll. En dålig prompt kan göra en bra uppsättning klumpig. Men en vacker prompt ovanpå en otydlig verksamhet är bara välsformulerad förvirring. Modellen kan låta bättre. Arbetet blir inte säkrare, billigare eller mer begripligt av en slump.
En prompt är inte en processkarta
En prompt kan tala om för en modell hur den ska bete sig i ett sammanhang. Den kan inte skapa sammanhanget om organisationen inte redan har gjort det. Den kan be om korthet, struktur, ödmjukhet och källhänvisningar. Den kan beskriva en roll. Den kan specificera ett format. Den kan varna modellen för att gissa. Detta är användbart. Men det är också smått jämfört med de processfrågor som avgör om ett AI-system hjälper till eller bara talar självsäkert i närheten av arbetet.
Vad är uppgiften. Är det klassificering, extraktion, sammanfattning, utkast, dirigering, rekommendation, verifiering eller åtgärd. Vilken del är automatiserad. Vilken del förblir mänsklig. Vilka tillstånd ändras om utdata accepteras. Vem påverkas. Vilka register berörs. Vilken policy gäller. Vilka bevis är obligatoriska. Vad händer när bevis saknas. Vilka misstag är tolerabla. Vilka misstag orsakar skada. Dessa frågor avgör systemets form. En prompt som inte vilar på tydliga svar blir en artig gissning med namnbricka.
Många misslyckade AI-piloter börjar med en prompt eftersom prompten är det mest synliga handtaget. Den känns kreativ och omedelbar. Du kan redigera den på ett möte. Du kan prova en ny version innan kaffet hinner kallna. Processdesign är långsammare. Datastädning är långsammare. Behörighetskartläggning är långsammare. Utvärderingsuppsättningar tar längre tid att bygga. Tyvärr är långsamt inte detsamma som valfritt. De delar som hoppas över före prompten återkommer senare som hallucination, omarbetning, misstro, policyundantag och ett stort kalkylblad som kallas ärenden.
Den bättre ordningen är inte glamorös. Skriv ner arbetet. Gå igenom verkliga fall. Identifiera källsystem. Markera vilka fält som avgör utfall. Separera regler från bedömning. Bestäm var människor kliver in. Definiera utdatakontrakt. Bygg exempel. Kom överens om avvisande. Testa med de människor som ska leva med resultatet. Först då blir prompten en användbar hävstång. Innan dess är den en dekorativ ratt på ett skrivbord.
Uppgiften behöver en gräns skarp nog att testa
AI-arbete börjar ofta med verb som är för stora. Hjälpa till med kundservice. Stödja juridisk granskning. Förbättra planering. Bistå upphandling. Göra rapportering smartare. Detta är ambitioner, inte uppgifter. En modell kan inte utvärderas mot en ambition. Den kan utvärderas mot en uppgift med indata, utdata, begränsningar, framgångskriterier och felvägar. Den snävare beskrivningen kan kännas mindre spännande. Den är också det första ögonblicket då arbetet blir byggbart.
En skarp uppgiftsgräns anger vad systemet får se och vad det får ändra. Den anger om modellen läser källmaterial, genererar ett utkast, extraherar strukturerade fält, rekommenderar en åtgärd eller anropar ett verktyg. Den anger vilka utdata som är slutgiltiga, vilka som är rådgivande och vilka som måste granskas. Den anger vad systemet avvisar. Den anger när modellen ska be om mer bevis i stället för att slutföra svaret. Den anger vad som ligger utanför omfattningen, eftersom det är utanför omfattningen som ambitiösa piloter blir incidentrapporter.
Gränser gör utvärdering möjlig. Om uppgiften är att skriva ett utkast till svar med hjälp av dessa källor och denna policy kan kvaliteten testas. Om uppgiften är att förbättra servicekvaliteten med AI kan varje resultat förklaras som framsteg av någon med tillräckligt många bilder. En gräns skyddar också användare från oavsiktlig eskalering. Ett verktyg som börjar med att skriva utkast kan få en knapp som skickar. En klassificerare kan bli en dirigent. En dirigent kan bli ett beslut. Utan en namngiven gräns känns denna förskjutning som införande. Med en gräns blir den en ändringsbegäran.
Gränsen bör formuleras i operativt språk, inte bara i tekniskt språk. Supportansvarig ska förstå den. Juridik ska förstå den. Dataägaren ska förstå den. Ingenjören ska kunna testa den. Om prompten är den enda plats där gränsen lever, är gränsen skör. Prompter är viktiga, men de är inte bärande policy-dokument. De är mer som instruktioner till en mycket begåvad tillfällig medarbetare som aldrig sett organisationsschemat.
Källor är inte en hög med dokument
Många team upptäcker under promptarbetet att de inte vet vilka källor som är auktoritativa. De har policy-sidor, PDF:er, e-postinstruktioner, utbildningsmaterial, äldre manualer, chattmeddelanden, ärendemakron, kalkylbladsregister och minnet hos en operatör som alla ringer för att hon vet hur det egentligen fungerar. Modellen ombeds sedan svara utifrån kunskapsbasen. Vilken kunskap. Vilken bas. Frasen kan dölja heroiska mängder otydlighet.
Källförberedelse är inte glamoröst, vilket är varför det ofta blir försenat. Det handlar om att bestämma vilket dokument som vinner när källor motsäger varandra, hur färskhet kontrolleras, hur tillfälliga regler upphör, hur undantag representeras, hur konfidentiellt material exkluderas, hur källversioner bevaras och hur citeringsidentifierare överlever modellens svar. Detta är inte pappersarbete. Det är skillnaden mellan återhämtning och rotande.
AI gör källdisciplin viktigare eftersom modellen kan få svaga källrutiner att se acceptabla ut. Den kan sy ihop fragment till flytande prosa. Den kan jämna ut motsägelser. Den kan producera ett trovärdigt svar från föråldrat material. Ett sökresultat med synliga luckor känns ofullständigt. Ett genererat svar med samma luckor kan kännas komplett. Ju bättre prosan, desto viktigare är härkomsten. Förtroende ska inte tillåtas tvätta en svag källkedja.
Bra källförberedelse minskar också promptens komplexitet. En prompt full av varningar om motstridiga policyer, föråldrade dokument, saknade fält och särskilda undantag är ofta ett symptom på försummelse i tidigare led. Om hämtningslagret redan filtrerar på auktoritet och färskhet kan prompten vara kortare. Om källan bär strukturerad metadata behöver modellen inte sluta sig till den från styckesrubriker. Om undantag representeras som regler behöver modellen inte bli en detektiv med tokenbegränsningar. Den bästa promptförbättringen är ibland ett bättre index.
Exempel är små stycken av styrning
Exempel behandlas oftast som träningshjälpmedel, men de är också styrning. Ett bra exempel visar vad kvalitet innebär i en viss situation. Det visar hur organisationen hanterar osäkerhet, saknad bevisning, motstridiga riktlinjer, känsligt tonläge, eskalering och avvisanden. Det lär modellen och teamet hur ett bra svar ser ut, men också hur ett bra icke-svar ser ut. Detta är viktigt eftersom många allvarliga system misslyckas genom att svara när de borde pausa.
Att bygga exempel tvingar fram beslut som abstrakta diskussioner undviker. Ta tjugo verkliga fall. Markera det korrekta utfallet. Markera godtagbara alternativ. Markera oacceptabla genvägar. Förklara varför. Inkludera gränsfall som fick erfarna medarbetare att tveka. Inkludera även vanliga fall, eftersom system som bara tränas på dramatik lär sig dåligt uppförande. Be domänexperter att vara oense och dokumentera oenigheten. Detta är långsammare än att be modellen vara försiktig. Det skapar också ett gemensamt språk för försiktighet.
Exempel bör inkludera negativa fall. Ingen källa hittad. Källkonflikt. Användaren saknar behörighet. Begäran utanför syftet. Kunden frågar efter något som låter enkelt men som utlöser policy. Modellen bör lära sig när den ska avvisa, eskalera, fråga eller returnera strukturerad osäkerhet. Om exempel bara visar framgångsrika svar kommer prompten att luta mot fullföljande. Fullföljande är inte alltid framgång. Ibland är det bästa svaret otillräcklig bevisning, vilket är svårt att fira i en demo men användbart i ett fungerande system.
Exempel är också början på utvärdering. De kan bli testfixturer, regressionsfall, utbildningsmaterial för granskare och övervakningsprover. När en incident inträffar kan ett korrigerat fall bli ett nytt exempel. Detta ger systemet minne. Utan exempel blir promptändringar humörändringar. Någon säger att svaret känns bättre. Någon annan säger att det känns sämre. Modellen ler i mitten, oberörd av bevisning.
Utformningen av utdata är ett operativt beslut
Promptdiskussioner lägger ofta för mycket tid på ton och för lite på utformningen av utdata. Ton spelar roll, särskilt i kund- eller offentlig kommunikation. Men utformningen av utdata avgör om svaret kan kontrolleras, dirigeras, lagras, godkännas, ifrågasättas eller användas av ett annat system. Ett stycke kan vara trevligt. En strukturerad utdata kan vara operativ. Seriöst AI-arbete behöver ofta både och: läsbar prosa för människor och fält som maskiner kan verifiera.
Utdataformatet omfattar obligatoriska fält, källhänvisningar, konfidens eller osäkerhet, skäl till avslag, eskaleringsflaggor, berörda poster, föreslagna åtgärder och status för mänskligt godkännande. Det anger om modellen får lämna ett fält tomt. Det anger om den måste citera en policyidentifierare. Det anger om den får hitta på kategorier eller måste välja från en kontrollerad lista. Det anger vad som händer när indata är tvetydig. Dessa val är inte bara promptkosmetika. De är arbetsflödesdesign.
Strukturerad utdata håller också modellen inom dess ansvarsområde. Om systemet kräver ett separat fält för bevis blir ogrundade påståenden synliga. Om det kräver en åtgärdstyp från en tillåten lista blir kreativ verktygsanvändning svårare. Om det kräver att osäkerhet görs explicit kan granskare prioritera. Om det kräver ett skäl till avslag kan blockerade fall analyseras. Prompten kan begära dessa saker, men det omgivande systemet bör validera dem. Att fråga snällt är inte en kontroll. Det är ett förslag med formatering.
Det finns en mänsklig sida. Människor behöver utdata som matchar deras arbetsrytm. En jurist kan behöva källklausuler och riskanteckningar. En supportagent kan behöva ett kundfärdigt utkast plus interna orsakskoder. En planerare kan behöva en ruttrekommendation och det villkor som drev den. En chef kan behöva aggregerade skäl, inte individuell prosa. Om utdataformatet ignorerar användaren kan prompten vara tekniskt korrekt och operativt irriterande. Det är en vanlig prestation, men inte en användbar sådan.
Auktoritet kan inte antydas genom hjälpsamhet
En hjälpsam modell inbjuder till förtroende. Det är bra tills hjälpsamhet misstas för auktoritet. Om modellen utformar ett svar, vem får skicka det. Om den rekommenderar en återbetalning, vem får godkänna den. Om den klassificerar risk, vem får agera på klassificeringen. Om den extraherar ett fält, vem korrigerar det. Om den inte kan hitta bevis, vem beslutar om man ska gå vidare. Dessa frågor måste besvaras före prompten, eftersom prompten inte kan bevilja institutionell auktoritet.
Auktoritetsdesign omfattar roller, trösklar, granskningsköer, överprövningsrätter, eskaleringsvägar och revisionsspår. Den skiljer förslag från beslut. Den skiljer automatiserade beslut från mänskliga beslut som stöds av automatisering. Den anger när en människa måste se källmaterial snarare än bara modellens prosa. Den anger när ett verktygsanrop är tillåtet och när det är blockerat. Den anger vem som äger skada, försening, korrigering och kommunikation. Modellen kan hjälpa inom den designen. Den bör inte vara designen.
Detta är särskilt viktigt när AI läggs till befintliga arbetsflöden. Befintlig auktoritet kan vara informell. En senior person godkänner undantag eftersom alla vet att man ska fråga henne. En teamledare tolkar policy eftersom hon har sett gränsfallen. Ett kalkylblad bär en tillfällig regel eftersom systemet inte kan. När AI kommer in blir informell auktoritet skör. Modellen kan skala upp den gamla tvetydigheten snabbare än människor hinner fånga den. Arbetet före prompten är att göra auktoriteten tillräckligt explicit så att skalning inte bara skalar förvirring.
Det är värt att säga att auktoritet inte är hastighetens fiende. Tydlig auktoritet gör ofta arbetet snabbare eftersom människor vet vad som kan gå vidare utan debatt, vad som måste pausas och vem som kan besluta. Vag auktoritet känns flexibel tills den möter volym. Då blir varje svårt fall en liten konstitutionell kris, med chattrådar som prejudikat. Detta är inte ett rekommenderat rättssystem.
Utvärdering är inte en vibekoll
Många prompt-iterationer bedöms efter känsla. Den här versionen låter bättre. Den där är mer koncis. Den här är mindre befallande. Sådana bedömningar kan vara användbara, men de räcker inte. AI-verksamhet behöver utvärdering som följer uppgiften. Använde modellen rätt källa. Missade den obligatoriska fält. Vägrade den när bevis saknades. Eskalerade den högriskärenden. Bevarade den policyidentifierare. Åsidosatte människor den. Ställde kunderna färre följdfrågor. Såg nedströms team mindre omarbetning.
Utvärdering bör omfatta vanliga fall, gränsfall, motståndarfall, inaktuella källor, saknade data, motstridig policy och exempel på acceptabel vägran. Den bör vara repeterbar. Den bör skilja modellfel från källfel, promptfel, gränssnittsfel och processfel. Annars blir varje problem ett promptproblem, eftersom prompten är den del som alla kan se. Den synliga delen är inte alltid den skyldiga delen. Detta gäller i mjukvara och i möten.
Utvärdering avgör också när man ska sluta. Utan en testuppsättning och releasekriterier kan promptarbete fortsätta i all evighet, eftersom språk alltid kan förbättras. Det kommer alltid att finnas ytterligare ett adjektiv, ytterligare en instruktion, ytterligare ett exempel, ytterligare en formateringsjustering. Frågan är inte om prompten är perfekt. Frågan är om systemet utför uppgiften inom överenskomna gränser för risk, kostnad och kvalitet. Perfektion är en dålig releaseledare. Den bär ingen personsökare.
Arbetet efter prompten börjar före releasen
Korrigeringsvägar bör utformas innan den första produktionsanvändaren rapporterar ett problem. Hur flaggar en användare ett felaktigt svar. Vart går den flaggan. Vem granskar den. Ändras källan. Ändras exempelbanken. Ändras prompten. Ändras en regel. Ändras ett tröskelvärde. Får en människa feedback. Blir det korrigerade fallet ett regressionstest. Om korrigering inte är utformad blir feedback en hög. Högar är där lärande går för att ta en lång tupplur.
Övervakning bör också beslutas före releasen. Spåra inte bara latens och kostnad, utan även vägransfrekvenser, frekvenser för saknade källor, skäl till åsidosättanden, eskaleringsbelastning, nedströms omarbetning, klagomålsteman, inaktuella citat och drift i uppgiftsmix. Modellens svarskvalitet är bara en del av operativ kvalitet. Ett system kan svara väl och ändå dirigera för mycket arbete till människor. Det kan svara snabbt och ändå öka korrigeringarna. Det kan minska ärenden och ändå skapa svårare ärenden. Övervakning bör se arbete, inte bara tokens.
Arbetet före prompten tar egentligen aldrig slut. Nya policyer tillkommer. Källsystem förändras. Användare hittar genvägar. Modellen förändras. Verksamheten förändras. En prompt som fungerade i maj kan vara fel i september eftersom arbetet har flyttat sig under den. Det betyder inte att allt är skört. Det betyder att AI-drift behöver ägarskap. Någon måste underhålla uppgiftsdefinition, källor, exempel, utvärdering, befogenhet och reparation. Annars blir prompten en fossil med utmärkt grammatik.
Läxan
Det verkliga arbetet ligger före prompten, för promptandet är den synliga kanten av ett större operativsystem. Modellen behöver en uppgift den kan utföra, källor den kan lita på, gränser den inte får överskrida, utdata som kan kontrolleras, exempel som kodar in omdöme, befogenhet som talar om för människor och verktyg vad de får göra, och utvärdering som kan skilja förbättring från snyggare prosa. Utan det bär prompten på ansvar den inte kan fullgöra.
Den här synen förminskar inte promptandet. Den gör promptandet mer värdefullt. En prompt i en förberedd drift kan vara kort, tydlig, testbar och underhållbar. Den kan fokusera modellen i stället för att kompensera för otydlighet. Den kan utvecklas med exempel och belägg. Den kan ändras med tillförsikt eftersom teamet vet vad som är bra. Det är bättre än promptmystik, som mest producerar längre prompts och tystare tvivel.
Innan du frågar hur du ska prompta modellen, fråga vilket arbete organisationen redan har gjort för modellen. Är uppgiften namngiven. Är källorna auktoritativa. Är exempel markerade. Är utdata strukturerad. Är befogenheten uttrycklig. Är fel säkra. Är utvärderingen verklig. Är reparationen designad. Om svaren är svaga, börja där. Den mest användbara prompten i rummet kan vara den som får alla att erkänna att prompten inte är där arbetet börjar.