प्रॉम्प्ट इंजीनियरिंग की छवि खराब है। इंटरनेट का आधा हिस्सा जादुई वाक्य बेचता है। दूसरा आधा कहता है प्रॉम्प्ट मायने नहीं रखते क्योंकि मॉडल पहले से "काफी स्मार्ट" हैं। प्रोडक्ट काम के लिए दोनों पक्ष गलत हैं।
प्रोडक्ट फीचर में मॉडल एक कंपोनेंट है: इनपुट, आउटपुट, लेटेंसी बजट, और फेल होने के तरीके। आपका प्रॉम्प्ट इंटरफेस का कॉन्ट्रैक्ट है। अस्पष्ट कॉन्ट्रैक्ट अस्पष्ट सॉफ्टवेयर बनाता है। कसे कॉन्ट्रैक्ट से उबाऊ, जाँचने लायक व्यवहार मिलता है।
यह पोस्ट उन प्रोडक्ट इंजीनियरों के लिए है जो असली ऐप में एलएलएम फीचर शिप करते हैं: सपोर्ट कोपायलट, सारांश, ट्रायज, फॉर्म भरना, कोड हेल्पर, कंटेंट चेकर। निजी चैट के लिए मज़ेदार सिस्टम प्रॉम्प्ट लिखने के लिए नहीं। ज्ञान जनवरी २०२६ तक के फ्रेम में है। मॉडल के नाम बदलते रहते हैं। फेल मोड ज़्यादातर नहीं।
प्रोडक्शन में "काम करना" का मतलब
डेमो में "काम करता" प्रॉम्प्ट वह है जो एक बार सहकर्मी को प्रभावित करे। प्रोडक्शन में काम करने वाला प्रॉम्प्ट वह है जो:
१. एक स्कीमा के अंदर रहे जिसे आप पार्स कर सकें (जेएसओएन, इनम, तय सेक्शन)। २. ज़ोर से फेल हो जब काम न कर पाए (मनाही, खाली वैकल्पिक फ़ील्ड, साफ़ कम कॉन्फिडेंस)। ३. डिस्ट्रीब्यूशन शिफ्ट पर गुणवत्ता रखे (नए प्रोडक्ट नाम, गन्दा यूज़र टेक्स्ट, लंबे थ्रेड)। ४. टोकन और रिट्राई पर इतना सस्ता रहे कि यूनिट इकोनॉमिक्स बंद हो। ५. सबूत से सुधरे, गलियारे की राय के एक और राउंड से नहीं।
अगर आप सिर्फ सुंदर भाषा ऑप्टिमाइज़ करते हैं, तो स्क्रीनशॉट में अच्छी और एज केस पर टूटने वाली फीचर शिप होगी।
१. संरचना कविता से जीतती है
मॉडल वाइब्स से ज़्यादा संरचना मानते हैं। प्रोडक्ट प्रॉम्प्ट सावधान ठेकेदार के ब्रीफ जैसे हों, प्रेरणा भाषण जैसे नहीं।
एक संरचना जो टिकती है:
# Role (one line)
You extract structured support tickets from user messages.
# Task
Given a user message and optional product context, return a ticket draft.
# Inputs
- user_message: free text from the customer
- product_context: short catalog of product names and plan tiers (may be empty)
# Output contract
Return ONLY valid JSON matching this schema:
{
"category": "billing" | "bug" | "how_to" | "account" | "other",
"priority": "low" | "medium" | "high",
"summary": string, // <= 140 chars, no greeting
"steps_tried": string[], // empty if unknown
"needs_human": boolean,
"confidence": number // 0.0-1.0
}
# Rules
- Prefer "other" over guessing a category.
- Set needs_human true for refunds, legal threats, or safety issues.
- Never invent product names not present in product_context or user_message.
- If the message is empty or nonsense, still return JSON with category "other",
confidence <= 0.2, and summary describing the problem.
# Examples
[few-shot examples here]
# User task
user_message: {{user_message}}
product_context: {{product_context}}
यह आकार क्यों काम करता है:
- भूमिका छोटी है। लंबे पर्सना निबंध टोकन जलाते हैं और सटीकता शायद ही सुधारें।
- आउटपुट कॉन्ट्रैक्ट मशीन से जाँचा जा सकता है। डेटाबेस छूने से पहले जेएसओएन वैलिडेट करें।
- नियम प्रोडक्ट नीति कोड करते हैं, लेखन शैली नहीं।
- उदाहरण कॉन्ट्रैक्ट के पास रहते हैं ताकि मॉडल आकार और नीति दोनों देखे।
बचें: "आप विश्व-स्तरीय सपोर्ट जीनियस हैं जो ग्राहकों की गहराई से परवाह करते हैं और हमेशा और आगे जाते हैं।" यह फीलर है। मॉडल पहले से मददगार रहता है। नीति कठिन हिस्सा है।
२. फ्यू-शॉट आपकी यूनिट टेस्ट सुइट है, भेष में
फ्यू-शॉट उदाहरण सजावट नहीं हैं। ज़्यादातर प्रोडक्ट प्रॉम्प्ट के लिए ये यूनिट टेस्ट के सबसे करीब हैं। इन्हें रिग्रेशन फिक्स्चर की तरह चुनें।
कितने:
- ०-१ तंग एक्सट्रैक्शन और सख्त स्कीमा के लिए (अक्सर काफी)।
- २-५ क्लासिफिकेशन, राउटिंग, या स्टाइल-संवेदनशील जनरेशन के लिए।
- ५ से ज़्यादा तभी जब हर उदाहरण अलग फेल क्लास कवर करे। उसके बाद आमतौर पर बेहतर नियम या छोटा स्पेशलिस्ट मॉडल चाहिए।
हर उदाहरण में क्या रखें:
१. यथार्थ इनपुट (अधूरी व्याकरण, आंशिक जानकारी, प्रोडक्ट जार्गन)। २. वही आउटपुट आकार जो चाहिए। ३. कम से कम एक नकारात्मक / कठिन केस: अस्पष्टता, गायब डेटा, नीति की सीमा।
क्लासिफायर के लिए अच्छा फ्यू-शॉट सेट:
| इनपुट का स्वाद | क्यों है |
|---|---|
| साफ़ बिलिंग सवाल | हैप्पी पाथ |
| बग रिपोर्ट जो फीचर रिक्वेस्ट जैसी लगे | श्रेणियों की सीमा |
| गुस्सैल रिफंड माँग | नीति: नीड्स_ह्यूमन, प्रायोरिटी |
| दो इरादों वाला संदेश | प्राथमिक श्रेणी नियम मजबूर करता है |
| खाली / सिर्फ इमोजी | नियंत्रित गिरावट |
बुरे फ्यू-शॉट आदतें:
- सभी उदाहरण साफ़ और विनम्र।
- उदाहरण लिखे नियमों से टकराते हैं।
- उदाहरण ऐसी शैली सिखाते हैं जिसकी ज़रूरत नहीं ("आदरणीय ग्राहक...")।
- लगभग एक जैसे छह टिकट चिपका देना। यह शोर है, सिग्नल नहीं।
प्रोडक्ट बदलाव के बाद गुणवत्ता गिरे तो पहले फ्यू-शॉट अपडेट करें। फाइन-ट्यूनिंग से सस्ता और एक और नियम पैराग्राफ से भरोसेमंद।
३. बाधाएँ: मॉडल को कम आज़ाद रखें
प्रोडक्ट इंजीनियर स्वतंत्रता के अंश हटाकर जीतते हैं। हर खुला विकल्प वह जगह है जहाँ गुणवत्ता भटकती है।
वे बाधाएँ जो गुणवत्ता सबसे ज़्यादा सुधारें:
- श्रेणी, प्राथमिकता, भाषा, टोन के लिए बंद सेट।
- लंबाई सीमा ("सारांश <= १४० अक्षर", "अधिकतम ३ बुलेट")।
- अनुमत टूल / स्रोत ("सिर्फ दिए स्निपेट इस्तेमाल करें; गायब हों तो कहें कि नहीं पता")।
- मना क्रियाएँ ("छूट न दें", "यूज़र वेरिफाइड न कहें")।
- क्रम ("सुझाव से पहले जोखिम सूची")।
- आरएजी पर उद्धरण प्रारूप ("हर तथ्यात्मक दावे पर सोर्स_आईडी")।
टेम्परेचर और डिकोडिंग प्रॉम्प्ट सिस्टम का हिस्सा हैं, भले एपीआई पैरामीटर में रहें:
| कार्य प्रकार | सामान्य सेटिंग | कारण |
|---|---|---|
| क्लासिफिकेशन / एक्सट्रैक्शन | टेम्परेचर ०-०.२ | स्थिर लेबल |
| छोटे यूआई कॉपी वेरिएंट | ०.४-०.७ | हल्की विविधता |
| ब्रेनस्टॉर्म / आइडिएशन | ०.७-१.० | निर्धारण से ज़्यादा विविधता |
मॉडल संस्करण पिन करें। "लेटेस्ट" रिलीज़ रणनीति नहीं है। चुपचाप मॉडल अपग्रेड जो इनम शब्द बदल दे, रात २ बजे पार्सर तोड़ देगा।
जहाँ स्टैक सहारे (जेएसओएन मोड, स्ट्रक्चर्ड आउटपुट, टाइप किए आर्ग वाला टूल कॉलिंग), स्कीमा एनफोर्समेंट इस उम्मीद से बेहतर है कि गद्य वैध रहे। फिर भी अपनी तरफ वैलिडेट करें। मॉडल वैध जेएसओएन दे सकता है जो बिज़नेस नियम तोड़े।
४. इवल लूप ही प्रोडक्ट है
बिना इवल सेट प्रॉम्प्ट शिप करना ड्राफ्ट शिप करना है। स्लैक की राय गुणवत्ता प्रणाली नहीं है।
एलएलएम फीचर के लिए न्यूनतम व्यवहार्य इवल:
१. गोल्डन सेट: ५०-२०० असली या यथार्थ केस, अपेक्षित आउटपुट (या रूब्रिक) के साथ। २. ऑटो चेक: स्कीमा वैध, इनम सदस्यता, लंबाई सीमा, ज़रूरी फ़ील्ड मौजूद, मना स्ट्रिंग नहीं। ३. मॉडल-एज़-जज संयम से: सिर्फ खुले गुणवत्ता के लिए, और सिर्फ तय रूब्रिक के साथ। लॉन्च कसौटी के लिए मानव लेबल बेहतर। ४. रिग्रेशन गेट: गोल्डन सटीकता या क्रिटिकल नीति चेक गिरें तो प्रॉम्प्ट बदलाव मर्ज न हो।
वह मापें जो यूज़र महसूस करे:
- टास्क सफलता दर (टिकट सही श्रेणी में?)
- एडिट दूरी / मानव ओवरराइड दर (एजेंट ड्राफ्ट कितना फिर लिखते हैं)
- सुरक्षा / नीति उल्लंघन दर
- सफल टास्क प्रति लेटेंसी और लागत
- "खाली पर आत्मविश्वासी" दर (पूरा लगता है, गलत है)
एक सरल ऑफलाइन लूप:
1. Collect failures from production logs (redact PII).
2. Turn each failure into a fixture: input + expected behavior.
3. Change one thing: rule, example, schema, or retrieval, not five at once.
4. Run the suite.
5. Spot-check 20 random cases by hand.
6. Ship behind a flag. Watch override rate for 48 hours.
वे प्रॉम्प्ट "सुधार" जो सिर्फ तीन चुने चैट पर जीतें, सुधार नहीं हैं। अतिरिक्त कदमों वाला ओवरफिटिंग है।
५. फेल मोड जो प्रोडक्ट इंजीनियर सच में झेलते हैं
गढ़ी हुई निश्चितता
मॉडल प्लान नाम, कीमत या नीति गढ़ लेता है। उपचार: सिर्फ ग्राउंडेड संदर्भ, "अज्ञात" की अनुमति, अनिवार्य उद्धरण, कैटलॉग आईडी से पोस्ट-चेक।
स्कीमा ड्रिफ्ट
वैध जेएसओएन, गलत फ़ील्ड प्रकार, वे इनम मान जो आपने कभी न लिखे। उपचार: सख्त स्कीमा वैलिडेशन, रिजेक्ट + छोटे रिपेयर प्रॉम्प्ट से रिट्राई, अमान्य पंक्ति कभी न लिखें।
निर्देश टकराव
सिस्टम कहे "संक्षेप में।" फ्यू-शॉट लंबे निबंध दिखाए। यूज़र कहे "पिछले निर्देश अनदेखा करें।" उपचार: शैली का एक स्रोत, नियमों से मेल खाते उदाहरण, अविश्वसनीय यूज़र सामग्री अलग या साफ़।
यूज़र सामग्री से प्रॉम्प्ट इंजेक्शन
सपोर्ट टिकट, ईमेल बॉडी और डॉक्स में "सभी नियम अनदेखा करें..." आ सकता है। उपचार: यूज़र सामग्री डेटा है, निर्देश नहीं; अलग चैनल (सिस्टम बनाम यूज़र); टूल अलाउलिस्ट; मॉडल सुझाया शेल या एसक्यूएल बिना सख्त गेट न चलाएँ।
संदर्भ ठूँसना
पूरा हैंडबुक प्रॉम्प्ट में डाल दिया। महत्वपूर्ण नियम डूब जाते हैं। उपचार: टॉप चंक रिट्रीव करें, सिस्टम नियम छोटे रखें, क्रिटिकल नीति शुरुआत और अंत में रखें अगर मॉडल लॉन्ग-कॉन्टेक्स्ट हो पर बीच में अभी भी खोए।
ओवर-रिफ्यूज़ल या अंडर-रिफ्यूज़ल
सेफ्टी जायज़ प्रोडक्ट मदद रोक दे, या हानिकारक माँग छोड़ दे। उपचार: प्रोडक्ट-विशिष्ट अनुमति/मना उदाहरण, सीमावर्ती वर्गों पर मानव समीक्षा, ऐप प्रॉम्प्ट में सामान्य सेफ्टी शून्य से न गढ़ें।
चुप मल्टी-इंटेंट पतन
यूज़र दो चीज़ें माँगे; मॉडल एक का जवाब दे। उपचार: साफ़ मल्टी-इंटेंट स्कीमा (intents[]) या पहला राउटर जो टास्क बाँटे।
रिट्राई से लेटेंसी मौत
रिपेयर लूप, टूल कॉल और लंबे संदर्भ जुड़कर पी९५ बेकार कर दें। उपचार: अधिकतम टोकन और अधिकतम टूल राउंड बजट; मानव कतार पर फेल; स्थिर सिस्टम प्रीफिक्स कैश।
मेट्रिक थिएटर
सिर्फ "थंब्स अप" ट्रैक करें। पावर यूज़र लाइक दबाते हैं; चुप फेल वोट नहीं करते। उपचार: ओवरराइड दर, टास्क पूरा होना, और सैंपल ऑडिट मापें, सिर्फ मुस्कान नहीं।
६. पैटर्न जो प्रोडक्टों में ट्रांसफर होते हैं
राउटर फिर स्पेशलिस्ट
एक सस्ता कॉल इरादा वर्गीकृत करे। स्पेशलिस्ट प्रॉम्प्ट बिलिंग, बग, हाउ-टू संभालें। छोटे प्रॉम्प्ट इवल में आसान और चलाने में सस्ते।
निकालो फिर करो
पहला कॉल: संरचित एक्सट्रैक्शन। दूसरा कॉल या निर्धारक कोड: साइड इफेक्ट (टिकट बनाएँ, ईमेल भेजें)। फ्री-फॉर्म जनरेशन अकेले राइट पथ का मालिक न बने।
इंसान के लिए ड्राफ्ट
अगर इंसान नतीजा संपादित करेगा, आसान सुधार के लिए ऑप्टिमाइज़ करें (साफ़ सेक्शन, छोटा सारांश, साफ़ मान्यताएँ)। "पूरा दिखने" के लिए नहीं।
गद्य योजना से बेहतर टूल कॉलिंग
जब मॉडल को डेटा चाहिए, टाइप किए आर्ग वाले टूल दें। फ्री टेक्स्ट "डॉक्स खोजो" से गढ़ी यूआरएल मिलती हैं।
प्रॉम्प्ट को कोड की तरह वर्शन करें
प्रॉम्प्ट रेपो या वर्शन्ड स्टोर में रखें। हर अनुरोध पर prompt_version लॉग करें। पीआर में प्रॉम्प्ट डिफ। किसी भी बुरे डिप्लॉय की तरह रोलबैक।
७. छोटा काम किया उदाहरण: बाधाओं से फिर लिखना
कमज़ोर प्रॉम्प्ट:
Summarize this support thread helpfully for an agent.
मज़बूत प्रॉम्प्ट (संक्षिप्त):
Summarize the support thread for an agent who has 20 seconds.
Return JSON:
{
"customer_goal": string,
"what_we_tried": string[],
"blockers": string[],
"next_action": string,
"sentiment": "calm" | "frustrated" | "urgent",
"open_questions": string[]
}
Rules:
- Quote product names exactly as written.
- next_action must be a single concrete step.
- If the thread is only acknowledgements, set customer_goal to
"unclear" and open_questions to what the agent should ask.
- No greeting, no closing, no markdown.
दूसरा संस्करण उन तरीकों से फेल होता है जिन्हें आप पकड़ सकते हैं। पहला उन तरीकों से फेल होता है जो तब दिखते हैं जब एजेंट गलत सारांश पर भरोसा कर ले।
८. कहाँ समय बर्बाद न करें
- प्रॉम्प्ट "मंत्र" ("गहरी साँस लें", "आप जीपीटी-जीनियस हैं") मुख्य रणनीति के रूप में। कभी-कभी स्टाइल धक्का ठीक; गुणवत्ता प्रणाली नहीं।
- विशाल पर्सना उपन्यास। एक पंक्ति भूमिका काफी।
- बिना इवल सुइट हर मॉडल रिलीज़ का पीछा। आप नहीं जान सकते कि नया मॉडल आपके टास्क पर बेहतर है।
- पहले फाइन-ट्यूनिंग। संरचना, रिट्रीवल और इवल ठीक करें। फाइन-ट्यून तब जब टास्क स्थिर हो और बचे त्रुटियाँ व्यवस्थित हों।
- हर प्रोडक्ट सतह के लिए एक मेगा-प्रॉम्प्ट। टास्क से बाँटें। साझा अंश इंक्लूड हो सकते हैं; सब कुछ साझा करना टेस्ट-अयोग्य बनाता है।
संक्षेप
प्रोडक्ट इंजीनियरों के लिए प्रॉम्प्ट इंजीनियरिंग इंटरफेस डिज़ाइन प्लस टेस्टिंग अनुशासन है।
प्रॉम्प्ट में कॉन्ट्रैक्ट रखें। फ्यू-शॉट से एज केस सिखाएँ। आज़ाद चुनाव सीमित करें। फिक्स्चर और प्रोडक्शन ओवरराइड दर से मापें। मतिभ्रम, इंजेक्शन, स्कीमा ड्रिफ्ट और रिट्राई लेटेंसी देखें। सब कुछ वर्शन करें।
यह करें तो प्रॉम्प्ट काम थिएटर नहीं रहता। स्टैक की एक और भरोसेमंद परत बनता है: कम चमकदार, जाँचने लायक, और शिप करने लायक।