Tootmis-promptide kavandamine: süsteemi, arendaja ja kasutaja kihid

Prototüübis on prompt string, mille kirjutasid ühel pärastlõunal. Tootmises laguneb see lähenemine umbes esimese kuu jooksul.

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.

Tootmis-promptisüsteem käsitleb seda kõike. See ei ole “kirjuta string”. See on arhitektuur.

See artikkel käsitleb, milline see arhitektuur välja näeb — kolm kihti, mallindusdistsipliin, versioonihaldus, hindamine ja operatiivsed praktikad, mis muudavad promptid artefaktist infrastruktuuriks.

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 kihti

Tootmis-promptidel on kolm eraldiseisvat kihti, igal omad mured:

Süsteemikiht. Stabiilne käitumine, identiteet, piirangud. Muutub harva. Kuulub AI-käitumise kavandajameeskonnale.

Arendajakiht. Per-funktsiooni juhised, tööriistakirjeldused, väljundvormingu nõuded. Muutub, kui funktsioonid muutuvad. Kuulub funktsiooniväljundamise meeskonnale.

Kasutajakiht. Kasutaja konkreetne soov ja dünaamiline kontekst (tema andmed, vestlusajalugu, otsitud teadmised). Iga kõnega erinev.

Nende segamine on kõige levinum tootmis-promptide viga. Süsteemiprompt kasvab 5000 sõnani, mis segab identiteeti, funktsioonijuhiseid ja dünaamilist konteksti, ja nüüd üht asja muutes katkeb teine.

Nende eraldamine on alustala:

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

Mudeli API-d toetavad seda selgesõnaliselt:

• OpenAI: system, developer, user rollid.
• Anthropic: system, seejärel messages koos user ja assistant rollidega. Tööriistakirjeldused on eraldi parameeter.
• Gemini: systemInstruction, seejärel contents rollidega.

Kasuta neid eristusi tahtlikult.

Kiht 1: Süsteemiprompt

Süsteemiprompt määratleb, kes AI on ja kuidas ta käitub. See muutub harva.

Hea süsteemiprompt katab:

Identiteet. Kes on AI. “You are an AI assistant for [Company], specializing in [domain].”

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

Ranged piirangud. Asjad, mida see ei tohi kunagi teha. Toota teatud sisu, teha teatud otsuseid, ignoreerida teatud juhiseid.

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 (“for sales emails, do X”).
• Dünaamilist konteksti (“the user’s order history is…”).
• Tööriistakirjeldusi (need lähevad mujale).
• Asju, mis muutuvad sageli.

Hea süsteemiprompt on 300–1000 sõna. Pikem ja seda on raske hallata; lühem ja sa alaspetsifitseerid käitumist.

Mall, mis töötab:

You are [name], an AI assistant for [company / context].

## Sinu roll
[2-3 sentences on what you do]

## Hääl ja stiil
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- Do not [anti-pattern 1]
- Do not [anti-pattern 2]

## Kindlad piirangud
- Never [hard rule 1]
- Never [hard rule 2]
- Always [hard rule 3]

## Kuidas ebakindlust käsitleda
- If you don't know something factual: say so explicitly.
- If a user asks for something outside scope: offer what you can help with.
- If a request might cause harm: refuse and explain why.

## Vorminguootused
- Plain text by default
- Use markdown when displaying code or structured data
- Be concise; do not pad responses with filler

See on selgroog. Iga interaktsioon läheb sellest läbi. Muudatused on tahtlikud ja harvad.

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. “Summarise this document for me.”

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

Per-kõne muutujaid. Kasutaja nimi, ajavöönd, keele-eelistus, kontotase.

See kiht on koostatud programmiliselt kõneajal. 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. Põhimõte: andmed lähevad siia, mitte süsteemi- ega arendajapromptidesse.

Mallindusdistsipliin

Promptid tootmises on ehitatud mallidest. Stringi konkateneerimine kohapeal on prototüübi lähenemine; see ei skaaleeru.

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 ennetab promptisüsti muutujate kaudu (varju kasutaja sisendit, kus sobib), võimaldab tingimuslikku loogikat ja hoiab promptistruktuuri järjepidevana.

Versioonihaldus

Promptid on kood. Salvesta need lähtekoodihaldusesse.

Muster, mis töötab: prompts/ kataloog sinu repos, ühe promptiga faili kohta:

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

Iga fail on eraldi prompt, oma commit-ajalooga. Muudatused vaadatakse läbi PR-ide kaudu. Tootmise juurutused viitavad konkreetsetele versioonidele.

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äldi: promptid salvestatud stringidena koodis (raske leida, raske diffida), promptid salvestatud kasutajaliidese tööriistas (versioneerimine on tööriista oma, mitte sinu oma), promptid kleebitud inimeste jututubadest (jälgimata, testimata).

Prompt kui andmed: väline salvestus

Promptide jaoks, mis muutuvad sageli — A/B-testid, kasutajatasemete variatsioonid, kohaspetsiifilised promptid — failipõhine lähtekoodihaldus on liiga aeglane.

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

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

Teenus säilitab:

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

Tööriistad: PromptLayer, Helicone või sisemine teenus. Enamiku meeskondade jaoks töötab sisemine teenus lihtsa andmebaasiskeemiga hästi.

Liides on kriitiline. Insenerid ja mitteinsenerid (toode, sisu) peaksid suutma promptisid muuta. Aga muudatused lähevad läbi ülevaatuse ja läbivad hindamised enne käiku minekut.

Hindamisega kaitstud muudatused

Iga promptimuudatus läbib hindamised enne juurutamist. See pole tõsiste tootmissüsteemide jaoks läbiräägitav.

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.

Praktikas tähendab see, et igal promptil on hindamiskomplekt ja komplekt käib CI-s promptimuudatuste korral.

Ilma selle väravata rikuvad promptimuudatused asju etteennustamatutel viisidel. Sellega saad liikuda kiiresti ja kindlalt.

Praktiline väljalaskekontroll

Enne tootmisprompti muutmist kontrolli vähemalt neid punkte:

Kaasas olev kontrollnimekiri sobib PR-i või väljalaskemärkmete juurde: tootmisprompti väljalaskekontroll.

A/B-testimine tootmises

Uute promptide jaoks annab nende A/B-testimine olemasoleva versiooni vastu väikesel osal tootmisliiklusest reaalse maailma signaali, mis ületab hindamisi.

Muster:

• 95% liiklusest kasutab tootmise prompti v3.
• 5% saab uue kandidaadi v4.
• Mõõda: kasutaja tagasiside, alamtarbija mõõdikud, hindamisskoorid reaalsel liiklusel.
• Pärast piisavaid andmeid otsusta: rulli v4 100%-le või jää v3 juurde.

Tööriistad: funktsioonilippud (LaunchDarkly, sisemine), promptiversioneerimise teenused (PromptLayer), 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.
• Ära jookse korraga liiga palju A/B-teste; interaktsioonid muutuvad segadusttekitavaks.

Promptide jälgitavus

Iga tootmise LLM-kõne peaks logima:

• Millist promptimalli kasutati (nimi, versioon).
• Milliseid muutujaid asendati.
• Lõpliku renderdatud prompti.
• Mudeli vastus.
• Latentsus, tokenid, kulu.
• Alamtarbija signaalid (kasutaja tagasiside, edu mõõdikud).

See on andmed, mida vajad selleks, et siluda “miks andis mudel sellele kasutajale veidra vastuse?”. Ilma selleta arvad.

Salvestus: andmebaasi tabel või jälgitavustööriist. Kulud on reaalsed, kui logid kõike (kõnemaht × tokeniarv × salvestus). Mõned meeskonnad teevad valimi.

Ülevaatused: regulaarne praktika (iganädalane) lugeda tootmise päris promptide ja vastuste valimit. Püüab kinni probleeme, mida hindamised ei püüa.

Promptide vastumustrid

Paar mustrit, mida vältida:

Vastumuster 1: Megaprompt. 10 000-sõnaline süsteemiprompt, mis üritab käsitleda iga olukorda. Raske muuta, raske siluda, mudel ignoreerib sageli hilisemaid juhiseid.

Parandus: eralda kihilisteks, fokusseeritud promptideks. Üks funktsiooni kohta.

Vastumuster 2: Sisseliinine stringi konkatenatsioon.

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 “üldine assistent” prompt, mida kasutatakse e-kirjade koostamiseks, koodirevisjonideks, klienditoeks ja uurimistöödeks. Iga on erinev ülesanne; üks prompt ei optimeeri ühegi jaoks.

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 tarnitakse promptiga, mida pole kunagi süsteemselt testitud. Kvaliteet on “vibe”. Triiv on tuvastamatu.

Parandus: igal promptil on hindamiskomplekt.

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 süsteemiprompt iga kõnega. Vahemällu salvestamine katkeb. Segadus rohkeneb.

Parandus: dünaamilised andmed lähevad kasutaja/konteksti kihti, mitte süsteemipromptidesse.

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.

Olulised juhised kaovad. Mudel võib need vahele jätta.

Parandus: struktureeri selgete sektsioonidega, paiguta kriitilised juhised algusesse ja lõppu (värskuse efekt aitab).

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": "<üks ülaltoodust>", "confidence": "<high|medium|low>", "reasoning": "<1 lause>"}

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:
- {Specific style trait 1}
- {Specific style trait 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: selgesõnalised arutlussammud, tööriistaeelarve, vastu-hallutsinatsioon, peegeldus.

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/turundus omab hääle- ja stiilijuhendi.
• 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.

90-päevane promptide küpsuseplaan

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

Päevad 1–30: Vundament.

• Eralda kõik promptid spetsiaalsetesse failidesse lähtekoodihalduses.
• Kehtesta 3-kihiline muster (süsteem / arendaja / kasutaja).
• Ehita lihtne mallikiht.
• Sea üles promptide ja vastuste põhilogimine.

Päevad 31–60: Hindamine.

• Ehita hindamiskomplektid 5 tippprompti jaoks.
• Jookse hindamisi promptimuudatuste korral (esmalt käsitsi).
• Sea üles CI-integratsioon hindamistele (auto-käivitus PR-idel).

Päevad 61–90: Operatsioonid.

• Rakenda promptide versioneerimine (andmebaas või teenus).
• Lisa A/B-testimise võimekus vähemalt ühele kriitilisele promptile.
• Ehita juhtpaneele tootmise prompti kvaliteedi jaoks.
• Kehtesta ülevaatusprotsess promptimuudatustele.

Pärast 90 päeva on promptid hallatud infrastruktuur. Muudatused on tahtlikud, testitavad, ülevaadatavad, tagasipööratavad. Kvaliteet on mõõdetav. Triiv on tuvastatav.

Promptid kui infrastruktuur

Tootmis-promptid ei ole stringid. Need on kihiline süsteem distsipliiniga versioneerimise, mallinduse, hindamise ja jälgitavuse ümber.

Kolmekihiline arhitektuur (süsteem / arendaja / kasutaja) eraldab mured ja hoiab promptid hooldatavana. Mallindus ennetab haprust. Lähtekoodihaldus või promptiteenus annab versiooniajaloo. Hindamised väratevad muudatusi. Jälgitavus püüab kinni selle, mida hindamised vahele jätavad.

See pole tõsises tootmistöös valikuline. Meeskonnad, kes need sammud vahele jätavad, lõpetavad promptide kaosega — stringid laiali koodis, pole aimugi, milline versioon on tootmises, kvaliteet pole mõõdetud ja pidevad seletamatud käitumismuutused.

Meeskonnad, kes investeerivad promptide infrastruktuuri, lõpetavad AI-käitumisega, mis on juhitav, mõõdetav ja parandatav. See on erinevus funktsiooni, mis vananeb hästi, ja sellise vahel, millest saab tehniline võlg.

Alusta arhitektuurist. Kõik muu muutub lihtsamaks.