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

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

طبق گزارش جامع منتشرشده در ۲۴ ژوئن ۲۰۲۶، یک عامل هوش مصنوعی با استفاده از Claude Code در ۹۳۶ اجرای مختلف تست شد تا بهینه‌ترین روش ارائه زمینه کد (Context) از طریق سرورهای پروتکل زمینه مدل (MCP) شناسایی شود. اکثر عامل‌های فعلی به صورت «کور» در مخازن کد جست‌وجو می‌کنند؛ آن‌ها توصیفاً یا فایل‌ها را می‌خوانند یا از دستور grep برای یافتن نمادها استفاده می‌کنند. در حالی که این روش شهودی به نظر می‌رسد، اما وقتی عامل نیاز دارد روابط پیچیده مانند ارث‌بری یا تحلیل «دایره اثر» (Blast Radius) را در حین بازسازی کد (Refactoring) درک کند، سربار توکنی عظیمی ایجاد می‌کند. تصور کنید می‌خواهید نقشه یک شهر را با خواندن دفترچه تلفن رسم کنید به جای اینکه به نقشه GPS نگاه کنید؛ در نهایت به آدرس می‌رسید، اما ساعت‌ها وقت خود را در کوچه‌های اشتباه تلف می‌کنید.

جزئیات چیدمان آزمایشی

برای اطمینان از یک رقابت عادلانه، محقق تمام متغیرها را ثابت نگه داشت و تنها سرور MCP ارائه‌دهنده زمینه را تغییر داد. مدل، پرامپت سیستم و تنظیمات به عنوان مقادیر ثابت باقی ماندند. میدان آزمایش، مخزن apache/superset بود که جایگزینی تقریباً کامل برای یک مورد تجاری در مقیاس بزرگ است. این پروژه یک پروژه چندزبane (Polyglot) با حدود ۴۰۰,۰۰۰ خط کد (LOC) است که دارای یک بک‌اند پایتونی و یک فرانت‌اند تایپ‌اسکریپتی است و یک مرز مشخص /api/v1/... بین آن‌ها وجود دارد. این مقیاس، دقیقاً نقطه‌ای است که در آن زمینه ساختاری از یک «آپشن» یا تجمل، به یک «ضرورت» تبدیل می‌شود.

در این بررسی، چهار «بازوی» متمایز اندازه‌گیری شدند که هر کدام نماینده یک کلاس از ارائه‌دهندگان زمینه بودند:

• filesystem: از @modelcontextprotocol/server-filesystem (ترکیبی از read_file و grep) استفاده می‌کند. این بازو خط پایه با زیرساخت صفر است که در هر جایی بدون نیاز به تنظیمات کار می‌کند.
• graphlens: یک گراف ساختاری کد که گره‌های موجودیت و یال‌های نوع‌بندی‌شده را فراهم می‌کند. این ابزار نیازمند یک گراف ساختاری روی MCP و یک مرحله ایندکس‌گذاری تحت عنوان analyze است.
• serena: رویکردی مبتنی بر پروتکل سرور زبان (LSP) که از یک گرم‌کردن فضای کاری (Workspace warm-up) استفاده می‌کند.
• codegraph: یک رقیب تجاری مبتنی بر گراف که نیازمند مرحله codegraph init برای شروع است. این ابزار در بررسی‌های پیشین نیز موفق شده بود مصرف توکن عامل‌های کدنویس را تا ۶۴٪ کاهش دهد.

این ابزارها با سه مدل مختلف جفت شدند: Claude Haiku 4.5، Sonnet 4.6 و Opus 4.8. آزمایش‌ها بر روی ۲۶ تکلیف خاص و با سه «دانه» (Seed) مختلف انجام شد تا نویزهای غیرقطعی (Non-deterministic) حذف شوند. حجم کل کاری شامل ۴ بازو × ۳ مدل × ۲۶ تکلیف × ۳ دانه بود که در مجموع ۹۳۶ اجرا روی نسخه ۲.۱.۱۸۷ از Claude Code انجام شد.

برای جلوگیری از «تقلب» یا رفتارهای جایگزین (Fallback)، تمامی ابزارهای داخلی Claude Code مانند Read، Grep و Bash با استفاده از دستور --disallowedTools غیرفعال شدند. اگر این ابزارها غیرفعال نشوند، عامل سرور MCP را نادیده گرفته و به مسیرهای معمول خود باز می‌گردد. این سیستم در یک محیط «اتاق پاک» (Clean Room) با یک CLAUDE_CONFIG_DIR تازه اجرا شد که فقط شامل اعتبارنامه‌های اشتراک بود (بدون هیچ‌گونه هوک، پلاگین، مهارت یا حافظه). همچنین از --strict-mcp-config استفاده شد تا اطمینان حاصل شود که فقط سرور مربوط به بازوی مورد نظر قابل مشاهده است. پرامپت سیستم اکیداً مدل را از پاسخ دادن بر اساس حافظه منع کرد؛ هر اجرای با صفر فراخوانی ابزار، مجدداً تکرار یا با تگ __NO_TOOLS__ علامت‌گذاری شد.

استانداردهای اندازه‌گیری و دقت

برای جلوگیری از سوق دادن بنچمارک به سمت یک نتیجه مطلوب، مطالعه قوانین سخت‌گیرانه‌ای برای اندازه‌گیری‌های صادقانه اجرا کرد:

• استانداردهای طلایی (Gold Standards): پاسخ‌ها به‌صورت دستی با منبع اصلی در تگ ۶.۰.۰ تأیید شدند. نکته حیاتی این بود که پاسخ‌های طلایی توسط هیچ‌یک از ابزارهای مورد آزمایش (نه pyright و نه graphlens) تولید نشدند تا سوگیری ایجاد نشود. تکالیف مجموعه‌ای (Set-task) با یک اوراکل مستقل با استفاده از ast پایتون بررسی شدند.
• محاسبه هزینه: مقدار cost_usd یک متریک معادل API است که توسط CLI صادر می‌شود. از آنجایی که اشتراک‌ها دارای نرخ ثابت هستند، این عدد نشان می‌دهد که توکن‌ها از طریق API چقدر هزینه می‌داشتند و یک متریک صحیح از دلار به‌ازای هر تکلیف (relative $/task) ارائه می‌دهد. این رویکرد برای کسانی که به دنبال محاسبه دقیق هزینه‌های واقعی هر پروژه در محیط‌هایی مانند Copilot و Cursor هستند، دیدگاه شفاف‌تری فراهم می‌کند.
• مدیریت شکست‌ها: هر شکست به عنوان دقت ۰ محاسبه شد. اگر بازوی filesystem به سقف ۵۰ دور (Turn) برسد بدون اینکه پاسخی تولید کند، به عنوان شکست امتیاز می‌گیرد و نه به عنوان «بدون داده».
• گزارش آماری: چون temperature=0 در این مدل‌ها تضمین‌کننده قطعیت نیست، گزارش به جای میانگین، «میانه» (Median) را در سه دانه مختلف نشان می‌دهد.

تکالیف ساده: هزینه نویز

برای مجموعه‌ای از ۲۰ «جست‌وجوی نقطه‌ای» (Pinpoint Lookups)—پاسخ‌های تک‌نقطه‌ای که با زیررشته (Substring) بررسی می‌شدند—هر چهار ابزار از نظر دقت تقریباً یکسان عمل کردند. این تکالیف شامل موارد زیر بود:

• where_defined (۷ تکلیف): مکان‌یابی فایل تعریف‌کننده یک کلاس پایتونی.
• inherits_from (۵ تکلیف): شناسایی کلاس پایه (Base class) یک کلاس پایتون.
• abstract_methods (۱ تکلیف): یافتن متدهای انتزاعی ABC.
• ts_where_defined (۱ تکلیف): مکان‌یابی فایل تعریف‌کننده یک هوک تایپ‌اسکریپت.
• ts_route_call (۴ تکلیف): نگاشت یک مسیر /api/v1/... به هوک TS فراخواننده آن.
• xlang_link (۲ تکلیف): اتصال یک مصرف‌کننده TS به یک هندلر پایتون در مرز API.

دقت در این بخش برابر بود (به‌صورت رسمی: Friedman χ²=0.40 که معنادار نیست). تنها تفاوت واقعی در برچسب قیمت و سرعت بود:

• Codegraph: بهینه‌ترین حالت، هزینه حدود ۰.۰۲۲ دلار به ازای هر تکلیف با ۱ فراخوانی و ۱۰ ثانیه تأخیر.
• Serena: هزینه حدود ۰.۰۳۱ دلار به ازای هر تکلیف با ۳ فراخوانی و ۲۰ ثانیه تأخیر.
• Graphlens: هزینه حدود ۰.۰۳۸ دلار به ازای هر تکلیف با ۳ فراخوانی و ۱۳ ثانیه تأخیر.
• Filesystem (grep): گران‌ترین حالت، هزینه حدود ۰.۰۶۳ دلار به ازای هر تکلیف با ۱۰ فراخوانی و ۴۳ ثانیه تأخیر.

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

تکالیف سخت: جایی که grep فرو می‌پاشد

پویایی‌ها کاملاً معکوس شدند وقتی عامل با شش تکلیف «سخت» مواجه شد که نیاز به درک معنایی داشتند. این رژیم، دایره اثر و ابهام‌زدایی را بررسی می‌کند، جایی که ساختار و معنا باید بر جست‌وجوی متنی غلبه کنند. این موارد با معیاری F1 (که بازخوانی را پاداش و دقت پایین را جریمه می‌کند) امتیازدهی شدند و این موارد را بررسی کردند:

• disambiguate (۲ تکلیف): یافتن کلاس صحیح برای یک نام متد مبهم (مثلاً cache_key که در کلاس‌های زیادی تعریف شده است).
• overrides_count (۲ تکلیف): شناسایی مجموعه کامل زیرکلاس‌هایی که یک متد پایه را بازنویسی (Override) می‌کنند.
• impact_set (۲ تکلیف): تعیین تک‌تک فایل‌هایی که یک متد خاص را فراخوانی می‌کنند (دایره اثر یا Blast Radius).

طبق داده‌ها، بازوی filesystem (grep) دچار یک شکست فاجعه‌بار شد:

• صحت پاسخ‌ها به ۰.۷۱ سقوط کرد.
• ۱۷٪ از اجراها کاملاً شکست خوردند (تنها ۸۳٪ به پایان رسیدند) و بدون یافتن پاسخ به سقف ۵۰ دور رسیدند.
• هزینه به شدت افزایش یافت و به ۰.۴۲۴ دلار به ازای هر تکلیف رسید که ۶ تا ۲۴ برابر گران‌تر از ابزارهای ساختاری بود.
• تأخیر میانگین به ۱۶۵ ثانیه رسید، در حالی که برای graphlens تنها ۹ ثانیه بود.

در مقابل، ابزارهای ساختاری پایدار ماندند. Codegraph به بالاترین دقت (۰.۹۳) رسید، در حالی که serena (۰.۸۵) و graphlens (۰.۸۴) رقابتی باقی ماندند. یک گراف معنایی به عامل اجازه می‌دهد رابطه را در یک یا دو رفت‌وبرگشت پیدا کند، در حالی که grep به طور میانگین به ۲۷ فراخوانی مجزا نیاز دارد تا نویزها را غربال کند. Graphlens، با وجود اینکه در تکالیف ساده در رتبه‌های میانی بود، در این رژیم سخت به ارزان‌ترین (۰.۰۱۸ دلار) و سریع‌ترین (۹ ثانیه) ابزار تبدیل شد.

تعامل مدل و ابزار

یکی از ضدشهودی‌ترین یافته‌ها مربوط به این است که کدام مدل با کدام ابزار جفت شود. محقق دریافت که ابزار بهینه به قیمت مدل بستگی دارد، زیرا سرورها بدین ترتیب بدایه‌های (Primitives) خود را تکه تکه می‌کنند.

Graphlens نتایج مفصلی برمی‌گرداند، شامل همسایگی‌های کامل گراف و لیست‌های ارجاع. در یک مدل ارزان مانند Haiku، این پرپراکی تقریباً رایگان است و آن را به ارزان‌ترین گزینه کلی (۰.۰۲۰ دلار/تکلیف) تبدیل می‌کند. اما در Opus، همین توکن‌ها قیمت بسیار بالاتری دارند و این پرپراکی به کیف پول ضربه می‌زند و graphlens را به گران‌ترین ابزار ساختاری (۰.۰۴۶ دلار/تکلیف) تبدیل می‌کند.

میانه هزینه هر تکلیف در هر دو رژیم به تفکیک مدل:

• Haiku: graphlens (۰.۰۲۰) < codegraph (۰.۰۲۳) < serena (۰.۰۲۶) < filesystem (۰.۰۵۳)
• Sonnet: serena (۰.۰۳۳) < graphlens (۰.۰۴۱) < codegraph (۰.۰۴۱) < filesystem (۰.۰۸۰)
• Opus: codegraph (۰.۰۳۱) < serena (۰.۰۴۲) < graphlens (۰.۰۴۶) < filesystem (۰.۰۸۷)

این منجر به یک درک حیاتی می‌شود: یک مدل ارزان جفت شده با یک ابزار ساختاری (مثلاً Codegraph + Haiku با هزینه ~۰.۰۲۳ دلار و دقت ~۰.۹۹) را در هر محور—دقت، هزینه و سرعت—به طور مداوم شکست می‌دهد یک مدل گران‌قیمت که با ابزاری ساده جفت شده است (مثلاً Filesystem + Opus با هزینه ~۰.۰۸۷ دلار و دقت ~۰.۹۳).

هشدارها و شکست‌های صادقانه

این مطالعه همچنین برجسته می‌کند که کجا «تب گراف» با واقعیت برخورد می‌کند. نویسنده عمداً دو تکلیف xlang_link را به عنوان یک تست فشار قرار داد و انتظار داشت ابزارهای تک‌زبانه در مرز TS به پایتون شکست بخورند. در کمال تعجب، هر ابزاری، از جمله grep، هر دو را حل کرد. استدلال داخلی عامل خودش از مرز عبور کرد، فارغ از اینکه ارائه‌دهنده زمینه چه بود. این تایید می‌کند که اگر عامل سرنخ‌های درستی داشته باشد، می‌تواند مرزها را پل بزند، حتی بدون یک گراف چندزبانه.

علاوه بر این، تحقیق تمایز شدیدی بین رژیم‌ها حفظ می‌کند. یک میانگین ترکیبی واحد، تحت تأثیر ۲۰ تکلیف ساده قرار می‌گرفت و شکست‌های بحرانی grep در تکالیف سخت را پنهان می‌کرد. شکاف دقت در تکالیف سخت، اگرچه از نظر بصری بزرگ است، اما از نظر آماری معنادار نبود (Friedman χ²=3.50) زیرا اندازه نمونه کوچک بود (n=6). نویسنده اشاره می‌کند که اگرچه سیگنال قوی است، اما این یک نتیجه توصیفی است و نه یک قانون اثبات‌شده؛ برای محکم کردن این ادعا، به تکالیف سخت بیشتری نیاز است، نه تکالیف ساده کمتر.

پیامدهای تجاری

برای تیم‌هایی که کدبیس‌های قدیمی (Legacy) را مدیریت می‌کنند، مورد تجاری بستگی به کاری دارد که به عامل واگذار می‌شود:

• جست‌وجوهای نقطه‌ای یک‌باره: grep بدون نیاز به تنظیمات عالی است. دقت یکسان است و سربار ایندکس‌گذاری وجود ندارد. شما حداکثر هزینه اندکی بابت توکن‌های اضافی برای جست‌وجوی متنی ساده می‌پردازید.
• کار مستمر روی دایره اثر: ابزارهای ساختاری هزینه را ۶ تا ۲۴ برابر و تأخیر را ۶ تا ۱۸ برابر در مقایسه با grep کاهش می‌دهند. مهم‌تر از آن، آن‌ها از رسیدن به سقف ۵۰ دور جلوگیری می‌کنند. grep در اینجا فقط گران نیست، بلکه غیرقابل اعتماد است.

در مورد استهلاک ایندکس، هزینه راه‌اندازی یک هزینه زمانی یک‌باره با صفر توکن مصرف شده است:

• Filesystem: ۰ ثانیه
• Codegraph: ۴۸ ثانیه
• Graphlens: ۸۴ ثانیه
• Serena: ۹۴ ثانیه

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

مسیرهای آینده برای Graphlens

این بنچمارک تایید می‌کند که اگرچه graphlens یک قدرت اقتصادی برای تحلیل اثر است—به‌ویژه در مدل‌های ارزان‌تر—اما جای رشد دارد. رتبه‌بندی نشان می‌دهد که Codegraph در تکالیف ساده با بسته‌بندی «منبع + مسیرهای فراخوانی» در یک مرحله (از طریق بدایه‌های explore / node) پیروز می‌شود و رفت‌وبرگشت‌ها را کاهش می‌دهد.

نتایج Graphlens در حال حاضر توکن‌محور (Verbose) هستند. تکرار بعدی بر بهبود دانه‌بندی ابزار MCP برای کاهش رفت‌وبرگشت‌ها و افزایش فشرده‌سازی خروجی متمرکز خواهد بود تا در صورت جفت شدن با مدل‌های گران‌قیمتی مانند Opus، «خود را ورشکست نکند». این بهبودها اکنون با اعداد سخت پشتیبانی می‌شوند و نه فقط با شهود.

تکرارپذیری، هسته این مطالعه است. تمام تجهیزات، داده‌های خام و متریک‌ها در https://github.com/Neko1313/agent-context-bench در دسترس هستند تا دیگران بتوانند خط لوله را از طریق uv run main.py (که superset را کلون کرده و ایندکس‌ها را می‌سازد) اجرا کرده و نتایج را روی کدبیس‌های مختلف تأیید کنند.

گام بعدی شما

• اگر از MCP در پروژه‌های خود استفاده می‌کنید، ابزارهای مبتنی بر گراف را جایگزین grep کنید تا هزینه توکن‌های خود را کاهش دهید.
• برای تحلیل‌های پیچیده، به جای ارتقای مدل (مثلاً از Sonnet به Opus)، ابتدا زیرساخت بازیابی داده (Context) خود را به گراف منتقل کنید.
• مخزن agent-context-bench را بررسی کنید تا متوجه شوید مدل شما در کدام بخش‌های کد دچار توهم می‌شود.

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