یک پست با برچسب "قابلیت عملیاتی"

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

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

ساعت ۹:۱۷ صبح​

ساعت ۹:۱۷ صبح است. فقط هفده دقیقه از راه‌اندازی دستیار جدید سازمان گذشته و یکی از مهندسان تیم، اولین پیام را می‌بیند:

«پاسخ درست بود، ولی چرا ۲۸ ثانیه طول کشید؟»

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

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

این صحنه گزارش یک رخداد واقعی در شرکت مشخصی نیست؛ سناریویی ترکیبی و فرضی است که failure modeهای گزارش‌شده در پژوهش‌های RAG را کنار هم می‌گذارد. بااین‌حال پرسش آن کاملا واقعی است: وقتی مدل «جواب می‌دهد» اما نمی‌توان به سرویس اعتماد کرد، باید دنبال ایراد کجا بگردیم؟

این رخداد ساختگی است، اما از مسئله هایی ساخته شده که در پژوهش های RAG بارها گزارش شده اند.