یہ خاکہ (ڈایاگرام) اعتماد کی حد (trust boundary) کو واضح کرتا ہے۔ صارف کا ان پٹ ناقابلِ اعتماد ہے کیونکہ کوئی بھی کالر اپنی مرضی کا متن (arbitrary text) ٹائپ کر سکتا ہے، اور ٹولز کے نتائج بھی ناقابلِ اعتماد ہیں کیونکہ کوئی ٹول غیر متوقع مواد فراہم کر سکتا ہے جو پھر واپس ماڈل کو بھیجا جاتا ہے۔
اس عمل کے چکر (loop) کا ایک اہم حفاظتی پہلو یہ ہے کہ ماڈل نہ تو ڈیٹا بیس کو پڑھتا ہے، نہ رقم کی واپسی (refund) جاری کرتا ہے اور نہ ہی پالیسیوں کا نفاذ کرتا ہے۔ ماڈل صرف ایسا متن تیار کرتا ہے جو اگلے ممکنہ اقدامات کی تجویز دیتا ہے، جبکہ ShopEasy ایپلی کیشن کا کوڈ وہ جزو ہے جو درحقیقت اقدامات انجام دیتا ہے اور ٹولز کے ذریعے ڈیٹا واپس لاتا ہے۔
یہ تفریق تبھی واضح رہتی ہے جب ہم تین شناختوں کو الگ الگ رکھیں۔ صارفِ حتمی (end user) وہ گاہک ہے جو کسی آرڈر کے بارے میں پوچھ گچھ کر رہا ہے، اور اس صارف کے اختیارات (permissions) کو محدود ہونا چاہیے کہ وہ کون سے آرڈرز دیکھ سکتا ہے اور کن اقدامات کی درخواست کر سکتا ہے۔ ShopEasy سروس ہمارا بیک اینڈ (backend) ہے، جس کے پاس وسیع تر صلاحیتیں موجود ہیں جیسے کہ ڈیٹا بیس تک رسائی اور request_refund (رقم کی واپسی کی درخواست) چلانے کی اہلیت۔ LLM فراہم کنندہ کی اسناد (credential) سے مراد وہ API کی (API key) یا سروس ٹوکن ہے جسے ShopEasy ماڈل کے اینڈ پوائنٹ کو کال کرنے کے لیے استعمال کرتا ہے، اور یہ اسناد صرف ماڈل کے استعمال کی اجازت دیتی ہیں، نہ کہ گاہک کے اقدامات کی۔ ان شناختوں کو آپس میں خلط ملط کرنے سے ایسی خرابیاں پیدا ہوتی ہیں جن میں بیک اینڈ رقم خرچ کر دیتا ہے، ڈیٹا ظاہر کر دیتا ہے، یا ایسے صارف کی جانب سے اقدامات انجام دیتا ہے جسے ایسا کرنے کا اختیار نہیں ہونا چاہیے۔ اگر کوئی خرابی پیدا ہو جائے، تو کون سا حصہ حقیقی معنوں میں اصولوں کا نفاذ کر سکتا ہے: پرامپٹ ٹیکسٹ (prompt text)، LLM، یا ShopEasy ایپلی کیشن کا کوڈ؟
ShopEasy کا سپورٹ چیٹ بوٹ “میرا آرڈر کہاں ہے؟” جیسے سوال کا جواب lookup_order جیسے بیک اینڈ فنکشن کو کال کر کے دے سکتا ہے، اور پھر اس کے نتیجے کو ایک ایسے مفید جملے میں تبدیل کر سکتا ہے جسے صارف پڑھ سکے۔
اس کورس میں Large Language Model (LLM) کی وضاحت کا ایک سادہ طریقہ یہ ہے کہ LLM ہمارے بھیجے گئے متن (text) کو لیتا ہے اور اس کے بعد آنے والے متن کی پیش گوئی کرتا ہے؛ یہ ایک انتہائی طاقتور ‘آٹو مکمل’ (autocomplete) کی طرح ہے جو پورے پیراگراف تخلیق کر سکتا ہے۔
آرڈر سے متعلق اس ایک سوال میں بھی، ShopEasy کے پاس پہلے سے چند مخصوص ان پٹس (inputs) موجود ہوتے ہیں۔ System prompt وہ نجی ہدایت ہے جو ShopEasy ہر درخواست کے ساتھ بھیجتا ہے، مثال کے طور پر: “آپ ShopEasy سپورٹ ہیں۔ مختصر بات کریں۔ اگر آرڈر نمبر موجود نہ ہو تو اس کا مطالبہ کریں۔” Conversation history (گفتگو کی تاریخچہ) پچھلے پیغامات کا وہ سلسلہ ہے جسے ShopEasy شامل کرتا ہے تاکہ ماڈل کا تسلسل برقرار رہے۔ User input وہ نیا پیغام ہے، جیسے کہ “میرا آرڈر کہاں ہے؟” ‘ٹولز’ (Tools) سرور سائیڈ کے وہ فنکشنز ہیں جنہیں ShopEasy چلا سکتا ہے (جیسے lookup_order اور request_refund)، جب چیٹ بوٹ کو ڈیٹا درکار ہو یا کوئی عمل (action) انجام دینا ہو۔
جب ShopEasy کے پاس یہ تمام اجزاء موجود ہوں، تو ایک درخواست (request) ایک ایسے چکر سے گزرتی ہے جسے دہرایا جا سکتا ہے۔ صارف کا پیغام ShopEasy API تک پہنچتا ہے، اور ایپلی کیشن ‘سسٹم پرامپٹ’، ‘گفتگو کی تاریخچہ’ اور ‘نئے صارف ان پٹ’ کو یکجا کر کے ماڈل کے لیے ایک پرامپٹ تیار کرتی ہے۔ ایپلی کیشن اس پرامپٹ کو LLM فراہم کرنے والے (provider) کو بھیجتی ہے، اور فراہم کنندہ ماڈل کی آؤٹ پٹ واپس بھیجتا ہے جو یا تو براہ راست تحریری جواب ہوتا ہے یا پھر دلائل (arguments) کے ساتھ کسی ٹول کو چلانے کی تجویز (tool call)۔
جب ماڈل کسی ٹول کو چلانے کی تجویز دیتا ہے، تو ShopEasy کا ایپلی کیشن کوڈ فیصلہ کرتا ہے کہ آیا اسے چلایا جائے یا نہیں، اور پھر شپنگ کی صورتحال جاننے کے لیے lookup_order یا ریفنڈ شروع کرنے کے لیے request_refund جیسا مخصوص فنکشن چلاتا ہے۔ اس کے بعد ShopEasy ٹول کے نتیجے کو ایک اور پیغام کے طور پر واپس ماڈل کو بھیجتا ہے تاکہ ماڈل صارف کے لیے حتمی جواب لکھ سکے، اور صرف وہی حتمی جواب صارف تک پہنچتا ہے۔ ایک تفصیل سیکیورٹی اور بعد میں ڈی بگنگ (debugging) کے لیے اہم ہے۔ ماڈل میں کالز کے درمیان کوئی اندرونی میموری (ذخیرہ شدہ معلومات) نہیں ہوتی، اس لیے ShopEasy کو ہر بار گفتگو کی تاریخچہ دوبارہ بھیجنی پڑتی ہے، ورنہ ماڈل ایسے ردعمل دیتا ہے جیسے اس نے صارف کو پہلے کبھی نہ دیکھا ہو۔ آئیے اس عمل کو ایک ‘درخواست کے راستے’ (request-path) والے خاکے میں سمجھتے ہیں۔