بڑے پیمانے پر پروڈکشن RAG: روزانہ 10,000 سے زائد لسٹنگز سے حاصل کردہ اسباق
میں نے ایک جاب بورڈ کے لیے RAG پائپ لائن بنائی۔ یہ اسٹیجنگ (staging) میں تو ٹھیک کام کر رہی تھی لیکن اصل لوڈ کے دوران اسے مشکلات کا سامنا کرنا پڑا۔ روزانہ ہزاروں لسٹنگز پر کارروائی کرنے کے لیے صرف ایک اچھے ویکٹر اسٹور (vector store) سے زیادہ کی ضرورت ہوتی ہے۔ آپ کو یہ سمجھنا ہوگا کہ سسٹم کہاں ناکام ہو رہا ہے۔
یہاں چنکنگ (chunking)، ایمبیڈنگز (embeddings)، اخراجات اور آبزرویبلٹی (observability) کے بارے میں میرے تجربات اور اسباق درج ہیں۔
1. اپنی چنکنگ حکمت عملی کا اندازہ نہ لگائیں
زیادہ تر ٹیوٹوریلز چنکنگ کو ایک سادہ سی سیٹنگ کے طور پر دیکھتے ہیں۔ پروڈکشن میں، آپ کی حکمت عملی درستگی اور اخراجات کا تعین کرتی ہے۔
میں نے جاب لسٹنگز کے لیے تین طریقوں کا تجربہ کیا:
- فکسڈ سائز چنکس (Fixed-size chunks): یہ ناکام رہے۔ انہوں نے "requirements" اور "benefits" جیسے حصوں کو بے ترتیب مقامات پر تقسیم کر دیا۔ اس سے غیر متعلقہ معلومات (noisy retrieval) حاصل ہوتی ہیں۔
- سیمنٹک چنکنگ (Semantic chunking): یہ بہتر تھی لیکن غیر مستقل تھی۔ کچھ چنکس بہت طویل تھے اور کچھ بہت مختصر۔
- اوورلیپ کے ساتھ ریکرسو کیریکٹر سپلٹنگ (Recursive character splitting with overlap): یہ سب سے زیادہ کامیاب رہی۔ میں نے نئی لائنوں اور جملوں کی بنیاد پر تقسیم کیا۔ میں نے 50 ٹوکن کے اوورلیپ کے ساتھ 400 ٹوکن کا سائز استعمال کیا۔ اس سے یہ یقینی بنتا ہے کہ دو چنکس میں پھیلے ہوئے جملے آپس میں جڑے رہیں۔
پرو ٹپ: چنکنگ سے پہلے اپنے ڈیٹا کو نارملائز (normalize) کریں۔ Greenhouse یا Lever جیسے مختلف ذرائع مختلف فارمیٹس فراہم کرتے ہیں۔ پہلے ٹیکسٹ کو صاف کریں تاکہ آپ کا چنکر ایک مستقل ڈھانچہ دیکھ سکے۔
2. ایمبیڈنگز: لاگت بمقابلہ درستگی
میں نے Ollama کے ذریعے Llama 3.1 کا OpenAI text-embedding-3-small کے ساتھ مقابلہ کیا۔
لوکل ماڈل مفت تھا لیکن "equity compensation" جیسے مخصوص اصطلاحات کے ساتھ اسے مشکل پیش آئی۔ اس نے غیر متعلقہ نتائج دیے۔ OpenAI زیادہ مہنگا تھا لیکن درست نتائج فراہم کرتا تھا۔ میں نے OpenAI کا انتخاب کیا کیونکہ خراب ریٹریول (retrieval) کی وجہ سے بعد میں LLM کالز پر زیادہ خرچہ آتا ہے۔
وقت بچانے کے لیے، میں اپنی درخواستوں کو بیچ (batch) میں بھیجتا ہوں۔ میں ایک ہی کال میں 100 تک چنکس بھیجتا ہوں۔ اس سے لیٹنسی (latency) کم ہوتی ہے اور پائپ لائن تیز رہتی ہے۔
3. ویکٹر اسٹور کا توازن (Trade-off)
میں نے پروٹو ٹائپنگ کے لیے Pinecone استعمال کیا کیونکہ اسے سیٹ اپ کرنا تیز ہے۔ تاہم، بڑے پیمانے پر اخراجات بہت زیادہ بڑھ گئے۔
میں نے PostgreSQL کے اندر pgvector پر منتقل ہونے کا فیصلہ کیا۔
- اسے سیٹ اپ کرنے میں زیادہ محنت لگی۔
- اس نے بہت زیادہ رقم بچائی۔
- اس نے ٹرانزیکشنل کنسسٹنسی (transactional consistency) فراہم کی۔
چونکہ ایمبیڈنگز اسی ڈیٹا بیس میں موجود ہیں جہاں جاب ڈیٹا ہے، اس لیے آپ کے پاس معلومات کا ایک ہی مستند ذریعہ (source of truth) ہوتا ہے۔ آپ کو دو مختلف سسٹمز کو سنک (sync) کرنے کی ضرورت نہیں پڑتی۔
4. LLM اخراجات کو کنٹرول کرنا
ہر لسٹنگ کو GPT-4o کے ذریعے اسکور کرنا مہنگا ہے۔ میں نے اخراجات کم کرنے کے لیے تین طریقے استعمال کیے:
- OpenAI Batch API: میں اسکورنگ کے کام رات کے وقت پروسیس کرتا ہوں۔ اس سے بڑی رعایت ملتی ہے۔
- کیشنگ (Caching): میں بار بار آنے والے امیدواروں کے پروفائلز کے نتائج کو کیش (cache) کر لیتا ہوں۔
- ماڈل ٹیئرنگ (Model tiering): میں "Sales Representative" جیسے عام کرداروں کے لیے GPT-4o-mini استعمال کرتا ہوں۔ میں GPT-4o صرف ان مخصوص (niche) کرداروں کے لیے استعمال کرتا ہوں جہاں درستگی انتہائی ضروری ہے۔
5. پہلے آبزرویبلٹی (Observability) بنائیں
میری پائپ لائن ایک بار خاموشی سے ناکام ہو گئی تھی۔ غلط فارمیٹ شدہ ڈیٹا کی وجہ سے خالی چنکس بن گئے، جنہیں سسٹم نے بغیر کسی غلطی (error) کے چھوڑ دیا۔
میں نے اسے ایک کورلیشن آئی ڈی (correlation ID) کے ساتھ اسٹرکچرڈ لاگنگ (structured logging) شامل کر کے ٹھیک کیا۔ اس سے مجھے ایک لسٹنگ کو انجیشن (ingestion) سے لے کر اسکورنگ تک ٹریس کرنے کی اجازت ملی۔ میں آخر کار دیکھ سکا کہ کون سے ڈیٹا ذرائع ناکامیوں کا باعث بن رہے تھے۔
سب سے بڑا سبق: زیادہ تر مسائل گندے ڈیٹا (messy data) سے آتے ہیں، AI سے نہیں۔ پہلے اپنے ڈیٹا کی پائپنگ (data plumbing) کو درست کریں۔
Optional learning community: https://t.me/GyaanSetuAi