LLM को निर्णय लेने या business logic चलाने न दें

 (sgnt.ai)
1 पॉइंट द्वारा GN⁺ 2025-04-03 | 1 टिप्पणियां | WhatsApp पर शेयर करें

मुख्य तर्क: LLM से जितनी जल्दी हो सके बाहर निकलें और उसमें ज़्यादा देर न रुकें

  • LLM को decision-making या business logic नहीं सौंपना चाहिए → इसमें accuracy और stability की कमी होती है
  • अधिकांश मामलों में, LLM को सिर्फ user और application API के बीच interface की भूमिका निभानी चाहिए
  • core logic को dedicated system या engine में चलना चाहिए, और LLM को केवल user request को API call में बदलने और result को फिर से natural language में बदलने की भूमिका निभानी चाहिए

ऐसा क्यों?

  • chess bot उदाहरण: user WhatsApp पर "मेरे bishop से knight को मारो" भेजता है → LLM chessboard की state बनाए रखते हुए खुद खेल भी सकता है, लेकिन reliability, performance, maintenance के लिहाज़ से इसमें कई समस्याएँ हैं

  • performance: LLM की chess खेलने की क्षमता प्रभावशाली है, लेकिन फिर भी यह dedicated chess engine (जैसे: Stockfish) की तुलना में धीमा है और इसकी accuracy भी कम है

  • debugging और tuning मुश्किल: उसने ऐसा निर्णय क्यों लिया, यह समझना कठिन होता है, इसलिए उसे इच्छित तरीके से काम करने के लिए ठीक करना आसान नहीं है

  • अन्य समस्याएँ:

    • LLM output का test करना कठिन है
    • math या random number generation में इसका प्रदर्शन कमजोर है
    • version control और auditing कठिन हैं
    • natural language में state बनाए रखने का तरीका नाज़ुक है
    • API pricing, rate limit जैसी समस्याएँ आती हैं
    • security boundary धुंधली हो जाती है

अलग-अलग उदाहरणों से सही role separation

  • game में "मैं player X पर vorpal sword से attack करूँगा" → LLM को बस इसे attack(player=X, weapon="vorpal_sword") के रूप में बदलकर game logic को सौंपना चाहिए
  • negotiation agent → LLM को negotiation का निर्णय नहीं लेना चाहिए; उसे केवल user input को पैकेज करके negotiation engine को देना और result पहुँचाना चाहिए
  • random response generation → चयन LLM को नहीं करना चाहिए; इसे external random function से संभालना चाहिए

LLM किस काम में अच्छा है

  • LLM transformation, interpretation, communication में विशेष रूप से अच्छा है
  • उदाहरण:
    • "orc को तलवार से मारता हूँ" → attack(target="orc", weapon="sword") में बदलना
    • { "error": "insufficient_funds" } → "आपके पास पर्याप्त gold नहीं है" के रूप में स्वाभाविक ढंग से समझाना
    • यह classify कर सकता है कि user input combat command है, inventory check है, या help request
    • यह human concepts (उदा.: blade = sword, smash = attack) को अच्छी तरह समझता है
  • मुख्य बात यह है कि यह complex judgment या state management के लिए नहीं है → यह केवल user intent को system से जोड़ने वाला एक bridge है

भविष्य की दिशा और बने रहने वाले सिद्धांत

  • तकनीक तेज़ी से आगे बढ़ रही है, इसलिए जो आज संभव नहीं है वह जल्द संभव हो सकता है
  • लेकिन वे structural समस्याएँ जिन्हें LLM हल नहीं कर सकता, संभव है कि आगे भी बनी रहें:
    • ऐसा logic जो LLM पर निर्भर नहीं है, उसे समझना आसान होता है, और maintenance व version control भी आसान होते हैं
    • execution cost भी कम होती है
  • भविष्य में भी यही लागू होगा: LLM को interface की भूमिका पर केंद्रित रखना चाहिए, और core logic dedicated systems को सौंपना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2025-04-03
Hacker News राय

  • लॉजिक के दो प्रकार होते हैं

      1. ऐसा लॉजिक जिसे स्वभावतः सही और सख्त होना चाहिए
      1. ऐसा लॉजिक जो कंप्यूटर की प्रकृति के कारण ऐसा बना है

  • पहला प्रकार security, finance, mathematics जैसे क्षेत्रों में आता है

  • दूसरे प्रकार को AI द्वारा बदले जाने की संभावना अधिक है

  • एक ही application के अलग-अलग हिस्से पहले या दूसरे प्रकार के लिए उपयुक्त हो सकते हैं

  • हाल की एक hackathon में एक educational game बनाया गया

    • LLM का उपयोग करके गेम बनाया और चलाया गया, लेकिन गेम का flow अच्छा नहीं था
    • अंततः गेम state को मैनेज करने के लिए काफी Python code और कई prompts का उपयोग किया गया
    • LLM को बड़े system के छोटे component के रूप में उपयोग करना सबसे बेहतर है

  • LLM को लॉजिक implement नहीं करना चाहिए

    • लॉजिक, optimization, constraint programming अलग-अलग techniques हैं
    • आधुनिक तर्कशास्त्र के संस्थापक George Boole थे, और वे Geoffrey Everest Hinton के दादा थे

  • LLM की क्षमताओं को समझना कठिन है

    • पाठक सरल उत्तर चाहते हैं
    • LLM को एक साधारण state machine लिखने में भी कठिनाई हो सकती है
    • research papers लोकप्रिय हो रहे हैं, और 2025 तक भी LLM को पूरी तरह समझने वाला शायद कोई नहीं होगा

  • अगर LLM response तेज़ और सस्ता चाहिए, तो छोटे prompts और छोटे models का उपयोग करना चाहिए

    • बहुत-सी जानकारी इस धारणा पर आधारित है कि बड़े models का उपयोग किया जाएगा
    • पारंपरिक UI बेहतर विकल्प हो सकता है

  • केवल LLM के भरोसे testing करना कठिन है

    • किसी व्यक्ति की शैली interaction को प्रभावित करती है
    • maintenance cost अधिक हो सकती है
    • इसे API calls में बदलना अधिक तर्कसंगत है

  • business logic में LLM का उपयोग जोखिमभरा है

    • यह language processing के लिए उपयुक्त है

  • AI से बनाई गई images का उपयोग करके लेखों का सारांश बनाया जा सकता है