صفر سے RAG بنانا
میرے پہلے AI ورژن نے مجھے بتایا کہ میں ایک ہائیڈرولک ایکسکیویٹر (hydraulic excavator) بیچتا ہوں۔ میں ایکسکیویٹرز نہیں بیچتا۔ اس نے مکمل اعتماد کے ساتھ ایک فرضی قیمت اور ایک فرضی تفصیل فراہم کی۔
یہ وہ لمحہ تھا جب میں نے صرف پرامپٹس (prompts) پر بھروسہ کرنا چھوڑ دیا۔ میں نے ایک اصول کے ساتھ سسٹم کو دوبارہ بنایا: یا تو یہ کیٹلاگ سے جواب دے گا، یا بالکل جواب نہیں دے گا۔
یہاں بتایا گیا ہے کہ میں نے Postgres اور Python کا استعمال کرتے ہوئے ایک قابل اعتماد RAG (Retrieval-Augmented Generation) سسٹم کیسے بنایا۔
ڈیٹا کی تیاری زیادہ تر ٹیوٹوریلز مشکل حصہ چھوڑ دیتے ہیں: ڈیٹا کی صفائی (cleaning data)۔ میں نے اپنے عمل کو دو مراحل میں تقسیم کیا ہے:
- مرحلہ 1: HTML فائلوں کو ڈسک پر ڈاؤن لوڈ کریں۔ میں میٹا ڈیٹا (metadata) کو ہر فائل کے اوپر ایک کمنٹ کے طور پر محفوظ کرتا ہوں۔ یہ عمل کو idempotent بناتا ہے۔ اگر فائل پہلے سے موجود ہے، تو میں اسے چھوڑ دیتا ہوں۔
- مرحلہ 2: ان فائلوں کو آف لائن پارس (parse) کریں۔ یہ HTML کو ایک صاف ستھرے JSON کیٹلاگ میں تبدیل کر دیتا ہے۔
میں پارسنگ کے بعد فیلڈ کوریج چیک کرتا ہوں۔ اگر وزن یا قیمت جیسی کوئی فیلڈ خالی ہو، تو مجھے فوراً پتہ چل جاتا ہے۔ اصل کام صاف ڈیٹا کے ساتھ ہی ہوتا ہے۔
AI کا حصہ میں ہر پروڈکٹ کو ٹیکسٹ کے ایک بلاک میں تبدیل کرتا ہوں اور bge-m3 ماڈل کا استعمال کرتے ہوئے اسے ایک ویکٹر (vector) میں تبدیل کرتا ہوں۔ میں ان ویکٹرز کو pgvector ایکسٹینشن کا استعمال کرتے ہوئے Postgres میں محفوظ کرتا ہوں۔
میں پروڈکٹس تلاش کرنے کے لیے ہائبرڈ سرچ (hybrid search) کا طریقہ استعمال کرتا ہوں:
- سیمنٹک سرچ (Semantic Search): یہ آپ کے سوال کے معنی سے مماثل پروڈکٹس تلاش کرنے کے لیے ویکٹرز کا استعمال کرتی ہے۔
- اسٹرکچرڈ فلٹرز (Structured Filters): میں "Siemens motors under €2000" جیسی کوئری کو JSON میں تبدیل کرنے کے لیے LLM کا استعمال کرتا ہوں۔ اس سے مجھے برانڈ اور قیمت کے لیے درست فلٹرز کے ساتھ SQL کوئری چلانے کی اجازت ملتی ہے۔
ایک ہی SQL سٹیٹمنٹ فزی سرچ (fuzzy search) اور ہارڈ فلٹرز (hard filters) دونوں کو سنبھالتی ہے۔ یہ سب کچھ ہم آہنگ (in sync) رکھتا ہے۔
گارڈ ریلز ایک اچھے RAG کو معلوم ہونا چاہیے کہ کب خاموش رہنا ہے۔ میں ہالوسینیشن (hallucinations) کو روکنے کے لیے دو تہیں (layers) استعمال کرتا ہوں:
- سیمیلرٹی تھریش ہولڈ (Similarity Threshold): ہر میچ کو ایک اسکور ملتا ہے۔ اگر اسکور مقررہ حد سے کم ہو، تو میں نتائج کو مسترد کر دیتا ہوں۔ اگر کوئی نتیجہ پاس نہ ہو، تو سسٹم LLM کو کال کیے بغیر ہی "not found" کہہ دیتا ہے۔ اگر ماڈل ڈیٹا دیکھ ہی نہ سکے تو وہ ہالوسینیشن نہیں کر سکتا۔
- سخت سسٹم پرامپٹ (Strict System Prompt): میں ماڈل کو کہتا ہوں کہ صرف فراہم کردہ پروڈکٹس سے ہی جواب دے۔ اگر پروڈکٹس غیر متعلقہ ہوں، تو اسے انکار کرنا چاہیے۔
تھریش ہولڈ غلط رویے کو ناممکن بنا دیتا ہے۔ پرامپٹ صرف اچھے رویے کی درخواست کرتا ہے۔ دونوں کا استعمال کریں۔
خلاصہ
- احتیاط سے جمع کریں۔
- دیانتداری سے صفائی کریں۔
- سادگی سے ایمبیڈ کریں۔
- ڈیزائن کے مطابق انکار کریں۔
انکار ہی وہ چیز ہے جو سسٹم کو قابل اعتماد بناتی ہے۔ اعتماد آرکیٹیکچر سے آتا ہے، نہ کہ ماڈل سے اچھے ہونے کی درخواست کرنے سے۔
ماخذ: https://dev.to/utku_catal/building-a-rag-from-scratch-collect-clean-embed-refuse-20ob
اختیاری سیکھنے کی کمیونٹی: https://t.me/GyaanSetuAi