اگر امروز برای ساخت دستیارهای مستندات فنی از عامل‌های هوش مصنوعی استفاده می‌کنید، احتمالاً بخشی از اعتبار پاسخ‌هایتان را بدون اینکه بدانید از دست می‌دهید. یک بررسی فنی نشان می‌دهد که SDK عامل‌های OpenAI (OpenAI Agents SDK) در ۴۰٪ از پاسخ‌های تست‌شده نتوانسته است فرمت‌های ارجاع درخواستی را حفظ کند. این موضوع یک شکاف دیده‌شدن (Visibility Gap) بحرانی برای توسعه‌دهندگانی ایجاد می‌کند که به هوش مصنوعی مستند (Grounded AI) متکی هستند. این یافته ثابت می‌کند که مرز بین یک سرور بازیابی داده و یک عامل هوش مصنوعی، دقیقاً همان جایی است که زنجیرهٔ اثبات واقعیت و منشأ داده‌ها (Factual Provenance) اغلب پاره می‌شود.
بسیاری از توسعه‌دهندگان تصور می‌کنند اگر ابزار بازیابی یک لینک منبع (Source URL) را ارائه دهد، عامل آن را به‌سادگی و بدون تغییر به کاربر می‌رساند. اما در واقعیت، عامل مانند یک فیلتر عمل می‌کند که می‌تواند به‌طور خاموش این لینک‌ها را حذف کند یا آن‌ها را تغییر دهد (Mutate). این موضوع به‌ویژه برای دستیارهای مستندات خطرناک است؛ چون پاسخی درباره یک API که درست است اما منبع ندارد، قابل تأیید نیست و کاربر نمی‌تواند برای بررسی موارد خاص (Edge Cases) روی لینک کلیک کرده و به صفحه مربوطه برود. بدتر از آن، پاسخی است که به صفحه اشتباه ارجاع می‌دهد؛ چنین پاسخی در ظاهر تأییدشده به نظر می‌رسد در حالی که در واقعیت نیست.
برای اندازه‌گیری این پدیده، پژوهشگری یک محک (Benchmark) طراحی کرد تا به یک سؤال مشخص پاسخ دهد: وقتی یک پایگاه دانش تولید بازیابی‌افزا (RAG) توسط یک عامل هوش مصنوعی از طریق پروتکل زمینهٔ مدل (MCP - Model Context Protocol) مصرف می‌شود، آیا ارجاعات در برابر فرآیند پاسخ‌دهی زنده می‌مانند یا خیر؟ این پروتکل به دلیل انعطاف‌پذیری بالا، پیش‌تر برای تبدیل عامل‌های هوشمند به متخصصان SEO مورد استفاده قرار گرفته است. این آزمایش به‌جای یک فراخوانی ساده‌ی «بازیابی-سپس-پاسخ»، پیچیدگی‌های تعامل عامل را بررسی کرد.
جزئیات آزمایش و ساختار محک
این آزمایش برای شبیه‌سازی دقیق و بازتولیدپذیرِ مرز بین سرور بازیابی و عامل طراحی شد. اجزای این سیستم عبارت بودند از:
- مجموعه داده (The Corpus): مستندات FastAPI شامل ۱۵۳ صفحه که به ۲۰۸۵ تکه (Chunk) با شناسایی سرتیترها (Heading-aware) تقسیم شده بودند. FastAPI به‌دلیل داشتن مارک‌داون‌های تمیز، URLهای عمومی پایدار و استفاده گسترده انتخاب شد.
- سرور MCP: یک ابزار واحد به نام
search_fastapi_knowledge_sourcesکه دقیقاً جفت{source_url, content}را روی پروتکل HTTP قابل استریم (Streamable) برمی‌گرداند. این ساختار دقیقاً قرارداد یک محصول بازیابی MCP واقعی، حتی در الگوهای نام‌گذاری، را منعکس می‌کند. این قابلیت اتصال به داده‌های زنده، مشابه رویکردی است که پروتکل MCP برای ایجاد نقشه‌های ذهنی تعاملی در محیط‌های چت به کار می‌برد. - پرسش‌ها: در ابتدا ۲۵۰ سؤال پیش‌نویس شد که پس از تأیید دستی در برابر مستندات، ۱۲۷ سؤال نهایی شدند. این مجموعه شامل ۸۲ سؤال بود که پاسخشان در یک صفحه بود، ۲۹ سؤال که به دو یا چند صفحه نیاز داشتند، و ۱۶ سؤال که اصلاً در مستندات نبودند تا بتوان توهمات (Hallucinations) مدل را شناسایی کرد.
سه خط لوله (Pipeline) با استفاده از مدل یکسان (gpt-4o-mini)، مستندات یکسان، پرامپت سیستمی یکسان و فرمت ارجاع اجباری یکسان (قرار دادن [url] بلافاصله بعد از هر ادعا) تست شدند:
۱. RAG تک‌مرحله‌ای (Single-shot RAG): یک بار جست‌وجو و سپس پاسخ. این حالت به‌عنوان گروه کنترل (Control) عمل کرد.
۲. عامل LangGraph: یک عامل ReAct که خودش تصمیم می‌گیرد چه زمانی و چند بار ابزار MCP را فراخوانی کند.
۳. عامل OpenAI Agents SDK: ساخته شده با فریم‌ورک عامل‌های OpenAI و پشتیبانی داخلی از MCP.
معیار نرخ بقای ارجاع (CSR)
برای اندازه‌گیری موفقیت ارجاعات، صرفاً شمردن تعداد URLها کافی نبود. یک پاسخ می‌تواند پر از لینک باشد اما ارجاعاتش اشتباه باشد، یا ممکن است به یک URL محتمل از FastAPI ارجاع دهد که عامل هرگز آن را بازیابی نکرده است (چون مدل‌ها می‌دانند ساختار لینک‌های FastAPI چگونه است).
پژوهشگر معیار نرخ بقای ارجاع (Citation Survival Rate یا CSR) را تعریف کرد که هر ارجاع را از دو بررسی سخت‌گیرانه عبور می‌دهد:
- بررسی پشتیبانی (The Support Check): آیا تکهٔ ارجاع‌شده واقعاً ادعای مطرح‌شده را تأیید می‌کند؟ هر پاسخ به ادعاهای کوچک اتمی تقسیم می‌شود (با استفاده از رویکرد FActScore) و یک مدل استنتاج (Entailment Model) هر ادعا را در برابر تکهٔ ارجاع‌شده بررسی می‌کند (با استفاده از رویکرد ALCE).
- بررسی ردپا (The Trace Check): آیا این URL واقعاً در داده‌هایی بود که عامل بازیابی کرده بود؟ تمام فراخوانی‌های ابزار ثبت (Log) می‌شوند، بنابراین هر ارجاع به صفحه‌ای که عامل هرگز ندیده است، به‌عنوان «ساختگی» شناسایی می‌شود.
CSR به‌عنوان کسری از منابع صحیحی تعریف می‌شود که عامل واقعاً بازیابی کرده و در نهایت در پاسخ نهایی قرار گرفته‌اند، به‌طوری که منبع واقعاً از ادعای مربوطه پشتیبانی کند. اگر عامل هرگز صفحه درست را پیدا نکند، این یک شکست در بازیابی (Retrieval Failure) است و از محاسبه CSR حذف می‌شود؛ زیرا این معیار فقط اتفاقاتی را می‌سنجد که «بعد» از عبور منبع درست از مرز بازیابی رخ می‌دهد.
شکاف عملکردی و نتایج تکان‌دهنده
نتایج اولیه در اولین مرحله، تفاوت فاحشی را نشان داد:
- RAG تک‌مرحله‌ای: نرخ CSR برابر با ۰.۶۱۸ [بازه اطمینان ۹۵٪: ۰.۵۲۸, ۰.۷۰۸]
- عامل LangGraph: نرخ CSR برابر با ۰.۶۱۴ [بازه اطمینان ۹۵٪: ۰.۵۲۴, ۰.۷۰۵]
- عامل OpenAI Agents SDK: نرخ CSR برابر با ۰.۳۲۳ [بازه اطمینان ۹۵٪: ۰.۲۳۷, ۰.۴۱۴]
عامل LangGraph تقریباً با گروه کنترل برابر بود (تفاوت ۰.۰۰۰ در هر سؤال)، که ثابت می‌کند وجود یک حلقهٔ عامل (Agent Loop) به‌تنهایی باعث از دست رفتن ارجاعات نمی‌شود. اما عامل OpenAI Agents SDK حدود نیمی از ارجاعات را گم کرد: در ۶۶ مورد از ۱۲۷ پاسخ، هیچ ارجاعی با فرمت درخواستی [url] وجود نداشت.
پس از بازرسی دستی آن ۶۶ پاسخ، پژوهشگر متوجه نکته‌ای ظریف شد: SDK لزوماً منابع را گم نمی‌کرد، بلکه فرمت درخواستی را نادیده می‌گرفت. در ۵۱ مورد از ۱۲۷ پاسخ، عامل از لینک‌های مارک‌داون مانند [source](https://...) به‌جای فرمت [url] استفاده کرده بود. ۷ مورد از فرمت‌های دیگر مانند [source: https://...] استفاده کرده بودند و تنها ۸ مورد اصلاً هیچ URLی نداشتند (در حالی که این عدد برای RAG تک‌مرحله‌ای ۱۹ مورد بود).
وقتی سیستم امتیازدهی به‌روز شد تا هر نوع فرمت ارجاع را بشمارد، نتایج تغییر کرد:
- RAG تک‌مرحله‌ای: ۰.۶۱۸ (بدون تغییر)
- عامل LangGraph: ۰.۶۴۳
- عامل OpenAI Agents SDK: ۰.۴۷۰
حتی با یک امتیازدهنده انعطاف‌پذیر، باز هم شکاف باقی ماند. پس از سه بار اجرای هر تنظیمات، یک افت تجمیعی شناسایی شد: ۰.۱۲- با امتیازدهنده اصلی و ۰.۰۹- با استفاده از داور gpt-4o. این افت تقریباً ۶۰٪ مربوط به فرمت‌بندی و ۴۰٪ مربوط به حذف واقعی ارجاعات بود. جالب اینجاست که در دمای (Temperature) صفر، هیچ افتی قابل شناسایی نبود.
ریشه‌یابی: مقصر کیست؟
پژوهشگر از طریق پنج آزمایش کنترل‌شده، علت این «انحراف فرمت» (Format Drift) را ایزوله کرد. عوامل زیر رد شدند:
- حلقهٔ عامل (The Agent Loop): حلقه‌های LangGraph مشابه بود اما فرمت را حفظ کرد. علاوه بر این، عامل‌های SDK به‌ندرت حلقه می‌زدند و به‌طور متوسط ۱.۲ تا ۱.۳ جست‌وجو برای هر پاسخ انجام می‌دادند.
- دما (Temperature): خط لوله SDK دمای مشخصی نداشت. تطبیق آن با دمای صفرِ LangGraph تغییر چندانی در انحراف ایجاد نکرد (تعداد پاسخ‌های بدون
[url]از ۶۰ به ۵۴ کاهش یافت). - لایه انتقال (The Transport): بررسی داده‌های دریافتی مدل از طریق SDK نشان داد که هر تکه با
source_urlدست‌نخورده رسیده است و ۹۸ مورد از ۱۱۸ لینک مارک‌داون دقیقاً به صفحاتی اشاره می‌کردند که عامل بازیابی کرده بود.
مقصر اصلی API بود. به‌صورت پیش‌فرض، OpenAI Agents SDK از Responses API شرکت OpenAI استفاده می‌کند، در حالی که یکپارچگی OpenAI در LangGraph از Chat Completions استفاده می‌کند. تغییر همین عامل SDK به Chat Completions، تعداد پاسخ‌های با فرمت اشتباه را از ۴۱ به ۹ مورد کاهش داد. علاوه بر این، استفاده از یک پرامپت سیستمی منتشرشده برای پاسخ‌های مستند، این تعداد را به ۲۰ مورد رساند. این تغییرات فرمت را اصلاح کرد اما تأثیر چشم‌گیری بر این موضوع که «آیا اصلاً منبع ذکر شود یا خیر» نداشت.
راهکار سمت سرور
از آنجا که ارائه‌دهندگان بازیابی نمی‌توانند کنترل کنند مشتری از چه عاملی استفاده می‌کند، پژوهشگر یک راهکار سمت سرور را تست کرد. به‌جای ارسال URLهای طولانی، سرور تکه‌ها را با شناسه‌های کوتاه منبع (مثلاً [S3fa21c]) برچسب‌گذاری کرد.
از عامل خواسته شد که این شناسه‌های کوتاه را نقل کند و سپس سرور پس از نوشته شدن پاسخ، این شناسه‌ها را دوباره به URLهای کامل تبدیل کرد. در یک محیط آینه‌ای (Mirror) میزبانی‌شده، پاسخ‌های با فرمت اشتباه از حدود ۵۰ مورد به حدود ۵ مورد در هر اجرا کاهش یافت، نرخ CSR عامل SDK بین ۰.۱۰ تا ۰.۱۳ افزایش یافت و شکاف آن با گروه کنترل بسته شد.
اعتبارسنجی و دقت علمی
برای اطمینان از قابلیت اطمینان این محک، چندین لایه حفاظتی اجرا شد:
- امتیازدهی دوگانه: هم از یک مدل استنتاج و هم از داور gpt-4o استفاده شد. داور با قضاوت‌های انسانی کور (Blind Judgments) در سطح κ 0.86 توافق داشت.
- بازرسی انسانی: در ۳۰ مورد کور، احکام CSR در ۲۵ تا ۲۷ مورد با قضاوت‌های انسانی مطابقت داشت. دو مورد از این‌ها دقیقاً همان نقطه کور لینک‌های مارک‌داون بودند که به شناسایی مشکل فرمت‌بندی کمک کرد.
- تکرار: هر تنظیمات gpt-4o-mini سه بار اجرا شد. یک قانون استحکام (Robustness Rule) را اعمال کردند که طبق آن علامت (مثبت/منفی) در هر اجرا باید یکسان باشد و بازه تجمیعی نباید عدد صفر را شامل شود.
- بررسی سخت‌گیرانه: یک بازرسی داخلی از خط لوله، پنج باگ را قبل از انتشار شناسایی کرد. مشکل فرمت‌بندی، ششمین کشف بود که پس از به اشتراک گذاشتن اعداد اولیه اصلاح شد.
نکات کلیدی برای توسعه‌دهندگان
این پژوهش برجسته می‌کند که مسئولیت یکپارچگی ارجاعات نمی‌تواند صرفاً بر دوش پایبندی LLM به یک پرامپت باشد. برای کسانی که RAG را از طریق MCP ارائه می‌دهند، اصول زیر کاربرد دارد:
- مرز، همان حد است: تضمین دقت شما در مرز (Boundary) متوقف می‌شود. شما بازیابی را کنترل می‌کنید، اما عاملی را که پاسخ را می‌نویسد خیر.
- پیش‌فرض‌های فریم‌ورک اهمیت دارند: دو عامل با مدل و پرامپت یکسان، به‌دلیل یک تنظیم پیش‌فرض در API متفاوت رفتار کردند. این پیش‌فرض‌ها بخشی خاموش از معماری سیستم شما هستند.
- تفکیک فرمت از حضور: «عدم وجود ارجاع در فرمت تجزیه‌شده» با «عدم وجود ارجاع» دو شکست متفاوت هستند. شمردن هر دو از نتیجه‌گیری‌های غلط (جایی که انسان لینک را می‌بیند اما سیستم نمی‌تواند آن را بخواند) جلوگیری می‌کند. در این راستا، برخی توسعه‌دهندگان برای حذف توهمات RAG از ترکیب آستانه شباهت و خروجی JSON استفاده کرده‌اند تا دقت پاسخ‌ها را افزایش دهند.
- خروجی‌ها را بخوانید: تعداد «پاسخ‌های بدون ارجاع» می‌تواند این حقیقت را پنهان کند که اکثر آن‌ها حاوی منبع هستند. خواندن خروجی‌های خام قبل از نتیجه‌گیری از معیارها ضروری است.
- نگاشت سمت سرور (Server-Side Mapping): سمت بازیابی می‌تواند فرمت را با ارائه شناسه‌های کوتاه (Source IDs) برای کپی کردن توسط عامل، به‌جای URLهای طولانی برای بازنویسی، اصلاح کند.
اگر ارجاعات برای محصول شما اهمیت دارند، باید اندازه‌گیری کنید که در آن سوی مرز چه اتفاقی می‌افتد. در غیر این صورت، سیستم RAG شما به یک «جعبه سیاه» تبدیل می‌شود که در آن پیوند بین ادعا و منبع شکننده است و به‌راحتی پاره می‌شود.
گفتگو