Tootmispromptide kavandamine: süsteemi-, arendaja- ja kasutajakiht

Prototüüp võib alata tekstisisesest sõnest. Tootmiskeskkonna surve tekib siis, kui prompt vajab omanikku, ülevaatust, tagasipööramist, andmekäitlust, mitut funktsiooni või lokaati või mõõdetavat käitumist; see võib juhtuda juba enne käivitamist ning universaalset ajakava pole.

Sa tahad muuta üht osa juhistest, aga mitte teisi. Sa tahad erinevat käitumist erinevatele klienditasemetele. Sa tahad A/B-testida versioone. Sa tahad tagasi pöörata, kui miski katkeb. Sa tahad teada, millal prompti viimati muudeti ja miks.

Tootmispromptide kavandamine teeb need valikud sõnaselgeks. Prompti tekst on üks artefakt hallatud väljalaske- ja käitussüsteemis.

Artikkel kasutab kolmekihilist toimetuslikku arhitektuuri, et selgitada omandit ja muutmissagedust, ning näitab siis, kuidas see teenusepakkujate API-dele kaardistada. See on näidislahendus, mitte universaalne juhtmevorming. Turvapiiri kohta järgi OWASPi promptisüsti vältimise juhendit: juhiste ja andmete eraldamine aitab ülevaatust ja hindamist, kuid ükski promptimall ei loo volitamis- ega isoleerimispiiri.

Tootmispromptide töös on kaks eraldi artefakti: korduvkasutatavad mallid ja päringupõhised andmed. Versiooni malle nagu koodi. Käsitle renderdatud prompte ja mudeli vastuseid tundlike logidena alati, kui need sisaldavad kasutaja, kliendi või sisemisi andmeid.

Kolm API-le kaardistatud toimetuslikku kihti

See lahendus eraldab kolm toimetuslikku vastutusala:

Süsteemikiht. Suhteliselt stabiilne käitumine, identiteet ja piirangud. Selle eest vastutab funktsioonideülese AI-käitumise eest aruandev tiim.

Arendajakiht. Funktsioonipõhised juhised, tööriistakasutuse reeglid ja väljundnõuded. Selle eest vastutab funktsiooni arendav tiim.

Kasutaja- ja käituskiht. Kasutaja soov ning dünaamiline kontekst, nagu volitatud kliendiandmed, vestlusajalugu ja leitud teadmised. See koostatakse päringu või vestlusvooru jaoks.

Omandi, stabiilsete reeglite, funktsioonijuhiste ja käitusandmete segamine võib teha muudatuse ülevaatamise, hindamise, vahemällu salvestamise ja tagasipööramise raskemaks. Eralda need seal, kus see kontrolli parandab; ära suru kolme API-välja peale, kui teenusepakkuja või rakendus kasutab teistsugust esitust.

Juhiste autoriteet ja andmete paigutus on seotud, kuid erinevad asjad. Usaldushierarhia vastab küsimusele, milline juhis konflikti korral võidab. Andmete paigutus vastab küsimusele, kus rakendus dünaamilist või ebausaldusväärset sisu kannab. Leitud teksti paigutamine kasutaja- või kontekstiväljale ei muuda seda volitatuks, täpseks ega turvaliseks. Jõusta identiteet, rentniku ligipääs, andmete minimeerimine, tööriistaõigused ja väljundi valideerimine väljaspool mudelit.

Nende eraldamine on alustala:

┌─────────────────────────────────────┐
│ Süsteemikiht (suhteliselt stabiilne)│  Identiteet, käitumine, reegli kavatsus
├─────────────────────────────────────┤
│ Arendajaprompt (funktsiooni kohta)  │  Funktsioonijuhised, tööriistad, vorming
├─────────────────────────────────────┤
│ Kasutajaprompt (kõne kohta)         │  Kasutaja päring, kontekst, vestlus
└─────────────────────────────────────┘

Teenusepakkujate API-d väljendavad juhiste ja sisu piire erinevalt:

• OpenAI: kasuta Responses API-s rakenduse juhiste jaoks ülataseme instructions parameetrit või developer sõnumit ning kasutaja sisendi jaoks user sõnumit. Kui haldad mitme pöördega töövoogu, ära eelda, et eelmise vastuse juhised kanduvad automaatselt edasi.
• Anthropic: kaardista lahendus Claude’i Messages API-le, selle süsteemijuhiste mehhanismile, sõnumirollidele ja tööriistakirjeldustele; toetatud rollipaigutus võib mudeli ja platvormi järgi erineda.
• Gemini: kaardista see system_instruction parameetrile ja päringu sisule ning valitud API eraldiseisvale tööriistaseadistusele.

Kasuta teenusepakkujapõhist adapterit ja lõiminguteste. Ära kopeeri rollinimesid API-de vahel ega eelda samaväärset prioriteeti, püsimist või tööriistakäitumist.

Kiht 1: Süsteemiprompt

Selles toimetuslikus mustris määrab süsteemikiht funktsioonideülese rolli ja käitumise. Püüa seda funktsioonijuhistest harvem muuta, kuid versiooni ja hinda iga muudatust.

Hea süsteemiprompt katab:

Identiteet. Kes on AI. „Oled ettevõtte [ettevõte] AI-assistent, kes on spetsialiseerunud valdkonnale [valdkond].“

Hääl ja stiil. Kuidas see peaks kõlama. Konkreetsed jooned, mitte ebamäärased kirjeldused.

Nõutavad käitumispiirangud. Millest mudel peaks keelduma, mida eskaleerima, avaldama või vormindama. Jõusta turve, õigused ja pöördumatute toimingute kontroll rakenduskoodis ning järgmistes süsteemides, mitte ära tugine üksnes sellele tekstile.

Käitumismustrid. Kuidas see käsitleb levinud olukordi. Keeldumised, eskalatsioonid, ebakindlus.

Ohutus ja vastavus. Nõutavad avalikustamised, regulatiivsed reeglid, sisupoliitikad.

Mida see EI peaks sisaldama:

• Funktsioonispetsiifilisi juhiseid („müügikirjade puhul tee X“).
• Dünaamilist konteksti („kasutaja tellimuste ajalugu on…“).
• Tööriistakirjeldusi (need lähevad mujale).
• Asju, mis muutuvad sageli.

Süsteemiprompt peaks olema ainult nii pikk, kui hinnatud käitumine nõuab. Lühikesest promptist võib piisata ja pikk võib siiski kriitilised reeglid välja jätta; sõnapiiri sihtimise asemel mõõda juhiste konflikte, ülesande kvaliteeti, latentsust ja tokenikulu.

Näidismall:

Oled [nimi], [ettevõtte või konteksti] AI-assistent.

## Sinu roll
[2–3 lauset selle kohta, mida teed]

## Hääl ja stiil
- [Konkreetne stiiliomadus 1]
- [Konkreetne stiiliomadus 2]
- [Konkreetne stiiliomadus 3]
- Väldi [vastumuster 1]
- Väldi [vastumuster 2]

## Kindlad piirangud
- Ära kunagi [range reegel 1]
- Ära kunagi [range reegel 2]
- Tee alati [range reegel 3]

## Kuidas ebakindlust käsitleda
- Kui sa mõnda fakti ei tea, ütle seda selgelt.
- Kui kasutaja palub midagi, mis jääb sinu ülesandest välja, paku abi selles, mida saad teha.
- Kui palve võib põhjustada kahju, keeldu ja selgita põhjust.

## Vorminguootused
- Vaikimisi lihttekst
- Koodi või struktureeritud andmete kuvamisel kasuta Markdowni
- Ole kokkuvõtlik; ära täida vastust sisutühja tekstiga

See võib olla promptilahenduse stabiilne reegleid kandev osa. Kinnita hindamise ja telemeetriaga, et kavandatud käitumine püsib funktsioonijuhiste, pika konteksti, tööriistatulemuste ning ründesuunaliste sisendite puhul.

Kiht 2: Arendajaprompt

Arendajaprompt on funktsioonispetsiifiline. Erinevatel funktsioonidel on erinevad arendajapromptid.

Kokkuvõtmise funktsiooni arendajaprompt:

Ülesanne: koosta alloleva dokumendi kokkuvõte.

Nõuded:
- 3–5 punkti
- Iga punkt on üks täielik lause
- Keskendu faktidele ja konkreetsetele väidetele, mitte muljetele
- Kui dokumendis on numbreid, lisa olulisemad
- Ära lisa turunduskeelt ega spekulatsiooni
- Kui dokument on millegi olulise osas ebaselge, märgi see

Vorming: lihtsad markdown-punktid, ilma sissejuhata.

Koodirevisjoni funktsiooni arendajaprompt:

Ülesanne: vaata allolev koodimuudatus (diff) üle.

Väljasta JSON-objekt:
- summary: 1–2 lausega ülevaade muudatusest
- concerns: massiiv konkreetsetest probleemidest (igaüks: file, line, severity, description)
- suggestions: massiiv parandustest (igaüks: file, line, suggestion)
- approved: boolean (true, kui blokeerivaid muresid pole)

Raskusastmed:
- "blocker": peab enne merge'i parandama
- "warning": tuleks lahendada, aga ei blokeeri
- "nit": stiililine, valikuline

Keskendu:
- Loogikavigadele
- Turvaprobleemidele
- Jõudlusprobleemidele
- Puuduvale testikatte
- Ebaselgele nimetamisele või struktuurile

Jäta vahele:
- Vormindus (teeb formatter)
- Subjektiivsed stiilieelistused

Igal funktsioonil on oma arendajaprompt. Need on salvestatud eraldi, versioneeritud eraldi, hinnatud eraldi.

Kiht 3: Kasutajaprompt

Kasutajakiht on dünaamiline. See sisaldab tüüpiliselt:

Kasutaja tegelikku soovi. „Tee sellest dokumendist kokkuvõte.“

Konteksti, mille süsteem otsis. Dokumendid RAG-ist, kliendi ajalugu, vestlusajalugu.

Päringupõhiseid muutujaid. Kasutaja nimi, ajavöönd, keele-eelistus, kontotase.

See kiht koostatakse päringu töötlemise ajal programmiliselt. Struktuur näeb tavaliselt välja nii:

{conversation_history_summary}

{retrieved_context}

Kasutaja soov: {user_query}

Lisakontekst:
- Kasutaja nimi: {name}
- Kasutaja ajavöönd: {timezone}
- Kasutaja tase: {tier}

Täpne struktuur sõltub funktsioonist ja teenusepakkujast. Hoia kiiresti muutuvad, kasutajapõhised ja leitud andmed korduvkasutatavatest juhisemallidest väljas, kui API leping ei nõua teistsugust paigutust. Kus andmed ka liiguvad, säilita nende päritolu ning rakenda volitamist, minimeerimist, piiritlemist ja valideerimist.

Mallindusdistsipliin

Tootmispromptide koostamisel on mallidest sageli abi. Tekstisisene ühendamine muutub harude, andmeväljade ja funktsioonide lisandudes raskemini ülevaadatavaks ning testitavaks.

Lihtne mallisüsteem:

from string import Template

SUMMARIZE_TEMPLATE = Template("""
$conversation_summary

Document to summarize:
$document

User's specific instructions: $user_instructions
""")

prompt = SUMMARIZE_TEMPLATE.substitute(
    conversation_summary=summarize_conversation(history),
    document=document_text,
    user_instructions=user_query,
)

Keerukam: malliteek (Jinja2, Handlebars) tingimuste ja osaliste mallidega.

{% if user_tier == "enterprise" %}
You have access to advanced analysis features.
{% endif %}

{% if retrieved_context %}
Relevant context from your knowledge base:
{{ retrieved_context }}
{% endif %}

User's request: {{ user_query }}

Mallindus hoiab prompti struktuuri järjepidevana, võimaldab tingimusloogikat ning teeb kasutaja sisendi piiritlemise või paomärkimise lihtsamaks. See ei peata iseenesest prompti süstimist: käsitle ebausaldusväärset teksti andmete, mitte juhistena.

Vali hallatud tõeallikas

Käsitle tootmisprompte versioonitud väljalaskeartefaktidena. Tõeallikas võib olla repositoorium, enda register või teenus või hallatud redigeerimisliidesega toode. Vali haldus- ja käitusvajaduste järgi, mitte eeldusest, et üks salvestusmuster sobib igale tiimile.

Koodiga hallatavate promptide jaoks on selge lähtemuster repositooriumi kataloog prompts/, kus iga prompt asub eraldi failis:

prompts/
  system/
    main.txt
    customer-support.txt
    code-assistant.txt
  features/
    summarize.txt
    classify-ticket.txt
    generate-email.txt
  templates/
    base.j2

Igal failil saab olla oma muudatuste ajalugu ja PR-i ülevaatus ning tootmisjuurutused viitavad teadaolevale koodiversioonile.

Miks see oluline on:

• Diffi nähtavus. Kui prompt muutub, on diff PR-is. Ülevaatajad näevad täpselt, mis muutus.
• Tagasipööramine. Kui muudatus midagi katki teeb, saad tagasi pöörata.
• Ajalugu. “Millal me muutsime promptis tagastamispoliitikat?” “Miks see lõik siin on?” — vastatav git blame’i kaudu.
• Tööriistad. Linterid, valideerijad, hindamiskomplektid integreeruvad failipõhiste promptidega.

Võrdle põhivalikuid sõnaselgelt:

Tekstisisesed sõned sobivad väikesele prototüübile, kuid neid on raskem avastada ja rakendusest sõltumatult väljastada. Redigeerimisliides võib sobida, kui selle õigused, ülevaatus, päritolu, juurutus ja tagasipööramine vastavad töövoo riskile. Vestlusakendest kleebitud promptid peaksid läbima sama ülevaatuse, puhastamise ja hindamise nagu iga muu kandidaat.

Ära commiti tootmisvestlusi, kliendikirjeid, tugipileteid, sisedokumente ega tundlikke muutujaid sisaldavaid renderdatud prompte. Lähtekoodihaldus on korduvkasutatavate mallide, testandmete ja puhastatud hindamisnäidete jaoks. Päris jäljed kuuluvad vaadeldavushoidlasse, kus on säilitamise, ligipääsu ja puhastamise kontrollid.

Käitusregistrid ja -teenused

Kui promptide väljalasked vajavad rakenduse juurutusest erinevat tempot või volitatud toimetajad vajavad kontrollitud kasutajaliidest, ei pruugi repositoorium üksi anda õiget töövoogu. Register või teenus saab valida heakskiidetud versiooni käitusajal.

Muster: andmebaas või teenus, mis salvestab promptiversioone koos metaandmetega.

prompt = prompt_service.get(
    name="summarize",
    version="v3",
    locale="en",
    user_tier="enterprise",
)

Teenus peaks säilitama:

• Iga prompti praegust ja ajaloolist versiooni.
• Metaandmeid: millal lisatud, kelle poolt, miks.
• Iga versiooniga seotud hindamisskoore.
• Tagasipööramise võimekust.

Salvestusmootor on ainult üks osa lahendusest. Võrdle rollipõhist ligipääsu, auditiajalugu, autenditud käitusligipääsu, keskkondadevahelist edutamist, juurutuse ühtlust, tagasipööramist, eksporti, krüpteerimist, andmekäitlust, käideldavust ja käituskulu. Väikesest andmebaasist piisab ainult siis, kui ümbritsevad kontrollid vastavad nõudele.

Määra, kes võib koostada, üle vaadata, heaks kiita, välja lasta, tagasi pöörata ja renderdatud prompte lugeda. Redigeerimisõigus ei tähenda tootmisväljalaske õigust. Tundlikud töövood võivad vajada eraldi rolle, puhastatud eelvaateid, topeltheakskiitu või liidest, mis ei ava kunagi päris kliendiandmeid.

Hindamisega kaitstud muudatused

Promptimuudatused, mis võivad mõjutada kasutajatulemusi, tööriistakasutust, andmekäitlust, reeglite järgimist või järgnevaid otsuseid, peaksid enne juurutamist läbima ülevaatuse ja riskiga proportsionaalsed hindamised. Väikese riskiga tekstimuudatus võib vajada väikest regressioonikogumit; makset, kontot või reguleeritud otsust mõjutada võiv prompt vajab tugevamaid võrguväliseid juhtumeid, ründeteste, heakskiitu ja etapilist väljalaset. Määra hädaolukorra tee koos piiritletud väljalaske, seire, heakskiidu ja tagasipööramisega, mitte ära möödu väravast vaikimisi.

Voog:

1. Insener või mitteinsener visandab promptimuudatuse.
2. Muudatus käib hindamiskomplekti vastu.
3. Hindamistulemused vaadatakse läbi koos muudatusega.
4. Kui hindamised läbivad (pole regressioone, ideaalis parandused), saab muudatust heaks kiita.
5. Heakskiidetud muudatused juurutatakse.
6. Juurutusjärgne seire püüab kinni selle, mis hindamistest mööda läks.

Sisuliste promptide jaoks säilita esinduslik hindamiskogum ja käita stabiilseid automaatkontrolle CI-s, kui nende signaal on muudatuse blokeerimiseks piisavalt usaldusväärne. Kasuta eksperdi või inimese ülevaatust seal, kus vastuvõtukriteeriumi ei saa automaatskooriks taandada. Talleta, mida testiti, lävend, ülevaataja ja jääv ebakindlus.

See värav ei tõesta õigsust. See muudab väljalaskeotsuse kontrollitavaks ja annab tiimile lähtejoone juurutusjärgsete regressioonide tuvastamiseks.

Praktiline väljalaskekontroll

Enne tootmisprompti muutmist kontrolli vähemalt neid punkte:

Artikliga seotud kontrollnimekiri muudab need kontrollid korratavaks väljalaskeülevaatuseks.

A/B-testimine tootmises

Veebikatseks sobivate promptide puhul võib etapiline võrdlus praeguse versiooniga anda võrguvälistele hindamistele lisaks päris keskkonna signaali. Ära kasuta päris liiklust esimese ohutustestina ega anna inimestele mõõdetavalt riskantsemat varianti üksnes andmete kogumiseks.

Näitlik muster, mitte vaikesuhe:

• 95% liiklusest kasutab tootmise prompti v3.
• 5% saab uue kandidaadi v4.
• Hoia mudelipääs, tööriistaõigused ja toimingupiirid heakskiidetud tootmispiirist kitsamad või sellega võrdsed.
• Mõõda ülesande edukust, ohutus- ja reeglivigu, kasutajate tagasisidet, järgnevaid mõõdikuid ning sobiva liikluse ülevaadatud hindamisskoore.
• Määra enne alustamist minimaalne valim, peatamistingimused, omanik ja ühesammuline tagasipööramine.
• Otsusta piisava tõendusmaterjali järel, kas kandidaati laiendada, parandada või peatada.

Väljastusmehhanismid võivad olla enda funktsioonilipud, juurutuskonfiguratsioon, heakskiidetud promptiregister või kohandatud marsruutimine.

Hoiatused:

• A/B-testimine püüab kinni ainult signaale, mida sa mõõdad. Kui sul pole kasutaja tagasisidet ega alamtarbija konversioonimõõdikuid, ütleb A/B-testimine sulle vähe.
• Statistiline olulisus nõuab mahtu. Madala mahuga funktsioonide jaoks on A/B raske.
• Samaaegsed katsed võivad üksteist mõjutada ja põhjuse omistamist segada; kontrolli kattuvusi teadlikult.
• Arvesta toote, sihtrühma ja jurisdiktsiooni teavitamis-, nõusoleku-, välistamis- ja ülevaatuskohustusi. Suure mõjuga või pöördumatud toimingud vajavad tavaliselt tugevamat heakskiitu ja tagasipööratavust kui liikluse jagamine suudab pakkuda.

Promptide jälgitavus

Määra iga tootmistöövoo jaoks privaatsust säilitav telemeetria. Sisulisi tulemusi mõjutavate kutsete puhul talleta järgmistest väljadest piisavalt, et tuvastada juurutatud käitumine ja taastada tõrge:

• Millist promptimalli kasutati (nimi, versioon).
• Milliseid muutujaid asendati, kasutades lubatud nimesid ja vajaduse korral puhastatud väärtusi.
• Lõplik renderdatud prompt või privaatsust säilitav viide sellele, kui sisu säilitamine on heaks kiidetud.
• Mudeli väljund või selle valideeritud struktureeritud alamhulk vastavalt säilitamisreeglile.
• Latentsus, tokenid, kulu.
• Alamtarbija signaalid (kasutaja tagasiside, edu mõõdikud).

Eesmärk on vastata, milline versioon käitus, milliseid volitatud tõendeid see sai, millise valideeritud väljundi andis, millised tööriistad või reeglid olid kaasatud ja mis järgmisena juhtus. Ära logi peidetud mõttekäiku nende faktide asendusena.

Salvestus võib olla andmebaasitabel või vaadeldavustööriist. Kõige logimisel on päris kulu (kutsete maht × tokenite arv × salvestus) ja päris privaatsusrisk. Otsusta töövoo kaupa, milliseid välju on ohutu säilitada, puhasta saladused ja isikuandmed vaikimisi ning hoia säilitusaeg lühike, kui pikemaks pole vastavusvajadust. Mõni tiim kasutab valimit.

Sea ülevaatussagedus ja valimimeetod mahu, riski, muutumiskiiruse, intsidentide ning õiguspiirangute põhjal. Vaata üle puhastatud või muul viisil heakskiidetud jäljed, lisa teadaolevad äärejuhtumid ja vii kinnitatud tõrked hindamistesse tagasi. Iganädalane valim võib ühele töövoole sobida ja teisele olla sobimatu või ebapiisav.

Promptide vastumustrid

Paar mustrit, mida vältida:

Vastumuster 1: omanikuta mitmeotstarbeline prompt. Suurt süsteemiprompti, mis ühendab omavahel seostamata funktsioone, reegleid, näiteid ja käituseeldusi, võib olla raske üle vaadata, hinnata ja tagasi pöörata. Puudus pole üksnes pikkus, vaid mõõtmata keerukus.

Parandus: eralda komponendid seal, kus omand või muutmispiir seda õigustab, eemalda dubleeritud ja aegunud juhised ning võrdle muudetud lahendust esinduslikes hindamistes.

Vastumuster 2: stringide ühendamine otse koodis.

prompt = "You are helpful. " + (
    "The user is a paid customer. " if user.tier == "paid" else ""
) + f"Their name is {user.name}. " + ...

Habras, raske lugeda, vastuvõtlik süstele.

Parandus: mallisüsteem.

Vastumuster 3: Sama prompt liiga paljudele kasutusjuhtudele.

Üks „üldise assistendi“ prompt, mida kasutatakse e-kirjade koostamiseks, koodi ülevaatamiseks, klienditoeks ja uurimistööks, võib peita ülesandepõhised vastuvõtukriteeriumid ning omandi.

Parandus: funktsioonispetsiifilised arendajapromptid jagatud süsteemipromptide peal.

Vastumuster 4: Kõvasti kodeeritud promptid.

response = openai.chat.completions.create(
    messages=[
        {"role": "system", "content": "You are a helpful assistant..."},
        {"role": "user", "content": query}
    ]
)

Prompt on koodi sisse maetud. Ei saa muuta ilma juurutuseta. Ei saa A/B-testida. Ei saa eraldi versioneerida.

Parandus: eralda promptifaili või -teenusesse.

Vastumuster 5: Hindamiskatte puudumine.

Funktsioon võetakse kasutusele promptiga, mida pole kunagi süsteemselt testitud. Kvaliteeti hinnatakse kõhutunde järgi. Kvaliteedinihet ei saa tuvastada.

Parandus: lisa olulistele käitumistele riskiga proportsionaalne hindamiskate, sealhulgas tõrke- ja eskaleerimisjuhtumid.

Vastumuster 6: Andmete segamine süsteemipromptidesse.

Sa oled assistent Johnile, premium-kliendile, kes liitus 2023. aastal, elab Tallinnas ja kellel on 47 avatud piletit.

Nüüd muutub korduvkasutatav juhise prefiks iga kutsega, mis võib vähendada vahemälu kasutamist ning hägustada reegli ja kliendiandmete erinevust.

Parandus: edasta dünaamilised andmed teenusepakkuja käitussisendi või kontekstimehhanismi kaudu koos päritolu, volituse ja minimeerimisega. Ära järelda usaldust sõnumirollist.

Vastumuster 7: Juhised keskele maetud.

Aita kasutajat taotlusega. Ole viisakas. Vorminda väljund JSON-ina. Ära kasuta markdowni. Kasutaja küsib hinnakujunduse kohta, seega ole ettevaatlik numbrite tsiteerimisel. Väljund peaks olema 1–2 lauset. Nüüd aita teda.

Kriitilisi nõudeid on ülevaatajal raskem leida ja need võivad lähedase tekstiga vastuollu minna.

Parandus: koonda kriitilised juhised selgelt sildistatud plokki, esita iga reegel üks kord ning testi, kas valitud mudel järgib neid esinduslikus pikas ja ründesuunalises kontekstis.

Konkreetsed mustrid levinud funktsioonidele

Paar funktsioonispetsiifilist mustrit:

Klassifikatsioon

Ülesanne: liigita järgmine tekst ühte neist kategooriatest:
- billing: makse, tagasimakse, tellimus
- technical: viga, error, integratsiooniprobleem
- account: sisselogimine, parool, profiilimuudatused
- feature_request: uue funktsionaalsuse soovid
- complaint: üldine rahulolematus ilma konkreetse tegevusliku probleemita

Väljasta JSON-objekt: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Liigendatav tekst:
{text}

Mustrid: nummerdatud kategooriad määratlustega, struktureeritud väljund, kindluse ja põhjenduse väljad.

Ekstraktimine

Ülesanne: eralda dokumendist struktureeritud andmed.

Skeem:
- vendor_name: arve väljastanud ettevõte
- invoice_number: dokumendil trükitud kujul
- date: ISO 8601 formaat
- line_items: massiiv {description, quantity, unit_price, total}
- subtotal, tax, total: numbrid

Reeglid:
- Kui väli puudub, kasuta null
- Numbrid peavad olema numbrilised, mitte stringid
- Ebaselgete juhtude korral määra "needs_review": true ja selgita

Dokument:
{document}

Mustrid: selgesõnaline skeem, tüübiootused, puuduvate andmete käsitlemine, ebamääraste juhtumite eskalatsioon.

Genereerimine stiiliga

Ülesanne: kirjuta {format} teemal {topic}, sihtgrupile {audience}.

Stiil:
- {Konkreetne stiiliomadus 1}
- {Konkreetne stiiliomadus 2}
- Väldi: {anti-pattern 1}, {anti-pattern 2}

Piirangud:
- Pikkus: {N} sõna
- Lisa: {required elements}
- Välista: {forbidden elements}

Hääle viide:
[Anna näide soovitud häälest]

Väljund: ainult {format}, ilma sisse- ega järelsõnata.

Mustrid: konkreetsed stiilijooned (mitte üldised), selgesõnalised piirangud, hääl ankurdatud viitenäidisega.

Agendi tsükkel

Sul on juurdepääs järgmistele tööriistadele:
{tool_descriptions}

Iga vooru kohta:
1. Mõtle, mida pead tegema.
2. Otsusta, kas vajad tööriista. Kui jah, kutsu see.
3. Pärast tulemuse vaatamist otsusta, kas vajad rohkem tööriistu või saad vastata.
4. Kui sul on piisavalt infot, koosta lõplik vastus.

Piirangud:
- Maksimaalselt 5 tööriistakutset päringu kohta.
- Kui pärast 5 kutset ei saa lõpetada, selgita, mis puudub.
- Ära kunagi välja mõtle tööriistade nimesid ega argumente.
- Kontrolli tööriistatulemusi enne nende alusel tegutsemist.

Kasutaja soov:
{user_query}

Mustrid: etapiline tööriistakasutuse protseduur, tööriistaeelarve, selgesõnaline valideerimine ja piiritletud tõrkekäsitlus.

Meeskondlik aspekt

Promptid tootmises hõlmavad tavaliselt mitut inimest:

• Insenerid ühendavad promptid süsteemi, hooldavad malle, haldavad juurutusi.
• Toode määratleb, mida promptid peaksid saavutama.
• Sisu- või turundustiim vastutab hääle- ja stiilijuhendi eest.
• Valdkonna eksperdid teavad, mis on õige konkreetsete kasutusjuhtude jaoks (juriidiline keel, meditsiinilised terminid jne).

Kasulik muster: “promptide ülevaatuse” protsess, mis sarnaneb koodirevisjoniga, õigete ülevaatajatega iga valdkonna jaoks. Häälmuudatused saavad sisu ülevaatuse. Loogikamuudatused saavad inseneriülevaatuse. Valdkonnaspetsiifiline sisu saab eksperdi ülevaatuse.

Tundlike kasutusjuhtude jaoks (õiguslik, meditsiiniline, finants) võivad promptid vajada formaalset ülevaatust ja allkirja. Ehita protsess vastavalt.

Etapiline promptide küpsusplaan

Meeskondadele, kes liiguvad “promptid on stringid koodis” → “promptid on hallatud infrastruktuur”:

1. etapp: vundament.

• Inventeeri promptid ja promptikoostamise kood, mis käitumist sisuliselt mõjutavad.
• Määra juhiste autoriteedimudel, käitusandmete piir, omanikud ja teenusepakkujate kaardistus.
• Vali väljalaskekorraga sobiv hallatud tõeallikas ja mallindusviis.
• Sea üles privaatsust säilitav telemeetria, mis tuvastab juurutatud versiooni ja tulemuse ebavajalikku tundlikku sisu säilitamata.

2. etapp: hindamine.

• Koosta esmalt hindamiskogumid suurima riski ja mahuga promptidele.
• Käita sisuliste promptimuudatuste korral esinduslikke hindamisi ning vajaduse korral valdkonnaülevaatust.
• Pane stabiilsed automaatkontrollid CI-sse ja hoia automatiseerimatud vastuvõtuotsused ülevaatuskirjes nähtavana.

3. etapp: käitus.

• Rakenda promptide versioonimine valitud repositooriumis, registris või teenuses.
• Lisa etapiline väljalaske- ja peatamismehhanism; kasuta A/B-testi ainult sobiva töövoo puhul.
• Ehita seire töövoo nõutud kvaliteedi-, ohutus-, reegli-, latentsus-, kulu- ja järgnevatele signaalidele.
• Kehtesta ülevaatusprotsess promptimuudatustele.

Ära luba seda tulemust kalendri järgi. Lõpeta etapid alles siis, kui testid näitavad, et promptide inventuur on täielik, kriitilised muudatused on versioonitud ja väravatud, tagasipööramine töötab, telemeetria tuvastab juurutatud versiooni ning omanikud suudavad intsidenditoimingu läbi harjutada.

Promptid kui infrastruktuur

Tootmispromptid võivad olla salvestatud sõnedena, kuid need toimivad versioonitud süsteemikomponentidena, mida ümbritsevad koostamise, hindamise, väljalaske, ligipääsu ja vaadeldavuse kontrollid.

Juhisehierarhia määrab autoriteedi, kuid ei turva käitusandmeid ega tööriistatoiminguid. Mallindus võib vähendada koostamisvigu, kuid ei takista promptisüsti. Hallatud tõeallikas annab versiooniajaloo. Riskiga proportsionaalsed hindamised toetavad väljalaskeotsust ja telemeetria testib, kas kavandatud käitumine püsib väljaspool hindamiskogumit.

Nõutav rangus sõltub riskist ja ulatusest, kuid iga välja jäetud kontroll vajab talletatud põhjendust. Avaldamisväited peaksid näitama tegelikult rakendatud versioonimise, hindamise, väljalaske, tagasipööramise ja telemeetria tõendeid.

Kavandatud juhitavus jääb hüpoteesiks, kuni hindamised ja tootmistelemeetria näitavad, et valitud mudel, promptiversioon, andmetee, tööriistad ja reeglid käituvad vastuvõtulävendite piires. Säilita need tõendid koos väljalaskega, uuri tõrkeid versiooni järgi ja hoia tagasipööramine kasutatavana.

Alusta väikseimast arhitektuurist, mis muudab omandi, autoriteedi, andmekäitluse, hindamise, juurutuse, tagasipööramise ja tõendid sõnaselgeks.