Tikrasis darbas prasideda po raginimo.
Seminaras apie užklausas, prasidėjęs per vėlai
Seminaras buvo užsakytas siekiant pagerinti užklausas. Taip buvo pavadinta kalendoriuje, su linksma maža lazdelės piktograma, kurios kažkas vėliau gailėjosi. Grupė vadovų, analitikų, operatorių ir inžinierių sėdėjo prie stalo su bendru dokumentu. Dabartinė užklausa buvo ekrane. Ji prašė kalbos modelio peržiūrėti klientų prašymus, nustatyti tinkamą politiką, parengti atsakymą ir pažymėti riziką. Ji buvo mandagi, struktūruota ir daug ilgesnė, nei kas nors norėjo pripažinti. Ji taip pat nebuvo pagrindinė problema.
Pirmasis bandomasis atvejis buvo klientas, prašantis išimties po pavėluoto pristatymo. Modelis pateikė tinkamą atsakymą. Tada kažkas iš operacijų skyriaus pasakė, kad ekrane rodoma politikos versija nebėra ta, kurią komanda naudoja penktadieniais, nes laikina vežėjo taisyklė buvo pratęsta du kartus, bet niekada nebuvo įtraukta į pagrindinį politikos puslapį. Kažkas iš teisės skyriaus pasakė, kad išimtims, viršijančioms tam tikrą sumą, reikia patvirtinimo, tačiau riba priklausė nuo produkto kategorijos. Finansų skyrius paklausė, kur registruojami geros valios kreditai. Palaikymo skyrius pasakė, kad modelio tonas buvo tinkamas, bet klientas paskambins dar kartą, nes atsakyme nebuvo paminėtas trūkstamas sekimo įvykis. Užklausa sėdėjo ir atrodė nekaltai.
Nė viena iš šių problemų nebūtų išspręsta geresne instrukcijų pastraipa. Modelis negalėjo nustatyti, kuris politikos puslapis yra autoritetingas. Jis negalėjo žinoti, kad laikina taisyklė tapo veiklos realybe. Jis negalėjo nuspręsti, kas turi patvirtinimo įgaliojimus. Jis negalėjo matyti, kad trūkstamas sekimo įvykis yra tikroji kito kontakto priežastis. Užklausa buvo prašoma kompensuoti neaiškų darbą. Tai dažna klaida. Žmonės ateina prie užklausos su krepšiu procesų neaiškumų ir prašo modelio būti elegantiškam dėl to.
Tikrasis darbas yra prieš užklausą. Tai darbas, apimantis užduoties įvardijimą, ribų apibrėžimą, šaltinių parinkimą, autoriteto nustatymą, pavyzdžių parengimą, nesėkmės kelių nustatymą, rezultato formavimą, kokybės matavimą ir korekcijos galimybės užtikrinimą. Užklausų rengimas yra svarbus. Bloga užklausa gali padaryti gerą sąranką nepatogią. Tačiau graži užklausa ant neaiškios operacijos yra tik gerai parašyta painiava. Modelis gali skambėti geriau. Darbas nebus saugesnis, pigesnis ar suprantamesnis atsitiktinai.
Užklausa nėra proceso žemėlapis
Promptas gali pasakyti modeliui, kaip elgtis tam tikrame kontekste. Jis negali sukurti konteksto, jei organizacija to nepadarė. Jis gali prašyti trumpumo, struktūros, kuklumo ir citatų. Jis gali apibūdinti vaidmenį. Jis gali nurodyti formatą. Jis gali įspėti modelį nespėlioti. Visa tai naudinga. Tačiau tai menka, palyginti su proceso klausimais, kurie lemia, ar dirbtinio intelekto sistema tikrai padeda, ar tik užtikrintai kalba šalia darbo.
Kokia yra užduotis. Ar tai klasifikavimas, ištraukimas, apibendrinimas, juodraščio rengimas, nukreipimas, rekomendavimas, tikrinimas ar veiksmas. Kuri dalis yra automatizuota. Kuri dalis lieka žmogaus rankose. Kokie būsenos pokyčiai įvyksta, jei rezultatas priimamas. Kam tai daro įtaką. Kokie įrašai yra paliečiami. Kokia politika taikoma. Kokie įrodymai yra privalomi. Kas atsitinka, kai įrodymų trūksta. Kurios klaidos yra toleruotinos. Kurios klaidos sukelia žalą. Šie klausimai nulemia sistemos formą. Promptas, kuris nėra pagrįstas aiškiais atsakymais, tampa mandagiu spėjimu su vardinuke.
Daugelis nepavykusių DI pilotinių projektų prasideda nuo prompto, nes promptas yra labiausiai matoma valdymo priemonė. Jis atrodo kūrybiškas ir greitas. Gali jį redaguoti per susitikimą. Gali išbandyti naują versiją, kol kava dar neatšalo. Proceso kūrimas yra lėtesnis. Duomenų valymas yra lėtesnis. Atsakomybių žemėlapio sudarymas yra lėtesnis. Vertinimo rinkinių kūrimas yra lėtesnis. Deja, lėtas nereiškia neprivalomas. Dalys, kurias praleidote prieš promptą, vėliau sugrįžta kaip haliucinacijos, perdarymas, nepasitikėjimas, politikos išimtys ir didelė skaičiuoklė, pavadinta problemomis.
Geresnė seka nėra įspūdinga. Užrašykite darbą. Peržiūrėkite realius atvejus. Nustatykite šaltinio sistemas. Pažymėkite, kurie laukai lemia rezultatus. Atskirkite taisykles nuo sprendimų. Nuspręskite, kur įsitraukia žmonės. Apibrėžkite rezultatų sutartis. Sukurkite pavyzdžius. Susitarkite dėl atsisakymo. Išbandykite su žmonėmis, kurie gyvens su rezultatu. Tik tada promptas tampa naudinga svirtimi. Iki tol jis yra dekoratyvinis vairas ant stalo.
Užduočiai reikia pakankamai aiškios ribos, kad ją būtų galima išbandyti
DI darbas dažnai prasideda nuo per plačių veiksmažodžių. Padėti klientų aptarnavimui. Paremti teisinę peržiūrą. Pagerinti planavimą. Padėti pirkimams. Padaryti ataskaitas protingesnes. Tai ambicijos, o ne užduotys. Modelio negalima vertinti pagal ambiciją. Jį galima vertinti pagal užduotį su įvestimis, išvestimis, apribojimais, sėkmės kriterijais ir nesėkmės keliais. Siauresnis apibūdinimas gali atrodyti mažiau įdomus. Tačiau tai pirmas momentas, kai darbas tampa įgyvendinamas.
Aiški užduoties riba nurodo, ką sistema gali matyti ir ką gali keisti. Ji nurodo, ar modelis skaito šaltinio medžiagą, rengia juodraštį, ištraukia struktūruotus laukus, rekomenduoja veiksmą ar kviečia įrankį. Ji nurodo, kurios išvestys yra galutinės, kurios patariamosios, o kurios turi būti peržiūrėtos. Ji nurodo, ko sistema atsisako. Ji nurodo, kada modelis turėtų prašyti daugiau įrodymų, o ne užbaigti atsakymą. Ji nurodo, kas yra už taikymo srities ribų, nes už ribų yra vieta, kur ambicingi pilotiniai projektai tampa incidentų ataskaitomis.
Ribos įgalina vertinimą. Jei užduotis yra parengti atsakymą naudojant šiuos šaltinius ir šią politiką, kokybę galima išbandyti. Jei užduotis yra pagerinti paslaugų kokybę naudojant DI, kiekvienas rezultatas gali būti paaiškintas kaip pažanga, jei kas nors turi pakankamai skaidrių. Riba taip pat apsaugo vartotojus nuo netyčinio eskalavimo. Įrankis, kuris pradeda nuo juodraščio rengimo, gali įgyti mygtuką, kuris siunčia. Klasifikatorius gali tapti maršrutizatoriumi. Maršrutizatorius gali tapti sprendimu. Be įvardytos ribos šis pokytis atrodo kaip pritaikymas. Su riba jis tampa pakeitimo prašymu.
The boundary should be written in operational language, not only technical language. The support lead should understand it. Legal should understand it. The data owner should understand it. The engineer should be able to test it. If the prompt is the only place where the boundary lives, the boundary is fragile. Prompts are important, but they are not load-bearing policy documents. They are more like instructions to a very talented temporary worker who never saw the org chart.
Sources are not a pile of documents
Many teams discover during prompting that they do not know which sources are authoritative. They have policy pages, PDFs, email instructions, training material, legacy manuals, chat messages, ticket macros, spreadsheet trackers, and the memory of an operator who everyone calls because she knows how it really works. The model is then asked to answer from the knowledge base. Which knowledge. Which base. The phrase can be doing heroic amounts of concealment.
Source preparation is not glamorous, which is why it is often late. It involves deciding which document wins when sources disagree, how freshness is checked, how temporary rules expire, how exceptions are represented, how confidential material is excluded, how source versions are preserved, and how citation identifiers survive the model's answer. This is not paperwork. It is the difference between retrieval and rummaging.
AI makes source discipline more important because the model can make weak source practices look acceptable. It can stitch fragments into fluent prose. It can smooth over contradictions. It can produce a plausible answer from stale material. A search result with visible gaps feels incomplete. A generated answer with the same gaps may feel complete. The better the prose, the more important the provenance. Confidence should not be allowed to launder a weak source chain.
Good source preparation also reduces prompt complexity. A prompt full of warnings about conflicting policies, stale documents, missing fields, and special exceptions is often a symptom of upstream neglect. If the retrieval layer already filters by authority and freshness, the prompt can be shorter. If the source carries structured metadata, the model does not need to infer it from paragraph titles. If exceptions are represented as rules, the model does not have to become a detective with token limits. The best prompt improvement is sometimes a better index.
Examples are small pieces of governance
Pavyzdžiai paprastai laikomi mokymo priemone, tačiau jie yra ir valdymo įrankis. Geras pavyzdys parodo, ką konkrečioje situacijoje reiškia kokybė. Jis atskleidžia, kaip organizacija tvarko neapibrėžtumą, trūkstamus įrodymus, prieštaringą politiką, jautrų toną, eskalavimą ir atsisakymą. Jis parodo modeliui ir komandai, kaip atrodo geras atsakymas, bet taip pat ir geras neatsakymas. Tai svarbu, nes daug rimtų sistemų žlunga atsakydamos tada, kai turėtų sustoti.
Kuriant pavyzdžius tenka priimti sprendimus, kurių abstrakčios diskusijos išvengia. Paimkite dvidešimt realių atvejų. Pažymėkite teisingą rezultatą. Pažymėkite priimtinus variantus. Pažymėkite nepriimtinus trumpinius. Paaiškinkite, kodėl. Įtraukite kraštinius atvejus, dėl kurių patyrę darbuotojai dvejojo. Įtraukite ir įprastų atvejų, nes sistemos, kurios mokosi tik iš dramatiškų situacijų, įgyja prastas manieras. Paprašykite srities ekspertų nesutarti ir užfiksuokite tą nesutarimą. Tai lėčiau nei paprašyti modelio būti atsargiam. Tačiau taip sukuriama bendra atsargumo kalba.
Pavyzdžiai turėtų apimti ir neigiamus atvejus. Šaltinio nerasta. Šaltiniai prieštarauja. Vartotojas neturi teisės. Prašymas neatitinka paskirties. Klientas prašo kažko, kas skamba paprastai, bet sukelia politikos apribojimus. Modelis turėtų išmokti, kada atsisakyti, eskaluoti, klausti ar grąžinti struktūruotą neapibrėžtumą. Jei pavyzdžiai rodo tik sėkmingus atsakymus, užklausa bus linkusi į užbaigimą. Užbaigimas ne visada yra sėkmė. Kartais geriausias atsakymas yra nepakankami įrodymai, ką sunku pademonstruoti pristatyme, bet naudinga veikiančioje sistemoje.
Pavyzdžiai taip pat yra vertinimo pradžia. Jie gali tapti testų rinkiniais, regresijos atvejais, vertintojų mokymo medžiaga ir stebėsenos pavyzdžiais. Įvykus incidentui, pataisytas atvejis gali tapti nauju pavyzdžiu. Tai suteikia sistemai atmintį. Be pavyzdžių užklausos pakeitimai tampa nuotaikų kaita. Vienas sako, kad atsakymas atrodo geresnis. Kitas sako, kad atrodo prastesnis. Modelis šypsosi viduryje, netrikdomas įrodymų.
Rezultato forma yra veiklos sprendimas
Diskusijose apie užklausas dažnai per daug dėmesio skiriama tonui ir per mažai rezultato formai. Tonas svarbus, ypač bendraujant su klientais ar visuomene. Tačiau rezultato forma lemia, ar atsakymą galima patikrinti, nukreipti, saugoti, patvirtinti, užginčyti ar naudoti kitoje sistemoje. Pastraipa gali būti maloni. Struktūruotas rezultatas gali būti tinkamas naudoti. Rimtas darbas su dirbtiniu intelektu dažnai reikalauja abiejų: skaitomos prozos žmonėms ir laukų, kuriuos mašinos gali patikrinti.
Išvesties struktūra apima privalomus laukus, šaltinių nuorodas, pasitikėjimo ar neapibrėžtumo lygį, atsisakymo priežastis, eskalavimo vėliavėles, paveiktus įrašus, siūlomus veiksmus ir žmogaus patvirtinimo būseną. Joje nurodoma, ar modelis gali palikti lauką tuščią. Joje nurodoma, ar jis privalo cituoti politikos identifikatorių. Joje nurodoma, ar jis gali kurti kategorijas, ar turi rinktis iš kontroliuojamo sąrašo. Joje nurodoma, kas atsitinka, kai įvestis yra dviprasmiška. Šie pasirinkimai nėra raginimo kosmetika. Jie yra darbo eigos dizainas.
Struktūrizuota išvestis taip pat laiko modelį jo vietoje. Jei sistema reikalauja atskiro lauko įrodymams, nepagrįsti teiginiai tampa matomi. Jei ji reikalauja veiksmo tipo iš leidžiamų sąrašo, kūrybiškas įrankių naudojimas tampa sudėtingesnis. Jei ji reikalauja aiškiai nurodyti neapibrėžtumą, peržiūrintieji gali atlikti triažą. Jei ji reikalauja atsisakymo priežasties, užblokuotus atvejus galima analizuoti. Raginimas gali to prašyti, tačiau aplinkinė sistema turėtų tai patvirtinti. Mandagus prašymas nėra kontrolė. Tai pasiūlymas su formatavimu.
Yra ir žmogiškoji pusė. Žmonėms reikia išvesties, atitinkančios jų darbo ritmą. Teisininkui gali reikėti šaltinio sąlygų ir rizikos pastabų. Palaikymo agentui gali reikėti klientui paruošto juodraščio ir vidinių priežasčių kodų. Planuotojui gali reikėti maršruto rekomendacijos ir apribojimo, kuris ją lėmė. Vadovui gali reikėti apibendrintų priežasčių, o ne atskirų tekstų. Jei išvesties struktūra ignoruoja vartotoją, raginimas gali būti techniškai teisingas, bet veikimo požiūriu erzinantis. Tai dažnas pasiekimas, bet ne naudingas.
Autoriteto negalima įgyti paslaugumu
Paslaugus modelis skatina pasitikėjimą. Tai gerai, kol paslaugumas nepainiojamas su autoritetu. Jei modelis parengia atsakymą, kas gali jį išsiųsti. Jei jis rekomenduoja grąžinti pinigus, kas gali tai patvirtinti. Jei jis klasifikuoja riziką, kas gali veikti pagal klasifikaciją. Jei jis ištraukia lauką, kas jį taiso. Jei jis neranda įrodymų, kas nusprendžia, ar tęsti. Į šiuos klausimus reikia atsakyti prieš raginimą, nes raginimas negali suteikti institucinio autoriteto.
Autoriteto dizainas apima vaidmenis, ribas, peržiūros eiles, perrašymo teises, eskalavimo kelius ir audito įrašus. Jis skiria pasiūlymą nuo sprendimo. Jis skiria automatizuotą sprendimą nuo žmogaus sprendimo, paremto automatizavimu. Jis nurodo, kada žmogus turi matyti šaltinio medžiagą, o ne tik modelio tekstą. Jis nurodo, kada įrankio iškvietimas leidžiamas, o kada blokuojamas. Jis nurodo, kam priklauso žala, vėlavimas, taisymas ir komunikacija. Modelis gali padėti laikydamasis to dizaino. Jis neturėtų būti pats dizainas.
Tai ypač svarbu, kai dirbtinis intelektas įtraukiamas į esamas darbo eigas. Esamas autoritetas gali būti neformalus. Vyresnysis darbuotojas tvirtina išimtis, nes visi žino, kad reikia jo paklausti. Komandos vadovas aiškina politiką, nes yra matęs kraštinius atvejus. Skaičiuoklėje saugoma laikina taisyklė, nes sistema to negali. Kai įsitraukia dirbtinis intelektas, neformalus autoritetas tampa trapus. Modelis gali išplėsti seną dviprasmybę greičiau, nei žmonės spėja ją pastebėti. Darbas prieš raginimą yra padaryti autoritetą pakankamai aiškų, kad išplėtimas tiesiog neišplėstų sumaišties.
Verta pasakyti, kad autoritetas nėra greičio priešas. Aiškus autoritetas dažnai pagreitina darbą, nes žmonės žino, kas gali judėti be diskusijų, kas turi sustoti ir kas gali nuspręsti. Neaiškus autoritetas atrodo lankstus, kol neatsiranda apimtis. Tada kiekvienas sudėtingas atvejis tampa maža konstitucine krize, o pokalbių gijos tampa teismų praktika. Tai nerekomenduotina teisinė sistema.
Vertinimas nėra nuotaikos patikra
Daugelis rašymo iteracijų vertinamos pagal nuojautą. Ši versija skamba geriau. Ta versija yra glaustesnė. Ši yra mažiau įsakmi. Tokie vertinimai gali būti naudingi, bet jų nepakanka. Dirbtinio intelekto operacijoms reikia vertinimo, kuris atitinka užduotį. Ar modelis naudojo tinkamą šaltinį. Ar praleido privalomus laukus. Ar atsisakė, kai įrodymų nebuvo. Ar pakėlė didelės rizikos atvejus. Ar išsaugojo politikos identifikatorius. Ar žmonės jį pervertė. Ar klientai uždavė mažiau papildomų klausimų. Ar vėlesnės komandos matė mažiau perdirbimo.
Vertinimas turėtų apimti įprastus atvejus, ribinius atvejus, priešiškus atvejus, pasenusius šaltinius, trūkstamus duomenis, prieštaringas politikas ir priimtino atsisakymo pavyzdžius. Jis turėtų būti pakartojamas. Jis turėtų atskirti modelio gedimą nuo šaltinio gedimo, raginimo gedimo, sąsajos gedimo ir proceso gedimo. Priešingu atveju kiekviena problema tampa raginimo problema, nes raginimas yra ta dalis, kurią visi mato. Matoma dalis ne visada yra kalta dalis. Tai pasakytina tiek apie programinę įrangą, tiek apie susirinkimus.
Vertinimas taip pat nusprendžia, kada sustoti. Be testų rinkinio ir išleidimo kriterijų, raginimų darbas gali tęstis amžinai, nes kalbą visada galima patobulinti. Visada atsiras dar vienas būdvardis, dar viena instrukcija, dar vienas pavyzdys, dar vienas formatavimo pakeitimas. Klausimas ne tas, ar raginimas yra tobulas. Klausimas tas, ar sistema atlieka užduotį laikydamasi sutartų rizikos, sąnaudų ir kokybės ribų. Tobulumas yra prastas išleidimo vadybininkas. Jis neturi budėjimo telefono.
Darbas po raginimo prasideda prieš išleidimą
Koregavimo keliai turėtų būti suprojektuoti prieš pirmajam gamybos vartotojui pranešant apie problemą. Kaip vartotojas pažymi neteisingą atsakymą. Kur tas pažymėjimas keliauja. Kas jį peržiūri. Ar keičiasi šaltinis. Ar keičiasi pavyzdžių bankas. Ar keičiasi raginimas. Ar keičiasi taisyklė. Ar keičiasi riba. Ar žmogus gauna grįžtamąjį ryšį. Ar ištaisytas atvejis tampa regresijos testu. Jei koregavimas nesuprojektuotas, grįžtamasis ryšys tampa krūva. Krūvos yra vieta, kur mokymasis eina ilgai pamiegoti.
Stebėsena taip pat turėtų būti nuspręsta prieš išleidimą. Stebėkite ne tik delsą ir sąnaudas, bet ir atsisakymo rodiklius, šaltinio trūkumo rodiklius, pervertimo priežastis, eskalavimo apkrovą, vėlesnį perdirbimą, skundų temas, pasenusias citatas ir užduočių mišinio pokyčius. Modelio atsakymo kokybė yra tik viena veiklos kokybės dalis. Sistema gali gerai atsakyti ir vis tiek nukreipti per daug darbo žmonėms. Ji gali atsakyti greitai ir vis tiek padidinti pataisymų skaičių. Ji gali sumažinti bilietų skaičių ir vis tiek sukurti sunkesnius bilietus. Stebėsena turėtų matyti darbą, o ne tik žetonus.
Darbas prieš raginimo sukūrimą niekada tikrai nesibaigia. Atsiranda naujos politikos. Keičiasi šaltinių sistemos. Vartotojai randa spragų. Keičiasi modelis. Keičiasi verslas. Raginimas, kuris veikė gegužę, rugsėjį gali būti neteisingas, nes darbas pasislinko po juo. Tai nereiškia, kad viskas yra trapu. Tai reiškia, kad dirbtinio intelekto operacijoms reikia atsakingo valdymo. Kažkas turi prižiūrėti užduoties apibrėžimą, šaltinius, pavyzdžius, vertinimą, įgaliojimus ir taisymą. Priešingu atveju raginimas tampa fosilija su puikia gramatika.
Pamoka
Tikrasis darbas vyksta prieš raginimą, nes raginimas yra matomas didesnės veiklos sistemos kraštas. Modeliui reikia užduoties, kurią jis gali atlikti, šaltinių, kuriais gali pasitikėti, ribų, kurių negali peržengti, rezultatų, kuriuos galima patikrinti, pavyzdžių, kurie įkūnija sprendimus, įgaliojimų, kurie žmonėms ir įrankiams sako, ką jie gali daryti, ir vertinimo, kuris gali atskirti patobulinimą nuo gražesnės prozos. Be to raginimas prisiima atsakomybę, kurios negali įvykdyti.
Šis požiūris nemažina raginimo svarbos. Jis daro raginimą vertingesnį. Raginimas parengtoje operacijoje gali būti trumpas, aiškus, patikrinamas ir lengvai prižiūrimas. Jis gali sutelkti modelį, o ne kompensuoti dviprasmybes. Jis gali vystytis kartu su pavyzdžiais ir įrodymais. Jį galima keisti užtikrintai, nes komanda žino, ką reiškia geras rezultatas. Tai geriau nei raginimo mistika, kuri dažniausiai sukuria ilgesnius raginimus ir tylesnes abejones.
Prieš klausdami, kaip sukurti raginimą modeliui, paklauskite, kokį darbą organizacija jau atliko dėl modelio. Ar užduotis yra įvardyta. Ar šaltiniai yra autoritetingi. Ar pavyzdžiai yra pažymėti. Ar rezultatas yra struktūruotas. Ar įgaliojimai yra aiškūs. Ar nesėkmė yra saugi. Ar vertinimas yra tikras. Ar taisymas yra suplanuotas. Jei atsakymai į šiuos klausimus yra silpni, pradėkite nuo jų. Naudingiausias raginimas kambaryje gali būti tas, kuris priverčia visus pripažinti, kad raginimas nėra vieta, kur prasideda darbas.