मानक रेट्रोस्पेक्टिव उन उत्पादों के लिए डिज़ाइन नहीं किए गए थे जहां मूल व्यवहार गैर-नियतात्मक है, अप्रत्याशित तरीकों से उपयोग के साथ लागत बढ़ती है, और पिछले महीने के सावधानीपूर्वक ट्यून किए गए संकेत ख़राब हो सकते हैं क्योंकि मॉडल प्रदाता ने एक अपडेट भेजा है।
यदि आप LLMs के साथ निर्माण कर रहे हैं, तो आपको रेट्रोस्पेक्टिव की आवश्यकता है जो AI उत्पादों के सफल और विफल होने के विशिष्ट तरीकों को ध्यान में रखता है। यहां बताया गया है कि हर रेट्रो को तीन घंटे की मेट्रिक्स समीक्षा में बदले बिना ऐसा कैसे किया जाए।
आपका सामान्य रेट्रो प्रारूप छोटा क्यों हो जाता है
पारंपरिक रेट्रोस्पेक्टिव एक पूर्वानुमानित मॉडल के आसपास बनाए गए हैं: आप कोड लिखते हैं, आप इसे शिप करते हैं, यह वही करता है जो आपने लिखा है। दिलचस्प समस्याएं प्रक्रिया, संचार और प्राथमिकताओं के बारे में हैं।
एआई उत्पाद उस मॉडल को कई तरीकों से तोड़ते हैं:
समान इनपुट के बीच आउटपुट अलग-अलग होते हैं। एक ही उपयोगकर्ता संदेश के साथ एक ही संकेत कॉल के दौरान अलग-अलग गुणवत्ता वाले परिणाम उत्पन्न कर सकता है। इसका मतलब है "यह मेरी मशीन पर काम करता है" का विस्तार "जब मैंने इसे पांच मिनट पहले परीक्षण किया था तो यह काम करता था।"
विफलता मोड नए हैं। मतिभ्रम, शीघ्र इंजेक्शन, पूर्वाग्रह प्रवर्धन, और संदर्भ विंडो अतिप्रवाह पारंपरिक बग श्रेणियों पर मैप नहीं करते हैं। इन पर चर्चा करने के लिए आपकी टीम को विशिष्ट शब्दावली और रूपरेखा की आवश्यकता है।
लागत उपयोग-आनुपातिक होती है और अनुमान लगाना कठिन होता है। एक पारंपरिक सुविधा को बनाने में उतनी ही लागत आती है और फिर यह आपके मौजूदा बुनियादी ढांचे पर चलती है। एक LLM सुविधा की लागत प्रत्येक उपयोगकर्ता इंटरैक्शन के साथ बढ़ती है, और एक वायरल क्षण आपका बजट रातों-रात बिगाड़ सकता है।
गुणवत्ता अदृश्य रूप से ख़राब हो जाती है। आपके प्रदाता का एक मॉडल अपडेट बिना किसी सूचना के आउटपुट गुणवत्ता को सूक्ष्मता से बदल सकता है। आपके संकेत एक विशिष्ट मॉडल संस्करण के लिए अनुकूलित किए गए थे - वह अनुकूलन स्थानांतरित नहीं हो सकता है।
इसमें से कोई भी मतलब रेट्रोस्पेक्टिव कम महत्वपूर्ण नहीं है। इसका मतलब है कि उन्हें अलग-अलग चीजों को देखने की जरूरत है।
एआई उत्पाद रेट्रो के लिए चार लेंस
क्लासिक "क्या अच्छा हुआ/क्या नहीं हुआ/कार्रवाई आइटम" संरचना के बजाय, अपने एआई उत्पाद ⟦रेट्रो⟧ को चार अलग-अलग लेंसों के आसपास व्यवस्थित करें। प्रत्येक समस्या की एक अलग श्रेणी सामने आती है।
लेंस 1: मॉडल प्रदर्शन
यह इस बारे में है कि क्या AI तकनीकी स्तर पर अपना काम कर रहा है।
चर्चा के लिए प्रश्न:
- हमारे मूल्यांकन स्कोर कैसे चलन में हैं? क्या हम सही चीज़ों को माप रहे हैं?
- क्या हमने गुणवत्ता में बदलाव देखा है जो मॉडल अपडेट या त्वरित परिवर्तनों से संबंधित है?
- इस अवधि में हमारी सबसे खराब विफलता के मामले क्या हैं? उनमें क्या समानता है?
- क्या ऐसे उपयोग के मामले हैं जहां मॉडल लगातार संघर्ष करता है कि हमें अलग तरीके से संबोधित करना चाहिए?
आपको कमरे में क्या चाहिए: मूल्यांकन परिणाम, त्रुटि लॉग, खराब आउटपुट के उदाहरण जो उपयोगकर्ताओं ने रिपोर्ट किए हैं या QA द्वारा चिह्नित किए गए हैं।
लेंस 2: शीघ्र इंजीनियरिंग प्रभावशीलता
संकेत आपके उत्पाद की नियंत्रण सतह हैं। वे समर्पित ध्यान देने योग्य हैं।
चर्चा के लिए प्रश्न:
- कौन से त्वरित बदलावों से वास्तव में परिणामों में सुधार हुआ, और कौन से एकतरफा कदम थे?
- क्या हम प्रॉम्प्ट संस्करणों को व्यवस्थित रूप से ट्रैक कर रहे हैं, या यह तदर्थ है?
- क्या हमारे पास ऐसे संकेत हैं जो भंगुर हैं - वे काम करते हैं लेकिन मामूली इनपुट बदलाव के साथ टूट जाते हैं?
- अन्य इंजीनियरिंग कार्यों की तुलना में हम त्वरित पुनरावृत्ति पर कितना समय खर्च कर रहे हैं? क्या वह अनुपात सही है?
आपको कमरे में क्या चाहिए: त्वरित परिवर्तनों और उनके मापा प्रभाव का एक लॉग। यदि आपके पास यह नहीं है, तो उस ट्रैकिंग सिस्टम को स्थापित करना आपका पहला कार्य है।
लेंस 3: उपयोगकर्ता अनुभव
मॉडल तकनीकी रूप से अच्छा प्रदर्शन कर सकता है जबकि उपयोगकर्ता अभी भी निराश हैं।
चर्चा के लिए प्रश्न:
- उपयोगकर्ता AI-जनरेटेड आउटपुट पर कैसी प्रतिक्रिया दे रहे हैं? फीडबैक क्या कहता है?
- उपयोगकर्ता AI सुझावों को कहां ओवरराइड कर रहे हैं, संपादित कर रहे हैं या अनदेखा कर रहे हैं? वे सिग्नल-समृद्ध क्षण हैं।
- क्या AI बिजली उपयोगकर्ताओं के लिए मूल्य जोड़ रहा है लेकिन नए उपयोगकर्ताओं को भ्रमित कर रहा है, या इसके विपरीत?
- क्या विश्वास संबंधी कोई समस्या है? क्या उपयोगकर्ता AI द्वारा उत्पादित हर चीज की दोबारा जांच कर रहे हैं, या वे उस पर जरूरत से ज्यादा भरोसा कर रहे हैं?
आपको कमरे में क्या चाहिए: उपयोगकर्ता प्रतिक्रिया, उपयोग विश्लेषण (विशेष रूप से ड्रॉप-ऑफ़ और संपादन दरें), और एआई सुविधाओं से संबंधित समर्थन टिकट।
लेंस 4: लागत और स्थिरता
यदि आपकी AI सुविधाएं आर्थिक रूप से टिकाऊ नहीं हैं, तो गुणवत्ता और UX कोई मायने नहीं रखते।
चर्चा के लिए प्रश्न:
- प्रत्येक AI सुविधा के लिए प्रति उपयोगकर्ता इंटरैक्शन हमारी वास्तविक लागत क्या है?
- हमारे विकास अनुमानों के साथ लागत का पैमाना कैसा है? क्या यह रैखिक है, या क्या हमारे पास लागत एम्पलीफायर हैं?
- क्या सार्थक गुणवत्ता प्रभाव के बिना लागत कम करने के अवसर हैं? (कैशिंग, छोटे संकेत, सरल कार्यों के लिए छोटे मॉडल।)
- क्या हम जो टोकन खर्च कर रहे हैं उससे हमें मूल्य मिल रहा है, या क्या हम फूले हुए संकेत और प्रसंस्करण आउटपुट भेज रहे हैं जिनका हम उपयोग नहीं करते हैं?
आपको कमरे में क्या चाहिए: फीचर, लागत-प्रति-इंटरैक्शन गणना और उपयोग वृद्धि के रुझान के आधार पर बिलिंग डेटा।
बैठक चलाना
अवधि: 60 मिनट. यदि आपकी टीम अनुशासित है तो आप इसे 45 में कर सकते हैं, लेकिन इसे 30 में समेटने का प्रयास न करें।
आवृत्ति: यदि आप एआई सुविधाओं पर सक्रिय रूप से पुनरावृत्ति कर रहे हैं तो हर दो सप्ताह में। मासिक एक बार चीजें स्थिर हो जाती हैं। अगर कुछ भी सार्थक नहीं बदला है तो इसे सिर्फ इसलिए न चलाएं क्योंकि यह कैलेंडर पर है।
वहां कौन होना चाहिए: उत्पाद प्रबंधक, इंजीनियर जो एआई सुविधाओं पर काम करते हैं, और कोई भी जो मॉडल आउटपुट या उपयोगकर्ता प्रतिक्रिया की समीक्षा करता है। आपको पूरी कंपनी की ज़रूरत नहीं है.
वह प्रारूप जो काम करता है:
डेटा वॉकथ्रू (10 मिनट): कोई व्यक्ति पिछले रेट्रो के बाद से प्रमुख मेट्रिक्स प्रस्तुत करता है। अभी तक कोई राय नहीं - केवल संख्याएँ। यह कमरे में सबसे ऊंचे स्वर वाले व्यक्ति को उनके किस्से पर बातचीत शुरू करने से रोकता है।
चार-लेंस चर्चा (35 मिनट): प्रत्येक लेंस पर गौर करें। आपको प्रत्येक पर समान समय खर्च करने की आवश्यकता नहीं है - कुछ अवधियों में, लागत बड़ा विषय होगा; अन्य समय में, गुणवत्ता प्रतिगमन हावी रहेगा। डेटा को यह मार्गदर्शन करने दें कि आप कहां ध्यान केंद्रित करते हैं।
कार्य आइटम (15 मिनट): विशिष्ट बनें। "त्वरित गुणवत्ता में सुधार करें" कोई कार्रवाई आइटम नहीं है। "V7 उम्मीदवार के विरुद्ध वर्तमान सारांश संकेत की तुलना करते हुए A/B परीक्षण चलाएँ, ROUGE स्कोर और उपयोगकर्ता संपादन दरों को मापें, अगले रेट्रो पर रिपोर्ट करें" एक कार्रवाई आइटम है।
ट्रैकिंग के लायक मेट्रिक्स (और कुछ जो नहीं हैं)
दर्जनों एआई मेट्रिक्स पर नज़र रखने वाला एक विस्तृत डैशबोर्ड बनाने का प्रलोभन है। इसका प्रतिरोध करें। मेट्रिक्स के एक छोटे सेट से शुरुआत करें जो वास्तव में जानकारीपूर्ण हो और केवल तभी जोड़ें जब आपको किसी विशिष्ट प्रश्न का उत्तर देने की आवश्यकता हो।
उच्च-मूल्य वाले मेट्रिक्स:
- कार्य सफलता दर — क्या AI ने वह पूरा किया जो उपयोगकर्ता ने पूछा था? यह सबसे महत्वपूर्ण मीट्रिक है, और इसे मापना अक्सर सबसे कठिन होता है। यहां तक कि एक रफ प्रॉक्सी (जैसे "उपयोगकर्ता ने संपादन के बिना आउटपुट स्वीकार कर लिया") कुछ भी नहीं से बेहतर है।
- प्रति सफल इंटरैक्शन लागत - न केवल प्रति कॉल लागत, बल्कि प्रति परिणाम लागत जिससे वास्तव में उपयोगकर्ता को मदद मिली। यह आपका ध्यान केवल वॉल्यूम पर नहीं, बल्कि वैल्यू पर केंद्रित रखता है।
- उपयोगकर्ता संपादन दर — उपयोगकर्ता AI-जनरेटेड सामग्री को कितनी बार संशोधित करते हैं? उच्च संपादन दर आवश्यक रूप से खराब नहीं है (इसका मतलब यह हो सकता है कि उपयोगकर्ता सक्रिय रूप से संलग्न हैं), लेकिन बढ़ती संपादन दर से पता चलता है कि गुणवत्ता में गिरावट आ रही है।
- p95 पर विलंबता - औसत विलंबता नहीं, जो दुखद अनुभवों को छुपाती है। 95वाँ प्रतिशत आपको बताता है कि आपके सबसे बदकिस्मत-लेकिन-नहीं-चरम उपयोगकर्ता किससे निपटते हैं।
मेट्रिक्स जो उपयोगी लगते हैं लेकिन अक्सर उपयोगी नहीं होते:
- कच्ची टोकन गिनती - आपको मात्रा बताती है, मूल्य नहीं। बिलिंग के लिए दिलचस्प है लेकिन उत्पाद निर्णयों के लिए नहीं।
- संकेत लंबाई - लंबी लंबाई स्वचालित रूप से खराब नहीं होती है और छोटी स्वचालित रूप से बेहतर नहीं होती है। आउटपुट की गुणवत्ता से निर्णय लें, लंबाई से नहीं।
- आइसोलेशन में मॉडल संस्करण की तुलना - अमूर्त बेंचमार्क में GPT-4o बनाम क्लाउड 3.5 की तुलना करने से आपको अपने विशिष्ट उपयोग के मामले के बारे में बहुत कम पता चलता है। केवल अपने वास्तविक कार्यों की तुलना अपने वास्तविक मूल्यांकन मानदंडों से करें।
कठिन बातचीत से निपटना
AI उत्पाद रेट्रो में ऐसे असहज विषय सामने आते हैं जिनसे टीमें अक्सर बचती हैं:
"हम वास्तव में नहीं जानते कि एआई अच्छा है या नहीं।" यदि आपकी टीम के पास आउटपुट गुणवत्ता का मूल्यांकन करने का कोई व्यवस्थित तरीका नहीं है, तो इसे स्वीकार करें। एक्शन आइटम एक न्यूनतम मूल्यांकन ढांचा भी बनाना है - अपेक्षित आउटपुट के साथ परीक्षण मामलों का एक सेट जिसे आप हर बदलाव के बाद चलाते हैं।
"हम बहुत अधिक खर्च कर रहे हैं और हमें यकीन नहीं है कि यह इसके लायक है।" यह एक उत्पाद प्रश्न है, तकनीकी नहीं। क्या AI सुविधा प्रतिधारण, रूपांतरण, या कुछ अन्य व्यावसायिक परिणाम ला रही है? यदि आप वह रेखा नहीं खींच सकते हैं, तो हो सकता है कि आप एआई सुविधाओं का निर्माण कर रहे हों क्योंकि वे मूल्यवान होने के बजाय प्रभावशाली हैं।
"मॉडल कभी-कभी कुछ समस्याग्रस्त करता है और हम निश्चित नहीं हैं कि इसे कैसे रोका जाए।" सुरक्षा संबंधी मुद्दों पर कागजी कार्रवाई न करें। यदि मॉडल कभी-कभी पक्षपातपूर्ण, हानिकारक, या भ्रामक सामग्री उत्पन्न करता है, तो यह सर्वोच्च प्राथमिकता वाली कार्रवाई है, न कि कोई "ज्ञात समस्या" जिसे आप दूर कर देते हैं।
"हमारी त्वरित इंजीनियरिंग अनुमान लगाने जैसी लगती है।" ऐसा अक्सर होता है, खासकर शुरुआती दिनों में। अधिक कठोरता स्थापित करने के लिए रेट्रो एक अच्छी जगह है: संकेतों के लिए संस्करण नियंत्रण, A/B परीक्षण प्रोटोकॉल, और स्पष्ट मूल्यांकन मानदंड।
रेट्रो अंतर्दृष्टि को उत्पाद निर्णयों से जोड़ना
इन रेट्रोस्पेक्टिव का उद्देश्य बदलावों की सूची तैयार करना नहीं है। यह बड़े उत्पाद निर्णयों को सूचित करने के लिए है:
- क्या हमें इस AI सुविधा में और अधिक निवेश करना चाहिए, या क्या यह एक मृत अंत है?
- क्या हम इस उपयोग के मामले के लिए सही मॉडल का उपयोग कर रहे हैं, या हमें विकल्पों के साथ प्रयोग करना चाहिए?
- क्या हमारा वर्तमान दृष्टिकोण स्केलेबल है, या लागत 10x उपयोगकर्ताओं पर हमारे मार्जिन को खा जाएगी?
- क्या हमें एआई क्षमताओं को जोड़ना चाहिए, या क्या हमें मौजूदा एआई क्षमताओं को दोगुना करना चाहिए?
यदि आपका रेट्रो इस प्रकार के निर्णयों को प्रभावित नहीं करता है, तो यह सिर्फ ⟦रेट्रो⟧ के कपड़े पहनकर एक स्टेटस मीटिंग है।
<घंटा/>NextRetro निःशुल्क आज़माएं — अपने अगले AI उत्पाद रेट्रोस्पेक्टिव में मॉडल, प्रॉम्प्ट, UX और लागत के लिए समर्पित कॉलम के साथ चार-लेंस प्रारूप का उपयोग करें।
<घंटा/>अंतिम अद्यतन: फरवरी 2026
पढ़ने का समय: 7 मिनट
