بعد از اینکه فهمیدیم چه Metricهایی باید جمع‌آوری کنیم، مرحله بعد این است که واقعاً سیستمی بسازیم که این اطلاعات را ثبت و تحلیل کند.
در Production، بدون Observability تقریباً نمی‌توان فهمید:
- چرا جواب اشتباه شد؟
- مشکل از Retriever بود یا LLM؟
- تغییر جدید بهتر شد یا بدتر؟
- هزینه سیستم چرا بالا رفت؟
1. پلتفرم‌های Observability برای RAG
برای سیستم‌های LLM-based ابزارهای آماده وجود دارد که کارهای زیر را انجام می‌دهند:
- جمع‌آوری Metricها
- ثبت درخواست‌ها
- Trace کردن مسیر درخواست
- اجرای Evaluation
- آزمایش تغییرات سیستم
مزیت استفاده از این ابزارها:
به جای ساختن سیستم مانیتورینگ از صفر، تمرکز روی:
- بهبود RAG
- آزمایش مدل‌ها
- افزایش کیفیت
می‌گذاریم.
2. نمونه ابزار: Phoenix
یکی از ابزارهای Open Source:
Phoenix توسط Arize
است.
کاربرد:
- Observability
- Evaluation
- Debugging
برای برنامه‌های:
- LLM
- RAG
- Agent
مهم‌ترین قابلیت Phoenix:
Trace
3. Trace چیست؟
Trace یعنی دنبال کردن کامل مسیر یک درخواست داخل RAG.
مثلاً:
کاربر:
How can I reset my password?
مسیر:
User Query
↓
Query Parser
↓
Retriever Query
↓
Vector Database
↓
Retrieved Chunks
↓
Re-ranker
↓
Final Prompt
↓
LLM
↓
Generated Answer
در Trace می‌توان دید:
1. Prompt اولیه
مثلاً:
How can I reset my password?
2. Query ارسال شده به Retriever
ممکن است تغییر کرده باشد:
password reset procedure
account recovery
3. Documents برگشتی
مثلاً:
doc12.pdf
doc45.pdf
doc80.pdf
4. Re-ranking
مثلاً:
قبل:
doc80
doc12
doc45
بعد:
doc12
doc45
doc80
5. Prompt نهایی LLM
شامل:
System Prompt
+
Retrieved Context
+
User Question
6. پاسخ نهایی
Your password can be reset from...
4. کاربرد Trace در Debug
فرض کنیم کاربر می‌گوید:
جواب اشتباه بود.
بدون Trace:
نمی‌دانیم مشکل چیست.
با Trace:
بررسی می‌کنیم:
حالت اول
Retriever خراب است:
Question
↓
Wrong Documents
↓
LLM جواب اشتباه
مشکل:
Retriever
حالت دوم
Retriever خوب است:
Question
↓
Correct Documents
↓
LLM ignores them
مشکل:
Prompt یا LLM
حالت سوم
Latency زیاد است:
Trace نشان می‌دهد:
Retriever:
100ms
Embedding:
50ms
LLM:
8 seconds
مشکل:
LLM
5. اتصال Evaluation به Observability
Phoenix می‌تواند با ابزارهایی مثل:
RAGAS
کار کند.
مثلاً:
Retriever Evaluation
بررسی:
- Search relevancy
- Precision
- Recall
LLM Evaluation
بررسی:
- Citation quality
- Faithfulness
- Response relevancy
مثلاً:
Question:
What is refund policy?
Retrieved:
refund_policy.pdf
Answer:
Refund available within 30 days
Faithfulness:
0.95
6. Experimentation
بعد از داشتن Evaluation می‌توانیم آزمایش کنیم.
مثلاً:
تغییر System Prompt
نسخه A:
Answer politely.
نسخه B:
Only answer using provided documents.
بعد مقایسه:
Before:
Faithfulness:
82%
After:
Faithfulness:
94%
یا:
اضافه کردن Re-ranker
قبل:
Recall:
80%
بعد:
Recall:
91%
7. A/B Testing
برای Production بسیار مهم است.
مثلاً:
کاربران تقسیم می‌شوند:
Users
|
----------------
| |
Version A Version B
GPT-4 Claude
بعد بررسی:
- رضایت کاربر
- زمان پاسخ
- هزینه
8. Aggregate Metrics
Trace برای جزئیات خوب است.
اما برای مدیریت کل سیستم نیاز به آمار کلی داریم.
مثلاً گزارش روزانه:
Daily Report
Requests:
120000
Average Latency:
2.1 sec
Retriever Recall:
88%
Hallucination Rate:
4%
User Satisfaction:
92%
9. محدودیت ابزارهای LLM Observability
ابزارهایی مثل Phoenix عالی هستند، اما همه چیز را پوشش نمی‌دهند.
مثلاً:
برای:
- CPU
- RAM
- GPU
- Disk
- Network
مناسب نیستند.
اینجا ابزارهای کلاسیک وارد می‌شوند:
Datadog
و
Grafana
معمولاً معماری Production:
RAG System
---------------------
| |
LLM Observability Infrastructure Monitoring
Phoenix Grafana
Traces CPU
RAGAS RAM
LLM Metrics GPU
10. چرخه بهبود Production
یک سیستم خوب یک چرخه دائمی دارد:
Real User Traffic
↓
Logging
↓
Analysis
↓
Find Problems
↓
Modify System
↓
Evaluate
↓
Deploy
این چرخه باعث می‌شود RAG به مرور بهتر شود.
11. Custom Evaluation Dataset
یکی از مهم‌ترین تکنیک‌ها:
ذخیره کردن Queryهای واقعی کاربران.
مثلاً:
کاربر قبلی پرسیده:
How do I cancel subscription?
ذخیره می‌کنیم:
{
question:
"How do I cancel subscription?",
retrieved_docs:
[
doc15,
doc20
],
answer:
"..."
}
بعد اگر تغییر دادیم:
- مدل LLM
- Embedding
- Prompt
- Retriever
همان Dataset را دوباره اجرا می‌کنیم.
مثلاً:
نسخه قدیمی:
Faithfulness:
90%
Latency:
2 sec
نسخه جدید:
Faithfulness:
95%
Latency:
3 sec
تصمیم‌گیری راحت‌تر می‌شود.
معماری پیشنهادی کامل Production RAG
User
↓
RAG API
↓
---------------------
| |
Retriever LLM
| |
| |
Trace + Logs + Metrics
↓
Observability
---------------------
| |
Phoenix Grafana
RAGAS Infra
نکات کلیدی درس
Trace مهم‌ترین ابزار Debug در RAG است.
فقط Metric کلی کافی نیست؛ باید مسیر تک تک درخواست‌ها را ببینی.
برای LLM از ابزارهایی مثل Phoenix و RAGAS استفاده کن.
برای زیرساخت از ابزارهایی مثل Grafana استفاده کن.
بهترین سیستم‌ها با داده واقعی کاربران دائماً بهبود پیدا می‌کنند.
در یک RAG Production واقعی، Observability همان چیزی است که تفاوت بین یک Demo ساده و یک سیستم قابل اعتماد تجاری را ایجاد می‌کند.