مدل‌های زبانی بزرگ معمولاً پاسخ‌هایی تولید می‌کنند که بسیار مطمئن، روان و حرفه‌ای به نظر می‌رسند.
مشکل اینجاست که «مطمئن به نظر رسیدن» الزاماً به معنی «درست بودن» نیست.
گاهی مدل ممکن است:
- یک منبع غیرواقعی معرفی کند
- عددی را از خودش بسازد
- ویژگی‌ای را به یک محصول نسبت دهد که وجود ندارد
- APIای پیشنهاد کند که هرگز ساخته نشده
- بخشی از اطلاعات درست را با اطلاعات نادرست ترکیب کند
- پاسخ کاملاً ساختگی را با لحن بسیار مطمئن ارائه دهد
به این پدیده معمولاً Hallucination گفته می‌شود.
به زبان ساده:
Hallucination یعنی مدل پاسخی تولید کند که از نظر زبانی طبیعی و قانع‌کننده است، اما از نظر واقعیت یا داده‌های موجود پشتوانه قابل اعتمادی ندارد.
این مسئله یکی از مهم‌ترین چالش‌های استفاده از LLMها در سیستم‌های واقعی است.
یک مثال ساده از Hallucination
فرض کنید از یک مدل سؤال کنیم:
در نسخه 4.2 محصول ما چه قابلیت‌هایی اضافه شده؟
اما مدل هیچ اطلاعاتی درباره محصول ما ندارد.
ممکن است به جای اینکه بگوید:
اطلاعات کافی ندارم.
پاسخی شبیه این تولید کند:
- در نسخه 4.2 قابلیت‌هایی مثل
- Real-time Analytics،
- Advanced Export
- و Role-based Dashboard
- اضافه شده‌اند.
پاسخ کاملاً طبیعی است.
مشکل فقط این است که شاید هیچ‌کدام از این قابلیت‌ها وجود نداشته باشند.
مدل در این حالت چیزی شبیه یک همکار بسیار خوش‌بیان است که پاسخ سؤال را نمی‌داند، اما بنا به دلایلی تصمیم گرفته جلسه را نجات دهد.
چرا Hallucination اتفاق می‌افتد؟
برای فهم این مسئله باید یک تصور اشتباه را کنار بگذاریم.
LLM معمولاً مانند Database اطلاعات را ذخیره و بازیابی نمی‌کند.
مدل در اصل تلاش می‌کند براساس Context و الگوهایی که آموخته، Token بعدی را پیش‌بینی کند.
به شکل بسیار ساده:
هدف اصلی مدل این نیست که:
حقیقت را از Database پیدا کند
بلکه تلاش می‌کند:
پاسخی محتمل و سازگار با Context تولید کند
این تفاوت بسیار مهم است.
مدل زبانی موتور جست‌وجو نیست
فرض کنید درباره یک موضوع بسیار خاص سؤال می‌کنیم.
اگر مدل اطلاعات کافی نداشته باشد، چند اتفاق ممکن است رخ دهد:
پاسخ ممکن است منطقی به نظر برسد، اما واقعیت نداشته باشد.
بنابراین نمی‌توان صرفاً به این دلیل که یک پاسخ خوب نوشته شده، آن را معتبر دانست.
انواع Hallucination
Hallucination فقط یک شکل ندارد.
در سیستم‌های واقعی می‌توان آن را به چند دسته تقسیم کرد.
1. ساختن Fact
مدل ممکن است اطلاعاتی تولید کند که وجود خارجی ندارند.
مثلاً:
شرکت X در سال 2017 تأسیس شده است.
در حالی که شرکت در سال دیگری تأسیس شده.
2. ساختن Source
گاهی مدل حتی منبع نیز تولید می‌کند.
مثلاً:
طبق مقاله Smith et al. 2023...
اما چنین مقاله‌ای اصلاً وجود ندارد.
این حالت در سیستم‌های Research بسیار خطرناک است.
3. ساختن API یا Library
در برنامه‌نویسی مدل ممکن است چیزی شبیه این پیشنهاد دهد:
client.enable_smart_cache()در حالی که چنین Methodای در Library وجود ندارد.
اسم Function آن‌قدر منطقی است که توسعه‌دهنده ممکن است چند دقیقه‌ای Documentation را متهم کند.
4. ترکیب اطلاعات درست و غلط
گاهی پاسخ کاملاً ساختگی نیست.
مثلاً مدل ممکن است:
- 80% اطلاعات درست
- +
- 20% اطلاعات اشتباه
تولید کند.
این نوع Hallucination خطرناک‌تر است، چون تشخیص آن سخت‌تر می‌شود.
5. Hallucination براساس Context
حتی وقتی اطلاعات به مدل داده شده باشند، ممکن است مدل آن‌ها را اشتباه تفسیر کند.
مثلاً Context می‌گوید:
بازپرداخت فقط برای پلن سالانه تا 7 روز ممکن است.
اما مدل پاسخ می‌دهد:
تمام کاربران تا 7 روز امکان بازپرداخت دارند.
اطلاعات وجود داشته، اما Generation اشتباه بوده است.
Hallucination فقط مشکل Training نیست
یک تصور رایج این است که اگر مدل بزرگ‌تر یا بهتر باشد، Hallucination کاملاً حل می‌شود.
مدل بهتر معمولاً می‌تواند مشکل را کاهش دهد.
اما مسئله فقط Model Quality نیست.
Hallucination می‌تواند از بخش‌های مختلف سیستم ایجاد شود:
هر کدام از این مراحل ممکن است باعث ایجاد یا تقویت خطا شوند.
مثال در یک سیستم RAG
فرض کنید یک RAG داریم.
کاربر سؤال می‌کند:
حداکثر زمان بازپرداخت چقدر است؟
اما Retrieval به جای سند مربوط به زمان بازپرداخت این Chunk را پیدا می‌کند:
برای درخواست بازپرداخت وارد پنل کاربری شوید.
سند مرتبط است، اما جواب سؤال را ندارد.
حالا LLM ممکن است:
حدس بزند
یا:
اطلاعات عمومی خودش را وارد پاسخ کند
در این حالت مشکل فقط مدل نیست.
Retrieval نیز بخشی از مشکل است.
RAG چگونه Hallucination را کاهش می‌دهد؟
یکی از مهم‌ترین روش‌های کاهش Hallucination استفاده از RAG است.
در RAG مدل به جای تکیه کامل بر دانشی که هنگام Training دیده، اطلاعات مرتبط را هنگام Query دریافت می‌کند.
معماری ساده:
مثلاً اگر کاربر سؤال کند:
شرایط لغو اشتراک چیست؟
سیستم ابتدا سند واقعی مربوط به Cancellation Policy را پیدا می‌کند.
سپس مدل براساس همان سند پاسخ تولید می‌کند.
اما RAG Hallucination را صفر نمی‌کند
این نکته بسیار مهم است.
RAG فقط احتمال دسترسی مدل به اطلاعات درست را افزایش می‌دهد.
اما همچنان ممکن است:
- Document اشتباه بازیابی شود
- Chunk ناقص باشد
- Document قدیمی باشد
- Context متناقض باشد
- مدل Context را اشتباه تفسیر کند
- مدل بخشی از پاسخ را از خودش اضافه کند
بنابراین:
RAG ≠ Hallucination Free
RAG فقط یکی از لایه‌های دفاع است.
Grounding چیست؟
مفهوم مهم بعدی Grounding است.
Grounding یعنی پاسخ مدل را به یک منبع مشخص و قابل اعتماد متصل کنیم.
مثلاً به مدل بگوییم:
فقط براساس Context زیر پاسخ بده.
اگر پاسخ در Context وجود ندارد،
اعلام کن اطلاعات کافی موجود نیست.Prompt می‌تواند چیزی شبیه این باشد:
You are an assistant answering questions
only using the provided context.
If the answer cannot be found in the context,
say that the information is unavailable.
Do not use external knowledge.در این حالت تلاش می‌کنیم فضای آزادی مدل را محدود کنیم.
RAG و Grounding چه تفاوتی دارند؟
این دو مفهوم نزدیک هستند، اما یکسان نیستند.
RAG می‌گوید:
اطلاعات مرتبط را پیدا کن.
Grounding می‌گوید:
پاسخ را به همین اطلاعات متصل نگه دار.
بنابراین می‌توان گفت:
اگر Retrieval خوب باشد ولی مدل اجازه داشته باشد آزادانه اطلاعات دیگری اضافه کند، Hallucination همچنان ممکن است رخ دهد.
Citation یکی از ابزارهای Grounding است
یکی از راه‌های افزایش اعتماد به پاسخ، ارائه منبع است.
مثلاً:
بازپرداخت تا 7 روز پس از خرید امکان‌پذیر است.
Source:
Refund Policy
Section 3این کار چند مزیت دارد:
- کاربر می‌تواند پاسخ را بررسی کند
- Debugging ساده‌تر می‌شود
- خطاهای Retrieval راحت‌تر دیده می‌شوند
- اعتماد به سیستم افزایش پیدا می‌کند
البته Citation نیز باید واقعاً به Source پاسخ اشاره کند.
نمایش یک لینک تصادفی زیر پاسخ، Grounding محسوب نمی‌شود. حتی اگر UI آن خیلی براق باشد.
Validation چیست؟
حتی اگر مدل پاسخ تولید کرد، لازم نیست بلافاصله آن را معتبر فرض کنیم.
می‌توان خروجی را قبل از استفاده Validate کرد.
مثلاً فرض کنید مدل باید این اطلاعات را استخراج کند:
{
"price": 125000,
"currency": "IRR"
}Backend می‌تواند بررسی کند:
- price باید عدد باشد
- currency باید یکی از مقادیر مجاز باشد
- price نباید منفی باشد
اگر Validation شکست خورد:
- Reject
- Retry
- Repair
- Fallback
انجام شود.
Validation چه چیزی را حل می‌کند؟
Validation بیشتر برای خطاهایی مناسب است که قابل بررسی هستند.
مثلاً:
- Type
- Format
- Range
- Required Fields
- Allowed Values
- Business Rules
اگر مدل بگوید:
{
"age": -42
}به راحتی قابل تشخیص است.
اما اگر بگوید:
{
"city": "Paris"
}و واقعاً ندانیم City درست چیست، Schema Validation کمکی نمی‌کند.
بنابراین Validation نیز فقط یک لایه است.
Structured Output چیست؟
یکی دیگر از ابزارهای مهم برای کنترل LLM استفاده از Structured Output است.
به جای اینکه مدل آزادانه متن تولید کند، از آن می‌خواهیم خروجی ساختار مشخصی داشته باشد.
مثلاً:
{
"answer": "",
"confidence": "",
"sources": []
}یا:
{
"intent": "refund",
"requires_human": false,
"document_ids": []
}این روش چند مزیت دارد:
- Parsing قابل اعتمادتر می‌شود
- Validation ساده‌تر می‌شود
- خروجی قابل استفاده برای Backend می‌شود
- رفتار مدل محدودتر می‌شود
Structured Output Hallucination را متوقف نمی‌کند
این نکته نیز مهم است.
Structured Output می‌تواند تضمین کند:
خروجی JSON باشد
اما تضمین نمی‌کند:
محتوای JSON درست باشد
مدل می‌تواند کاملاً معتبر بنویسد:
{
"refund_period": 30,
"source": "policy-v7"
}در حالی که مقدار واقعی 7 روز است.
بنابراین:
- Valid JSON
- ≠
- Valid Information
کامپیوترها عاشق این نوع تفاوت‌های کوچک و پرهزینه هستند.
Structured Output + Validation
ترکیب Structured Output و Validation بسیار قدرتمندتر است.
مثلاً:
اگر خروجی معتبر نباشد:
- Retry
- یا
- Human Review
انجام می‌شود.
Validation براساس Source
Validation فقط Schema نیست.
در بعضی سیستم‌ها می‌توان ادعاهای مدل را نیز بررسی کرد.
مثلاً مدل تولید می‌کند:
{
"answer": "بازپرداخت تا 7 روز امکان‌پذیر است.",
"source_id": "refund-policy-v3"
}سیستم می‌تواند بررسی کند:
آیا source_id واقعاً Retrieve شده؟
و حتی:
آیا Claim در Source وجود دارد؟
این نوع Validation می‌تواند کیفیت سیستم را افزایش دهد.
Retrieval Quality یکی از مهم‌ترین عوامل است
در یک RAG، اگر اطلاعات اشتباه به مدل بدهیم، انتظار پاسخ درست منطقی نیست.
فرض کنید Search پنج Document برگرداند:
- Document A - Relevant
- Document B - Old
- Document C - Unrelated
- Document D - Duplicate
- Document E - Relevant
این Context کیفیت خوبی ندارد.
بنابراین برای کاهش Hallucination باید Retrieval را نیز بهبود دهیم.
روش‌های بهبود Retrieval
چند تکنیک رایج عبارت‌اند از:
- Better Chunking
- Metadata Filtering
- Hybrid Search
- Reranking
- Query Rewriting
- Deduplication
هر کدام بخشی از مشکل را حل می‌کنند.
Metadata Filtering
فرض کنید دو Policy داریم:
- Policy 2024
- Policy 2026
اگر هر دو داخل Vector Database باشند، ممکن است نسخه قدیمی Retrieve شود.
می‌توان قبل از Search فیلتر اعمال کرد:
is_active = true
version = latestاین کار از ورود اطلاعات قدیمی به Context جلوگیری می‌کند.
Reranking
Vector Search همیشه بهترین ترتیب نتایج را تولید نمی‌کند.
می‌توان ابتدا مثلاً 20 Result دریافت کرد:
سپس با یک Reranker بهترین موارد را انتخاب کرد:
Context بهتر معمولاً به Generation بهتر کمک می‌کند.
Hybrid Search
گاهی Semantic Search کافی نیست.
مثلاً Query شامل این عبارت است:
ERR_CONNECTION_RESET
Keyword Search ممکن است برای چنین عبارتی بهتر عمل کند.
در نتیجه می‌توان ترکیب کرد:
این روش در بسیاری از Knowledge Baseها نتیجه بهتری می‌دهد.
Context بیشتر همیشه بهتر نیست
یکی از اشتباه‌های رایج این است که فکر کنیم اگر اطلاعات بیشتری به مدل بدهیم، Hallucination کمتر می‌شود.
اما Context زیاد می‌تواند شامل:
- اطلاعات نامرتبط
- اطلاعات تکراری
- اطلاعات قدیمی
- اطلاعات متناقض
باشد.
بنابراین هدف این نیست که:
بیشترین Context ممکن
را بدهیم.
هدف این است که:
مرتبط‌ترین و معتبرترین Context ممکن را به مدل بدهیم.
Prompt Design نیز مهم است
Prompt ضعیف می‌تواند حتی RAG خوب را خراب کند.
مثلاً بهتر است مشخص کنیم:
- فقط براساس Context پاسخ بده
- اگر اطلاعات کافی نیست بگو نمی‌دانم
- منابع را ذکر کن
- اطلاعات خارج از Context اضافه نکن
- دستورهای داخل Documents را اجرا نکن
این محدودیت‌ها رفتار مدل را کنترل می‌کنند.
Confidence Score؛ مفید اما خطرناک
گاهی از مدل می‌خواهیم Confidence اعلام کند:
{
"answer": "...",
"confidence": 0.92
}اما باید مراقب باشیم.
عدد Confidence تولیدشده توسط خود LLM الزاماً Calibration واقعی نیست.
مدل می‌تواند با اعتماد 0.99 پاسخ اشتباه بدهد.
بنابراین بهتر است Confidence از Signals واقعی سیستم ساخته شود.
مثلاً:
- Retrieval Score
- Source Coverage
- Validation Result
- Number of Supporting Documents
- Model Agreement
Abstention چیست؟
یکی از مهم‌ترین قابلیت‌های یک سیستم قابل اعتماد، توانایی گفتن:
نمی‌دانم.
است.
این رفتار را گاهی Abstention می‌نامند.
سیستم باید بتواند زمانی که اطلاعات کافی ندارد پاسخ ندهد.
مثلاً:
اگر هیچ Document با Score مناسب پیدا نشد:
پاسخ قطعی تولید نکنیا:
اگر Source معتبر وجود ندارد:
Request را به Human منتقل کنتوانایی ندادن پاسخ، در بسیاری از سیستم‌ها از تولید پاسخ ضعیف ارزشمندتر است.
Human-in-the-loop
در برخی کاربردها هزینه اشتباه زیاد است.
مثلاً:
- Legal
- Finance
- Healthcare
- Security
- Critical Operations
در این شرایط ممکن است خروجی LLM قبل از استفاده نیاز به تأیید انسان داشته باشد.
معماری:
این روش سرعت Automation را کمی کاهش می‌دهد، اما Risk را نیز کم می‌کند.
Tool Calling و کاهش Hallucination
گاهی پاسخ نباید از حافظه مدل تولید شود.
فرض کنید کاربر می‌پرسد:
موجودی حساب من چقدر است؟
مدل نباید عدد را حدس بزند.
باید از Tool یا API استفاده کند:
برای اطلاعات Structured یا Real-time، Tool Calling معمولاً از RAG مناسب‌تر است.
معماری چندلایه برای کاهش Hallucination
یک سیستم Production می‌تواند چند روش را همزمان استفاده کند.
مثلاً:
این معماری بسیار قابل اعتمادتر از:
است.
Guardrails چیست؟
به مجموعه محدودیت‌ها و کنترل‌هایی که روی ورودی و خروجی مدل قرار می‌دهیم معمولاً Guardrails گفته می‌شود.
Guardrail می‌تواند شامل موارد زیر باشد:
- Input Validation
- Output Schema
- Allowed Actions
- Content Policy
- Tool Permissions
- Business Rules
- Source Requirements
Guardrail نباید فقط در Prompt باشد.
بخش مهمی از آن بهتر است در Backend enforce شود.
قوانین مهم را به LLM نسپارید
فرض کنید قانون سیستم این است:
- Refund بیشتر از 5 میلیون تومان
- نیاز به تأیید مدیر دارد.
این Rule بهتر است در Code باشد:
if refund_amount > 5_000_000:
require_manager_approval()نه اینکه فقط در Prompt بنویسیم:
لطفاً یادت باشد...
مدل زبانی ابزار خوبی برای Reasoning و Generation است.
اما سیستم مجوزدهی سازمان نیست.
Hallucination در Agentها خطرناک‌تر می‌شود
در Chatbot ساده، Hallucination ممکن است فقط یک پاسخ اشتباه باشد.
اما در Agent ممکن است مدل Action انجام دهد.
مثلاً:
- ارسال Email
- حذف File
- تغییر Database
- ثبت Refund
- اجرای Command
در این حالت Hallucination می‌تواند اثر واقعی داشته باشد.
بنابراین باید بین:
Thinking
و:
Action
لایه Validation وجود داشته باشد.
قبل از Tool Call چه چیزی را Validate کنیم؟
مثلاً اگر مدل بخواهد Refund ثبت کند:
{
"action": "refund",
"order_id": 7421,
"amount": 2500000
}Backend باید بررسی کند:
- آیا Order وجود دارد؟
- آیا User مالک Order است؟
- آیا Refund قبلاً انجام نشده؟
- آیا Amount معتبر است؟
- آیا User Permission دارد؟
و فقط بعد Tool را اجرا کند.
Hallucination را چگونه اندازه‌گیری کنیم؟
اگر چیزی را اندازه‌گیری نکنیم، کاهش آن نیز بیشتر شبیه امیدواری است تا Engineering.
برای Evaluation می‌توان Dataset ساخت:
- Question
- Expected Source
- Expected Answer
- Allowed Variations
بعد بررسی کنیم:
- Answer Correctness
- Faithfulness
- Citation Accuracy
- Retrieval Accuracy
- Unsupported Claims
Faithfulness چیست؟
یکی از معیارهای مهم در RAG این است که پاسخ چقدر به Context وفادار است.
مثلاً Context:
ارسال تهران 1 تا 2 روز طول می‌کشد.
پاسخ:
ارسال تهران معمولاً 1 تا 2 روز کاری است.
Faithful است.
اما اگر مدل اضافه کند:
ارسال رایگان نیز خواهد بود.
این Claim در Context وجود ندارد.
پس پاسخ کاملاً Grounded نیست.
Hallucination Rate
می‌توان درصد پاسخ‌هایی که شامل Claim بدون پشتیبانی هستند اندازه‌گیری کرد.
مثلاً:
البته تعریف دقیق Metric باید متناسب با Use Case باشد.
Evaluation باید روی داده واقعی انجام شود
چند سؤال دستی کافی نیست.
بهتر است Queryهای واقعی کاربران جمع‌آوری شوند.
مثلاً:
- سؤال ساده
- سؤال مبهم
- سؤال بدون جواب
- سؤال با اطلاعات متناقض
- سؤال درباره نسخه قدیمی
- سؤال خارج از Domain
این Dataset به مرور تبدیل به Regression Test سیستم AI می‌شود.
یک Pipeline عملی
فرض کنیم یک Documentation Assistant می‌سازیم.
Pipeline می‌تواند این باشد:
Structured Output:
{
"answer": "...",
"sources": [
{
"document_id": "docs-42",
"section": "Authentication"
}
],
"requires_human": false
}Backend بررسی می‌کند Sourceهایی که مدل اعلام کرده واقعاً جزو Documents بازیابی‌شده باشند.
اگر اطلاعات کافی نبود چه کنیم؟
فرض کنید Search نتیجه قابل اعتمادی پیدا نکرد.
بدترین گزینه این است که مدل را مجبور کنیم حتماً پاسخ تولید کند.
بهتر است:
مثلاً:
در منابع موجود اطلاعات کافی برای پاسخ دقیق پیدا نکردم.
یا:
این سؤال نیاز به بررسی کارشناس دارد.
در بعضی پروژه‌ها بهترین پاسخ AI واقعاً همین است.
یک Strategy ساده برای Production
برای بسیاری از پروژه‌ها می‌توان از این ترتیب شروع کرد:
- 1. Prompt خوب
- 2. RAG یا Tool مناسب
- 3. Grounding
- 4. Structured Output
- 5. Validation
- 6. Citation
- 7. Evaluation
- 8. Human Fallback
بعد براساس داده واقعی سیستم را پیچیده‌تر کرد.
آیا Fine-tuning Hallucination را حل می‌کند؟
نه لزوماً.
Fine-tuning می‌تواند رفتار مدل را برای Task مشخص بهتر کند.
اما جایگزین Source معتبر نیست.
اگر اطلاعات پروژه دائماً تغییر می‌کنند، Fine-tuning به تنهایی نمی‌تواند تضمین کند مدل آخرین نسخه اطلاعات را می‌داند.
در این شرایط معمولاً ترکیبی از:
- Fine-tuning
- +
- RAG
یا:
- Fine-tuning
- +
- Tools
منطقی‌تر است.
چهار سؤال قبل از اعتماد به پاسخ مدل
برای هر سیستم LLM می‌توان این چهار سؤال را پرسید:
1. مدل اطلاعات را از کجا آورده؟
- Source?
- RAG?
- API?
- Database?
- Model Memory?
2. آیا پاسخ به Source متصل است؟
- Grounding
- Citation
3. آیا خروجی بررسی شده؟
- Validation
- Business Rules
- Schema
4. اگر مدل نداند چه اتفاقی می‌افتد؟
- Abstention
- Fallback
- Human Review
اگر پاسخ این چهار سؤال مشخص نباشد، احتمالاً معماری هنوز جای کار دارد.
جمع‌بندی
Hallucination یکی از ویژگی‌های مهم سیستم‌های مبتنی بر LLM است که باید از ابتدا در معماری در نظر گرفته شود.
مدل ممکن است پاسخی تولید کند که:
- روان است
- منطقی است
- مطمئن است
- اما درست نیست
هیچ تکنیک واحدی Hallucination را کاملاً حذف نمی‌کند.
راه‌حل عملی معمولاً چندلایه است:
در نتیجه هدف واقعی این نیست که:
مدل هیچ‌وقت اشتباه نکند.
هدف این است که سیستمی بسازیم که:
- احتمال اشتباه را کاهش دهد
- خطا را تشخیص دهد
- از پاسخ بدون پشتوانه جلوگیری کند
- منبع پاسخ را مشخص کند
- و در صورت نبود اطلاعات، بتواند پاسخ ندهد
LLM به تنهایی یک سیستم قابل اعتماد نیست.
اما LLM همراه با Retrieval، Grounding، Validation، Structured Output و Guardrails می‌تواند به بخشی قابل کنترل‌تر از یک معماری واقعی تبدیل شود.
تفاوت بین یک Demo جذاب و یک سیستم Production معمولاً دقیقاً همین‌جاست.