AI इवैल्स समझाया गया: बुनियादी बातों से लेकर स्व-सुधार करने वाले एजेंटों तक

ईज़ी मोड: WTF है एक eval - एक eval यह देखने के लिए एक परीक्षण है कि क्या एक AI एजेंट ने जो किया वह सही है - 'सही' में असली बात यह है कि आप / आपके संगठन को जो सही लगता है उसे सॉफ्टवेयर में एन्कोड करना - उदाहरण: GTM एजेंट जो ग्राहक मीटिंग लॉग करता है, follow-up ड्राफ्ट लिखता है और भेजने से पहले रुक जाता है - इस संदर्भ में एक eval यह जांच सकता है कि क्या ग्राहक मीटिंग लॉग हुई, क्या follow-up ड्राफ्ट लिखा गया, क्या एजेंट भेजने से पहले रुका - Evals वास्तव में नए नहीं हैं, वे सिर्फ unit tests का एक विकसित संस्करण हैं, जो सॉफ्टवेयर में हमेशा से मौजूद रहे हैं - eval सेट करने की विधि वास्तव में काफी सरल है: एजेंट + सिस्टम + कार्य + verifier - GTM एजेंट उदाहरण में, आपके पास आपका एजेंट है, Salesforce तक read/write पहुंच, कार्यों का एक सेट (जैसे lead status अपडेट करना, कॉल लॉग करना, follow-up लिखना), और एक verifier (ऐसा टूल जिसका काम यह निर्धारित करना है कि कार्य सही या गलत तरीके से किया गया) - Verifiers एक साधारण Python फ़ंक्शन या content/prose जांच हो सकते हैं - Rubrics उन गैर-verifiable कार्यों के लिए यह कोडिफाई करने का एक शानदार तरीका है कि अच्छा कैसा दिखता है ताकि verifiers फिर भी काम कर सकें - एक बार rubrics बन जाने के बाद अगर एजेंट प्रदर्शन नहीं करता है, तो मूल कारण हो सकता है: checklist अधूरी है, मॉडल पर्याप्त स्मार्ट नहीं है, खराब/अधूरा context या prompt पर्याप्त अच्छा नहीं है हार्ड मोड: WTF हैं Agent Environments - Environment = वह स्थान जहां एजेंट काम करता है और हम मापते हैं कि वह कैसा प्रदर्शन करता है - Environments आवश्यक हो गए क्योंकि हम ChatGPT युग के text in text out से agentic युग के prompt in, real world work out की ओर बढ़े - उदाहरण: Claude Code/Codex के लिए, जब वे आपके कंप्यूटर पर काम करते हैं, तो environment फाइलें, ब्राउज़र, ईमेल, ऐप्स, permissions होता है - जब आप आज agent environments बनाते हैं = मौजूदा टूलिंग के recreations simulations जो एजेंट को वास्तविक लगते हैं लेकिन वास्तविक नहीं हैं (prod को overwrite नहीं करेंगे) - मूल रूप से आप यह परीक्षण करना चाहते हैं कि आपके एजेंट कितने प्रभावी हैं बिना आपकी कंपनी के live systems/data के साथ छेड़छाड़ किए - एजेंट + evals बनाते समय आवश्यकताएं: (1) टीम द्वारा कार्य प्रबंधित करना (GTM ≠ SWE), (2) टीम-विशिष्ट environments, (3) सभी infra खुद बनाए बिना बड़े पैमाने पर चलाना - Agent environments सेट करने के लिए लोकप्रिय टूलिंग एक open source framework है जिसे Harbor कहा जाता है, जो evals चलाने के लिए आवश्यक सभी agent environment abstractions प्रदान करता है ताकि आपको सब कुछ प्रबंधित न करना पड़े, लेकिन जरूरत पड़ने पर low-level जा सकते हैं - Harbor primitives कवर करते हैं: environment building, verifier building, instruction building, sandbox infra - शुरुआती रास्ता: मौजूदा Harbor-format eval पकड़ें → Claude Code/Codex से समझाने को कहें → अपने एजेंट के लिए tweak करें - LangSmith Engine: बड़े पैमाने पर evals बनाएं; उन लोगों के लिए UI जो अच्छे/बुरे outputs का न्याय कर सकते हैं और बिना कोड में रहे feedback देना चाहते हैं - Environments को मान्य करें उनमें कई वास्तविक एजेंट/मॉडल चलाकर (जैसे frontier + GLM + छोटा Qwen) और अजीब पैटर्न देखकर - Environment engineering iterative है जैसे agent engineering; मनुष्य निर्माण और outputs की समीक्षा करते हैं - बड़े पैमाने पर evals करने के लिए आपको एक eval suite चाहिए। एक eval suite agent tasks का एक संग्रह है जिसे आप एक कंपनी के रूप में चला रहे हैं। प्रत्येक task में एक input prompt, एक verifier, और environment शामिल होता है। - जब भी नया मॉडल आता है, आप अपना eval suite (या suite से tasks का चयन) चलाएंगे, और cost बनाम speed बनाम intelligence के tradeoffs को तौलेंगे गॉड मोड: WTF है एक self-improving agent - एजेंट का real world में निरंतर चक्र → production data → production को evals में बदलना (और सुधार के लिए evals का उपयोग करना) → एजेंट में लगातार सुधार करना - Hot take: अगर आपकी टीम production data को evals में बदलने में वास्तव में अच्छी है, तो आप एजेंटों में लगातार सुधार कर सकते हैं - Evals विफलताओं को खोजने के लिए मौजूद हैं; फिर एजेंट को बदलें ताकि वह विफलता फिर कभी न हो - दो सुधार श्रेणियां: harness engineering और छोटे मॉडल का fine tuning - Harness engineering: (शुरू करने के लिए सस्ती जगह): prompts, tool definitions/descriptions, model choice, model combos tweak करें (जैसे Sol+Opus, GLM+Opus) - Fine-tune (अपने संकीर्ण production task पर): open models + fine-tune infra मौजूद हैं; उस *विशेष* कार्य पर Opus से मेल खा सकते हैं लगभग 10x सस्ता; GTM एजेंट को frontier math की जरूरत नहीं है - गॉड मोड = वास्तविक production data इकट्ठा करें → evals/environments में बदलें → सुधार का तरीका चुनें (पहले harness; बाद में विशिष्ट कार्यों के लिए खुद की fine-tuned intelligence) - अड़चन अक्सर मानव द्वारा verifiers/rubrics अपडेट करना होती है - स्वायत्तता के लिए दो प्रश्न: कैसे तेजी से घुमाएं; क्या यह बिना मानव के loop में चल सकता है? - लक्ष्य: loop पर मानव संपर्क बिंदुओं को कम करना - Agent Traces एजेंटों का उपयोग करने वाले संगठनों के लिए पहला व्यावहारिक कदम है - Trace = हर क्रिया का लॉग: tool calls - मनुष्य अच्छी तरह से तर्क नहीं कर सकते कि एजेंट *क्या* करेगा; live behavior (उर्फ traces) देखने से सही/गलत स्पष्ट हो जाता है - खराब परिणाम देखें → traces (receipts) पढ़ें → गलत कदम खोजें → एजेंट बदलें ताकि वह दोहराए नहीं - हर स्मार्ट मॉडल रिलीज़ के साथ मानव संपर्क बिंदु घटते हैं - आज की मानव भूमिका #1 (शुरुआत में): mining/improvement agent को समझाएं कि अच्छा बनाम बुरा कैसा दिखता है (देखने के लिए व्यवहारों का prompt); ज्यादातर शुरुआत में कुछ समय के साथ edits के साथ - फिर एक एजेंट विफल tool calls, instruction-following विफलताएं आदि ढूंढ सकता है, और सुधार प्रस्तावित कर सकता है (नया prompt, नया/अलग टूल, आदि) - एक अच्छे eval suite या अच्छे prod bad-behavior measurement के साथ, रात भर चलने वाला एजेंट fixes प्रस्तावित करने में बहुत अच्छा हो सकता है - मानव भूमिका #2: production को evals/environments में बदलते समय, समीक्षा करें कि *कंपनी* किस बारे में परवाह करती है - सबसे उच्च leverage संगठनात्मक कार्य: मनुष्य लिखते हैं कि अच्छा कैसा दिखता है