Det egentlige arbejde venter foran prompten
Promptworkshoppen, der startede for sent
Workshoppen var booket til at forbedre prompts. Det var titlen i kalenderen med et muntert lille tryllestavsikon, som nogen fortrød senere. En gruppe ledere, analytikere, operatører og ingeniører sad omkring et bord med et fælles dokument. Den aktuelle prompt var på skærmen. Den bad en sprogmodel om at gennemgå kundeforespørgsler, identificere den rigtige politik, udkast til et svar og markere risiko. Den var høflig, struktureret og meget længere, end nogen ville indrømme. Den var heller ikke hovedproblemet.
Det første testtilfælde var en kunde, der bad om en undtagelse efter en forsinket levering. Modellen producerede et anstændigt svar. Så sagde en fra operations, at kildepolitikken på skærmen ikke længere var den, teamet brugte om fredagen, fordi en midlertidig transportørregel var blevet forlænget to gange, men aldrig flettet ind i hovedpolitiksiden. En fra legal sagde, at undtagelser over et bestemt beløb krævede godkendelse, men at tærsklen afhang af produktkategori. Finance spurgte, hvor goodwill-kreditter blev registreret. Support sagde, at modellens tone var fin, men at kunden ville ringe igen, fordi svaret ikke nævnte den manglende sporingshændelse. Promptsad der og så uskyldig ud.
Ingen af disse problemer ville blive løst af et bedre instruktionsafsnit. Modellen kunne ikke udlede, hvilken politiksides der var autoritativ. Den kunne ikke vide, at en midlertidig regel var blevet operationel virkelighed. Den kunne ikke beslutte, hvem der havde godkendelsesautoritet. Den kunne ikke se, at den manglende sporingshændelse var den egentlige årsag til den næste kontakt. Prompts blev bedt om at kompensere for uklart arbejde. Dette er en almindelig fejl. Folk møder op til prompten med en kurv af procesuklarhed og beder modellen om at være elegant omkring det.
Det rigtige arbejde er før prompten. Det er arbejdet med at navngive opgaven, definere grænsen, vælge kilder, fastlægge autoritet, forberede eksempler, beslutte fejlveje, forme output, måle kvalitet og gøre korrektion mulig. Prompting betyder noget. En dårlig prompt kan gøre et godt setup klodset. Men en smuk prompt oven på en uklar operation er bare velformuleret forvirring. Modellen lyder måske bedre. Arbejdet bliver ikke sikrere, billigere eller mere forståeligt ved et tilfælde.
En prompt er ikke et proceskort
En prompt kan fortælle en model, hvordan den skal opføre sig i en kontekst. Den kan ikke skabe konteksten, hvis organisationen ikke har gjort det. Den kan bede om kortfattethed, struktur, ydmyghed og kildehenvisninger. Den kan beskrive en rolle. Den kan specificere et format. Den kan advare modellen mod at gætte. Det er nyttigt. Men det er også småt i forhold til de procesmæssige spørgsmål, der afgør, om et AI-system hjælper eller blot taler selvsikkert i nærheden af arbejdet.
Hvad er opgaven. Er det klassificering, ekstraktion, opsummering, udkast, routing, anbefaling, verifikation eller handling. Hvilken del er automatiseret. Hvilken del forbliver menneskelig. Hvilken tilstand ændres, hvis outputtet accepteres. Hvem er berørt. Hvilke registreringer berøres. Hvilken politik gælder. Hvilke beviser er obligatoriske. Hvad sker der, når beviser mangler. Hvilke fejl er tolerable. Hvilke fejl skaber skade. Disse spørgsmål afgør systemets form. En prompt, der ikke hviler på klare svar, bliver en høflig gæt med et navneskilt.
Mange fejlslagne AI-pilotprojekter begynder med en prompt, fordi prompten er det mest synlige håndtag. Det føles kreativt og umiddelbart. Du kan redigere den på et møde. Du kan prøve en ny version, før kaffen bliver kold. Procesdesign er langsommere. Datarensning er langsommere. Autoritetskortlægning er langsommere. Opbygning af evalueringssæt er langsommere. Desværre er langsom ikke det samme som valgfri. De dele, der springes over før prompten, vender senere tilbage som hallucination, omarbejdning, mistillid, politikundtagelser og et stort regneark kaldet issues.
Den bedre rækkefølge er ikke glamourøs. Skriv arbejdet ned. Gennemgå rigtige sager. Identificer kildesystemer. Marker, hvilke felter der afgør resultater. Adskil regler fra vurdering. Beslut, hvor mennesker træder ind. Definér outputkontrakter. Byg eksempler. Bliv enige om afvisning. Test med de mennesker, der skal leve med resultatet. Først derefter bliver prompten en nyttig løftestang. Før det er den et dekorativt rat på et skrivebord.
Opgaven har brug for en grænse skarp nok til at teste
AI-arbejde begynder ofte med verber, der er for store. Hjælp med kundeservice. Understøt juridisk gennemgang. Forbedr planlægning. Assister indkøb. Gør rapportering smartere. Det er ambitioner, ikke opgaver. En model kan ikke evalueres mod en ambition. Den kan evalueres mod en opgave med input, output, begrænsninger, succes-kriterier og fejlveje. Den smallere beskrivelse føles måske mindre spændende. Det er også det første øjeblik, hvor arbejdet bliver bygbart.
En skarp opgavegrænse siger, hvad systemet må se, og hvad det må ændre. Den siger, om modellen læser kildemateriale, genererer et udkast, ekstraherer strukturerede felter, anbefaler en handling eller kalder et værktøj. Den siger, hvilke output der er endelige, hvilke der er rådgivende, og hvilke der skal gennemgås. Den siger, hvad systemet afviser. Den siger, hvornår modellen skal bede om flere beviser i stedet for at færdiggøre svaret. Den siger, hvad der er uden for scope, fordi uden for scope er, hvor ambitiøse pilotprojekter bliver til hændelsesrapporter.
Grænser gør evaluering mulig. Hvis opgaven er at udarbejde et svar ved hjælp af disse kilder og denne politik, kan kvalitet testes. Hvis opgaven er at forbedre servicekvaliteten med AI, kan ethvert resultat forklares som fremskridt af en person med nok slides. En grænse beskytter også brugere mod utilsigtet eskalering. Et værktøj, der begynder med at udarbejde udkast, kan få en knap, der sender. En klassificerer kan blive en router. En router kan blive en beslutning. Uden en navngiven grænse føles denne drift som adoption. Med en grænse bliver den en ændringsanmodning.
Grænsen skal beskrives i operationelt sprog, ikke kun teknisk sprog. Supportlederen skal kunne forstå den. Juridisk skal kunne forstå den. Dataejeren skal kunne forstå den. Ingeniøren skal kunne teste den. Hvis prompten er det eneste sted, hvor grænsen lever, er grænsen skrøbelig. Prompter er vigtige, men de er ikke bærende politikdokumenter. De minder mere om instruktioner til en meget dygtig midlertidig medarbejder, der aldrig har set organisationsdiagrammet.
Kilder er ikke en bunke dokumenter
Mange teams opdager under promptarbejdet, at de ikke ved, hvilke kilder der er autoritative. De har politikker, PDF'er, mailinstruktioner, træningsmateriale, gamle manualer, chatbeskeder, ticket-makroer, regneark og hukommelsen hos en operatør, som alle ringer til, fordi hun ved, hvordan det faktisk fungerer. Modellen bliver så bedt om at svare ud fra vidensbasen. Hvilken viden. Hvilken base. Udtrykket kan skjule en hel del.
Kildeforberedelse er ikke glamourøst, og derfor er den ofte forsinket. Det handler om at beslutte, hvilket dokument der vinder, når kilder er uenige, hvordan friskhed kontrolleres, hvordan midlertidige regler udløber, hvordan undtagelser repræsenteres, hvordan fortroligt materiale udelukkes, hvordan kildeversioner bevares, og hvordan citeringsidentifikatorer overlever modellens svar. Dette er ikke papirarbejde. Det er forskellen mellem at hente og at rode rundt.
AI gør kildedisciplin vigtigere, fordi modellen kan få svag kildehåndtering til at se acceptabel ud. Den kan sy fragmenter sammen til flydende prosa. Den kan glatte modsigelser ud. Den kan producere et plausibelt svar fra forældet materiale. Et søgeresultat med synlige huller føles ufuldstændigt. Et genereret svar med de samme huller kan føles komplet. Jo bedre prosæn, desto vigtigere er oprindelsen. Selvtillid skal ikke kunne hvidvaske en svag kæde af kilder.
God kildeforberedelse reducerer også promptens kompleksitet. En prompt fuld af advarsler om modstridende politikker, forældede dokumenter, manglende felter og særlige undtagelser er ofte et symptom på forsømmelse længere oppe i systemet. Hvis hentningslaget allerede filtrerer efter autoritet og friskhed, kan prompten være kortere. Hvis kilden bærer struktureret metadata, behøver modellen ikke at udlede det fra afsnitsoverskrifter. Hvis undtagelser er repræsenteret som regler, behøver modellen ikke at blive en detektiv med token-grænser. Den bedste promptforbedring er nogle gange et bedre indeks.
Eksempler er små stykker styring
Eksempler behandles normalt som træningshjælp, men de er også styring. Et godt eksempel siger, hvad kvalitet betyder i en given situation. Det viser, hvordan organisationen håndterer usikkerhed, manglende dokumentation, modstridende politikker, følsom tone, eskalering og afvisning. Det fortæller modellen og teamet, hvordan et godt svar ser ud, men også hvordan et godt ikke-svar ser ud. Det betyder noget, fordi mange alvorlige systemer fejler ved at svare, når de burde holde inde.
At opbygge eksempler tvinger beslutninger frem, som abstrakt diskussion undgår. Tag tyve virkelige sager. Markér det korrekte resultat. Markér acceptable alternativer. Markér uacceptable genveje. Forklar hvorfor. Inkluder grænsetilfælde, der fik erfarne medarbejdere til at tøve. Inkluder også almindelige tilfælde, fordi systemer, der kun trænes på drama, lærer dårlige manerer. Bed domæneeksperter om at være uenige, og registrer uenigheden. Det er langsommere end at bede modellen om at være forsigtig. Det skaber også et fælles sprog for forsigtighed.
Eksempler bør inkludere negative tilfælde. Ingen kilde fundet. Kildekonflikt. Brugeren mangler autorisation. Forespørgsel uden for formålet. Kunden beder om noget, der lyder simpelt, men udløser en politik. Modellen skal lære, hvornår den skal afvise, eskalere, spørge eller returnere struktureret usikkerhed. Hvis eksempler kun viser succesfulde svar, vil prompten hælde mod fuldførelse. Fuldførelse er ikke altid succes. Nogle gange er det bedste svar ikke tilstrækkelig dokumentation, hvilket er svært at fejre i en demo, men nyttigt i et fungerende system.
Eksempler er også begyndelsen på evaluering. De kan blive testfiksturer, regressionstilfælde, træning af reviewere og overvågningsprøver. Når en hændelse sker, kan en korrigeret sag blive et nyt eksempel. Det giver systemet hukommelse. Uden eksempler bliver promptændringer til stemningsændringer. Nogen siger, at svaret føles bedre. En anden siger, at det føles værre. Modellen smiler midt i det hele, upåvirket af dokumentation.
Outputform er en operationel beslutning
Promptdiskussioner bruger ofte for meget tid på tone og for lidt på outputform. Tone betyder noget, især i kunde- eller offentlig kommunikation. Men outputformen afgør, om svaret kan kontrolleres, dirigeres, gemmes, godkendes, udfordres eller bruges af et andet system. Et afsnit kan være behageligt. En struktureret output kan være operationel. Seriøst AI-arbejde kræver ofte begge dele: læsbar prosa til mennesker og felter, som maskiner kan verificere.
Outputformens omfang omfatter obligatoriske felter, kildehenvisninger, sikkerhed eller usikkerhed, begrundelser for afslag, eskaleringsflag, berørte poster, foreslåede handlinger og status for menneskelig godkendelse. Den angiver, om modellen må lade et felt stå tomt. Den angiver, om modellen skal citere en politikidentifikator. Den angiver, om modellen må opfinde kategorier eller skal vælge fra en kontrolleret liste. Den angiver, hvad der sker, når inputtet er tvetydigt. Disse valg er ikke blot kosmetiske detaljer i prompten. De er design af arbejdsgangen.
Struktureret output holder også modellen på sporet. Hvis systemet kræver et separat felt til dokumentation, bliver ubegrundede påstande synlige. Hvis det kræver en handlingstype fra en tilladt liste, bliver kreativ brug af værktøjer sværere. Hvis det kræver, at usikkerhed gøres eksplicit, kan reviewere prioritere. Hvis det kræver en begrundelse for afslag, kan blokerede sager analyseres. Prompts kan anmode om disse ting, men det omkringliggende system bør validere dem. At spørge pænt er ikke en kontrol. Det er en anmodning med formatering.
Der er en menneskelig side. Folk har brug for output, der matcher deres arbejdsrytme. En jurist kan have brug for kildeklausuler og risikonotater. En supportmedarbejder kan have brug for et kundeklart udkast plus interne årsagskoder. En planlægger kan have brug for en ruteanbefaling og den begrænsning, der drev den. En leder kan have brug for samlede årsager, ikke individuel prosa. Hvis outputformen ignorerer brugeren, kan prompten være teknisk korrekt og operationelt irriterende. Det er en almindelig præstation, men ikke en nyttig en.
Autoritet kan ikke antages ud fra hjælpsomhed
En hjælpsom model inviterer til tillid. Det er godt, indtil hjælpsomhed forveksles med autoritet. Hvis modellen udarbejder et svar, hvem må så sende det. Hvis den anbefaler en refusion, hvem må så godkende den. Hvis den klassificerer risiko, hvem må så handle på klassificeringen. Hvis den udtrækker et felt, hvem retter så det. Hvis den ikke kan finde dokumentation, hvem beslutter så, om man skal fortsætte. Disse spørgsmål skal besvares før prompten, fordi prompten ikke kan tildele institutionel autoritet.
Autoritetsdesign omfatter roller, tærskler, reviewkøer, ret til at tilsidesætte, eskaleringsveje og revisionsspor. Det adskiller forslag fra beslutning. Det adskiller automatiseret beslutning fra menneskelig beslutning understøttet af automatisering. Det angiver, hvornår et menneske skal se kildemateriale frem for kun modelprosa. Det angiver, hvornår et værktøjskald er tilladt, og hvornår det er blokeret. Det angiver, hvem der ejer skade, forsinkelse, korrektion og kommunikation. Modellen kan hjælpe inden for det design. Den bør ikke være designet.
Dette er især vigtigt, når AI tilføjes til eksisterende arbejdsgange. Eksisterende autoritet kan være uformel. En seniorperson godkender undtagelser, fordi alle ved, at man skal spørge vedkommende. En teamleder fortolker politik, fordi vedkommende har set grænsetilfældene. Et regneark bærer en midlertidig regel, fordi systemet ikke kan. Når AI kommer ind, bliver uformel autoritet skrøbelig. Modellen kan skalere den gamle tvetydighed hurtigere, end folk kan fange den. Arbejdet før prompten er at gøre autoriteten eksplicit nok, så skalering ikke blot skalerer forvirring.
Det er værd at sige, at autoritet ikke er fjende af hastighed. Klar autoritet gør ofte arbejdet hurtigere, fordi folk ved, hvad der kan bevæge sig uden debat, hvad der skal pause, og hvem der kan beslutte. Vagt autoritet føles fleksibel, indtil den møder volumen. Så bliver hvert vanskeligt tilfælde en lille forfatningskrise, med chat-tråde som retspraksis. Dette er ikke et anbefalet retssystem.
Evaluering er ikke en stemningsmåling
Mange prompt-iterationer vurderes på fornemmelsen. Denne version lyder bedre. Den version er mere kortfattet. Den her er mindre kommanderende. De vurderinger kan være nyttige, men de er ikke nok. AI-operationer har brug for evaluering, der følger opgaven. Brugte modellen den rigtige kilde. Missede den obligatoriske felter. Afviste den, når der manglede beviser. Eskalerede den højrisiko-sager. Bevarede den politik-identifikatorer. Overskrev mennesker den. Stillede kunderne færre opfølgningsspørgsmål. Så downstream-teams mindre rework.
Evaluering bør omfatte almindelige tilfælde, kanttilfælde, modstander-tilfælde, forældede kilder, manglende data, modstridende politik og eksempler på acceptabel afvisning. Den skal kunne gentages. Den skal adskille modelfejl fra kildefejl, promptfejl, grænsefladefejl og procesfejl. Ellers bliver ethvert problem et promptproblem, fordi prompten er den del, alle kan se. Den synlige del er ikke altid den skyldige del. Det gælder i software og i møder.
Evaluering afgør også, hvornår man skal stoppe. Uden et testsæt og release-kriterier kan prompt-arbejde fortsætte uendeligt, fordi sprog altid kan forbedres. Der vil altid være et adjektiv mere, en instruktion mere, et eksempel mere, en formateringsjustering mere. Spørgsmålet er ikke, om prompten er perfekt. Spørgsmålet er, om systemet udfører opgaven inden for aftalte risici, omkostninger og kvalitetsgrænser. Perfektion er en dårlig release-manager. Den har ikke en pager med sig.
Arbejdet efter prompten starter før release
Korrektionsstier bør designes, før den første produktionsbruger rapporterer et problem. Hvordan markerer en bruger et forkert svar. Hvor går den markering hen. Hvem gennemgår den. Ændrer kilden sig. Ændrer eksempelbanken sig. Ændrer prompten sig. Ændrer en regel sig. Ændrer en tærskel sig. Modtager et menneske feedback. Bliver det korrigerede tilfælde en regressionstest. Hvis korrektion ikke er designet, bliver feedback en bunke. Bunker er, hvor læring tager sig en lang lur.
Overvågning bør også besluttes før release. Spor ikke kun latenstid og omkostninger, men også afvisningsrater, kildemangelfrekvenser, årsager til overskrivelser, eskalationsbelastning, downstream-rework, klagetemaer, forældede citater og ændringer i opgaveblandingen. Modellens svarkvalitet er kun en del af den operationelle kvalitet. Et system kan svare godt og stadig dirigere for meget arbejde til mennesker. Det kan svare hurtigt og stadig øge antallet af korrektioner. Det kan reducere billetter og stadig skabe sværere billetter. Overvågning bør se arbejde, ikke kun tokens.
Arbejdet før prompten slutter aldrig rigtigt. Nye politikker dukker op. Kildesystemer ændrer sig. Brugere finder genveje. Modellen ændrer sig. Virksomheden ændrer sig. En prompt, der virkede i maj, kan være forkert i september, fordi arbejdet har flyttet sig under den. Det betyder ikke, at alt er skrøbeligt. Det betyder, at AI-drift har brug for ejerskab. Nogen skal vedligeholde opgavedefinition, kilder, eksempler, evaluering, autoritet og reparation. Ellers bliver prompten en fossil med fremragende grammatik.
Lærdommen
Det egentlige arbejde ligger før prompten, fordi prompting er den synlige kant af et større operativsystem. Modellen har brug for en opgave, den kan udføre, kilder, den kan stole på, grænser, den ikke kan overskride, output, der kan kontrolleres, eksempler, der indkoder dømmekraft, autoritet, der fortæller mennesker og værktøjer, hvad de må, og evaluering, der kan skelne forbedring fra pænere prosa. Uden det bærer prompten ansvar, den ikke kan opfylde.
Denne opfattelse formindsker ikke prompting. Den gør prompting mere værdifuld. En prompt i en forberedt drift kan være kort, klar, testbar og vedligeholdelsesvenlig. Den kan fokusere modellen i stedet for at kompensere for tvetydighed. Den kan udvikle sig med eksempler og dokumentation. Den kan ændres med tillid, fordi teamet ved, hvad godt betyder. Det er bedre end promptmystik, som mest producerer længere prompter og mere stille tvivl.
Før du spørger, hvordan du prompte modellen, så spørg, hvilket arbejde organisationen allerede har gjort for modellen. Er opgaven navngivet. Er kilder autoritative. Er eksempler markeret. Er output struktureret. Er autoritet eksplicit. Er fejl sikkert. Er evaluering reel. Er reparation designet. Hvis svarene er svage, så start der. Den mest nyttige prompt i rummet kan være den, der får alle til at indrømme, at prompten ikke er der, hvor arbejdet begynder.