AI एजेंट्स और ऑटोमेशन: RAG, वर्कफ़्लो और गाइड

आपने OpenAI पर बनाया, फिर Claude आज़माना चाहा और Gemini से तुलना करनी चाही — और हर प्रोवाइडर के अलग SDK, फ़ॉर्मैट, तथा error handling में घंटों गँवा दिए। LLM gateway (AI gateway / LLM proxy) एक रिले है जिसे आप अपनी ऐप और प्रोवाइडर्स के बीच लगाते हैं: यह हर मॉडल तक पहुँचने के लिए एक OpenAI-compatible API पेश करता है और cross-cutting काम अपने ज़िम्मे लेता है — fallback, cost tracking, virtual keys, caching, rate limiting, और observability। यह गाइड बताती है कि आपको इसकी ज़रूरत क्यों है, gateway असल में क्या है, तीन प्रकार (self-hosted proxy = LiteLLM / hosted = OpenRouter / SDK = Vercel AI SDK), LiteLLM, OpenRouter, और Vercel AI SDK में से कैसे चुनें, न्यूनतम सेटअप कोड जो सिर्फ़ endpoint बदलता है, और सीमाएँ — एक hop latency, gateway एक नया failure point, शुल्क (OpenRouter खरीद पर 5.5% लेता है), फ़ीचर का नुकसान, और privacy।

AI एजेंट बनाने के बाद, आप हमेशा उसी दीवार से टकराते हैं: "ठीक है, पर क्या यह सचमुच काम कर रहा है?" यह तय करने का तंत्र कि किसी प्रॉम्प्ट या मॉडल बदलाव ने चीज़ों को अंदाज़े के बजाय डेटा के आधार पर बेहतर किया या बदतर, ही है evals। LLM एक ही इनपुट पर हर बार अलग आउटपुट देते हैं, इसलिए एग्ज़ैक्ट-मैच यूनिट टेस्ट फ़िट नहीं होते। यह लेख इन्हें असल में बनाकर चलाने के चरणों पर केंद्रित है, और इसमें शामिल हैं गुणवत्ता मापने के पाँच तरीके (① ग्राउंड-ट्रुथ मैचिंग ② नियम-आधारित जाँच ③ LLM-as-judge ④ रिग्रेशन टेस्टिंग ⑤ प्रोडक्शन मॉनिटरिंग), एजेंट-विशिष्ट मूल्यांकन (टास्क सफलता-दर, सही टूल कॉल, ट्रैजेक्टरी, लागत), 20 विफलता उदाहरणों से छोटे से शुरुआत, आम गलतियाँ, और प्रमुख टूल (Anthropic Console/Evals, OpenAI Evals, LangSmith, Langfuse, Ragas) — प्रैक्टिशनर्स के लिए लिखा गया।

स्वचालन का चिरस्थायी सवाल: "AI एजेंट या RPA?" जवाब "या तो यह या वह" वाला नहीं — भूमिका से चुनें, और 2026 का जीतने वाला पैटर्न है दोनों का हाइब्रिड। RPA निर्धारक "हाथ" हैं जो तय प्रक्रिया को तेज़ी व सटीकता से चलाते हैं (पर स्क्रीन/स्पेसिफ़िकेशन बदलने पर टूट जाते हैं); AI एजेंट प्रायिक "दिमाग़" है जो हालात पढ़कर फ़ैसला लेता है (अस्पष्टता व अपवादों में मज़बूत, पर हर बार वही नतीजा नहीं)। यह लेख काम करने के सिद्धांत का फ़र्क़, तुलना तालिका (पुनरुत्पादकता बनाम सहनशीलता की अदला-बदली), चुनाव का तरीक़ा (कसौटी है "क्या इसे पूरी तरह नियमों में लिखा जा सकता है?" — हाँ → RPA, न लिखा जा सके ऐसा फ़ैसला → AI एजेंट), 2026 का रुझान (RPA अग्रणी UiPath, Automation Anywhere, Blue Prism एजेंटिक बन रहे — अभिसरण; सवाल अब "कौन सा" नहीं बल्कि "तर्क कहाँ रहे" = ऑर्केस्ट्रेशन-पहले), और व्यावहारिक जवाब को समेटता है: एक हाइब्रिड जहाँ दिमाग़ (AI एजेंट) फ़ैसला/ऑर्केस्ट्रेशन सँभाले और हाथ (RPA) निर्धारक निष्पादन चलाएँ — जहाँ निर्धारकता ज़रूरी हो वहाँ एजेंट न लगाएँ, और सौंपे गए फ़ैसले के साथ गार्डरेल व मानवीय अनुमोदन रखें। विक्रेताओं की आधिकारिक जानकारी पर आधारित, FAQ सहित।

क्या आप AWS संचालन AI को सौंप सकते हैं? 2026 में काफी कुछ सौंपा जा सकता है। AWS खुद Amazon Q Developer और Agent Toolkit for AWS (May 2026 — 40+ agent skills + एक मैनेज्ड AWS MCP Server + प्लगइन्स) प्रदान करता है, जिससे AI, IaC जनरेशन से रिसोर्स ऑपरेशन तक पहुँच सकता है। यह गाइड "सौंपने" को तीन स्तरों में समझाती है (① कोड/IaC जनरेशन, ② पढ़ने-केंद्रित ऑपरेशन/जाँच, ③ एक स्वायत्त एजेंट जो सचमुच AWS संचालित करता है), मुख्य टूल्स को कवर करती है (Amazon Q Developer, Agent Toolkit, AWS MCP Server, Terraform MCP, Bedrock AgentCore) — जिसमें Claude Code या Codex को AWS CLI देकर शेल से "aws" चलवाने वाला अपना-लाओ रास्ता भी शामिल है — फायदे (तेज़ IaC, स्वचालित ट्राइएज, कॉस्ट-ऑप्टिमाइज़ेशन के विचार, ज्ञान का लोकतंत्रीकरण), और फिर असली मुद्दा, नुकसान (IAM permission sprawl, गलतियों/प्रॉम्प्ट इंजेक्शन के लिए ब्लास्ट-रेडियस बढ़ाने वाली अधिक-अनुमति, कार्य के बाद बची अनुमतियाँ, कॉस्ट रनअवे — 2025-26 की वास्तविक प्रोड-DB-डिलीशन घटनाओं के साथ), AWS आधिकारिक और सुरक्षा-वेंडर स्रोतों के आधार पर। मुख्य पेच: सवाल "क्या यह हो सकता है?" नहीं बल्कि "बिना रनअवे या बिल विस्फोट के आप इसे कैसे सौंपें" है — और AWS द्वारा खुद Agent Toolkit में IAM गार्डरेल्स, CloudTrail ऑडिट और सैंडबॉक्सिंग शामिल करना उत्तर की रूपरेखा दिखाता है। इसमें पाँच सिद्धांत (न्यूनतम-विशेषाधिकार IAM, विनाशकारी ऑपरेशन के लिए मानवीय अनुमोदन, ऑब्ज़र्वेबिलिटी, JIT अल्पकालिक क्रेडेंशियल्स, सैंडबॉक्सिंग) और एक FAQ शामिल है।

AI एजेंट को असली काम में उतारने की पहली बाधा है "इसे किस फ्रेमवर्क पर बनाएँ।" डेवलपर और तकनीक-चयनकर्ता के नज़रिए से यह लेख छह प्रमुख फ्रेमवर्कों की तुलना करता है — LangGraph, CrewAI, AutoGen (Microsoft Agent Framework में समाहित, GA अप्रैल 2026), OpenAI Agents SDK, Google ADK और Claude Agent SDK — ऑर्केस्ट्रेशन दृष्टिकोण (दिशात्मक ग्राफ़ / भूमिका-आधारित क्रू / संवादात्मक GroupChat / हैंडऑफ़ / श्रेणीबद्ध वृक्ष / स्वायत्त टूल लूप), भाषा, सीखने की चढ़ाई, नियंत्रण, प्रोडक्शन परिपक्वता, टोकन लागत और सबसे उपयुक्त उपयोग-परिदृश्य के आधार पर। मुख्य चेतावनी: जो फ्रेमवर्क "प्रोटोटाइप में सबसे तेज़" है (CrewAI) वही प्रोडक्शन में सबसे महँगा हो सकता है — करीब 3× टोकन (एक बेंचमार्क में LangGraph 18.5k के मुकाबले 41k) और अनिर्धारक, जो वित्त और स्वास्थ्य के लिए खराब फिट है। यह भी बताता है कि 2026 में MCP (टूल) और A2A (एजेंट-टू-एजेंट) से इंटरऑप कैसे आया, जिससे अलग-अलग फ्रेमवर्कों के एजेंट अब मिलकर काम कर सकते हैं और लॉक-इन कमज़ोर पड़ गया। इसमें उपयोग-परिदृश्य चयन गाइड और FAQ शामिल हैं।

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 के सबएजेंट, 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 एजेंट आम हो चुके हैं, अगली चुनौती है एजेंट्स को आपस में कैसे सहयोग करवाया जाए। अगर 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 बुरे आउटपुट इकट्ठा करके और उन्हें स्कोर करके करें।