هیچ چیز به اندازه‌ی دیدن یک داشبورد نظارتی کاملاً سبز با تأخیر زیر ۱۰۰ میلی‌ثانیه ترس‌ناک نیست، به‌ویژه وقتی درست در همان لحظه یک مشتری سازمانی برای شما اسکرین‌شاتی از دروغ‌گویی هوش مصنوعی‌تان به کاربرانش ایمیل می‌کند.

دقیقاً شش ماه پیش، تیم من یک مدل بازیابی-افزوده (RAG) برای یک مشتری فین‌تک تحویل داد. وظیفه ما ایجاد سیستمی بود که بتواند هزاران PDF بدون ساختار حاوی گزارش‌های مالی را پردازش کند، داده‌های حیاتی استخراج کند، تعبیه‌ها (embeddings) را محاسبه کرده و همه چیز را در یک پایگاه داده برداری ذخیره کند تا ربات گفتگوی داخلی را تغذیه کند.

سیستم در ابتدا بی‌نقص کار می‌کرد. اما پس از مدتی، ربات گفتگو شروع به پاسخ‌دادن به سوالات درباره عملکرد شرکت در سال ۲۰۲۲ کرد، در حالی که داده‌های سال ۲۰۱۸ را استناد می‌کرد. همچنین درآمد رقبا را به شرکت‌های تابعه مشتری نسبت می‌داد. نکته ترس‌ناک این بود که سیستم اطلاعات را از پایگاه داده برداری به درستی بازیابی می‌کرد. مشکل از خط لوله RAG نبود؛ ما پایگاه داده را با یک موتور بلع خودکار معیوب مسموم کرده بودیم.

اشتباه کجا بود؟ توهم در فرآیند بلعیدن

گردش کار ما از یک خط لوله استاندارد هوش مصنوعی پیروی می‌کرد. به محض قرارگرفتن PDF در سطل S3، فرآیند بلعیدن یک عامل استخراج را راه‌اندازی می‌کرد که با کمک یک LLM پیشرو، تکه‌های متن و فراداده‌هایی مانند document_type، fiscal_year، company_entity و خلاصه‌ای به صورت JSON استخراج می‌کرد. این فراداده‌ها سپس به تکه‌های متن اضافه و برای تعبیه به فروشگاه برداری ارسال می‌شدند.

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

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

چرا شگفت‌انگیز بود: شکست «LLM به عنوان قاضی»

اتاق پژواک هوش مصنوعی مفهوم «LLM به عنوان قاضی» را دوست دارد. خرد رایج می‌گوید اگر به خروجی یک LLM اعتماد ندارید، یک LLM دیگر را برای بررسی قرار دهید. ما دقیقاً این کار را کردیم: یک «عامل تأییدکننده» ثانویه، JSON استخراج‌شده را در برابر متن خام ارزیابی می‌کرد.

پس چرا توهمات از قلم افتادند؟ چون چاپلوسی LLM (LLM Sycophancy) را دست کم گرفته بودیم. وقتی لاگ‌ها را بررسی کردیم، عامل تأییدکننده به طور مداوم با عامل استخراج موافقت می‌کرد. اگر عامل استخراج {"fiscal_year": 2024} را تولید می‌کرد، عامل تأییدکننده متن را اسکن می‌کرد، سالی پیدا نمی‌کرد و به جای رد بار، در خود منطقی می‌کرد: «خب، مدل اول باید چیزی را دیده باشد که من ندیدم.»

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

چه چیزی کار نکرد: تله مهندسی پرامپت

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

  • «توهم نداشته باش»
  • «اگر ۱۰۰٪ مطمئن نیستی، NULL خروجی بده»
  • «تو یک حسابرس مالی سختگیری؛ حدس زدن منجر به جریمه می‌شود»

نتیجه؟ شکست مطلق. LLM بیش از حد تدافعی شد و داده‌های کاملاً خوب را رد کرد. علاوه بر این، هزینه API ما ۴۰٪ افزایش یافت. انتظار اینکه یک ماتریس ریاضی از یک طرحواره سختگیرانه پیروی کند، تنبلی فکری بود.

راه‌حل نهایی: کد بر پرامپت‌ها

مشخص شد که باید تمام اختیارات تصمیم‌گیری را از فرآیند تأیید حذف کنیم. خطوط لوله داده به قراردادهای سختگیرانه (contracts) و منطق قطعی نیاز دارند، نه قضاوت احتمالی. ما یک لایه تأیید مبتنی بر قوانین (rule-based) اضافه کردیم که پس از استخراج، صحت فراداده را با اسکن مستقیم متن بررسی می‌کرد. اگر سال مالی در متن یافت نمی‌شد، کل رکورد رد می‌شد و فرآیند استخراج دوباره با پارامترهای متفاوت اجرا می‌شد.

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

درس‌های آموخته‌شده

  1. احتمالی را قطعی نگیرید: LLMها ماشین‌های حدس‌زن هستند؛ هر خروجی آن‌ها نیاز به اعتبارسنجی قطعی دارد.
  2. LLM قاضی خوبی نیست: استفاده از LLM برای تأیید LLM دیگر تنها به حلقه تعصب دامن می‌زند. از منطق قطعی یا قاعده‌محور استفاده کنید.
  3. هزینه مهندسی پرامپت: پرامپت‌ها نمی‌توانند محدودیت‌های ذاتی مدل را برطرف کنند. کد بزنید، نه پرامپت.
  4. شفافیت در ورودی: همیشه فراداده‌های استخراج‌شده را قبل از ورود به پایگاه داده برداری به صورت قطعی تأیید کنید.

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