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

 (arxiv.org)
4 पॉइंट द्वारा GN⁺ 2025-05-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जब उपयोगकर्ता अपनी आवश्यकताएँ एक ही बार में पूरी तरह नहीं लिख पाता, तो 15 LLMs का मल्टी-टर्न·अपूर्ण निर्देश प्रदर्शन सिंगल-टर्न·पूर्ण निर्देश की तुलना में काफ़ी गिर जाता है; 6 जनरेशन टास्क का औसत 90% से घटकर 65% रह गया
  • प्रयोग को मौजूदा सिंगल-टर्न बेंचमार्क निर्देशों को कई हिस्सों में बाँटने वाली sharding पद्धति से बनाया गया, ताकि बातचीत आगे बढ़ने पर शर्तें और संदर्भ धीरे-धीरे सामने आएँ
  • प्रदर्शन में गिरावट का मुख्य कारण सिर्फ़ क्षमता की कमी नहीं, बल्कि अस्थिरता में वृद्धि था; 200,000 से अधिक बातचीतों में मॉडल शुरुआती मान्यताओं और जल्दी अंतिम उत्तर देने की कोशिश पर ज़रूरत से ज़्यादा निर्भर दिखे
  • परीक्षण में Llama3.1-8B-Instruct से लेकर Gemini 2.5 Pro तक के मॉडल शामिल थे, और Code, Database, Actions, Math, Data-to-Text, Summary जैसे प्रोग्रामिंग और प्राकृतिक भाषा जनरेशन टास्क साथ में इस्तेमाल किए गए
  • यह वास्तविक मानव-AI बातचीत का एक सरल सिमुलेशन है, लेकिन सभी बातचीत इस तरह डिज़ाइन की गई थीं कि अंत तक समस्या हल करने लायक पर्याप्त जानकारी मिल जाए; इसलिए देखी गई गिरावट वास्तविक अपूर्ण मल्टी-टर्न बातचीत की तुलना में कम हो सकती है

सिंगल-टर्न मूल्यांकन और वास्तविक संवाद उपयोग के बीच अंतर

  • LLMs को ChatGPT, Gemini, Claude जैसे संवादी इंटरफ़ेस में इस्तेमाल किया जाता है, और उपयोगकर्ता अक्सर शुरुआत में अपनी आवश्यकता पूरी तरह तय नहीं कर पाते; वे कई टर्न में उसे परिभाषित, खोज और संशोधित करते हैं
  • मौजूदा LLM मूल्यांकन ज़्यादातर सिंगल-टर्न·पूर्ण निर्देश वातावरण पर केंद्रित रहे हैं, जबकि LLM बातचीत लॉग में उपयोगकर्ता निर्देशों की अपूर्णता आम है
  • कई मौजूदा मल्टी-टर्न मूल्यांकन बातचीत को स्वतंत्र रूप से जाँचे जा सकने वाले उप-कार्यों की श्रृंखला जैसा मानते हैं; यह episodic दृष्टिकोण के अधिक क़रीब है
    • यह टर्नों के बीच कुछ संदर्भ-समझ की माँग तो करता है, लेकिन अपूर्ण उपयोगकर्ता निर्देशों से जानकारी को सक्रिय रूप से जोड़ने वाली स्थिति से अलग है
    • ऐसे टास्क मल्टी-टर्न बातचीत में LLM प्रदर्शन को वास्तविकता से बेहतर दिखा सकते हैं

sharding से बनाई गई अपूर्ण मल्टी-टर्न बातचीत

  • प्रयोग में उच्च-गुणवत्ता वाले सिंगल-टर्न बेंचमार्क के पूर्ण निर्देशों को sharded instruction में बदला गया
    • पहला shard टास्क के उच्च-स्तरीय इरादे को बताता है
    • बाद के shard मूल निर्देश की अतिरिक्त शर्तें या संदर्भ एक-एक करके देते हैं
    • सभी shard मिलाकर वही जानकारी बनती है जो मूल पूर्ण निर्देश में थी
  • उदाहरण के तौर on GSM8K के snowball प्रश्न में एक ही विवरण में “हर घंटे 20 बनते हैं”, “हर 15 मिनट में 2 पिघलते हैं”, “कुल 60 चाहिए” जैसी सभी शर्तें दी जाती हैं, लेकिन sharded संस्करण इन्हें कई टर्न में बाँटकर प्रकट करता है
  • sharding प्रक्रिया अर्ध-स्वचालित थी; GPT-4o ने उम्मीदवार बनाए और सत्यापित किए, फिर शोधकर्ताओं ने उनकी समीक्षा और संशोधन किया

बातचीत सिमुलेशन की संरचना

  • मल्टी-टर्न सिमुलेशन में तीन घटक हैं
    • मूल्यांकनाधीन assistant: वह LLM जिसका प्रदर्शन मापा जाना है
    • user simulator: वह LLM जिसे पूरा sharded instruction पता है और जो हर टर्न में अगला shard खोलता है
    • system: वह घटक जो assistant के उत्तरों को वर्गीकृत करता है और उत्तर-प्रयास का मूल्यांकन करता है
  • पहले टर्न में user simulator केवल पहला shard दिखाता है, और assistant स्वतंत्र टेक्स्ट में जवाब देता है
  • assistant के जवाब को 7 रणनीतियों में से एक में वर्गीकृत किया जाता है
    • clarification
    • refusal
    • hedging
    • interrogation
    • discussion
    • missing
    • answer attempt
  • यदि जवाब को answer attempt माना जाता है, तो answer extractor कोड अंश, संख्या, SQL आदि जैसे मूल्यांकन-योग्य उत्तर हिस्से निकालता है, और टास्क-विशिष्ट evaluator स्कोर देता है
  • बातचीत दो में से किसी एक शर्त पर समाप्त होती है
    • assistant का उत्तर-प्रयास सही माना जाए
    • नए टर्न की शुरुआत पर दिखाने के लिए कोई shard बाकी न हो
  • user simulator, strategy classifier और answer extractor को prompt-आधारित GPT-4o-mini से लागू किया गया
  • सैकड़ों बातचीतों के मैनुअल annotation से पाया गया कि user simulator·classifier·extractor की त्रुटियाँ जाँची गई बातचीतों के 5% से कम में थीं, और assistant मॉडल के ख़िलाफ़ जाने वाली त्रुटियाँ 2% से कम थीं

तुलना किए गए पाँच सिमुलेशन प्रकार

  • FULL मूल पूर्ण निर्देश को पहले टर्न में देने वाला सिंगल-टर्न सिमुलेशन है, और इसे आधारभूत प्रदर्शन baseline के रूप में इस्तेमाल किया गया
  • SHARDED कई टर्न में shard खोलने वाली मल्टी-टर्न·अपूर्ण बातचीत है; यही मुख्य मूल्यांकन वातावरण है
  • CONCAT shard को एक टर्न के bullet-point निर्देश में जोड़कर देता है
    • FULL की तरह अपूर्णता हट जाती है
    • SHARDED की तरह sharding प्रक्रिया में हुई पुनर्व्यक्ति बनी रहती है
    • यदि FULL और CONCAT में सफलता मिले लेकिन SHARDED में विफलता हो, तो कारण सूचना-हानि नहीं बल्कि मल्टी-टर्न·अपूर्णता स्वयं हो सकती है
  • RECAP में SHARDED बातचीत के बाद अंत में सभी shard एक साथ फिर से दिए जाते हैं, ताकि LLM को अंतिम उत्तर का एक और मौका मिले
  • SNOWBALL में हर टर्न पर नए shard के साथ अब तक खुले सभी shard फिर से बताए जाते हैं, यानी हर टर्न पर संचयी सारांश दिया जाता है

इस्तेमाल किए गए टास्क और बेंचमार्क

  • प्रयोग में प्रोग्रामिंग और प्राकृतिक भाषा जनरेशन दोनों उपयोग मामलों को कवर करने वाले 6 जनरेशन टास्क शामिल थे
  • हर टास्क के लिए 90~120 sharded instruction तैयार किए गए, और कुल 600 instruction थे
  • टास्क संरचना:
    • Code: HumanEval, LiveCodeBench आधारित Python फ़ंक्शन लेखन
    • Database: Spider आधारित text-to-SQL जनरेशन
    • Actions: Berkeley Function Calling Leaderboard आधारित API फ़ंक्शन कॉल जनरेशन
    • Math: GSM8K आधारित प्राथमिक गणित शब्द-समस्या समाधान
    • Data-to-Text: ToTTo आधारित तालिका डेटा का वर्णनात्मक वाक्य जनरेशन
    • Summary: Summary of a Haystack आधारित दस्तावेज़-समूह सारांश और citation जनरेशन
  • मूल्यांकन मेट्रिक्स में मूल बेंचमार्क के मेट्रिक्स को ही पुनः इस्तेमाल किया गया
    • Code और Database के लिए execution-आधारित accuracy
    • Actions और Math के लिए संदर्भ उत्तर से semantic equivalence या संख्यात्मक सही उत्तर
    • Data-to-Text के लिए BLEU
    • Summary के लिए सूचना कवरेज और source attribution accuracy मापने वाला LLM-as-a-judge “Joint Score”
  • बाइनरी accuracy को भी 0~100 रेंज में मैप किया गया, ताकि सभी टास्क स्कोर एक ही स्केल पर जोड़े जा सकें

प्रदर्शन, क्षमता और अस्थिरता का मापन

  • LLM output प्रायिकतात्मक होते हैं, इसलिए उसी instruction और simulation type पर N=10 बार दोहराकर रन किया गया
  • हर रन का मूल्यांकन 0~100 रेंज के स्कोर से किया गया
  • तीन मेट्रिक्स इस्तेमाल किए गए
    • औसत प्रदर्शन P: दोहराए गए रन के स्कोर का औसत
    • aptitude A90: स्कोर का 90वाँ percentile, यानी शीर्ष 10% रन में best-case प्रदर्शन का अनुमान
    • unreliability U90-10: 90वें percentile और 10वें percentile का अंतर, यानी best-case और worst-case के बीच का फ़ासला
  • सिंगल-टर्न में उच्च aptitude वाले मॉडल अधिक विश्वसनीय भी होते थे, लेकिन मल्टी-टर्न में aptitude से स्वतंत्र रूप से सभी LLMs में unreliability अधिक दिखी

बड़े पैमाने के प्रयोग के परिणाम

  • मुख्य प्रयोग 600 instruction, 3 simulation type (FULL, CONCAT, SHARDED) और 15 LLMs पर किया गया
  • हर संयोजन को 10 बार दोहराकर 200,000 से अधिक बातचीतों का सिमुलेशन किया गया
  • सभी simulation डिफ़ॉल्ट temperature T=1 पर चलाए गए, और aptitude व reliability पर temperature के प्रभाव को अलग सहायक प्रयोग में देखा गया
  • कुल मिलाकर मल्टी-टर्न·अपूर्ण बातचीत में औसत प्रदर्शन 65% था, जो शुरुआत से पूरा निर्देश मिलने वाली सिंगल-टर्न performance 90% से 25 अंक कम है
  • छोटे open-weight मॉडल से लेकर नवीनतम मॉडल तक, मल्टी-टर्न प्रदर्शन में गिरावट समान रूप से देखी गई
    • परीक्षण में Llama3.1-8B-Instruct जैसे छोटे open-weight मॉडल और Gemini 2.5 Pro जैसे नवीनतम मॉडल शामिल थे
    • Figure 1 में Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1, Gemini 2.5 Pro को उदाहरण के रूप में दिखाया गया है
  • 6 जनरेशन टास्क के औसत प्रदर्शन में गिरावट 39% थी, और Figure 1 मल्टी-टर्न सेटिंग में लगभग -35% performance drop दिखाता है

वे रास्ता क्यों भटकते हैं

  • प्रदर्शन में गिरावट को दो हिस्सों में बाँटा गया
    • aptitude में कमी: best-case प्रदर्शन स्वयं कुछ कम हो जाता है
    • unreliability में वृद्धि: रन के बीच गुणवत्ता का अंतर बहुत बढ़ जाता है
  • Figure 1 के अनुसार मल्टी-टर्न में aptitude -15% घटता है और unreliability +112% बढ़ती है
  • मॉडल शुरुआती अपूर्ण जानकारी देखकर ग़लत मान्यताएँ बना लेते हैं और बातचीत के शुरुआती चरण में ही अंतिम उत्तर देने की कोशिश करते हैं
  • बाद में नई जानकारी मिलने पर भी वे पहले के ग़लत उत्तर-प्रयास पर अत्यधिक निर्भर रहते हैं और दिशा सुधारने में विफल होते हैं
  • मल्टी-टर्न अपूर्ण बातचीत में एक बार ग़लत दिशा में जाने के बाद संभल न पाने की इस स्थिति को lost in conversation कहा गया है

सीमाएँ और व्यावहारिक निहितार्थ

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

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

1 टिप्पणियां

 
GN⁺ 2025-05-16
Hacker News की राय

  • जिन्होंने LLM tools इस्तेमाल किए हैं, उनके लिए अच्छा है कि पेपर heuristic तौर पर पहले से पता बात की पुष्टि करता है। साफ़ context बनाए रखना अहम है, और “conversation” सिर्फ़ product interface द्वारा बनाई गई रचना है; LLM की अपनी response quality के लिए यह नुकसानदेह है। Context एक बार दूषित हो जाए तो recover नहीं होता, इसलिए नई chat से फिर शुरू करना पड़ता है

    • मेरा अनुभव भी कुछ हद तक इस observation से मेल खाता है, लेकिन दूसरे मामले भी रहे। Gemini के साथ मैंने IPSEC issue को 2 हफ्ते तक debug किया; शुरुआत में OPNsense और pfSense के IPSEC docs दोनों डाले, काम का context बताया, फिर दोनों तरफ़ की settings sensitive information हटाकर जोड़ दीं। उसके बाद logs upload करके सवाल-जवाब की लंबी feedback loop चलाई
      2 हफ्तों के अंत तक LLM बहुत कम भटकने लगा था, और forum threads या Stack Overflow posts पूरे डालने पर भी यह अलग कर देता था: “यह वह phenomenon नहीं है जो यहाँ दिख रहा है। वजह [पिछले context या discovery] है।” Dead ends मुझे logically eliminate करके बताने पड़े, लेकिन आखिर में root cause मिल गया
      यह बात भी सही लगती है कि LLM जटिल जानकारी को सरल रूप में compress करने में मजबूत है, और सरल ideas को complex चीज़ों में expand करने में कमजोर। जब input output से बड़ा या ज्यादा complex था, तो result संतोषजनक रहा
      LLM के बिना भी यह किया जा सकता था, लेकिन जब मैं शुरुआत से डाले गए facts भूल गया था या नए context में जल्दी याद नहीं कर पा रहा था, तब यह repository की तरह मददगार रहा, और बड़े log files में time patterns खोजने में भी useful था। सिर्फ़ एक problem fix नहीं की; कई settings भी optimize कीं और काफी कुछ सीखा। यह कभी-कभी current parameter state गलत बताता था, लेकिन उसे आसानी से ठीक किया जा सकता था। अगर आपको पता है कि जाना कहाँ है और इसे tool की तरह handle करते हैं, तो यह मदद करता है; लेकिन decision-making इसे सौंपनी नहीं चाहिए या इसे आपको गलत दिशा में ले जाने देना नहीं चाहिए
      कुल usage लगभग 350k tokens था। संबंधित blog post https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/ पर है, हालांकि यह इस specific issue से सीधे match नहीं करता। WireGuard की सलाह नहीं चाहिए
    • मेरे अनुभव से बिल्कुल मेल खाता है। “दूषित” शब्द अच्छा है। एक बार कुछ गलत हो जाए तो लगता है कि बाद के सारे responses खराब हो जाते हैं, इसलिए ChatGPT का memory feature भी मुझे थोड़ा ambiguous लगता है। ऐसा नहीं कि इससे बड़े problems होते दिखे हों, लेकिन जिस तरीके को मैं पूरी तरह समझता नहीं, उससे context गंदा होता है—यह मुझे पसंद नहीं
    • मैं काफी समय से कहता आया हूँ कि conversation fork करना संभव होना चाहिए। मैं यह experiment करना चाहता हूँ कि exchange किस दिशा में जाता है, बिना किसी promising flow को irreversibly दूषित किए। ChatGPT में यह नहीं हो सकता; जानना चाहूँगा कि कहीं यह feature मिलता है या नहीं
    • मेरी सिखाई जाने वाली नंबर 1 tip है कि ChatGPT और Claude के बहुत छोटे और लगभग छिपे हुए “edit” button का actively इस्तेमाल करें। अगर खराब response आए, तो उसके ऊपर आगे build न करें; रुककर edit करें ताकि बेहतर response मिले और कचरा कचरे को बढ़ाता न जाए
    • इस problem का एक दिलचस्प छोटा example initial prompt है। क्योंकि वह practically मिटाया न जा सकने वाला permanent और hidden context होता है। अभी Twitter का “Grok” bot हाल में “White Genocide” का अक्सर ज़िक्र करने लगा है, जो काफी अजीब है
      बहुत संभव है कि किसी ने हाल में prompt tweak करके white genocide पर perspective specify किया हो; perfect chatbot होता तो दूसरे topics पूछने पर यह matter नहीं करता, लेकिन reality में करता है। वह context का हिस्सा है, इसलिए अब वह इसी बारे में बात करने लगता है

  • यह जानी-पहचानी overconfidence और self-reflection में अक्षमता का एक पहलू लगता है। अगर prior probability बहुत कम हो, तो इसे यह समझ नहीं आता कि और detailed information मांगनी चाहिए। Reasoning models का output देखें तो clarification questions पूछने का विचार लगभग आता ही नहीं, और confuse होने पर यह बस अंतहीन अंदाज़े लगाता रहता है कि user का मतलब क्या रहा होगा
    इसका “human programmer replacement” वाले विचार की समझदारी पर भी असर है। क्योंकि इस job के कठिन हिस्सों में से एक stakeholders के साथ interact करके vague और अक्सर confusing ideas को precise specifications में बदलना है

    • “self-reflection में अक्षमता” के बारे में, मुझे लगता है LLMs से deal करने की core trick यह पहचानना है कि कोई real agent नहीं है और user suspension of disbelief वाली narrative में फंस रहा है
      ज़्यादातर मामलों में user किसी movie script document में User character की lines लिख रहा होता है, और LLM algorithm बस समय-समय पर Chatbot character की incomplete lines को autocomplete करता है
      आप DraculaBot नाम के vampire का interview कर सकते हैं, लेकिन वह character सिर्फ़ उतने ही superficial और fictional तरीके से “self-reflect” कर सकता है जितना वह “खून की लालसा” रखता है या “चमगादड़ों के झुंड में बदल” जाता है
    • LLM का clarification questions न पूछ पाना ठीक वही defect था जो अस्पष्ट रूप से बताए गए open problem को test करते समय सामने आया। यह paradoxical situations को DeepSeek-R1 और Claude-3.7-Sonnet से test करने के context में था, और experiment post https://pankajpansari.github.io/posts/paradoxes/ पर है
    • असली programmers बहुत समय यह पता लगाने में लगाते हैं कि लोग वास्तव में चाहते क्या हैं। LLM अभी भी guessing को feature की तरह treat करता है
    • इसे पढ़कर ऐसा लगता है जैसे smart लोगों को बेहतर Emacs doctor से बेवकूफ बनते देख रहा हूँ। LLM न introspect करता है, न confident होता है। वह “बस” text autocomplete suggest करता है
      इसलिए जब autocomplete खराब होने लगे, तो नए सिरे से शुरू करना पड़ता है। कोई concepts नहीं हैं, सिर्फ़ training text में दिखे words और संभावित follow-up text का विशाल ढेर है
    • “human programmer replacement” वाले विचार के संबंध में विडंबना यह है कि junior developers के साथ काम करना भी काफी ऐसा ही होता है। आप task देते हैं और बाद में कुत्ते और torch लेकर गहरे जंगल में उन्हें खोजने जाना पड़ता है। क्योंकि वे बस आगे बढ़ते जाते हैं, assumptions बना लेते हैं, सवाल नहीं पूछते और रास्ता खो देते हैं

  • मैं अक्सर LLM से अब तक की discussion का prompt format में concise summary बनाने को कहता हूँ। उसे सही तरह edit करके baggage-free नई conversation शुरू करने में इस्तेमाल करना बहुत प्रभावी रहा है। शायद यह जल्द ही automate हो जाएगा

    • Cursor ने इसे automatically करने की कोशिश की थी। अगर Gemini 2.5 Pro जैसे बड़े context model का इस्तेमाल न करें, तो अभी भी ऐसा हो सकता है। लेकिन summary से बहुत सारी details छूट जाती थीं, इसलिए उसे ज्यों का त्यों इस्तेमाल करना मुश्किल था
    • Claude Code में अब तक की conversation को summarize करके context tokens बचाने के लिए /compact command है

  • इसलिए TSCE (Two-Step Contextual Enrichment) बनाया गया। GPT-35-turbo के साथ 300 tasks को मिलाकर test करने पर +30 percentage points का improvement दिखा
    यह एक free public framework है और repository में सीधे आज़माया जा सकता है: https://github.com/AutomationOptimization/tsce_demo
    लोगों को नापसंद आने वाले उभरे हुए “em-dash” हटाने के task पर gpt-4.1 में फिर से 300 बार test किया गया। single-pass baseline और TSCE की तुलना समान instruction और prompt “Remove the em-dashes from my linkedin post. . .” के साथ की गई
    300 runs में baseline 149/300 बार em-dash हटाने में fail हुआ, जबकि TSCE 18/300 बार fail हुआ। यह काम करता है, और पूरा data व test scripts repository में मौजूद हैं

    • लगता है find-and-replace task पर बहुत ज्यादा kilowatt-hours बर्बाद कर दिए गए। सोच रहा हूं text.replace("—", "-") के बारे में सुना है या नहीं
    • em dash baseline example को थोड़ा सा बदलते ही, extra calls, token cost या technical दिखावे के बिना GPT-4.1 में 100% success rate मिला
      system prompt: "Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."
      user prompt:
      Temperature: 0.0

  • इस समस्या को हल करने पर काफी सफलतापूर्वक काम कर रहा हूं, और जल्द ही और share करूंगा। system 2 हैं: पहला खुद LLM है और दूसरा एक तरह के thought curator की तरह काम करता है
    context के कुछ हिस्सों को dynamically जोड़ता और हटाता है, explicit definitions पर आधारित नहीं होता और LLM की “खाली जगहें भरने” की क्षमता पर निर्भर करता है। यह system LLM को problem को छोटे tasks में तोड़ने में मदद करता है, और वे छोटे tasks आखिर में पूरे task में aggregate हो जाते हैं

    • अच्छा idea है। असल में यह chat के ऊपर किया जाने वाला Retrieval-Augmented Generation (RAG) है
      आगे चलकर ऐसी memory layers का distinction और स्पष्ट होगा। training data की primary memory, context की secondary memory, और RAG की tertiary memory जैसी layers हो सकती हैं
    • दिलचस्प idea लगता है। भले ही अभी यह सिर्फ कुछ prompts के स्तर का हो, जो भी आपके पास है उसे दुनिया के सामने public करने की सलाह दूंगा। लोग देखकर improve कर सकते हैं, और अगर idea अच्छा है तो उसे अपनाया जाएगा, दूसरे लोग उस पर काम करेंगे, और शायद वह अपनी life ले ले
    • यह Emotion Machine के mental critic वाली category में आता है
    • तो क्या यह Map-Reduce-of-Thought है?

  • यह हैरानी की बात है कि major chat tools में branching/forking core feature नहीं है। response edit कर सकते हैं, लेकिन ऐसा करने पर काफी दूसरा context गायब हो जाता है
    मेरा flow लगभग ऐसा है: 1) plan 2) implement 3) branch (किसी feature या अजीब dependency issue की वजह से) 4) फिर step 2 पर जाना। prompt pruning और branching किसी भी LLM use में first-class tools होने चाहिए

    • Google AI Studio में कम से कम यह feature है। हालांकि उसकी implementation काफी confusing थी, और शायद इसी वजह से यह ज्यादा “consumer-oriented” tools में अच्छे से शामिल नहीं होती
    • कुछ समय से ऐसा कुछ बनाने के बारे में सोच रहा था। BetterChatGPT में कम से कम history deletion की usability ठीक है। लेकिन मैं सहमत हूं कि अगला step branching है

  • single-turn बातचीत को केंद्र में रखकर LLM interface बनाने पर एक साफ समस्या दिखती है। ज्यादातर लोग linear conversation की उम्मीद करते हैं
    मैंने LLMs के लिए general-purpose UI के तौर पर Telegram bot http://t.me/experai_bot बनाया था, features थोड़ा कम रखे और इसे “जो message reply नहीं है, वह नई conversation है” वाले idea के around design किया। context बनाए रखना हो तो bot के reply पर लगातार reply करते रहें। advanced user न होने वाले लोगों को यह concept मुश्किल लगता है
    यह भी देखा कि OpenAI model जब उसी सवाल का जवाब देता है, तो बहुत छोटा system message होने पर भी performance खराब हो जाती है। जैसे reply में options की list छोटी हो गई। 3.5 और 4o में ऐसा था; latest models के बारे में नहीं पता। इसलिए default रूप से system message न डालने का फैसला किया। फिर भी जरूरत हो तो जोड़ सकते हैं, और on/off करके combine भी कर सकते हैं

  • अभी LLM space में ऐसा लगता है जैसे लोग वही problem बार-बार solve कर रहे हैं

    • कुछ workflows में ठीक है, लेकिन यह “learning” से ज्यादा cats herding जैसा है
    • हर कोई अपनी शानदार prompt engineering जोड़ना चाहता है

  • यही मुख्य वजह थी कि मैंने promptdown बनाया। मैं हर turn पर पूरी chat history edit कर पाना चाहता था, और append-only standard chat interface में यह आसान नहीं है
    https://github.com/t-kalinowski/promptdown

  • “prompt engineering” शब्द पर जो मजाक उड़ाया जाता है, मुझे हमेशा लगा कि उसका एक कारण यह भी है कि लोग initial prompt की अहमियत को बढ़ा-चढ़ाकर आंकते हैं और ongoing context management की अहमियत को कम करके देखते हैं
    experience से यह sense विकसित होता है कि model को कैसे steer करना है और कब नई conversation शुरू करनी है। system prompt या initial prompt भी important हैं, लेकिन अगर भोलेपन से conversation बहुत लंबी खींच दी जाए तो वे कुछ नहीं बचा पाएंगे

    • सही है। prompt engineering सिर्फ perfect पहली line बनाने का काम नहीं है, बल्कि यह ज्यादा conversation management जैसा है। flow कब पटरी से उतर रहा है और कब reset करना चाहिए, इसका अंदाजा experience से आता है