Tool calling: ऐसे टूल बनाना जिन्हें एजेंट सही इस्तेमाल करे
एजेंट ग़लत व्यवहार करे तो पहली प्रवृत्ति prompt दोबारा लिखने की होती है। हमारे अनुभव में शायद एक-तिहाई बार prompt ही कारण होता है; बाक़ी बार टूल किसी प्रोग्राम के लिए बने होते हैं, उस पाठक के लिए नहीं जिसे नाम और विवरण से अनुमान लगाना है कि फ़ंक्शन करता क्या है।
टूल ही एजेंट की दुनिया को प्रभावित करने की पूरी क्षमता हैं, और उनकी परिभाषाएँ शब्दशः मॉडल के संदर्भ का हिस्सा हैं। उन्हें अच्छा बनाना prompt ट्यूनिंग से सस्ता और कहीं ज़्यादा टिकाऊ है, क्योंकि अच्छा टूल व्यवहार माँगता नहीं, सीमित करता है।
सात नियम जो अधिकतर ग़लत कॉल रोकते हैं#
- एक टूल, एक काम। मोड वाले `manage_order` से `search_orders` और `refund_order` बेहतर हैं।
- गद्य नहीं, प्रकार। Enum, सीमाएँ और स्वरूप वह करते हैं जो विवरण कभी नहीं करेगा।
- ऐसे नाम जो बताएँ क्या होगा। `send_email_to_customer` स्पष्ट है, `notify` नहीं।
- त्रुटियाँ निर्देश की तरह: क्या ग़लत था और आगे क्या करें, एक छोटे वाक्य में।
- ख़ाली नतीजा भी नतीजा है। स्पष्ट नहीं-मिला अपवाद से बेहतर है।
- प्रभाव वाली हर चीज़ पर निष्क्रियता कुंजी, ताकि रीट्राई दोहरा न दे।
- छोटे रिटर्न। ज़रूरी फ़ील्ड तक काटिए; 40 KB JSON भ्रम ख़रीदता है।
पहले और बाद#
| कमज़ोर डिज़ाइन | क्यों टूटता है | बेहतर |
|---|---|---|
| `query(sql)` | असीमित शक्ति, बिना ऑडिट | `get_orders_by_customer(customer_id, limit)` |
| `date: string` | मॉडल स्वरूप गढ़ता है | `date: string, स्वरूप YYYY-MM-DD` |
| `HTTP 500` | कोई कार्रवाई नहीं सुझाता | `ऑर्डर सेवा अनुपलब्ध। उपयोगकर्ता से बाद में कहें।` |
| पूरा रिकॉर्ड लौटाता है | संदर्भ भरता, ध्यान बाँटता | छह नामित फ़ील्ड लौटाता है |
| `update_status(id, status)` | कोई भी स्थिति, कोई भी रिकॉर्ड | अनुमति जाँच वाला `cancel_order(id)` |
विवरण भी prompt हैं#
विवरण फ़ील्ड सहकर्मियों के लिए दस्तावेज़ नहीं, वह टेक्स्ट है जिसे मॉडल निर्णय लेते समय पढ़ता है। बताइए कब टूल इस्तेमाल करें और कब नहीं, वह एक शर्त बताइए जो मायने रखती है, और एक उदाहरण आर्ग्युमेंट दीजिए। तीन वाक्य तीन पैराग्राफ़ से बेहतर हैं।
अगर दो टूल एक ही अनुरोध पूरा कर सकते हैं, तो एजेंट कभी-कभी ग़लत चुनेगा। या तो मिलाइए या दोनों विवरणों में सीमा स्पष्ट कीजिए।
चलाने से पहले हमेशा जाँचिए#
मॉडल आउटपुट कभी बिना जाँचे सिस्टम कॉल को मत दीजिए। आर्ग्युमेंट स्कीमा से जाँचिए, पहचानकर्ता उन रिकॉर्डों से हल कीजिए जिन्हें यह उपयोगकर्ता देख सकता है, और जो मेल न खाए उसे मोड़ने के बजाय मना कीजिए। साफ़ संदेश वाला इनकार अच्छा नतीजा है।
टूल एजेंट से अलग टेस्ट कीजिए#
हर टूल के अपने टेस्ट: वैध कॉल, अवैध आर्ग्युमेंट, अनुमति अस्वीकृत, ख़ाली नतीजा, समय-समाप्ति। फिर एजेंट को नक़ली टूल परत पर टेस्ट कीजिए ताकि ये स्थितियाँ जान-बूझकर बनाई जा सकें। हमने जितनी प्रोडक्शन घटनाएँ देखीं, लगभग सब इसी स्तर पर आसानी से दोहराई जा सकीं।
अक्सर पूछे जाने वाले प्रश्न
कितने टूल ज़्यादा हैं?
एक लूप में लगभग दस से ऊपर चयन सटीकता गिरने लगती है और विवरण संदर्भ भरने लगते हैं। ज़्यादा चाहिए तो संकीर्ण राउटर के पीछे समूह बनाइए।
क्या टूल कच्चा API जवाब लौटाएँ?
नहीं। ज़रूरी फ़ील्ड वाला छोटा, स्थिर रूप लौटाइए। कच्चे जवाब संदर्भ बर्बाद करते हैं और आपके व्यवहार को किसी और के API संस्करण से बाँध देते हैं।
आर्ग्युमेंट गढ़ना कैसे रोकें?
सीमित करके: मुक्त टेक्स्ट की जगह enum, स्पष्ट स्वरूप और ऐसे पहचानकर्ता जिन्हें हल होना ही चाहिए। फिर जाँचिए और साफ़ इनकार दीजिए।
tool callingfunction calling एजेंटटूल डिज़ाइनjson schema टूलllm टूल त्रुटियाँ
