Skip to main content
AI9 min read

शिप करने से पहले AI सुविधाओं का मूल्यांकन कैसे करें

AI सुविधाओं के लिए एक व्यावहारिक मूल्यांकन चक्र: वादा परिभाषित करें, विफलता सेट बनाएं, सामान्य मामलों का परीक्षण करें, और सिस्टम के विश्वास अर्जित करने तक एक मानव को लूप में रखें।

Part ofAI Engineering->
By Jason TeixeiraJune 16, 2026
AI EvaluationProduct EngineeringQALLMsReliability
Share:
On this page

कोई AI फीचर तब पूरा नहीं होता जब वह डेमो में काम करता है।

यही जाल है। आप उससे तीन सरल प्रश्न पूछते हैं, वह ढाई का जवाब देता है, हर कोई भविष्य की झलक देखता है, और अचानक प्रोडक्ट रोडमैप पर "AI असिस्टेंट" नाम का एक फीचर उस जगह बैठ जाता है जहाँ एक स्पेक होना चाहिए।

मुझे प्रक्रिया के उस संस्करण पर भरोसा नहीं है। मुझे धीमे संस्करण पर भरोसा है: वादे का नाम बताएं, विफलता के मामले लिखें, उबाऊ रास्ते का परीक्षण करें, और एक इंसान को पास रखें जब तक सिस्टम यह साबित न कर दे कि वह व्यवहार कर सकता है।

AI मूल्यांकन लूपवादा -> प्रमाण
वादाविफलताएंसमीक्षाशिप

फीचर का एक बार मूल्यांकन नहीं होता। यह एक लूप में चलता है: वादे को परिभाषित करें, विफलता सेट बनाएं, वास्तविक आउटपुट की समीक्षा करें, और तभी तय करें कि क्या शिप किया जा सकता है।

वादे से शुरू करें

पहला प्रश्न यह नहीं है "हमें कौन सा मॉडल इस्तेमाल करना चाहिए?"

पहला प्रश्न है: इस फीचर के जवाब देने के बाद उपयोगकर्ता को क्या विश्वास करने की अनुमति है?

यह वाक्य मायने रखता है। यदि फीचर किसी दस्तावेज़ का सारांश प्रस्तुत करता है, तो उपयोगकर्ता मानता है कि सारांश विश्वसनीय है। यदि यह सपोर्ट रिप्लाई का ड्राफ्ट तैयार करता है, तो उपयोगकर्ता मानता है कि यह कोई रिफंड पॉलिसी नहीं गढ़ेगा। यदि यह ट्रेडिंग सिग्नल समझाता है, तो उपयोगकर्ता मानता है कि यह दोस्ताना लहजे में छिपी वित्तीय सलाह नहीं है।

वादे को एक पंक्ति में लिखें:

  • "यह फीचर अनुरोध को वर्गीकृत करता है और इसे सही वर्कफ़्लो पर रूट करता है।"
  • "यह फीचर एक प्रतिक्रिया का ड्राफ्ट तैयार करता है जिसे भेजने से पहले एक इंसान अनुमोदित करता है।"
  • "यह फीचर आंतरिक दस्तावेज़ों में खोज करता है और अपने द्वारा उपयोग किए गए स्रोत का हवाला देता है।"

यदि वादे को एक पैराग्राफ लगता है, तो फीचर अभी तक स्कोप नहीं किया गया है।

हैप्पी पथ से पहले विफलता सेट बनाएं

अधिकांश AI डेमो गलती से डेमो पास करने के लिए प्रशिक्षित होते हैं।

वास्तविक मूल्यांकन सेट में वे इनपुट शामिल होने चाहिए जो प्रोडक्ट को असहज बनाते हैं:

  • अस्पष्ट अनुरोध
  • परस्पर विरोधी निर्देश
  • गुम संदर्भ
  • दुर्भावनापूर्ण प्रॉम्प्ट इंजेक्शन
  • पुरानी पॉलिसी दस्तावेज़
  • डुप्लिकेट रिकॉर्ड
  • गुस्से वाले ग्राहक संदेश
  • ऐसे एज केस जिन्हें गलत तरीके से संभालने पर पैसे खर्च होते हैं

क्लाइंट-फेसिंग AI वर्कफ़्लो के लिए, मैं सिस्टम के आकार पर भरोसा करने से पहले कम से कम 25 उदाहरण चाहता हूँ। 25 सही बेंचमार्क पंक्तियाँ नहीं। पच्चीस बदसूरत उदाहरण जो वास्तविक काम का प्रतिनिधित्व करते हैं।

मूल्यांकन सेट कागजी कार्रवाई नहीं है। यह प्रोडक्ट की सीमा है।

मॉडल गुणवत्ता को प्रोडक्ट गुणवत्ता से अलग करें

एक मॉडल अच्छा हो सकता है और प्रोडक्ट फिर भी खराब हो सकता है।

मॉडल बिना किसी उद्धरण के सही उत्तर दे सकता है। वर्कफ़्लो सही दस्तावेज़ का हवाला दे सकता है लेकिन महत्वपूर्ण चेतावनी को दबा सकता है। UI उत्तर को अंतिम दिखा सकता है जबकि वह केवल एक ड्राफ्ट है।

मैं AI फीचर्स को परतों में स्कोर करता हूँ:

  1. क्या इसने कार्य को समझा?
  2. क्या इसने सही स्रोत या टूल का उपयोग किया?
  3. क्या इसने स्रोत के बाहर दावे करने से परहेज किया?
  4. क्या इसने परिणाम को ऐसे रूप में लौटाया जिस पर उपयोगकर्ता कार्रवाई कर सके?
  5. क्या UI ने सिस्टम के आत्मविश्वास और सीमाओं को स्पष्ट किया?

केवल पहले दो ज्यादातर मॉडल प्रश्न हैं। बाकी प्रोडक्ट प्रश्न हैं।

एक इंसान को लूप में रखें, सुविधाजनक लगने से अधिक समय तक

AI वर्कफ़्लो का पहला प्रोडक्शन संस्करण आमतौर पर ड्राफ्ट-फर्स्ट होना चाहिए, सेंड-फर्स्ट नहीं।

यह कम जादुई लगता है। अच्छा है।

ड्राफ्ट-फर्स्ट आपको समीक्षा डेटा देता है। यह दिखाता है कि उपयोगकर्ता आउटपुट को कहाँ संपादित करते हैं, कहाँ अस्वीकार करते हैं, कौन से फ़ील्ड सुधारते हैं, और कौन से कार्यों को पहले स्थान पर कभी स्वचालित नहीं किया जाना चाहिए था।

मानव समीक्षा चरण कोई स्थायी सहारा नहीं है। यह इंस्ट्रूमेंटेशन है।

जब संपादन पूर्वानुमानित हो जाते हैं, तो संपादन को स्वचालित करें। जब अस्वीकृतियाँ एक इनपुट प्रकार के आसपास केंद्रित होती हैं, तो राउटर बदलें। जब समीक्षक मैन्युअल रूप से उसी स्रोत की जाँच करता रहता है, तो रिट्रीवल और साइटेशन जोड़ें।

आप इंसान को इसलिए नहीं हटाते क्योंकि डेमो ने काम किया। आप इंसान को तब हटाते हैं जब समीक्षा लॉग कहता है कि सिस्टम ने इसे अर्जित कर लिया है।

शिपिंग चेकलिस्ट

इससे पहले कि मैं कोई AI फीचर शिप करूँ, मैं ये चीज़ें जगह पर चाहता हूँ:

  • एक-वाक्य का वादा
  • बदसूरत उदाहरणों वाला एक मूल्यांकन सेट
  • प्रत्येक उदाहरण के लिए पास/फेल मानदंड
  • प्रॉम्प्ट, टूल कॉल, स्रोत और परिणाम के लिए लॉगिंग
  • उच्च-जोखिम वाले आउटपुट के लिए मानव-समीक्षा पथ
  • मॉडल अनुपलब्ध होने पर एक फॉलबैक
  • UI से खराब आउटपुट रिपोर्ट करने का एक तरीका

इनमें से कोई भी फीचर को कम प्रभावशाली नहीं बनाता।

यह फीचर को वास्तविक बनाता है।

संबंधित सिस्टम: The AI implementation audit before you build इसी विचार को टीमों के लिए प्री-बिल्ड ऑडिट पथ में तोड़ता है जो यह तय कर रहे हैं कि पहले क्या स्वचालित करना है।

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

AI Engineering

intent

AI

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 5d6c8652026-08-05 06:00Z
// solo studio// no analytics resold// every commit human-reviewed