میں نے ان 7 غلطیوں کو درست کرنے سے پہلے RAG انفراسٹرکچر پر $500 خرچ کیے۔
میں نے نجی دستاویزات کی تلاش کے لیے ایک RAG پائپ لائن بنائی۔ اس پر کمپیوٹ کے $500 اور ڈی بگنگ (debugging) کے کئی ہفتے لگے۔ نتائج بہت خراب تھے۔ صارفین کو غلط جوابات مل رہے تھے اور کوئریز (queries) سست تھیں۔
میں نے پائپ لائن کا آڈٹ کیا۔ مجھے 7 غلطیاں ملیں۔ انہیں درست کرنے سے سب کچھ بدل گیا۔
1. فکسڈ ٹوکن چنکنگ (Fixed Token Chunking) میں نے دستاویزات کو 512 ٹوکنز کے حساب سے تقسیم کیا۔ اس سے سیاق و سباق (context) تباہ ہو گیا۔ ایک API کی وضاحت جملے کے درمیان میں ہی کٹ جاتی تھی۔ LLM کو صرف ٹکڑے ملتے تھے جس کی وجہ سے وہ فضول جوابات دیتا تھا۔ حل: سیمنٹک چنکنگ (semantic chunking) کا استعمال کریں۔
- پیراگراف یا ہیڈرز جیسی قدرتی حدود کے مطابق تقسیم کریں۔
- پیرنٹ-ڈاکیومنٹ ریٹریول (parent-document retrieval) کا استعمال کریں۔
- تلاش کے لیے چھوٹے چائلڈ چنکس (child chunks) بنائیں۔
- LLM کو مکمل پیرنٹ دستاویز واپس کریں۔
- چنکس کے درمیان 10-20% اوورلیپ (overlap) شامل کریں۔
2. ناقص ہائبرڈ سرچ ویٹس (Bad Hybrid Search Weights) میں نے ویکٹر (vector) اور کی ورڈ (keyword) سرچ کے لیے 50/50 کا تناسب استعمال کیا۔ یہ تکنیکی دستاویزات کے لیے ناکام رہا۔ تکنیکی صارفین کو درست کی ورڈ میچز کی ضرورت ہوتی ہے۔ حل: ڈائنامک ویٹس (dynamic weights) کا استعمال کریں۔
- حقائق پر مبنی کوئریز: 35% ویکٹر، 65% کی ورڈ۔
- سیمنٹک کوئریز: 75% ویکٹر، 25% کی ورڈ۔
- عام کوئریز: 60% ویکٹر، 40% کی ورڈ۔
3. HNSW پیرامیٹرز کی ضرورت سے زیادہ ٹیوننگ
میں نے ef_construction کو زیادہ سے زیادہ (maximum) پر سیٹ کر دیا۔ اس سے میرا سرور کریش ہو گیا۔ اس نے تمام دستیاب RAM استعمال کر لی۔
حل: مناسب پیرامیٹرز کا استعمال کریں۔
- M کو 8 اور 32 کے درمیان سیٹ کریں۔
ef_constructionکو 200 پر سیٹ کریں۔ef_searchکو 50 پر سیٹ کریں۔ میموری کا استعمال 70% کم ہو گیا۔
4. عام ایمبیڈنگ ماڈلز (General Embedding Models) میں نے ویکیپیڈیا پر تربیت یافتہ ماڈل استعمال کیا۔ میری دستاویزات تکنیکی انجینئرنگ رن بکس (runbooks) تھیں۔ ماڈل میرے ڈومین (domain) کو نہیں سمجھ پا رہا تھا۔ حل: تکنیکی یا کوڈ مواد کے لیے فائن ٹیون (fine-tuned) کیے گئے ماڈل کا استعمال کریں۔
5. کوئری ری رائٹنگ (Query Rewriting) کا نہ ہونا صارفین قدرتی سوالات پوچھتے ہیں۔ تکنیکی دستاویزات میں رسمی اصطلاحات استعمال ہوتی ہیں۔ یہ آپس میں میل نہیں کھاتیں۔ حل: کوئریز کو دوبارہ لکھنے کے لیے ایک ہلکا پھلکا (lightweight) LLM مرحلہ شامل کریں۔
- صارف پوچھتا ہے: "why is my build slow"
- سسٹم اسے یوں تبدیل کرتا ہے: "CI pipeline performance optimization"
- اس سے ریکال (recall) میں 40% بہتری آئی۔
6. غیر ضروری نتائج (Redundant Results) ٹاپ-10 چنکس نکالنے سے اکثر ایک ہی پیراگراف تین بار مل جاتا تھا۔ LLM اپنی بات دہرا رہا تھا۔ حل: نتائج میں تنوع (diversity) کو یقینی بنانے کے لیے Maximal Marginal Relevance (MMR) کا استعمال کریں۔
7. غلط چیز کی جانچ کرنا میں نے پوری پائپ لائن کو ایک ساتھ ٹیسٹ کیا۔ مجھے معلوم نہیں تھا کہ مسئلہ ریٹریول (retrieval) میں تھا یا LLM میں۔ حل: ریٹریول کی جانچ (evaluation) کو الگ کریں۔
- ہٹ ریٹ (hit rate) کو ٹریک کریں۔
- Mean Reciprocal Rank (MRR) کو ٹریک کریں۔
- 100 کوئری-دستاویز جوڑوں کا ایک ٹیسٹ سیٹ بنائیں۔
اصلاحات کے بعد کے نتائج:
- جواب کی مطابقت: 45% سے 85%
- لیٹنسی (Latency): 3.2s سے 1.8s
- ماہانہ لاگت: $180 سے $95
سب سے پہلے chunking درست کریں۔ پھر weights، اور پھر embedding quality۔