داده‌های تفکیکی در برابر ردیف‌های خلاصه؛ نبرد برای دقت عامل‌ها

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

روهان سینگ (Rohan Singh) در ۷۲ آزمایش اخیر خود به یک موازنهٔ حیاتی دست یافت: کاهش هزینه‌های توکن در پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) اغلب به شکست کامل عامل منجر می‌شود. طبق اعلام سینگ، توسعه‌دهندگان معمولاً برای بهینه‌سازی پنجرهٔ زمینه (Context Window) — که شبیه میز کاری است که جا برای چند ورق دارد، نه برای کل کتابخانه — خروجی‌ها را فشرده می‌کنند، اما این مطالعه ثابت می‌کند که تجمیع تهاجمی داده‌ها باعث می‌شود عامل‌ها در مواجهه با وظایف پیچیده، به‌سادگی تسلیم شوند.

زمینه (Context)

این تنش در حوزهٔ مشاهده‌پذیری (Observability) به اوج رسیده است. بحث اصلی بر سر این است که ابزارهای MCP داده‌ها را چگونه به مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — برگردانند. در این دامنه، مناقشه بین ارائه ردیف‌های خلاصه‌شده (Summary Rows) است که ارزان و کم‌حجم‌اند، و ارائه داده‌های سری زمانی خام به ازای هر باکت (Raw per-bucket time series) که گران اما کامل هستند. این فشار زمانی رخ می‌دهد که صنعت با هزینه بالای توکن برای اتصال چندین سرور به یک عامل واحد دست‌وپنجه نرم می‌کند.

سینگ اشاره می‌کند که بحث‌های فعلی درباره MCP بیشتر بر روی اعداد خام توکن متمرکز است؛ برای مثال، در برخی گفتگوها اشاره شده که چهار سرور متصل، پیش از آنکه حتی سؤالی پرسیده شود، ۲۱,۰۷۷ توکن از زمینه را می‌بلعند. با این حال، به گزارش این پژوهش، کمتر کسی اندازه‌گیری کرده است که عامل‌ها واقعاً با داده‌های بازگشتی از یک ابزار چه می‌کنند. این مطالعه به درخواست یکی از نگهدارندگان سرور MCP در پروژه Jaeger (زیرمجموعه CNCF) آغاز شد؛ او اصرار داشت که تصمیمات طراحی در مورد شکل خروجی باید بر اساس محک‌ها (Benchmarks) باشد، نه بر اساس نظرات شخصی.

جزئیات (Details)

برای حل این چالش و رفع تردید در مسیر طراحی، سینگ یک محیط تست در مخزن jaeger-mcp-bench ساخت. این ساختار شامل Jaeger v2 به همراه کانکتور spanmetrics، Prometheus برای مدیریت وضعیت متریک‌ها و ابزاری به نام hotrod برای تولید ترافیک است. او یک سرور بنچ سبک را در مقابل API متریک‌ها قرار داد که دارای یک سوئیچ ساده بود: --format=summary|series.

او دو عامل سطح تولید را با استفاده از پرامپت‌های سیستمی واقعی و رابط‌های خط فرمان (CLI) آن‌ها آزمایش کرد:

• Claude Sonnet از طریق رابط خط فرمان Claude Code
• Gemini 2.5 Pro از طریق رابط خط فرمان Gemini

برای اطمینان از اینکه نتایج به نفع فرضیه او دست‌کاری نشده باشد، سینگ ۶ وظیفه عیب‌یابی را در دو دسته طراحی کرد:

• پرسش‌های نقطه‌ای (Point Questions): سه وظیفه متمرکز بر تأخیر فعلی، رتبه‌بندی و بررسی آستانه‌ها (Thresholds) که پیش‌بینی می‌شد داده‌های خلاصه در آن‌ها برنده شوند.
• پرسش‌های زمانی (Temporal Questions): سه وظیفه متمرکز بر تشخیص پیک‌ها (Spike detection)، همبستگی و روندها که پیش‌بینی می‌شد داده‌های سری زمانی در آن‌ها برنده باشند.

این آزمایش در مجموع ۷۲ بار اجرا شد (سه بار برای هر سلول آزمایشی) و برای جلوگیری از اثر انحراف در محیط تست، ترتیب اجراها با استفاده از seed 42 تصادفی شد. امتیازدهی نیز به جای تکیه بر «حس کلی» (Vibes)، به صورت برنامه‌نویسی شده و در برابر داده‌های مرجع (Ground Truth) سنجیده شد.

نتایج

نتایج یک شکاف عمیق در رفتار عامل‌ها را نشان داد، هرچند نه به شکلی که بسیاری انتظار داشتند. جالب اینجاست که تقریباً هیچ پاسخ اشتباهی وجود نداشت؛ در ۷۲ آزمایش، تنها یک مورد تعهد اشتباه (Wrong commitment) ثبت شد که سینگ آن را به باگی در سرور بنچ خودش نسبت داد، نه به فرمت داده‌ها.

• نرخ امتناع (Decline Rates): تفاوت واقعی در نرخ امتناع بود. عامل‌ها وقتی در پرسش‌های زمانی داده‌های خلاصه‌شده دریافت می‌کردند، ۷ برابر بیشتر احتمال داشت بگویند: «با داده‌های موجود نمی‌توانم این مورد را تعیین کنم».
• معناداری آماری: شکاف عملکرد بین حالت خلاصه و سری زمانی در مدل Claude از نظر آماری بسیار معنادار بود (p=0.001 در برابر آلفای 0.0125). در مدل Gemini نیز این شکاف p=0.016 بود که دقیقاً روی مرز معناداری قرار داشت.
• پرسش‌های نقطه‌ای: این موارد بی‌تأثیر بودند. وقتی یک سؤال فقط به یک عدد نیاز دارد، فرمت داده هیچ اهمیتی ندارد.

«صورت‌حساب شکست»

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

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

برای کسانی که ابزارهای MCP می‌سازند، درس این است: فرمت خروجی را با نوع سؤال تطبیق دهید، نه با بودجه توکن. پرسش‌های زمانی و علی نیاز به داده‌های خام دارند (حدود ۷۲۰ نقطه برای هر سرویس در رزولوشن پیش‌فرض)؛ زیرا شما نمی‌توانید یک پیک ترافیکی را در یک عدد میانگین پیدا کنید.

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

گام بعدی شما

• اگر ابزار MCP توسعه می‌دهید، برای پرسش‌های تحلیلی و زمانی، خروجی‌های خام را جایگزین خلاصه کنید.
• در داشبوردهای نظارتی خود، متغیر «نرخ امتناع» (Decline Rate) را به عنوان شاخص کیفیت استقرار عامل تعریف کنید.
• پیش از فشرده‌سازی داده‌ها، یک محک (Benchmark) ساده روی داده‌های مرجع اجرا کنید تا نقطه شکست استدلال مدل را بیابید.

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