در مقاله قبلی دیدیم که Embedding داده‌هایی مثل متن، تصویر یا محصول را به Vector تبدیل می‌کند.
مثلاً یک متن می‌تواند به مجموعه‌ای از اعداد تبدیل شود:
[0.12, -0.44, 0.78, 0.31, ...]این Vector نمایشی عددی از مفهوم داده است.
اما وقتی تعداد Vectorها زیاد شود، یک مسئله جدید ایجاد می‌شود:
چطور نزدیک‌ترین Vectorها را با سرعت مناسب پیدا کنیم؟
اینجاست که Vector Database وارد می‌شود.
Vector Database نوعی دیتابیس است که برای ذخیره، ایندکس و جست‌وجوی Vectorهای چندبعدی طراحی شده است.
چرا دیتابیس معمولی همیشه کافی نیست؟
فرض کنید 100 Vector داریم.
می‌توانیم Query کاربر را به Vector تبدیل کنیم و آن را با تمام 100 Vector مقایسه کنیم.
اما اگر:
1,000,000 Vector
داشته باشیم، مقایسه Query با تک‌تک آن‌ها می‌تواند بسیار پرهزینه شود.
اگر برای هر Search مجبور شویم همه Vectorها را بررسی کنیم، پیچیدگی عملیات بالا می‌رود.
به همین دلیل Vector Database از ساختارهای Index مخصوص استفاده می‌کند تا بتواند نزدیک‌ترین Vectorها را سریع‌تر پیدا کند.
Vector Search چیست؟
Vector Search یعنی جست‌وجو براساس شباهت Vectorها.
فرض کنید Query کاربر این است:
چطور Performance یک API را افزایش بدهم؟
ابتدا از Query یک Embedding ساخته می‌شود:
سپس Vector Database نزدیک‌ترین Vectorهای ذخیره‌شده را پیدا می‌کند.
مثلاً:
- 1. بهینه‌سازی Queryهای دیتابیس
- 2. استفاده از Cache در Backend
- 3. کاهش تعداد درخواست‌های خارجی
این نتایج ممکن است حتی کلمات دقیق Query را نداشته باشند.
شباهت براساس معنا محاسبه شده است.
Similarity Search چیست؟
به فرایند پیدا کردن Vectorهای مشابه معمولاً Similarity Search گفته می‌شود.
فرض کنید دو Vector داریم:
A = [0.2, 0.8, 0.3]
B = [0.21, 0.77, 0.29]این دو Vector به یکدیگر نزدیک هستند.
اما:
C = [-0.8, 0.1, -0.4]ممکن است از آن‌ها دورتر باشد.
Vector Database با استفاده از معیارهای مختلف میزان شباهت را محاسبه می‌کند.
Distance Metric چیست؟
برای مقایسه Vectorها از معیارهایی استفاده می‌شود که معمولاً با نام Distance Metric یا Similarity Metric شناخته می‌شوند.
سه مورد رایج عبارت‌اند از:
Cosine Similarity
زاویه بین دو Vector را بررسی می‌کند.
برای بسیاری از Embeddingهای متنی کاربرد زیادی دارد.
Euclidean Distance
فاصله هندسی بین دو Vector را اندازه‌گیری می‌کند.
Dot Product
ضرب داخلی دو Vector را محاسبه می‌کند.
مدل Embedding مورد استفاده معمولاً مشخص می‌کند کدام Metric مناسب‌تر است.
Vector Database چه چیزی ذخیره می‌کند؟
در یک سیستم واقعی فقط Vector ذخیره نمی‌شود.
معمولاً هر رکورد شامل مواردی شبیه این است:
{
"id": "article-42",
"vector": [0.12, 0.73, -0.31, "..."],
"title": "Caching چیست؟",
"category": "backend",
"url": "/blog/caching",
"published": true
}در نتیجه هر Vector معمولاً همراه با Metadata ذخیره می‌شود.
Metadata چرا مهم است؟
فرض کنید در دیتابیس یک میلیون Vector داریم.
اما می‌خواهیم فقط بین مقاله‌های:
category = backendجست‌وجو کنیم.
یا فقط اسناد یک User خاص را بررسی کنیم:
user_id = 42در این حالت Metadata Filtering بسیار مهم می‌شود.
Query می‌تواند چیزی شبیه این باشد:
Find nearest vectors
where:
category = "backend"
published = trueاین قابلیت باعث می‌شود Vector Search برای سیستم‌های واقعی قابل‌کنترل‌تر شود.
Vector Database چه تفاوتی با SQL Database دارد؟
دیتابیس‌های SQL برای کارهایی مثل:
user_id = 12
price > 100
status = "paid"عالی هستند.
اما Vector Database برای سؤال‌هایی مثل:
کدام مقاله از نظر معنایی شبیه این Query است؟
طراحی شده است.
به شکل ساده:
SQL Database
→ Exact / Structured Search
Vector Database
→ Similarity / Semantic Searchاین دو رقیب مستقیم یکدیگر نیستند.
در پروژه‌های واقعی اغلب کنار هم استفاده می‌شوند.
آیا Vector Database جای PostgreSQL را می‌گیرد؟
خیر.
مثلاً اطلاعات سفارش:
- order_id
- user_id
- price
- status
- created_at
همچنان بهتر است در یک دیتابیس رابطه‌ای ذخیره شود.
اما Embedding مربوط به:
- Product Description
- Article Content
- Support Ticket
- Document
می‌تواند در سیستم Vector Search استفاده شود.
در بسیاری از معماری‌ها ترکیبی از هر دو وجود دارد:
- PostgreSQL
- +
- Vector Search
- +
- Application Backend
pgvector چیست؟
گاهی اصلاً لازم نیست یک Vector Database کاملاً جدا داشته باشیم.
pgvector افزونه‌ای برای PostgreSQL است که امکان ذخیره و جست‌وجوی Vectorها را فراهم می‌کند.
در این حالت می‌توان Vector را داخل همان PostgreSQL نگه داشت.
مثلاً:
CREATE TABLE documents (
id bigserial PRIMARY KEY,
content text,
embedding vector(768)
);سپس می‌توان براساس فاصله Vectorها Query انجام داد.
این روش برای بسیاری از پروژه‌های کوچک و متوسط کاملاً مناسب است.
چه زمانی pgvector انتخاب مناسبی است؟
اگر پروژه از قبل PostgreSQL دارد و حجم Vectorها خیلی بزرگ نیست، pgvector می‌تواند گزینه بسیار خوبی باشد.
مزیت‌ها:
- زیرساخت جدید لازم نیست
- Backup ساده‌تر است
- Metadata و Vector کنار هم قرار می‌گیرند
- Transaction و قابلیت‌های PostgreSQL را داریم
- پیچیدگی عملیاتی کمتر می‌شود
این همان بخش جذاب مهندسی است که گاهی «اضافه نکردن یک سرویس جدید» واقعاً بهترین تصمیم معماری است. عجیب، ولی واقعی.
Dedicated Vector Database چیست؟
در مقیاس‌های بزرگ‌تر ممکن است از دیتابیس‌های تخصصی Vector استفاده شود.
این سیستم‌ها معمولاً برای:
- Large-scale vector search
- Distributed search
- High throughput
- Low latency
- Advanced filtering
بهینه شده‌اند.
برخی Vector Databaseهای شناخته‌شده شامل:
- Qdrant
- Pinecone
- Weaviate
- Milvus
هستند.
هرکدام معماری و قابلیت‌های متفاوتی دارند.
Approximate Nearest Neighbor چیست؟
اگر بخواهیم نزدیک‌ترین Vector را با دقت کامل پیدا کنیم، می‌توانیم همه Vectorها را بررسی کنیم.
به این روش Exact Search می‌گویند.
اما در دیتاست‌های بزرگ هزینه آن زیاد است.
برای همین بسیاری از Vector Databaseها از الگوریتم‌های Approximate Nearest Neighbor یا ANN استفاده می‌کنند.
هدف ANN این است:
تقریباً نزدیک‌ترین Vectorها را با سرعت بسیار بالاتر پیدا کن.
ممکن است در بعضی موارد دقیقاً نزدیک‌ترین نتیجه پیدا نشود، اما سرعت جست‌وجو به شکل قابل توجهی بهتر می‌شود.
چرا Approximate Search قابل قبول است؟
در بسیاری از کاربردهای Semantic Search نیازی نیست نتیجه از نظر ریاضی دقیق‌ترین Vector ممکن باشد.
اگر 10 نتیجه بسیار مرتبط دریافت کنیم، معمولاً کافی است.
مثلاً در سیستم پیشنهاد مقاله:
نتیجه شماره 1
و:
نتیجه شماره 2
ممکن است هر دو از نظر کاربر کاملاً مرتبط باشند.
در این شرایط افزایش سرعت ارزش بیشتری از اختلاف بسیار کوچک Distance دارد.
HNSW چیست؟
یکی از الگوریتم‌های معروف برای Approximate Nearest Neighbor، الگوریتمی به نام HNSW است.
HNSW مخفف:
Hierarchical Navigable Small World
است.
به زبان بسیار ساده، HNSW یک Graph چندلایه از Vectorها می‌سازد.
هنگام Search به جای بررسی تمام Vectorها، از مسیرهایی در Graph عبور می‌کند تا سریع‌تر به نقاط نزدیک برسد.
شکل مفهومی آن:
این روش در بسیاری از سیستم‌های Vector Search رایج است.
Index چیست؟
همان‌طور که در دیتابیس سنتی Index می‌تواند Query را سریع‌تر کند، در Vector Database هم Index نقش بسیار مهمی دارد.
بدون Index:
- Query
- → Compare with every vector
با Index:
- Query
- → Navigate index
- → Candidate vectors
- → Similar results
البته Index رایگان نیست.
ساخت آن می‌تواند:
- زمان ببرد
- RAM مصرف کند
- Storage اضافه نیاز داشته باشد
- هنگام Insert هزینه داشته باشد
بنابراین انتخاب Index هم یک Trade-off است.
Top K چیست؟
در Vector Search معمولاً مشخص می‌کنیم چند نتیجه می‌خواهیم.
مثلاً:
top_k = 5یعنی پنج Vector نزدیک‌تر برگردانده شوند.
شکل ساده Query:
عدد مناسب Top K به کاربرد سیستم بستگی دارد.
Threshold چیست؟
گاهی نمی‌خواهیم فقط Top K نتیجه بگیریم.
می‌خواهیم فقط نتیجه‌هایی برگردند که حداقل میزان شباهت را داشته باشند.
مثلاً:
similarity >= 0.75
اما Threshold نباید از اینترنت کپی شود و تبدیل به قانون مقدس پروژه شود.
مقدار مناسب به:
- مدل Embedding
- داده
- Domain
- Similarity Metric
- نوع Query
بستگی دارد.
باید با داده واقعی سیستم ارزیابی شود.
Vector Database در Semantic Search
یکی از مهم‌ترین کاربردهای Vector Database، Semantic Search است.
فرض کنیم Query کاربر این است:
چطور درخواست‌های زیاد API را کنترل کنیم؟
ممکن است مقاله‌ای با عنوان:
Rate Limiting در Backend
وجود داشته باشد.
حتی اگر کلمات Query و عنوان دقیقاً یکسان نباشند، Embeddingها ممکن است از نظر معنایی نزدیک باشند.
Vector Database می‌تواند آن را پیدا کند.
معماری Semantic Search
ساخت Index:
هنگام Search:
این یکی از رایج‌ترین معماری‌های Semantic Search است.
Vector Database در RAG
یکی از مهم‌ترین کاربردهای Vector Database در سیستم‌های RAG است.
RAG مخفف:
Retrieval-Augmented Generation
است.
فرض کنیم یک شرکت هزاران سند داخلی دارد.
کاربر سؤال می‌پرسد:
سیاست شرکت درباره بازپرداخت چیست؟
سیستم می‌تواند:
- سؤال را به Embedding تبدیل کند.
- اسناد مرتبط را از Vector Database پیدا کند.
- اسناد را داخل Context مدل زبانی قرار دهد.
- از LLM بخواهد براساس آن‌ها پاسخ تولید کند.
معماری:
چرا Vector Database در RAG مهم است؟
اگر Retrieval خوب نباشد، LLM Context مناسبی دریافت نمی‌کند.
اگر Context اشتباه باشد، حتی بهترین مدل زبانی هم ممکن است پاسخ ضعیفی تولید کند.
به همین دلیل کیفیت سیستم RAG فقط به LLM بستگی ندارد.
بخش Retrieval اهمیت زیادی دارد.
گاهی مشکل سیستم AI اصلاً مدل نیست. فقط دیتابیس با اعتمادبه‌نفس چند Chunk نامرتبط تحویل داده و بقیه زنجیره هم مؤدبانه فاجعه را ادامه داده است.
Chunk و Vector چه ارتباطی دارند؟
در سیستم RAG معمولاً سند را به چند Chunk تقسیم می‌کنیم.
مثلاً:
سپس از هر Chunk یک Embedding ساخته می‌شود:
- Chunk 1 -> Vector 1
- Chunk 2 -> Vector 2
- Chunk 3 -> Vector 3
Vector Database این Vectorها را ذخیره می‌کند.
هنگام Search فقط Chunkهای مرتبط بازیابی می‌شوند.
Chunk Size چرا مهم است؟
اگر Chunk خیلی بزرگ باشد، ممکن است چند مفهوم مختلف در یک Embedding قرار بگیرند.
اگر خیلی کوچک باشد، Context کافی وجود ندارد.
مثلاً این Chunk:
Redis
اطلاعات زیادی ندارد.
اما این Chunk:
Redis یک دیتابیس In-Memory است که معمولاً برای Cache، Session و Queue استفاده می‌شود.
معنای بیشتری دارد.
Chunk Size باید با داده واقعی سیستم آزمایش شود.
Vector Database برای Recommendation System
فرض کنید سایت مقاله دارد.
می‌توان برای هر مقاله Embedding ساخت.
وقتی کاربر مقاله‌ای درباره:
Django REST Framework
می‌خواند، Vector مقاله با سایر مقاله‌ها مقایسه می‌شود.
نتیجه می‌تواند:
- FastAPI
- REST API
- Authentication
- PostgreSQL
باشد.
از این روش می‌توان برای بخش:
مطالب مرتبط
استفاده کرد.
Vector Database برای جست‌وجوی محصول
فرض کنید کاربر در یک فروشگاه جست‌وجو کند:
کفش سبک برای دویدن طولانی
ممکن است هیچ محصولی دقیقاً این جمله را در Description نداشته باشد.
اما Embedding Query می‌تواند با توضیحات محصولات مقایسه شود.
محصولاتی که از نظر مفهوم نزدیک هستند در نتایج نمایش داده می‌شوند.
Vector Database برای پشتیبانی مشتری
فرض کنید هزاران Support Ticket داریم.
وقتی Ticket جدید ثبت می‌شود می‌توان Embedding آن را ساخت.
سپس سیستم Ticketهای مشابه را پیدا می‌کند.
مثلاً:
Payment failed after checkout
ممکن است با:
Card charged but order failed
از نظر معنایی مرتبط باشد.
این قابلیت می‌تواند برای:
- پیشنهاد پاسخ
- تشخیص Duplicate Ticket
- دسته‌بندی مشکلات
- پیدا کردن Incidentهای مشابه
استفاده شود.
Hybrid Search چیست؟
Vector Search همیشه کافی نیست.
فرض کنید Query کاربر:
PostgreSQL error 23505
است.
بخش:
23505
باید تقریباً به صورت Exact پیدا شود.
Semantic Search ممکن است برای چنین داده‌ای مناسب نباشد.
بنابراین بسیاری از سیستم‌ها از Hybrid Search استفاده می‌کنند:
- Keyword Search
- +
- Vector Search
ترکیب این دو روش اغلب نتایج بهتری ارائه می‌کند.
Full-text Search و Vector Search چه تفاوتی دارند؟
Full-text Search بیشتر روی Termها و Keywordها تمرکز دارد.
Vector Search بیشتر روی معنا تمرکز می‌کند.
مثال:
Query:
speed up APIیک مقاله ممکن است عبارت:
backend performance optimization
را داشته باشد.
Vector Search احتمالاً ارتباط معنایی را بهتر تشخیص می‌دهد.
اما اگر Query شامل:
CVE-2026-1234
باشد، Exact Text Search اهمیت بیشتری دارد.
آیا همیشه به Vector Database نیاز داریم؟
خیر.
این یکی از مهم‌ترین نکات مقاله است.
اگر فقط:
500
Vector دارید، احتمالاً لازم نیست یک Cluster تخصصی Vector Database راه‌اندازی کنید.
حتی یک In-memory Search یا PostgreSQL می‌تواند کافی باشد.
Vector Database زمانی ارزش بیشتری دارد که:
- تعداد Vectorها زیاد باشد
- Latency مهم باشد
- Similarity Search زیاد انجام شود
- Metadata Filtering نیاز داشته باشید
- Scale کردن Search اهمیت داشته باشد
- RAG یا Semantic Search بخش مهم محصول باشد
چه زمانی Vector Database اضافه‌کاری است؟
فرض کنید فقط می‌خواهید User را براساس Email پیدا کنید:
SELECT *
FROM users
WHERE email = 'user@example.com';استفاده از Embedding و Vector Database برای این مسئله تقریباً معادل استفاده از موتور جت برای رفتن تا سوپرمارکت است.
از نظر مهندسی هیجان‌انگیز، از نظر منطقی کمی مشکوک.
چه زمانی از PostgreSQL + pgvector شروع کنیم؟
برای بسیاری از پروژه‌ها این نقطه شروع خوبی است:
اگر:
- PostgreSQL از قبل دارید
- چند میلیون Vector یا کمتر دارید
- Query Load خیلی شدید نیست
- تیم کوچک است
- سادگی زیرساخت مهم است
این معماری می‌تواند کاملاً مناسب باشد.
قبل از اضافه کردن سرویس جدید بهتر است واقعاً نیاز آن را اندازه‌گیری کنید.
چه زمانی Dedicated Vector Database منطقی می‌شود؟
یک سرویس تخصصی زمانی جذاب‌تر می‌شود که:
- Dataset بسیار بزرگ است
- Search throughput بالاست
- Latency پایین ضروری است
- Horizontal Scaling نیاز دارید
- Advanced Filtering مهم است
- Multi-tenancy پیچیده دارید
- Vector Search بخش اصلی محصول است
در این شرایط دیتابیس تخصصی می‌تواند مدیریت و Performance بهتری ارائه دهد.
انتخاب Vector Database براساس چه معیارهایی است؟
به جای انتخاب براساس محبوبیت، این موارد را بررسی کنید:
Scale
چند Vector ذخیره می‌کنید؟
- 10K
- 1M
- 100M
تفاوت زیادی دارند.
Latency
آیا Search باید در:
20ms
انجام شود یا:
500ms
هم قابل قبول است؟
Filtering
آیا نیاز به Filter پیچیده روی Metadata دارید؟
Update Frequency
آیا Vectorها دائماً تغییر می‌کنند یا تقریباً ثابت‌اند؟
Deployment
آیا سرویس Managed می‌خواهید یا Self-hosted؟
Cost
Storage، RAM، CPU و Network همه هزینه دارند.
Operational Complexity
یک سرویس جدید یعنی:
- Monitoring
- Backup
- Security
- Upgrade
- Incident
نیز به پروژه اضافه می‌شود.
امنیت در Vector Database
Vector Database ممکن است داده‌های حساس را به شکل Embedding ذخیره کند.
نباید تصور کرد Vector چون برای انسان قابل خواندن نیست، پس کاملاً امن است.
باید مواردی مثل:
- Authentication
- Authorization
- Encryption
- Tenant Isolation
- Data Retention
در نظر گرفته شوند.
همچنین Metadata ممکن است مستقیماً اطلاعات حساس داشته باشد.
Multi-tenancy در Vector Search
فرض کنید یک SaaS داریم و هر شرکت اسناد خودش را دارد.
نباید Vectorهای شرکت A در Search شرکت B ظاهر شوند.
یکی از روش‌ها استفاده از Metadata است:
tenant_id = 42و هنگام Query:
Search similar vectors
WHERE tenant_id = 42این Filter بخش امنیتی سیستم است، نه صرفاً Optimization.
Vector Search را چطور تست کنیم؟
صرفاً اینکه Search نتیجه‌ای برگرداند کافی نیست.
باید کیفیت Retrieval را ارزیابی کنیم.
برای مجموعه‌ای از Queryهای واقعی مشخص کنید:
Expected relevant documents
سپس بررسی کنید:
- نتیجه درست در Top 1 قرار دارد؟
- در Top 5 هست؟
- نتایج نامرتبط زیاد هستند؟
- Queryهای کوتاه چطور عمل می‌کنند؟
- زبان فارسی چطور است؟
این Evaluation برای انتخاب مدل Embedding و Vector Database مهم است.
Recall چیست؟
یکی از معیارهای مهم در Search، Recall است.
به زبان ساده، Recall بررسی می‌کند چه تعداد از نتایج مرتبط واقعی توانسته‌اند پیدا شوند.
اگر 10 سند مرتبط وجود داشته باشد و سیستم فقط 6 مورد را پیدا کند:
Recall = 60%در Approximate Search معمولاً بین سرعت و Recall یک Trade-off وجود دارد.
Latency و Recall
معمولاً Search دقیق‌تر می‌تواند پردازش بیشتری نیاز داشته باشد.
بنابراین ممکن است:
و:
باشد.
تنظیمات Index باید براساس نیاز محصول انتخاب شوند.
معماری نمونه یک سیستم RAG
یک معماری ساده:
در زمان سؤال:
اگر پاسخ AI به اطلاعات اختصاصی پروژه متکی باشد، Vector Database اغلب در بخش Retrieval این معماری قرار می‌گیرد.
اشتباهات رایج هنگام استفاده از Vector Database
انتخاب دیتابیس قبل از فهم مسئله
اول باید بدانیم:
- چند Vector؟
- چه نوع Search؟
- چه Latency؟
- چه Filtering؟
سپس ابزار انتخاب شود.
استفاده از Vector Search برای همه‌چیز
Vector Search جایگزین:
- SQL
- Full-text Search
- Cache
- Exact Lookup
نیست.
نادیده گرفتن Metadata
Vector بدون Metadata در بسیاری از پروژه‌ها ارزش محدودی دارد.
عوض کردن Embedding Model بدون Re-index
اگر مدل Embedding تغییر کند، معمولاً Vectorهای قبلی باید دوباره تولید شوند.
نداشتن Evaluation
بدون Test Set نمی‌دانیم Search واقعاً خوب است یا فقط Demo زیبایی ساخته‌ایم.
یک Rule of Thumb ساده
اگر مسئله شما این است:
«چیزی را دقیقاً با ID پیدا کن»
دیتابیس معمولی استفاده کنید.
اگر مسئله این است:
«چیزی را پیدا کن که از نظر معنی شبیه این باشد»
Vector Search را بررسی کنید.
اگر هر دو را لازم دارید:
Hybrid Architecture.
زندگی مهندسی نرم‌افزار با جواب «بستگی دارد» ادامه پیدا می‌کند. طبیعت ظاهراً حاضر نیست یک ابزار واحد برای همه‌چیز به ما بدهد.
جمع‌بندی
Vector Database برای ذخیره و جست‌وجوی سریع Embeddingها طراحی شده است.
مهم‌ترین مفاهیمی که باید به خاطر داشته باشیم:
Vector Search برای پیدا کردن Vectorهای مشابه استفاده می‌شود.
Similarity Metric میزان شباهت Vectorها را اندازه‌گیری می‌کند.
ANN امکان Search سریع در Datasetهای بزرگ را فراهم می‌کند.
HNSW یکی از الگوریتم‌های رایج Approximate Search است.
Metadata Filtering امکان محدود کردن Search براساس اطلاعات ساختاریافته را می‌دهد.
Hybrid Search ترکیبی از Keyword و Vector Search است.
pgvector می‌تواند برای اضافه کردن قابلیت Vector Search به PostgreSQL استفاده شود.
Vector Database زمانی ارزشمند است که معنا و شباهت برای Search اهمیت داشته باشد و تعداد Embeddingها آن‌قدر زیاد باشد که Search ساده دیگر مناسب نباشد.
اما مهم‌ترین تصمیم معماری شاید این باشد:
قبل از اضافه کردن Vector Database مطمئن شوید واقعاً به Vector Database نیاز دارید.
در مقاله بعدی این مجموعه وارد RAG می‌شویم و می‌بینیم چگونه Embedding، Vector Database و LLM را کنار هم قرار دهیم تا مدل بتواند با داده‌های اختصاصی ما پاسخ تولید کند.