सेशन रिकॉर्ड याद रखना एजेंट के लिए उपयोगी नहीं है
(12gramsofcarbon.com)- SWE काम में अगर एजेंट पहले से ही documents, PRs, commits जैसे context देख सकता है, तो पिछले सेशन रिकॉर्ड सर्च से कोई performance फायदा नहीं मिला
- आम implementation में सभी transcripts को DB में store करने के बाद vector search, Elasticsearch, SQL search, graph जोड़कर उसे MCP या CLI skill के ज़रिए expose किया जाता है, लेकिन कई महीनों के comparative tests में इससे कोई फर्क नहीं पड़ा और कभी-कभी model quality खराब हो सकती थी
- जिस environment में अच्छे commit messages, PR messages, documentation और metadata बचते हैं, वहाँ महत्वपूर्ण जानकारी पहले से ही coding outputs में व्यवस्थित होती है, इसलिए session records सिर्फ duplicate information और temporary notes को token खर्च करके फिर से पढ़वाते हैं
- एजेंट long-term memory के लिए ज़रूरी context removal अच्छी तरह नहीं कर पाते, और state न होने की वजह से input context के code, notes और tokens सभी को intent मान लेते हैं, जिससे intent drift जमा हो सकता है
- session records team observability में काम आ सकते हैं, लेकिन performance सुधारने के साधन के रूप में नकारात्मक हैं, और nori bots के साप्ताहिक change proposals में भी इंसानों को diff review करना पड़ता था और वास्तविक acceptance rate 20% से कम था
सेशन रिकॉर्ड सर्च performance क्यों नहीं बढ़ा पाया
- SWE काम में पिछले session records को search करने देने पर भी, जब दूसरे context मौजूद हों, तो performance advantage 0 निकला
- session records को अपने-आप खंगालकर agent context सुधारने की कोशिश भी human review के बिना बड़ा फायदा नहीं दे सकी
- आम session-based memory architecture में आम तौर पर यह flow होता है
- पूरे organization के सभी transcripts को DB में store करना
- उसके ऊपर vector search, Elasticsearch, SQL search layer जोड़ना
- ज़्यादा ambitious teams तीनों का उपयोग करती हैं और graph भी शामिल करती हैं
- MCP या skill वाले CLI के माध्यम से एजेंट को expose करना
- कई महीनों तक session search approach के साथ और बिना तुलना करने पर, यह अतिरिक्त काम कोई अंतर नहीं बना सका और कुछ मामलों में model को और खराब कर सकता था
- उपयोगी जानकारी पहले से ही coding outputs में व्यवस्थित होती है
- code changes में अच्छे commit messages, PR messages, comprehensive documentation, और code के साथ commit किया गया metadata शामिल होता है
- एजेंट को किसी खास code पर काम करते समय documentation और पुराने PR देखने के लिए कहा जाता है
- session record search एजेंट को वही चीज़ें फिर पढ़वाता है जो वह पहले से जानता है, और उन temporary judgments तथा scratchpad तक पर token खर्च करवाता है जिन्हें शुरू से रिकॉर्ड नहीं किया जाना था
जहाँ automatic memory डगमगाती है
- एजेंट long-term memory बनाए रखने के लिए महत्वपूर्ण memory cleanup नहीं कर पाते
- हज़ारों sessions में वास्तव में context हटाने का उदाहरण नहीं देखा गया
- यह ऐसा गुण नहीं है जिसे prompt engineering से हटाया जा सके, और state न होने के कारण एजेंट input context window की हर चीज़ को ground truth मान लेते हैं
- code, existing memory, और सभी tokens को intent की अभिव्यक्ति माना जाता है, चाहे वे पिछले agent session के मनमाने फैसले हों या बिना human review की सामग्री
- इस प्रक्रिया में intent drift जमा होता जाता है
- एजेंट जितना अधिक autonomously memory base बनाता है, उतना ही पिछले inputs की गलत intent interpretation जमा होती रहती है
- ऐसा कोई coding benchmark नहीं है जो माने कि input data contaminated है, और model अगर input data को गलत माने तो उसे उल्टा नुकसान होता है
- “codebase को delete मत करो” और “कुछ input context हटा दो” दोनों को एक साथ संतुष्ट करने का आसान तरीका भी नहीं है
- automatic memorization अंततः token खर्च करता है, cost बढ़ाता है, और model quality घटाने वाले अनावश्यक कचरा context में बदल जाता है
- session records team observability में उपयोगी हो सकते हैं, लेकिन एजेंट को बेहतर बनाने वाले tool के रूप में देखना मुश्किल है
nori bots का human review तरीका
- समय के साथ context सीखने का तरीका पूरी तरह असंभव नहीं है, और nori bots हर हफ्ते PR, Slack, Drive आदि में कंपनी में हुई चीज़ों की समीक्षा करके built-in nori skillsets में बदलाव के प्रस्ताव देते हैं
- change proposals Slack में team को tag करते हैं, लेकिन default रूप से सब reject होते हैं
- बदलाव स्वीकार करने के लिए diff को सीधे देखकर यह पुष्टि करनी होती है कि वह intent के अनुरूप है
- acceptance rate 20% से कम है, और बाकी 80% “automatic” updates शायद model को और खराब बनाते
- अगर सैकड़ों लोगों वाले organization ऐसे updates को हमेशा automatically save करें, तो यह और भी कम sustainable हो सकता है
1 टिप्पणियां
Hacker News की टिप्पणियाँ
जब OpenAI ने कहा था कि वह ChatGPT में sessions के बीच memory फीचर जोड़ रहा है, तो वही याद आता है। आखिर में यह ऐसा लगा जैसे मेरी स्पष्ट सहमति के बिना मेरे बारे में तरह-तरह की जानकारी ढूँढकर prompts के बीच copy-paste कर दी जाती हो
जैसे: “इन तीन कारों की तुलना करो। ओह, और संदर्भ के लिए, मैं एक data engineer हूँ, मेरी माँ का विवाह-पूर्व उपनाम Joana है, मुझे खराब कविताओं से allergy है। Code DRY होना चाहिए, मैं Python से ज़्यादा SQL पसंद करता हूँ, और Scandinavia का सबसे ज़हरीला फूल कौन सा है?”
याद रखा गया संदर्भ पूरी तरह असंबंधित projects और conversations में भी रिसकर आ जाता है, जिससे बहुत अजीब outputs आते हैं, इसलिए मैं इसे सबसे पहले बंद करता हूँ
पूरी तरह सहमत। claude-code का memory system कभी-कभी काम आता है, लेकिन ज़्यादातर मामलों में यह पुरानी जानकारी खींच लाता है जो मौजूदा काम को धुंधला कर देती है, इसलिए नुकसान ज़्यादा होता है। मैंने अक्सर देखा है कि Claude की अपनी memory ही उसे बुरी तरह भटका देती है
अंदाज़ा लगाऊँ तो यह शायद training process की वजह से है, जहाँ model “अभी क्या हो रहा है” और “पहले क्या हुआ था” में ठीक से फ़र्क नहीं कर पाता। अगर memory से reasoning करने की प्रक्रिया training में शामिल होती तो बात अलग होती, लेकिन यह सिर्फ inference के समय जोड़ी गई capability लगती है, इसलिए model को confuse करती है
LLM इतने समझदार नहीं हैं कि हल्का-सा context pollution भी सह सकें
जिस सोच या context ने उसे उधर पहुँचाया, उसमें inertia रहती है, इसलिए उसे छोड़ दो तो वह चिपकी रहती है
और बाद में वही चीज़ memory से फिर निकाल ली जाए तो काफ़ी झुंझलाहट होती है
memory को training में शामिल करने का विचार दिलचस्प है
Code को “क्या करने के लिए बनाना चाहा गया था” यह आम तौर पर महत्वपूर्ण नहीं होता। महत्वपूर्ण यह है कि code वास्तव में क्या करता है
session logs निश्चित रूप से उपयोगी हो सकते हैं, लेकिन उन पर लगातार build करते हुए development के दौरान नहीं, बल्कि verification phase में। Markdown योजना और CI pass होने के बीच, जब 800 नई lines of code जुड़ चुकी हों और क्लिक करके देखने पर सब मोटे तौर पर ठीक लगे, ठीक उसी हिस्से में
session logs यह दिखा सकते हैं कि कौन-सा manual verification हुआ था। CI existing tests चलाता है, code यह दिखाता है कि नए unit tests क्या हैं, लेकिन session logs यह दिखाते हैं कि agent ने Playwright से app को सच में चलाया था या नहीं, और उसने सिर्फ dev settings नहीं बल्कि prod settings भी पढ़कर ध्यान में रखी थीं या नहीं
यह perfect नहीं है, लेकिन हर verification task को ऐसा test बनने की ज़रूरत नहीं जो repository में हमेशा के लिए रह जाए। हमने sessions को फिर से analyze करके उन जगहों को खोजने में बहुत लाभ देखा है जहाँ agent ने बिना पूछे decisions ले लिए, और फिर उसे उन decisions के verification पर विचार करने के लिए मजबूर किया। ऐसी चीज़ें शुरू से निर्देशों में देना कठिन है, लेकिन session logs में वे आसानी से सामने आ जाती हैं
यह बहुत परेशान करने वाली समस्या है। पहले पूछे गए hypothetical question की वजह से यह लगातार नकली premises बना लेता है
सिर्फ इसलिए कि मैंने इसे कुछ investigate करने को कहा था, यह मान लेता है कि मेरे पास data centers हैं और बहुत सारे GPU भी
मुझे लगता है यह बस सीखे हुए कड़वे सबक का एक रूप है। जो context और agents हम मेहनत से बना रहे हैं, शायद वे बड़े और बेहतर models आते ही गायब हो जाएँ
ऐसे conversation logs कम क्षमता वाले models के लिए बहुत उपयोगी हैं, लेकिन frontier models के लिए शायद लगभग अनावश्यक हों
मैं https://minimal-agent.com/ पर आधारित एक custom harness इस्तेमाल कर रहा हूँ, जो swe-mini-agent पर बना है और इसका core logic लगभग 50 lines का है। सिर्फ Bash काफ़ी है
छोटे tasks में यह हर model के standard harness की तुलना में लगभग 8 गुना तेज़ है और tokens भी 8 गुना कम खर्च करता है
बड़े tasks में मैंने इसे ज़्यादा test नहीं किया। यह काम तो करता है, लेकिन उस स्थिति में कम focused लगता है और productivity भी थोड़ी गिरती है। हो सकता है बड़े harness का 20k-token system prompt software development flow को दिशा देने में महत्वपूर्ण काम करता हो। उदाहरण के लिए, मैंने सुना है कि Fable के पास Claude Code के लिए custom system prompt है, और शायद इसी वजह से वह कहीं ज़्यादा proactively काम करता है
इसलिए मैं मानना चाहूँगा कि context engineering में अभी भी value है। बस हर नए model के साथ उसकी value घटती हुई लगती है, क्योंकि models को आम तौर पर कम मूर्खतापूर्ण behavior के लिए fine-tune किया गया है, इसलिए उन्हें हाथ पकड़कर चलाने की ज़रूरत कम पड़ती है
सबसे पहले, मुझे अभी भी लगता है कि models को context layers की ज़रूरत है। Context को देखने का एक तरीका compression है। यानी model को यह समझने में आसान बनाना कि उसे क्या करना है। ऐसी दुनिया में भी जहाँ model capacity और context length असीमित हो, यह फिर भी उपयोगी रहेगा, क्योंकि हर बार सब कुछ first principles से दोबारा derive नहीं करना पड़ेगा। अगर model कम tokens में बेहतर perform करे, और जब तक हमें token cost की परवाह है, context एक उपयोगी, शायद ज़रूरी shortcut है
अगर हम मान लें कि किसी न किसी रूप में context layers की ज़रूरत है, तो अगला सवाल होगा कि कैसी layers। यहाँ मैं सहमत हूँ कि model के लिए परिचित रूप, जैसे code के बगल में रखा Markdown file, के साथ काम करना बेहतर है। लेकिन यह context की ज़रूरत है या नहीं, उससे कम और over-engineered solution द्वारा मुख्य user यानी agent को ठीक से न समझ पाने की समस्या ज़्यादा लगती है
लेकिन मैं बहुत उत्सुक हूँ कि कहीं बहुत बेहतर next-token prediction इस पूरे setup को सीधा obsolete न बना दे। किसी भी दिशा में जवाब मिला, तो बहुत कुछ स्पष्ट हो जाएगा
यह भी याद रखना चाहिए कि brain की structure भी learned होती है। बस वह किसी व्यक्ति के जीवनकाल से कहीं लंबे timescale पर सीखी जाती है
मैं इस बात से सहमत हूँ कि जानबूझकर कोई जटिल memory system बनाने की ज़रूरत नहीं है। जो चीज़ें याद रखने लायक हैं, वे docs, guides, source comments, commit messages, tickets में होनी चाहिए।
किसी और layer की ज़रूरत नहीं है। जितनी भी granularity की कल्पना की जा सकती है, उन सबको मौजूदा best practices पहले से कवर करती हैं
यह extension यह करता है: https://github.com/gitsense/pi-brains
अभी “human” को information access pattern के लिए routing rules define करने पड़ते हैं, लेकिन आगे चलकर यह ऐसे “knowledge agents” को support करेगा जो बातचीत को monitor करें और ज़रूरत पड़ने पर context inject करें
~/.claude/…, उसके लिए तो और भी नहीं।जिन projects में memory की ज़रूरत पड़ी, वहाँ मैंने बस AGENTS.md में एक लाइन जोड़ दी कि memory को MEMORY.md में लिखो या progress को STATUS.md में track करो
लेकिन अगर उसे trace log में tags के साथ रखा जाए, तो ज़रूरत पड़ने पर उसे efficiently ढूँढा जा सकता है। और docs सड़ जाती हैं, जबकि trace logs में commit hash या दूसरी जानकारी जोड़कर उनकी validity को ज़्यादा स्पष्ट बनाया जा सकता है
मैं इससे ज़ोरदार असहमति रखता हूँ।
मैं Claude/Codex से logs लिखवाता हूँ [1]। यह सिर्फ़ AGENTS.md [0] में prompt के ज़रिए निर्देश देकर किया है।
“हर session को session log या plan में से एक बनाना चाहिए, और अंत में एक लिखा हुआ summary जोड़ना चाहिए। default log है, और plan का उपयोग केवल substantial design work के लिए होना चाहिए।”
यह बेहद valuable है। उदाहरण के लिए आज भी मैंने कुछ sessions ऐसे शुरू किए: “Renovate task की status क्या है?”, “हाल में X पर काम किया था, उसे ढूँढो”, “backup issue ठीक किया था क्या? अगला step क्या है?”, “यह bug फिर आ गया। क्या इसे पहले ठीक नहीं किया था?”
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
कुल मिलाकर मुझे memory systems पसंद हैं। संदर्भ के लिए, मैं ज़्यादातर Opus 4.8 + Max effort इस्तेमाल करता हूँ।
यह memory से relevant बातें काफ़ी बार निकाल लाता है। उदाहरण के लिए अगर मैं self-hosted OIDC providers के कुछ candidates सुझाने को कहूँ, तो यह कहेगा, “ops team के आकार को देखते हुए X और Y कारणों से यह वाला बेहतर fit हो सकता है।”
बेशक, ऐसी बातें CLAUDE.md में होनी चाहिए। लेकिन उस स्थिति में मुझे यह ख़याल ही नहीं आया था कि इसे CLAUDE.md में डालना चाहिए, और memory ने उसे निकाल दिया, यह अच्छा लगा।
कभी-कभी यह चूक भी जाता है। आज मैंने auth issue के बारे में पूछा तो इसने कहा, “क्योंकि apps को haproxy के पीछे रखा जाता है, यह trusted proxy setting से टकरा रहा हो सकता है।” हमारी 95% apps के लिए यह ठीक बात थी, इसलिए इसका ज़िक्र करना बनता था, लेकिन इस बार ऐसा नहीं था, इसलिए मुझे सुधारना पड़ा। फिर भी अगर वह सच में proxy के पीछे होता, तो इससे बहुत समय बच सकता था, इसलिए इसका बताना अच्छा था
खासकर अगर आप hypothetical सवाल अक्सर पूछते हैं या दूसरे लोगों की समस्याओं में मदद करते हैं, तो यह और मुश्किल हो जाता है। कोई इंसान शायद मान लेने के बजाय ऐसे clarifying questions पूछेगा: “क्या यह X की ops team के बारे में है? क्या उसका आकार अभी भी Y है?”, “क्या यह app भी पहले बताए गए दूसरे apps की तरह proxy के पीछे है?”
ऐसे context में एक स्पष्ट hierarchy भी होती है जिसे सही तरह model करना पड़ता है। उदाहरण के लिए आप एक साथ कई teams के साथ जुड़े हो सकते हैं जिन पर अलग-अलग rules लागू होते हैं, और इंसान इसे स्वाभाविक रूप से समझ लेते हैं
memory बंद कर दें तब भी एक ही बातचीत के भीतर ऐसा होता है।
यह उस परेशान करने वाले दोस्त जैसा है जो पिछली बातचीत की किसी बात को याद रखता है और उसे बार-बार सामने लाता रहता है, जबकि मैं तब से बढ़ चुका हूँ और बदल चुका हूँ
मूल रूप से यह hardware problem है। 1 million tokens उतना context नहीं है कि वह codebase को उसी तरह समझ सके जैसे इंसान समझते हैं।
चुनिंदा रूप से भूल पाने की क्षमता संभावित रूप से बहुत क़ीमती है। लेकिन अभी यह बस उस मानवीय क्षमता की जगह लेने की कोशिश है जिसमें इंसान किसी चीज़ का मोटा आकार याद रखते हैं, उसे गैर-रोचक मानते हैं, और यह भी याद रखते हैं कि वह गैर-रोचक है।
कहा जाता है कि memory तभी उपयोगी है जब इंसान उसे guide करे, लेकिन मुझे लगता है सही समाधान उससे भी गहरा है। शायद दिशा यह हो कि पूरे codebase और सभी agent sessions को model fine-tuning में डाल दिया जाए। हालाँकि उस बिंदु पर शायद यह निर्देश देना पड़े कि किसी खास session को model में शामिल न किया जाए। या शायद उसकी भी ज़रूरत न पड़े, और सीखे गए lessons लागू हो जाएँ