جلوگیری از توهم هوش مصنوعی در RAG: طراحی پنج‌لایه

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

روش RAG (تولید مبتنی بر بازیابی)، یعنی نوشتن پاسخ بر پایه متن‌هایی که از یک پیکره بازیابی می‌شوند، به‌تنهایی جلوی توهم هوش مصنوعی را نمی‌گیرد؛ زمینه (context) ضعیف حتی ممکن است مدل را به‌جای محتاط‌تر، مطمئن‌تر کند. پس جای بیشتر لایه‌های محافظ (guardrails) در کدی است که پیرامون مدل اجرا می‌شود، نه در خود مدل. این محافظ‌ها را، همان‌طور که در دستیار همین سایت ساخته شده‌اند، در پنج لایه و با ترتیبی ثابت بچینید:

1. پرسش‌هایی را که دستیار هرگز نباید به آن‌ها پاسخ دهد، پیش از بازیابی رد کنید.

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

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

4. پاسخ را جمله‌به‌جمله و فقط پس از بررسی‌های قطعی برای خواننده ارسال کنید.

5. هرگز نگذارید دستیار از زبان شخصی که پشت آن است سخن بگوید.

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

این سایت و دستیارش را خودم ساخته‌ام و نگهداری می‌کنم. برای این دستیار هیچ رقمی از دقت منتشر نمی‌کنم؛ دلیل آن در بخش ارزیابی آمده است.

RAG چیست و چرا هنوز دچار توهم می‌شود؟

در معماری RAG، پرسش ابتدا به بازیاب (retriever) می‌رسد. بازیاب چند قطعه متن از پیکره برمی‌گرداند و مدل زبانی پاسخ را بر پایه همان قطعه‌ها می‌نویسد. توهم هوش مصنوعی، که در نوشته‌های فارسی «هالوسینیشن» هم خوانده می‌شود، یعنی مدل گزاره‌ای نادرست یا بی‌پشتوانه را چنان بگوید که گویی درست است.

بازیابی دامنه چیزهایی را که مدل احتمالاً می‌گوید تنگ‌تر می‌کند، اما مرزی قطعی برایش نمی‌گذارد.

بازیابی گاهی مدل را مطمئن‌تر می‌کند، نه درست‌تر

پژوهشگران Google دو وضعیت را از هم جدا کردند: زمینه بازیابی‌شده یا برای پاسخ به پرسش کافی است، یا نیست. نویسندگان در جمع‌بندی مقاله‌شان، که در ICLR ۲۰۲۵ ارائه شد، بی‌پرده می‌گویند RAG «به‌طور کلی عملکرد را بهتر می‌کند، اما به‌طرز متناقضی توانایی مدل را برای خودداری از پاسخ، در جایی که خودداری بجاست، کاهش می‌دهد». در یکی از نمونه‌ها، مدل Gemma بدون هیچ زمینه‌ای به ۱۰٫۲٪ پرسش‌ها پاسخ نادرست داد، اما با زمینه ناکافی این سهم به ۶۶٫۱٪ رسید.

دانستنِ اینکه چه وقت نباید پاسخ داد سودمند است: روش تولید گزینشی (selective generation) که نویسندگان پیشنهاد کرده‌اند، سهم پاسخ‌های درست را در میان دفعاتی که مدل پاسخ داده است، برای Gemini و GPT و Gemma به میزان ۲ تا ۱۰ درصد افزایش داد.

بازیاب top-k همیشه k قطعه برمی‌گرداند، چه مرتبط باشند چه نه. اگر داوری درباره کافی بودن این قطعه‌ها فقط با خود مدل باشد، تصمیم به خودداری به همان مؤلفه‌ای سپرده شده است که این پژوهش نشان می‌دهد اغلب در آن خطا می‌کند.

مدل‌ها برای حدس‌زدن پاداش می‌گیرند

به استدلال Kalai و همکارانش، مدل‌های زبانی دچار توهم می‌شوند، چون «روال‌های آموزش و ارزیابی به‌جای اذعان به عدم قطعیت، به حدس‌زدن پاداش می‌دهند».

وضعیت مثل آزمون چهارگزینه‌ای بدون نمره منفی است: داوطلبی که پاسخ را نمی‌داند، با حدس‌زدن نمره بیشتری می‌گیرد تا با سفید گذاشتن پاسخ. وقتی نمره‌دهی برای «نمی‌دانم» امتیازی قائل نیست، حدس‌زدن به صرفه است. دستوری که از مدل می‌خواهد به عدم قطعیتش اذعان کند، خلاف جهت همین انگیزه عمل می‌کند. کمک می‌کند، اما سازوکار کنترلی نیست.

ابزارهای حقوقی تجاری هم دچار توهم شدند

برخی ارائه‌دهندگان ابزارهای پژوهش حقوقی RAG را راهی برای «از بین بردن» توهم معرفی کرده بودند. نخستین ارزیابی پیش‌ثبت‌شده (preregistered) ابزارهای هوش مصنوعی پژوهش حقوقی نشان داد محصولات LexisNexis و Thomson Reuters هر کدام در ۱۷٪ تا ۳۳٪ موارد دچار توهم شدند. اینکه این یافته برای ساخت محصولات حقوقی چه معنایی دارد، موضوع نوشته توهم هوش مصنوعی حقوقی: چه باید ساخت؟ است.

معماری RAG با پنج لایه محافظ، در یک نگاه

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

لایه اول: امتناع پیش از بازیابی

نخستین خطا نبودنِ پاسخ نیست؛ پاسخی است که اصلاً نباید وجود داشته باشد.

پرسش‌هایی که پیکره پاسخشان را دارد، اما دستیار نباید پاسخ دهد

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

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

• شرایط همکاری: دستمزد، زمان در دسترس بودن و به‌کارگیری.

• اطلاعات خصوصی که سایت آگاهانه منتشر نمی‌کند، مانند شماره تلفن، نشانی منزل، وضعیت تأهل یا نظام وظیفه، یا تاریخ تولد.

• گمانه‌زنی: پیش‌بینی و مقایسه با افراد مشخصی که نامشان در پرسش آمده است.

• درخواست‌های متا که می‌کوشند دستورالعمل‌های دستیار را بیرون بکشند یا دور بزنند.

• درخواست انجام کار: نوشتن کد یا متن، یا ترجمه یا حل کردن چیزی، به‌جای پرسش درباره کارهای منتشرشده.

متن امتناع ثابت است، نه خروجی مدل: امتناعی که مدل بنویسد، امتناعی است که خود مدل می‌تواند با استدلال از آن بگذرد. کلاینت مدل embedding (مدلی که متن را به بردار تبدیل می‌کند) و کلاینت مدل زبانی فقط هنگام نیاز ساخته می‌شوند؛ پس امتناع در این لایه هیچ فراخوانی بیرونی ندارد.

برای سامانه خودتان فهرستی از پرسش‌هایی بنویسید که پاسخ درستشان این است: «این دستیار جای پاسخ به این پرسش نیست»، فارغ از اینکه پیکره چه در خود دارد.

الگو، نه طبقه‌بند

مجموعه امتناع برای انگلیسی و فارسی فهرستی از عبارت‌های منظم (regular expressions) است و برای هشت زبان دیگر سایت فهرستی از عبارت‌ها، و همه روی شکل یکسان‌سازی‌شده پرسش اجرا می‌شوند: حروف لاتین کوچک می‌شوند، شکل‌های عربی حروف به شکل فارسی‌شان برمی‌گردند، ارقام فارسی و عربی به لاتین تبدیل می‌شوند، اعراب‌گذاری عربی حذف می‌شود و نیم‌فاصله درون واژه‌ها جای خود را به فاصله می‌دهد. پرسش یک بار هم با خواندن نام من به‌صورت ضمیر آزموده می‌شود؛ پس «دستمزد محمد پناهی چقدر است؟» همان‌طور رد می‌شود که «دستمزد او چقدر است؟»، و پرسش پیگیری همراه با پرسش پیش از آن بررسی می‌شود.

این مجموعه طبقه‌بند (classifier) نیست. یک طبقه‌بند، حتی اگر بیشتر وقت‌ها درست تشخیص دهد، باز هم وعده‌ای است که این سایت نمی‌تواند بدهد، چون هر خطایش تعهدی به نام یک شخص است.

محدودیتش روشن است: الگوها صورت‌بندی‌های دیگرِ همان پرسش را نمی‌گیرند. گونه‌های املایی فارسی اما دیگر شکاف این لایه نیستند. چون یکسان‌سازی نیم‌فاصله را به فاصله تبدیل می‌کند، واژه‌ای که املای معیار آن را با نیم‌فاصله می‌نویسد، جداشده به الگوها می‌رسد، و هر الگوی فارسی هر دو شکل را می‌پذیرد؛ «چقدر می‌گیرد؟» و «چقدر میگیرد؟» هر دو رد می‌شوند. پرسشی که با واژه‌هایی بیرون از این فهرست پرسیده شود همچنان می‌گذرد، و لایه‌های بعدی برای همان‌اند: پرامپت سخن‌گفتن از دستمزد و زمان در دسترس بودن را ممنوع می‌کند، و گیت جمله‌ای (sentence gate) در لایه چهارم جلوی ارسال هر جمله‌ای را می‌گیرد که یکی از واژه‌های اول شخصِ فهرست‌شده، یا رقمی که در منابع نیامده، در آن باشد. این کار شکاف را تنگ‌تر می‌کند، اما نمی‌بندد. فهرست‌های زبان‌هایی جز انگلیسی و فارسی کوتاه‌ترند، و صورت‌بندی‌های دیگرِ پرسش در آن زبان‌ها بیشتر از این لایه می‌گذرند.

لایه دوم: آستانه شباهت و امتناع بدون فراخوانی مدل

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

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

چرا نمی‌توان روی امتیاز RRF آستانه گذاشت؟

بازیاب این سایت ترکیبی (hybrid) است: جستجوی برداری چگال و جستجوی کلیدواژه‌ای با تطبیق واژه کامل، که با ادغام رتبه معکوس (reciprocal rank fusion یا RRF) ترکیب می‌شوند. اینکه این ترکیب با متن فارسی و انگلیسی در کنار هم چه می‌کند، در راهنمای جستجوی ترکیبی در RAG فارسی آمده است.

RRF روش خوبی برای ترکیب رتبه‌بندی‌هاست، اما عددی که می‌سازد برای آستانه‌گذاری مناسب نیست. در صورت‌بندی Cormack و Clarke و Büttcher، امتیاز هر سند مجموع 1/(k + r(d)) روی همه رتبه‌بندی‌هاست؛ r(d) رتبه سند در هر فهرست است و مقدار k = 60 «در یک بررسی آزمایشی تعیین شد و در اعتبارسنجی‌های بعدی تغییری نکرد».

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

آستانه به‌جای آن چه چیزی را می‌سنجد؟

هر جستجویی که بتواند شباهتی کران‌دار بسازد، آن را هم گزارش می‌دهد:

• جستجوی برداری شباهت کسینوسی را گزارش می‌کند که به بازه ۰ تا ۱ محدود شده است. آستانه شباهت با خود پرسش را به کار می‌گیرد و، برای پرسش پیگیری، شباهت با پرسشی را که به پرسش پیش از آن پیوسته شده است. اگر پرسش پیگیری به شکل جایگاهی در یک فهرست بیان شود، مثلاً «دومی»، موردی که به آن اشاره می‌کند هم به آن پیوسته می‌شود: جایگاه از خود پرسش خوانده می‌شود و فهرست از پاسخ قبلی، با عنوان‌ها و نام‌های خود سایت یا با آنچه پاسخ در گیومه آورده است، و به مدل گفته می‌شود کدام مورد است. آن مورد فقط وقتی پیوسته می‌شود که هم جایگاه و هم فهرست بی‌هیچ تردیدی خوانده شوند؛ وگرنه ابتدای پاسخ قبلی به جای آن پیوسته می‌شود. آنچه سنجیده می‌شود شیوه بیان پرسش است، نه پاسخ: پرسش پیگیری بی‌ربطی هم که از قضا «دومی» بگوید، ابتدای پاسخ را همراه خود می‌گیرد و ممکن است از آستانه بگذرد؛ پرامپت و گیت همچنان پشت آن ایستاده‌اند. وقتی پرسش درباره من باشد، بازیابی یک بار هم با افزودن نام من جستجو می‌کند. این کار به مرتب‌کردن قطعه‌ها کمک می‌کند، اما هرگز در آستانه به حساب نمی‌آید: نام، هر پرسشی درباره من را به رزومه نزدیک نشان می‌دهد، حتی پرسش‌هایی را که سایت پاسخی برایشان ندارد.

• جستجوی کلیدواژه‌ای پوشش را گزارش می‌کند: سهم واژه‌های محتوایی سه‌حرفی یا بلندتر پرسش (در چینی، دو نویسه یا بیشتر) که به‌صورت واژه کامل در قطعه آمده‌اند. پیش از آن، واژه‌های پربسامد (stop words) هر یک از زبان‌های سایت کنار گذاشته می‌شوند، و پوشش فقط وقتی در آستانه به حساب می‌آید که دست‌کم دو واژه محتوایی متفاوت تطبیق یابند. تطبیق یک واژه تصادف است. در پرسش پیگیری‌ای که جز جایگاه مورد چیزی نمی‌گوید، مثلاً «دربارهٔ دومی بیشتر بگو»، واژه‌های محتوایی همان واژه‌های عنوان یا نامی است که خود سایت به آن مورد داده است.

برای هر قطعه، بزرگ‌ترِ این دو مقدار نگه داشته می‌شود و آستانه با بیشترین مقدار در میان قطعه‌های بازگردانده‌شده مقایسه می‌شود؛ قطعه‌ای که این مقدار را تعیین می‌کند همیشه در میان آن‌هاست. امتیاز ادغامی فقط ترتیب را تعیین می‌کند.

تطبیق واژه کامل مهم است. اگر به‌جای آن زیررشته‌ها تطبیق داده شوند، «سال» درون «ارسال» پیدا می‌شود و پرسش‌های بی‌ربط شبیه شاهد به نظر می‌رسند. اگر سرویس embedding در دسترس نباشد، بازیابی فقط به جستجوی کلیدواژه‌ای تکیه می‌کند و آستانه همچنان اعمال می‌شود.

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

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

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

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

آستانه شباهت در RAG را چگونه انتخاب کنیم؟

عدد ثابتی که برای همه سامانه‌ها درست باشد وجود ندارد. شباهت کسینوسی به مدل embedding، ترکیب زبان‌ها و خود پیکره بستگی دارد؛ آستانه‌ای که برای یک مدل مناسب است، روی مدلی دیگر ممکن است همه چیز را رد کند، یا هیچ چیز را.

مقدار پیش‌فرض طراحی در این سایت ۰٫۳۵ است و مجموعه آزمون‌ها با یک مدل embedding جانشین، یعنی مدلی که فقط در آزمون‌ها به کار می‌رود، با همین مقدار اجرا می‌شود. این مقدار هنوز با مدل embedding عملیاتی کالیبره نشده است. فرمانی که فقط بازیابی را اجرا می‌کند، پرسش‌های مجموعه طلایی و پرسش‌های پیشنهادی سایت را بدون فراخوانی مدل از مدل embedding مستقر می‌گذراند، و آستانه عملیاتی فقط وقتی تغییر می‌کند که این اجرا موفق شود. عددی نیست که بتوان آن را عیناً برداشت. برای انتخاب عدد خودتان:

1. پرسش‌هایی را که دستیار باید به آن‌ها پاسخ دهد و پرسش‌هایی را که باید رد کند، از همان مدل embedding که مستقر می‌کنید بگذرانید و توزیع بیشترین شباهت را در این دو گروه مقایسه کنید.

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

3. ثبت کنید این عدد به کدام مدل embedding و کدام پیکره تعلق دارد. هر صفحه‌ای که به پیکره اضافه شود، دامنه چیزهایی را که یک پرسش بی‌ربط می‌تواند با آن‌ها تطبیق یابد تغییر می‌دهد؛ همین نوشته هم از این قاعده بیرون نیست.

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

لایه سوم: پرامپت سیستم تنها لایه‌ای است که مدل می‌تواند نادیده بگیرد

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

اما اجرای هیچ‌کدام را نمی‌تواند تضمین کند. مدخل LLM07:2025 System Prompt Leakage در فهرست OWASP لایه‌های محافظی بیرون از مدل را توصیه می‌کند، چون سامانه‌ای مستقل که خروجی را بررسی کند تا معلوم شود مدل مطابق انتظار رفتار کرده است یا نه، «بر دستورهای پرامپت سیستم ترجیح دارد». راهنمای Anthropic برای کاهش توهم، که اجازه‌دادن به مدل برای گفتن «نمی‌دانم» را هم در بر دارد، به همان اندازه صریح است: این روش‌ها توهم را «به‌طور چشمگیری کاهش می‌دهند، اما به‌طور کامل از بین نمی‌برند».

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

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

لایه چهارم: کنترل پاسخ استریم، جمله‌به‌جمله

جمله‌ای را که خواننده خوانده است، نمی‌توان پس گرفت. مستندات NeMo Guardrails شرکت NVIDIA این بده‌بستان را صریح نام می‌برد: وقتی stream_first روشن باشد، که حالت پیش‌فرض است، «اگر یک rail محتوا را مسدود کند، کاربر توکن‌ها را پیش‌تر دریافت کرده است».

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

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

1. نشانگر در محدوده. نشانگر منبع باید به منبعی اشاره کند که واقعاً به مدل داده شده است.

2. وجود نشانگر. جمله‌ای که محتوای واقعی دارد باید نشانگر داشته باشد؛ جمله کوتاهی که فقط دو جمله را به هم پیوند می‌دهد و هیچ مقداری در آن نیست، عبور می‌کند. طول جمله با شمار واژه‌های جداشده با فاصله سنجیده می‌شود، جز در چینی که میان واژه‌ها فاصله نمی‌گذارد: در آن هر سه نویسه دو واژه شمرده می‌شود.

3. مقادیر در شواهدِ ارجاع‌شده. هر عدد، URL و نشانی ایمیل باید در منبعی آمده باشد که جمله به آن ارجاع می‌دهد؛ مقایسه پس از تبدیل ارقام فارسی و عربی به لاتین انجام می‌شود.

4. بدون اول شخص. وجود واژه‌های اول شخص یعنی دستیار شروع کرده است از زبان من سخن بگوید.

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

نشانگرها بررسی و سپس حذف می‌شوند؛ خواننده نثر می‌بیند، نه فهرست منابع. پاسخی که به سقف توکن خروجی مدل برسد و ناتمام بماند، اعلان دیگری دارد: جمله‌ای که قطع شده، جمله‌ای بی‌پشتوانه نیست.

جمله‌ای که منبع دارد لزوماً درست نیست. مقادیر با منابعی مقایسه می‌شوند که جمله به آن‌ها ارجاع می‌دهد، نه با خود ادعا: جمله‌ای که به دو منبع ارجاع دهد می‌تواند مقداری را از هر کدام بگیرد، و جمله‌ای بدون مقدار با هر نشانگری که در محدوده باشد عبور می‌کند. گیت نمی‌تواند نشان دهد ادعایی درست است، یا حتی اینکه قطعه ارجاع‌شده همین ادعا را دارد. مدخل LLM09:2025 Misinformation در OWASP از تیم‌ها می‌خواهد «خروجی‌های کلیدی را به‌طور خودکار اعتبارسنجی کنند»؛ این گیت نسخه‌ای محدود و قطعی از همین توصیه است. سازوکار کامل آن در لایه‌های محافظ برای پاسخ استریم LLM آمده است.

لایه پنجم: قواعد سخنگویی و نمایندگی

دستیاری که از طرف کسی سخن می‌گوید، از طرف او تعهد هم می‌دهد

در پرونده Moffatt v. Air Canada (2024 BCCRT 149)، به گزارش McCarthy Tétrault و Bristows، دیوان حل اختلاف مدنی بریتیش کلمبیا به شکایتی رسیدگی کرد که در آن چت‌بات یک شرکت هواپیمایی به مشتری گفته بود می‌تواند تخفیف ویژه سوگواری (bereavement fare) را عطف به ماسبق درخواست کند. به تعبیر دیوان، موضع شرکت در عمل این بود که «چت‌بات شخصیت حقوقی مستقلی است که مسئول اقدامات خودش است». دیوان این را نپذیرفت: «فرقی نمی‌کند اطلاعات از یک صفحه ثابت بیاید یا از یک چت‌بات».

این توضیح مهندسی است، نه مشاوره حقوقی، و رأی یک دیوان قاعده‌ای عام نیست. درس مهندسی محدودتر است: دستیاری که روی سایت شماست، با اعتبار سایت شما سخن می‌گوید. رقم دستمزد یا تاریخ شروع همکاری، اگر به زبان من نوشته شود، اظهاری است که من هرگز نکرده‌ام. پاسخ نادرستِ بااطمینان از نبودن پاسخ بدتر است؛ تعهد نادرستِ بااطمینان از آن هم بدتر.

سوم شخص، متن ثابت امتناع و بررسی اول شخص

دستیار هرگز من نیست. درباره من به‌صورت سوم شخص می‌نویسد و همه متن‌های امتناع و اعلان‌ها ثابت‌اند. قاعده سخنگویی در سه جا اعمال می‌شود:

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

• لایه سوم اول شخص و هر تعهدی از طرف من را ممنوع می‌کند.

• لایه چهارم با ظاهرشدن واژه‌ای اول شخص، جریان را متوقف می‌کند.

این بررسی در فارسی ضعیف‌تر است. فهرست اول شخص انگلیسی ضمیرها را پوشش می‌دهد. فهرست فارسی گزینش‌شده است، نه جامع: فارسی شخص را با شناسه فعل نشان می‌دهد، و قاعده‌ای آن‌قدر گسترده که همه این شناسه‌ها را بگیرد، واژه‌های معمولیِ مختوم به «م» مانند «نظام» و «پیام» را هم می‌گیرد. در این فهرست ضمیرها و چند فعل پرخطر آمده‌اند، مانند «هستم» و «دارم»، و هر فعلی که با پیشوند «می» می‌آید به هر دو شکلی که یکسان‌سازی می‌سازد فهرست شده است: این بررسی هم پیش از جداکردن واژه‌ها یکسان‌سازی می‌کند، پس «می‌کنم» به دو نشانه و «میکنم» به یک نشانه می‌رسد. آنچه بیرون از پوشش می‌ماند شناسه فعل است، نه املا. کنترل اول شخص در فارسی بیشتر به پرامپت تکیه دارد، و این موضوع مکتوب شده است، نه پنهان. برای دیگر زبان‌های سایت، فهرست ضمیرهای اول شخص و شکل‌های ملکی آن‌ها را در بر دارد، و در اسپانیایی، پرتغالی، روسی، عربی و هندی، که اول شخص را اغلب تنها با فعل بیان می‌کنند، چند فعل اول شخص هم به آن افزوده شده است. در چینی، که واژه‌ها را با فاصله از هم جدا نمی‌کند، بررسی به دنبال 我 در هر جای جمله می‌گردد، مگر در ترکیب‌هایی با 自我 به معنای «خود-»، مانند 自我修正، یعنی «خوداصلاحی». در عربی یک واژه اول شخص عمداً کنار گذاشته شده است، چون همان یکسان‌سازی حروف که املای فارسی و عربی را مقایسه‌پذیر می‌کند، آن را با یک حرف اضافه رایج یکی می‌کند.

هزینه مهارنشده LLM و حمله Denial of Wallet: خطایی از همان جنس

توهم خروجی‌ای است که هیچ‌کس اجازه‌اش را نداده است. صورت‌حساب بی‌سقف هزینه‌ای است که هیچ‌کس اجازه‌اش را نداده است. OWASP مورد دوم را ذیل LLM10:2025 Unbounded Consumption دسته‌بندی می‌کند که Denial of Wallet (تخلیه عمدی بودجه) را هم در بر می‌گیرد: مهاجمان «از مدل پرداخت به‌ازای استفاده در سرویس‌های ابری هوش مصنوعی سوءاستفاده می‌کنند و بار مالی غیرقابل‌تحملی بر ارائه‌دهنده تحمیل می‌کنند». راهکارهای پیشنهادی آن از جمله این‌هاست: محدودکردن اندازه ورودی، محدودیت درخواست و سهمیه کاربر، مهلت زمانی و کندکردن عملیات پرمصرف، و افت تدریجی کارکرد (graceful degradation) به‌جای از کار افتادن کامل.

بودجه پیش از فراخوانی، نه هشدار پس از آن

بررسی‌ای که پس از فراخوانی مدل اجرا شود، وقتی به نتیجه می‌رسد که پول خرج شده است. در این سایت، بررسی سقف ماهانه هزینه پس از آستانه و پیش از فراخوانی مدل اجرا می‌شود. این بررسی هزینه ثبت‌شده از ابتدای ماه تا این لحظه را با کران بالای هزینه همین نوبت گفت‌وگو جمع می‌زند: کل پرامپت به نرخ یک توکن برای هر بایت در کدگذاری UTF-8، به‌علاوه کل سقف خروجی، از جمله سهمیه استدلال (reasoning). اگر به‌جای این کران، هزینه مورد انتظار سنجیده شود، سقف دقیقاً از همین راه شکسته می‌شود.

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

شمار بایت‌ها سقفی قطعی است، نه برآوردی سخاوتمندانه. هر واژگانی که این نقطه پایانی می‌تواند به آن وصل شود، BPE بایت‌محور است و در چنین توکنایزری هر توکن دنباله‌ای ناتهی از بایت‌هاست؛ پس هیچ متنی نمی‌تواند توکنی بیش از بایت‌هایش بسازد، به هر زبانی که نوشته شده باشد. تنها راه عبور از این کران، توکنایزری است که متن را پیش از تقسیم گسترش دهد، و هیچ‌کدام از این توکنایزرها چنین نمی‌کنند. این قاعده جای نرخ ثابت «یک توکن برای هر دو نویسه» را گرفت، همان قاعده‌ای که این سایت کنارش گذاشت: مقاله مالیات توکن فارسی نشان داد آن نرخ در cl100k_base برای تک‌تک جمله‌های فارسی یک پیکره موازی کمتر از شمار واقعی توکن برآورد می‌کند. این سقف بسیار بالاتر از مصرف واقعی است — برای فارسی چند برابر هزینه واقعی پرامپت رزرو می‌شود — و خطایش در همان جهتی است که یک سقف هزینه اجازه دارد در آن اشتباه کند.

دو محدودیت باقی می‌ماند. این بررسی رزرو نیست: هزینه فقط خوانده و مقایسه می‌شود، نگه داشته نمی‌شود؛ پس درخواست‌های هم‌زمان ممکن است هر کدام از بررسی بگذرند و روی هم از سقف فراتر روند، و محدودیت‌های هر IP این احتمال را کمتر می‌کنند، اما از بین نمی‌برند. شمارنده هم دفتر حساب کامل نیست: هزینه فراخوانی‌های مدل زبانیِ همین نقطه پایانی را نگه می‌دارد، پس فراخوانی embedding میزبانی‌شده که پشت هر پرسش انجام می‌شود بیرون از آن می‌ماند، و نوشتنی که هنگام در دسترس نبودن انباره شمارنده از دست برود، دوباره تلاش نمی‌شود. این سقف سازوکاری محافظتی است، نه صورت‌حساب.

هنگام خرابی: سقف هزینه بسته می‌ماند، محدودیت درخواست باز

اگر انباره شمارنده در دسترس نباشد، هزینه نامعلوم است، و هزینه نامعلوم در برابر سقفی سخت فقط یک تفسیر امن دارد: درخواست رد شود، گویی سقف پر شده است. به این رفتار «بسته‌ماندن در خرابی» (fail closed) می‌گویند.

محدودکننده درخواست، برعکس، در خرابی باز می‌ماند (fail open) و درخواست‌ها را عبور می‌دهد، چون از کار افتادن کش نباید کل سایت را از دسترس خارج کند. بدترین پیامد محدودکننده‌ای که در خرابی باز بماند، چند درخواست اضافه است؛ بدترین پیامد سقف هزینه‌ای که در خرابی باز بماند، صورت‌حسابی بی‌حد.

برای هر IP سه محدودیت وجود دارد که در بازه یک دقیقه، یک ساعت و یک روز دوباره پر می‌شوند، و کلیدشان نشانی‌ای است که پراکسی لبه (edge proxy) دیده است، نه سرآیندی که کلاینت بتواند خودش بنویسد. این محدودیت‌ها اسکریپت‌ها را کند می‌کنند؛ سقف ماهانه پشتوانه نهایی مهار هزینه است، نه تضمین آن.

وقتی خواننده می‌رود، هزینه هم باید قطع شود

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

آنچه پیش از این توقف تولید شده، تولید شده است و بهایش را ارائه‌دهنده حساب می‌کند؛ پس به حساب ماه هم ثبت می‌شود. هر دو پروتکل ارائه‌دهنده، مصرف را در رویدادی پایانی گزارش می‌کنند که جریان نیمه‌کاره هرگز به آن نمی‌رسد؛ برای همین سرویس هر نویسه‌ای را که دریافت کرده نگه می‌دارد و فقط جای خالی گزارش ارائه‌دهنده را با همان نرخ یک توکن برای هر بایت پر می‌کند. هر جا ارائه‌دهنده عددی گزارش کرده باشد، همان عدد ملاک است: نوبتی که تا پایان پیش رفته، دقیقاً همان چیزی را ثبت می‌کند که ارائه‌دهنده گفته است، نه تقریبی از آن.

چگونه RAG را ارزیابی کنیم: دقت امتناع، recall@k و اتکا به منبع

سه ویژگی اهمیت دارد. دقت امتناع می‌سنجد که آیا دستیار آنچه را باید رد کند، رد می‌کند. معیار recall@k می‌سنجد که آیا شواهد به دست مدل می‌رسد. اتکا به منبع (groundedness) می‌سنجد که آیا پاسخ درون همان شواهد می‌ماند. در این سایت، یک مجموعه طلایی (golden set) از پرسش‌ها به هر ده زبان سایت، که بیشترشان انگلیسی و فارسی‌اند، در هر اجرای CI به‌صورت قطعی و بدون هیچ فراخوانی مدل نمره می‌گیرد.

دقت امتناع: دو مجموعه، بدون نمره جزئی

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

برای گذشتن از CI، هر دو مجموعه باید نمره کامل بگیرند. یک امتناعِ انجام‌نشده یعنی تعهدی ساختگی روی سایت یک شخص واقعی، و میانگین‌گرفتن همین خطا را پنهان می‌کرد. همان اجرا خطای وارونه را هم می‌سنجد: پرسش‌های پاسخ‌پذیری که الگوها یا آستانه بی‌جا رد کرده‌اند. پرسش‌های متداول ارزیابی (evals FAQ) نوشته Hamel Husain و Shreya Shankar قضاوت قبول یا رد را بر مقیاس‌های امتیازدهی ترجیح می‌دهد، چون «ارزیابی‌های دودویی ارزیاب را به فکر روشن‌تر و برچسب‌گذاری یکنواخت‌تر وا می‌دارند».

پرسش‌هایی را که باید رد شوند اینجا نقل نمی‌کنم: این نوشته وارد پیکره دستیار می‌شود و نقل آن‌ها باعث می‌شد همان پرسش‌ها با این صفحه تطبیق کلیدواژه‌ای قوی پیدا کنند.

سنجش recall@k با k کوچک‌تر از مقدار پیش‌فرض

در مجموعه طلایی، معیار recall@k می‌پرسد آیا دست‌کم یک قطعه که به پرسش پاسخ می‌دهد در میان k نتیجه برتر هست یا نه؛ یعنی در عمل نرخ اصابت (hit rate) را می‌سنجد. Anthropic در نوشته Contextual Retrieval تعریف سخت‌گیرانه‌تری به کار می‌برد، یعنی سهم اسناد مرتبطی که بازیابی می‌شوند، و معیار شکست خود را «۱ منهای recall@20» گزارش می‌کند.

مجموعه طلایی recall را با k برابر ۵ می‌سنجد، کمتر از top-k پیش‌فرض دستیار که ۸ است، چون در پیکره آزمونی با چند ده قطعه، هشت نتیجه برتر سهم بزرگی از کل پیکره است و سنجش در آن نقطه، بازیاب را بهتر از واقع نشان می‌دهد.

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

در ارزیابی آفلاین، اتکا به منبع معمولاً با معیار faithfulness (وفاداری به زمینه) سنجیده می‌شود. مستندات Ragas آن را شمار ادعاهایی از پاسخ که زمینه بازیابی‌شده پشتیبانی‌شان می‌کند، تقسیم بر کل ادعاهای پاسخ تعریف می‌کند، در بازه ۰ تا ۱؛ در شکل استاندارد، یک LLM ادعاها را استخراج و بررسی می‌کند.

داورهای LLM هم سودمندند و هم سوگیری دارند. Zheng و همکارانش سوگیری نسبت به جایگاه پاسخ، پاسخ‌های پرگوتر و پاسخ‌های خودِ مدل داور را گزارش کردند، در حالی که داورهای قوی همچنان به بیش از ۸۰٪ توافق با ترجیحات انسانی رسیدند. Husain و Shankar توصیه می‌کنند نرخ مثبت واقعی (TPR) و نرخ منفی واقعی (TNR) داور روی مجموعه‌ای برچسب‌خورده که کنار گذاشته شده است (held-out) سنجیده شود، و هر جا قاعده‌ای می‌تواند حکم کند، کار با بررسی‌های ارزان مبتنی بر کد آغاز شود.

این سایت راه مبتنی بر کد را برگزیده است: گیت جمله‌ای اتکا به منبع را در زمان اجرا اعمال می‌کند، و هیچ معیار faithfulness یا داور LLM در CI اجرا نمی‌شود.

مجموعه طلایی من چه چیزی را ثابت نمی‌کند

• مدل embedding جانشین است. بازیابی در CI از یک مدل درهم‌سازی «کیسه توکن‌ها» (bag-of-tokens hashing) استفاده می‌کند که هیچ معنای آموخته‌ای ندارد. مسیریابی، ادغام، رتبه‌بندی، انتخاب top-k و تصمیم درباره شواهد، از جمله مقایسه با آستانه، همان کد عملیاتی است؛ فقط امتیازدهی قطعه‌های نامزد، که در محیط عملیاتی درون پایگاه داده انجام می‌شود، در خود آزمون بازسازی شده است. پس CI پسرفتِ سازوکار مسیریابی و رتبه‌بندی را می‌گیرد، نه پسرفت کوئری پایگاه داده یا recall دستیار زنده را، و مدل جانشین حتی فهرستی تنک (sparse) را به کار می‌گیرد که محیط عملیاتی از آن استفاده نمی‌کند.

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

• بررسی‌های زنده فرمان‌اند، نه بخشی از CI. آزمونی که قرار است مجموعه طلایی را به بازیاب مستقر بفرستد همچنان کنار گذاشته می‌شود (skip). فرمانی که فقط بازیابی را اجرا می‌کند، پرسش‌های طلایی و پیشنهادی را بدون فراخوانی مدل از مدل embedding مستقر می‌گذراند، و اسکریپتی که پس از هر درون‌ریزی محتوا به‌صورت دستی اجرا می‌شود، پرسش‌هایی را که باید رد شوند از دستیار زنده می‌پرسد.

• پاسخ‌هایی که از رکوردها ساخته می‌شوند فقط با گیت بررسی می‌شوند. CI بررسی می‌کند کدام پرسش‌ها به رکوردهای سایت می‌رسند و کدام رکوردها را می‌گیرند، روی داده‌ای ثابت (fixture) و با جانشینی برنامه‌ریزی‌شده به‌جای مدل. اینکه یک مدل واقعی پاسخ را از روی آن‌ها چگونه می‌نویسد، در زمان اجرا و با گیت بررسی می‌شود.

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

ساختار به‌جای اعتماد در یک دستیار قرارداد

در کارتز کانترکت (Kartez Contract)، فضای کاری سه‌زبانه‌ای برای قرارداد، مهندس هوش مصنوعی بودم؛ پروژه‌ای که یک ماه مانده به اتمام، به دلیل مشکلات مالی ناشی از جنگ، از سوی کارفرما متوقف شد. در آنجا پایبندی مدل به متن با ساختار تأمین شد، نه با اعتماد: پاسخ‌ها فقط از بندهای انتخاب‌شده استفاده می‌کنند، اصلاحات موظف‌اند متن موجود را عیناً نقل کنند، خروجی‌ها از قالب‌های ثابت پیروی می‌کنند و مدل هنگام نگارش با میزان تصادفی‌بودن پایین اجرا می‌شود. این‌ها قیدهای طراحی‌اند، نه تضمینی سنجیده‌شده. آستانه و گیتی که بالاتر شرح دادم به دستیار همین سایت تعلق دارند، نه به کارتز. مطالعه موردی کارتز کانترکت خود پروژه را شرح می‌دهد. اینکه این الگوها در هوش مصنوعی قرارداد چه شکلی دارند و چرا مجموعه ارزیابی باید پیش از همه ساخته شود، در توهم هوش مصنوعی حقوقی: چه باید ساخت؟ آمده است.

چک‌لیست لایه‌های محافظ برای یک دستیار RAG عملیاتی

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

• روی شباهت آستانه بگذارید، نه روی امتیاز رتبه. شباهت کسینوسی می‌تواند آستانه داشته باشد، و پوشش واژه کامل هم، به شرط آنکه واژه‌های پربسامد حذف شوند و دست‌کم دو واژه محتوایی تطبیق یابند؛ امتیاز RRF نمی‌تواند. زیر آستانه، مدل را فراخوانی نکنید و با متن ثابت امتناع کنید.

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

• آستانه را روی همان مدل embedding که مستقر می‌کنید کالیبره کنید. آستانه‌ای که روی مدل جانشین بررسی شده، فقط مقدار پیش‌فرض است.

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

• جریان پاسخ را جمله‌به‌جمله کنترل کنید. نشانگر منبع را الزامی کنید؛ اعداد، URLها و ایمیل‌ها را عیناً بررسی کنید؛ از جمله ردشده به بعد هیچ چیز ارسال نکنید؛ و برای پاسخ ناتمام اعلانی جدا از پاسخ ساختگی نشان دهید.

• در دستیاری که درباره یک شخص یا شرکت سخن می‌گوید، اول شخص را ممنوع کنید و مستند کنید بررسی کجا ضعیف‌تر است؛ در فارسی، شناسه‌های فعل.

• پیش از فراخوانی، کران بالای هزینه را رزرو کنید، نه یک برآورد سخاوتمندانه. در توکنایزر BPE بایت‌محور، شمار بایت‌های پرامپت در UTF-8 یکی از همین کران‌هاست. رزرو را به‌صورت اتمی (atomic) انجام دهید تا درخواست‌های هم‌زمان نتوانند همگی از بررسی بگذرند، اگر شمارنده در دسترس نبود درخواست را رد کنید، و با قطع اتصال، کار سمت ارائه‌دهنده را لغو کنید.

• هزینه هر فراخوانی را ثبت کنید، از جمله فراخوانی‌هایی که نیمه‌کاره قطع شده‌اند: متن را همان‌طور که استریم می‌شود نگه دارید و تنها جای خالیِ رویداد پایانی ارائه‌دهنده را پر کنید.

• امتناع را جدا از recall بسنجید. مدل embedding، اندازه مجموعه‌ها و آنچه را اجرا ثابت نمی‌کند بنویسید.

پرسش‌های متداول

آیا RAG توهم هوش مصنوعی را از بین می‌برد؟

خیر. ابزارهای پژوهش حقوقی LexisNexis و Thomson Reuters که بر RAG تکیه دارند، در یک مطالعه پیش‌ثبت‌شده همچنان در ۱۷٪ تا ۳۳٪ موارد دچار توهم شدند، و زمینه ناکافی می‌تواند مدل را به‌جای محتاط‌تر، مطمئن‌تر کند. بازیابی احتمال پاسخ درست را بالا می‌برد؛ تضمین از بررسی‌هایی بیرون از مدل می‌آید.

آستانه شباهت مناسب برای RAG چیست؟

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

آیا پرامپت سیستم برای جلوگیری از توهم کافی است؟

خیر. OWASP توصیه می‌کند «تا جای ممکن» از پرامپت سیستم برای کنترل رفتار مدل استفاده نشود و به «سامانه‌هایی بیرون از LLM» تکیه شود، و راهنمای Anthropic می‌گوید روش‌های پرامپت‌نویسی توهم را کاهش می‌دهند اما از بین نمی‌برند. پرامپت را نگه دارید و برای هر دستوری که اهمیت دارد، بررسی قطعی‌ای بیرون از مدل بگذارید.

آیا داور LLM می‌تواند جای بررسی‌های قطعی را بگیرد؟

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

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

پیش از فراخوانی مدل، کران بالای هزینه آن را به‌صورت اتمی رزرو کنید — در توکنایزر BPE بایت‌محور، شمار بایت‌های پرامپت در UTF-8 چنین کرانی است، در هر زبانی — و اگر شمارنده در دسترس نیست، درخواست را رد کنید. هزینه هر فراخوانی را ثبت کنید، از جمله فراخوانی‌هایی که نیمه‌کاره قطع شده‌اند: متن استریم‌شده را نگه دارید و آنچه را رویداد پایانی ارائه‌دهنده گزارش نکرده است پر کنید. به‌جای پیام خطا متن ثابت نشان دهید، و با قطع اتصال کلاینت، تولید پاسخ را در سمت ارائه‌دهنده لغو کنید. OWASP این خطر را با عنوان LLM10:2025 Unbounded Consumption فهرست می‌کند که Denial of Wallet را هم در بر می‌گیرد.

منابع

• مقاله Magesh و همکاران (۲۰۲۴): Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools

• وبلاگ Google Research (۱۴ مه ۲۰۲۵): Deeper insights into retrieval augmented generation: The role of sufficient context

• مقاله Joren و همکاران (۲۰۲۴، ویرایش ۲۰۲۵): Sufficient Context: A New Lens on Retrieval Augmented Generation Systems

• مقاله Kalai و همکاران (۲۰۲۵): Why Language Models Hallucinate

• مقاله Cormack و Clarke و Büttcher در کنفرانس SIGIR سال ۲۰۰۹: Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods

• پروژه OWASP GenAI: LLM07:2025 System Prompt Leakage

• مستندات Anthropic: Reduce hallucinations

• مستندات NVIDIA NeMo Guardrails: Output Rail Streaming Configuration

• پروژه OWASP GenAI: LLM09:2025 Misinformation

• وبلاگ TechLex مؤسسه McCarthy Tétrault (۱۹ فوریه ۲۰۲۴): Moffatt v. Air Canada: A Misrepresentation by an AI Chatbot

• وبلاگ Inquisitive Minds مؤسسه Bristows (۲۷ مارس ۲۰۲۴): AI Chatbot flies solo and Air Canada foots the bill - Moffatt v. Air Canada

• پروژه OWASP GenAI: LLM10:2025 Unbounded Consumption

• پرسش‌های متداول ارزیابی Hamel Husain و Shreya Shankar (آخرین ویرایش ۱۳ سپتامبر ۲۰۲۶): AI Evals: Everything You Need to Know

• وبلاگ مهندسی Anthropic (۱۹ سپتامبر ۲۰۲۴): Introducing Contextual Retrieval

• مستندات Ragas: Faithfulness

• مقاله Zheng و همکاران، بخش Datasets and Benchmarks کنفرانس NeurIPS سال ۲۰۲۳: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

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