AI टूल्स की गाइड, तुलना और नवीनतम समाचार

एक दिन अचानक आपका ChatGPT या Claude account काम करना बंद कर देता है: 2026 में account निलंबन (ban) और चेतावनियों की रिपोर्टें बढ़ रही हैं, और डरावनी बात यह है कि बिना किसी बुरे इरादे के भी, गलती से नियम तोड़ने पर आप ban हो सकते हैं। यह लेख OpenAI (ChatGPT, Codex) और Anthropic (Claude, Claude Code) पर अपना account न खोने के लिए जानने योग्य बातों को प्रकाशित usage policies और रिपोर्टों के आधार पर व्यवस्थित करता है। दोनों में आम पाँच triggers: प्रतिबंधित content / jailbreak, अनधिकृत automation / scraping, account/API keys साझा या बेचना, संदिग्ध access patterns, और payment में बेमेल/धोखाधड़ी। 2026 का सबसे बड़ा जाल: निजी-plan (Free/Pro/Max) के OAuth tokens को Agent SDK जैसे harnesses समेत आधिकारिक app के अलावा कहीं इस्तेमाल करना Consumer ToS उल्लंघन है। सही तरीका है apps/agents को API (pay-as-you-go) से चलाना। साथ में 7-बिंदु बचाव checklist और appeals की जानकारी।

किसी विशाल AI को शुरू से दोबारा ट्रेन करना बहुत महँगा है, पर आप इसे बस अपने लिए थोड़ा बदलना चाहते हैं; LoRA (Low-Rank Adaptation) मूल मॉडल को फ्रीज़ करके और सिर्फ़ एक छोटे adapter को ट्रेन करके यह इच्छा पूरी करती है, जिससे ट्रेन होने वाले parameters लगभग 90% घट जाते हैं। LoRA fine-tuning को नाटकीय रूप से सस्ता और तेज़ बनाती है, और Stable Diffusion जैसी इमेज जनरेशन में किरदार या स्टाइल जोड़ने वाली छोटी फ़ाइल के रूप में बेहद लोकप्रिय है। यह लेख इसे एक पैच की उपमा से समझाता है। LoRA, parameter-efficient fine-tuning (PEFT) की अग्रणी तकनीक है: विशाल मूल weights को frozen रखें, हर लेयर में एक छोटा matrix डालें, और सिर्फ़ उसी को ट्रेन करें (W = W0 + BA)। फ़ायदे: ~90% कम params (GPT-3 पैमाने पर 10,000x कम), कम GPU मेमोरी (~3x कम), तेज़ व सस्ती ट्रेनिंग, merge के बाद कोई inference latency नहीं, और कम overfitting। इसकी सबसे बड़ी ताक़त बदलने योग्य adapters हैं: एक साझा बेस रखें और हर उपयोग के लिए few-MB LoRA फ़ाइलें तुरंत बदलें। QLoRA, quantization को मिलाकर 4-bit बेस पर LoRA ट्रेन करती है, मानक LoRA से ~4x कम मेमोरी में, जिससे उपभोक्ता GPU पर भी विशाल मॉडल fine-tune होते हैं। बनाम full fine-tuning, LoRA अक्सर काफ़ी होती है। बेस बनाए रखें, उसे छोटे पैमाने पर स्वाद दें।

एक विशाल 70B model डेटा-सेंटर के GPU rack के बजाय घर के एक gaming PC पर चल सके, यह quantization से संभव होता है, जो model के weights की numerical precision घटाकर आकार और memory नाटकीय रूप से कम करता है। जहाँ model distillation ज्ञान को एक अलग छोटे model में ले जाती है, वहीं quantization उसी model को हल्का बनाता है। यह लेख इसे फोटो-compression की उपमा से समझाता है। quantization, FP16/FP32 दशमलव के रूप में संग्रहित weights को INT8 (8-bit) या INT4 (4-bit) integers से बदलता है, प्रति weight bytes घटाते हुए (FP32=4, INT8=1, INT4=0.5); RAW फोटो को JPEG में compress करने जैसा, आप थोड़ी precision की कुर्बानी देकर बड़ी कमी पाते हैं, और हैरानी इस बात की है कि आप कितना कम खोते हैं। memory पर, 4-bit, FP16 की लगभग एक-चौथाई लेता है: एक 70B model ~140GB से ~35GB तक गिरता है, और एक 8B model 4-bit पर ~4.5-5GB का होता है, जो midrange 8GB-VRAM GPU में लोकल उपयोग के लिए समाता है (LLMs का लोकतंत्रीकरण)। accuracy पर, INT8 लगभग बिना नुकसान है और INT4 सामान्य Q&A/सामान्य-ज्ञान tasks पर 4% से कम घटता है, पर गणित, code generation और कठिन reasoning के लिए नुकसान ज़्यादा साफ़ दिखता है (यह perplexity में थोड़ी वृद्धि के रूप में दिखता है), इसलिए task के लिए bit-width चुनें। मुख्य तरीके: GPTQ (सटीक 4-bit का अग्रदूत), AWQ (सबसे महत्वपूर्ण ~1% weights सुरक्षित रखता है, अक्सर 1-2% अधिक सटीक और तेज़), GGUF (llama.cpp/Ollama format, Q2_K-Q8_0, CPU+GPU hybrid, लोकल के लिए), और QLoRA (4-bit base साथ LoRA, consumer-GPU fine-tuning के लिए)। यह distillation (एक अलग छोटे model में जाना) और fine-tuning (task ज्ञान जोड़ना) से अलग है, और तीनों आमतौर पर मिलाए जाते हैं (एक distilled model को quantize करें; एक quantized base को fine-tune करें)। शुरू करने के लिए, एक command में Ollama के साथ एक GGUF model चलाएँ, VRAM के अनुसार Q4/Q8 चुनें, और code या सटीक गणित के लिए INT4 से बचें। अधिकांश प्रमुख model पहले से quantized आते हैं, इसलिए आप बस उन्हें download करके इस्तेमाल करते हैं। समझदारी बनाए रखें, सिर्फ़ वज़न घटाएँ। आँकड़े सार्वजनिक सामग्री से उद्धृत, दिशा-सूचक।

एक विशाल, उच्च-प्रदर्शन वाली AI स्मार्ट तो है पर भारी और महंगी; model distillation (knowledge distillation) इसे एक बड़े teacher model का ज्ञान छोटे student model में स्थानांतरित करके हल करता है, और teacher के प्रदर्शन का 95%+ उसके दसवें हिस्से के आकार और गति पर बनाए रखता है। यह लेख इसे teacher-student की उपमा से समझाता है। कुंजी soft labels हैं: साधारण प्रशिक्षण केवल "उत्तर बिल्ली है" सिखाता है (hard label), जबकि distillation teacher का पूरा संभाव्यता वितरण जैसे "90% बिल्ली, 8% कुत्ता, 2% लोमड़ी" सौंपता है, जिसकी झिझक की मात्रा समृद्ध जानकारी रखती है; एक temperature पैरामीटर संभावनाओं को नरम कर सूक्ष्म संबंध उजागर करता है (वास्तविक उदाहरण: GPT-4o mini, GPT-4o से distilled)। फायदे: तेज़ और सस्ता, ~10x ज़्यादा कॉम्पैक्ट, 95%+ प्रदर्शन बनाए रखते हुए, edge पर चलता है, विशेषीकरण में मज़बूत। दो तरीके: white-box (weights और आंतरिक प्रतिनिधित्वों तक पूरी पहुँच, गहरा स्थानांतरण; अपने या OSS models के लिए) और black-box (केवल आउटपुट/API responses दिखते हैं; किसी दूसरी कंपनी की API को teacher बनाना terms का उल्लंघन कर सकता है)। यह quantization (उसी model की weight precision संपीड़ित करना) और fine-tuning (मौजूदा model को किसी task के लिए आगे प्रशिक्षित करना) से अलग है — distillation ज्ञान को एक अलग छोटे model में ले जाता है, और तीनों को मिलाया जा सकता है। कानूनी/ToS हकीकत 2026 का बड़ा मुद्दा था: तकनीक वैध है, पर OpenAI, Anthropic, Mistral और xAI में anti-competitive distillation खंड हैं जो आउटपुट का उपयोग प्रतिस्पर्धी models बनाने के लिए करना प्रतिबंधित करते हैं, इसलिए किसी प्रतिबंधित API से प्रतिस्पर्धी distill करना terms का उल्लंघन कर सकता है। OpenAI बनाम DeepSeek विवाद (OpenAI ने आरोप लगाया कि DeepSeek से जुड़ी accounts ने प्रतिबंध दरकिनार कर distillation के लिए आउटपुट हासिल किए, जबकि DeepSeek की terms कथित तौर पर अपने आउटपुट distill करने की अनुमति देती हैं) दिखाता है कि आकलन इस पर निर्भर है कि किसकी API terms लागू होती हैं, और Claude Fable 5/Mythos 5 कथित तौर पर distillation-चिह्नित काम पर responses सीमित करते हैं। सुझाव: teacher के रूप में अपना या लाइसेंस प्राप्त OSS model इस्तेमाल करें, commercial API इस्तेमाल करने से पहले anti-distillation खंड जाँचें, और तय करें कि उपयोग "प्रतिस्पर्धी model विकसित करना" तो नहीं है। स्मार्टनेस बड़े model से, संचालन छोटे से — पर आप teacher किसे चुनते हैं यह तकनीकी और कानूनी रूप से परिणाम बदल देता है। आँकड़े सार्वजनिक सामग्री से उद्धृत, दिशात्मक।

AI observability वह तकनीक है जो दिखाती है कि production में आपके LLMs और agents असल में क्या करते हैं — कौन-सा model, कौन-से tools व searches, क्या लौटाया, और कितना समय व लागत — ताकि कुछ टूटने पर आप कारण तक पीछे जा सकें। सामान्य app monitoring से निर्णायक अंतर: AI 50ms में 200 OK लौटा सकता है और फिर भी आत्मविश्वास से hallucinate कर सकता है, इसलिए अधिकांश AI विफलताएँ infrastructure नहीं, गुणवत्ता विफलताएँ हैं। तीन स्तंभ: traces, metrics, logs. उद्योग मानक OpenTelemetry GenAI conventions इन्हें vendor-neutral schema में संभालते हैं। यह लेख observability बनाम evals का अंतर, देखने योग्य metrics, और प्रमुख tools (LangSmith/Langfuse/Phoenix/MLflow/AgentOps/OpenTelemetry) समझाता है।

"Multi-agent system क्या है?" में अवधारणा समझने के बाद, यह व्यावहारिक अगला कदम है। 2026 के वास्तविक मानक supervisor pattern से शुरुआती लोगों को 5-चरण में बनाना सिखाता है। मुख्य सिद्धांत: पहले एकल agent बनाएँ और सीमा से टकराने पर ही न्यूनतम स्तर पर agents जोड़ें (लगभग 80% उपयोग एक से चल जाते हैं; सीधे-सादे काम में multi से लागत 3-10x बढ़ती है और Google शोध के अनुसार क्रमिक कार्यों में सटीकता −39-70% गिरती है)। multi अपनाने के 3 संकेत: विशेषज्ञता विभाजन, समानांतरता, निर्णय पृथक्करण। supervisor pattern (supervisor पूरा कार्य लेता है, बाँटता है, workers को सौंपता है, परिणाम जोड़ता है) पर Claude Code subagents, LangGraph Supervisor और OpenAI Agents SDK handoffs सभी मिल गए हैं — व्यापक framework समर्थन, ज्ञात failure mode और आसान audit के कारण। 5 चरण: 1) कार्य साफ़-साफ़ विभाजित करें; 2) एक भूमिका + tools + output format वाले workers (अधिकतम 3-5); 3) supervisor डिज़ाइन करें, बुलाने योग्य नाम सूचीबद्ध करें (hard cap); 4) handoff और context साझाकरण तय करें, केवल ज़रूरी सौंपें (मानक A2A); 5) agents जोड़ने से पहले हर handoff मापें, सीमाएँ लगाएँ, evals और guardrails तैयार करें। छद्म-कोड workers, hard-capped supervisor और iteration-bounded loop दिखाता है। आम गलतियाँ और समाधान: over-delegation, token का फूलना, अस्थिरता, सटीकता गिरना, अज्ञात विफलता-बिंदु। साझा सबक: सफलता framework से ज़्यादा prompts, tools और eval harness तय करते हैं। छोटा बनाएँ, मापें, तभी जोड़ें जब फ़ायदेमंद हो।

"एक AI agent जिस जटिल काम को अकेले नहीं संभाल सकता, उसे कई agents में बाँट देना" — यही multi-agent systems की सोच है। यह शुरुआती-अनुकूल गाइड इसकी कार्यप्रणाली, मुख्य पैटर्न और प्रमुख frameworks बताती है, और सबसे ज़रूरी बात, बिना अतिशयोक्ति के असली निर्णय-नियम कि कब कई agents इस्तेमाल करें और कब एक ही काफी है। एक multi-agent system में अलग-अलग भूमिकाओं वाले कई AI एक बड़े काम पर मिलकर काम करते हैं; सब कुछ अकेले करने वाले single agent (जो ~80% use cases के लिए ठीक, सस्ता और debug में आसान है) के मुकाबले यह काम को विशेषज्ञता से बाँटता है ताकि समानांतर निष्पादन और आपसी जाँच हो सके, पर coordination लागत और token खपत ज़्यादा होती है। चार प्रमुख orchestration पैटर्न हैं: orchestrator-worker (लीड बाँटता, workers को समानांतर भेजता, और जोड़ता है; सबसे प्रचलित, audit trail के साथ), sequential handoff (संदर्भ अगले agent को सौंपना), group conversation (agents एक thread में बहस करते हैं, selector तय करता है कौन बोले; सत्यापन के लिए अच्छा), और graph state machine (agents nodes, transitions edges, स्पष्ट state; branching और checkpoints में मज़बूत)। Frameworks 2026 में LangGraph (सबसे बड़ा production आधार), CrewAI (सबसे कम सीखने की मेहनत, prototyping), AutoGen/AG2 (बहस और सत्यापन, रिसर्च), और OpenAI Swarm (हल्के handoffs) में सिमट गए। पर यह रामबाण नहीं: जटिल बहु-क्षेत्रीय कामों पर reasoning benchmarks में +23% तक, फिर भी एक-रास्ते sequential कामों पर Google रिसर्च में single agent बनाम -39-70%, एक agent को वही compute दें तो वह अक्सर बराबरी या बढ़त लेता है, और 10 में से 7 deployments में ~15x token खपत पर बिना ROI लागत बढ़ी (औसत ROI 2.5-3.5x, सही निशाने पर शीर्ष चौथाई 4-6x)। अनुशंसित रास्ता: पहले single बनाएँ, एक ठोस छत पहचानें (धुँधली भूमिकाएँ, समानांतर होने योग्य काम), फिर cost cap और logging के साथ न्यूनतम 2-3 agent लीड-पैटर्न टीम जोड़ें, और मापें कि सटीकता में बढ़त वृद्धि को सही ठहराती है या नहीं। A2A (communication protocol) और MCP (tool connection) multi-agent को सहारा देने वाली बुनियादी तकनीक हैं। 80% के लिए single, सिर्फ़ कठिन हिस्सों के लिए multi। आँकड़े सर्वेक्षणों और रिसर्च से लिए गए, परिस्थिति-निर्भर और दिशासूचक हैं।

अब जब AI एजेंट आम हो चुके हैं, अगली चुनौती है एजेंट्स को आपस में कैसे सहयोग करवाया जाए। अगर MCP किसी एजेंट को उसके tools से जोड़ता है, तो A2A (Agent2Agent) एक एजेंट को दूसरे एजेंट से जोड़ता है — एक open standard जिससे अलग-अलग vendors और frameworks पर बने AIs एक साझा परंपरा के ज़रिए खोज, संवाद और सहयोग कर सकें। Google ने इसे अप्रैल 2025 में रिलीज़ किया, उसी जून में Linux Foundation को दान किया, और 2026 में यह v1.0 तक पहुँचा। यह शुरुआती गाइड बताती है कि A2A क्या है (कंपनियों की व्यापारिक साझेदारी के शिष्टाचार जैसा), यह क्यों ज़रूरी है (विशेषज्ञ एजेंट काम को रिले करते हैं — एक planning एजेंट से hotel-booking एजेंट से payment एजेंट तक), MCP से इसका अंतर (MCP vertical है, agent ↔ tools; A2A horizontal है, agent ↔ agent; दोनों को एक साथ लगाना ही standard दो-स्तरीय सेटअप है), यह कैसे काम करता है (एक Agent Card — /.well-known/agent-card.json पर रखा एक JSON "विज़िटिंग कार्ड" — से क्षमताएँ discover होती हैं, फिर एक Task working, input-required, completed जैसी states के साथ request ले जाता है, और एक Artifact result लौटाता है, यह सब HTTP, Server-Sent Events, और JSON-RPC 2.0 पर होता है, जबकि एजेंट अपने आंतरिक हिस्से छिपे रखते हैं), तथा इसकी वर्तमान स्थिति और implementation (अप्रैल 2026 तक, 150+ संगठन production में, 22,000+ GitHub stars, पाँच भाषाओं में SDKs — Python, JavaScript, Java, Go, .NET — और Microsoft, Salesforce, SAP, ServiceNow शामिल)। याद रखने का तरीका: tools से जुड़ना = MCP, peers से जुड़ना = A2A।

आपने RAG तो बना लिया, पर search की क्वालिटी औसत है — ठीक यहीं reranking काम आती है। Reranking, embedding (vector) search से मोटे तौर पर जुटाए गए candidates को query से उनकी relevance के आधार पर फिर से score करती है और उन्हें फिर से क्रम में लगाकर सिर्फ़ टॉप वाले रखती है; यह एक कदम किसी RAG सिस्टम के जवाब की क्वालिटी को नाटकीय रूप से बदल सकता है। यह शुरुआती गाइड बताती है कि reranking क्या है (पहली-छँटाई-और-आख़िरी-इंटरव्यू वाली उपमा), यह क्यों ज़रूरी है (embedding search query और दस्तावेज़ों को अलग-अलग vector में बदलता है, इसलिए relevance को सिर्फ़ मोटे तौर पर आँकता है, और ख़राब क्रम सीधे जवाब की क्वालिटी घटाता है — शोध reranking जोड़ने से करीब 40% RAG सटीकता सुधार की रिपोर्ट करते हैं, और इसे hybrid search पर चढ़ाना 2026 का मानक है), two-stage retrieval कैसे काम करती है (recall के लिए तेज़ embedding search से "व्यापक रूप से जुटाएँ," फिर precision के लिए reranker से "समझदारी से छाँटें," फिर टॉप को LLM को सौंपें), reranker ज़्यादा सटीक क्यों है (bi-encoder query और दस्तावेज़ को अलग-अलग vector में बदलता है, तेज़ पर अनुमानित; cross-encoder उन्हें एक साथ feed करके 0–1 relevance score देता है, सटीक पर भारी — इसलिए तेज़ bi-encoder से जुटाएँ और सटीक cross-encoder से छाँटें), और मॉडल व implementation (API प्रकार जैसे Cohere Rerank, Voyage, Jina; open-source जैसे BGE reranker, mixedbread, FlashRank; और LLM-आधारित scoring जैसे RankLLM — बस 50–100 retrieve करें और टॉप 5 तक छाँटें)। सिद्धांत: व्यापक रूप से जुटाएँ, समझदारी से छाँटें, और संख्याओं को AI evals से ट्यून करें।

जब आप AI ऐप्स बनाना सीख जाते हैं, तो अगला चरण उन्हें सुरक्षित रूप से चलाना है। LLMs को दुर्भावनापूर्ण input से धोखा दिया जा सकता है, वे गोपनीय डेटा लीक कर सकते हैं, या आत्मविश्वास के साथ बेतुकी बातें ठोक सकते हैं; इसे रोकने वाला सुरक्षा तंत्र ही AI guardrails है, जो 2026 में AI agent की घटनाओं के असल में होने के साथ production का अनिवार्य हिस्सा बन चुका है। guardrails वे नियम और फ़िल्टर हैं जो खतरनाक input और अवांछित output को रोकते हैं, user input को LLM तक पहुँचने से पहले और जवाब को वापस लौटने से पहले जाँचते हैं — model से अलग एक स्वतंत्र सुरक्षा परत। मुख्य खतरे हैं prompt injection (सबसे बड़ा), jailbreak, डेटा लीक (गोपनीय डेटा, PII, system prompt), और hallucination या हानिकारक output। सुरक्षा दो परतों पर काम करती है: input guardrails (injection और jailbreak का पता लगाना, PII पहचानना/mask करना, विषय सीमित करना, sanitize करना) और output guardrails (हानिकारक सामग्री फ़िल्टर करना, लीक रोकना, hallucination जाँचना, format सत्यापित करना)। prompt injection — OWASP LLM Top 10 में सबसे गंभीर — direct (user "पिछले सभी निर्देश अनदेखा करो" टाइप करता है) और indirect (वेब पेज या RAG दस्तावेज़ में छिपे आदेश) रूपों में आता है, और indirect injection को अकेला RAG नहीं रोकता, इसलिए retrieved दस्तावेज़ों की अपनी जाँच चाहिए। यह शुरुआती गाइड tools (LLM Guard, Guardrails AI, NeMo Guardrails, Llama Guard, और Azure, AWS व OpenAI की cloud safety सुविधाएँ) तथा defense in depth, least privilege, मानव की मंज़ूरी और लगातार निगरानी के व्यावहारिक सिद्धांतों को भी कवर करती है।

RAG, semantic search और सिफ़ारिशें सभी एक अनसुने मेहनती कारीगर पर निर्भर हैं: embedding (vector)। embedding टेक्स्ट (या छवि) के अर्थ को संख्याओं की एक श्रृंखला — एक vector — में बदलना है। "कुत्ता" शब्द सैकड़ों से हज़ारों संख्याओं की सूची बन जाता है जो "अर्थ के निर्देशांक" की तरह काम करती है, इसलिए अर्थ में नज़दीक शब्द पास-पास बैठते हैं ("कुत्ता" और "पिल्ला" नज़दीक; "कुत्ता" और "कार" दूर), और नज़दीकी को cosine similarity जैसे मापों से आँका जाता है। प्रसिद्ध उदाहरण: "राजा − पुरुष + स्त्री ≈ रानी"। इसी कारण, अक्षर मेल न खाने पर भी मशीन यह आँक सकती है कि अर्थ नज़दीक है या नहीं। यह शुरुआती गाइड बताती है कि embedding क्या है (एक "अर्थ का नक्शा"), नज़दीकी से अर्थ क्यों मापा जाता है (dimensions और cosine similarity), इसका उपयोग कहाँ होता है (RAG, semantic search, वर्गीकरण और दोहराव-हटाना, सिफ़ारिशें और multimodal), embedding model कैसे चुनें (API प्रकार जैसे OpenAI text-embedding-3, Cohere, Gemini, Voyage; open-source जैसे BGE-M3, Nomic, Qwen3; साथ ही Matryoshka, जो 3,072 dimensions को 1,024 तक घटाकर लगभग एक-तिहाई लागत पर लगभग 95% गुणवत्ता बनाए रखता है), और vector DB (Pinecone, Weaviate, Qdrant, Chroma, pgvector) के साथ तीन-चरण शुरुआत (model चुनें, दस्तावेज़ vector में बदलकर संग्रहित करें, सवाल को vector में बदलकर search करें)। embedding, RAG लागू करने की नींव हैं।

आपने prompts निखारे, RAG से ज्ञान जोड़ा, शायद fine-tuning भी की — तो कैसे पक्का करें कि यह सचमुच बेहतर हुआ? यहीं AI evals मुख्य भूमिका में आते हैं, और 2026 तक मूल्यांकन इतना ज़रूरी है कि इसे "infrastructure" कहा जाता है। AI evals का मतलब है किसी LLM के आउटपुट की गुणवत्ता (सटीकता, hallucinations, फ़ॉर्मैट पालन, लहजा) को अंदाज़े के बजाय एक तय पैमाने पर व्यवस्थित रूप से मापना; इनके बिना सुधार महज़ एक अंदाज़ा है। दो तरीके हैं: यांत्रिक रूप से मापने योग्य बातों के लिए code-based मूल्यांकन (सटीक मिलान, फ़ॉर्मैट, ज़रूरी/प्रतिबंधित शब्द — तेज़, सस्ता, स्थिर) और व्यक्तिपरक बातों के लिए LLM-as-judge (किसी शक्तिशाली LLM को रेफ़री बनाकर pairwise तुलना या एकल-आउटपुट स्कोरिंग से आँकना)। सिद्धांत: जो कोड माप सकता है उसे कोड से ही मापें। LLM-as-judge में verbosity, position और self-preference biases होती हैं; उपाय हैं अलग परिवार के मॉडल को मूल्यांकनकर्ता बनाना, क्रम बदलकर दो बार आँकना, rubric में संक्षिप्तता डालना, और मानवीय निर्णय के विरुद्ध calibrate करना। मोटे पैमाने (pass/fail या 1–3) बारीक 1–10 से बेहतर हैं। व्यवहार में तीन स्तर चलाएँ — हर बदलाव पर तुरंत code जाँच, रात्रिकालीन LLM-judge regression टेस्ट, और लगातार प्रोडक्शन निगरानी — CI के लिए DeepEval, Promptfoo, RAGAS तथा निगरानी के लिए Braintrust, LangSmith, Arize जैसे उपकरणों के साथ। शुरुआत 10 अच्छे और 10 बुरे आउटपुट इकट्ठा करके और उन्हें स्कोर करके करें।