बड़े context windows पर भरोसा मत करो

मूल लेख ↗ Hacker News चर्चा ↗

Large Context Windows के साथ अनुभव

  • “dumb zone” की गंभीरता और सीमा को लेकर मजबूत असहमति है।
    • कुछ लोगों को साफ़ गिरावट तब दिखती है जब context विंडो का लगभग 10–20% पार हो जाता है (जैसे 1M विंडो में 100–200k), जहाँ याददाश्त की गलतियाँ बढ़ जाती हैं और “tainted” path बन जाते हैं जिनसे उबरना मुश्किल होता है।
    • अन्य लोग 300–500k, यहाँ तक कि 700–900k tokens के बाद भी स्थिर व्यवहार की रिपोर्ट करते हैं, और कहते हैं कि वे context के बारे में लगभग कभी सोचते ही नहीं।
  • कई लोग बताते हैं कि performance task पर बहुत निर्भर करती है: simple “plumbing” या localized edits लंबे sessions को complex, holistic refactors की तुलना में बेहतर सहन करते हैं।
  • कई यह भी नोट करते हैं कि raw length से ज़्यादा context की quality और consistency मायने रखती है; “debris,” विरोधाभासी instructions, और बार-बार की असफल कोशिशें बाद के reasoning को ज़हरीला कर देती हैं।

Context Management Strategies

  • सामान्य pattern: top-level conversations को छोटा रखें और काम को sub-agents, workflows, या recursive calls में offload करें, जिनके अपने fresh contexts हों।
  • दूसरे लोग समय-समय पर reset करते हैं: plan या current state को markdown (AGENTS.md, DESIGN, ROADMAP, आदि) में summarize करके, उससे एक fresh session शुरू करते हैं, और आगे बढ़ते हैं।
  • कुछ लोग hard caps लागू करते हैं (जैसे विंडो का 15–20%, 200–400k tokens), auto-compaction thresholds, या “no brown M&Ms” checks (जैसे model किसी custom build command को भूल जाए तो fail करना)।
  • एक छोटा समूह context को बहुत aggressively minimize करता है: हर feature के लिए एक conversation, manual “/last”-style compaction, या coding से पहले design docs/PRDs पर insist करना।
  • कई लोग तर्क देते हैं कि repo में मौजूद external documents, live context या proprietary memory systems में facts ठूँसने से बेहतर “memory” हैं, क्योंकि वे गलत या stale data भी store कर सकते हैं।

Model, Harness, और Sampling Differences

  • व्यवहार model version और tooling के साथ बदलता है। कुछ लोग बताते हैं कि पुराने या सस्ते models जल्दी degrade होते हैं; नए frontier models और कुछ tools (जैसे agent frameworks, workflows) long-run reliability सुधारते हैं।
  • Attention mechanisms, tokenizer granularity, और sampling strategies (जैसे min_p जैसे “modern” samplers) को अनुभवों के अलग होने का संभावित कारण बताया जाता है, लेकिन यह अभी भी anecdotal है।

Cost, UX, और Vendor Incentives

  • एक camp कई agents को parallel में चलाता है और उन्हें score करता है (जैसे ELO-style), भले ही token use बहुत अधिक हो; उनका तर्क है कि outcome और time savings, cost से ज़्यादा महत्वपूर्ण हैं।
  • दूसरे इसे wasteful कहते हैं और prompt caching, incremental updates, तथा tokens कम करने के लिए stricter scoping पर ज़ोर देते हैं।
  • फिर भी कई लोग 1M-token windows को एक बड़ा UX improvement मानते हैं, भले ही उन्हें हमेशा सुरक्षित रूप से उपयोग न किया जाए।

Rigor, Benchmarks, और Uncertainty

  • कई लोग इस चर्चा की आलोचना करते हैं कि यह मुख्यतः anecdotal “gardening advice” है और ऐसे systematic evals की माँग करते हैं जो standardized tests से पहले context को pre-fill करें।
  • दूसरे जवाब देते हैं कि model churn तेज़ होने के कारण stable, up-to-date benchmarks बनाना कठिन है, इसलिए practitioners बदलती heuristics पर भरोसा करते हैं।