मल्टी-टर्न बातचीत में LLM रास्ता भटक जाते हैं

 (arxiv.org)
4 पॉइंट द्वारा GN⁺ 2025-05-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बड़े भाषा मॉडल (LLM) मल्टी-टर्न बातचीत में परफॉर्मेंस गिरावट और विश्वसनीयता में कमी दिखाते हैं
  • सिंगल-टर्न की तुलना में मल्टी-टर्न स्थितियों में औसतन 39% परफॉर्मेंस गिरावट प्रयोगों में देखी गई
  • मुख्य कारण मामूली aptitude में कमी और बहुत बड़ी reliability में गिरावट, यानी नतीजों में निरंतरता की कमी है
  • LLM शुरुआती चरण में गलत मान्यताएँ बना लेते हैं, या अंतिम उत्तर देने की कोशिश बहुत जल्दी करने लगते हैं
  • नतीजतन, बातचीत की शुरुआत में गलती होने पर LLM उबर नहीं पाते और बातचीत की दिशा खो देते हैं

ABSTRACT

  • बड़े भाषा मॉडल (LLM) एक conversational interface के रूप में ऐसे सिस्टम हैं जिनमें यह क्षमता है कि जब उपयोगकर्ता अपनी जरूरतें पूरी तरह स्पष्ट न कर पाए, तब भी वे मल्टी-टर्न बातचीत के जरिए जरूरतों को धीरे-धीरे परिभाषित, खोज और संशोधित करने में मदद कर सकें
  • लेकिन अधिकांश LLM मूल्यांकन केवल सिंगल-टर्न पूर्ण-विवरण वाले निर्देश वाले वातावरण पर केंद्रित रहे हैं, जबकि वास्तविक बातचीत लॉग के विश्लेषण में underspecification बार-बार दिखाई देता है
  • इस अध्ययन में सिंगल-टर्न और मल्टी-टर्न (underspecified) वातावरणों में LLM के प्रदर्शन की बड़े पैमाने पर simulation करके तुलना की गई
  • परिणामस्वरूप, 15 प्रमुख LLM में मल्टी-टर्न बातचीत के दौरान औसतन 39% प्रदर्शन गिरावट देखी गई, जिसे aptitude में हल्की कमी और reliability में तेज गिरावट के रूप में विश्लेषित किया गया
  • जब LLM बातचीत की शुरुआत में गलत रास्ता चुन लेते हैं, तो बाद में वे उबर नहीं पाते और दिशा खोकर भटकते रहते हैं

Introduction

  • आधुनिक LLM (जैसे ChatGPT, Gemini, Claude आदि) मल्टी-टर्न बातचीत सक्षम इंटरफेस हैं
  • उपयोगकर्ता अगर शुरुआत में अपनी सारी जरूरतें साफ़-साफ़ न भी बताए, तो भी दोहराए जाने वाले प्रश्नोत्तर (underspecified → refined) के जरिए जरूरतों को धीरे-धीरे अधिक स्पष्ट बनाया जा सकता है
  • वास्तविक दुनिया में कई उपयोगकर्ता बातचीत की शुरुआत में अस्पष्ट अनुरोध देते हैं, फिर भी अधिकांश मूल्यांकन केवल सिंगल-टर्न पूर्ण-विवरण वातावरण में किए जाते हैं
  • कुछ पूर्व शोधों ने मल्टी-टर्न मूल्यांकन की कोशिश की है, लेकिन वे अक्सर बातचीत के हर turn को अलग episode की तरह मानते हैं, जिससे वास्तविक मानवीय संवाद में आम अस्पष्टता के प्रभाव को कम करके आँका जाता है
  • इस अंतर को कम करने के लिए, यह अध्ययन sharded simulation (जानकारी को कई टुकड़ों में बाँटकर हर turn में केवल एक टुकड़ा उजागर करना) नामक एक सेटअप प्रस्तावित करता है, जो मल्टी-टर्न और अस्पष्ट निर्देशों वाली स्थितियों का अधिक सटीक simulation करता है

प्रमुख शोध निष्कर्षों का सार

  • सिंगल-टर्न में जब LLM को पूरा निर्देश एक साथ दिया गया, तो 90% प्रदर्शन मिला, लेकिन मल्टी-टर्न अस्पष्ट निर्देश में यह 65% तक गिर गया (औसतन 25 पॉइंट की गिरावट)
  • यह घटना केवल दो turn की बातचीत के बाद भी दिखाई देती है, और open/open-weight, closed, बड़े और छोटे सभी LLM में समान रूप से देखी गई
  • परफॉर्मेंस गिरावट के कारणों के विश्लेषण से दो बातें सामने आईं: (1) aptitude loss और (2) unreliability में तेज वृद्धि
    • सिंगल-टर्न में उच्च aptitude वाले मॉडल अधिक reliable भी थे, लेकिन मल्टी-टर्न में aptitude से अलग होकर reliability कम हो गई
    • यानी, मल्टी-टर्न बातचीत के दौरान LLM अगर गलत दिशा में मुड़ जाएँ, तो रिकवरी संभव नहीं होती — इसे “lost in conversation” नाम दिया गया है
  • मुख्य कारण
    • लंबे-चौड़े जवाब और अंतिम उत्तर देने की जल्दबाज़ी
    • अस्पष्ट जानकारी के आधार पर गलत मान्यताएँ
    • पहले किए गए गलत प्रयासों पर अत्यधिक निर्भरता
  • वास्तविक LLM उपयोग और मॉडल मूल्यांकन के तरीकों के बीच बड़ा अंतर मौजूद है
    • खासकर नए उपयोगकर्ता शुरुआत में अधूरे निर्देश देते हैं, इसलिए यह घटना वास्तविक उपयोग में अपनाने को कठिन बनाने वाले प्रमुख कारणों में से एक है
  • पेपर की संरचना: पूर्व शोध का सार, simulation वातावरण का विवरण, 6 generation tasks और evaluation metrics, 15 LLM पर बड़े पैमाने के प्रयोग और परिणाम, तथा practical/product application के लिए संकेत और ठोस सिफारिशें

Background and Related Work

  • पिछली पीढ़ी के भाषा मॉडल (जैसे BART, GPT-2, T5) वास्तव में मल्टी-टर्न बातचीत को अच्छी तरह संभाल नहीं पाते थे, इसलिए उनका मूल्यांकन मुख्यतः सिंगल-टर्न पर हुआ
  • ChatGPT के आने के बाद मल्टी-टर्न मूल्यांकन में रुचि बढ़ी, और MT-bench जैसे crowdsourced evaluation सामने आए
  • लेकिन अधिकांश मूल्यांकन ढाँचे अभी भी episodic conversation (हर turn का अलग मूल्यांकन) तक सीमित हैं, इसलिए वास्तविक अस्पष्ट बातचीत की निरंतरता पर पर्याप्त ध्यान नहीं दिया जाता
  • वास्तविक दुनिया में “न्यूनतम प्रयास के सिद्धांत” के अनुसार लोग अक्सर अस्पष्ट निर्देश देते हैं (a.k.a. underspecification), और LLM भी जानकारी की कमी में जल्दी निष्कर्ष निकालने तथा अनुकूलन की कमी जैसी वजहों से प्रदर्शन खो देते हैं
  • यह अध्ययन ऐसे मूल्यांकन की ओर उन्मुख है जो अस्पष्टता-केंद्रित वास्तविक वातावरण के अधिक करीब हो

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

  • मूल पूर्ण-विवरण निर्देश को कई shard (जानकारी के टुकड़े) में बाँटा जाता है
    • उदाहरण: एक ही वाक्य में सारी शर्तें देने के बजाय, हर turn में केवल एक सूचना (स्थिति, संख्या, शर्त आदि) दी जाती है
  • पहला shard हमेशा निर्देश के उच्च-स्तरीय लक्ष्य को बताता है, और उसके बाद के shard हर turn में अतिरिक्त जानकारी (context, constraints आदि) धीरे-धीरे देते हैं
  • यह sharding प्रक्रिया LLM (GPT-4o) के प्रस्ताव+सत्यापन और मैनुअल सुधार के जरिए उच्च-गुणवत्ता वाला मल्टी-टर्न instruction dataset बनाती है
  • हर task के लिए 90–120 sharded instructions बनाए गए (कई घंटों की मैनुअल समीक्षा के साथ)

3.2 Simulating Sharded Conversations

  • बातचीत simulation में 3 भूमिकाएँ होती हैं: मूल्यांकनाधीन LLM (assistant), सभी shard जानने वाला user simulator, और response classification व scoring system
  • पहला turn: user simulator केवल पहला shard assistant को देता है → assistant जवाब देता है → उसकी रणनीति (स्पष्टीकरण, प्रश्न, उत्तर देने की कोशिश आदि) वर्गीकृत की जाती है और उत्तर निकाला जाता है → फिर उसका मूल्यांकन होता है
  • अगले turn में: बचे हुए shard में से केवल एक और दिया जाता है, और यही प्रक्रिया दोहराई जाती है / हर turn में assistant स्वतंत्र रूप से जवाब दे सकता है
  • बातचीत समाप्ति: (1) evaluator सही उत्तर तय कर दे, या (2) देने के लिए कोई shard न बचे
  • user simulator को LLM (GPT-4o-mini) से बनाया गया है, जिससे shard को स्वाभाविक ढंग से देना और स्वत: rephrase करना संभव होता है
  • पूरे प्रयोग में सहायक LLM की misclassification या extraction errors 5% से कम थीं, और assistant के लिए प्रतिकूल मामले 2% से कम थे
  • assistant का मूल्यांकन इस वातावरण के बारे में कोई विशेष जानकारी दिए बिना default state में किया गया (यानी वास्तविक उपयोग की तरह उसे scenario की अतिरिक्त जानकारी नहीं दी गई)

3.3 Simulation Types

  • FULLY-SPECIFIED (FULL): सिंगल-टर्न में पूरा निर्देश देना, baseline performance मापने के लिए
  • SHARDED: हर turn में केवल एक जानकारी का टुकड़ा उजागर करना, यही मल्टी-टर्न अस्पष्ट बातचीत पर इस अध्ययन का मुख्य प्रयोग है
  • CONCAT: पूरे sharded instruction को एक साथ bullet-point के रूप में देना, ताकि केवल instruction information loss का प्रभाव मापा जा सके
  • RECAP: sharded बातचीत के बाद अंत में सभी shard का सार/पुनर्प्रस्तुति, simple agent-like intervention के एक रूप के रूप में
  • SNOWBALL: हर turn में नया shard जोड़ने के साथ पहले दिए गए सभी shard को दोहराना, ताकि assistant कोई जानकारी न छोड़े और उसे बार-बार याद दिलाया जाए (memory reinforcement experiment)

Task and Metric Selection

4.1 Task Selection

  • कुल 6 tasks: programming (Code), database (SQL generation), API function calling (Actions), math, table-to-text (Data-to-Text), और question-answer style summarization (Summary)
    • उदाहरण: Python function लिखना, natural language → SQL query conversion आदि
  • हर task के लिए उच्च-गुणवत्ता benchmark से 90~120 निर्देश चुने गए, फिर sharding के बाद उनका मैनुअल सत्यापन किया गया
  • ये 6 tasks programming और non-programming दोनों तरह के प्रतिनिधि परिदृश्यों को कवर करते हैं, जिनमें long context माँगने वाला Summary जैसे मामले भी शामिल हैं

4.2 Metric Selection

  • मूल्यांकन मेट्रिक्स
    • औसत प्रदर्शन (P): कई simulations में प्राप्त औसत स्कोर (0~100)
    • aptitude (A90): शीर्ष 10% simulation परिणामों का मान (90th percentile, best-case)
    • reliability (U90_10): शीर्ष 90% और निचले 10% स्कोर का अंतर (परिणामों की निरंतरता/विविधता का माप)
  • उदाहरण: box-plot में सबसे ऊपर aptitude दर्शाता है, और ऊपर-नीचे का फैलाव reliability को
  • सभी 6 tasks में एकसमान पैमाने पर स्कोरिंग की गई (सही उत्तर/समानता/BLEU आदि)
  • सभी प्रयोग पैरामीटर, उदाहरण, sampling आदि की विस्तृत विधि और code भी appendix में दिए गए हैं

Simulation Scale and Parameters

  • कुल 600 instructions को 6 tasks के लिए तैयार किया गया, और FULL/CONCAT/SHARDED scenarios पर प्रयोग किए गए
  • 15 LLM (GPT-4, Claude, Gemini आदि) पर हर संयोजन के लिए 10-10 simulations चलाए गए, जिससे 2 लाख से अधिक experimental data points बने
  • सभी प्रयोग temperature 1 (sampling) पर किए गए, और अतिरिक्त प्रयोग (7.2) में temperature के प्रभाव का भी विश्लेषण किया गया
  • इस बड़े simulation dataset से LLM के मल्टी-टर्न underspecified बातचीत में व्यवहार और प्रदर्शन गिरावट के प्रमुख कारणों और पैटर्न को समझना संभव हुआ

Lost in Conversation Experiment

  • आगे पेपर में experiment setup, individual model results, performance गिरावट के कारणों का विश्लेषण, mitigation techniques (RECAP/SNOWBALL) के प्रयास, और व्यावहारिक संकेतों व ठोस सिफारिशों का विस्तार से वर्णन किया गया है

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

1 टिप्पणियां

 
GN⁺ 2025-05-16
Hacker News टिप्पणियाँ

  • यह देखकर खुशी हुई कि एक पेपर ने वही बात पुष्टि की, जिसे LLM tools को वास्तव में इस्तेमाल करने वाला हर व्यक्ति अनुभव से जानता है। “बातचीत” की अवधारणा प्रोडक्ट इंटरफ़ेस से बनी है। context को साफ़ रखना महत्वपूर्ण है। context दूषित हो जाए तो वह रिकवर नहीं होता, इसलिए नई बातचीत से फिर शुरू करना पड़ता है

    • मेरा अनुभव भी इस अवलोकन से मिलता-जुलता है, हालांकि कुछ अंतर भी थे। मैंने 2 हफ्ते तक Gemini के साथ IPSEC समस्या debug की। शुरुआत में OPNsense और pfSense के IPSEC docs पढ़वाकर उसे समग्र context दिया। फिर config जानकारी साझा की और सवाल-जवाब चलते रहे। अंत तक LLM का बिखरना कम हो गया था, और कभी-कभी मैंने forum posts या SO postings भी डालीं, लेकिन LLM यह भी कहता था कि “यह अभी दिख रही समस्या से अलग है।” हमने हर dead end को तार्किक रूप से बाहर किया, और LLM reflection में मदद करता था लेकिन निर्णय इंसान को ही लेना था। आखिरकार मैंने root cause ढूंढ लिया, और जैसा दूसरे users ने कहा है, LLM जटिल जानकारी को सरल बनाने में अच्छा है, लेकिन सरल अवधारणाओं को जटिल विस्तार में बढ़ाने में कमजोर है। जब input output से ज्यादा जटिल या लंबा हो, तब मैं परिणाम से ज़्यादा संतुष्ट रहता हूँ। LLM के बिना भी यह किया जा सकता था, लेकिन जो बातें मैं context में याद नहीं रख पाता था या जल्दी फिर से नहीं बना पाता था, उन्हें store करके रखना उपयोगी था। बड़े logs में time patterns ढूंढने में भी मदद मिली। कई configs भी सुधारीं। सिर्फ समस्या हल नहीं हुई, बहुत कुछ सीखा भी। इसकी स्थिति-समझ कभी-कभी गलत होती थी, लेकिन उसे सीधे ठीक करना आसान था। यानी, अगर लक्ष्य पता हो और इसे tool की तरह इस्तेमाल करो तो यह उपयोगी है, लेकिन अगर निर्णय इसे सौंप दो या इसकी गलत दिशा में बह जाओ, तो कोई फ़ायदा नहीं। 3.5 लाख tokens (लगभग 3 लाख शब्द) इस्तेमाल किए। इस पर एक blog post भी है। wireguard की सिफारिश की ज़रूरत नहीं है
    • मेरा अनुभव पूरी तरह यही है। “दूषित” शब्द बिलकुल सही है। एक बार कुछ गलत हो जाए, उसके बाद हर जवाब बिगड़ने लगता है। इसलिए मुझे ChatGPT की memory feature पसंद नहीं। कोई बड़ा हादसा नहीं हुआ, लेकिन context pollution कैसे होता है, यह पूरी तरह न समझ पाने से बेचैनी होती है
    • मेरी सबसे अच्छी टिप यह है कि ChatGPT और Claude के बहुत छोटे और छिपे हुए “edit” बटन का भरपूर इस्तेमाल करो। अगर खराब जवाब आए, तो उसे यूँ ही मत छोड़ो; रुको, उसे सुधारो, फिर बेहतर जवाब लो। नहीं तो गड़बड़ी बढ़ती ही जाती है
    • मेरा हमेशा मन करता है कि बातचीत को fork करके अलग-अलग दिशाओं में प्रयोग करूँ। किसी promising flow में irreversible pollution न हो, यही चाहता हूँ। ChatGPT में मैं यह feature इस्तेमाल नहीं कर पा रहा, क्या कोई service है जो यह देती हो?
    • इस समस्या का एक दिलचस्प उदाहरण initial prompt है। वह लगभग स्थायी और छिपा हुआ context है। Twitter का Grok bot हाल में “White Genocide” का बार-बार ज़िक्र कर रहा है, क्योंकि किसी ने prompt को उस विषय के अनुकूल बदल दिया। एक perfect chatbot को दूसरे विषयों से प्रभावित नहीं होना चाहिए, लेकिन व्यवहार में वह प्रभावित होता है। आखिर context बदल गया, और वह उसी विषय पर अटका रहता है
    • इसी वजह से मैंने FileKitty बनाया। यह कई source code files को जल्दी से markdown format में जोड़ने का tool है। जब software development में LLM से मदद लेते हैं, तो codebase search के लिए LLM पर निर्भर रहने से error की संभावना बढ़ जाती है। context compression के loss की वजह से output पतला भी पड़ सकता है। सबसे अच्छे नतीजे तब मिलते हैं जब खास context शुरू से स्पष्ट हो और बातचीत के बीच-बीच में उसे refresh किया जाए। फिर भी बातचीत की लंबाई का ध्यान रखना पड़ता है। ऐसे prompts भी हैं जो context को अच्छे से capture करके नई session में पास करते हैं। किन files को शामिल करना है, उन्हें चुनकर नए prompt में डालते हैं। इससे जुड़ी चर्चा HN के दूसरे thread में भी देखी जा सकती है
    • अब यह पैटर्न मेरे workflow का हिस्सा बन गया है। कभी-कभी मैं LLM से पूछता हूँ, “अच्छी प्रगति है, मैं अगला कदम लेना चाहता हूँ, लेकिन क्या इस बातचीत में आगे बढ़ना ठीक है या नया शुरू करना चाहिए?” अगर model कहे कि नया शुरू करना बेहतर है, तो वह अच्छा summary prompt तैयार कर देता है, और कभी कहता है कि जारी रखना ठीक है। मैंने “आगे exploration के लिए शुरुआती मान” जैसे कई notes बना रखे हैं। RL-आधारित post-training आदि के कारण chatbots में बातचीत जारी रखने की प्रवृत्ति होती है। RL में post-training, असली RL से अलग, केवल one-shot preference-based mechanism इस्तेमाल करता है। long-term preferences या long conversations में computational complexity ज्यामितीय रूप से बढ़ती है, इसलिए इस पर बहुत research नहीं है
    • क्या कहीं ऐसा interface बना है जो conversation history को “साफ़-सुथरा” कर सके? यानी बातचीत के भीतर dead paths या irrelevant सामग्री को व्यवस्थित कर दे। पूरी history बनी रहे, लेकिन topic path के हिसाब से सिर्फ़ अनावश्यक हिस्से prune/organize हों। summary से ज़्यादा organic तरह की सफ़ाई
    • मैं LLM को सिर्फ autocomplete के लिए इस्तेमाल करता हूँ, लेकिन मुझे लगता है कि LLM chat UI में “delete message” बटन या option जोड़ने से यह समस्या हल हो सकती है। आख़िरी LLM message हटाने पर नया जवाब मिल सकता है। high-temperature LLMs में यह खास उपयोगी है। अगर दूसरे messages हटाए जाएँ, तो बाद के जवाबों में उसे reflect करने के लिए context अपडेट हो। इससे users का यह भ्रम भी टूट सकता है कि LLM सचमुच intelligent है। मुझे नहीं पता यह पहले से standard है या नहीं। अगर नहीं, तो यह idea public domain में है। दूसरी ओर, “subcontext LLM” रखना भी व्यावहारिक है, जो main context को manage करे। यानी, जब responses बहुत लंबे या भारी हों, तो एक helper LLM उन्हें summarize/organize करके पूरी बातचीत के context को तराशे। या और सरल रूप में “edit message” बटन हो, ताकि इंसान खुद सफ़ाई कर सके
    • context दूषित हो जाए तो रिकवर करना मुश्किल होता है। अगर LLM में कुछ खास हिस्सों को समय-समय पर reset या साफ़ करने की क्षमता हो, तो सुधार हो सकता है। लेकिन कौन से हिस्से साफ़ किए जाएँ, और कहीं महत्वपूर्ण जानकारी न खो जाए, यही चुनौती है। लंबी बातचीत की consistency बनाए रखने में smarter context management मदद कर सकता है, लेकिन संतुलन कठिन है। शायद कोई दूसरा agent इसे automate कर सके
    • AI chatbots में chain-of-thought style prompts की सीमाएँ भी इसी कारण सामने आती हैं
    • “बातचीत” सिर्फ़ product interface की उपज है—इस बात पर एक राय। RL के multi-turn evaluation dataset training के बाद यह प्रवाह कुछ बदला है। context window हर बार नया होता है, लेकिन हर prompt को लंबी बातचीत के हिस्से की तरह समझने की प्रवृत्ति बढ़ी है। publicly multi-turn post-training अभी scale नहीं हुआ है, लेकिन लंबे समय में ज़्यादा goal achievement के लिए इसे अपनाया जाएगा
    • coding करते समय भी मैं अक्सर बिना उसी बातचीत को जारी रखे नई chat शुरू करता हूँ और मौजूदा code के साथ फिर से समझाता हूँ। कई बार यह एक ही बातचीत में लगातार कोशिश करने से बेहतर परिणाम देता है। अगर manual commands से model को explicitly summary और forgetting करने को कहा जाए, तो शायद समस्या हल हो सकती है। यह कुछ हद तक इंसानी working mechanism (working memory vs narrative/episodic memory) से भी मेल खाता है
    • ChatGPT की सबसे परेशान करने वाली features में से एक है “memory”। conversation pollution chats के बीच भी पीछे-पीछे आ सकता है
    • “दूषित” वाकई एक सटीक शब्द है। काश conversation/API में “version control” होता, ताकि पुरानी स्थिति पर rollback किया जा सके या नई chat में clone किया जा सके। खासकर इसलिए कि typo या message edits भी बाद के responses में हल्का bias ला देते हैं
    • मुझे zed का chat UX बहुत पसंद है। आप पूरी conversation history को text file की तरह edit कर सकते हैं, अनचाहे हिस्सों को साफ़, delete, modify और refine कर सकते हैं, और फिर कहीं ज़्यादा साफ़ व relevant context के साथ बातचीत जारी रख सकते हैं। इसलिए मैं programming के बाहर के कामों में भी zed को LLM बातचीत के मुख्य interfaces में से एक की तरह इस्तेमाल करता हूँ
    • pollution बेकार सवालों या जवाबों, और बार-बार होने वाले “dilution” से भी हो सकता है। content generate करते समय भी मैं अक्सर देखता हूँ कि जो निर्देश शुरू में स्पष्ट थे, वे धीरे-धीरे बिखर जाते हैं
    • मैं हमेशा याद रखने की कोशिश करता हूँ कि “बातचीत सिर्फ़ product interface की उपज है,” लेकिन व्यवहार में अलग-अलग conversational cues की वजह से यह आसान नहीं होता
    • मुझे memory ऑन रखने का पछतावा हुआ। बेकार जानकारी से बातचीत दूषित हो जाती है
    • हैरानी की बात यह है कि model कितनी जल्दी गलत assumptions बनाकर उन्हीं पर अटक जाता है
    • सोचा जाए तो इंसानों में भी ऐसा बहुत होता है
    • अब ChatGPT “memory” के ज़रिए पुरानी बातचीत तक भी पहुँच सकता है, इसलिए pollution स्थायी हो सकता है। एक बार वह कोई गलत idea पकड़ ले, तो user के बार-बार यह कहने के बावजूद कि उसे दोबारा मत लाओ, वह उसे जवाबों में घुसाता रहता है। यहाँ तक कि internal prompt (“user बहुत असंतुष्ट है, xyz हटाना है”) भी गलती से output हो गया, और नतीजतन वह xyz पर और भी ज़्यादा फ़ोकस करने लगा—काफ़ी हास्यास्पद स्थिति थी

  • यह LLMs की जानी-पहचानी overconfidence प्रवृत्ति, self-reflection की कमी, और उस समय अधिक जानकारी माँगने की ज़रूरत को न पहचान पाने से पैदा होने वाली समस्या है। reasoning models के outputs को देखें, तो confusion की स्थिति में LLM अतिरिक्त स्पष्टीकरण माँगने के बजाय सिर्फ़ अंदाज़ा लगाता रहता है कि user का मतलब क्या रहा होगा। यह “मानव programmers को replace कर देंगे” जैसी सोच की वास्तविक सीमाएँ दिखाता है। असली कठिन हिस्सा तो stakeholders के साथ interaction के ज़रिए अस्पष्ट requirements को स्पष्ट बनाना होता है

    • self-reflection की अक्षमता के बारे में, LLM में कोई वास्तविक agency नहीं होती; user एक तरह की “belief-maintenance story” में फँस जाता है। ज़्यादातर मामलों में user अगर फ़िल्म script के user-role की तरह text input देता है, तो LLM chatbot-role में अधूरी storyline को बस autocomplete करता है। उदाहरण के लिए Dracula-bot के साथ interview में self-reflection को वह सिर्फ़ सतही तौर पर “खून की प्यास” या “चमगादड़ों के बादल में बदलना” जैसी चीज़ों से mimic करता है
    • मैं भी इस बात से उतना ही निराश हूँ कि ambiguity वाले open-ended problem situations (खासकर paradoxes) में LLM स्पष्ट रूप से अतिरिक्त जानकारी नहीं माँग पाता। मैंने DeepSeek-R1 और Claude-3.7-Sonnet पर इसे test किया है, और इस पर एक experimental blog भी है
    • Gemini 2.5 Pro और ChatGPT-o3 अक्सर task execute करने से पहले अतिरिक्त जानकारी माँगते हैं। Gemini कई options भी पेश करता है और मेरा input मांगता है
    • असली programmers वास्तव में अपना ज़्यादातर समय requirements को ठीक-ठीक समझने में लगाते हैं। LLM अब भी guessing को ही एक feature की तरह लेता है
    • विडंबना यह है कि junior developers के साथ काम करते हुए भी अक्सर यही होता है। उन्हें कोई task दो, तो वे सीधे भागते जाते हैं, assumptions पर assumptions बनाते हैं, कोई सवाल नहीं पूछते, और अंत में इतने गहरे जंगल में फँस जाते हैं कि rescue team भेजनी पड़े
    • मुझे लगता है इसे काफ़ी आसानी से बदला जा सकता है। जैसे chain of thought prompting में आख़िरी token को “हूँ” जैसा मोड़ दिया जाता है, वैसे ही जब LLM “शायद यह ~ होगा” जैसी बात कहने लगे, तो token को “पहले मैं अतिरिक्त स्पष्टीकरण माँगूंगा” में बदल देना चाहिए
    • अतिरिक्त जानकारी माँगना या self-reflection भी, अगर कहा जाए, तो वह काफ़ी अच्छी तरह कर सकता है

  • मुझे यह तकनीक पसंद है कि अब तक की चर्चा को LLM से concise prompt format में summarize करवाऊँ, फिर उसे खुद modify/edit करके नई conversation शुरू करूँ। यह काफ़ी असरदार रही है, और मुझे लगता है जल्द ही automate हो जाएगी

    • Cursor ने यह अपने आप करने की कोशिश की थी, लेकिन (जब तक large-context model न हो) summarized सामग्री बहुत ज़्यादा details छोड़ देती थी, इसलिए व्यवहार में ज़्यादा काम की नहीं थी
    • Claude Code में /compact command है, जो conversation summarize करके token usage कम करता है

  • मैंने खुद TSCE (Two-Step Contextual Enrichment) बनाया। GPT-35-turbo के साथ 300 tasks पर इस्तेमाल करने से performance +30pp बढ़ी। यह open framework है और मुक्त उपयोग के लिए उपलब्ध है। gpt-4.1 के साथ 300 अतिरिक्त experiments भी किए। baseline में em-dash हटाने में 149/300 बार विफलता हुई, TSCE में 18/300 बार। पूरा data और scripts भी प्रकाशित हैं

    • एक साधारण find and replace काम पर kilowatt-hours बर्बाद हो रहे हैं। क्या आपने text.replace("—", "-") जैसा कुछ आज़माया है?
    • baseline prompt में थोड़ा-सा बदलाव करके भी GPT-4.1 पर 100% success rate मिल गया। अतिरिक्त calls, token खर्च, या जटिल techniques के बिना भी यह संभव था

  • मुझे दो systems (LMM + automatic curator) के साथ समस्याएँ हल करने का अनुभव है। एक खुद LLM, दूसरा “thought curator” जो context के हिस्सों को गतिशील रूप से बदलता और manage करता है। यह स्पष्ट नियमों के बजाय LLM की fill-in क्षमता पर आधारित है। यह problem को छोटे हिस्सों में बाँटकर हल करवाने में मदद करता है, और वे नतीजे मिलकर अंतिम लक्ष्य तक पहुँचते हैं

    • शानदार विचार। यह अभी जो हो रहा है, वह conversational RAG जैसा लगता है। भविष्य में memory layers (training data / current context / RAG) का विभाजन और स्पष्ट होगा
    • दिलचस्प विचार है। अगर आप इसे दुनिया के साथ, भले ही सरल रूप में, साझा करें तो बहुत लोग इसे बेहतर बनाते हुए community को खुद बढ़ा सकते हैं
    • यह Emotion Machine में बताए गए internal criticism system जैसा है
    • काश आपके बन रहे project के बारे में और जानकारी मिल सके। काफ़ी रोचक लग रहा है
    • तो अंततः इसे Map-Reduce-of-Thought कहा जा सकता है

  • यह अजीब है कि main chat tools में branching/forking डिफ़ॉल्ट नहीं है। जवाबों को edit तो किया जा सकता है, लेकिन उस स्थिति में बहुत-सा दूसरा context खो जाता है। मेरा workflow है 1. plan 2. build 3. branch 4. repeat. मुझे लगता है prompt pruning/branching, LLM उपयोग का मुख्य tool होना चाहिए

    • Google AI Studio में कम से कम यह feature है। लेकिन उसका implementation उलझा हुआ था, और शायद यही वजह है कि यह ज़्यादा नहीं फैला
    • मैं लंबे समय से खुद ऐसा कुछ बनाना चाहता था। BetterChatGPT में कम से कम history deletion interface अच्छा है, लेकिन मुझे भी branching अगला कदम लगता है

  • जब LLM interfaces को single-turn conversation केंद्रित बनाकर डिज़ाइन किया जाता है, तो समस्याएँ आती हैं। ज़्यादातर users linear बातचीत की अपेक्षा करते हैं। इसलिए मैंने Telegram bot experai_bot बनाया, ताकि वह LLM के लिए universal UI बन सके, और “reply नहीं तो नई बातचीत” वाला approach इस्तेमाल किया। context बनाए रखना है, तो reply tree structure में ही आगे बढ़ना चाहिए। non-experts को इस तरीके को समझने में दिक्कत होती है। साथ ही OpenAI models (3.5, 4o के आधार पर) में एक ही सवाल दोहराने पर whitespace या options छोटे होते जाते हैं और नतीजे धीरे-धीरे कम सटीक होने लगते हैं। system message को न्यूनतम रखने पर results अपेक्षाकृत स्थिर रहते हैं। ज़रूरत हो तो option के रूप में system message जोड़ा जा सकता है

  • promptdown बनाने का मेरा मुख्य कारण यही था कि पूरी chat history को हर turn पर पूरी तरह edit किया जा सके। standard interfaces की ‘append-only’ संरचना इसे कठिन बना देती है

  • इस समय LLM क्षेत्र ऐसा लगता है जैसे हर कोई वही समस्या बार-बार हल कर रहा है

    • multi-turn conversations में LLM की तरह, हर कोई वही समस्या दोहराता जा रहा है
    • यह “learning” नहीं बल्कि “cats को हाँकने” जैसा है, लेकिन कुछ workflows के लिए यह उपयुक्त है
    • हर कोई अपनी prompt engineering skill दिखाना चाहता है

  • LLM सचमुच बोतल वाले जिन्न जैसा है। तीन सवालों तक जवाब देता है, उसके बाद अजीब बातें करने लगता है