زیادہ تر RAG ٹیوٹوریلز ڈیمو پر ہی ختم ہو جاتے ہیں۔ آپ ٹوکن کی تعداد کے حساب سے چنکنگ (chunking) کرتے ہیں، سب کچھ ایک ویکٹر ڈیٹا بیس میں ڈال دیتے ہیں، اور کام مکمل سمجھ لیتے ہیں۔ یہ تب تو کام کرتا ہے جب کوئی صارف کسی صاف ستھرے FAQ میں "ریٹرن پالیسی کیا ہے؟" جیسا سوال پوچھے، لیکن یہ تب ناکام ہو جاتا ہے جب کوئی آدھا معاہدہ (contract) پیسٹ کر کے تیسری شق (clause) کے بارے میں پوچھے، یا جب کوئی ڈویلپر آپ کی ڈاکومنٹیشن سرچ میں کوئی پیچیدہ ایرر کوڈ ٹائپ کرے۔

مقررہ ٹوکن ونڈوز (fixed token windows) قانونی معاہدوں کو جملے کے درمیان میں ہی کاٹ دیتی ہیں۔ بڑے چنکس (chunks) API ریفرنسز کو شور سے بھرے پیراگراف کے نیچے دبا دیتے ہیں۔ سب سے بدترین بات یہ ہے کہ سست ریٹریول (retrieval) صارفین کو ماڈل کے جواب تیار کرنے سے پہلے ہی سوال چھوڑنے پر مجبور کر دیتا ہے۔ ہم نے یہ سبق مشکل طریقے سے سیکھا۔ جب ہم نے اپنے ریٹریول لیئر کو محض امید کے بجائے پیمائش (measurement) پر منتقل کیا، تو ہم نے لیٹنسی (latency) میں چالیس فیصد کمی کی اور ریکال (recall) کو پچانوے فیصد تک پہنچا دیا۔ یہاں وہ تمام تبدیلیاں دی گئی ہیں جو ہم نے کیں۔

اسمارٹ چنکنگ (Smart Chunking)

چنک سائز کو ایک جادوئی نمبر سمجھنا چھوڑ دیں۔ 512-ٹوکن ونڈو کسی قانونی دستاویز کے لیے کوئی معنی نہیں رکھتی جہاں ایک ہی شق کئی پیراگراف پر محیط ہو، اور یہ API ڈاکومنٹیشن کے لیے بھی اتنی ہی بے کار ہے جہاں ایک فنکشن سگنیچر (function signature) اور اس کی دو لائنوں کی تفصیل کو ایک ساتھ ہونا چاہیے۔ ہم نے اسٹرکچر کے آگاہ (structure-aware) اسپلٹنگ پر منتقلی کی۔

قانونی متن کے لیے، ریکرسو چنکنگ (recursive chunking) دستاویز کے ڈھانچے (hierarchy) کا احترام کرتی ہے، جس سے شقیں مکمل رہتی ہیں۔ API ڈاکومنٹیشن کے لیے، ہم فنکشن کے آگاہ (function-aware) اسپلٹنگ کا استعمال کرتے ہیں جو سگنیچرز، پیرامیٹرز اور مثالوں کو ایٹمی اکائیوں (atomic units) کے طور پر ایک ساتھ رکھتا ہے۔ سپورٹ ٹکٹس اور بات چیت کے ڈیٹا کو سیمنٹک حدود (semantic boundaries) کی ضرورت ہوتی ہے، یعنی وہاں تقسیم ہونا چاہیے جہاں موضوع بدلے، نہ کہ کسی بے معنی کریکٹر کاؤنٹ پر۔ اس کا نتیجہ یہ نکلتا ہے کہ ہر چنک میں اتنا سیاق و سباق (context) ہوتا ہے کہ وہ مفید ہو، لیکن اتنا زیادہ نہیں کہ وہ اصل معلومات (signal) کو کمزور کر دے۔ آپ کے ایمبیڈنگ ماڈل (embedding model) کے پاس توجہ کا ایک محدود بجٹ ہوتا ہے۔ اسے سمجھداری سے خرچ کریں۔

ہائبرڈ ریٹریول (Hybrid Retrieval)

ویکٹر سرچ تصوراتی طور پر مماثل مواد تلاش کرنے میں بہترین ہے۔ اگر آپ ڈیٹا بیس کی سست کوئریز کے بارے میں پوچھیں گے تو یہ پرفارمنس ٹیوننگ گائیڈز سامنے لے آئے گا۔ لیکن اگر آپ "Error 0x80070057" کے بارے میں پوچھیں گے تو سیمنٹک سرچ غیر متعلقہ علاقوں کی طرف نکل جائے گی کیونکہ ڈینس ایمبیڈنگز (dense embeddings) درست مماثلت (exact matches) کو اچھے طریقے سے نہیں سنبھال پاتیں۔ دوسری طرف، BM25 بالکل درست اسٹرنگز اور نایاب الفاظ کو پکڑ لیتا ہے، لیکن اسے یہ اندازہ نہیں ہوتا کہ "latency" اور "slow response time" کا مطلب ایک ہی ہے۔

ہم ان دونوں کو متوازی (parallel) طور پر چلاتے ہیں اور انہیں Reciprocal Rank Fusion (RRF) کے ذریعے ضم کرتے ہیں۔ RRF سادہ اور مؤثر ہے۔ یہ ہر طریقے سے رینک شدہ فہرستیں لیتا ہے اور دستاویزات کو ان کے مقام کی بنیاد پر اسکور کرتا ہے، جس سے دونوں سسٹمز کے مضبوط امیدواروں کو برابر کا موقع ملتا ہے۔ فیوژن کے بعد، ہم مجموعی نتائج پر ایک کراس انکوڈر ری رینکر (cross-encoder reranker) چلاتے ہیں اور صرف ٹاپ پانچ نتائج واپس کرتے ہیں۔ ری رینکر تقریباً پچاس ملی سیکنڈ کی لیٹنسی بڑھاتا ہے لیکن اس نے ہمارے ریکال کو پندرہ فیصد بہتر بنا دیا۔ یہ توازن (trade-off) جنریشن کی کوالٹی میں کئی گنا فائدہ مند ثابت ہوتا ہے۔

کوئری ایکسپینشن (Query Expansion)

صارفین کوئری کرنے میں بہت کمزور ہوتے ہیں۔ وہ الفاظ کو مختصر کر دیتے ہیں، غلط سپیلنگ لکھتے ہیں، یا تین سوالات کو ایک طویل اور الجھی ہوئی بات میں بھر دیتے ہیں۔ اگر آپ بالکل وہی تلاش کریں گے جو انہوں نے ٹائپ کیا ہے، تو آپ ان دستاویزات کو مس کر دیں گے جن کی انہیں اصل میں ضرورت ہے۔

اب ہم انڈیکس تک پہنچنے سے پہلے ہر کوئری کو تبدیل کرتے ہیں۔ پہلا، ہم مترادفات (synonyms) اور متبادل جملوں کو کور کرنے کے لیے اصل سوال کے کئی نئے ورژن تیار کرتے ہیں۔ دوسرا، ہم پیچیدہ سوالات کو چھوٹے ذیلی سوالات (sub-questions) میں تقسیم کرتے ہیں۔ ایک کوئری جیسے "بین الاقوامی صارفین کے لیے ریفنڈ کیوں ناکام ہو رہا ہے اور میں اسے کیسے ٹھیک کروں؟" دو الگ الگ تلاش بن جاتی ہے: ایک بین الاقوامی ریفنڈ کی ناکامیوں کے بارے میں اور دوسری اصلاحی اقدامات (remediation steps) کے بارے میں۔ صرف کوئری ایکسپینشن نے ہمارے ریکال کو اٹھتر فیصد سے بڑھا کر چورانوے فیصد کر دیا۔ سبق بالکل واضح ہے: صارف کے پہلے ڈرافٹ پر بھروسہ نہ کریں۔ ان کی مدد کریں۔

اندازے لگانا چھوڑیں، تلاش شروع کریں

چنک سائز، اوورلیپ فیصد (overlap percentage)، top-k کٹ آف، اور ری رینکر کی گہرائی (depth) ایسے طریقوں سے ایک دوسرے پر اثر انداز ہوتے ہیں جنہیں دستی طور پر (by hand) ٹیون کرنا ناممکن ہے۔ ہم نے اس بحث میں بہت زیادہ وقت ضائع کیا کہ آیا 256 ٹوکنز 512 سے بہتر ہیں، جبکہ ہم اس اوورلیپ سیٹنگ کو نظر انداز کر رہے تھے جو اصل میں تسلسل (coherence) کو تباہ کر رہی تھی۔

ہم نے وجدان (intuition) کی جگہ بیزیئن آپٹیمائزیشن (Bayesian optimization) کا استعمال کیا۔ گرڈ سرچ (grid search) کے بجائے، جو واضح طور پر خراب حصوں پر کمپیوٹ (compute) ضائع کرتی ہے، بیزیئن طریقے اس بات کا ایک احتمالی ماڈل (probabilistic model) بناتے ہیں کہ کیا کام کرتا ہے اور وہ فعال طور پر اس 'پاریٹو فرنٹیر' (Pareto frontier) کی تلاش کرتے ہیں جو لیٹنسی کو کم سے کم کرتے ہوئے ریکال کو زیادہ سے زیادہ کر دے۔ ہمارے اسٹیک (stack) کے لیے، اس کا مطلب چنک سائز، اوورلیپ اور top-k کا وہ مخصوص مجموعہ تلاش کرنا تھا جس نے ہمارے لیٹنسی بجٹ کو متاثر کیے بغیر ہمیں پچانوے فیصد ریکال فراہم کیا۔ مختلف استعمال کے کیسز اس فرنٹیر پر مختلف مقامات پر پہنچے۔ کسٹمر فیسنگ چیٹ بوٹس نے رفتار کو ترجیح دی۔ اندرونی قانونی تحقیق نے ریکال کو ترجیح دی۔ خودکار آپٹیمائزیشن نے ہمیں کنفیگ فائلوں کی دستی کاپی پیسٹنگ کے بغیر دونوں کی خدمت کرنے کی اجازت دی۔

نتائج

اعداد و شمار صاف صاف کہہ رہے ہیں۔ ہمارا Recall@10 اٹھتر فیصد سے بڑھ کر پچانوے فیصد ہو گیا۔ p95 latency 850 ملی سیکنڈ سے کم ہو کر 320 ملی سیکنڈ رہ گئی۔ اور چونکہ ماڈل کو آخر کار شور (noise) کے بجائے متعلقہ سیاق و سباق (context) مل رہا تھا، اس لیے hallucination کی شرح بارہ فیصد سے کم ہو کر تین فیصد رہ گئی۔ بہتر retrieval نہ صرف جوابات کو تیز بناتا ہے، بلکہ انہیں درست بھی بناتا ہے۔

آگے کیا کرنا ہے

اگر آپ اپنا retrieval layer دوبارہ بنا رہے ہیں، تو یہاں سے آغاز کریں:

  • ٹیکن کاؤنٹ کے بجائے دستاویز کی ساخت کے مطابق chunking کریں۔ اپنی splitting strategy کو اپنے ڈیٹا کی شکل کے مطابق بنائیں۔
  • hybrid retrieval استعمال کریں۔ vector search اور BM25 کو یکجا کریں، Reciprocal Rank Fusion کے ساتھ ضم کریں، اور جنریٹ کرنے سے پہلے rerank کریں۔
  • بہتر کوریج کے لیے queries کو وسعت دیں۔ سرچ شروع ہونے سے پہلے انہیں rephrase اور decompose کریں۔
  • ٹیسٹنگ کے لیے ایک golden dataset تیار کریں۔ آپ اس چیز کو optimize نہیں کر سکتے جسے آپ ناپ نہیں سکتے۔
  • خودکار ٹولز کے ذریعے parameters کو optimize کریں۔ Bayesian search آپ کے اندازوں سے بہتر سیٹنگز تلاش کر لے گا۔

Retrieval کوئی ایسی configuration file نہیں ہے جسے آپ ایک بار سیٹ کر کے بھول جائیں۔ یہ ایک infrastructure ہے، اور infrastructure بھی production code کی طرح ہی سختی اور توجہ کا مستحق ہے: ٹیسٹ، پیمائش، اور مسلسل optimization۔ اگر آپ اس کے ساتھ ایسا ہی سلوک کریں گے، تو آپ کا RAG system محض ایک demo نہیں رہے گا بلکہ ایک product بن جائے گا۔

اختیاری لرننگ کمیونٹی: GyaanSetu AI