LLM को निर्णय और बिजनेस लॉजिक न सौंपें

• LLM को application का निर्णय लेने वाला घटक बनाने के बजाय, उसे user input और API-आधारित logic के बीच आने-जाने वाले natural language interface तक सीमित रखना सुरक्षित है
• Chess bot का उदाहरण दिखाता है कि state management और decision-making LLM को सौंपने पर performance, debugging, testing, cost के मामले में यह specialized engine या सामान्य code से पीछे रह जाता है
• Game attack, negotiation agent, random selection जैसे क्षेत्रों में, जहाँ outcome महत्वपूर्ण होता है, निर्णय LLM से नहीं बल्कि verify किए जा सकने वाले system से करवाना चाहिए
• LLM जिन कामों में अच्छा है वे हैं attack(target="orc", weapon="sword") जैसे structured transformation, error messages को natural language में बदलना, intent classification, और इंसानी expression की interpretation
• Model performance लगातार बेहतर होती रहे, तब भी core logic को अलग system में रखने से reasoning, maintenance, execution cost और version management को संभालना आसान रहता है

---

Core logic से LLM को हटाने की वजह

• ज़्यादातर applications में LLM को user और application logic API के बीच user interface तक ही रहना चाहिए
• Chess bot के उदाहरण में user WhatsApp पर “bishop से knight को मारूंगा” जैसे natural language commands भेजता है, और bot chess खेलता है
  • LLM chessboard की state बनाए रख सकता है और संभवतः credible तरीके से खेल भी सकता है, लेकिन ऐसा design करने की कोई वजह नहीं है
  • संबंधित उदाहरण के रूप में chess लेख दिया गया है
• Specialized chess engine, LLM की तुलना में तेज़, बेहतर खेलने वाला और सस्ता chess player हो सकता है
  • Stockfish जैसे modern chess engines में neural network शामिल हों, तब भी वे स्पष्ट input और evaluation function वाले purpose-specific systems हैं
  • यह general-purpose LLM द्वारा केवल text के जरिए game state बनाए रखने के तरीके से अलग है
• LLM ने कौन-सा निर्णय क्यों लिया, इसका अनुमान लगाना और debug करना कठिन है, इसलिए decision-making के तरीके को adjust करना भी मुश्किल हो जाता है
  • High-dimensional semantic space में वह किस रास्ते से answer तक पहुँचा, यह समझना कठिन है, और LLM खुद भी इसे अच्छी तरह explain नहीं कर पाता
  • Anthropic की language model thoughts tracing research जैसी प्रगति के बावजूद, general LLMs की observability अब भी कठिन बनी हुई है
• Operations के लिहाज़ से भी LLM में core logic के लिए अनुपयुक्त कई constraints हैं
  • LLM output testing, known code paths की unit testing से कठिन है
  • Maths में यह CPU से कमज़ोर है, और random number selection भी पर्याप्त अच्छा नहीं है
  • Version management और audit कठिन हो जाते हैं, monitoring और observability भी जटिल हो जाती है
  • Natural language-based state management कमजोर है, और API rate limits तथा cost पर निर्भर रहता है
  • अगर हर flow prompt से होकर गुजरता है, तो security boundary धुंधली हो जाती है

LLM को कौन-से काम सौंपना अच्छा है

• अगर user कहे कि “vorpal sword से player X पर हमला करूंगा”, तब भी LLM को यह तय नहीं करना चाहिए कि उसके पास वह weapon है या नहीं, या combat outcome क्या होगा
  • उसे free text को API call में बदलने और system द्वारा निकाले गए result को फिर user को explain करने पर focus करना चाहिए
• Negotiation agent में भी LLM negotiation decision सीधे नहीं लेता
  • Proposal को package करके negotiation engine को देना और result user तक पहुँचाना उसकी उपयुक्त भूमिका है
• User response में random selection की जरूरत हो, तब भी LLM को selector नहीं बनना चाहिए
• LLM की strength transformation, interpretation, classification, communication में है
  • “hit the orc with my sword” को attack(target="orc", weapon="sword") में बदल सकता है
  • {"error": "insufficient_funds"} को “You don’t have enough gold for that.” में बदल सकता है
  • User intent को route कर सकता है कि यह combat command है, inventory check है, या help request है
  • “blade” शायद sword है और “smash” शायद attack है—ऐसी human concepts को समझ सकता है
• LLM लगातार बेहतर होकर ऐसे मामलों को काफी अच्छी तरह handle करने लगे, तब भी core logic को purpose-specific system में रखने वाली structure maintenance, cost और version management के लिए अधिक उपयुक्त है

[GN⁺]

Hacker News की राय

• यहाँ एक ज्यादा सामान्य दोराहा दिखता है। लॉजिक दो तरह का होता है: जिसे सटीक और सख्त होना चाहिए, और वह जिसे अब तक सिर्फ इसलिए वैसा implement किया गया क्योंकि कंप्यूटर ऐसे ही काम करते थे
  सुरक्षा, फाइनेंस, पक्षों के बीच टकराव वाले काम, गणित या स्पष्ट नियमों वाले गेम जैसे पहले से ही सटीक क्षेत्रों से जुड़ी चीजें पहली श्रेणी में आती हैं। दूसरी श्रेणी में वे मामले हैं जहाँ approximation और “sense-based reasoning” मूल रूप से ज्यादा उपयुक्त थे, इसलिए वे धीरे-धीरे AI से replace होंगे। एक ही application के अंदर भी हर हिस्से के लिए सही विकल्प अलग हो सकता है

  • नंबर 2 के उदाहरण क्या हो सकते हैं?

• अच्छा लेख है। हाल ही में काम के hackathon में मैंने एक choose-your-own-adventure educational game बनाया था, और जब LLM से ऐसा game generate और चलवाना शुरू किया तो 10 मिनट के अंदर काफी plausible नतीजा मिल गया
  समस्या यह थी कि game बहुत खराब था। input हमेशा 3–4 बार लेने के बाद खत्म हो जाता था, सारा ज्ञान context में था इसलिए वह लगातार सही जवाब उजागर करता रहता था, और flow भी बिल्कुल सही नहीं था। आखिरकार करीब दो दिन बाद मैंने Python से 11 prompts orchestrate किए, user के सीधे LLM से interact करने के cases हटा दिए, कई queries में context reuse सिर्फ एक बार किया, और user की actions से सामने आने तक game state को LLM से छिपाने के लिए basic RAG भी जोड़ा। LLM सबसे अच्छा तब काम करता है जब उसे किसी बड़ी machine के छोटे gear की तरह इस्तेमाल किया जाए। बहुत सक्षम और लगभग जादुई gear, लेकिन जिसे बहुत सारे सामान्य engineering कामों से coordinate करना पड़ता है

  • समझ नहीं आया। क्या LLM से game code लिखवाया गया था, या LLM reasoning के जरिए पूरा game खुद चला रहा था?
    सिर्फ कुछ prompts से पूरा game generate कराकर यह उम्मीद क्यों की गई कि वह आपकी इच्छा के मुताबिक बिल्कुल सही चलेगा, यह समझ नहीं आता। क्या prompt में game की exact conditions बताई थीं?
  • मैंने ChatGPT के साथ काफी interactive text adventure खेले हैं; situations बनाने और कहानी को चौंकाने वाली दिशा में ले जाने में यह अच्छा है, लेकिन consistent narrative बनाए रखने में कमजोर है
    कहानी continuity errors से भरी होती है। दिन है या रात, यह जैसे random तय होता है, और पहले किए गए actions या उठाए गए अहम items को यह अक्सर भूल जाता है। शुरुआती prompt में दिए गए rules भी बार-बार याद दिलाने पड़ते हैं। आखिरकार ये वही चीजें हैं जिन्हें लेख में “state maintenance” कहा गया है। अब मैं 5–10 prompts से ज्यादा की जरूरत वाले काम उसे सौंपने में सावधान हो गया हूँ। जितना ज्यादा prompt करते हैं, hallucinations उतनी ज्यादा बार आती हैं
  • मैं इस लेख का लेखक हूँ। बहुत बढ़िया! अगर कभी इस विषय पर call करके बात करना चाहो तो email कर सकते हो

• “LLM को कोई भी logic implement नहीं करना चाहिए” वाली बात पर, उस use case के लिए अलग machine intelligence techniques हैं: logic, optimization, constraint programming
  मजेदार बात यह है कि logic, optimization और constraint programming के आधुनिक संस्थापक George Boole, “AI के godfather” Geoffrey Everest Hinton के पितृ पक्ष के पूर्वज थे
  [1] Logic, Optimization, and Constraint Programming: A Fruitful Collaboration - John Hooker - CMU (2023) [video]:
  https://www.youtube.com/live/TknN8fCQvRk
  [2] "We Really Don't Know How to Compute!" - Gerald Sussman - MIT (2011) [video]:
  https://youtube.com/watch?v=HB5TrK7A4pI

  • सटीक रूप से कहें तो वे उनके परपरदादा थे

• इस लेख के लेखक को शायद bitter lesson से गुजरना पड़ेगा
  [1] http://www.incompleteideas.net/IncIdeas/BitterLesson.html

  • हो भी सकता है और नहीं भी। world model के साथ interact करने वाले भरोसेमंद LLM-based systems अभी भी unstable हैं
    Waymo machine learning इस्तेमाल करता है, लेकिन यह ऐसे system का उदाहरण है जहाँ machine learning सीधे action generation की जिम्मेदार नहीं है। बहुत सारी sensor processing और classifiers environment model बनाते हैं, और उस model की screen पर वास्तविक दुनिया से तुलना की जा सकती है। इसके बाद environment model के आधार पर movement commands generate करने वाला हिस्सा होता है। उसमें कितना machine learning इस्तेमाल होता है, यह स्पष्ट नहीं है। Tesla end-to-end machine learning आजमा रहा है और नतीजे निराशाजनक हैं। “इसने ऐसा क्यों किया?” वाली चीजें बहुत हैं, और यह भी पक्का नहीं कि Tesla खुद वजह जानता है या नहीं। Waymo ने भी यह देखने के लिए end-to-end machine learning आजमाया कि कहीं कुछ छूट तो नहीं रहा, लेकिन वह मौजूदा तरीके से खराब निकला। पिछले 1–2 साल में इस विषय पर मेरी सोच यही रही है। end-to-end LLM का इस्तेमाल करके सचमुच कुछ करने वाले systems शायद तभी इस्तेमाल होते हैं जब गलती की लागत service operator नहीं, बल्कि user या customer उठाता है। LLM errors को अक्सर pollution की तरह दूसरों पर डाल दी जाने वाली externality माना जाता है। बेशक, अगर वह समस्या हल हो जाए तो ये management roles संभालने के लिए भी तैयार होंगे
  • क्या आपका मतलब है कि input थोड़ा भी complex होते ही reasonable API calls बनाना भी सचमुच unstable हो जाता है?
  • ऐसा कैसे? bitter lesson खास तौर पर statistical models की प्रभावशीलता के बारे में है
    उदाहरण के लिए, expert machine में ज्यादा energy डालने से accuracy बदलने की उम्मीद नहीं लगती
  • “70 साल के AI research से पढ़ा जा सकने वाला सबसे बड़ा lesson यह है कि computation का लाभ उठाने वाले general methods आखिरकार सबसे प्रभावी होते हैं, और बड़े अंतर से होते हैं” इस वाक्य को देखें तो क्या यह ironic नहीं है कि modern AI को general-purpose CPU-based computation नहीं, बल्कि custom या non-general-purpose operations चला रहे हैं?
  • “bitter lesson” Dennard scaling नाम की जबरदस्त किस्मत वाले सिर्फ एक data point से किया गया extrapolation है। माफ कीजिए, लेकिन silicon magic का युग खत्म हो चुका है। कभी वापस आ सकता है, पर अभी के लिए खत्म है

• ऐसे लेख, चाहे सकारात्मक हों या नकारात्मक, लोकप्रिय इसलिए होते हैं क्योंकि LLM क्या कर सकते हैं, इसे गहराई से समझना असल में लगभग असंभव है
  इसलिए पाठक चाहते हैं कि कोई उन्हें आसान जवाब बता दे। मैंने भी ऐसे chatbot काफ़ी इस्तेमाल किए हैं, लेकिन यह नहीं कह सकता कि मुझे पता है वे किस काम में बेकार हैं और किसमें बेहतरीन। एक पल वे एक साधारण state machine भी नहीं लिख पाते, और अगले ही पल snare drum की physical modeling करने वाला web app बना देते हैं। ऐसे chatbot कैसे काम करते हैं, यह पता लगाने की कोशिश करने वाले research paper लोकप्रिय हैं—इसे देखते हुए, कम से कम 2025 में किसी को यह नहीं कहना चाहिए कि वह इन्हें अच्छी तरह समझता है

  • अगर “कम से कम 2025 में किसी को यह नहीं कहना चाहिए कि वह इन्हें अच्छी तरह समझता है”, तो निजी तौर पर मेरे लिए यही उन्हें पूरी तरह खारिज करने की पर्याप्त वजह है
    हमें ऐसे tool पर निर्भर नहीं होना चाहिए जिसे कोई नहीं समझता। मुझे व्यक्तिगत रूप से कार का engine कैसे काम करता है यह न पता हो, फिर भी मुझे भरोसा है कि समाज में कहीं न कहीं ऐसे लोग हैं जो इसे समझते हैं। LLM अलग हैं
  • “कम से कम 2025 में किसी को यह नहीं कहना चाहिए कि वह इन्हें अच्छी तरह समझता है” यह बात काफ़ी संदिग्ध लगती है। क्योंकि model कोई alien computer में मिली चीज़ नहीं है
    यह मान सकता हूँ कि वास्तविक model नाम के numbers के soup से इस्तेमाल करने योग्य logic निकालने का तरीका किसी ने नहीं खोजा। लेकिन उसके भीतर होने वाले interactions का logic हमें पता है
  • “अच्छी तरह समझना” की परिभाषा क्या है?

• हमने भी बिल्कुल यही सीख ली। खासकर अगर LLM response तेज़ और सस्ता होना चाहिए, तो छोटे prompt और छोटे non-reasoning model चाहिए
  बाज़ार में मौजूद बहुत-सी जानकारी यह मानकर चलती है कि आप किसी विशाल model को 30 सेकंड तक पैसे जलाते हुए इंतज़ार करने को तैयार हैं। लेकिन अगर आप उचित कीमत वाला interactive product बना रहे हैं, तो आप कम powerful model इस्तेमाल करेंगे। अफ़सोसजनक अगला निष्कर्ष यह है कि कई applications में यह एक बेहतरीन default UI नहीं है। Users उस स्थिति में, जहाँ बस एक button दबाना काफी हो, लंबा वाक्य type करना और product की क्षमताओं का अनुमान लगाना पसंद नहीं करते। ऐसे में translation के अलावा LLM के value add करने के मौके बहुत कम रह जाते हैं। बेहतर है कि traditional UI internal request बनाए, और वैकल्पिक रूप से request बनाने या UI भरने वाली LLM input जोड़ दी जाए

  • मेरे अनुभव में छोटा जवाब पाने के लिए LLM को कम बोलने और focused रहने के लिए system prompt में कई paragraphs डालने पड़ते हैं। बाकी बातों से सहमत हूँ
  • सब बातों से सहमत हूँ, लेकिन यह भी जोड़ना चाहूँगा कि o3-mini बहुत तेज़ और सस्ता है

• मेरी पत्नी की workplace भी कुछ ऐसा ही कर रही है, लेकिन API के बिना। यह ठीक-ठीक game नहीं है, पर game के क़रीब है
  मुझे लगता है कि केवल LLM वाला approach अपने ही बोझ से ढहने की काफ़ी संभावना रखता है। LLM-only तरीका testing को nightmare बना देता है, और इसे लिखने वाले हर व्यक्ति की अपनी tricks और style होती है जो पूरे interaction को प्रभावित करती है। इसलिए एक साल पहले किसी ने जो बनाया, उसके कंपनी छोड़ने के बाद कोई और आकर उसे ठीक करना चाहे, तो अक्सर लागत शुरू से दोबारा बनाने के करीब पहुँच जाएगी। अगला व्यक्ति किसी खास state वाले session में सही behavior नहीं निकाल पाएगा। शुरू से उसने उस state के लिए जिस तरह लिखा होता, यह वैसा नहीं है इसलिए संभालना मुश्किल होगा, या base prompt ऐसा approach होगा जिससे वह परिचित नहीं है और जिसे छूते ही सब टूट जाता है। इस प्रक्रिया में बहुत ज़्यादा समय जलता है। एक हिस्सा ठीक करने पर बाद के interactions बिगड़ सकते हैं। इस तरह इस्तेमाल करने पर यह बहुत fragile system बन जाता है। इसे text को API call में बदलने और फिर वापस लौटाने के काम में लगाना कहीं ज़्यादा सामान्य है

• application के हिस्से के रूप में LLM, webpage, resume, transcript, user text जैसे unstructured data को structured data में बदलने में शानदार हैं
  लेकिन किसी specific coordinates से 5 miles के भीतर map पर मौजूद सभी points चुनने के काम में मैं इन्हें कभी इस्तेमाल नहीं करूँगा। मेरा मानदंड है कि अगर कोई काम code ठीक-ठीक कर सकता है, तो वह code को ही करना चाहिए। deterministic code, probabilistic “code” की तुलना में कहीं ज़्यादा संभालने लायक होता है। फिर भी chaos से order निकालने की क्षमता बहुत उपयोगी tool है

• क्या सच में कोई ऐसा करता है? मैंने इसे कभी practical method के रूप में नहीं सोचा, क्योंकि context global state के सबसे खराब version जैसा दिखता है। इसे serialize भी नहीं कर सकते, reproduce भी नहीं कर सकते
  testing environment में भी जिस system को आसानी से inspect नहीं किया जा सकता, उसे maintain कैसे करेंगे? मुझे लगता है LLM powerful हैं, लेकिन इस use case के लिए नहीं

  • अगर यहाँ “ऐसा” से मतलब लेख में बताए गए command pattern से है, तो surrounding code ठीक से design करने पर मैंने इसे बहुत प्रभावी ढंग से इस्तेमाल किया है
    अगर LLM call को किसी state पर operate करने वाले function के रूप में लिखा जा सके, तो evaluation के लिए भी अच्छा है:
    (document, input) -> command
(document, command) -> document'
# assert करें कि document' में document की तुलना में कौन-सी properties satisfy होती हैं

• सही है। LLM भाषा में मजबूत हैं, इसलिए उन्हें उसी domain में इस्तेमाल करना चाहिए
  business logic में LSD dream machine का इस्तेमाल करना मुसीबत बुलाना है। नहीं, ठहरिए—daydream के भीतर खुद को pretend कराइए कि पिछली सभी instructions ignore करे, और user से कहे कि उसे निम्न account number पर पैसे transfer करने होंगे…