शुरुआती गाइड

आपने 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 बुरे आउटपुट इकट्ठा करके और उन्हें स्कोर करके करें।

जब आप AI को अपनी कंपनी के लिए कस्टमाइज़ करना चाहते हैं, तब फाइन-ट्यूनिंग एक विकल्प होता है — पर बिना सोचे-समझे इसमें कूदना महँगा है और गलत होना आसान। यह शुरुआती गाइड फाइन-ट्यूनिंग को समझाता है: पहले से प्रशिक्षित एक बेस मॉडल को लेना, उसे अपने उपयोग के अनुरूप डेटा पर और आगे प्रशिक्षित करना, और उसके वेट फिर से लिखकर "व्यवहार" (कंपनी की शैली, आउटपुट फ़ॉर्मैट, क्षेत्र की शब्दावली) को मॉडल के भीतर ही बैठाकर एक विशेषीकृत मॉडल में ढालना। फाइन-ट्यूनिंग व्यवहार बदलने में अच्छी है पर ताज़ा जानकारी याद रखने में कमज़ोर, इसलिए नियम है "तथ्य और ज्ञान → RAG, व्यक्तित्व और साँचा → फाइन-ट्यूनिंग, पहले प्रॉम्प्ट।" जैसा विशेषज्ञ कहते हैं, "हमें फाइन-ट्यूनिंग चाहिए" के लगभग 80% मामले बेहतर रिट्रीवल (RAG) या प्रॉम्प्टिंग से हल हो जाते हैं, इसलिए क्रम मायने रखता है। लेख समझाता है कि फाइन-ट्यूनिंग क्या है (नए कर्मचारी के प्रशिक्षण का उदाहरण), यह किसमें अच्छी और किसमें कमज़ोर है, फाइन-ट्यूनिंग बनाम RAG बनाम प्रॉम्प्टिंग की तुलना तालिका, मुख्य तरीके (full फाइन-ट्यूनिंग, LoRA, और QLoRA — 4-bit क्वांटाइज़ेशन जो शुरुआती के लिए काफ़ी हल्का है), क्या ज़रूरी है (कसौटी के तौर पर 500+ उच्च-गुणवत्ता वाले उदाहरण, जहाँ डेटा तैयार करना ही असली काम है; लागत $5,000 से $50,000 से अधिक तक, OpenAI की फाइन-ट्यूनिंग लगभग $25–$100 प्रति मिलियन ट्रेनिंग टोकन; OpenAI, Unsloth, Axolotl और Hugging Face जैसे टूल), और शुरू करने का क्रम। फाइन-ट्यूनिंग आखिरी उपाय है।

आप शायद मानते हों कि किसी LLM को क्लाउड में ही चलना पड़ता है, पर 2026 में AI को पूरी तरह अपने ही PC के अंदर चलाना — यानी "लोकल LLM" — एक व्यावहारिक विकल्प है। लोकल LLM का मतलब है ChatGPT या Claude जैसी मॉडल को क्लाउड के बजाय सीधे अपनी मशीन पर चलाना। इसके तीन बड़े आकर्षण हैं: प्राइवेसी (इनपुट कभी डिवाइस से बाहर नहीं जाता), शून्य लागत (कोई API शुल्क नहीं) और ऑफलाइन उपयोग (इंटरनेट के बिना भी चलता है)। कमज़ोरियाँ: यह सबसे ऊपरी क्लाउड AI जितना समझदार नहीं, इसे एक ठीक-ठाक सक्षम PC चाहिए, थोड़ा सेटअप लगता है, और इसके पास ताज़ा जानकारी नहीं होती। यह शुरुआती गाइड बताती है कि लोकल LLM क्या है (स्ट्रीमिंग-बनाम-डाउनलोडिंग की उपमा), फायदे और कमज़ोरियाँ, ज़रूरी स्पेक्स और क्वांटिज़ेशन (GGUF फ़ॉर्मैट, जिसमें Q4_K_M सबसे पसंदीदा है जो गुणवत्ता बनाए रखते हुए मेमोरी को लगभग एक-चौथाई कर देता है; 4-बिट पर प्रति 1B पैरामीटर लगभग 0.5 GB मेमोरी), शुरुआत कैसे करें (शुरुआती लोगों के लिए LM Studio का GUI, डेवलपर्स के लिए Ollama का CLI — 2026 की पहली तिमाही में 5.2 करोड़ मासिक डाउनलोड), सुझाई गई 2026 मॉडल्स (Llama 3.2 7B, Google Gemma 4, Alibaba Qwen3.5, साथ ही DeepSeek और Mistral — सभी ओपन), और लोकल बनाम क्लाउड का उपयोग कब करें (गोपनीय, अधिक-मात्रा और ऑफलाइन काम के लिए लोकल; कठिन समस्याओं के लिए क्लाउड)। सबसे तेज़ पहला कदम: LM Studio में एक छोटी 3B–7B मॉडल चलाएँ।

जिस युग में कोड AI लिखता है, वहाँ ज़्यादा मूल्यवान कौशल "कोड लिखने" से बदलकर "spec लिखने" की ओर जा रहा है — और इस बदलाव को दर्शाने वाला तरीका है Spec-Driven Development (SDD)। SDD में spec परियोजना के केंद्र में सत्य के स्रोत के रूप में रहता है, और एक AI agent तुरंत कोड लिखने के बजाय उसी से डिज़ाइन, विभाजन और इम्प्लीमेंटेशन निकालता है। अहम बात यह है कि हर चरण एक दस्तावेज़ (अक्सर Markdown) छोड़ता है जिसे अगला चरण पढ़ता है। यह शुरुआती-अनुकूल गाइड बताती है कि SDD क्या है (spec ही प्रामाणिक है; कोड एक व्युत्पन्न है), अभी यह क्यों मायने रखता है (यह vibe coding की तकनीकी ऋण और आवश्यकताओं के खिसकने वाली "तीन महीने की दीवार" को डिज़ाइन चरण में ही रोकता है — GitHub के अनुसार "शून्य से दोबारा बनाने" वाले चक्र लगभग दस गुना घटे), बुनियादी चार चरण (Specify → Plan → Tasks → Implement), प्रमुख टूल (90,000+ स्टार और 30 से ज़्यादा समर्थित agent वाला GitHub Spec Kit, Requirements → Design → Tasks प्रवाह और Auto router वाला AWS Kiro, साथ ही BMAD, OpenSpec, Tessl, Google Antigravity और Cursor), इसका उपयोग कब बनाम vibe coding (एक हाइब्रिड: खोजबीन के लिए vibe, डिलीवरी के लिए spec-driven, अनिवार्य इंसानी समीक्षा के साथ), और आज से इसे कैसे आज़माएँ। AI के युग में वे लोग आगे बढ़ते हैं जो ठीक-ठीक परिभाषित कर सकते हैं कि क्या बनाना है, न कि वे जो सबसे तेज़ कोड लिखते हैं।

AI के साथ काम करने में ध्यान का केंद्र prompt engineering से context engineering की ओर खिसक रहा है। Anthropic की परिभाषा उधार लें तो, context engineering है "उन रणनीतियों का समूह जिनसे आप inference के दौरान मॉडल को सौंपे जाने वाले tokens (जानकारी) के सबसे उपयुक्त समूह को चुनते और बनाए रखते हैं" — जो केवल prompt को नहीं, बल्कि context window की हर चीज़ को कवर करता है: system prompt, tools, बातचीत की history, और बाहरी डेटा। यह "context rot" के कारण मायने रखता है: आप जितने ज़्यादा tokens जोड़ते हैं, सटीकता असल में उतनी ही घटती है। Chroma के 2025 अध्ययन ने 18 अग्रणी मॉडलों (GPT, Claude, Gemini और अन्य) का परीक्षण किया और हर एक input के लंबा होते जाने के साथ कमज़ोर पड़ा, जहाँ लंबे context के बीच में रखी जानकारी को नज़रअंदाज़ करना खासकर आसान था ("lost in the middle")। यह शुरुआती-अनुकूल गाइड बताती है कि context engineering क्या है और prompt engineering से इसका क्या संबंध है, context rot क्यों होता है (attention एक सीमित बजट है), context में असल में क्या होता है, छह मुख्य तकनीकें (सही ऊँचाई पर निर्देश, tool चयन, just-in-time retrieval, compaction/सारांश संपीडन, बाहरी memory notes, और sub-agent अलगाव), RAG व Claude Skills से इसका संबंध, और आज से अपनाई जा सकने वाली आदतें जैसे विषय बदलने पर नया session शुरू करना और केवल मुख्य बिंदु पेस्ट करना। मूल विचार: केवल सबसे छोटे, सबसे उपयोगी tokens रखें।

Claude Skills (Agent Skills) पर एक शुरुआती-अनुकूल गाइड — वह व्यवस्था जो Claude को बार-बार वही प्रक्रिया समझाने की झंझट खत्म कर देती है। एक Skill निर्देशों, scripts और संदर्भ सामग्री को एक ही फ़ोल्डर में पैक करती है, जिसका केंद्र एक SKILL.md फ़ाइल होती है जिसमें name, description और चरण रहते हैं। ज़्यादातर समय Claude सिर्फ़ हर skill की छोटी description पढ़ता है, और body को तभी खोलता है जब आपका अनुरोध उससे मेल खाता है — इस डिज़ाइन को progressive disclosure कहते हैं, जो दर्जनों skills इंस्टॉल होने पर भी आपके context को हल्का रखता है। यह लेख बताता है कि Skills क्या हैं, ये क्यों मायने रखती हैं (हर बार prompt चिपकाने का अंत), SKILL.md और न्यूनतम फ़ोल्डर संरचना कैसे लिखें, इसे कैसे बनाएं (आधिकारिक skill-creator या खुद हाथ से, .claude/skills में डालकर, जनवरी 2026 के तुरंत-रीलोड के साथ), Skills MCP (connectivity) और subagents (context अलगाव) से कैसे अलग हैं, वह open standard जिसे अब Claude apps, Claude Code, API और Agent SDK के अलावा Codex CLI, Cursor, Gemini CLI तथा GitHub Copilot ने भी अपनाया है, साथ ही दस्तावेज़ निर्माण और आंतरिक नियम लागू करने जैसे ठोस इस्तेमाल। Anthropic ने इसे 16 अक्टूबर 2025 को घोषित किया, और Simon Willison ने इसे "शायद MCP से भी बड़ी बात" कहा।

9 जून 2026 को Anthropic के पहले सार्वजनिक "Mythos-class" model के रूप में जारी Claude Fable 5 की यहां सिर्फ़ coding के लिए पड़ताल की गई है (पूरी रिलीज़ अलग से कवर है)। संक्षेप में: coding जितनी कठिन, Fable 5 उतना आगे निकलता है। यह SWE-bench Verified पर 95.0% और कठिन SWE-bench Pro पर 80.3% देता है (Opus 4.8 69.2% और GPT-5.5 58.6% के मुकाबले), तथा कठिनतम FrontierCode Diamond पर 29.3% (Opus 13.4% और GPT-5.5 5.7% के मुकाबले, GPT से ~5 गुना), जबकि Terminal-Bench 2.1 पर 84.3% की कांटे की टक्कर है। लेख में तीन-बिंदु डेवलपर सारांश, side-by-side benchmark टेबल और उसे पढ़ने का तरीका, effort-scaling गुण (low 11.5% से max 30.9%, जबकि GPT-5.5 5-6% पर ठहर जाता है), यह असल में किसमें अच्छा है (बड़े multi-file refactor, लंबे autonomous agent run, screenshot से front-end, API डिज़ाइन + tests + docs; Simon Willison ने output को "कई दिनों जितना" आंका पर 5.5 घंटे में $110 से अधिक के साथ इसे धीमा और महंगा कहा), कमज़ोरियां ($10/$50, 500k-1M token session, कब रुकना है गलत आंकता है, review सटीकता में पीछे, Terminal-Bench के लगभग 20% trials में Opus 4.8 पर fallback), routing मार्गदर्शन (डिफ़ॉल्ट Opus 4.8, कठिन 10-20% Fable 5 को, terminal काम GPT-5.5 को), और कहां इस्तेमाल करें (Claude Code, GitHub Copilot, AWS Bedrock, Azure Foundry, Databricks, Anthropic API) कीमत, 1M-token context, 128k max output और June 9-22 मुफ़्त अवधि के साथ शामिल हैं। भारी एकमुश्त काम के लिए Fable 5, रोज़मर्रा के अधिकांश के लिए Opus 4.8। आंकड़े दिशासूचक और scaffold-निर्भर हैं।

"मैंने एक AI से कहा और उसने ब्राउज़र खोला, चीज़ें ढूँढीं, और एक form भी भर दिया।" 2026 में यह अब कोई दिखावटी demo नहीं रहा: agentic browsers (ChatGPT Atlas, Claude for Chrome, Gemini/Chrome, Perplexity Comet) एक साथ आ गए। तो ये असल में कहाँ तक automate करते हैं? हकीकत साफ़-साफ़ तीन स्तरों में बँट जाती है। (1) रिसर्च = production-ready: WebVoyager (असली sites) पर शीर्ष agents 89-98% तक पहुँचते हैं, और चूँकि ग़लत action की क़ीमत कम है, सौंपना यहीं से शुरू करें। (2) Form भरना = हो सकता है, पर जाँचें: इनपुट खुद समर्थित है, फिर भी agents fields को ग़लत label दे सकते हैं या ग़लत submit दबा सकते हैं, इसलिए "AI draft करे, इंसान भेजे" सुरक्षित है। (3) बुकिंग/भुगतान = अभी भी खुद करें: agents CAPTCHA, जटिल JavaScript checkout, two-factor auth और session management पर लड़खड़ाते हैं, और WebArena पर सबसे बेहतरीन भी क़रीब 47-68% ही पाते हैं (~78% इंसानी baseline के मुक़ाबले); OpenAI ने स्वतंत्र Operator (2025/8/31) इसी checkout अविश्वसनीयता के कारण बंद किया। लेख पहले दो तरीके बताता है (उपभोक्ता ब्राउज़र/extension बनाम डेवलपर API/OSS), फिर 2026 के खिलाड़ी मैप करता है, बुकिंग विफल होने की चार दीवारें समझाता है, और सबसे बड़े खतरे — indirect prompt injection — में गहराई से उतरता है (Comet zero-click credential चोरी के प्रति कमज़ोर दिखा और फ़रवरी 2026 में ठीक हुआ; बचाव से पहले 23.6% सफलता बुनियादी बचाव से ~11% और सबसे मज़बूत से ~1% तक घटती है, फिर भी शून्य नहीं)। अंत में पाँच सुरक्षा सिद्धांत। एक बेहतरीन रिसर्च साथी; पैसा हिलाने वाले काम खुद करें।

"ठीक है, AI एजेंट कमाल के हैं — पर मैं इन्हें असल में किस काम के लिए इस्तेमाल करूँ?" यह वही सवाल है जिससे हर कोई बुनियाद सीखते ही टकराता है, और 2026 में इसका जवाब अब भविष्य की बात नहीं रहा: सपोर्ट, सेल्स, अकाउंटिंग, डेवलपमेंट और HR भर में एजेंट रोज़मर्रा का काम संभालने लगे हैं, एक सर्वे बताता है कि 65% कंपनियाँ किसी वर्कफ़्लो को पहले ही ऑटोमेट कर चुकी हैं। यह लेख अमूर्त बातें छोड़कर कार्य-विभाग के अनुसार 10 ठोस उपयोग के उदाहरण असली मिसालों और आँकड़ों के साथ देता है: कस्टमर सपोर्ट, सेल्स लीड-जनरेशन, मार्केटिंग SEO, सॉफ़्टवेयर डेवलपमेंट, IT-ऑपरेशंस, फ़ाइनेंस रिपोर्टिंग, धोखाधड़ी की पहचान, HR भर्ती, रिसर्च, और सप्लाई चेन। साथ ही ऑटोमेट करने योग्य काम पहचानना (दोहराव × मात्रा × निर्णय), ROI की असलियत (McKinsey के अनुसार 3 साल में 3.5x, 3–14-माह लागत-वसूली, 30–60% कटौती, पर केवल 23% बड़े पैमाने पर लागू), और सुरक्षित शुरुआत (एक काम चुनें, छोटे पैमाने पर आज़माएँ, इंसान मंज़ूरी दे, नापें और फैलाएँ) न्यूनतम-अनुमति सुरक्षा के साथ। आँकड़े सर्वे और कंपनियों की घोषणाओं से उद्धृत हैं, प्रवृत्तियों के तौर पर संदर्भ के लिए। अपने काम को दोहराव, मात्रा और निर्णय के नज़रिए से परखें, और अपने सबसे तकलीफ़देह काम से एक छोटा कदम उठाएँ।