vector database کیا ہوتا ہے؟

vector database ایک سوال کا جواب دیتا ہے، بہت تیزی سے

اسے نمبروں کی ایک فہرست دیں اور یہ وہ محفوظ فہرستیں واپس دیتا ہے جو اس کے قریب ترین ہیں۔ یہی اس کا پورا انٹرفیس ہے۔

یہ فہرستیں ایمبیڈنگز ہیں۔ ایک embedding model کسی حصے، کسی پروڈکٹ کی تفصیل یا کسی تصویر کو چند سو سے چند ہزار نمبروں میں بدل دیتا ہے، اس طرح رکھے گئے کہ ملتے جلتے معنی ایک دوسرے کے قریب آ جائیں، اور AI میں embeddings کیا ہیں یہ بتاتا ہے کہ کیسے۔ vector database وہ جگہ ہے جہاں یہ فہرستیں رہتی ہیں جب آپ کے پاس ان کی بڑی تعداد ہو جاتی ہے۔ یہ ہر فہرست کو ایک ID اور کچھ metadata کے ساتھ محفوظ کرتا ہے، ان پر ایک index بناتا ہے، اور nearest neighbour search کا جواب دیتا ہے: "یہ ایک query vector ہے، مجھے دس قریب ترین دو۔"

مشکل حصہ لفظ تیز ہے۔ 1,536 نمبروں والے دس لاکھ محفوظ vectors کے ساتھ ایک query کا موازنہ کرنا 1.5 ارب ضربیں ہیں، اور ہر حرف ٹائپ کرنے پر یہ کرنا قابلِ عمل نہیں۔ اس لیے vector databases approximate nearest neighbour indexes استعمال کرتے ہیں، جن میں سب سے عام HNSW ہے، Malkov اور Yashunin کے 2016 کے مقالے سے ایک graph ساخت جو تمام دس لاکھ کے بجائے چند سو امیدواروں کو دیکھتی ہے اور تقریباً ہر بار درست جواب دیتی ہے۔ یہ "تقریباً" ہی سودا ہے: تھوڑی سی recall کے بدلے ہزار گنا رفتار۔

آپ کا موجودہ ڈیٹا بیس الفاظ ملاتا ہے؛ vector database معنی ملاتا ہے

ایک relational database ایسی قطاریں تلاش کرتا ہے جن کی قدریں میل کھاتی ہوں: WHERE customer_id = 4127۔ ایک full-text index وہ دستاویزات تلاش کرتا ہے جن میں الفاظ موجود ہوں: refund AND policy۔ vector database ایسی اشیاء تلاش کرتا ہے جن کا معنی قریب ہو: سوال "مجھے اپنے پیسے کیسے واپس ملیں گے" اس حصے کو واپس دیتا ہے جس کا عنوان "Returns and refunds" ہے، حالانکہ دونوں میں کوئی لفظ مشترک نہیں۔

آخری قطار ظاہر کرتی ہے کہ یہ زمرہ کتنا دھندلا ہو چکا ہے۔ pgvector عام Postgres میں vector کالمز اور ایک HNSW index شامل کرتا ہے، اور Elasticsearch نے 2019 میں ورژن 7.0 سے ایک vector field اور 2022 میں ورژن 8.0 سے HNSW search رکھی ہے۔ "vector database" اکثر اس ڈیٹا بیس کے اندر ایک صلاحیت ہوتی ہے جو آپ پہلے ہی چلا رہے ہیں، نہ کہ کوئی نیا پروڈکٹ، اور الگ سے موجود پروڈکٹس اسکیل اور operational معیار پر مقابلہ کرتے ہیں، نہ کہ کچھ ایسا کرنے پر جو Postgres نہیں کر سکتا۔

Chat-with-your-documents دراصل ماڈل کے ساتھ ایک vector search ہے

Retrieval-augmented generation، جسے RAG کیا ہے تفصیل سے بیان کرتا ہے، ایک تلاشی مرحلہ اور ایک تحریری مرحلہ رکھتا ہے۔ vector database تلاشی مرحلہ ہے۔

1. ہر دستاویز کو چند سو سے ایک ہزار tokens کے حصوں میں تقسیم کریں۔
2. ہر حصے کو embed کریں اور vectors کو، حصے کے متن اور اس کے ماخذ کے ساتھ، vector database میں محفوظ کریں۔
3. جب کوئی سوال آئے تو اسے embed کریں اور database سے قریب ترین حصے مانگیں۔
4. وہ حصے سوال کے ساتھ language model کو دیں، اور اسے جواب لکھنے دیں۔

مرحلہ 1 اور 2 صرف ایک بار ہوتے ہیں، جب دستاویزات شامل کی جاتی ہیں۔ مرحلہ 3 اور 4 ہر سوال پر ہوتے ہیں۔ language model کبھی پورا مجموعہ نہیں دیکھتا؛ یہ صرف وہ پانچ یا دس حصے دیکھتا ہے جو database نے چنے۔ یہی وجہ ہے کہ جواب اتنا ہی اچھا ہوتا ہے جتنی تلاش: اگر قریب ترین vector غلط حصہ ہو تو ماڈل بھروسے سے غلط سوال کا جواب دیتا ہے، جسے AI hallucination کیا ہے ایک ایجاد کے بجائے retrieval کی ناکامی کے طور پر درج کرتا ہے۔

کب اس کی ضرورت ہے، اور کب پوری فائل بھیجنا بہتر ہے

یہ فیصلہ حجم کے بارے میں ہے۔ ایک ماڈل ایک وقت میں صرف اپنی context window کو مدنظر رکھ سکتا ہے، اور اس کے اندر ہر token ہر بار کی قیمت لیتا ہے۔ vector database اس لیے ہے کہ ماڈل کے سامنے صرف متعلقہ حصہ رکھا جائے۔ ایک ایسی دستاویز کے لیے جو سما جائے، retrieval ایک ایسا مرحلہ ہے جسے چھوڑا جا سکتا ہے؛ ایک ایسے مجموعے کے لیے جو نہ سمائے، یہی واحد آپشن ہے۔

دونوں ڈیزائنز کی قیمت ایک 300,000-token رپورٹ پر لگائیں، یعنی کئی سو صفحات، جس سے دس سوالات پوچھے جائیں، اور ہر سوال پر پانچ 1,000-token حصے حاصل کیے جائیں۔ ہر بار پوری فائل بھیجنا 3 ملین input tokens بنتا ہے۔ ہر سوال پر پانچ 1,000-token حصے حاصل کرنا 50,000 بنتا ہے۔ AI model cost index کی فہرستی input شرحوں پر، جو OpenRouter سے 2026-08-20 کو لی گئیں، فرق ہر ماڈل پر 60 گنا ہے۔ Prompt caching، جہاں فراہم کنندہ اسے پیش کرتا ہے، وہی فائل دوبارہ پڑھنے کا حساب فہرستی قیمت کے دسویں سے آدھے حصے پر لگاتا ہے، جس سے فرق تقریباً 6 گنا سے 30 گنا تک سکڑ جاتا ہے۔ Retrieval پھر بھی جیتتا ہے، مگر کم فرق سے۔

پوری فائل والا ڈیزائن اس رقم کے بدلے کچھ دیتا ہے جب فائل بجٹ میں سما جائے: ایک 60 صفحات کا معاہدہ، تقریباً 40,000 tokens، ماڈل کو ایسے سوالات کا جواب دینے دیتا ہے جن کے لیے پوری دستاویز بیک وقت درکار ہو، مثلاً "کیا یہاں کچھ clause 14 سے متصادم ہے"، جو retrieval نہیں پوچھ سکتا کیونکہ یہ کبھی clause 14 اور تضاد ایک ہی بیچ میں نہیں دیکھتا۔ اس سے جو اصول نکلتا ہے: ایک دستاویز، یا چند، پوری بھیجی جائیں؛ ایک لائبریری vector database سے گزرے۔ دونوں کے درمیان، اپلوڈ کو موضوع کے مطابق تقسیم کریں تاکہ ماڈل کو وہ حصہ ملے جس کی اسے ضرورت ہے۔

Whizi متن خود بھیجتا ہے، 40,000-token turn تک

Whizi آپ کی چیٹ کے لیے کوئی vector database نہیں چلاتا۔ جب آپ کوئی فائل منسلک کرتے ہیں، تو document upload کا راستہ متن نکالتا ہے اور اسے ماڈل کو prompt متن کے طور پر بھیجتا ہے، فی turn ایک مقررہ 40,000-token بجٹ تک؛ اس سے لمبی اپلوڈ کاٹ دی جاتی ہے، ساتھ میں ایک toast اور پیغام کے اندر ایک نشان جو یہ بتاتا ہے۔ Project files بھی اسی طرح کام کرتی ہیں: projects فیچر 10 فائلوں تک pin کرتا ہے اور ہر پیغام پر ان کا متن دوبارہ prompt میں شامل کرتا ہے، جو فی فائل 32,000 حروف اور پورے project block کے لیے 120,000 تک محدود ہے۔

یہ حدیں ڈیزائن کی سرحد ہیں۔ 32,000 حروف سے زیادہ کی pinned فائل کاٹ دی جاتی ہے، 40,000-token turn بجٹ سے زیادہ کا attachment کاٹ دیا جاتا ہے، اور project ایک searchable لائبریری نہیں بلکہ ایک فولڈر ہے۔ یہ سمجھوتہ جان بوجھ کر ہے: ایسے معاہدے یا مقالے کے لیے جو turn بجٹ میں سما جائے، متن کا حاضر ہونا اس کے تلاش کیے جانے سے بہتر ہے، اور جو چیک اہم ہے، یعنی ماڈل سے وہ حصہ کوٹ کرنے کو کہنا جو اس نے استعمال کیا، وہ کام کرتا ہے کیونکہ حصہ وہاں موجود ہے۔ ایک ہزار دستاویزات کے لیے، vector database درست ٹول ہے اور ایک چیٹ ایپ غلط۔

اس طریقہ کار سے دو عادتیں آتی ہیں۔ ایک سے زیادہ فائلیں منسلک ہونے پر اپنے سوال میں فائل کا نام ایک بار لیں، کیونکہ ورنہ ماڈل خاموشی سے خود چن لیتا ہے۔ اور کسی بھی ایسے جواب پر جس پر آپ عمل کریں گے، وہ حوالہ مانگیں۔ ایک retrieval نظام غلط حصہ واپس دے سکتا ہے؛ ایک whole-file نظام فائل کے بجائے یادداشت سے جواب دے سکتا ہے۔ حوالہ دونوں کو پکڑ لیتا ہے۔