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:

┌─────────────────────────────────────┐
│ System prompt (stable)              │  Identity, behavior, hard constraints
├─────────────────────────────────────┤
│ Developer prompt (per-feature)      │  Feature instructions, tools, format
├─────────────────────────────────────┤
│ User prompt (per-call)              │  User query, context, conversation
└─────────────────────────────────────┘

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:

Task: produce a summary of the document below.

Requirements:
- 3-5 bullet points
- Each bullet is one complete sentence
- Focus on facts and concrete claims, not impressions
- If the document contains numbers, include the most important ones
- Do not include marketing language or speculation
- If the document is ambiguous about something important, note it

Format: plain markdown bullets, no preamble.

Koodirevisjoni funktsiooni arendajaprompt:

Task: review the code diff below.

Output a JSON object with:
- summary: 1-2 sentence overview of the change
- concerns: array of specific issues (each: file, line, severity, description)
- suggestions: array of improvements (each: file, line, suggestion)
- approved: boolean (true if no blocking concerns)

Severity levels:
- "blocker": must be fixed before merge
- "warning": should be addressed but not blocking
- "nit": stylistic, optional

Focus on:
- Logic errors
- Security issues
- Performance issues
- Missing test coverage
- Unclear naming or structure

Skip:
- Formatting (handled by formatter)
- Subjective style preferences

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}

User's request: {user_query}

Additional context:
- User name: {name}
- User timezone: {timezone}
- User tier: {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:

| Kontroll | Mida peab nägema | |---|---| | Omanik | Promptil on vastutaja ja selge muutmise põhjus. | | Juhisekihid | Süsteemi-, arendaja- ja kasutajakiht on eraldi, mitte ühte stringi segatud. | | Skeem | Struktureeritud väljundil on valideeritav JSON schema või samaväärne kontroll. | | Süstimise käsitlemine | Kasutaja- ja allikatekst ei saa muuta süsteemi- ega arendajajuhiseid. | | Hindamised | Muudatus läbib regressioonitestid ja sisaldab vähemalt mõnda halva sisendi näidet. | | Logid | Logitakse malli versioon, sisendikategooria, tulemus ja vead ilma tarbetute saladusteta. | | Tagasipööre | On teada, kuidas vana promptiversioon taastada ja milline signaal tagasipöörde käivitab. |

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.

You are an assistant for John, a premium customer who joined in 2023, lives in Tallinn, and has 47 open tickets.

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.

Help the user with their request. Be polite. Format output as JSON. Don't use markdown. The user is asking about pricing, so be careful about quoting numbers. Output should be 1-2 sentences. Now help them.

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

Task: classify the following text into one of these categories:
- billing: payment, refund, subscription
- technical: bug, error, integration issue
- account: login, password, profile changes
- feature_request: new functionality requests
- complaint: general dissatisfaction without specific actionable issue

Output a JSON object: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}

Text to classify:
{text}

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

Ekstraktimine

Task: extract structured data from the document below.

Schema:
- vendor_name: company that issued the invoice
- invoice_number: as printed on the document
- date: ISO 8601 format
- line_items: array of {description, quantity, unit_price, total}
- subtotal, tax, total: numbers

Rules:
- If a field is not present, use null
- Numbers should be numeric, not strings
- For ambiguous cases, set "needs_review": true and explain

Document:
{document}

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

Genereerimine stiiliga

Task: write a {format} on the topic of {topic}, targeting {audience}.

Style:
- {Specific style trait 1}
- {Specific style trait 2}
- Avoid: {anti-pattern 1}, {anti-pattern 2}

Constraints:
- Length: {N} words
- Include: {required elements}
- Exclude: {forbidden elements}

Voice reference:
[Provide a sample of the desired voice]

Output: the {format} only, with no preamble or post-script.

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

Agendi tsükkel

You have access to the following tools:
{tool_descriptions}

For each turn:
1. Think about what you need to do.
2. Decide if you need a tool. If yes, call it.
3. After observing the result, decide if you need more tools or can answer.
4. When you have enough information, produce the final answer.

Constraints:
- Maximum 5 tool calls per request.
- If after 5 calls you can't complete, explain what's missing.
- Never invent tool names or arguments.
- Verify tool results before acting on them.

User request:
{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.

Põhipoint

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.