← 返回列表

AI साक्षात्कार प्रश्न 2: बड़े भाषा मॉडल (LLM) द्वारा टूल कॉलिंग की विश्वसनीयता कैसे सुनिश्चित करें

AI साक्षात्कार प्रश्न 2: बड़े भाषा मॉडल (LLM) द्वारा टूल कॉलिंग की विश्वसनीयता कैसे सुनिश्चित करें

यह सुनिश्चित करना कि बड़ा भाषा मॉडल (LLM) टूल कॉलिंग के दौरान विश्वसनीय और नियंत्रित रूप से काम करे, न कि केवल प्रॉम्प्ट पर निर्भर रहे। इसके लिए एक बहु-स्तरीय बाधा ढांचा व्यवस्थित रूप से प्रस्तुत किया गया है।

मौसम पूछने के उदाहरण में, टूल कॉलिंग में मॉडल के तीन सामान्य "मनगढ़ंत" व्यवहार:
1. टूल को कॉल न करना और सीधे गलत उत्तर देना
2. टूल को कॉल करते समय गलत प्रारूप में पैरामीटर भेजना (जैसे, टूल "परसों" का समर्थन नहीं करता, फिर भी पैरामीटर date="परसों" भेजना)।
3. अपनी ओर से पैरामीटर प्रारूप बदलना (जैसे, "परसों" को स्वेच्छा से विशिष्ट तिथि में बदलना), भले ही टूल को इसकी आवश्यकता न हो।

समस्या की जड़ यह है कि मॉडल का आउटपुट मूलतः संभाव्य होता है, और प्रॉम्प्ट केवल संभाव्यता वितरण पर एक "नरम बाधा" लगाता है, न कि मॉडल को सख्ती से पालन करने के लिए मजबूर करने वाला तंत्र। जटिल परिदृश्यों में, यह "नरम बाधा" आसानी से विफल हो जाती है।

इस समस्या को हल करने के लिए, एक बहु-स्तरीय इंजीनियरिंग समाधान की आवश्यकता है:

  1. पहला स्तर: प्रॉम्प्ट को अनुकूलित करना (नरम बाधा)

    • यह बाधा प्रणाली का प्रारंभिक बिंदु है, लेकिन अंतिम नहीं।
    • प्रॉम्प्ट को एक "संचालन अनुबंध" के रूप में मानें, जिसमें टूल के उपयोग, प्रत्येक पैरामीटर के प्रकार, सीमाएँ स्पष्ट रूप से बताई जाएँ, और अमान्य मानों के उदाहरण दिए जाएँ।
    • Few-shot उदाहरण शामिल करें, जो "सही इनपुट → सही कॉल" के नमूने दिखाकर संदर्भ सीखने के माध्यम से मॉडल के व्यवहार पैटर्न को स्थिर करें।
  2. दूसरा स्तर: JSON Schema लागू करना (कठोर बाधा)

    • यह "समझाने" से "बाड़ लगाने" की ओर एक महत्वपूर्ण कदम है।
    • प्राकृतिक भाषा में पैरामीटर विवरण को मशीन-पठनीय, सत्यापन योग्य संरचित परिभाषा (JSON Schema) से बदलें। यह फ़ील्ड प्रकार, अनिवार्यता, एनुम मानों की सीमा को सख्ती से परिभाषित कर सकता है, और additionalProperties: false सेट करके मॉडल को किसी भी अपरिभाषित फ़ील्ड को आउटपुट करने से रोक सकता है।
    • मुख्यधारा के API प्लेटफ़ॉर्म मॉडल डिकोडिंग चरण में ही इस प्रकार के संरचित आउटपुट बाधा का समर्थन करते हैं, जो जनरेटिव स्रोत पर ही प्रारूप उल्लंघन से बचाता है।
  3. तीसरा स्तर: सत्यापन-सुधार-पुनर्प्रयास चक्र स्थापित करना (निष्पादन सुरक्षा)

    • Schema होने के बावजूद, मॉडल आउटपुट प्राप्त करने के बाद वाक्यविन्यास और Schema सत्यापन आवश्यक है।
    • सत्यापन विफल होने पर, स्वचालित सफाई और पुनर्प्रयास तंत्र (सीमित प्रयासों के साथ) डिज़ाइन करें, त्रुटि जानकारी मॉडल को वापस भेजकर आउटपुट सुधारें। अधिकतम प्रयासों के बाद, डिग्रेडेशन या मानवीय हस्तक्षेप योजना होनी चाहिए।
  4. आर्किटेक्चर स्तर: जिम्मेदारी का पृथक्करण

    • निर्णय और निष्पादन को अलग करके तीन-स्तरीय आर्किटेक्चर बनाएँ:
      • मॉडल स्तर: केवल निर्णय लेने के लिए जिम्मेदार (किस टूल को कॉल करना है, कौन से पैरामीटर उत्पन्न करने हैं)।
      • फ्रेमवर्क स्तर: निष्पादन ढांचे के लिए जिम्मेदार, जिसमें Schema सत्यापन, टूल कॉलिंग, पुनर्प्रयास प्रबंधन और परिणाम एकीकरण शामिल है। यह सुनिश्चित करता है कि मॉडल त्रुटियाँ सीधे टूल सुरक्षा को प्रभावित न करें, और टूल बदलने पर बार-बार प्रॉम्प्ट समायोजन की आवश्यकता न हो।
      • टूल स्तर: विशिष्ट व्यावसायिक क्षमता का कार्यान्वयन।
    • LangChain, LlamaIndex जैसे फ्रेमवर्क इसी प्रकार का कार्य कर रहे हैं।

वर्तमान समाधान की सीमाएँ: यह पैरामीटर प्रारूप की समस्या को अच्छी तरह से संभाल सकता है, लेकिन पैरामीटर अर्थ (जैसे "शंघाई" और "हु" की समानता) का सत्यापन अभी भी अपर्याप्त है। यह भविष्य की इंजीनियरिंग चुनौती होगी।

मुख्य निष्कर्ष: LLM को विश्वसनीय रूप से टूल कॉल करने देना मूलतः एक सॉफ्टवेयर इंजीनियरिंग समस्या है, जिसके लिए नरम बाधा, कठोर बाधा, निष्पादन सुरक्षा और आर्किटेक्चर डिज़ाइन से युक्त एक व्यवस्थित इंजीनियरिंग योजना की आवश्यकता है, न कि केवल प्रॉम्प्ट अनुकूलन पर निर्भर रहना।

评论

暂无已展示的评论。

发表评论(匿名)