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

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

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

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

قیف بازیابی

هسته این سیستم یک قیف است: ابتدا بازیابی گسترده، سپس ترتیب‌بندی دقیق و در نهایت گیت شواهدی. این معماری وظایف را تفکیک می‌کند؛ یک اپلیکیشن Node.js برای نقاط انتهایی HTTP و وضعیت گفتگو، و یک سرویس کوچک Python برای کارهای سنگین ایندکس‌گذاری، ادغام و ارزیابی.

این مرز تعمدی است. این جداسازی اجازه می‌دهد نوت‌بوکی که آزمایش‌های بازیابی در آن شروع می‌شود، از همان توابعی استفاده کند که محیط تولید (Production) فراخوانی می‌کند، بدون اینکه منطق رتبه‌بندی به یک فریم‌ورک وب گره بخورد. جریان داده در محیط تولید به گونه‌ای طراحی شده است که به راحتی قابل بازرسی باشد: پرسش $ \rightarrow $ دو بازیاب $ \rightarrow $ کاندیداهای ادغام‌شده $ \rightarrow $ بازرتبه‌بندی $ \rightarrow $ آستانه شواهدی $ \rightarrow $ پاسخ مستند.

برای پیاده‌سازی، مستندات ابتدا به تکه‌های کوچکی تقسیم می‌شوند که به آن‌ها تکه‌بندی (Chunking) — مثل برش‌های یک کیک طولانی که مدل تکه‌تکه می‌خورد — می‌گویند. هر تکه باید URL منبع، مسیر سرتیتر (Heading Path) و یک شناسه مستند پایدار را حفظ کند. هر تکه دو بار ایندکس می‌شود: یک بار در ایندکس لغت‌نامه‌ای برای عبارات دقیق و یک بار به صورت بردار معنایی (Embedding) — مثل کارت معرفی عددی برای هر واژه که همسایگی معنایی آن را مشخص می‌کند — برای شباهت‌های مفهومی. در زمان پرس‌وجو، سیستم به‌طور همزمان از هر دو ایندکس بازیابی را انجام می‌دهد.

جست‌وجوی ترکیبی و ادغام رتبه‌ها

بازیابی بر اساس کلمات کلیدی هرگاه مستندات شامل رشته‌های نسخه، نام متدها، کدهای خطا، کلیدهای پیکربندی و واژگان خاص محصول باشد، ضروری است. در مقابل، بازیاب‌های برداری خطاهای متفاوتی را پوشش می‌دهند؛ مثلاً وقتی کاربر می‌گوید «نشست من منقضی می‌شود» اما در مستندات عبارت «عمر نشست» (session lifetime) به کار رفته است.

به دلیل اینکه شباهت کسینوسی (Cosine Similarity) (مثلاً ۰.۷۸) و امتیازات لغت‌نامه‌ای (مثلاً ۱۲.۴) واحدهای ناسازگاری هستند، نمی‌توان آن‌ها را با یک عبارت حسابی ساده ترکیب کرد. این سیستم از روش Reciprocal Rank Fusion (RRF) در این مرز استفاده می‌کند. RRF بر اساس جایگاه، سهمی را اختصاص می‌دهد: $1 / (k + rank)$ که در آن $k$ یک ثابت تنظیم (معمولاً ۶۰) است.

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

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

پس از ادغام لیست‌ها، سیستم همه موارد را به مدل نمی‌فرستد. یک مجموعه کوچک کاندیدا (مثلاً ۲۰ مورد برتر) انتخاب شده و از طریق یک بازرتبه‌بندی (Reranking) در برابر پرسش اصلی سنجیده می‌شوند. این کار باعث حذف موارد تکراری می‌شود — به این معنی که متنی که دو بار بازیابی شده است، تنها یک جایگاه در ورودی مدل اشغال می‌کند — و تضمین می‌کند که فقط مرتبط‌ترین بستر، توکن‌های (Token) — تکه‌های کوچکی از متن که مدل مصرف می‌کند — ورودی مدل را اشغال کند.

پیاده‌سازی گیت شواهدی

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

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

• جمع‌آوری امتیازات بازرتبه‌بندی برای پرسش‌های پشتیبانی‌شده و پشتیبانی‌نشده در همان مجموعه داده خاص.
• انتخاب آستانه بر اساس خطای خاصی که تیم می‌خواهد به حداقل برساند.
• حفظ یک مسیر سخت‌گیرانه برای «خودداری از پاسخ» (Abstention Path).

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

جزئیات: بهینه‌سازی و موازنه

طراحی خط لوله بازیابی نیازمند موازنه بین بستر و هزینه است. مکانیزم‌های زیر برای تنظیم حیاتی هستند:

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

حفاظ‌های تولیدی و امنیت

به نقل از راهنمای OWASP برای برنامه‌های LLM، سیستم‌های بازیابی باید در برابر تزریق پرامپت (Prompt Injection) و افشای اطلاعات حساس دفاع کنند. این معماری لایه‌های ایمنی زیر را اجرا می‌کند:

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

مدیریت خطا و نسخه‌بندی

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

• محدودیت نرخ (Rate Limiting): مدیریت خطای ۴۲۹ با سقف تلاش مجدد ثابت و یک ضرب‌الاجل کلی برای درخواست، تا از مصرف کل بودجه تأخیر قبل از شروع تولید پاسخ جلوگیری شود.
• اعتبارسنجی خروجی: رد فوری خروجی‌های بدشکل بازرتبه‌بندی.
• همگام‌سازی نسخه‌ها: اگر ایندکس لغت‌نامه‌ای به‌روز شد اما ایندکس برداری نسخه قدیمی را ارائه می‌دهد، هر نتیجه باید مهر نسخه داشته باشد تا نسخه‌ها در یک پاسخ مخلوط نشوند.
• بازیابی جزئی: تفاوت بین یک جست‌وجوی موفق اما خالی، با بازیابی جزئی را مشخص کنید؛ در مورد دوم باید به فراخوان‌کننده اطلاع داده شود که سیستم تمام منابع پیکربندی‌شده را بررسی نکرده است.

تست و کالیبراسیون

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

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

• میزان Recall در مرحله کاندیداها.
• کیفیت رتبه‌بندی در رده‌های برتر.
• صحت ارجاعات و دقت در خودداری از پاسخ.
• توکن‌های ارسالی به بازرتبه‌بندی و مدل پاسخ.

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

چه زمانی از این پیچیدگی اجتناب کنیم؟

این رویکرد ترکیبی در موارد زیر بیش از حد پیچیده (Overkill) است:

• وقتی مجموعه داده آنقدر کوچک است که جست‌وجوی قطعی (Deterministic) کافی است.
• وقتی فیلترهای ساختاریافته (پرس‌وجوهای پایگاه‌داده) می‌توانند پاسخ دهند.
• وقتی تیم توان نگهداری دو ایندکس و یک مجموعه ارزیابی سخت‌گیرانه را ندارد.
• برای مجموعه‌هایی که مترادف‌ها در آن‌ها ارزش کمی دارند (فقط از جست‌وجوی لغت‌نامه‌ای استفاده کنید).
• وقتی بازیابی ادغام‌شده در حال حاضر هدف top-k را در محدوده بودجه تأخیر برآورده می‌کند و بازرتبه‌بندی را غیرضروری می‌سازد.

چک‌لیست عملیاتی

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

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

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

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.