تصور کنید برنامه‌نویسی که می‌تواند پیچیده‌ترین توابع را روی کاغذ بنویسد، اما وقتی پشت ترمینال می‌نشیند، نمی‌داند چگونه یک خطا را عیب‌یابی کند. این شکاف دقیقاً همان چیزی است که به‌روزرسانی جدید DeepSeek V4 Flash در اواخر ژوئیه ۲۰۲۶ برملا کرد. این به‌روزرسانی ثابت می‌کند که توانایی یک مدل در نوشتن کد، اساساً با توانایی آن در به‌کاراندازی و مدیریت یک ماشین متفاوت است.
طبق اعلام DeepSeek، این مدل در حالی که معماری، بودجه وزن‌ها و تعداد پارامترها (۲۸۴ میلیارد پارامتر کل با ۱۳ میلیارد پارامتر فعال به ازای هر توکن) را کاملاً حفظ کرده، تنها از طریق تغییر در پس‌آموزش (Post-training) به نتایجی دست یافته که معیارهای فعلی صنعت را به چالش می‌کشد. در حالی که نمرات بنچمارک کدنویسی تک‌مرحله‌ای (One-shot) مدل کاملاً ثابت مانده، عملکرد آن در حلقه‌های عامل‌محور (Agentic) به‌شدت افزایش یافته است. این پیشرفت در راستای روندی است که در آن مدل V4-Flash در بنچمارک‌های عامل‌محور توانست از نسخه Pro پیشی بگیرد و کارایی خود را به رخ بکشد. این موضوع نشان می‌دهد که صنعت احتمالاً از معیارهای اشتباهی برای اندازه‌گیری توانایی عامل‌های هوش مصنوعی استفاده کرده است.
بنچمارک‌های کدنویسی؛ معیاری قدیمی برای دنیای جدید
سال‌هاست توسعه‌دهندگان از محک‌هایی مانند SWE-bench Verified برای تخمین توانایی‌های عامل‌ها استفاده می‌کنند. در این آزمون‌ها، مدل یک مخزن کد و یک گزارش خطا دریافت می‌کند و باید در یک مرحله، یک وصله (Patch) درست تولید کند. در این حالت، مدل می‌خواند، استدلال می‌کند و یک diff را در یک مرحله می‌نویسد. این فرآیند توانایی نوشتن یک تابع صحیح را می‌سنجد؛ قابلیتی که دو سال پیش، زمانی که کاربران توابع را صرفاً در پنجره‌های چت کپی می‌کردند، اولویت اول و سطح اصلی محصول بود.
اما تجربه مدرن توسعه با ابزارهایی مثل Claude Code، حالت عامل در Cursor، Aider و Codex تغییر کرده است. این ابزارها فقط کد نمی‌نویسند؛ آن‌ها تست‌های pytest را اجرا می‌کنند، ردپای خطاها (Stack traces) را می‌خوانند، فایل‌ها را ویرایش می‌کنند و روی شکست‌ها تکرار می‌کنند. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر خروجی‌های تک‌مرحله‌ای ریسک‌های عملیاتی زیادی دارد. این مدل‌های جدید به مهارتی متفاوت نیاز دارند: توانایی اجرای یک دستور، تحلیل خروجی، تشخیص اینکه نتیجه مورد انتظار رخ نداده است، شکل‌دهی به فرضیه‌ای جدید و تلاش دوباره—که احتمالاً باید بیست بار متوالی بدون گم کردن رشته‌ی افکار تکرار شود.
واگرایی در داده‌های عملکرد
بر اساس مستندات منتشر شده توسط DeepSeek، به‌روزرسانی V4 Flash منجر به یک واگرایی عجیب و چشمگیر در عملکرد شده است. توانایی مدل در نوشتن یک تابع تغییری نکرد، اما توانایی مدیریت ماشین در برخی محک‌ها تقریباً چهار برابر شد:
- SWE-bench Verified: دقیقاً روی ۷۹.۰ باقی ماند (بدون حتی یک تغییر جزئی یا خطای گرد کردن).
- DeepSWE: از ۷.۳ به ۵۴.۴ جهش کرد.
- Terminal Bench: از ۲.۱ به ۶۱.۸ رسید.
- Cybergym: از ۳۸.۷ به ۷۶.۷ افزایش یافت.
این اعداد ثابت می‌کنند مدلی که شاید کد متوسطی بنویسد اما بتواند به‌طور قابل‌اعتماد متوجه شکست دستورات شود، در یک حلقه عامل‌محور بسیار مفیدتر از یک کدنویس نابغه است که نمی‌تواند از یک خطای ترمینال بازیابی کند. این تغییر حیاتی است زیرا در محیط‌های عملیاتی، قابلیت بازیابی از خطا بسیار ارزشمندتر از دقت اولیه در نوشتن کد است. این جهش‌های عملکردی در کنار تغییرات استراتژیک در مدل‌های این شرکت رخ می‌دهد، مشابه آنچه در گزارش DeepSeek درباره جهش توانایی کدنویسی هم‌زمان با تغییر قیمت API مشاهده شد.
اعتبارسنجی مستقل و چالش توهم
باید هشدار داد که اعداد بالا توسط خود سازنده و روی محیط‌های غیرعمومی (Non-public harness) اندازه‌گیری شده‌اند که شامل دو مجموعه داده داخلی است. گزارش‌های Artificial Analysis که مدل‌ها را به‌صورت مستقل اجرا می‌کند، تصویر واقع‌بین‌تر و متفاوتی ارائه می‌دهد:
- GPQA Diamond: ۹۰.۸٪ (استدلال علمی سطح تحصیلات تکمیلی که برای ۱۳ میلیارد پارامتر فعال بسیار تحسین‌برانگیز است).
- Humanity's Last Exam: ۳۶.۸٪.
- AA-LCR (استدلال زمینه بلند): ۶۵.۷٪.
- CritPt (فیزیک سطح پژوهشی): ۱۶.۶٪.
- AA-Omniscience (نرخ عدم توهم): ۱۵.۶٪.
نرخ پایین عدم توهم (Hallucination) نقطه ضعف اصلی مدل است؛ V4 Flash در استدلال‌های ساختاریافته قوی است اما همچنان ممکن است با اطمینان کامل، ادعاهای غلطی بکند. بنابراین این مدل نباید به‌عنوان یک «پیشگو» یا منبع حقیقت مطلق دیده شود، بلکه باید به‌عنوان ابزاری برای هدایت در یک حلقه با تاییدیه (Verification) استفاده شود.
شکست در حالت «ترک در میانه راه»
یک نقطه شکست نادیده گرفته شده در این عامل‌ها، تمایل به «ترک در میانه راه» (Quit Halfway) است؛ یعنی مدل اعلام می‌کند کار تمام شده در حالی که به‌وضوح ناقص است. سازنده Koda (یک عامل ترمینال) در حین ساخت این ابزار، اندازه‌گیری کرد که مدل‌ها در انجام وظایف چندمرحله‌ای، تنها در ۱۳.۶٪ موارد واقعاً یک لیست کارهای انجام شده (Todo list) تولید می‌کنند.
در ۸۶٪ باقی‌مانده، هیچ چک‌لیستی برای مقایسه وجود نداشت. در این حالت، عامل می‌گفت «تمام شد»، سیستم بررسی متوجه نبود چه چیزی باید چک شود و حلقه بسته می‌شد. این وضعیت ممکن است به نظر برسد که مدل «کودنویسی ضعیفی» دارد، اما در واقع شکست در لایه «دروازه تایید» (Gate) است. راهکار این است که تایید نهایی را غیرمشروط کرده و یک دستور verify اجباری تعریف کنند تا ادعای اتمام کار توسط مدل، حتماً با یک وضعیت خروجی exit 0 اثبات شود. در حال حاضر هیچ رتبه‌بندی رسمی برای «ترک در میانه راه» وجود ندارد، اما این یکی از بزرگ‌ترین تفاوت‌های کیفی در استقرار واقعی عامل‌هاست.
تأخیر و تست‌های دنیای واقعی
تأخیر (Latency) نقشی تعیین‌کننده در کاربرد عامل‌ها دارد که بنچمارک‌ها نادیده می‌گیرند. مدلی که عالی استدلال می‌کند اما هر گام ۴۰ ثانیه زمان می‌برد، در یک حلقه ۳۰ مرحله‌ای کاملاً غیرقابل‌استفاده است. اندازه‌گیری‌های درگاه OpenAdapter (که V4 Flash را در کنار بیش از ۴۰ مدل بازمتن دیگر ارائه می‌دهد)، میانگین سه اجرا را به این صورت نشان داد:
- پرامپت کوتاه: ۱.۱ ثانیه
- زمینه ۶ هزار توکنی: ۱.۵ ثانیه
- زمینه ۳۴ هزار توکنی: ۴.۷ ثانیه
توانایی پاسخ به ۳۴ هزار توکن کد در کمتر از ۵ ثانیه، همان چیزی است که این مدل را برای استفاده به‌عنوان بک‌اِند یک عامل، کاربردی و سریع می‌کند.
این شواهد نشان می‌دهد که این حوزه باید از تلقی نمرات کدنویسی تک‌مرحله‌ای به‌عنوان معیاری برای قابلیت اطمینان عامل‌ها دست بردارد. اگر در حال اجرای یک عامل هستید، به دنبال معیارهای Terminal Bench، DeepSWE و معیارهای استفاده از ابزار در چندین نوبت (Multi-turn tool use) باشید. تفاوت واقعی مدل‌ها زمانی آشکار می‌شود که به آن‌ها باگی بدهید که برای یافتنش در یک کدبیس با مراحل ساخت (Build step) غیرمعمول، نیاز به اجرای یک مجموعه تست باشد. دقت کنید که مدل در سومین دستور شکست‌خورده چه واکنشی نشان می‌دهد؛ اینجاست که توانایی واقعی مدل نهفته است.
گام بعدی شما
- اگر در حال پیاده‌سازی عامل‌های کدنویسی هستید، به‌جای تکیه بر نمرات Pass@1، روی معیارهای Terminal Bench و DeepSWE تمرکز کنید.
- برای کاهش نرخ «ترک در میانه راه»، سیستم تایید خروجی (Verification Gate) را اجباری کنید تا مدل مجبور به اثبات اتمام کار شود.
- در استقرار مدل، تعادل بین قدرت استدلال و تأخیر (Latency) را اولویت قرار دهید تا حلقه‌های تکرار کند نشوند.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو