LLM ایک وقت میں متن کی صرف محدود مقدار ہی ”دیکھ“ سکتے ہیں، جسے سیاق ونڈو کہتے ہیں. یہ چھوٹے کاموں کے لیے مؤثر ہے، لیکن جب معلوماتی ذخیرہ ہزاروں صفحات پر پھیلا ہو تو ناکام ہونے لگتا ہے. سیاق ونڈو کافی ہونے کے باوجود، ”بھوسے کے ڈھیر میں سوئی“ والے مسئلے کی وجہ سے کارکردگی پھر بھی کم ہو سکتی ہے.
RAG، یعنی ”بازیافت سے تقویت یافتہ تخلیق“، ایک عام طریقہ بن چکا ہے۔ اس میں آپ معلوماتی ذخیرہ، مثلاً دستاویزات، ویکی، پالیسیاں اور نقلِ گفتگو، برقرار رکھتے ہیں، صارف کے سوال پر معنوی تلاش چلا کر ایمبیڈنگز کی مدد سے موزوں ترین اقتباسات حاصل کرتے ہیں، پھر ان حصوں کو سوال کے ساتھ LLM کو دیتے ہیں. اس سے ماڈل کا سیاق محدود رہتا ہے اور درست طریقے سے کرنے پر جواب کا معیار بہتر اور اختراعی غلطیاں کم ہو سکتی ہیں.
pgai ایک آزاد ماخذ Postgres توسیع اور اس کے معاون اوزار ہیں، جو معتبر آزاد ماخذ ڈیٹابیس PostgreSQL پر ”مصنوعی ذہانت سے بازیافت“ کے عملی سلسلے بنانے میں مدد دیتے ہیں.
بنیادی خیال یہ ہے کہ معیاری RAG سلسلے کا زیادہ حصہ ڈیٹابیس کی سطح پر منتقل کیا جائے، یعنی مواد لینا ← حصے بنانا ← ایمبیڈ کرنا ← ایمبیڈنگز ہم وقت رکھنا، بجائے اس کے کہ ڈیٹابیس کو ایمبیڈنگز کے لیے ”محض ذخیرہ“ سمجھا جائے.
ابتدائی تاثر یہ ہے کہ یہ امید افزا ہے، لیکن RAG سلسلہ ذرا بھی پیچیدہ ہو، خصوصاً حصے بنانے کے طریقوں میں، تو یہ موزوں نہیں رہتا. تاہم ہم اس منصوبے پر گہری نظر رکھیں گے.
RAG بنانے کے کئی طریقے ہیں۔ مختلف طریقوں کی تفصیلی وضاحت کے لیے حسبِ ضرورت RAG حلوں کی عملی مثالیں. پڑھیں۔ معیار اہم ہو تو ڈیزائن کے امکانات حیرت انگیز حد تک وسیع ہو جاتے ہیں، جبکہ عام ”طے شدہ“ طریقہ عموماً یوں ہوتا ہے:
دستاویزات کا ایک مجموعہ لیں.
انہیں حصوں میں تقسیم کریں. اس کے کئی طریقے ہیں، مثلاً پیراگراف یا معنوی گروہ بندی.
ہر حصے کو ایمبیڈنگ میں بدلیں.
ایمبیڈنگز کو سمتی ڈیٹابیس، مثلاً Pinecone یا Milvus، میں یا pgvector کی مدد سے Postgres میں محفوظ کریں.
سوال کے وقت قریب ترین حصے تلاش کریں `اور انہیں LLM کو دیں۔ ایک بار پھر، ایسا کرنے کے بھی کئی طریقے ہیں.
بہت سے نظاموں میں مراحل (1) تا (3) ڈیٹابیس سے باہر اطلاقی رمز یا معلوماتی سلسلے میں انجام پاتے ہیں، جبکہ ڈیٹابیس زیادہ تر ان کاموں کے لیے استعمال ہوتا ہے:
ایمبیڈنگز محفوظ کرنا
ایمبیڈنگز تلاش کرنا
pgai ایک Postgres توسیع ہے، جو آزاد ماخذ ہے اور Timescale نے تیار کی ہے، اور اس تقسیم کو کم کرنے کی کوشش کرتی ہے.
ایمبیڈنگز کو اطلاقیہ کے ذریعے دستی طور پر سنبھالنے کے بجائے، pgai انہیں ڈیٹابیس کی ایک خصوصیت بنا دیتا ہے:
آپ طے کرتے ہیں کہ کس جدول یا کن دستاویزات کو ایمبیڈ کرنا ہے.
آپ ایمبیڈنگ ماڈل اور حصے بنانے کی حکمتِ عملی متعین کرتے ہیں.
باقی کام pgai سنبھالتا ہے، بشمول ماخذ معلومات بدلنے پر ایمبیڈنگز کو تازہ رکھنا.
یہ امکانات پُرکشش ہیں:
برقرار رکھنے کے لیے کم حسبِ ضرورت رابطی رمز.
بنیادی ماخذ دستاویزات بدلنے پر ایمبیڈنگز کو ”تازہ“ رکھنا آسان ہونا چاہیے.
دوبارہ کوششیں، شرح کی حدیں اور ناکام کام وغیرہ Postgres/pgai سنبھالتا ہے.
قاری کے لیے نوٹ: pgai میں pgvector بھی شامل ہے، جو RAG کے لیے ایک اور بہت مقبول Postgres توسیع ہے. pgvector، Postgres میں سمتی ذخیرہ اور مماثلت کی تلاش شامل کرتا ہے، جبکہ pgai اسی بنیاد پر حصے بنانے، ایمبیڈ کرنے اور ایمبیڈنگز تازہ رکھنے جیسے RAG مراحل خودکار بناتا ہے.
1) اسے چلانا آسان ہے.
مثالی صورت میں عمل خاصا آسان ہے:
Timescale کی Docker تصاویر حاصل کریں، یعنی ڈیٹابیس اور کارکن.
اپنے ایمبیڈنگ فراہم کنندہ کی API کلید دیں.
سمتی کار متعین کرنے کے لیے تھوڑی سی SQL چلائیں، یعنی کیا ایمبیڈ کرنا ہے، حصے کیسے بنانے ہیں اور کون سا ماڈل استعمال کرنا ہے.
اس کے بعد pgai ایک سمتی کار کارکن کو الگ عمل کے طور پر چلاتا ہے اور غیر ہم وقتی طور پر ایمبیڈنگز بناتا ہے، مثلاً ہر پانچ منٹ بعد یا آپ کی مطلوبہ رفتار سے.
2) پورا سلسلہ ڈیٹابیس کے ”قریب“ چلانا مفید ہے.
pgai جدولوں سے مواد لے سکتا ہے اور S3 جیسی جگہوں سے دستاویزات لا کر انہیں پڑھ، تقسیم اور ایمبیڈ بھی کر سکتا ہے. یہ PDF اور Markdown وغیرہ جیسے مختلف متنی دستاویزی قالب بھی سنبھال سکتا ہے.
1) آپ بہت سا اختیار کھو دیتے ہیں، جبکہ RAG میں کبھی کبھی اختیار ضروری ہوتا ہے.
جواب کے معیار کے لحاظ سے اعلیٰ کارکردگی والے RAG نظاموں کو اکثر حسبِ ضرورت سلسلوں کی ضرورت ہوتی ہے، مثلاً:
حصے بنانے کے حسبِ ضرورت اصول، مثلاً عنوان، صفحہ یا مقرر کی باری کے مطابق
اضافی معلومات سے باخبر حصہ بندی، جس میں باب کے عنوان، اوقات، مصنفین اور دستاویز کی قسم محفوظ رہیں
ہر دستاویزی قسم کے لیے مختلف ایمبیڈنگ حکمتِ عملیاں
مندرجہ بالا معاملات میں pgai کم لچک فراہم کرتا ہے.
فی الحال حصے بنانے کی دو بنیادی حکمتِ عملیاں ہیں: حروف پر مبنی متن تقسیم کار اور تکراری حروف پر مبنی متن تقسیم کار۔ اس کے علاوہ حصہ بندی نہ کرنے کا اختیار بھی ہے. یہ بعض صورتوں کے لیے کافی ہو سکتا ہے، مگر بہت سے عملی RAG نظاموں کو مزید حسبِ ضرورت تبدیلی درکار ہوتی ہے.
یہ بہت عمدہ ہوگا اگر Timescale، Chonkie جیسی کتب خانوں میں موجود زیادہ ترقی یافتہ حصہ بندی کی حکمتِ عملیاں شامل کرے اور Anthropic کی سیاقی بازیافت جیسے جدید ڈیزائنوں کی بھی مدد کرے.
2) پہلے متن، کثیر واسطی نہیں.
RAG کے کئی دلچسپ مسائل اب صرف متن تک محدود نہیں رہے:
خاکوں والی PDF دستاویزات
پردہ تصاویر اور عام تصاویر
صوتی ریکارڈنگز
ویڈیو اقتباسات
اگر آپ ان ماخذوں سے ”متن نکال“ بھی لیں تو یہ حقیقی کثیر واسطی ایمبیڈنگ سلسلے کے برابر نہیں ہے.
اگر pgai بالآخر ابتدا سے انتہا تک کثیر واسطی ماڈلوں کی مدد کرے، یعنی S3 میں محفوظ بڑی تصاویر، صوت اور ویڈیو کو لے، تقسیم اور ایمبیڈ کرے اور مضبوط ہم وقتی برقرار رکھے، تو یہ متاثر کن ہوگا۔ مگر آج یہ صرف متنی ایمبیڈنگ کا سلسلہ ہے.
3) اگر آپ کو صرف ایمبیڈنگز درکار ہیں تو شاید pgai کی ضرورت نہ ہو.
اگر مواد لینے کا آپ کا سلسلہ پہلے ہی حسبِ ضرورت ہے یا ایسا ہونا ضروری ہے، تو ”متن کے حصوں کو ایمبیڈ کرنا“ RAG کا مشکل ترین حصہ نہیں ہے. ایسی صورت میں pgai مسئلے کا سب سے آسان حصہ حل کر رہا ہوتا ہے.
مزید یہ کہ اگر آپ کا معلوماتی ذخیرہ شاذ و نادر ہی بدلتا ہے تو خودکار ایمبیڈنگ ہم وقتی کی قدر بھی اتنی زیادہ نہیں رہتی.
pgai کے استعمال کا ایک خاصا اچھا طریقہ یہ ہوگا کہ اپنے ڈیٹابیس کے اوپر متن سے SQL کا واسطہ نصب کیا جائے. یہ کام pgai کے فراہم کردہ semantic_catalog جزو سے بہت آسانی سے کیا جا سکتا ہے. بس اسے یوں مرتب کریں:
Bash
پھر pgai semantic-catalog create کے ذریعے معنوی فہرست کو اپنی معلوماتی لغات پڑھنے دیں. اس سے آپ کے معلوماتی ذخیرے کا سیاق بنتا ہے، جو تقریباً یوں دکھائی دیتا ہے:
Plain Text
اب یہ سیاق pgai کو کئی طریقوں سے دستیاب ہے:
معنوی تلاش کے ذریعے:
یہ استفسار وہ جدول، دالے اور دیگر اشیا واپس کرے گا جو آپ کے فطری زبان والے استفسار سے متعلق ہو سکتی ہیں:
Bash
خام سیاق حاصل کریں:
یہ آپ کے فطری زبان والے استفسار سے متعلق خام YAML سیاق دکھائے گا:
Bash
SQL بنائیں:
یا آپ اپنے استفسار کا جواب دینے کے لیے درکار خام SQL براہِ راست بنا سکتے ہیں. پچھلے مرحلے کا سیاق LLM کو بھیجا جاتا ہے اور جواب تیار کیا جاتا ہے.
Bash
اگر آپ نسبتاً آسان RAG نظام بنا رہے ہیں تو ان ضرورتوں کے لیے pgai آزمانے کے قابل ہے:
Postgres کو مستند نظام کے طور پر استعمال کرنا،
کم سے کم رابطی رمز،
خودکار طور پر ہم وقت رہنے والی ایمبیڈنگز،
اپنے ڈیٹابیس پر متن سے SQL لاگو کرنے کا تیز طریقہ،
نئے RAG اوزار اور Postgres توسیعات آزمانا.
اگر آپ کے RAG سلسلے کو درج ذیل میں سے کسی چیز کی ضرورت ہے تو فی الحال pgai کا انتظار کرنا بہتر ہوگا:
مواد لینے یا حصے بنانے کی انتہائی حسبِ ضرورت منطق
مختلف تجزیاتی تقاضوں والی کئی دستاویزی اقسام
کثیر واسطی ایمبیڈنگز
آخر میں، pgvector کو وسیع پیمانے پر اپنایا گیا ہے، مگر یہ واضح نہیں کہ pgai کو بھی اتنی ہی دلچسپی اور مدد ملے گی، اگرچہ اسے آئے صرف تقریباً 18 ماہ ہوئے ہیں.
pgai، RAG کے لیے ایک دلچسپ طریقہ ہے جس میں معمول کے عملی کام ڈیٹابیس سنبھالتا ہے، تاکہ آپ کے اطلاقیے کا رمز آسان رہے.
فی الحال یہ:
آسان RAG ترتیبوں کے لیے قابلِ استعمال اور واقعی خوش گوار ہے
زیادہ حسبِ ضرورت سلسلوں، خصوصاً کثیر واسطی سلسلوں، کے لیے کافی لچک دار نہیں ہے
یہ امید افزا ہے اور اس کی پیش رفت پر نظر رکھنا یقیناً فائدہ مند ہوگا.