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

 (garrit.xyz)
6 पॉइंट द्वारा GN⁺ 22 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • LLM का context window मॉडल के तेज़ी से काम करने वाले smart zone और ध्यान कम होने पर पहले के निर्देश भूलने लगने वाले dull zone में बंटा हो सकता है
  • इनके बीच की सीमा लगभग 100k tokens के आसपास दिखती है, और advertised context window size बड़ा होने का मतलब यह नहीं कि उतनी पूरी कार्य-सीमा वास्तव में उपयोगी हो
  • Coding agents सिर्फ़ file पढ़ने, लंबी debugging, और बड़े test runs से भी तेज़ी से tokens खर्च करके 100k tokens तक पहुँच सकते हैं
  • RULER और Chroma की context rot report दिखाती हैं कि effective context advertised संख्या का सिर्फ़ एक हिस्सा होता है, और window भरने पर performance धीरे-धीरे गिरती जाती है
  • लंबे sessions को auto-summarize करने से बेहतर यह है कि जानकारी को session के बाहर सीधे लिखे गए specs और छोटे artifacts में छोड़ा जाए, ताकि काम smart zone में बना रहे

context window की वास्तविक सीमा

  • LLM context window मॉडल के तेज़ smart zone और ध्यान घटने वाले dull zone में बंटा हो सकता है
    • dull zone में मॉडल कुछ मिनट पहले दी गई बातों को भूलना शुरू कर देता है
    • यह सीमा लगभग 100k tokens के आसपास होती है
    • advertised context window size बड़ा होने पर भी यह सीमा गायब नहीं होती
  • Coding agents आज के इस्तेमाल के तरीके में tokens बहुत तेज़ी से खर्च करते हैं
    • कुछ file reads, लंबा debugging session, और बड़े test execution से ही 100k tokens तक पहुँचा जा सकता है
    • Vendors 200k, 1M, 2M context windows का विज्ञापन करते हैं, लेकिन ये संख्याएँ usable working set को नहीं दर्शातीं
  • बड़े context windows ज़्यादातर marketing numbers के क़रीब हैं
    • इनके पीछे की architecture काम करती है, लेकिन यह उस समस्या को ढक देती है जिसे base attention mechanism वास्तव में हल नहीं कर पाता
    • Product में दिखने वाली संख्याएँ हर release के साथ बढ़ती हैं, लेकिन उपयोगी हिस्सा उसी रफ़्तार से नहीं बढ़ता
  • RULER और Chroma की context rot report दिखाती हैं कि effective context advertised संख्या का सिर्फ़ एक हिस्सा है
    • context window भरने पर performance धीरे-धीरे घटती जाती है

session को छोटा रखने का काम करने का तरीका

  • नए agents लंबे sessions संभालने के लिए automatic compression features अपनाने लगे हैं
    • Claude Code session लंबा होने पर history को summarize करके नए सिरे से शुरू करने वाला auto-compact करता है
    • यह तरीका मददगार है, लेकिन तब काम करता है जब आप पहले ही dull zone में समय बिता चुके होते हैं
    • summary भी वही model बनाता है जिसकी performance पहले से घट चुकी होती है
  • बेहतर handoff तरीका यह है कि नया session खोला जाए और सीधे लिखी गई spec सौंपी जाए
    • खुद लिखी गई spec, automatic summary की तुलना में ज़्यादा मज़बूत signal देने वाला handoff material बनती है
    • क्योंकि आगे क्या महत्वपूर्ण है, यह इंसान सीधे तय कर सकता है
    • यह तरीका breadcrumb approach जैसा है, जिसमें अगला session या अगला व्यक्ति साफ़-सुथरे ढंग से आगे बढ़ सके, ऐसे artifacts छोड़े जाते हैं
  • obra/superpowers और mattpocock/skills agent workflow को छोटे, नाम वाले artifacts के आसपास बनाते हैं
    • PRD, plans, skills, और sub-agent handoff ऐसे artifacts के उदाहरण हैं
    • हर artifact जानकारी को live session से बाहर ले जाता है ताकि अगला session उसे पढ़ सके
    • यह तरीका work session को smart zone में बनाए रखने में मदद करता है
  • context window को budget की तरह देखना चाहिए
    • मानकर चलना चाहिए कि वास्तव में मददगार हिस्सा आगे के कुछ chunks ही होते हैं
    • live session से written artifact में ले जाई गई जानकारी उन चीज़ों को कम करती है जिन पर model के attention को संघर्ष करना पड़ता है

संबंधित पढ़ाई

2 टिप्पणियां

 
baam12 15 시간 전

1 लाख तो छोड़िए, 40-50 हज़ार tokens पर ही जूझता हुआ दिखता है।
 
GN⁺ 22 시간 전
Hacker News की राय

  • AI की बुनियादी बातें सीखना काफ़ी मज़ेदार है, लेकिन अभी यह जिस दिशा में जा रहा है, उससे मैं सहमत नहीं हूँ
    ऐसे थ्रेड्स की टिप्पणियाँ कितनी बेचैन करने वाली लगती हैं, इसे शब्दों में कहना मुश्किल है। “XYZ मेरे लिए ऐसे काम किया” जैसी सद्भावना वाली निजी बातें Facebook के pet care या cooking thread की सलाह जैसी लगती हैं
    3D printing Facebook groups तो और भी बुरे हैं; अगर आप print तो करते हैं लेकिन यह भी समझना चाहते हैं कि असल में क्या हो रहा है, तो शायद आप समझ रहे होंगे कि मेरा क्या मतलब है
    LLM की दुनिया, ख़ासकर cloud LLM की दुनिया में, साझा rigor पूरी तरह बिखर गई है, और आख़िर में सब कुछ जादुई नकल तक सिमटता हुआ लगता है। फिर कोई भी किसी और से ज़्यादा सही या ग़लत नहीं रह जाता
    माहौल कुछ ऐसा है जैसे, “क्या आपने context को Dawn dish soap से साफ़ करके सुखाया, फिर glue stick की एक परत लगाई?”
    मैं मदद करने की कोशिश कर रहे लोगों के बारे में बहुत कठोर नहीं होना चाहता। बस यह दूसरे विषयों के थ्रेड्स से बहुत अलग महसूस होता है। आम तौर पर किसी के सुझाव पर दूसरे लोग बहस करते हैं या उसे निखारते हैं, और कभी कोई bash history selection जैसी चीज़ समझा देता है तो ज़िंदगी बदल जाती है, लेकिन ऐसे थ्रेड आख़िर में “अगर धमकाने से काम हो जाता है, तो क्या यह अजीब नहीं है?” पर पहुँच जाते हैं

    • LLM workflow का मनमाना और non-deterministic स्वभाव सच में असहज करता है। embedded/systems की पुरानी पृष्ठभूमि से आने के कारण मैंने हमेशा determinism और reproducibility को प्राथमिकता दी है
      फिर भी agents कमाल के हैं, और “thought process designer” बनना भी मज़ेदार है। मैं अब पीछे नहीं लौटूँगा। अगर आज AI development रुक भी जाए, तो भी मेरा career पहले जैसा नहीं रहेगा
    • tech industry में LLM आने से बहुत पहले से भी ऐसा हमेशा होता आया है
      मैंने बहुत ज़्यादा ऐसी meetings झेली हैं जहाँ फ़ैसले objective और measurable criteria की बजाय “थोड़ा ज़्यादा मशहूर company ऐसा करती है” के आधार पर होते थे। यहाँ तक कि उस company के उस approach को आम तौर पर न अपनाने के सबूत भी हैरान कर देने वाली हद तक असरहीन रहते थे
    • IT सलाह में मूल रूप से हमेशा कुछ न कुछ ऐसा तत्व रहा है। जितने complex systems और outcomes होते हैं, उतना ही “बेहतर” और “बदतर” को साफ़-साफ़ परिभाषित करना मुश्किल हो जाता है
      ऊपर से LLM के बहुत non-deterministic होने की बात जोड़ दें, तो LLM सलाह लगभग gardening advice जैसी बन जाती है
      यहाँ तक कि “benchmarks” भी ज़्यादातर किसी की intuition को कुछ हद तक सफलतापूर्वक crystallize करने की कोशिश जैसे ही लगते हैं
    • इस झुंझलाहट से मैं गहराई से सहमत हूँ और कुल मिलाकर बात भी सही लगती है। जब भी मैं LLM-आधारित workflow को formalize करने की कोशिश करता हूँ, तो फिर निराशा होती है क्योंकि किसी को ठीक-ठीक पता नहीं लगता कि कुछ चीज़ें क्यों काम करती हैं और कुछ क्यों नहीं
      इसलिए मैं आख़िरकार /plan पर लौट आता हूँ और कहता हूँ, “implementation को दोहराने से पहले, बाद के लिए इसे Markdown document में लिख लो,” और उम्मीद करता हूँ कि शायद अगले महीने तक कुछ ज़्यादा rigorous और rationally grounded चीज़ सामने आए
      मैं glue stick बिल्कुल इस्तेमाल नहीं करता क्योंकि उसकी ज़रूरत नहीं पड़ती। लेकिन Dawn, Bambu build plate को फिर से ठीक से चिपकने लायक बनाने में काफ़ी असरदार लगती है। मैंने इसे ढूँढ़कर ख़ास तौर पर नहीं लिया था, यह पहले से बर्तन धोने के लिए घर में था। IPA काम नहीं कर रहा था, तो मैंने Dawn आज़माया, और उसने कई बार prints को फिर से अच्छी तरह चिपकने में मदद की। अभी N=30 तक नहीं पहुँचा हूँ
    • दिमाग़ में जो “shared rigor” है, शायद वही अपने-आप में एक भ्रम हो, और LLM तथा उसकी context समस्या बस उसे उजागर कर रहे हों
      tech industry में दशकों बिताने के बाद भी मैंने rigor बहुत कम देखी है। tools बढ़ते रहे, paradigms आते-जाते रहे और फिर लौटते रहे, और किसी भी चीज़ को मापने के लिए हमेशा अलग units वाले competing yardsticks मौजूद रहे। power और signal की physics, और silicon wafer की हावी लागतों से आगे निकलते ही, बहुत पुरानी और कम-से-कम कुछ गिनी-चुनी disciplines की तुलना में हम लगभग सभी बस अलग-अलग skill level वाले tinkerer ही हैं
      context limits से निपटना अपेक्षाकृत आसान रहा है। spec तय करो और scope सीमित करो। LLM से अच्छे नतीजे चाहिए हों, तो उसे clear specifications और strong guidance चाहिए
      लेकिन यह भी शायद अभी की अस्थायी, जोड़-तोड़ वाली practical sense भर है। हो सकता है 90 दिनों बाद यह बोझ भी ग़ायब हो जाए, और एक simple prompt से world-class operating system, programming language, और दोनों के लिए mathematical formal foundations तक तैयार हो जाएँ

  • एजेंट लूप पर एक साधारण-सा constraint लगाकर context size problem से बचा जा रहा है। user के top-level conversation thread में सभी tool calls रोक दिए जाते हैं। जिन कामों में tool call चाहिए, वे सिर्फ agent की recursive call के अंदर होते हैं, और सिर्फ result caller को वापस किया जाता है
    10 लाख LOC से बड़े codebase में भी पूरे दिन वही high-level conversation चलाते हुए meaningful token limit तक नहीं पहुँचे। compression या summarization tricks की भी ज़रूरत नहीं पड़ी। recursive call में 5 करोड़ token जला देने पर भी root conversation thread 1 लाख token तक नहीं छूता
    हर बार agent फिर से Narnia में उतरता है तो “bootstrap” करने वाला कुछ दोबारा काम करना पड़ता है, लेकिन हर चीज़ को साथ लेकर चलने वाले बड़े flat context से यह कहीं ज़्यादा efficient है
    Recursion token usage control करने में बहुत effective है, लेकिन इसकी limits भी हैं। recursion depth 1 से आगे कभी फायदा नहीं मिला। agent को कुछ बार कोशिश करते देखा, लेकिन असली performance नहीं आई। बाहरी symbolic recursion शायद frontier models को सिखाई गई चीज़ नहीं है। context के अंदर recursion की नकल करने में यह शानदार है, लेकिन अगर मकसद token usage घटाना है, तो वह उलटी दिशा है

    • अगर आप Claude Code इस्तेमाल करते हैं, तो बस इसे कहिए कि सारे काम workflow के अंदर करे। उसके लिए tool मौजूद है, और Opus 4.8 के साथ आया feature लंबी jobs में थोड़ा बेहतर लगता है
      इस बिंदु पर main conversation सिर्फ काम coordinate करने की भूमिका निभाती है
    • सहज रूप से यह बात समझ में आती है। आप कौन-सा harness इस्तेमाल कर रहे हैं कि ऐसे constraints सेट कर सकते हैं, और यह कैसे सेट करते हैं, यह जानने की जिज्ञासा है
    • लगता है Claude Code कुछ मामलों में यह अपने आप करता है। शायद “यह बहुत context खा लेगा” जैसी कोई heuristic है, और उसी आधार पर यह sub-agent को सौंपने का फैसला करता है
      problem solving या data analysis flow में यह अक्सर दिखता है, जहाँ data collection और aggregation sub-agent को दे दिए जाते हैं, और सिर्फ summarized result वापस लिया जाता है
      इसी तरह main agent design docs या Markdown files में context बनाए रखते हुए आगे बढ़ता और उन्हें update करता है। इससे कभी भी clear, restart, या handoff करना संभव हो जाता है
    • मैं एक अलग तरीका इस्तेमाल कर रहा हूँ, और अभी भी समझ रहा हूँ कि यह कितना अच्छा काम करता है। recursion में जाने के बजाय, जब context बहुत बड़ा हो जाता है या flow अटक जाता है, तो agent summary/report/reflection चरण से गुजरकर thread को restart कर सकता है, मुख्य निष्कर्ष persistent memory में लिख सकता है, और prompt को फिर से लिख सकता है
      एक तरह से यह tail call optimization वाली recursion के करीब है
      कुछ मायनों में यह spec-driven approach का सामान्यीकृत रूप है, जहाँ formal spec के साथ-साथ inherited buffer भी memory में रहता है
    • यह इसलिए दिलचस्प है क्योंकि context और token usage कम करना user के लिए फायदेमंद है, लेकिन AI providers के वित्तीय हितों से मेल नहीं खाता
      expert न होने पर भी यह “सरल तरकीब” context problem को ठीक करने और token usage पर कहीं ज्यादा सघन नियंत्रण देने वाली लगती है। इसे HN comment में साझा करने के लिए धन्यवाद। हो सकता है कि आगे चलकर जानकार लोग AI agents का इस्तेमाल करने का तरीका बदल दें। इसके साथ चलना मुश्किल है

  • Anthropic ने subscription plan में 10 लाख token context window देने के बाद से Opus में मुझे ऐसा अनुभव नहीं हुआ। आम तौर पर भी मैं 5 लाख token पार कर देता हूँ, और कभी-कभी 8 लाख token के करीब जाने पर भी यह समस्या नहीं दिखती
    असली सीमा के करीब, यानी 9 लाख token से ऊपर, कुछ हद तक देखा है, लेकिन लेखक ने जितनी गंभीर बात कही है उतना नहीं
    वैसे भी single task या आपस में इतने जुड़े task set में कि एक ही context बनाए रखना पड़े, context window को इतना भर देना कम ही होता है; आम तौर पर यह 2 लाख से 6 लाख के बीच रहता है
    इसका मतलब यह नहीं कि किसी को यह अनुभव नहीं होता, लेकिन कुछ लोगों को यह इतना अक्सर दिखता है कि उन्होंने इसका नाम तक रख दिया है, यह अजीब लगता है

    • ऐसी बातें मैं अक्सर देखता हूँ, लेकिन Opus models को 1 लाख token से कम पर भी बुनियादी recall mistakes करते कई बार देखा है, इसलिए यह दावा अविश्वसनीय लगता है
      मेरे हिसाब से Opus का smart zone 60 हज़ार token से कम है। Opus 4.7 और 4.8 अधिक granular tokenizer की वजह से और खराब हैं
    • Opus 4.6, 2 लाख पार करते ही जैसे नशे में लगने लगता था; 4.7 मैंने छोड़ दिया; 4.8 लगभग 3.5 लाख तक ठीक था; और Fable सीमित testing में 4 लाख से ऊपर भी शानदार था
      quality ऊपर जाती हुई लगती है
    • हर कोई वही model और harness नहीं इस्तेमाल कर रहा, और न ही models का इस्तेमाल एक ही तरीके से हो रहा है
      model और model version अलग-अलग attention architecture इस्तेमाल करते हैं, और इसका लंबा context performance पर असर पड़ता है। long-context training की मात्रा और प्रकार भी निश्चित ही अलग होंगे
      agents context को कैसे बनाते हैं और context compression कैसे implement करते हैं, यह भी अलग होता है
      जब तक वही model, वही agent/harness, और बहुत मिलता-जुलता task न हो, तब तक context size से जुड़ा model behavior सबको एक जैसा अनुभव होगा, ऐसा मानने का कारण नहीं है
    • मैं अक्सर 3 लाख पार करता हूँ और 8 लाख पर भी काम किया है, लेकिन यह साफ़ तौर पर दिखाई देने वाली समस्या है
      कुछ problems में बड़ा context window काम कर सकता है, लेकिन मुझे 3 लाख से कम वाले छोटे context की ओर झुकना ज्यादा प्रभावी लगता है
    • सहमत। Claude family इस मामले में हर release के साथ बेहतर होती गई है
      Opus 4.5 में 2 लाख limit के पास पहुँचते ही tool calls fail होने लगते थे, Opus 4.6 लगभग 3 लाख तक जाता था फिर confuse होने लगता था, Opus 4.7 को लगभग 4 लाख तक बढ़ाया जा सकता था लेकिन उसके बाद dumb zone शुरू हो जाता था। Opus 4.8 में कुछ sessions 5 लाख से आराम से ऊपर गए
      Fable के साथ समय सीमित रहा, लेकिन कुछ sessions 8 लाख से 9 लाख तक बिना समस्या के गए

  • Opus के हाल के versions 1 लाख से ऊपर भी ठीक हैं, लेकिन मैं आम तौर पर इसे 2 लाख से नीचे रखने की कोशिश करता हूँ
    इसी वजह से मुझे लगता है कि तथाकथित memory system अक्सर model को और बेवकूफ बनाने वाली गलती है। model के पास memory नहीं, सिर्फ context होता है, और जितने ज़्यादा गैर-ज़रूरी facts आप context में ठूंसते हैं, उतना ही समस्या के लिए उपलब्ध context कम हो जाता है। जितनी कम रुकावट, उतना बेहतर result
    agent से कुछ “याद” रखने का तरीका यह है कि उसे काम को वैसे document करने दिया जाए जैसे कोई मानव developer दूसरे developers के लिए अनुकूल project बनाते समय करता है। index page वाले अच्छे dev docs और checklist वाली अच्छी planning को concise Markdown files में सहेजकर repository में commit कर देना model के लिए आदर्श memory है, और यह समझने के लिए भी आदर्श दस्तावेज़ है कि model आखिर कर क्या रहा था। इससे लोगों या दूसरे models द्वारा code review में भी मदद मिलती है, और इसका कोई downside नहीं है

    • कम-से-कम मेरे मामले में, Opus लगातार memory में कुछ-न-कुछ लिखता रहता है, लेकिन वही गलती दोहराने से पहले उस memory को देखना लगातार भूल जाता है
      इसलिए “memory check करना याद रखो!” फिर से memory में लिख दिया जाता है। यह निश्चित ही कोई बहुत अच्छा working system नहीं है
    • “Memory” system developers को यह महसूस कराने का तरीका है कि वे AI में योगदान दे रहे हैं

  • यहाँ लगभग सभी टिप्पणियाँ व्यक्तिगत अनुभव पर अपील कर रही हैं। इसके उलट, मूल पोस्ट कई मॉडलों के लिए कुछ मानकीकृत टेस्ट परफ़ॉर्मेंस की तुलना करने वाले दो शोध-पत्रों का संदर्भ देती है
    मैं यह नहीं कह सकता कि वे टेस्ट कितने अच्छे हैं, लेकिन LLM परफ़ॉर्मेंस जैसी अस्पष्ट और व्यक्तिपरक चीज़ पर किस्सागोई-आधारित सबूत से वे बदतर नहीं हो सकते

    • अगर किस्सागोई-आधारित सबूत और जोड़ूँ, तो मैंने जो भी टेस्ट किए उनमें Llama परिवार का instruction following बहुत खराब था। RULER के दूसरे मॉडलों के बारे में मैं ज़्यादा नहीं जानता
      Chroma के नतीजों में Sonnet 4 दिखता है, और मेरे अनुभव में भी Sonnet 4 बहुत खराब था। वही prompt जो Sonnet 4.5 में पूरी तरह काम करता था, Sonnet 4 में बुरी तरह फेल हो गया
      मैं एक नया टेस्ट देखना चाहूँगा जिसमें नवीनतम frontier models और open weights models दोनों शामिल हों। frontier models हमेशा निर्देश बेहतर फ़ॉलो करते और विषय से कम भटकते लगते हैं, और इसे सपोर्ट करने वाला डेटा अच्छा होगा
    • वे शोध 2024 और 2025 के डेटा पर आधारित हैं। वे मौजूदा Claude मॉडलों पर लागू नहीं होते

  • AI के product manager की तरह व्यवहार करते हुए, और हर बनने वाली feature के लिए छोटा PRD लिखने की सख्त माँग करके, मुझे काफ़ी अच्छे नतीजे मिले हैं
    इससे समय बीतने पर भी यह रेफ़र करना आसान रहता है कि क्या बनाया गया था, और हर feature में कम भटकाव होता है। मैं हर feature के लिए अलग बातचीत रखता हूँ
    मेरे लिए यह एक ठीक-ठाक समझौता है जो derail होने से बचाता है, लेकिन ज़रूरत पड़ने पर पुराने फ़ैसलों का संदर्भ लेने देता है। Pocock के तरीके में जो बात मुझे पसंद नहीं, वह यह है कि उसमें PRD कम लिखा जाता है और पहले गहरी चर्चा से alignment बनाई जाती है, लेकिन उस शुरुआती आगे-पीछे में सबसे अच्छे हिस्से का बहुत ज़्यादा समय बर्बाद हो जाता है

    • जिज्ञासा है कि यह ad hoc है, या आप openspec जैसे किसी ज़्यादा structured approach का इस्तेमाल करते हैं
      मैं भी पहले planning करता हूँ, लेकिन वह session के भीतर एक todo list बनकर रह जाती है, जिसे बाद में रेफ़र करना मुश्किल होता है

  • agent के अंदर क्या हो रहा है, इस पर ध्यान देना शायद ज़्यादा समय तक software development का हिस्सा नहीं रहेगा
    व्यक्तिगत रूप से, मैं पहले से ही LLM और agents को black box की तरह देखता हूँ। मैं हर feature request कई LLMs को देता हूँ और नतीजों की तुलना करता हूँ। मैं “session” हाथ से नहीं लिखता। मैं सिर्फ़ परिणाम देखता हूँ। अगर पसंद नहीं आता, तो git reset --hard करता हूँ, prompt बदलता हूँ, और feature request फिर से शुरू कर देता हूँ
    मैं logs रखता हूँ ताकि लगातार अंदाज़ा रहे कि कौन-सा agent सबसे अच्छा काम कर रहा है, और जो agent मेरी ज़रूरतों को सबसे अच्छी तरह पूरा करता है उसका ELO score निकालता हूँ। मेरे लिए वही score मायने रखता है; agent वहाँ तक कैसे पहुँचा, यह उतना महत्वपूर्ण नहीं है

    • असल inference cost को देखते हुए यह सचमुच बेहद फ़िज़ूलखर्च तरीका है, और शेख़ी बघारने लायक नहीं
    • जिज्ञासा है कि आप किस तरह के projects या code work उन्हें सौंपते हैं
      मेरा अनुमान है कि frontend के ऐसे कामों के लिए यह ठीक हो सकता है जहाँ security या दूसरी verification की बहुत ज़रूरत न हो
      लेकिन regulated industries या बेहद सावधानी वाले कामों के लिए यह उपयुक्त नहीं लगता
    • अभी कौन-सा model सबसे आगे चल रहा है?

  • हाँ, context management ही असली कुंजी है
    मैं अपना framework बना रहा हूँ और इस समस्या को debug करने में बहुत समय दे रहा हूँ, और absolute context size से ज़्यादा समस्या इस बात की है कि window के अंदर कचरा या गलत दिशा-निर्देश होने की कितनी संभावना है, जो यूज़र की नज़र में महत्वपूर्ण बातों को ढक देते हैं
    यह इस रूप में दिखता है कि LLM बार-बार वही काम दोहराना चाहता है जिसमें वह अभी-अभी पिछली approach में फेल हुआ था। context window के अंदर अगर कोई चीज़ बार-बार आती है, तो वह गलत होने पर भी वज़न पकड़ लेती है
    LLM को ढेर सारे tools देने की बजाय, tools खोजने के लिए tool देने जैसी कई तरकीबें भी हैं
    लेकिन बड़ा समाधान process में है। superpowers जैसी चीज़ें इस्तेमाल करके LLM को step-by-step मजबूर करना होगा, और यह नियंत्रित करना होगा कि आगे कौन-सा context ले जाया जाए

  • मैंने Pi के लिए एक बहुत छोटा personal extension बनाया और /last command जोड़ी। यह पूरी session साफ़ कर देता है और agent का सिर्फ़ आख़िरी output message छोड़ता है
    इससे हाथ से “compression” संभव हो जाती है। मूल रूप से मैं agent से कहता हूँ, “चर्चा की गई योजना को edit की जाने वाली files के references के साथ summarize करो”, फिर /last चलाता हूँ, और उसके बाद implement करने को कहता हूँ
    [1] https://pi.dev/

  • मुझे यहाँ “models” कहकर सबको एक साथ समेटना पसंद नहीं है। हर model की attention architecture अलग होती है, इसलिए लंबे context में व्यवहार में बड़ा फ़र्क हो सकता है
    यह सही है कि लंबा context एक समस्या है और ज़्यादातर models में quality गिरती है, लेकिन मैं पुराने models के व्यवहार को सीधे नए models पर generalize नहीं करूँगा