आपके कोडबेस के लिए रिट्रीवल अभी भी 1M-Token विंडो से बेहतर है

कुछ हफ्ते पहले मैं एक साइड प्रोजेक्ट में auth बग डीबग कर रहा था — एक TypeScript बैकएंड, शायद 140 फाइलें, आराम से एक मिलियन टोकन के भीतर। मेरे पास 1M-token मॉडल था, इसलिए मैंने आलसी रास्ता अपनाया: पूरे src/ ट्री को एक प्रॉम्प्ट में डाला और एजेंट से पूछा कि session token कहाँ रिफ्रेश हुआ और कभी-कभी क्यों नहीं हुआ।

उसने सब कुछ पढ़ा। उस एक टर्न के लिए input tokens में मुझे अच्छी रकम खर्च करनी पड़ी। और उसने आत्मविश्वास से एक refreshToken हेल्पर की ओर इशारा किया जो सही लगा — लेकिन गलत था। अलग-अलग मॉड्यूल में दो थे, और जिसे उसने चुना वह उस पाथ पर नहीं था जो fire हुआ। मैंने उसे पूरा haystack दिया और उसने बीच से एक horoscope वाला needle पकड़ लिया।

फिर मैंने वह सेशन बंद किया, उसी मॉडल के साथ एक नया सेशन खोला, और इसे सामान्य तरीके से काम करने दिया: ट्री लिस्ट करो, refreshToken के लिए grep करो, जो तीन फाइलें मिलीं उन्हें पढ़ो, imports follow करो। इसने असली बग को लगभग एक-चौथाई tokens में और दो-तिहाई wall-clock time में ढूंढ लिया। वही मॉडल। वही रेपो। फर्क पूरी तरह इस बात में था कि मैंने उसे code कैसे दिया।

संक्षेप में: एक असली कोडबेस के लिए, सब कुछ एक विशाल कॉन्टेक्स्ट विंडो में डालना आमतौर पर बुरा कदम है — इसलिए नहीं कि विंडो बहुत छोटी है, बल्कि इसलिए कि जैसे-जैसे आप इसे भरते हैं मॉडल मापनीय रूप से कम विश्वसनीय हो जाता है, और code इस विफलता के लिए worst-case input है। टार्गेटेड रिट्रीवल — grep, symbol indexing, dependency-aware reading — लागत, लेटेंसी, और सटीकता में अधिकांश code tasks के लिए जीतती है। लंबा कॉन्टेक्स्ट कुछ विशिष्ट मामलों में जीतता है, और मैं आपको अंत में नियम दूँगा।

विंडो नंबर असली है; इस्तेमाल होने वाला हिस्सा नहीं

पहले वह हिस्सा जो सच है: बड़े नंबर मौजूद हैं। जून 2026 तक तीन प्रमुख कोडिंग मॉडल — Claude Opus 4.8, GPT-5.5, और Gemini 3.1 Pro — सभी 1M-token विंडो के साथ आते हैं, और तेरह से अधिक होस्टेड frontier मॉडल 1M या उससे अधिक का विज्ञापन करते हैं (Morph का context-window comparison)। Anthropic और OpenAI ने long-context surcharge भी हटा दिया है, इसलिए अब पूरी विंडो में एक ही per-token rate पर billing होती है।

समस्या यह है कि advertised और usable दो अलग नंबर हैं। 2026 में independent recall testing लगातार दिखाती है कि effective capacity label से काफी कम है — एक roundup effective context को nominal का लगभग 50–65% बताता है, और MRCR multi-needle scores रिपोर्ट करता है जो विंडो के पिछले आधे हिस्से में cliff से गिरते हैं: Gemini 3.1 Pro 128K–256K बैंड में ~84.9% recall रखता है और 512K–1M बैंड में 26.3% तक गिर जाता है (CodingFleet का "context window lie" writeup)। सटीक percentages को directional मानें — ये vendor-benchmark figures हैं, controlled study नहीं — लेकिन आकार हर जगह consistent है: recall विंडो भरने से पहले ही कम हो जाती है।

इस गिरावट का एक नाम और research trail है, और यह code के लिए लगभग किसी भी अन्य चीज़ की तुलना में अधिक मायने रखता है।

Code पूर्ण विंडो के लिए worst-case input क्यों है

जब आप एक रेपो को एक प्रॉम्प्ट में भरते हैं तो दो well-replicated effects आपके खिलाफ काम करते हैं।

Lost in the middle. Liu et al. paper (TACL में प्रकाशित) ने दिखाया कि model accuracy एक U-shaped function है जहाँ relevant information बैठती है: जब यह context की शुरुआत या अंत में होती है तो सबसे अधिक, और जब यह बीच में दबी होती है तो 30% से अधिक गिर जाती है — और यह छह model families में multi-document QA और key-value retrieval पर valid था। कोडबेस "बीच में relevant information" के अलावा कुछ नहीं है। जिस function की आपको जरूरत है वह शायद ही पहली या आखिरी file हो जो आपने paste की।

Context rot. Chroma का 2025 study 18 frontier models का परीक्षण किया — Claude Opus 4 / Sonnet 4 / 3.7 / 3.5 / Haiku 3.5, OpenAI o3 और GPT-4.1 family, Gemini 2.5 Pro/Flash, और तीन Qwen3 sizes — और पाया कि सामान्य tasks जैसे string ढूंढना या repeated words को replicate करना पर भी input length बढ़ने पर performance गिरती है (Chroma का "Context Rot" report)। वह finding जो हर code-agent builder को uncomfortable करे: LongMemEval task पर, हर model ने full ~113k-token history के साथ उसी relevant content के focused ~300-token excerpt की तुलना में worse किया। सही चीज़ के अधिक tokens, bulk में प्रस्तुत, छोटे curated slice से कम score किए।

उस report में एक detail है जो लगभग funny है अगर आप code लिखते हैं: जब haystack "ideas का logical flow preserve" करता है तो models worse score किए बनिस्बत shuffle किए जाने के। एक repository maximally logically structured है — imports, call graphs, type definitions, ordered modules। आप मॉडल को वह exact input shape दे रहे हैं जिसे वह सबसे बुरी तरह handle करता है।

और code prose की तुलना में failure को अधिक कठोरता से दंडित करता है। अगर chatbot किसी लंबे document का एक वाक्य miss करता है, तो वह थोड़ा vaguer जवाब देता है। अगर code agent असली refreshToken definition miss करता है, तो वह code लिखता है जो एक ऐसे method को call करता है जो exist नहीं करता या गलत function को patch करता है — और वह confidently ऐसा करता है। जैसा कि agent retrieval के एक teardown में कहा गया: "coding contexts में RAG का failure mode silent और compounding है" (MindStudio)। गलत retrieval error नहीं करती। वह ship हो जाती है।

Code के लिए "retrieval" का मतलब क्या है (यह ज्यादातर embeddings नहीं है)

"Retrieval" सुनने पर लोग vector database की कल्पना करते हैं। Code के लिए, जो agents actually ship होते हैं — Claude Code, Cursor, Devin — वे ज्यादातर पहले उसकी ओर नहीं जाते। वे उसी तरह navigate करते हैं जैसे एक अनुभवी developer करता है: file tree देखो, symbol grep करो, जो match करती फाइलें हैं उन्हें पढ़ो, import chain follow करो (MindStudio)। Claude Code का primary search tool ripgrep है — fast, exact, line-numbered text matching जो किसी भी repo पर zero preprocessing के साथ काम करती है।

Vectors code के लिए default नहीं हैं, और इसका कारण nostalgia नहीं है। एक उपयोगी framing तीन layers है, केवल जरूरत पड़ने पर escalate करें (AI agents के लिए Code search):

• Lexical (ripgrep): exact-match, milliseconds, gitignore-aware। आपका default।
• Structural (ast-grep): AST-pattern matching — "हर async function ढूंढो," "हर catch-and-rethrow" — ऐसी चीजें जो regex cleanly express नहीं कर सकती। तब escalate करें जब query shape के बारे में हो, strings के बारे में नहीं।
• Semantic (embeddings / repo-map): natural-language conceptual queries। Last resort।

Semantic last resort क्यों है और first क्यों नहीं? क्योंकि code agent जो queries generate करता है वे छोटी और symbol-shaped होती हैं — auth flow, user service, refreshToken — और यह वही format है जो embedding search को तोड़ देता है। CoREB benchmark ने पाया कि short keyword queries "tested लगभग हर semantic model को near-zero nDCG@10 पर collapse कर देती हैं।" Embeddings meaning similarity capture करती हैं; code dependencies, imports, और type definitions का एक graph है, और similarity वह relation नहीं है जो आप query कर रहे हैं। दो functions semantically near-identical हो सकते हैं और structurally unrelated; जिसकी आपको जरूरत है वह call path पर है, वह नहीं जो alike reads करे।

इससे semantic indexing useless नहीं होती — यह एक specialist tool बनती है। जब यह अपनी भूमिका निभाती है, अच्छे implementations arbitrary text windows embed नहीं करते। वे tree-sitter के साथ real units में parse करते हैं — functions, classes, interfaces उनके docstrings के साथ intact — उन chunks को whole रखते हैं, और vector similarity को BM25 keyword matching plus dependency tracing और blast-radius analysis के लिए call-graph tools के साथ pair करते हैं (opencode-codebase-index)। Code retrieval का पूरा game यही है: dependency-aware, symbol-boundary chunking with a keyword fallback — "हर 512 tokens पर file split करो और उम्मीद करो" नहीं।

Cost और latency का गणित जो कोई नहीं करता

एक second के लिए accuracy को अलग रखें और बस bill चलाएं। मान लें एक medium repo 600K tokens है। उसे एक turn में डालना मतलब हर turn of the conversation में 600K input tokens pay करना जब तक आप carefully cache नहीं कर रहे — और cache होने पर भी, आप model के उस सब पर attend करने की latency carry करते हैं। एक retrieval pass की जगह tree (कुछ KB), एक grep result (कुछ सौ tokens), और शायद चार files जो आप actually पढ़ते हैं (~15K tokens) भेजी जाती है। यह rounding-error difference नहीं है; यह per turn एक से दो orders of magnitude का अंतर है, debugging session में हर turn से गुणा।

Latency उसी curve पर चलती है। 600K tokens पर reasoning करने वाला model 18K पर reasoning करने वाले उसी model से first token और overall दोनों में slower है। एक interactive loop में जहाँ आप bug chase करने के लिए बीस turns कर रहे हैं, यह minutes of dead waiting में compound हो जाता है। Retrieval हर turn को small रखती है, इसलिए हर turn fast है, इसलिए loop tight रहती है।

और एक quieter cost है: attention budget। विंडो में हर irrelevant file एक distractor है, और Chroma ने दिखाया कि distractors measurably accuracy drag करते हैं — एक distractor ने hurt किया, चार ने compound किया। किसी भी दिए गए प्रश्न के लिए context में एक पूरा repo हजारों distractors है। आप न केवल अधिक pay कर रहे हैं और slower हो रहे हैं; आप अधिक pay कर रहे हैं और slower हो रहे हैं और more wrong भी हो रहे हैं।

जब Long Context वास्तव में जीतता है

यह "retrieval हमेशा" नहीं है। एक real envelope है जहाँ सब कुछ डालना right call है, और यह repo size और task shape से defined है, न कि उस window के size से जिसके लिए आप pay कर रहे हैं।

Long context जीतता है जब:

• पूरा repo genuinely headroom के साथ fit हो जाए — मान लें ~150K tokens के नीचे, विंडो के high-recall front के भीतर — और task को cross-file reasoning की जरूरत हो जिसे piecemeal retrieve करना मुश्किल हो। एक small repo जहाँ सब कुछ matter करता है exactly वह case है जहाँ retrieval over-complicates करती है।
• आपको one shot में whole-file या whole-module reasoning चाहिए — एक single big file जिसे आप fully refactor करना चाहते हैं, एक module का top-to-bottom security read, एक architectural review जहाँ model को relationships एक साथ view में रखने की जरूरत है। Retrieval इसे fragment करती है; context इसे preserve करता है।
• यह एक one-shot, read-only pass है, iterative loop नहीं। एक single "इस PR को review करो" या "यह service कैसे काम करती है summarize करो" call cost को एक turn में amortize करता है। Long context को kill करने वाली economics — हर turn पर full window pay करना — तब नहीं bite करती जब केवल एक ही turn हो।

Retrieval बाकी सब जगह जीतती है, जो practically अधिकांश work है: कोई भी repo जो comfortably fit नहीं होता, कुछ भी iterative, कुछ भी जहाँ आपको general understanding की बजाय specific definition चाहिए, और कुछ भी जहाँ एक silently-wrong retrieval broken code ship करे।

एक rough rule जो मैं actually use करता हूँ: अगर task का relevant slice repo से छोटा है, retrieve करो। अगर task है पूरा repo और repo window के पहले ~15% में fit हो जाए, तो load करो। अधिकांश दिनों, slice repo से छोटा होता है।

Takeaway

1M-token विंडो एक real capability है, और इसके लिए surcharge-free pricing use करना worth है उन jobs के लिए जिनमें यह अच्छा है — code का one-shot review जो fit हो जाए, whole-module reasoning, occasional small repo जहाँ सब कुछ relevant हो। लेकिन यह जानने का substitute नहीं है कि आपका code कहाँ रहता है। एक working code agent के लिए, boring stack — tree list करो, symbol grep करो, match होने वाली चार files पढ़ो, imports follow करो, केवल तब AST या embeddings पर escalate करो जब keyword search खाली आए — impressive वाले से सस्ता, faster, और अधिक accurate है। Spec sheet पर बड़ा नंबर एक option है, instruction नहीं। ज्यादातर समय, इसे मत भरो।