چرا AI پاسخ درست را پیدا می‌کند اما از آن استفاده نمی‌کند؟ راهنمای تشخیص و رفع

پاسخ درست در پایگاه دانش هست، اما در پاسخ نهایی غایب است

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

در عمل باید دو نوع شکست کاملاً متفاوت را از هم جدا کرد: شکست بازیابی (سند درست در فهرست نتایج نیست) و شکست وفاداری یا به‌کارگیری (سند درست در زمینه ارسالی هست، ولی مدل بر پایه آن استدلال نمی‌کند). این دو، تیم مسئول، هزینه رفع و ابزار سنجش متفاوتی دارند. تا وقتی این تفکیک انجام نشود، هر بهبودی در پایگاه برداری یا هر تعویض مدلی، در نیمی از موارد فقط هزینه است و نه راه‌حل.

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

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

چرا مدل شواهد درست را نادیده می‌گیرد؟ مکانیزم‌های رایج

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

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

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

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

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

چیدمان زمینه و الزام به استناد: اصلاحات سمت تولید پاسخ

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

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

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

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

وقتی نادیده گرفتن پاسخ، رفتار درست است: سیاست، اختیار و دروازه تصمیم

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

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

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

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

آزمون اوراکل و سنجش جداگانه: چگونه لایه خراب را پیدا کنیم

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

گام دوم، جدا کردن سنجه‌هاست. باید دو معیار مستقل داشته باشید: یکی برای کیفیت بازیابی (آیا شواهد درست در فهرست نتایج هستند؟) و یکی برای وفاداری پاسخ (آیا ادعاهای پاسخ به شواهد ارائه‌شده قابل ارجاع هستند؟). اگر این دو را در یک عدد ترکیب کنید، هر بهبودی در یکی، افت دیگری را پنهان می‌کند. یک مجموعه طلایی از پرسش‌های واقعی سازمان با شواهد برچسب‌خورده بسازید و آن را در هر تغییر قطعه‌بندی یا مدل嵌入 دوباره اجرا کنید.

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

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

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

اگر می‌خواهید این مشکل را در عمل کم کنید، لازم نیست همه‌چیز را هم‌زمان بازسازی کنید. ترتیب زیر بر اساس نسبت اثر به هزینه چیده شده است: از کارهای ارزان و سریع شروع می‌شود و به تغییرات ساختاری می‌رسد. تمرکز اصلی روی این است که در هر گام بتوانید تفاوت را اندازه بگیرید، وگرنه تغییرات روی هم انباشته می‌شوند و دیگر نمی‌دانید کدام‌یک کمک کرده است.

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

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

نتیجه‌گیری: مسئله معمولاً بازیابی نیست، معماری استفاده از شواهد است

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

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

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