پایگاه‌داده برداری به یک سوال پاسخ می‌دهد، خیلی سریع
فهرستی از اعداد به آن بدهید و فهرست‌های ذخیره‌شده‌ای را برمی‌گرداند که به آن نزدیک‌ترند. تمام رابط کاربری همین است.
این فهرست‌ها را embedding می‌گویند. یک مدل embedding یک قطعه متن، توضیح یک محصول یا یک تصویر را به چند صد تا چند هزار عدد تبدیل می‌کند، طوری که معناهای مشابه در کنار هم قرار بگیرند، و embedding در هوش مصنوعی چیست نحوه انجام آن را توضیح می‌دهد. پایگاه‌داده برداری جایی است که این فهرست‌ها، وقتی تعدادشان زیاد شد، زندگی می‌کنند. هر کدام را همراه با یک شناسه و مقداری متادیتا ذخیره می‌کند، روی آن‌ها یک ایندکس می‌سازد و به جستجوی نزدیک‌ترین همسایه پاسخ می‌دهد: «این یک بردار پرسش است، ده مورد نزدیک‌تر را به من بده.»
بخش سخت کار همان کلمه «سریع» است. مقایسه یک پرسش با یک میلیون بردار ذخیره‌شده که هر کدام 1,536 عدد دارند، به معنای 1.5 میلیارد ضرب است، و انجام این کار در هر ضربه کلید مقیاس‌پذیر نیست. به همین دلیل پایگاه‌های داده برداری از ایندکس‌های نزدیک‌ترین همسایه تقریبی استفاده می‌کنند که رایج‌ترین آن‌ها HNSW است، یک ساختار گراف از مقاله‌ای در سال 2016 نوشته Malkov و Yashunin که چند صد گزینه را به‌جای کل یک میلیون بررسی می‌کند و تقریباً همیشه پاسخ درست را برمی‌گرداند. همین «تقریباً» همان معامله است: کمی دقت کمتر در ازای سرعتی هزار برابر.
پایگاه‌داده فعلی شما با کلمات مطابقت می‌دهد؛ پایگاه‌داده برداری با معنا
یک پایگاه‌داده رابطه‌ای ردیف‌هایی را پیدا می‌کند که مقادیرشان مطابقت دارد: WHERE customer_id = 4127. یک ایندکس تمام‌متن اسنادی را پیدا می‌کند که حاوی کلماتی خاص‌اند: refund AND policy. یک پایگاه‌داده برداری آیتم‌هایی را پیدا می‌کند که معنایشان نزدیک است: پرسش «چطور پولم را پس بگیرم» بخشی با عنوان «بازگشت کالا و استرداد وجه» را برمی‌گرداند، با اینکه این دو هیچ کلمه مشترکی ندارند.
| پایگاه‌داده رابطه‌ای | جستجوی تمام‌متن | پایگاه‌داده برداری | |
|---|---|---|---|
| می‌پرسد | کدام ردیف‌ها با این مقدار مطابقت دارند؟ | کدام اسناد حاوی این کلمات هستند؟ | کدام آیتم‌ها معنایی نزدیک به این دارند؟ |
| ایندکس | B-tree روی ستون‌ها | ایندکس معکوس روی عبارت‌ها | گراف یا خوشه‌بندی روی بردارها (HNSW, IVF) |
| دقیق است؟ | بله | بله | معمولاً تقریبی |
| در چه چیزی خوب است | شناسه، تاریخ، مبلغ، join | نام‌ها، کدها، عبارات دقیق | مترادف، بازنویسی، چندزبانه، تصاویر |
| در چه چیزی ضعیف است | معنا | معنا | رشته‌های دقیق، شمارش، فیلتر بر اساس مقدار |
| نمونه‌ها | Postgres، MySQL، SQLite | Elasticsearch، Lucene | Pinecone، Weaviate، Qdrant، Milvus، Chroma، pgvector |
ردیف آخر نشان می‌دهد این دسته‌بندی چقدر مبهم است. pgvector ستون‌های برداری و یک ایندکس HNSW به Postgres معمولی اضافه می‌کند، و Elasticsearch از نسخه 7.0 در سال 2019 یک فیلد برداری دارد و از نسخه 8.0 در سال 2022 جستجوی HNSW را هم پشتیبانی می‌کند. یک «پایگاه‌داده برداری» اغلب یک قابلیت درون پایگاه‌داده‌ای است که از قبل استفاده می‌کنید، نه یک محصول جدید، و محصولات مستقل بر سر مقیاس و پرداخت عملیاتی رقابت می‌کنند، نه انجام کاری که Postgres نمی‌تواند.
چت با اسناد شما یک جستجوی برداری با یک مدل در انتهای آن است
تولید تقویت‌شده با بازیابی (RAG) که RAG چیست آن را توضیح می‌دهد، یک مرحله جستجو و یک مرحله نوشتن دارد. پایگاه‌داده برداری همان مرحله جستجو است.
- هر سند را به قطعاتی چند صد تا هزار توکنی تقسیم کنید.
- هر قطعه را embed کنید و بردارها را همراه با متن قطعه و منبع آن در پایگاه‌داده برداری ذخیره کنید.
- وقتی پرسشی می‌رسد، آن را embed کنید و از پایگاه‌داده نزدیک‌ترین قطعات را بخواهید.
- آن قطعات را همراه با پرسش به مدل زبانی بدهید و بگذارید پاسخ را بنویسد.
مراحل 1 و 2 فقط یک‌بار، هنگام افزودن اسناد، اتفاق می‌افتند. مراحل 3 و 4 در هر پرسش تکرار می‌شوند. مدل زبانی هرگز کل مجموعه را نمی‌بیند؛ فقط پنج یا ده قطعه‌ای را می‌بیند که پایگاه‌داده انتخاب کرده است. به همین دلیل کیفیت پاسخ به کیفیت جستجو بستگی دارد: اگر نزدیک‌ترین بردار قطعه اشتباهی باشد، مدل با اطمینان به پرسش اشتباهی پاسخ می‌دهد، چیزی که توهم هوش مصنوعی چیست آن را یک خطای بازیابی می‌داند، نه یک اختراع.
چه زمانی به آن نیاز دارید و چه زمانی ارسال کل فایل بهتر است
این تصمیم به اندازه مربوط می‌شود. یک مدل فقط می‌تواند پنجره زمینه خودش را در یک لحظه در نظر بگیرد، و هزینه هر توکن داخل آن در هر نوبت پرداخت می‌شود. پایگاه‌داده برداری وجود دارد تا فقط بخش مرتبط را جلوی مدل بگذارد. برای یک سند که در این پنجره جا می‌شود، بازیابی مرحله‌ای است که می‌توانید حذف کنید؛ برای مجموعه‌ای که جا نمی‌شود، تنها گزینه همین است.
قیمت دو طراحی را روی یک گزارش 300,000 توکنی، چند صد صفحه‌ای، با ده پرسش و بازیابی پنج قطعه 1,000 توکنی برای هر پرسش حساب کنید. ارسال کل فایل در هر بار، 3 میلیون توکن ورودی است. بازیابی پنج قطعه 1,000 توکنی برای هر پرسش، 50,000 توکن است. با نرخ‌های ورودی فهرست در شاخص هزینه مدل‌های هوش مصنوعی، که در 2026-08-20 از OpenRouter گرفته شده، این اختلاف در همه مدل‌ها 60 برابر است. کش کردن پرامپت، جایی که ارائه‌دهنده آن را پیشنهاد می‌کند، هزینه خواندن دوباره همان فایل را به یک‌دهم تا نصف قیمت فهرست می‌رساند، که این اختلاف را به حدود 6 تا 30 برابر کاهش می‌دهد. بازیابی همچنان برنده است، اما با فاصله کمتر.
طراحی کل‌فایل وقتی فایل در بودجه جا می‌شود چیزی در ازای آن پول می‌خرد: یک قرارداد 60 صفحه‌ای، حدود 40,000 توکن، به مدل اجازه می‌دهد به پرسش‌هایی پاسخ دهد که به کل سند در یک لحظه نیاز دارند، مثل «آیا اینجا چیزی با بند 14 تناقض دارد؟»، پرسشی که بازیابی نمی‌تواند بپرسد چون هرگز بند 14 و تناقض را در یک دسته نمی‌بیند. قانونی که از این بیرون می‌آید این است: یک سند، یا چند سند، به‌طور کامل وارد می‌شود؛ یک کتابخانه از پایگاه‌داده برداری عبور می‌کند. بین این دو، آپلود را بر اساس موضوع تقسیم کنید تا مدل بخشی را که نیاز دارد دریافت کند.
Whizi خود متن را می‌فرستد، تا سقف نوبتی 40,000 توکنی
Whizi برای چت شما پایگاه‌داده برداری اجرا نمی‌کند. وقتی فایلی پیوست می‌کنید، مسیر آپلود سند متن را استخراج می‌کند و آن را به‌عنوان متن پرامپت به مدل می‌فرستد، تا سقف ثابت 40,000 توکن در هر نوبت؛ آپلودی طولانی‌تر بریده می‌شود، همراه با یک اعلان و یک نشانگر داخل پیام که این را می‌گوید. فایل‌های پروژه هم به همین شکل کار می‌کنند: ویژگی پروژه‌ها تا 10 فایل را سنجاق می‌کند و متن آن‌ها را در هر پیام دوباره در پرامپت می‌سازد، با سقف 32,000 کاراکتر برای هر فایل و 120,000 برای کل بلوک پروژه.
این سقف‌ها لبه طراحی هستند. فایل سنجاق‌شده‌ای که از 32,000 کاراکتر بیشتر شود کوتاه می‌شود، پیوستی که از بودجه 40,000 توکنی هر نوبت بیشتر شود بریده می‌شود، و یک پروژه یک پوشه است، نه یک کتابخانه قابل جستجو. این معامله عمدی است: برای یک قرارداد یا مقاله‌ای که در بودجه هر نوبت جا می‌شود، حاضر بودن متن بهتر از جستجو شدن آن است، و آزمونی که اهمیت دارد، یعنی خواستن نقل‌قول از مدل درباره قطعه‌ای که استفاده کرده، کار می‌کند چون آن قطعه واقعاً آنجاست. برای هزار سند، پایگاه‌داده برداری ابزار درست است و یک اپلیکیشن چت ابزار اشتباه.
دو عادت از این سازوکار باقی می‌مانند. وقتی چند فایل پیوست شده، نام فایل را در پرسش خود بیاورید، چون در غیر این صورت مدل بی‌سروصدا خودش انتخاب می‌کند. و برای هر پاسخی که می‌خواهید بر اساس آن عمل کنید، نقل‌قول بخواهید. یک سیستم بازیابی ممکن است قطعه اشتباهی برگرداند؛ یک سیستم کل‌فایل ممکن است از حافظه پاسخ دهد نه از فایل. نقل‌قول هر دو را می‌گیرد.
- یک سند را کامل بفرستید؛ یک مجموعه را پشت یک پایگاه‌داده برداری قرار دهید
- آپلود طولانی را بر اساس موضوع تقسیم کنید تا مدل بخشی را که پرسش نیاز دارد دریافت کند
- قبل از تکیه بر پاسخ، از مدل بخواهید قطعه‌ای را که استفاده کرده نقل‌قول کند
- برای شناسه‌ها، کدها و عبارات دقیق از جستجوی متنی ساده استفاده کنید؛ جستجوی برداری معنا را مطابقت می‌دهد، نه کاراکترها را
- یک خطای بازیابی را یک مشکل جستجو در نظر بگیرید: قبل از مقصر دانستن مدل نویسنده، با مدلی بهتر یا قطعاتی کوچک‌تر دوباره embed کنید
پرسش‌های متداول
وکتور دیتابیس به زبان ساده چیست؟
محلی برای نگهداری فهرست‌های عددی که یک مدل هوش مصنوعی برای نشان دادن معنا استفاده می‌کند، ساخته‌شده برای پیدا کردن نزدیک‌ترین تطبیق‌ها به سرعت. embedding یک پرسش را به آن می‌دهید و آن embeddingها، و متن پشت آن‌ها، را که معنایی مشابه دارند برمی‌گرداند. این نیمه جستجوی چت با اسناد شماست، هر وقت مجموعه برای ارسال کامل خیلی بزرگ باشد.
آیا برای استفاده از هوش مصنوعی با اسنادم به وکتور دیتابیس نیاز دارم؟
فقط اگر اسناد در پنجره زمینه مدل جا نشوند. یک گزارش یا قرارداد تنها می‌تواند کامل به مدل فرستاده شود، کاری که Whizi با پیوست‌ها و فایل‌های سنجاق‌شده پروژه انجام می‌دهد. یک کتابخانه با هزاران سند به بازیابی نیاز دارد، و بازیابی به یک ایندکس برداری نیاز دارد، چه در یک محصول اختصاصی و چه در افزونه‌ای برای Postgres مثل pgvector.
تفاوت وکتور دیتابیس با پایگاه‌داده معمولی چیست؟
یک پایگاه‌داده معمولی مقادیر را مطابقت می‌دهد: این شناسه، این تاریخ، این کلمه دقیق. یک پایگاه‌داده برداری معنا را مطابقت می‌دهد و آیتم‌های ذخیره‌شده‌ای را برمی‌گرداند که embeddingشان به embedding پرسش نزدیک‌ترین است. این کار معمولاً تقریبی است و از ایندکسی مثل HNSW استفاده می‌کند که چند صد گزینه را به‌جای همه آیتم‌ها بررسی می‌کند، و در تطبیق دقیقی که یک پایگاه‌داده معمولی خوب انجام می‌دهد، ضعیف است.
پرکاربردترین وکتور دیتابیس‌ها کدام‌اند؟
Pinecone، Weaviate، Qdrant، Milvus و Chroma محصولات مستقل رایج هستند، و pgvector همین قابلیت را به Postgres اضافه می‌کند. Elasticsearch و OpenSearch هم جستجوی برداری دارند. انتخاب معمولاً عملیاتی است، درباره مقیاس و میزبانی، چون همه آن‌ها همان ایده نزدیک‌ترین همسایه تقریبی را پیاده‌سازی می‌کنند.
بازیابی نسبت به ارسال کل فایل چقدر صرفه‌جویی می‌کند؟
ده پرسش روی یک گزارش 300,000 توکنی، اگر فایل در هر نوبت ارسال شود روی Claude Sonnet 5 حدود $6.00 هزینه دارد و اگر به‌جای آن پنج قطعه 1,000 توکنی بازیابی شود $0.10، بر اساس نرخ‌های فهرست OpenRouter که در 2026-08-20 گرفته شده. روی GPT-5.6 Luna همین دو عدد $0.60 در برابر $0.01 است. این نسبت روی همه مدل‌ها 60 برابر است چون هر دو طراحی به ازای هر توکن همان نرخ را می‌پردازند.
