आपकी टीम के पास पूरे कोडबेस में संकेत बिखरे हुए हैं। कुछ कॉन्फ़िग फ़ाइलों में हैं। कुछ हार्डकोडेड स्ट्रिंग हैं। कुछ महत्वपूर्ण व्यक्ति Google दस्तावेज़ में रहते हैं जिसे एक व्यक्ति बनाए रखता है। किसी को याद नहीं है कि सारांश सुविधा के लिए सिस्टम प्रॉम्प्ट क्यों कहता है "एक सहायक ब्रिटिश लाइब्रेरियन के रूप में प्रतिक्रिया दें" - लेकिन उस वाक्यांश को हटाने से आउटपुट खराब हो जाता है, इसलिए यह बना रहता है।
अधिकांश टीमें इस प्रकार संकेतों का प्रबंधन करती हैं, और यह लगभग 2005 में संस्करण नियंत्रण के बिना कोड लिखने के बराबर है। यह तब तक काम करता है जब तक यह काम नहीं करता है, और जब यह काम करना बंद कर देता है, तो आपको पता नहीं चलता कि क्या बदल गया है या इसे कैसे ठीक किया जाए।
प्रॉम्प्ट इंजीनियरिंग रेट्रोस्पेक्टिव LLM इंटरैक्शन में वही अनुशासन लाती है जो इंजीनियरिंग रेट्रोस्पेक्टिव सॉफ्टवेयर विकास में लाती है: व्यवस्थित समीक्षा, साझा शिक्षण और वृद्धिशील सुधार। यहां बताया गया है कि वास्तव में इसे कैसे करना है।
तदर्थ संकेत के साथ समस्या
अधिकांश टीमें एक चक्र के माध्यम से संकेत विकसित करती हैं जो इस तरह दिखता है: कोई व्यक्ति संकेत लिखता है, कुछ उदाहरणों के विरुद्ध उसका परीक्षण करता है, उसे भेजता है और आगे बढ़ता है। जब आउटपुट गुणवत्ता ख़राब हो जाती है या एक नया विफलता मोड प्रकट होता है, तो कोई विशिष्ट विफलता मामले के आधार पर संकेत को बदल देता है, शायद प्रक्रिया में तीन अन्य मामलों को तोड़ देता है, और चक्र दोहराता है।
इस दृष्टिकोण से जुड़े मुद्दे:
कोई इतिहास नहीं.जब आप प्रॉम्प्ट बदलते हैं, तो पुराना संस्करण ख़त्म हो जाता है। यदि नया संस्करण ख़राब है, तो आप आसानी से वापस नहीं आ सकते। यदि कोई पूछता है "संकेत ऐसा क्यों कहता है?", तो कोई नहीं जानता।
कोई साझा सीख नहीं.जिस व्यक्ति ने यह पता लगाया कि तर्क संकेत में "कदम दर कदम सोचें" जोड़ने से ध्यान देने योग्य अंतर से सटीकता में सुधार हुआ है, वह उस अंतर्दृष्टि को साझा नहीं करता है। अगला संकेत लिखने वाला व्यक्ति शुरू से वही सबक सीखता है।
कोई व्यवस्थित परीक्षण नहीं.जो भी उदाहरण मन में आते हैं, उनके विरुद्ध संकेतों का परीक्षण किया जाता है, जो आमतौर पर आसान मामले होते हैं। एज मामले, प्रतिकूल इनपुट और वितरण बदलाव तब तक अप्रयुक्त रहते हैं जब तक वे उत्पादन में विफल नहीं हो जाते।
कोई माप नहीं."आउटपुट बेहतर दिखता है" सबसे आम मूल्यांकन पद्धति है। बेहतर कैसे? किसकी तुलना में? किसके द्वारा मापा गया? निरंतर मूल्यांकन के बिना, आप यह नहीं बता सकते कि परिवर्तन वास्तव में सुधार हैं या नहीं।
एक नियमित संकेत रेट्रोस्पेक्टिव इन सभी चार समस्याओं का समाधान करता है।
प्रॉम्प्ट में क्या समीक्षा करें रेट्रोस्पेक्टिव
अपना साक्ष्य एकत्र करें
⟦रेट्रो⟧ से पहले, इकट्ठा करें:
उत्पादन विफलता.कोई भी उदाहरण जहां LLM-संचालित सुविधा ने खराब आउटपुट उत्पन्न किया जिसे उपयोगकर्ता ने देखा। इनपुट, प्रॉम्प्ट और आउटपुट कैप्चर करें। यदि आपके पास उपयोगकर्ता प्रतिक्रिया (अंगूठे नीचे, शिकायतें, सुधार) हैं, तो उसे शामिल करें।
पिछले रेट्रो के बाद से शीघ्र परिवर्तन।बदलाव के संकेत क्या थे, बदलाव के पीछे मंशा क्या थी और उसके बाद क्या हुआ? यदि आप अपने संकेतों को संस्करण-नियंत्रित कर रहे हैं (आपको होना चाहिए), तो यह एक अलग समीक्षा है। यदि आप नहीं हैं, तो यह आपके रेट्रो का पहला एक्शन आइटम है।
गुणवत्ता मीट्रिक रुझान.यदि आप स्वचालित मूल्यांकन चला रहे हैं (इस पर अधिक जानकारी नीचे दी गई है), तो रुझान लाएँ। क्या हालात सुधर रहे हैं? बदतर हो रही? समतल?
लागत और विलंबता डेटा.संकेत सीधे तौर पर दोनों को प्रभावित करते हैं। एक वर्बोज़ सिस्टम प्रॉम्प्ट जो एक छोटे अंतर से गुणवत्ता में सुधार करता है लेकिन आपके टोकन उपयोग को दोगुना कर देता है, स्पष्ट रूप से चर्चा करने लायक एक समझौता है।
बातचीत
एक अच्छा संकेत ⟦रेट्रो⟧ में तीन प्रश्न शामिल हैं:
1. हमारे संकेत कहाँ विफल हो रहे हैं, और क्यों?
अपनी असफलताओं को वर्गीकृत करें. सामान्य श्रेणियाँ:
- अनुदेश निम्नलिखित: मॉडल ने वह नहीं किया जो प्रॉम्प्ट ने पूछा था। आमतौर पर इसका मतलब है कि निर्देश अस्पष्ट है या संकेत के किसी अन्य भाग का खंडन करता है।
- प्रारूप का उल्लंघन: जब आप सादा पाठ चाहते थे तो मॉडल JSON लौटाता था, या इसके विपरीत। आमतौर पर स्पष्ट प्रारूप विनिर्देशों और उदाहरणों के साथ इसे ठीक किया जा सकता है।
- माया: मॉडल द्वारा उत्पन्न जानकारी प्रदत्त संदर्भ द्वारा समर्थित नहीं है। यह एक त्वरित समस्या (कमजोर ग्राउंडिंग निर्देश) या एक मॉडल सीमा हो सकती है।
- स्वर/शैली का बहाव: आउटपुट इच्छित से भिन्न लगता है। अक्सर ऐसा होता है जब संकेत लंबे होते हैं और शैली निर्देश दब जाते हैं।
- एज केस विफलता: प्रॉम्प्ट विशिष्ट इनपुट के लिए काम करता है लेकिन असामान्य इनपुट पर टूट जाता है। यहीं पर व्यवस्थित परीक्षण की कमी सबसे अधिक खलती है।
प्रत्येक विफलता श्रेणी के लिए, पूछें: क्या यह एक त्वरित समस्या है, एक मॉडल समस्या है, या एक इनपुट समस्या है? प्रत्येक के लिए फिक्स अलग है.
2. हमने इस मॉडल को प्रेरित करने के बारे में क्या सीखा है?
हर मॉडल में विचित्रताएं होती हैं। GPT-4 क्लाउड की तुलना में एक ही संकेत पर अलग-अलग प्रतिक्रिया देता है, और दोनों अपडेट के साथ व्यवहार बदलते हैं। आपकी टीम दैनिक कार्य के माध्यम से इन विचित्रताओं के बारे में ज्ञान एकत्र करती है - ⟦रेट्रो⟧ वह जगह है जहां उस ज्ञान को साझा किया जाता है और दस्तावेजित किया जाता है।
पकड़ने के लिए उपयोगी चीज़ें:
- तकनीकें जो आउटपुट में विश्वसनीय रूप से सुधार करती हैं (और किस प्रकार के कार्यों के लिए)
- ऐसे दृष्टिकोण जिनसे ऐसा लग रहा था कि उन्हें काम करना चाहिए लेकिन नहीं किया
- प्रदाता अद्यतन के बाद मॉडल व्यवहार बदल जाता है
- ऐसे संकेत देने वाले पैटर्न जो आपके विशिष्ट उपयोग के मामलों के लिए अच्छा काम करते हैं
यह एक टीम ज्ञान आधार बनाता है जो सभी को समान पाठों को दोबारा खोजने से रोकता है।
3. हमें आगे क्या बदलना या परीक्षण करना चाहिए?
विफलताओं और सीखों के आधार पर विशिष्ट प्रयोगों की पहचान करें। अच्छे प्रयोग हैं:
- दायरा सीमित करें (एक समय में एक चीज़ बदलें)
- मापने योग्य (परिभाषित करें कि परीक्षण से पहले "बेहतर" का क्या अर्थ है)
- टाइम-बॉक्स्ड (एक विशिष्ट अवधि या मूल्यांकन की संख्या के लिए चलाएं)
उदाहरण: "हम परीक्षण करेंगे कि ग्राहक सेवा प्रॉम्प्ट में वांछित आउटपुट प्रारूप के दो उदाहरण जोड़ने से प्रारूप उल्लंघन 12% से घटकर 5% से कम हो जाता है, जो 200 से अधिक उत्पादन प्रश्नों में मापा जाता है।"
एक त्वरित प्रबंधन अभ्यास का निर्माण
रेट्रोस्पेक्टिव तब अधिक प्रभावी होते हैं जब आपके पास बुनियादी त्वरित प्रबंधन होता है। शुरू करने के लिए आपको फैंसी टूलींग की आवश्यकता नहीं है - बस कुछ अभ्यास।
संस्करण अपने संकेतों पर नियंत्रण रखें
संकेतों को कोड की तरह समझें. उन्हें अपने भंडार में संग्रहीत करें, पीआर और टैग संस्करणों में परिवर्तनों की समीक्षा करें। यह आपको इतिहास, रोलबैक क्षमता और समीक्षा निरीक्षण प्रदान करता है। यदि त्वरित परिवर्तन से गुणवत्ता में गिरावट आती है, तो आप देख सकते हैं कि वास्तव में क्या परिवर्तन हुआ है और उसे वापस कर सकते हैं।
कई संकेतों वाली टीमों के लिए, एक समर्पित निर्देशिका संरचना पर विचार करें:
prompts/
summarization/
system.txt
few-shot-examples.json
customer-service/
system.txt
escalation-rules.txt
classification/
system.txt
label-definitions.json
एक मूल्यांकन सेट बनाएं
प्रत्येक प्रमुख संकेत के लिए, परीक्षण मामलों का एक सेट बनाए रखें: इनपुट-आउटपुट जोड़े जहां आप जानते हैं कि अच्छा आउटपुट कैसा दिखता है। इसे बहुत बड़ा करने की आवश्यकता नहीं है - प्रति प्रॉम्प्ट 20-50 मामले जो विशिष्ट उपयोग, किनारे के मामलों और ज्ञात विफलता मोड को कवर करते हैं।
जब भी आप संकेत बदलें तो अपना मूल्यांकन सेट चलाएँ। यह उत्पादन तक पहुंचने से पहले प्रतिगमन को पकड़ लेता है। शुरुआत में इसे बनाने में समय लगता है, लेकिन उत्पादन विफलताओं को डीबग करने की तुलना में नाटकीय रूप से अधिक समय की बचत होती है।
अपने निर्णयों का दस्तावेजीकरण करें
जब आप कोई त्वरित बदलाव करते हैं, तो एक संक्षिप्त नोट लिखें: समस्या क्या थी, आपने क्या बदलाव किया और आपने इससे मदद की उम्मीद क्यों की। यह तीन महीने बाद तक ओवरहेड जैसा लगता है जब आप एक प्रॉम्प्ट को देख रहे होते हैं और सोच रहे होते हैं कि इसमें एक प्रतीत होता है कि यादृच्छिक निर्देश क्यों शामिल है जो महत्वपूर्ण साबित होता है।
संकेत रेट्रोस्पेक्टिव प्रारूप जो काम करते हैं
जरूरी नहीं कि हर रेट्रो एक जैसा हो। यहां दो प्रारूप हैं जो विभिन्न ताल पर अच्छा काम करते हैं:
त्वरित समीक्षा (30 मिनट, द्वि-साप्ताहिक)
तेजी से पुनरावृत्ति करने वाली टीमों के लिए। पिछले सत्र से उत्पादन विफलताओं की समीक्षा करें, किए गए किसी भी त्वरित परिवर्तन पर चर्चा करें, प्रत्येक एक त्वरित अंतर्दृष्टि साझा करें, और अगले दो सप्ताह के लिए सर्वोच्च प्राथमिकता वाला प्रयोग चुनें। इसे चुस्त और क्रियान्वित रखें।
डीप डाइव (90 मिनट, मासिक)
जब आपको पीछे हटने और बड़ी तस्वीर देखने की ज़रूरत हो। सभी संकेतों में गुणवत्ता मेट्रिक्स और रुझानों की समीक्षा करें। सबसे खराब प्रदर्शन करने वाला प्रॉम्प्ट चुनें और गहन विश्लेषण करें: विफलताओं पर विचार करें, मूल कारण पर चर्चा करें, दृष्टिकोणों पर विचार-मंथन करें और एक उचित प्रयोग डिज़ाइन करें। अपनी प्रॉम्प्ट लाइब्रेरी और दस्तावेज़ीकरण की पुरानीता के लिए भी समीक्षा करें - क्या कोई प्रॉम्प्ट पुराना या अप्रयुक्त है?
घटना की समीक्षा (तदर्थ)
जब त्वरित विफलता वास्तविक उपयोगकर्ता-सामना वाली घटना का कारण बनती है, तो कुछ दिनों के भीतर एक केंद्रित समीक्षा करें। क्या हुआ, संकेत विफल क्यों हुआ, हमारे परीक्षण ने इसे क्यों नहीं पकड़ा, और विफलता के इस वर्ग को रोकने के लिए हम अपने मूल्यांकन सेट में क्या जोड़ते हैं?
सामान्य ख़तरे
अति-इंजीनियरिंग संकेत.लंबे संकेत हमेशा बेहतर नहीं होते. आपके द्वारा जोड़ा गया प्रत्येक निर्देश हर दूसरे निर्देश के साथ अप्रत्याशित तरीकों से इंटरैक्ट कर सकता है। यदि आपका प्रॉम्प्ट 500 शब्दों से अधिक है, तो विचार करें कि क्या आप एक प्रॉम्प्ट में बहुत अधिक करने का प्रयास कर रहे हैं और इसे एक श्रृंखला में तोड़ देना चाहिए।
गलत मीट्रिक के लिए अनुकूलन।एक प्रॉम्प्ट जो स्वचालित मेट्रिक्स पर अच्छा स्कोर करता है लेकिन ऐसे आउटपुट उत्पन्न करता है जो उपयोगकर्ताओं को अनुपयोगी लगते हैं, एक अच्छा प्रॉम्प्ट नहीं है। अपनी प्रक्रिया में मानवीय मूल्यांकन को शामिल करें, न कि केवल स्वचालित स्कोरिंग को।
लागत की अनदेखी.आपके टोकन उपयोग को दोगुना करने वाले त्वरित सुधार गुणवत्ता लाभ के लायक नहीं हो सकते हैं। गुणवत्ता के साथ-साथ प्रति क्वेरी लागत को ट्रैक करें और स्पष्ट रूप से ट्रेडऑफ़ बनाएं।
कारणों के बजाय लक्षणों को ठीक करना।यदि आप नए विफलता मोड के लिए एक ही प्रॉम्प्ट को पैच करना जारी रखते हैं, तो संभवतः प्रॉम्प्ट को किसी अन्य बैंड-सहायता के बजाय रीडिज़ाइन की आवश्यकता होती है। आपका रेट्रोस्पेक्टिव डेटा इस पैटर्न को दिखाएगा - एक संकेत जो कई रेट्रोज़ में विफलता सूचियों में दिखाई देता है, उस पर अधिक मौलिक ध्यान देने की आवश्यकता है।
प्रतिकूल इनपुट के साथ परीक्षण नहीं करना।आपके उपयोगकर्ता वे चीजें करेंगे जिनकी आपको अपेक्षा नहीं है। आपके ⟦रेट्रो⟧ में समय-समय पर इस बात की समीक्षा शामिल होनी चाहिए कि जब प्रॉम्प्ट को असामान्य, शत्रुतापूर्ण या दायरे से बाहर इनपुट प्राप्त होता है तो क्या होता है। यह जानने के लिए किसी उत्पादन घटना की प्रतीक्षा न करें कि आपके प्रॉम्प्ट में कोई रेलिंग नहीं है।
शुरू करना
शुरू करने के लिए आपको हर चीज़ का पता लगाने की ज़रूरत नहीं है। यहां एक न्यूनतम पहला कदम है:
- अपनी सबसे महत्वपूर्ण LLM-संचालित सुविधा चुनें।
- 10 हाल की विफलताएँ (खराब आउटपुट, उपयोगकर्ता शिकायतें, कुछ भी इष्टतम से कम) एकत्र करें।
- अपनी टीम के साथ यह वर्गीकरण करते हुए 30 मिनट बिताएँ कि प्रत्येक टीम असफल क्यों हुई।
- सबसे आम विफलता पैटर्न की पहचान करें और इसे संबोधित करने के लिए एक प्रयोग डिज़ाइन करें।
- प्रयोग चलाएँ और दो सप्ताह में परिणामों की समीक्षा करें।
यह आपका पहला संकेत रेट्रोस्पेक्टिव है। इसे बार-बार करें और आप मांसपेशियों का निर्माण करेंगे। सर्वोत्तम एआई आउटपुट गुणवत्ता वाली टीमें सबसे चतुर संकेतों वाली नहीं हैं - वे वे हैं जो व्यवस्थित रूप से अपनी विफलताओं से सीखते हैं और कभी भी एक ही गलती दो बार नहीं करते हैं।
NextRetro निःशुल्क आज़माएँ- त्वरित विफलताओं को श्रेणियों में वर्गीकृत करें, प्राथमिकताओं पर वोट करें और पूरे स्प्रिंट में सुधार प्रयोगों को ट्रैक करें।
आखरी अपडेट:फरवरी 2026
पढ़ने का समय:7 मिनट
