آموزش و راهنما

توهم هوش مصنوعی چیست؟ آموزش تشخیص و کاهش Hallucination در مدل‌های زبانی

هوش مصنوعی زمانی رخ می‌دهد که مدل پاسخی روان اما نادرست یا بدون منبع تولید کند. در این راهنما، انواع Hallucination، روش‌های تشخیص و راهکارهای عملی کاهش آن با RAG، ارزیابی و کدنویسی را یاد می‌گیرید.

مدل‌های زبانی می‌توانند متن‌هایی بسیار روان، منظم و قانع‌کننده تولید کنند؛ اما روان بودن پاسخ به‌معنای درست بودن آن نیست. گاهی مدل نام یک کتاب، آمار، تاریخ، قابلیت نرم‌افزار، نقل‌قول یا حتی یک منبع را با اطمینان تولید می‌کند، در حالی که آن اطلاعات وجود خارجی ندارند یا با واقعیت سازگار نیستند.

به این پدیده «توهم هوش مصنوعی» یا AI Hallucination گفته می‌شود. توهم یکی از مهم‌ترین محدودیت‌های مدل‌های زبانی بزرگ یا LLMهاست و در طراحی چت‌بات، دستیار سازمانی، موتور جست‌وجوی هوشمند، سیستم RAG و اپلیکیشن‌های متصل به API باید جدی گرفته شود.

در این مقاله ابتدا مفهوم توهم هوش مصنوعی را توضیح می‌دهیم، سپس انواع و دلایل آن را بررسی می‌کنیم و در نهایت یک روش عملی و چندلایه برای کاهش Hallucination در برنامه‌های واقعی پیاده‌سازی خواهیم کرد.

توهم هوش مصنوعی چیست؟

توهم هوش مصنوعی زمانی رخ می‌دهد که یک مدل محتوایی تولید کند که:

از نظر واقعی نادرست است.
در منابع ارائه‌شده وجود ندارد.
با Context یا اطلاعات ورودی تناقض دارد.
شامل جزئیات ساختگی است.
منبع یا استناد غیرواقعی ارائه می‌دهد.
درباره موضوعی نامطمئن، با قطعیت بیش از حد صحبت می‌کند.
بخشی از اطلاعات صحیح را با نتیجه‌گیری نادرست ترکیب می‌کند.

برای مثال، ممکن است از مدل بخواهید مقاله‌ای علمی را خلاصه کند و مدل نام بخشی را بیاورد که اصلاً در مقاله وجود ندارد. یا ممکن است درباره قابلیت یک نرم‌افزار توضیح دهد و دستوری تولید کند که معتبر نیست.

توهم الزاماً به‌معنای دروغ‌گویی آگاهانه نیست. مدل زبانی قصد، آگاهی و درک انسانی از حقیقت ندارد؛ بلکه براساس ورودی و الگوهای آموخته‌شده، توکن بعدی را پیش‌بینی می‌کند.

پاسخ زیر نمونه‌ای از توهم است:

سؤال:
نویسنده مقاله X در سال ۲۰۲۵ چه نتیجه‌ای گرفته است؟

پاسخ مدل:
این مقاله توسط سه پژوهشگر دانشگاه Y منتشر شده و نتیجه گرفته است که روش Z دقت را ۴۲ درصد افزایش می‌دهد.

اگر مقاله، نویسندگان، دانشگاه یا عدد ۴۲ درصد در منبع وجود نداشته باشند، مدل اطلاعاتی ظاهراً دقیق اما ساختگی تولید کرده است.

تفاوت توهم با پاسخ ضعیف چیست؟

هر پاسخ اشتباه لزوماً Hallucination نیست.

مدل ممکن است:

سؤال را اشتباه تفسیر کند.
محاسبه را نادرست انجام دهد.
دستور کاربر را ناقص اجرا کند.
پاسخ بیش از حد کلی ارائه دهد.
اطلاعات قدیمی داشته باشد.
به‌دلیل کمبود Context پاسخ نامرتبط تولید کند.

توهم بیشتر به تولید ادعاهایی اشاره دارد که فاقد پشتیبانی معتبرند یا برخلاف منبع و واقعیت ارائه می‌شوند.

در عمل، مرز میان توهم، خطای استدلالی و اطلاعات قدیمی همیشه کاملاً مشخص نیست. به همین دلیل بهتر است در محصول واقعی، همه آن‌ها را زیر مفهوم گسترده‌تر «قابلیت اعتماد پاسخ» ارزیابی کنیم.

چرا پاسخ توهم‌آمیز قانع‌کننده به نظر می‌رسد؟

مدل‌های زبانی برای تولید دنباله‌ای محتمل و منسجم از کلمات آموزش دیده‌اند. این هدف با «تشخیص قطعی حقیقت» یکسان نیست.

مدل ممکن است الگوهای زیر را به‌خوبی یاد گرفته باشد:

شکل ظاهری یک مقاله علمی
نحوه نوشتن Citation
قالب یک URL
ساختار پاسخ تخصصی
لحن رسمی و مطمئن
الگوی نام‌گذاری کتاب، شرکت یا نرم‌افزار
نحوه نمایش عدد، تاریخ یا آمار

اگر اطلاعات دقیق در دسترس مدل نباشد، ممکن است براساس همین الگوها جزئیاتی تولید کند که از نظر زبانی طبیعی‌اند، اما از نظر واقعی وجود ندارند.

به همین دلیل، نشانه‌هایی مانند لحن حرفه‌ای، طولانی بودن پاسخ، استفاده از اصطلاحات تخصصی یا وجود چند Citation ظاهری، صحت محتوا را تضمین نمی‌کنند.

انواع توهم در مدل‌های زبانی

شناخت نوع Hallucination کمک می‌کند راهکار مناسب‌تری برای کاهش آن انتخاب کنیم.

توهم واقعی یا Factual Hallucination

مدل ادعایی درباره جهان واقعی تولید می‌کند که نادرست یا بدون پشتوانه است.

مثال:

شرکت X در سال ۲۰۱۸ تأسیس شده است.

در حالی که شرکت در سال دیگری تأسیس شده یا اصلاً وجود ندارد.

توهم درون‌متنی یا Intrinsic Hallucination

پاسخ مدل با Context ارائه‌شده تناقض دارد.

Context:

نسخه آزمایشی محصول در مهرماه منتشر شد.

پاسخ مدل:

نسخه آزمایشی محصول در شهریورماه منتشر شد.

مدل به اطلاعاتی دسترسی داشته اما آن را به‌درستی حفظ نکرده است.

توهم برون‌متنی یا Extrinsic Hallucination

مدل اطلاعاتی اضافه می‌کند که در Context وجود ندارد و امکان تأیید آن از روی منبع داده‌شده وجود ندارد.

Context:

محصول در مهرماه منتشر شد.

پاسخ مدل:

محصول در مهرماه منتشر شد و در ماه اول ۵۰ هزار کاربر جذب کرد.

عدد ۵۰ هزار ممکن است درست یا نادرست باشد؛ اما از Context قابل‌اثبات نیست.

توهم Citation و منبع

مدل ممکن است موارد زیر را جعل کند:

عنوان مقاله
نام نویسنده
DOI
لینک
شماره صفحه
نقل‌قول مستقیم
نام استاندارد یا گزارش
تاریخ انتشار

این نوع توهم خطرناک است، زیرا وجود یک Citation ظاهری باعث افزایش اعتماد کاربر می‌شود.

توهم عددی

مدل اعداد را اشتباه ترکیب یا تولید می‌کند:

درصد رشد
قیمت
تاریخ
تعداد کاربران
نرخ تبدیل
نتیجه Benchmark
جمع و تفریق
واحد پول
حجم داده

خطای کوچک در ممیز، واحد یا بازه زمانی می‌تواند نتیجه را کاملاً تغییر دهد.

توهم زمانی

مدل اطلاعات مربوط به زمان‌های مختلف را با یکدیگر ترکیب می‌کند یا اطلاعات قدیمی را به‌عنوان وضعیت فعلی ارائه می‌دهد.

نمونه‌ها:

معرفی نسخه قدیمی به‌عنوان آخرین نسخه
اعلام قیمت منسوخ‌شده
نسبت دادن یک سمت سازمانی قدیمی به فرد
استفاده از مستندات نسخه قبلی یک Library

توهم موجودیت

نام افراد، شرکت‌ها، محصولات، مدل‌ها یا مکان‌ها با یکدیگر ترکیب می‌شوند.

برای مثال، مدل ممکن است قابلیت یک محصول را به محصول دیگری نسبت دهد یا دو مدل دارای نام مشابه را یکی فرض کند.

توهم کدنویسی

در پاسخ‌های برنامه‌نویسی، Hallucination می‌تواند به شکل‌های زیر ظاهر شود:

معرفی Package غیرواقعی
استفاده از متد حذف‌شده
ساختن Option نامعتبر
Import از مسیر اشتباه
ترکیب API دو نسخه مختلف
استفاده از پارامتر پشتیبانی‌نشده
تولید کدی که از نظر Syntax درست اما از نظر Runtime اشتباه است
ادعای پشتیبانی یک مدل از قابلیتی که واقعاً ندارد

توهم در سیستم RAG

حتی اگر از Retrieval-Augmented Generation استفاده شود، توهم کاملاً حذف نمی‌شود. مدل ممکن است:

سند نامرتبط دریافت کند.
بخش اشتباه سند را تفسیر کند.
چند منبع متناقض را ترکیب کند.
اطلاعاتی خارج از منابع اضافه کند.
Citation را به بخش اشتباه نسبت دهد.
از سند قدیمی استفاده کند.
پاسخ درست را از میان Chunkهای ناقص پیدا نکند.

بنابراین RAG یک راهکار مهم برای کاهش توهم است، اما تضمین‌کننده صحت کامل پاسخ نیست.

چرا مدل‌های زبانی دچار توهم می‌شوند؟

Hallucination معمولاً حاصل یک عامل واحد نیست و می‌تواند از ترکیب مدل، داده، Prompt، Retrieval و معماری برنامه ایجاد شود.

ماهیت احتمالاتی تولید متن

مدل زبانی در هر مرحله، احتمال توکن‌های بعدی را محاسبه می‌کند. خروجی براساس احتمال زبانی تولید می‌شود، نه براساس یک موتور داخلی قطعی برای Fact Checking.

ناقص یا متناقض بودن داده آموزشی

داده‌های آموزشی ممکن است:

ناقص باشند.
اطلاعات اشتباه داشته باشند.
شامل دیدگاه‌های متناقض باشند.
مربوط به زمان‌های مختلف باشند.
برخی موضوعات را کمتر پوشش داده باشند.

قدیمی بودن دانش مدل

مدل ممکن است به آخرین اطلاعات دسترسی نداشته باشد. پرسیدن قیمت فعلی، آخرین نسخه نرم‌افزار یا وضعیت امروز بدون Retrieval یا ابزار مناسب، ریسک پاسخ قدیمی یا ساختگی را افزایش می‌دهد.

Prompt مبهم

این Prompt مبهم است:

درباره این محصول توضیح بده.

مشخص نیست منظور کدام نسخه، کدام منبع، چه بازه زمانی و چه سطحی از جزئیات است.

Prompt دقیق‌تر:

فقط براساس متن مستندات پیوست‌شده، قابلیت‌های نسخه ذکرشده را در پنج مورد خلاصه کن. اگر قابلیتی در منبع وجود ندارد، آن را اضافه نکن.

درخواست جزئیات بیش از حد

اگر از مدل بخواهید برای موضوعی ناشناخته، ده‌ها نام، آمار، منبع و تاریخ تولید کند، احتمال ساخت جزئیات افزایش می‌یابد.

Context ناکافی

ممکن است پاسخ در اسناد داخلی موجود باشد، اما سند یا Chunk درست به مدل داده نشده باشد. مدل برای پر کردن شکاف اطلاعاتی از الگوهای احتمالی استفاده می‌کند.

Context بیش از حد طولانی

قرار دادن حجم بزرگی از اطلاعات بدون ساختار نیز مشکل‌ساز است. ممکن است بخش مهم در میان داده‌های زیاد گم شود یا منابع متناقض به مدل داده شوند.

Retrieval نامناسب

در RAG، پاسخ نهایی به کیفیت Retrieval وابسته است. مشکلات متداول عبارت‌اند از:

Chunking نامناسب
Embedding نامتناسب
نبود Hybrid Search
تعداد نامناسب نتایج
نبود Reranking
Metadata ناقص
وجود اسناد تکراری
استفاده از نسخه قدیمی سند

تنظیمات Sampling

افزایش temperature معمولاً تنوع خروجی را بیشتر می‌کند. برای کارهای واقع‌محور، مقدار پایین‌تر اغلب خروجی باثبات‌تری ایجاد می‌کند؛ اما Temperature پایین، صحت پاسخ را تضمین نمی‌کند.

مدل می‌تواند یک پاسخ نادرست را با Temperature صفر نیز به‌صورت پایدار تکرار کند.

خطای ابزار یا Tool

اگر Agent از Search، Database، Calculator یا API استفاده کند، Hallucination ممکن است از این نقاط وارد شود:

ابزار نتیجه اشتباه برگرداند.
مدل ورودی ابزار را نادرست بسازد.
پاسخ ابزار ناقص باشد.
مدل خروجی ابزار را اشتباه تفسیر کند.
Timeout به‌عنوان پاسخ خالی مدیریت نشود.
نتیجه ابزار با داده قبلی ترکیب شود.

آیا می‌توان توهم هوش مصنوعی را کاملاً حذف کرد؟

در سیستم‌های زایشی عمومی، حذف کامل Hallucination معمولاً هدف واقع‌بینانه‌ای نیست. هدف بهتر، کاهش احتمال خطا، تشخیص پاسخ‌های مشکوک و محدود کردن اثر آن‌هاست.

یک معماری قابل‌اعتماد باید سه قابلیت داشته باشد:

پیشگیری: احتمال ایجاد ادعای بی‌پشتوانه را کاهش دهد.
تشخیص: پاسخ مشکوک یا بدون منبع را شناسایی کند.
کنترل اثر: از استفاده خودکار پاسخ تأییدنشده در عملیات مهم جلوگیری کند.

هیچ روش واحدی برای تمام کاربردها کافی نیست. معمولاً باید چند لایه دفاعی هم‌زمان استفاده شود.

روش اول: محدود کردن دامنه پاسخ

به مدل دقیقاً بگویید از چه منابعی اجازه پاسخ‌گویی دارد:

فقط براساس Context ارائه‌شده پاسخ بده.

اگر پاسخ در Context وجود ندارد، دقیقاً بنویس:
«اطلاعات کافی در منابع ارائه‌شده وجود ندارد.»

هیچ نام، عدد، تاریخ، قابلیت یا منبعی را حدس نزن.

این دستور تضمین کامل ایجاد نمی‌کند، اما مرز پاسخ را روشن‌تر می‌کند.

نمونه System Prompt:

شما یک دستیار پاسخ‌گویی مبتنی بر اسناد هستید.

قواعد:
1. فقط از اطلاعات داخل بخش SOURCES استفاده کن.
2. هر ادعای واقعی باید حداقل یک Source ID داشته باشد.
3. اگر منابع کافی نیستند، صریحاً اعلام کن.
4. میان اطلاعات قطعی، استنباط و پیشنهاد تفاوت بگذار.
5. از ساختن نام، عدد، تاریخ، URL و Citation خودداری کن.
6. اگر منابع با یکدیگر تناقض دارند، تناقض را گزارش کن.

روش دوم: اجازه دادن به مدل برای اعلام ندانستن

بسیاری از Promptها به‌طور ناخواسته مدل را مجبور به پاسخ می‌کنند:

حتماً یک پاسخ کامل بده.

برای کاهش Hallucination باید گزینه عدم پاسخ نیز وجود داشته باشد:

اگر شواهد کافی وجود ندارد، پاسخ قطعی نده و بگو چه اطلاعاتی برای پاسخ لازم است.

خروجی مطلوب می‌تواند چنین باشد:

براساس منابع ارائه‌شده نمی‌توان تاریخ دقیق انتشار را تعیین کرد. برای پاسخ قطعی به صفحه Release Notes یا گزارش رسمی انتشار نیاز است.

این پاسخ از یک تاریخ ساختگی مفیدتر است.

روش سوم: استفاده از RAG

RAG اطلاعات مرتبط را پیش از تولید پاسخ بازیابی کرده و همراه سؤال در اختیار مدل قرار می‌دهد.

جریان ساده RAG:

سؤال کاربر
    ↓
بازیابی اسناد مرتبط
    ↓
انتخاب و رتبه‌بندی Chunkها
    ↓
ارسال Context به مدل
    ↓
تولید پاسخ همراه Citation

مقاله اصلی RAG نشان داد ترکیب حافظه پارامتریک مدل با منابع خارجی بازیابی‌شده می‌تواند در کارهای دانش‌محور، خروجی دقیق‌تر و واقع‌محورتری نسبت به مدل صرفاً پارامتریک تولید کند. جزئیات این پژوهش در مقاله Retrieval-Augmented Generation در NeurIPS منتشر شده است.

RAG برای داده‌های زیر مناسب است:

مستندات محصول
دانش‌نامه سازمانی
مقاله‌ها
راهنماهای داخلی
اطلاعات محصولات
FAQ
محتوای سایت
داده‌های دارای تاریخ بروزرسانی
مستندات فنی نسخه‌بندی‌شده

اصول RAG برای کاهش توهم

صرفاً قراردادن چند متن در Prompt کافی نیست. یک RAG قابل‌اعتماد باید این موارد را رعایت کند:

Chunk مناسب

Chunk باید آن‌قدر کامل باشد که مفهوم را منتقل کند و آن‌قدر کوچک باشد که Retrieval دقیق باقی بماند.

نگهداری Metadata

برای هر Chunk اطلاعات زیر را نگه دارید:

{
  "source_id": "DOC-104",
  "title": "راهنمای تنظیمات مدل",
  "version": "3.2",
  "updated_at": "2026-07-20",
  "url": "https://example.com/docs/model-settings",
  "section": "Temperature"
}

حذف نسخه‌های قدیمی

اگر چند نسخه از یک سند وجود دارد، مدل ممکن است آن‌ها را ترکیب کند. وضعیت نسخه باید در Metadata مشخص باشد.

استفاده از Hybrid Search

ترکیب جست‌وجوی معنایی و جست‌وجوی واژه‌ای برای عبارت‌های دقیق، Model ID، کد خطا، نام قابلیت و عدد مفید است.

استفاده از Reranker

Reranker می‌تواند نتایج اولیه را دوباره براساس ارتباط با سؤال مرتب کند و Chunkهای مرتبط‌تر را در Context نهایی قرار دهد.

تعیین حداقل امتیاز ارتباط

اگر هیچ سندی امتیاز کافی ندارد، بهتر است سیستم پاسخ دهد «منبع کافی پیدا نشد» و سؤال را به مدل بدون Context مناسب ارسال نکند.

روش چهارم: الزام Citation قابل‌بررسی

به‌جای درخواست «منبع بده»، Source IDهای مشخص را به مدل ارائه کنید:

[SOURCE: DOC-101]
درواره یک زیرساخت API برای اتصال نرم‌افزارها به مدل‌های هوش مصنوعی است.

[SOURCE: DOC-102]
آدرس پایه API برابر با https://api.darvareh.ir/v1 است.

سپس قالب پاسخ را مشخص کنید:

هر ادعای واقعی را با Source ID مرتبط بنویس.

نمونه:
آدرس پایه API درواره برابر با ... است. [DOC-102]

فقط از Source IDهای موجود استفاده کن.

بعد از دریافت پاسخ، Citationها را در برنامه بررسی کنید:

آیا Source ID واقعاً وجود دارد؟
آیا Citation به سندی از Retrieval جاری اشاره می‌کند؟
آیا ادعا واقعاً در همان سند پشتیبانی می‌شود؟
آیا URL از Metadata سیستم آمده یا مدل آن را ساخته است؟

مدل نباید URL منابع را از حافظه تولید کند. برنامه باید براساس Source ID، لینک معتبر را از Database یا Metadata اضافه کند.

روش پنجم: خروجی ساختاریافته

خروجی JSON امکان بررسی برنامه‌نویسی‌شده پاسخ را فراهم می‌کند:

{
  "answer": "متن پاسخ",
  "claims": [
    {
      "text": "ادعای اول",
      "source_ids": ["DOC-101"],
      "confidence": "high"
    }
  ],
  "insufficient_evidence": false
}

Schema پیشنهادی:

{
  "type": "object",
  "properties": {
    "answer": {
      "type": "string"
    },
    "claims": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "text": {
            "type": "string"
          },
          "source_ids": {
            "type": "array",
            "items": {
              "type": "string"
            }
          },
          "confidence": {
            "type": "string",
            "enum": [
              "high",
              "medium",
              "low"
            ]
          }
        },
        "required": [
          "text",
          "source_ids",
          "confidence"
        ],
        "additionalProperties": false
      }
    },
    "insufficient_evidence": {
      "type": "boolean"
    }
  },
  "required": [
    "answer",
    "claims",
    "insufficient_evidence"
  ],
  "additionalProperties": false
}

Structured Output جلوی تمام خطاهای واقعی را نمی‌گیرد. ممکن است JSON کاملاً معتبر باشد اما ادعای داخل آن نادرست باشد. مزیت آن این است که برنامه می‌تواند قواعدی مانند وجود Citation، مقدار Confidence و نبود فیلد اضافی را بررسی کند.

روش ششم: استخراج و بررسی ادعاهای اتمی

یک پاسخ طولانی ممکن است هم‌زمان شامل اطلاعات صحیح و نادرست باشد. ارزیابی کل پاسخ با یک برچسب «درست» یا «غلط» کافی نیست.

راه بهتر:

پاسخ را به ادعاهای مستقل تقسیم کنید.
هر ادعا را جداگانه بررسی کنید.
منبع پشتیبان هر ادعا را پیدا کنید.
وضعیت ادعا را مشخص کنید.
ادعاهای بدون پشتیبانی را حذف یا بازنویسی کنید.

نمونه پاسخ:

محصول در سال ۲۰۲۴ منتشر شد، در ماه اول ۲۰ هزار کاربر جذب کرد و نسخه موبایل آن در تابستان عرضه شد.

این جمله حداقل سه ادعای مستقل دارد:

ادعای ۱: محصول در سال ۲۰۲۴ منتشر شد.
ادعای ۲: محصول در ماه اول ۲۰ هزار کاربر جذب کرد.
ادعای ۳: نسخه موبایل در تابستان عرضه شد.

ممکن است فقط ادعای اول در منبع وجود داشته باشد.

روش FActScore نیز متن بلند را به Factهای اتمی تقسیم و درصد Factهای پشتیبانی‌شده توسط منبع معتبر را ارزیابی می‌کند. توضیحات این روش در مقاله FActScore در ACL Anthology در دسترس است.

یک معیار ساده برای پروژه:

دقت واقعی پاسخ =
تعداد ادعاهای پشتیبانی‌شده
تقسیم بر
تعداد کل ادعاهای قابل‌بررسی
ضرب‌در ۱۰۰

اگر پاسخ ۱۰ ادعای قابل‌بررسی داشته باشد و ۸ ادعا توسط منابع تأیید شوند:

Factual Precision = 8 / 10 × 100 = 80%

این فرمول با ادیتور Ghost سازگار است و به LaTeX نیاز ندارد.

روش هفتم: بررسی سازگاری چند پاسخ

یکی از روش‌های تشخیص توهم، تولید چند پاسخ مستقل برای یک سؤال و مقایسه آن‌هاست.

اگر مدل درباره یک Fact مطمئن باشد، پاسخ‌های مختلف معمولاً سازگاری بیشتری دارند. اگر در هر بار پاسخ، نام، تاریخ یا عدد متفاوتی ارائه شود، احتمال نامطمئن بودن محتوا بیشتر است.

ایده SelfCheckGPT بر همین مبناست: نمونه‌های متعدد از پاسخ مدل تولید می‌شوند و ناسازگاری میان آن‌ها به‌عنوان نشانه احتمالی Hallucination بررسی می‌شود. این روش در مقاله SelfCheckGPT در EMNLP ارائه شده است.

این روش محدودیت‌هایی نیز دارد:

هزینه و Latency را افزایش می‌دهد.
مدل ممکن است یک اشتباه را به‌طور پایدار تکرار کند.
سازگاری به‌تنهایی اثبات‌کننده حقیقت نیست.
برای پاسخ‌های خلاقانه تنوع طبیعی است.
بررسی منابع خارجی همچنان ارزشمندتر است.

بنابراین Self-Consistency یک سیگنال است، نه مدرک قطعی.

روش هشتم: استفاده از ابزارهای قطعی

برای برخی عملیات بهتر است به‌جای تکیه بر حافظه یا استدلال آزاد مدل، از ابزار مناسب استفاده شود:

نوع سؤال	ابزار مناسب
محاسبه عددی	Calculator یا کد
اطلاعات Database	Query کنترل‌شده
قیمت یا وضعیت لحظه‌ای	API معتبر
محتوای داخلی	RAG
تاریخ و زمان	ابزار Date/Time
اطلاعات محصول	Catalog API
وضعیت سفارش	Backend سازمان
وجود فایل	File Storage API

مدل باید وظیفه تشخیص نیاز به ابزار و تفسیر نتیجه را انجام دهد، اما داده واقعی از منبع قطعی دریافت شود.

روش نهم: استفاده از مدل مناسب

تمام مدل‌ها در Factuality، Reasoning، زبان فارسی، Context Length، Tool Calling و Structured Output عملکرد یکسانی ندارند.

برای انتخاب مدل، فقط به معروف بودن یا اندازه مدل توجه نکنید. مدل را روی داده واقعی پروژه ارزیابی کنید:

چند سؤال واقعی جمع‌آوری کنید.
پاسخ مرجع تهیه کنید.
ادعاهای قابل‌بررسی را مشخص کنید.
چند مدل را با تنظیمات یکسان اجرا کنید.
صحت، هزینه و سرعت را مقایسه کنید.
نرخ عدم پاسخ صحیح را نیز اندازه بگیرید.
عملکرد مدل در زبان فارسی را جداگانه بررسی کنید.

برای مشاهده مدل‌ها و Model IDهای قابل‌استفاده، به صفحه مدل‌های درواره مراجعه کنید.

روش دهم: کاهش Temperature با انتظار واقع‌بینانه

برای پاسخ‌های واقع‌محور می‌توانید Temperature پایین‌تری انتخاب کنید:

{
  "temperature": 0.1
}

برای تولید خلاقانه ممکن است مقدار بالاتر مناسب باشد:

{
  "temperature": 0.8
}

اما این قاعده مطلق نیست. Temperature پایین‌تر معمولاً تنوع را کم می‌کند، نه اینکه یک Fact Checker به مدل اضافه کند.

اگر دانش مدل اشتباه باشد، تنظیم زیر نیز می‌تواند همان پاسخ اشتباه را تولید کند:

{
  "temperature": 0
}

روش یازدهم: طراحی پاسخ با سطح اطمینان

مدل می‌تواند برای هر ادعا یک سطح اطمینان لفظی ارائه کند:

{
  "claim": "نسخه موردنظر در تاریخ X منتشر شده است",
  "confidence": "medium",
  "reason": "فقط یک منبع این تاریخ را ذکر کرده است"
}

اما Self-Reported Confidence نباید احتمال واقعی صحت تلقی شود. مدل ممکن است نسبت به پاسخ نادرست نیز Confidence بالا اعلام کند.

Confidence زمانی مفیدتر است که از چند سیگنال ساخته شود:

امتیاز Retrieval
تعداد منابع مستقل
تازگی سند
سازگاری منابع
وجود Citation
نتیجه Verifier
سازگاری چند پاسخ
نوع سؤال

روش دوازدهم: Human Review برای خروجی‌های مهم

در کاربردهای حساس یا تصمیم‌های مهم، خروجی مدل نباید بدون بررسی انسانی اجرا یا منتشر شود.

می‌توان یک Queue برای بررسی ایجاد کرد:

اگر Confidence پایین بود
یا
هیچ Citation معتبری وجود نداشت
یا
منابع متناقض بودند
یا
پاسخ شامل عدد مهم بود
یا
Verifier ادعایی را رد کرد

پاسخ به Human Review ارسال شود.

هدف این نیست که تمام پاسخ‌ها دستی بررسی شوند؛ بلکه موارد پرریسک به مسیر بازبینی هدایت شوند.

معماری پیشنهادی برای کاهش توهم

یک معماری عملی می‌تواند چنین مراحلی داشته باشد:

۱. دریافت سؤال کاربر
۲. اعتبارسنجی و دسته‌بندی سؤال
۳. تشخیص نیاز به Retrieval یا Tool
۴. بازیابی منابع مرتبط
۵. اعمال حداقل امتیاز Retrieval
۶. Rerank کردن منابع
۷. ساخت Prompt محدود به شواهد
۸. تولید پاسخ ساختاریافته
۹. استخراج ادعاهای اتمی
۱۰. بررسی Citation و Source ID
۱۱. اجرای Verifier
۱۲. محاسبه امتیاز اعتماد
۱۳. پاسخ، عدم پاسخ یا ارجاع به بررسی انسانی
۱۴. ثبت نتیجه برای ارزیابی‌های بعدی

این معماری نسبت به ارسال مستقیم سؤال به مدل هزینه و پیچیدگی بیشتری دارد، اما برای یک محصول قابل‌اعتماد ضروری‌تر است.

پیاده‌سازی پاسخ مبتنی بر منابع با API درواره

در این مثال، چند منبع از قبل بازیابی شده‌اند و همراه سؤال به مدل ارسال می‌شوند. برای سادگی، مرحله Vector Search خارج از مثال در نظر گرفته شده است.

ابتدا Requests را نصب کنید:

pip install requests

متغیر محیطی را تنظیم کنید:

export DARVAREH_API_KEY="YOUR_DARVAREH_API_KEY"
export DARVAREH_MODEL_ID="YOUR_MODEL_ID"

در Windows PowerShell:

$env:DARVAREH_API_KEY="YOUR_DARVAREH_API_KEY"
$env:DARVAREH_MODEL_ID="YOUR_MODEL_ID"

کد اصلی:

import os
import re
from dataclasses import dataclass

import requests


API_URL = "https://api.darvareh.ir/v1/chat/completions"


@dataclass(frozen=True)
class Source:
    source_id: str
    title: str
    content: str
    url: str


def build_sources_context(
    sources: list[Source],
) -> str:
    blocks: list[str] = []

    for source in sources:
        blocks.append(
            "\n".join(
                [
                    f"[SOURCE_ID: {source.source_id}]",
                    f"TITLE: {source.title}",
                    f"CONTENT: {source.content}",
                ]
            )
        )

    return "\n\n".join(blocks)


def build_prompt(
    question: str,
    sources: list[Source],
) -> str:
    context = build_sources_context(sources)

    return f"""
فقط براساس منابع زیر پاسخ بده.

قواعد:
1. هیچ اطلاعاتی خارج از منابع اضافه نکن.
2. هر ادعای واقعی را با Source ID بنویس.
3. قالب Citation باید دقیقاً مانند [DOC-101] باشد.
4. URL، نام، عدد یا تاریخ جدید نساز.
5. اگر منابع کافی نیستند، بنویس:
   «اطلاعات کافی در منابع ارائه‌شده وجود ندارد.»
6. اگر منابع متناقض‌اند، تناقض را توضیح بده.
7. پاسخ را به زبان فارسی بنویس.

SOURCES:
{context}

QUESTION:
{question}
""".strip()


def call_model(
    question: str,
    sources: list[Source],
) -> str:
    api_key = os.environ.get(
        "DARVAREH_API_KEY"
    )
    model_id = os.environ.get(
        "DARVAREH_MODEL_ID"
    )

    if not api_key:
        raise RuntimeError(
            "DARVAREH_API_KEY is missing"
        )

    if not model_id:
        raise RuntimeError(
            "DARVAREH_MODEL_ID is missing"
        )

    response = requests.post(
        API_URL,
        headers={
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json",
        },
        json={
            "model": model_id,
            "temperature": 0.1,
            "messages": [
                {
                    "role": "system",
                    "content": (
                        "شما یک دستیار مبتنی بر شواهد هستید. "
                        "نباید اطلاعات بدون منبع تولید کنید."
                    ),
                },
                {
                    "role": "user",
                    "content": build_prompt(
                        question,
                        sources,
                    ),
                },
            ],
        },
        timeout=45,
    )

    response.raise_for_status()

    data = response.json()

    answer = (
        data.get("choices", [{}])[0]
        .get("message", {})
        .get("content", "")
        .strip()
    )

    if not answer:
        raise RuntimeError(
            "Model returned an empty answer"
        )

    return answer


def extract_citations(
    answer: str,
) -> set[str]:
    return set(
        re.findall(
            r"\[([A-Z]+-\d+)\]",
            answer,
        )
    )


def validate_citations(
    answer: str,
    sources: list[Source],
) -> tuple[bool, set[str]]:
    allowed_ids = {
        source.source_id
        for source in sources
    }

    cited_ids = extract_citations(answer)

    invalid_ids = cited_ids - allowed_ids

    return len(invalid_ids) == 0, invalid_ids


def attach_source_links(
    answer: str,
    sources: list[Source],
) -> dict:
    cited_ids = extract_citations(answer)

    links = [
        {
            "source_id": source.source_id,
            "title": source.title,
            "url": source.url,
        }
        for source in sources
        if source.source_id in cited_ids
    ]

    return {
        "answer": answer,
        "sources": links,
    }


if __name__ == "__main__":
    retrieved_sources = [
        Source(
            source_id="DOC-101",
            title="معرفی درواره",
            content=(
                "درواره زیرساخت API برای اتصال "
                "نرم‌افزارها به مدل‌های هوش مصنوعی است."
            ),
            url="https://darvareh.ir",
        ),
        Source(
            source_id="DOC-102",
            title="آدرس پایه API",
            content=(
                "آدرس پایه API درواره برابر با "
                "https://api.darvareh.ir/v1 است."
            ),
            url="https://darvareh.ir/developers",
        ),
    ]

    user_question = (
        "درواره چیست و آدرس پایه API آن کدام است؟"
    )

    generated_answer = call_model(
        user_question,
        retrieved_sources,
    )

    citations_are_valid, invalid_citations = (
        validate_citations(
            generated_answer,
            retrieved_sources,
        )
    )

    if not citations_are_valid:
        raise RuntimeError(
            "Model used invalid citations: "
            + ", ".join(sorted(invalid_citations))
        )

    result = attach_source_links(
        generated_answer,
        retrieved_sources,
    )

    print(result)

این کد چند اصل مهم را رعایت می‌کند:

کلید API از Environment Variable خوانده می‌شود.
فقط Source IDهای مشخص به مدل ارائه می‌شوند.
مدل اجازه ساخت URL ندارد.
Citationهای خروجی با فهرست منابع مجاز مقایسه می‌شوند.
لینک‌ها توسط برنامه و از Metadata معتبر اضافه می‌شوند.
برای درخواست Timeout تعیین شده است.
Temperature برای پاسخ واقع‌محور پایین تنظیم شده است.

با این حال، بررسی وجود Source ID ثابت نمی‌کند ادعای مدل واقعاً توسط منبع پشتیبانی می‌شود. برای این مرحله باید Claim Verification نیز اضافه شود.

ساخت Verifier برای بررسی ادعاها

یک روش ساده دو مرحله‌ای:

مرحله اول: تولید پاسخ

مدل پاسخ را همراه ادعا و Source ID تولید می‌کند.

مرحله دوم: بررسی پاسخ

درخواست دوم فقط وظیفه بررسی دارد:

ادعای زیر را فقط با منبع ارائه‌شده مقایسه کن.

CLAIM:
آدرس پایه API درواره برابر با ... است.

SOURCE:
متن منبع

یکی از این وضعیت‌ها را برگردان:
SUPPORTED
CONTRADICTED
NOT_ENOUGH_INFORMATION

خروجی Verifier:

{
  "status": "SUPPORTED",
  "explanation": "آدرس دقیقاً در منبع ذکر شده است."
}

قواعد تصمیم‌گیری پیشنهادی:

SUPPORTED:
ادعا مستقیماً توسط منبع پشتیبانی می‌شود.

CONTRADICTED:
منبع با ادعا تناقض دارد.

NOT_ENOUGH_INFORMATION:
منبع برای تأیید یا رد ادعا کافی نیست.

در Production بهتر است Verifier به‌صورت مستقل ارزیابی شود. استفاده از همان مدل برای تولید و بررسی می‌تواند برخی سوگیری‌ها و خطاهای مشترک را حفظ کند.

نمونه Prompt ضعیف و نسخه اصلاح‌شده

Prompt ضعیف:

درباره آخرین قابلیت‌های این سرویس کامل توضیح بده و منبع هم بده.

مشکلات:

سرویس مشخص نیست.
تاریخ «آخرین» تعریف نشده است.
منابع در اختیار مدل نیستند.
مدل برای تولید منبع آزاد است.
معیار کامل بودن پاسخ مشخص نیست.

Prompt بهتر:

براساس مستندات زیر، قابلیت‌های سرویس را تا تاریخ درج‌شده در سند خلاصه کن.

قواعد:
- فقط اطلاعات موجود در مستندات را استفاده کن.
- حداکثر هفت قابلیت بنویس.
- برای هر قابلیت Source ID بده.
- اگر نسخه یا تاریخ مشخص نیست، آن را حدس نزن.
- قابلیت‌هایی که در اسناد وجود ندارند اضافه نکن.
- اگر دو سند متناقض‌اند، هر دو مورد را گزارش کن.

چگونه توهم را اندازه‌گیری کنیم؟

بدون Dataset و معیار ثابت نمی‌توان فهمید تغییر Prompt، مدل یا Retrieval واقعاً مفید بوده است.

یک مجموعه ارزیابی بسازید که شامل این موارد باشد:

سؤال
پاسخ مرجع
منابع معتبر
ادعاهای ضروری
ادعاهای ممنوع
وضعیت قابل‌پاسخ بودن
تاریخ اعتبار منبع
سطح سختی
دسته موضوعی

نمونه:

{
  "question": "آدرس پایه API چیست؟",
  "reference_answer": "https://api.darvareh.ir/v1",
  "required_claims": [
    "https://api.darvareh.ir/v1"
  ],
  "forbidden_claims": [
    "آدرس‌های تأییدنشده"
  ],
  "answerable": true,
  "source_ids": [
    "DOC-102"
  ]
}

معیارهای قابل‌اندازه‌گیری:

Factual Precision

چه درصدی از ادعاهای تولیدشده پشتیبانی می‌شوند؟

Factual Precision =
ادعاهای پشتیبانی‌شده / تمام ادعاهای قابل‌بررسی

Citation Precision

چه درصدی از Citationها واقعاً از ادعای مربوط پشتیبانی می‌کنند؟

Citation Precision =
Citationهای صحیح / تمام Citationهای ارائه‌شده

Citation Recall

چه درصدی از ادعاهای نیازمند منبع، Citation دارند؟

Citation Recall =
ادعاهای دارای Citation / تمام ادعاهای نیازمند Citation

Correct Refusal Rate

در سؤال‌هایی که پاسخ در منابع وجود ندارد، مدل چند بار به‌درستی از پاسخ قطعی خودداری می‌کند؟

Unsupported Claim Rate

چه درصدی از ادعاها بدون شواهد کافی تولید شده‌اند؟

Unsupported Claim Rate =
ادعاهای بدون منبع / تمام ادعاهای قابل‌بررسی

Contradiction Rate

چه درصدی از ادعاها با منابع تناقض دارند؟

Source Validity Rate

چه درصدی از Source IDها و لینک‌های ارائه‌شده واقعاً معتبرند؟

Latency و Cost

افزودن Retrieval، چند پاسخ و Verifier می‌تواند کیفیت را افزایش دهد، اما هزینه و زمان پاسخ را نیز بیشتر می‌کند. این دو معیار باید همراه Factuality اندازه‌گیری شوند.

طراحی Test Set واقعی

برای ساخت Dataset ارزیابی:

بین ۵۰ تا ۲۰۰ سؤال واقعی کاربران را انتخاب کنید.
اطلاعات شخصی و محرمانه را حذف کنید.
پاسخ مرجع را از منابع معتبر تهیه کنید.
سؤال‌های بدون پاسخ را نیز اضافه کنید.
سؤال‌های مبهم و دارای منبع متناقض را وارد کنید.
سؤال‌های عددی، زمانی و مربوط به نسخه را جداگانه برچسب بزنید.
پاسخ مدل‌ها را بدون دانستن نام مدل ارزیابی کنید.
Test Set را با داده‌های جدید بروزرسانی کنید.

فقط سؤال‌های ساده وارد Dataset نکنید. سیستم باید روی مواردی که در کاربرد واقعی باعث خطا می‌شوند ارزیابی شود.

الگوی امتیاز اعتماد چندسیگناله

یک امتیاز داخلی ساده می‌تواند از چند سیگنال تشکیل شود:

Trust Score =
امتیاز ارتباط Retrieval
+ پوشش Citation
+ تأیید Verifier
+ تازگی منبع
+ سازگاری منابع
- جریمه تناقض
- جریمه Citation نامعتبر
- جریمه نبود شواهد

این فرمول نباید بدون Calibration به‌عنوان «احتمال واقعی صحت» به کاربر نمایش داده شود. ابتدا باید با Dataset واقعی آزمایش شود.

یک سیاست تصمیم‌گیری نمونه:

Trust Score بالا:
پاسخ نمایش داده شود.

Trust Score متوسط:
پاسخ با هشدار و منابع نمایش داده شود.

Trust Score پایین:
پاسخ قطعی تولید نشود یا برای بررسی ارسال شود.

چه زمانی RAG کافی نیست؟

RAG به‌تنهایی در این شرایط کافی نیست:

سؤال به محاسبه دقیق نیاز دارد.
داده لحظه‌ای است.
پاسخ باید از Database تراکنشی دریافت شود.
منابع با یکدیگر تناقض دارند.
عملیات باید در سیستم دیگری اجرا شود.
پاسخ به احراز هویت یا سطح دسترسی وابسته است.
سند بازیابی‌شده ناقص یا قدیمی است.
مدل باید چند مرحله Tool Calling انجام دهد.

در این موارد باید از Tool، API، Query یا Workflow کنترل‌شده استفاده شود.

توهم در زبان فارسی

عملکرد مدل در تمام زبان‌ها یکسان نیست. احتمال خطا در فارسی می‌تواند تحت‌تأثیر عوامل زیر باشد:

داده آموزشی کمتر نسبت به انگلیسی
تفاوت املای نام‌ها
ترکیب متن فارسی و انگلیسی
استفاده از اعداد فارسی و انگلیسی
تفاوت تقویم شمسی و میلادی
نیم‌فاصله و شکل‌های مختلف یک واژه
ترجمه نام محصولات و اصطلاحات
منابع محدودتر فارسی
Retrieval ضعیف برای متن راست‌به‌چپ

برای سیستم فارسی:

هر دو شکل فارسی و انگلیسی اصطلاحات مهم را Index کنید.
اعداد را Normalization کنید.
تاریخ شمسی و میلادی را با Metadata دقیق نگه دارید.
نیم‌فاصله و حروف عربی و فارسی را Normalize کنید.
Retrieval را با سؤال‌های واقعی فارسی ارزیابی کنید.
نام انگلیسی محصول را کنار نام فارسی نگه دارید.
پاسخ فارسی مدل را جداگانه Benchmark کنید.

توهم در کدنویسی با هوش مصنوعی

برای کاهش کد ساختگی:

نسخه Framework را در Prompt مشخص کنید.
لینک مستندات رسمی را در Context قرار دهید.
از مدل بخواهید Package و Importها را فهرست کند.
کد را Build و Test کنید.
Type Check اجرا کنید.
دستورات نصب را در محیط آزمایشی بررسی کنید.
APIهای استفاده‌شده را با مستندات نسخه جاری تطبیق دهید.
از مدل بخواهید بخش‌های نامطمئن را علامت‌گذاری کند.
خروجی را مستقیم در Production اجرا نکنید.

Prompt مناسب:

کد را برای Node.js 22 و TypeScript بنویس.

فقط از APIهای موجود در مستندات ارائه‌شده استفاده کن.

در پایان موارد زیر را فهرست کن:
- Packageهای لازم
- نسخه‌های فرض‌شده
- Environment Variableها
- دستور اجرا
- بخش‌هایی که نیاز به بررسی دارند

آیا مدل بزرگ‌تر همیشه توهم کمتری دارد؟

الزاماً نه. مدل بزرگ‌تر ممکن است در بسیاری از وظایف قوی‌تر باشد، اما اندازه به‌تنهایی تضمین‌کننده Truthfulness نیست.

پژوهش TruthfulQA نشان داد مدل‌ها می‌توانند باورهای نادرست رایج در داده‌های انسانی را بازتولید کنند و افزایش مقیاس به‌تنهایی مسئله حقیقت‌گویی را حل نمی‌کند. جزئیات این Benchmark در مقاله TruthfulQA آمده است.

برای انتخاب مدل باید آن را روی کاربرد، زبان، اسناد و معیارهای واقعی پروژه خودتان ارزیابی کنید.

چک‌لیست کاهش توهم در برنامه هوش مصنوعی

سطح Prompt

آیا دامنه پاسخ مشخص است؟
آیا مدل اجازه اعلام کمبود اطلاعات دارد؟
آیا حدس زدن نام، عدد و URL ممنوع شده است؟
آیا تفاوت Fact و Inference مشخص شده است؟
آیا قالب Citation تعریف شده است؟

سطح Retrieval

آیا Chunking مناسب است؟
آیا Metadata کامل است؟
آیا نسخه و تاریخ سند مشخص است؟
آیا اسناد قدیمی حذف شده‌اند؟
آیا Hybrid Search استفاده می‌شود؟
آیا Reranking وجود دارد؟
آیا حداقل امتیاز ارتباط تعریف شده است؟

سطح Generation

آیا مدل مناسب انتخاب شده است؟
آیا Temperature با نوع کار هماهنگ است؟
آیا خروجی ساختاریافته است؟
آیا پاسخ فقط به منابع محدود شده است؟
آیا طول پاسخ کنترل می‌شود؟

سطح Verification

آیا ادعاهای اتمی استخراج می‌شوند؟
آیا Source IDها معتبرند؟
آیا Citation واقعاً ادعا را پشتیبانی می‌کند؟
آیا منابع متناقض شناسایی می‌شوند؟
آیا پاسخ‌های کم‌اعتماد متوقف می‌شوند؟

سطح محصول

آیا کاربر منابع را می‌بیند؟
آیا هشدار مناسب برای پاسخ نامطمئن وجود دارد؟
آیا امکان گزارش پاسخ اشتباه فراهم است؟
آیا موارد پرریسک بازبینی می‌شوند؟
آیا Prompt و پاسخ حساس بدون نیاز ذخیره نمی‌شوند؟
آیا Evals به‌صورت دوره‌ای اجرا می‌شوند؟
آیا هزینه و Latency پایش می‌شوند؟

اشتباهات رایج در کاهش Hallucination

نوشتن «توهم نزن»

این دستور به‌تنهایی کافی نیست:

اطلاعات اشتباه تولید نکن.

مدل برای تشخیص اشتباه بودن به منبع، Context، ابزار یا Verifier نیاز دارد.

اعتماد به Citation ظاهری

وجود لینک یا نام مقاله اثبات نمی‌کند منبع واقعی است. لینک باید توسط برنامه از Metadata معتبر ارائه شود.

فرض اینکه RAG همه‌چیز را حل می‌کند

RAG ضعیف می‌تواند پاسخ را بدتر کند. اگر سند اشتباه بازیابی شود، مدل ممکن است همان سند را با اطمینان خلاصه کند.

استفاده از مدل برای تأیید خودش

Self-Verification مفید است، اما مدل ممکن است خطای خودش را تأیید کند. برای پاسخ مهم از منبع خارجی یا Verifier مستقل استفاده کنید.

تکیه کامل بر Confidence مدل

Confidence لفظی مدل لزوماً Calibration واقعی ندارد.

پایین آوردن Temperature به صفر

Temperature صفر، پاسخ را باثبات‌تر می‌کند؛ اما صحت را تضمین نمی‌کند.

ارزیابی با چند سؤال ساده

یک Demo موفق نشان‌دهنده آمادگی Production نیست. Test Set باید سؤال‌های سخت، مبهم، بدون پاسخ، عددی و دارای منابع متناقض داشته باشد.

پرسش‌های متداول درباره توهم هوش مصنوعی

Hallucination در هوش مصنوعی یعنی چه؟

یعنی مدل اطلاعاتی نادرست، ساختگی، متناقض یا بدون پشتوانه تولید کند و آن را به‌شکل یک پاسخ طبیعی ارائه دهد.

آیا تمام مدل‌های زبانی توهم دارند؟

مدل‌های زایشی ممکن است پاسخ اشتباه یا بدون پشتوانه تولید کنند. میزان آن به مدل، سؤال، زبان، Context، Retrieval و روش ارزیابی بستگی دارد.

آیا RAG توهم را کاملاً حذف می‌کند؟

خیر. RAG می‌تواند با ارائه منابع مرتبط Hallucination را کاهش دهد، اما Retrieval اشتباه، Context ناقص یا تفسیر نادرست مدل همچنان ممکن است باعث خطا شود.

آیا Temperature پایین توهم را کم می‌کند؟

ممکن است تنوع و نوسان پاسخ را کاهش دهد، اما صحت اطلاعات را تضمین نمی‌کند.

چگونه منبع ساختگی مدل را تشخیص دهیم؟

نام مقاله، نویسنده، DOI و URL را در منبع معتبر بررسی کنید. در برنامه Production بهتر است URL توسط مدل تولید نشود و از Metadata سیستم اضافه شود.

بهترین Prompt برای جلوگیری از توهم چیست؟

Promptی که دامنه منابع، امکان عدم پاسخ، قالب Citation، منع حدس زدن و نحوه برخورد با تناقض را دقیق تعریف کند. با این حال هیچ Promptی به‌تنهایی تضمین کامل ایجاد نمی‌کند.

چگونه توهم مدل را در API کاهش دهیم؟

از RAG، Citation معتبر، Structured Output، Validation، Verifier، Tool Calling، Temperature مناسب و Evals استفاده کنید.

آیا پاسخ مدل را می‌توان بدون بررسی منتشر کرد؟

برای محتوای کم‌ریسک نیز بهتر است اطلاعات واقعی، اعداد، نقل‌قول‌ها و منابع بررسی شوند. در تصمیم‌ها یا عملیات مهم، بازبینی انسانی و کنترل‌های فنی ضروری‌تر است.

کدام مدل کمترین Hallucination را دارد؟

پاسخ ثابتی برای تمام کاربردها وجود ندارد. مدل باید روی Dataset واقعی پروژه، زبان فارسی، نوع سؤال و منابع مورداستفاده ارزیابی شود.

جمع‌بندی

توهم هوش مصنوعی یکی از محدودیت‌های اساسی مدل‌های زبانی است. مدل می‌تواند پاسخی روان، حرفه‌ای و قانع‌کننده تولید کند که بخشی از آن نادرست یا بدون منبع باشد.

راهکار قابل‌اعتماد، استفاده از یک دستور ساده مانند «اطلاعات اشتباه نده» نیست. کاهش Hallucination به معماری چندلایه نیاز دارد:

سؤال و دامنه پاسخ را محدود کنید.
امکان اعلام کمبود اطلاعات را فراهم کنید.
اسناد معتبر را با RAG بازیابی کنید.
Source ID و Citation قابل‌بررسی ارائه دهید.
URL منابع را از Metadata سیستم اضافه کنید.
پاسخ را به ادعاهای اتمی تقسیم کنید.
ادعاها را با منابع بررسی کنید.
خروجی را با Schema کنترل کنید.
ابزارهای قطعی را جایگزین حدس مدل کنید.
کیفیت را با Dataset واقعی اندازه بگیرید.
موارد کم‌اعتماد را متوقف یا بازبینی کنید.
مدل، هزینه و Latency را با هم مقایسه کنید.

برای ساخت و ارزیابی برنامه‌های متصل به مدل‌های مختلف می‌توانید از API یکپارچه درواره استفاده کنید. مدل‌ها و Model IDهای قابل‌استفاده در صفحه مدل‌های درواره قرار دارند.

مقالات مرتبط

منابع تکمیلی

برای مطالعه شرایط استفاده و محدودیت‌های مسئولیت، صفحه «سلب مسئولیت» را مشاهده کنید.