ایک پراعتماد جواب نہ ہونے والے جواب سے زیادہ برا کیوں ہو سکتا ہے

آپ نے اپنا انٹرنل چیٹ بوٹ (internal chatbot) تیار کر لیا ہے۔ آپ اس میں کمپنی کی ہر ایچ آر پالیسی (HR policy)، انجینئرنگ سپیک (engineering spec)، اور آن بورڈنگ دستاویز (onboarding doc) ڈال دیتے ہیں۔ ایک نیا ملازم کلائنٹ ڈنر کے لیے سفری اخراجات کی حد کے بارے میں پوچھتا ہے۔ بوٹ فوراً جواب دیتا ہے۔ یہ خود پر مکمل یقین رکھتا ہے۔ یہ بتاتا ہے کہ حد فی شخص 75 ڈالر ہے۔

اصل پالیسی 50 ڈالر کہتی ہے۔ بوٹ نے یہ جواب خود سے گھڑ لیا ہے۔ اس نے آپ کی فائلیں کبھی کھولی ہی نہیں۔ اس نے محض اندازہ لگایا، جو کہ برسوں پرانے اپنے ٹریننگ ڈیٹا میں موجود پیٹرنز (patterns) کی بنیاد پر تھا۔ نجی دستاویزات کے لیے خام لاج لینگویج ماڈلز (raw large language models) استعمال کرنے کی تلخ حقیقت یہی ہے۔ ان کی آپ کے اندرونی علم تک کوئی رسائی نہیں ہوتی۔ جب وہ حقائق جن کی انہیں ضرورت ہے ان کے ٹریننگ ویٹس (training weights) سے باہر ہوتے ہیں، تو وہ لاعلمی کا اعتراف کرنے کے بجائے خود سے کچھ بنا لیتے ہیں۔ پروڈکشن (production) میں، یہ بات محض دلچسپ نہیں رہتی بلکہ ایک نقصان کا باعث بن جاتی ہے۔

Retrieval-Augmented Generation، یا RAG، بالکل اسی مسئلے کو حل کرنے کے لیے بنایا گیا تھا۔ ماڈل سے سب کچھ یاد رکھنے کے بجائے، آپ اسے چیزیں تلاش کرنے کی اجازت دیتے ہیں۔

اندازے لگانے سے پڑھنے تک

ایک خام LLM کو ایک ایسے ذہین ساتھی کے طور پر سوچیں جس کی یادداشت فوٹوگرافک ہے، لیکن وہ آپ کے کمپنی میں شامل ہونے سے پہلے ہی چھوڑ کر جا چکا ہے۔ وہ فصیح نثر لکھ سکتے ہیں، منطقی پہیلیاں حل کر سکتے ہیں، اور تصورات کو سادہ الفاظ میں سمجھا سکتے ہیں۔ لیکن اگر آپ ان سے گزشتہ سہ ماہی کی API تبدیلیوں کے بارے میں پوچھیں گے، تو وہ محض کچھ ایسا بنا دیں گے جو سننے میں درست لگے۔ ان کے پاس کوئی دوسرا راستہ نہیں ہوتا۔

RAG اس ساتھی کو ایک فائلنگ کیبنٹ (filing cabinet) تک رسائی فراہم کرتا ہے۔ جب کوئی صارف سوال پوچھتا ہے، تو سسٹم سوال کو اندھا دھند ماڈل کے سامنے نہیں پھینکتا۔ یہ پہلے متعلقہ دستاویزات تلاش کرتا ہے، انہیں سیاق و سباق (context) کے طور پر پرامپٹ (prompt) میں شامل کرتا ہے، اور اس کے بعد ہی ماڈل سے پڑھنے اور جواب دینے کو کہتا ہے۔ ماڈل حقائق کو یاد کرنے کے بجائے ان حقائق کو سمجھنے کی طرف منتقل ہو جاتا ہے جو لفظی طور پر اس کے سامنے ہوتے ہیں۔

یہ عمل دو حصوں میں تقسیم ہے: آف لائن بنیاد (offline groundwork) اور آن لائن جواب (online response)۔

مرحلہ 1: تیاری کا مرحلہ (آف لائن)

اس سے بہت پہلے کہ کوئی سوال ٹائپ کرے، آپ کو اپنے بکھرے ہوئے دستاویزات کے مجموعے کو ایک قابلِ تلاش نالج بیس (knowledge base) میں تبدیل کرنا ہوگا۔ یہی بنیاد طے کرتی ہے کہ آپ کا RAG سسٹم کامیاب ہوگا یا خاموشی سے ناکام ہو جائے گا۔

Document loaders آپ کا نقطہ آغاز ہیں۔ یہ کنیکٹرز PDFs، Notion ورک اسپیسز، SharePoint فولڈرز، ویب صفحات اور انٹرنل وکیز (internal wikis) سے خام متن نکالتے ہیں۔ یہ وہ جگہ ہے جہاں اصل چیلنج سامنے آتا ہے۔ ایک لوڈر Word دستاویز سے صاف متن نکال سکتا ہے، لیکن ایک اسکین شدہ PDF پر اٹک سکتا ہے جو حقیقت میں محض ایک تصویر ہے اور اس میں ٹیکسٹ لیئر موجود نہیں ہے۔ لوڈر ایک خالی اسٹرنگ (empty string) واپس کرتا ہے، آپ کا ڈیٹا بیس کچھ بھی محفوظ نہیں کرتا، اور آپ کے صارف کو بعد میں بغیر کسی وارننگ کے "مجھے نہیں معلوم" کا جواب ملتا ہے۔ ہمیشہ تصدیق کریں کہ آپ کے لوڈرز نے اصل میں کیا نکالا ہے۔ پائپ لائن (pipeline) پر بھروسہ کرنے سے پہلے ہر ذریعے سے چند دستاویزات پر سپاٹ چیک (spot checks) کریں۔

اس کے بعد text splitting آتی ہے، جسے چنکنگ (chunking) بھی کہا جاتا ہے۔ آپ اسی ایک ٹکڑے میں اسیاسی صفحات کی سیکیورٹی پالیسی کو پرامپٹ میں نہیں ڈال سکتے؛ آپ سیاق و سباق کی حدود (context limits) سے تجاوز کر جائیں گے اور اصل معلومات شور میں دب جائیں گی۔ اس کے بجائے، آپ دستاویزات کو چنکس (chunks) میں تقسیم کرتے ہیں۔ اصل چال صحیح سائز کا انتخاب کرنا ہے۔ بہت چھوٹے چنکس، جیسے کہ اکیلے جملے، اکثر اہم سیاق و سباق کو چھوڑ دیتے ہیں۔ ایک چنک جو کہتا ہے "تمام درخواستوں کی منظوری مینیجر سے ہونی چاہیے" یہ بتانا بھول جاتا ہے کہ یہ اصول صرف بین الاقوامی سفر پر لاگو ہوتا ہے۔ بہت بڑے چنکس، جیسے کہ مکمل ابواب، ایمبیڈنگ (embedding) کو کمزور کر دیتے ہیں اور ریٹریول (retrieval) کو الجھا دیتے ہیں کیونکہ وہ ایک ساتھ پندرہ مختلف موضوعات کا احاطہ کرتے ہیں۔ عملی طور پر، بہت سی ٹیمیں 300 سے 500 ٹوکنز کے درمیان چنکس سے آغاز کرتی ہیں، اور 50 ٹوکنز کا اوورلیپ (overlap) رکھتی ہیں تاکہ تقسیم کے درمیان آنے والے جملے بگڑ نہ جائیں۔ اپنے مواد کی بنیاد پر اس میں تبدیلی کریں۔ API دستاویزات چھوٹے چنکس کو قبول کر لیتی ہیں۔ قانونی معاہدوں کو اکثر شرطیہ منطق (conditional logic) کو برقرار رکھنے کے لیے بڑے چنکس کی ضرورت ہوتی ہے۔

چنک ہونے کے بعد، ہر حصے کو ایک embedding میں تبدیل کر دیا جاتا ہے۔ اس کا مطلب ہے متن کو ایک ایسے ماڈل سے گزارنا جو نمبروں کی ایک فہرست، یعنی ایک ویکٹر (vector) فراہم کرتا ہے، جو اس چنک کے مفہومی معنی (semantic meaning) کی نمائندگی کرتا ہے۔ اس ریاضیاتی جگہ میں ملتے جلتے خیالات ایک دوسرے کے قریب ہوتے ہیں۔ "401k matching policy" اور "retirement contribution rules" ایک دوسرے کے زیادہ قریب ہوں گے، بجائے اس کے کہ "401k matching policy" اور "office printer setup" قریب ہوں۔ یہ ویکٹرز ایک vector database میں محفوظ کیے جاتے ہیں، جیسے کہ Pinecone، Weaviate، یا Chroma جیسا کوئی اوپن سورس متبادل۔ ویکٹر اسٹور محض ایک کوڑے دان نہیں ہے۔ یہ approximate nearest-neighbor سرچ کے لیے موزوں ایک انڈیکس ہے، جو آپ کو لاکھوں دستاویزات میں سے بھی ملی سیکنڈز میں سب سے زیادہ متعلقہ چنکس تلاش کرنے کی اجازت دیتا ہے۔

مرحلہ 2: لائیو راستہ (آن لائن)

جب آخر کار کوئی صارف پوچھتا ہے، "کلائنٹ ڈنر کے لیے ہماری سفری اخراجات کی واپسی کی پالیسی کیا ہے؟"، تو لائیو پائپ لائن کام کرنا شروع کر دیتی ہے۔

وہ