‏وقتی ایجنت یه کوئری SQL رو ۲۵۴ بار اجرا کرد

تیم Funnel یه پلتفرم ایجنت داده‌ای داخلی به اسم Reef داره که روی سه لایه دانش شرکت کار می‌کنه: یه گراف از مدل کلی شرکت، داده‌های عملیاتی ساختاریافته مثل متریک‌های مالی و CRM، و مکالمه‌های مشتری‌ها. تو این مقاله اومده که این تیم یه تست A/B تصادفی بین مدل open-weight یعنی GLM-5.2 (مدلی که وزن‌هاش عمومیه و می‌شه خودت اجراش کنی) و Claude Opus 4.8 گذاشت.

اولش نتیجه‌ها خوب به نظر می‌رسید. هر فراخوانی GLM به‌طور میانگین ۷.۸ ثانیه طول می‌کشید و Opus ۱۸.۱ ثانیه، یعنی بیش از دو برابر سریع‌تر. ولی وقتی کل اجرای یه تسک رو حساب کردن، GLM به‌طور میانگین ۱۹ بار ابزار صدا می‌زد و Opus فقط ۱۱ بار، یعنی ۶۶٪ بیشتر. نتیجه این شد که GLM با وجود جواب‌های سریع‌تر، تسک‌ها رو ۱۴٪ دیرتر تموم می‌کرد.

عجیب‌ترین بخش این بود که GLM تو دو اجرای جدا، یه کوئری SQL موفق رو ۱۱۳ و ۲۵۴ بار پشت سر هم اجرا کرد. تو یکی از این موارد، ابزار فقط یه پیش‌نمایش ۲۰ ردیفی برمی‌گردوند و مدل به‌جای اینکه این محدودیت رو بفهمه، همون کوئری رو دوباره و دوباره می‌زد. همهٔ فراخوانی‌ها موفق بودن ولی هیچ پیشرفتی نبود. به گفتهٔ نویسنده، tool call موفق لزوماً tool call مفید نیست. همین رفتار رو با Kimi K2.6 و Qwen3.8 27B هم دیدن و Qwen حتی دو برابر GLM ابزار صدا می‌زد.

نویسنده می‌گه وسوسه‌انگیزه که تقصیر رو گردن مدل بندازیم، ولی تصویر اصلی چیز دیگه‌ایه. بعضی از دستورالعمل‌های ذخیره‌شدهٔ ایجنت به جدول‌ها و فیلدهای Athena اشاره می‌کردن که اصلاً وجود نداشتن. یه جاهایی هم قرارداد ابزارها مبهم بود، جلوی فراخوانی تکراری گرفته نمی‌شد یا توضیح نحوهٔ گرفتن داده کافی نبود. Opus تونسته بود از پس بیشتر این مشکلات بربیاد، ولی مشکل همچنان سر جاش بود. حرف اصلی نویسنده اینه که agent harness (یعنی ابزارها، دستورها و قواعد دور مدل) به اندازهٔ هوش مدل اهمیت داره و عوض کردن مدل می‌تونه فرض‌های پنهون معماری رو بیرون بریزه.

نویسنده برای کسایی که می‌خوان مدل‌های open-weight رو وارد پلتفرم ایجنتی‌شون کنن سه پیشنهاد داره: قرارداد ابزارها رو صریح کنن و فرق پیش‌نمایش با نتیجهٔ کامل و نحوهٔ pagination رو واضح بگن، رفتار ایجنت رو محدود کنن (تشخیص فراخوانی تکراری، بودجهٔ اجرا، چک کردن دستورها با schema واقعی) و کل سیستم رو بنچمارک کنن، نه فقط سرعت مدل رو. به گفتهٔ اون، فایدهٔ مدل‌های open-weight تو هزینه و کنترل واقعیه، ولی فقط با عوض کردن endpoint به دست نمیاد. آخرش هم اشاره می‌کنه که الان از GLM-5.3 استفاده می‌کنن و راضی‌ان.

نکات کلیدی:

• میانگین زمان هر فراخوانی: GLM-5.2 حدود ۷.۸ ثانیه و Opus 4.8 حدود ۱۸.۱ ثانیه
• GLM به‌طور میانگین ۱۹ tool call داشت و Opus ۱۱، یعنی ۶۶٪ بیشتر
• زمان کل انجام تسک با GLM حدود ۱۴٪ بیشتر از Opus بود
• GLM یه کوئری SQL موفق رو تو دو اجرا ۱۱۳ و ۲۵۴ بار تکرار کرد چون ابزار فقط ۲۰ ردیف پیش‌نمایش می‌داد
• Qwen3.8 27B دو برابر GLM ابزار صدا می‌زد و Kimi K2.6 هم رفتار مشابهی داشت
• بخشی از مشکل، دستورالعمل‌هایی بود که به جدول‌های ناموجود Athena اشاره می‌کردن