Tool use: LLM کب طے کرتا ہے کہ فنکشن کال کرنا ہے

تین طریقے

1. 1

   طریقہ اپنے نام سے زیادہ سادہ ہے۔ ایپلیکیشن ماڈل کو بتاتی ہے: 'تمہارے پاس یہ ٹولز ہیں، ان کی شکل یہ ہے۔' ہر ٹول کا تعارف ایک چھوٹے JSON آبجیکٹ میں ہوتا ہے: نام، سادہ زبان میں وضاحت، اور ان پُٹ کے لیے JSON schema۔ صارف سوال کرتا ہے، ماڈل فیصلہ کرتا ہے کہ خود جواب دے یا ٹول کال کرے۔ کال کرے گا تو ساختہ جواب میں ٹول کا نام اور ان پُٹ بھرتا ہے۔ ایپلیکیشن ٹول چلاتی ہے، نتیجہ ماڈل کو دیتی ہے، ماڈل آگے بڑھتا ہے۔ ماڈل دماغ ہے۔ ایپلیکیشن جسم۔ ٹولز ہاتھ۔

2. 2

   ایک پاکستانی سیاق کی ٹول تعریف۔ تصور کریں آپ Claude کو verify_ntn نامی ٹول دیتے ہیں: 'بتاتا ہے کہ دیا گیا NTN FBR کے ساتھ رجسٹرڈ ہے اور آج active taxpayer ہے۔ ان پُٹ: ntn (سٹرنگ، 7 ہندسے)۔ آؤٹ پُٹ: status (active یا inactive)، filer_status (true/false)، last_filing_year (نمبر)۔' وضاحت سب سے اہم چیز ہے۔ ماڈل اسے job description کی طرح پڑھتا ہے۔ مبہم وضاحت پر ماڈل غلط کال کرتا ہے۔ تیز وضاحت پر صحیح۔ ٹول کی وضاحت کو ایک جونیئر ملازم کے معاہدے کی طرح لیں، کیونکہ یہی ہے۔

3. 3

   ماڈل کے اندر کا فیصلہ کوئی جادو نہیں۔ ماڈل کو ہزاروں مثالوں پر تربیت دی گئی ہے جہاں 'NTN 1234567 کا status چیک کریں' جیسا متن verify_ntn ٹول کی کال میں بدلا، 1234567 ان پُٹ کے ساتھ۔ تربیت سے ماڈل پہچاننا سیکھتا ہے کہ کب صارف کا سوال کسی ٹول سے ملتا ہے۔ ماڈل ہمیشہ صحیح نہیں ہوتا۔ دو عام غلطیاں: ٹول کال کرتا ہے جب نہیں کرنا تھا، یا کال کیے بغیر جواب دیتا ہے جب کرنا تھا۔ اچھے system prompts اور اچھی ٹول وضاحتیں ماڈل کو صحیح طرف جھکاتی ہیں۔ Evaluations ماپتے ہیں کتنی بار غلط جھکتا ہے۔

کیوں؟

Claude کے ساتھ آزمائیں

Claude یا ChatGPT کے ساتھ آزمانے کے لیے پرامپٹ: 'پاکستانی برآمدی فرم کے AI اسسٹنٹ کے لیے پانچ ٹولز ڈیزائن کریں۔ ہر ٹول میں نام، وضاحت، ان پُٹ JSON schema، اور ایک اردو انکار کی شق۔ مثالیں: HS code تلاش، letter of credit کا status، Form-E کا مسودہ۔ پھر اپنے ڈیزائن پر تنقید کریں اور بتائیں کون سا ٹول سب سے زیادہ غلط استعمال ہو سکتا ہے۔' تنقیدی نظر سے پڑھیں۔