زیادہ تر RAG ٹیوٹوریلز نوٹ بک پر ختم ہو جاتے ہیں۔ وہ چند صاف ستھرے PDFs لوڈ کرتے ہیں، ہر ایک ہزار حروف کے بعد متن کو تقسیم کرتے ہیں، ٹکمنٹس (fragments) کو ویکٹر ڈیٹا بیس میں ڈالتے ہیں، اور اسے ایک آرکیٹیکچر قرار دے دیتے ہیں۔ جمعہ کی ایک دوپہر کو، وہ ڈیمو بالکل صحیح چلتا ہے۔ لیکن پروڈکشن میں، وہی پائپ لائن خاموشی سے ایک بوجھ بن جاتی ہے۔
ایک ریٹریول سسٹم (retrieval system) میں اصل رکاوٹ شاذ و نادر ہی ماڈل یا پرامپٹ ہوتی ہے۔ یہ انجیٹشن (ingestion) ہے۔ ایک RAG پائپ لائن صرف وہی چیز ریٹریو (retrieve) کر سکتی ہے جو اسے فراہم کی گئی ہو، اور اگر فراہم کردہ ڈیٹا شور والا (noisy)، پرانا (stale)، یا نامکمل ہو، تو ماڈل پر اعتماد کے ساتھ غلط معلومات فراہم کرے گا۔ جب صارفین شکایت کرتے ہیں کہ بوٹ نے ہالوسینیشن (hallucination) کی ہے، تو غلطی اکثر ڈیٹا پائپ لائن کے بہت پہلے کے مراحل میں ہوتی ہے جس کی کوئی نگرانی نہیں کر رہا ہوتا۔
وائٹ بورڈ کا جال
آرکیٹیکچر ڈایاگرامز انجیٹشن کو "Documents → Vector DB" کے لیبل والے ایک واحد تیر کی طرح دکھاتے ہیں۔ حقیقت اس سے کہیں زیادہ پیچیدہ ہے۔ سورس سسٹم بغیر کسی اطلاع کے تبدیل ہو جاتے ہیں۔ HTML لے آؤٹ کو ری ڈیزائن کیا جاتا ہے۔ URLs عام لینڈنگ پیجز پر ری ڈائریکٹ ہو جاتے ہیں۔ جاوا اسکرپٹ فریم ورکس ابتدائی HTTP رسپانس کے بعد مواد کو تبدیل کر دیتے ہیں۔ انجیٹشن کو ایک بار کے سیٹ اپ کے کام کے طور پر سمجھنا پہلی غلطی ہے۔ یہ ڈیٹا انجینئرنگ کا ایک مسلسل مسئلہ ہے جو کسی بھی ETL پائپ لائن کی طرح سختی کا مستحق ہے۔
RAG کی ناکامی کی اصل وجہ عام طور پر فیڈ (Feed) کا مسئلہ ہوتی ہے
اس کا تصور کریں: ایک صارف آپ کے اندرونی اسسٹنٹ سے موجودہ ریفنڈ پالیسی کے بارے میں پوچھتا ہے۔ ماڈل ویکٹر اسٹور سے ٹاپ چنک (top chunk) نکالتا ہے اور 30 دن کی مدت بتاتا ہے۔ اصل پالیسی گزشتہ سہ ماہی میں بدل کر 60 دن ہو گئی تھی۔ LLM نے غلط جواب خود سے ایجاد نہیں کیا۔ اس نے غلط ان پٹ پر بھروسہ کیا۔ ریٹریول لیئر نے ایک پرانا صفحہ پیش کیا، اور چونکہ ایمبیڈنگ (embedding) سیمنٹک طور پر کافی قریب نظر آئی، اس لیے ماڈل نے اسے حقیقت سمجھ لیا۔
یہ پیٹرن مسلسل دہرایا جاتا ہے۔ ٹیمیں ٹمپریچر (temperature) اور top-k کو ٹھیک کرنے میں گھنٹوں ضائع کر دیتی ہیں جبکہ ان کا کارپس (corpus) نیویگیشن فوٹرز، ڈپلیکیٹ پریس ریلیز، اور ایسے ٹکمنٹس سے بھرا ہوتا ہے جو ٹیبلز کو درمیان سے توڑ دیتے ہیں۔ جنریشن (generation) کو بہتر بنانے سے پہلے، اس بات کا آڈٹ کریں کہ آپ کا سسٹم کیا جاننے کا مجاز ہے۔
سات جال جو انجیٹشن کو تباہ کر دیتے ہیں
1. پہلی بار کا رن (Run) ایک دھوکہ ہے
آپ کے ابتدائی کرال (crawl) پر سبز ٹک کا مطلب تقریباً کچھ بھی نہیں ہے۔ پروڈکشن ڈیٹا زندہ ہوتا ہے۔ ڈاکومنٹیشن پیجز کو ری فیکٹر (refactor) کیا جاتا ہے، بلاگ کے پرمالنکس (permalinks) ٹوٹ جاتے ہیں، اور سائٹ میپس خاموشی سے سیکشنز کو ختم کر دیتے ہیں۔ اگر آپ صرف اس بات کی تصدیق کرتے ہیں کہ پائپ لائن بغیر کسی غلطی کے مکمل ہو گئی ہے، تو آپ اندھیرے میں تیر چلا رہے ہیں۔ آپ کو آؤٹ پٹ کی تصدیق کرنے کی ضرورت ہے۔ چیک کریں کہ مطلوبہ دستاویزات موجود ہیں، ان کا ڈھانچہ اب بھی درست طریقے سے پارس (parse) ہو رہا ہے، اور متن کا کل حجم اس لیے کم نہیں ہوا کیونکہ کسی سورس نے نتائج کو مختلف طریقے سے پیجینیشن (paginate) کرنے کا فیصلہ کیا ہے۔
2. کرالنگ (Crawling) کا مطلب انجیٹشن نہیں ہے
HTML حاصل کرنا آسان حصہ ہے۔ ایک خام کرال (raw crawl) سب کچھ کیپچر کر لیتا ہے: کوکی بینرز، "متعلقہ مضامین" کے سائیڈ بارز، اشتہارات کے بلاکس، اور فوٹر کاپی رائٹ نوٹس۔ اگر آپ اس خام HTML کو سادہ طریقے سے چنک (chunk) کرتے ہیں، تو متن کا ہر ٹکڑا نیویگیشن مینو کے ٹکڑے بھی ساتھ لے آئے گا۔ جب کوئی صارف API ریٹ لمٹس کے بارے میں پوچھتا ہے، تو ریٹریور ایک ایسا چنک سامنے لا سکتا ہے جس کا 40 فیصد حصہ سائیڈ بار لنکس ہو۔ صاف ستھرا ایکسٹریکشن (extraction) بہت ضروری ہے۔ آپ کو اہم مواد کے حصے کی شناخت کرنے، بوائلر پلیٹ (boilerplate) کو ہٹانے، اور ان عناصر کو ہٹانے کی ضرورت ہے جو ہر صفحے پر دہرائے جاتے ہیں۔ ورنہ آپ نالج بیس نہیں بنا رہے، بلکہ آپ ویب سائٹ کے بیرونی ڈھانچے (chrome) کے لیے ایک سرچ انجن بنا رہے ہیں۔
3. چنکنگ (Chunking) معنی کو توڑ دیتی ہے
تقریباً ہر کوئیک اسٹارٹ گائیڈ میں فکسڈ سائز چنکنگ (fixed-size chunking) ڈیفالٹ ہوتی ہے، اور یہ خطرناک ہے۔ اگر آپ کسی دستاویز کو صرف حروف کی تعداد کے لحاظ سے تقسیم کریں گے تو آپ ٹیبلز کو درمیان سے کاٹ دیں گے، کسی نمبر والے طریقہ کار میں مرحلہ 4 اور 5 کو الگ کر دیں گے، اور بلٹ پوائنٹس کو ان کی ہیڈنگز سے جدا کر دیں گے۔ قیمتوں کے ٹیبل کا صرف دوسرا حصہ رکھنے والا چنک سیمنٹک طور پر بیکار ہے۔ سٹرکچر کے مطابق چنکنگ (structure-aware chunking) اصل فارمیٹ کا احترام کرتی ہے۔ ہیڈنگ ہائیرارکی کو پارس کریں۔ جہاں تک ممکن ہو ٹیبلز کو مکمل رکھیں۔ ایک ہی H2 یا H3 کے تحت پیراگراف کی حدود پر تقسیم کریں۔ اگر فہرستیں کافی چھوٹی ہیں تو انہیں ایک ہی چنک کے اندر محفوظ رکھیں۔ مقصد برابر سائز کے بلاکس نہیں ہیں۔ مقصد معنی کے مربوط یونٹس (coherent units of meaning) ہیں۔
4. تازگی (Freshness) کا مسئلہ
کسی انٹرنل ویکی کا اسٹیٹک اسنیپ شاٹ سادہ موڈ ہے۔ لائیو ویب سے مسلسل ڈیٹا حاصل کرنا (ingesting) مشکل ہے۔ آپ کو یہ جاننے کی ضرورت ہے کہ کوئی صفحہ آخری بار کب جمع کیا گیا تھا، کیا اس میں اس وقت سے کوئی تبدیلی آئی ہے، اور وہ معلومات کتنی دیر تک کارآمد رہیں گی۔ پرانا (stale) ڈیٹا کا مطلب ہمیشہ یہ نہیں ہوتا کہ اس پر کوئی پرانی تاریخ درج ہو۔ کبھی کبھی کوئی صفحہ اپنا متن اپ ڈیٹ کر دیتا ہے لیکن URL وہی رہتا ہے، اس لیے مواد کی ہیشنگ (content hashing) کے بغیر آپ کا سسٹم کبھی اس کا پتہ نہیں لگا پائے گا۔ ذریعے کی تبدیلی (volatility) کی بنیاد پر واضح ریفریش رولز بنائیں۔ ایک مالیاتی ڈیٹا فیڈ کو شاید ہر گھنٹے چیک کرنے کی ضرورت ہو۔ کمپنی کے 'About' صفحے کو شاید سہ ماہی چیکنگ کی ضرورت ہو۔ ٹائم اسٹیمپ ریکارڈ کریں اور time-to-live کی حدود مقرر کریں، خاص طور پر اگر آپ کا ڈومین ریگولیٹڈ یا سیفٹی کریٹیکل رہنمائی سے متعلق ہے جہاں پرانی معلومات حقیقی نقصان کا باعث بن سکتی ہیں۔
5. Duplicate Pollution
ویب سائٹس تکرار سے بھری ہوتی ہیں۔ وہی پروڈکٹ ڈسکرپشن کیٹیگری پیج، پروڈکٹ پیج، اور پروموشنل لینڈنگ پیج پر نظر آتی ہے۔ وہی پریس ریلیز /news/, /press/, اور /blog/ کے تحت موجود ہوتی ہے۔ ویکٹر سرچ خود بخود ڈپلیکیٹ ڈیٹا ختم نہیں کرتا۔ اگر آپ کے ڈیٹا بیس میں دس تقریباً ایک جیسے چنکس (chunks) موجود ہوں، تو وہ آپ کی top-k ریٹریول میں متنوع اور متعلقہ نتائج کو پیچھے چھوڑ سکتے ہیں۔ ایمبیڈنگ سے پہلے آپ کو کینونیکل ٹریکنگ یا مواد کی ڈپلیکیشن ختم کرنے کی ضرورت ہے۔ اگر دو چنکس ایک ہی بات کہہ رہے ہیں، تو مستند ذریعہ (authoritative source) رکھیں اور کاپیز کو ختم کر دیں۔ آپ کے ریٹریور کے سلاٹس محدود ہیں۔ انہیں ضائع نہ ہونے دیں۔
6. Missing Metadata
میٹا ڈیٹا کے بغیر ویکٹر ڈیٹا بیس محض ایک ایسا ٹیکسٹ سرچ انجن ہے جس کے پاس سیاق و سباق (context) کی کوئی یادداشت نہیں ہوتی۔ ذہین ریٹریول ان فلٹرنگ اور رینکنگ سگنلز پر منحصر ہے جو خام ایمبیڈنگز (raw embeddings) فراہم نہیں کر سکتیں۔ سورس URL، کیپچر کی تاریخ، دستاویز کی کیٹیگری، اور ورژن نمبر محفوظ کریں۔ اگر آپ API ڈاکومنٹیشن حاصل کر رہے ہیں، تو ورژننگ ضروری ہے۔ اس کے بغیر، ایک کوئری v1 اور v2 کی تفصیلات کو ایک ہی جواب میں ملا سکتی ہے۔ اگر آپ
صرف پائپ لائن ڈیش بورڈز کے ذریعے ڈیٹا انجیشن (ingestion) کی صحت کی پیمائش کرنا بند کریں۔ کامیاب جابز اور صاف ستھرے لاگز ایک صاف ستھرے کورپس (corpus) کی ضمانت نہیں دیتے۔ ڈیٹا بیس کھولیں اور ان اصل چنکس (chunks) کو پڑھیں جو آپ کے صارفین حاصل کریں گے۔ اگر متن کاپی رائٹ نوٹس، بکھرے ہوئے ٹیبلز، اور پرانی پالیسیوں کے صفحات سے بھرا ہوا ہے، تو آپ کا مسئلہ LLM نہیں ہے۔ پہلے فیڈ کو درست کریں۔ باقی سب کچھ کچرے کے اوپر ٹیوننگ کرنے کے سوا کچھ نہیں۔