Tootmis-promptide kavandamine: süsteemi, arendaja ja kasutaja kihid
Tootmispromptid ei ole 'ütle AI-le, mida sa tahad'. Need on kihiline süsteem — stabiilsed juhised, dünaamiline kontekst, päringupõhised muutujad — mida hallatakse nagu koodi. Arhitektuur, mustrid ja distsipliin, mis eristavad tootmist prototüübist.
Outcome: Eraldad süsteemi, arendaja ja kasutaja juhised ning testid tootmisprompte versioonitud süsteemikomponentidena.
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,userrollid. - Anthropic:
system, seejärelmessageskoosuserjaassistantrollidega. Tööriistakirjeldused on eraldi parameeter. - Gemini:
systemInstruction, seejärelcontentsrollidega.
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 fillerSee 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 preferencesIgal 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.j2Iga 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:
- Insener või mitteinsener visandab promptimuudatuse.
- Muudatus käib hindamiskomplekti vastu.
- Hindamistulemused vaadatakse läbi koos muudatusega.
- Kui hindamised läbivad (pole regressioone, ideaalis parandused), saab muudatust heaks kiita.
- Heakskiidetud muudatused juurutatakse.
- 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.