در یک سیستم RAG Production همیشه یک تضاد وجود دارد:
Response Quality ↑
|
|
|
↓
Latency ↑
هرچه سیستم را هوشمندتر کنیم، معمولاً زمان پاسخ بیشتر می‌شود.
مثلاً اضافه کردن:
- Retriever
- Query Rewriter
- Reranker
- Agent Workflow
- چند LLM مختلف
باعث افزایش کیفیت می‌شود، اما Latency را بالا می‌برد.
Latency در RAG از کجا می‌آید؟
یک Pipeline ساده:
User Query
|
↓
Embedding
|
↓
Vector Search
|
↓
Reranker
|
↓
Prompt Construction
|
↓
LLM Generation
|
↓
Answer
هر مرحله زمان اضافه می‌کند.
اما بزرگ‌ترین عامل:
Transformer Models
هستند.
یعنی:
- LLM اصلی
- Query Rewriter
- Router LLM
- Reranker مبتنی بر Transformer
اهمیت Latency به نوع کاربرد بستگی دارد
همه سیستم‌ها یک هدف ندارند.
مثال ۱: فروشگاه اینترنتی
کاربر:
یک لپ‌تاپ خوب پیشنهاد بده
انتظار:
زیر 1 ثانیه
کیفیت کمی کمتر قابل قبول است.
معماری:
Fast Retrieval
+
Small LLM
مثال ۲: تشخیص بیماری نادر
کاربر:
علائم یک بیماری نادر چیست؟
اینجا:
کیفیت مهم‌تر از سرعت است.
ممکن است:
30 ثانیه
هم قابل قبول باشد.
معماری:
Deep Retrieval
+
Reranker
+
Large Reasoning Model
مهم‌ترین راه کاهش Latency: LLM
چون بیشتر زمان صرف Generation می‌شود.
1. استفاده از مدل کوچک‌تر
مثلاً:
به جای:
70B Model
استفاده از:
8B Model
نتیجه:
- سرعت بیشتر
- هزینه کمتر
اما کیفیت:
کمی پایین‌تر.
2. Quantization
مثلاً:
قبل:
FP16 Model
بعد:
INT8
یا
INT4
نتیجه:
VRAM کمتر
Inference سریع‌تر
هزینه کمتر
3. Router LLM
یکی از بهترین تکنیک‌ها:
همه سؤال‌ها را با مدل بزرگ جواب ندهیم.
معماری:
User
|
↓
Small Router LLM
|
-----------------
| |
Simple Complex
| |
Small LLM Large LLM
مثال:
سؤال ساده:
ساعت کاری شرکت؟
نیاز ندارد:
GPT بزرگ اجرا شود.
ولی:
تحلیل قرارداد 100 صفحه‌ای
ارسال شود به مدل قوی.
4. Caching
اگر کاربران سؤال‌های مشابه می‌پرسند:
به جای اجرای دوباره LLM:
از Cache استفاده کنیم.
مثال:
کاربر اول:
شرایط مرخصی چیست؟
LLM اجرا می‌شود.
ذخیره:
Question
+
Answer
کاربر دوم:
قوانین مرخصی چیه؟
سیستم:
Similarity Search
انجام می‌دهد.
اگر نزدیک بود:
Return Cached Answer
نتیجه:
Latency:
10s
↓
100ms
Semantic Cache
Cache ساده:
تطابق دقیق متن.
مثلاً:
What is refund policy?
با:
Explain refund rules
متفاوت است.
Semantic Cache:
ابتدا Embedding می‌سازد:
Question Vector
↓
Similarity
↓
Find Similar Question
Cache + Personalization
گاهی جواب Cache شده دقیق نیست.
راه بهتر:
Cached Answer
+
New User Prompt
|
↓
Small LLM
|
Personalized Answer
مثال:
Cache:
شرایط بیمه چیست؟
کاربر:
برای کارمند جدید چطور؟
یک LLM کوچک اصلاح می‌کند.
کاهش Latency در Componentهای دیگر
بعد از LLM:
بررسی کنیم:
- Query Rewrite
- Reranker
- Router
مثلاً:
Pipeline:
Query Rewrite
500ms
Retriever
50ms
Reranker
800ms
LLM
5000ms
مشکل اصلی:
LLM است.
اما اگر:
Reranker
+
500ms
+
1% quality improvement
داشته باشیم شاید ارزش نداشته باشد.
قاعده:
هر Component باید جواب بدهد:
چقدر کیفیت اضافه کردی؟
در مقابل چقدر زمان گرفتی؟
کاهش Latency در Vector Search
Vector Database معمولاً سریع است.
اما برای حجم خیلی بالا:
1. Binary Quantization
به جای:
32-bit float
استفاده از:
1-bit vector
نتیجه:
- محاسبات کمتر
- Search سریع‌تر
2. Sharding
تقسیم Database:
قبل:
1 Billion vectors
|
|
Search
بعد:
Shard 1
100M
Shard 2
100M
Shard 3
100M
جستجو موازی انجام می‌شود.
مثال یک معماری Production بهینه
حالت سریع:
User
↓
Small Router
↓
Vector Search
↓
Small LLM
↓
Answer
Latency:
کم
Quality:
خوب
حالت کیفیت بالا:
User
↓
Query Rewrite LLM
↓
Hybrid Search
↓
Reranker
↓
Large Reasoning LLM
↓
Citation Generator
↓
Answer
Latency:
زیاد
Quality:
بسیار بالا
چگونه تصمیم بگیریم؟
با Evaluation.
نه حدس.
اندازه‌گیری:
Latency
Quality
Cost
مثلاً تست:
نسخه A:
Without Reranker
Latency:
2s
Quality:
85%
نسخه B:
With Reranker
Latency:
4s
Quality:
92%
اگر کاربرد پزشکی باشد:
نسخه B بهتر است.
اگر Chatbot فروشگاه باشد:
نسخه A شاید بهتر باشد.
خلاصه نهایی
برای کاهش Latency در RAG:
| مشکل | راهکار |
|---|---|
| LLM کند است | مدل کوچک‌تر |
| VRAM کم | Quantization |
| سؤال‌ها مشابه‌اند | Semantic Cache |
| همه درخواست‌ها سخت نیستند | Router LLM |
| Reranker کند است | حذف یا مدل کوچک‌تر |
| Vector Search کند است | Binary Quantization |
| دیتابیس بزرگ است | Sharding |
اصل مهم:
در RAG Production هدف کمترین Latency یا بیشترین Quality نیست؛ هدف پیدا کردن نقطه تعادل بین سرعت، هزینه و کیفیت برای کاربرد واقعی است.