پرش به محتوای اصلی
پرش به محتوای مقاله

آیا افزایش تلاش مدل‌های استدلالی منجر به پاسخ‌های دقیق‌تر می‌شود؟

·۱۹ مهر ۱۴۰۵۱۶ دقیقه مطالعه
چرخش دکمه استدلال به «زیاد» در ۴ مدل: یک مشکل حل شد، همه‌چیز پولی شد.
چرخش دکمه استدلال به «زیاد» در ۴ مدل: یک مشکل حل شد، همه‌چیز پولی شد.
اشتراک‌گذاری
واقعاً چه چیز جدید است؟

کشف یک «مالیات پنهان» در APIها؛ مدل‌هایی مانند Gemini-3.7-flash حتی در حالت none توکن‌های زیادی مصرف می‌کنند بدون اینکه ردپایی از استدلال را به کاربر نشان دهند.

پرداخت هزینه برای «فکر کردنِ» بیشترِ مدل‌های زبانی، در اکثر مواقع تنها به معنای یک صورت‌حساب گران‌تر است، نه پاسخی دقیق‌تر. تحلیل فنی منتشر شده در ۱۱ اکتبر ۲۰۲۶ نشان می‌دهد که برای اکثریت وظایف، افزایش محاسبات در زمان استنتاج (test-time compute) هیچ تأثیری بر صحت پاسخ‌ها ندارد، حتی در حالی که هزینه هر پاسخ صحیح تا ۳.۴ برابر افزایش می‌یابد.

توسعه‌دهندگان در حال حاضر پارامترهایی مانند reasoning_effort یا thinking را بر اساس شهود تنظیم می‌کنند؛ یعنی برای سؤالات سخت حالت high و برای محیط تولید حالت low را انتخاب می‌کنند. با این حال، تقریباً هیچ داده تجربی در مورد اینکه این تنظیمات در مدل‌های مختلف چه تغییری ایجاد می‌کنند، وجود ندارد. این شکاف اطلاعاتی یک «مالیات پنهان» بر زیرساخت‌های هوش مصنوعی ایجاد کرده است؛ جایی که تیم‌ها برای تفکری هزینه می‌دهند که یا اصلاً رخ نمی‌دهد یا کمکی به نتیجه نمی‌کند.

برای کمی کردن این موضوع، پژوهشگری به نام Abeera81 محک Reasoning Dial را در Kaggle طراحی کرد. در این مطالعه، تمام متغیرها ثابت نگه داشته شدند — پرامپت‌های یکسان، آیتم‌های مشابه و یک ارزیاب قطعی — و تنها سطح استدلال (none, low, medium, high) تغییر کرد. این آزمایش شامل بیش از ۱۸۰۰ فراخوانی ارزیابی‌شده روی چهار مدل gpt-5.4-mini، gemini-3.7-flash، claude-haiku-5.5 و gpt-oss-120b بود. این رویکرد ارزیابی دقیق، یادآور تحلیل‌های پیشین ماست که در آن ریشه‌یابی خطاهای مدل‌های کوچک در برابر مدل‌های پیشرو در محیط Kaggle مورد بررسی قرار گرفت.

طراحی محک

این مطالعه از سه خانواده وظیفه متمایز برای آزمایش مرزهای استدلال استفاده کرد که هر کدام ۲۰ مورد داشتند و برای هر سلول دو تکرار انجام شد تا اثر نویز حذف شود:

  • استنتاج (Deduce): پازل‌های زمان‌بندی ۷ نفره برای ۷ روز با ۶ تا ۱۲ سرنخ (مانند «قبل از»، «بلافاصله قبل از»، «نه در روزِ»، «نه در مجاورتِ»). این وظایف دقیقاً یک راه حل دارند که با روش brute force روی تمام ۷! ترتیب ممکن تأیید شده است. هدف این است که مشخص شود کجا «تفکر بیشتر» واقعاً کمک می‌کند. یک نمونه سؤال این است: «چه کسی روز جمعه سخنرانی می‌کند؟» (پاسخ: Fay).
  • حساب (Arith): مسائل متنی شش‌مرحله‌ای شامل یک گام محاسبه درصد و یک تقسیم دقیق که منجر به پاسخ‌های ۴ تا ۶ رقمی می‌شود (مثلاً صورت‌حساب سوخت یک پیک با ۱۰٪ مالیات که نتیجه آن ۱۱۸۸۰ است). این بخش به عنوان یک کنترل عمل می‌کند، زیرا مدل‌ها در حال حاضر در این حوزه نمرات بالایی می‌گیرند.
  • تشتت (Distract): وظایف شمارش که در آن مدل باید اشیاء متعلق به کاربر را بشمارد و اعداد نامرتبط را نادیده بگیرد (مثلاً فروش یک فروشگاه یا یک قطعه کد). این بخش بر اساس متدولوژی Gema et al 2025 طراحی شده تا بررسی کند آیا تفکر بیشتر منجر به کاهش صحت (inverse scaling) می‌شود یا خیر. یک نمونه آیتم از مدل می‌خواهد ابزارها را بشمارد در حالی که متن می‌گوید: «شما یک قلم تراش و یک دریل دارید»، و سپس عوامل تشتت مانند فروش ۸۳۷۷ تراز در فروشگاهی در Easton یا یک قطعه کد پایتون که len(stock) * 3 را محاسبه می‌کند، اضافه می‌کند.

پیاده‌سازی فنی و دقت علمی

به نقل از مستندات پروژه، پژوهشگر برای تضمین اعتبار علمی، فرضیات و برنامه تحلیل را پیش از اجرا در فایل docs/PREREGISTRATION.md ثبت کرد. ۶۰ مورد آزمایشی با هش SHA-256 (مقدار 90dd5498…0042) قفل شدند و اسکریپت تحلیل در صورتی که هش مطابقت نداشته باشد، از اجرا خودداری می‌کند. پیش‌ثبت شامل چهار فرضیه خاص (H1-H4) و برنامه‌ای برای آزمون Wilcoxon جفت‌شده با اصلاح Holm و یک بوت‌استرپ (bootstrap) خوشه‌ای-آیتمی با ۵۰۰۰ تکرار بود.

ارزیابی پاسخ‌ها کاملاً قطعی بود. یک پارسر regex آخرین خط FINAL ANSWER: را می‌خواند و هیچ مدل زبانی به‌عنوان داور (LLM judge) استفاده نشد. سیستم فرمت‌های مختلف از جمله نشانگرهای Bold و دو-نقطه‌های تمام-عرض را مدیریت می‌کرد و بلوک‌های <think> را حذف می‌نمود. پژوهشگر از خروجی‌های ساختاریافته کتابخانه (schema=) استفاده نکرد، زیرا بازگشتِ <think>…</think>{json} توسط پروکسی باعث شکست در تجزیه JSON می‌شد.

همان‌طور که در تحلیل‌های قبلی ما درباره بهینه‌سازی هزینه استنتاج اشاره کردیم، مدیریت توکن‌ها کلید سودآوری در مقیاس است. در این پروژه، کل هزینه اجرای اصلی ۴.۲۰ دلار بود، اما کل پروژه با احتساب مراحل پایلوت و دو دور کالیبراسیون، ۶.۳۸ دلار از سهمیه Kaggle مصرف کرد. خط لوله از کتابخانه kaggle-benchmarks استفاده کرد، جایی که متد llm.prompt() یک آرگومان reasoning= می‌پذیرد و پروکسی Kaggle آن را به پارامتر reasoning_effort خاص هر فروشنده تبدیل می‌کند.

یافته اول: عدم استاندارد بودن «دکمه استدلال»

بر اساس یافته‌های این پژوهش، پارامتر reasoning_effort به‌طور یکسان در مدل‌های مختلف پیاده‌سازی نشده است (تأیید فرضیه H1). در gpt-5.4-mini، این دکمه طبق انتظار عمل کرد و میانگین توکن‌های خروجی را از ۱۸ در حالت none به ۲۵۴ در حالت high رساند (افزایش ۱۴.۱ برابری). در مقابل، مدل gpt-oss-120b تنظیم none را کاملاً رد کرد و خطای HTTP 400 داد؛ به این معنا که یک پیکربندی چند-مدلی که از مقدار none استفاده کند، در این مدل کرش خواهد کرد. این عدم یکپارچگی در رفتار مدل‌ها، مشابه چالش‌هایی است که در بررسی عدم تطابق شناسه‌ی مدل با خروجی‌های ثابت مشاهده کردیم و ریسک‌های حاکمیتی در زیرساخت‌های AI ایجاد می‌کند.

مدل Gemini-3.7-flash مورد عجیبی بود. در تنظیم none، این مدل به‌طور میانگین ۴۵۳ توکن مصرف کرد — بیشتر از مصرف gpt-5.4-mini در حالت high — اما هیچ ردپایی از استدلال (reasoning trace) در حالت none یا low نمایش نداد. کاربران در واقع برای «تفکر پنهانی» هزینه می‌دهند که API آن را افشا نمی‌کند.

تحلیل‌های اکتشافی بیشتر نشان داد که اثر دکمه استدلال به شدت به نوع سؤال بستگی دارد. برای gpt-5.4-mini، توکن‌های وظایف استنتاج (Deduce) از ۱۸ به ۳۰۴۰ رسید (افزایش ۱۶۹ برابری)، در حالی که توکن‌های حساب (Arith) تنها از ۱۲۸ به ۲۲۰ تغییر کرد. مدل gpt-oss-120b در وظایف تشتت (Distract) در حالت high، ۲۰.۶ برابر توکن بیشتری نسبت به حالت low مصرف کرد، حتی زمانی که پاسخ در اولین جمله موجود بود.

یافته دوم: تنها پیروزی در صحت پاسخ‌ها

از میان ۱۲ ترکیب مدل-وظیفه، تنها یک مورد بهبود آماری معناداری داشت که از اصلاح p-value Holm عبور کرد (p = 0.00056): مدل gpt-5.4-mini در پازل‌های منطقی (Deduce). صحت پاسخ‌های این مدل از ۱۵٪ در حالت none (که تقریباً نرخ حدس تصادفی برای ۷ نام است) به ۹۷.۵٪ در حالت high جهش کرد (تأیید فرضیه H3 فقط برای این مدل).

جالب اینجاست که بخش عمده این پیشرفت در همان گام اول رخ داد؛ انتقال از none به low باعث افزایش ۶۰ درصدی صحت شد (۱۵٪ ← ۷۵٪). هر افزایش بعدی در تلاش، تنها بهبودهای جزئی ایجاد کرد اما هزینه هر پاسخ صحیح را به شدت افزایش داد. برای این مدل، هزینه هر پاسخ صحیح از ۰.۰۰۱۹ دلار در حالت none به ۰.۰۱۶۰ دلار در حالت high رسید — یک افزایش ۸.۵ برابری.

سایر مدل‌ها این جهش را نداشتند چون از قبل در سقف دقت بودند. Claude Haiku 5.5 در حالت none نمره ۹۷.۵٪ و Gemini نمره ۱۰۰٪ را کسب کردند؛ بنابراین برای آن‌ها، بالا بردن دکمه استدلال چیزی برای اصلاح نداشت.

یافته سوم: هزینه بیش‌-تفکری (Over-Thinking)

در ۷ مورد از ۱۲ سلول آزمایش، صحت پاسخ‌ها بدون توجه به تنظیمات دکمه، یکسان باقی ماند. در این موارد، هزینه هر پاسخ صحیح بین ۱.۵ تا ۳.۴ برابر افزایش یافت. در وظایف حساب (Arith)، تمام مدل‌ها صحت خود را حفظ کردند اما هزینه‌ها بالا رفت (۱.۶۵ برابر برای gpt-5.4-mini تا ۲.۵ برابر برای gpt-oss-120b) که ثابت می‌کند صرف تلاش بیشتر برای مسئله‌ای حل‌شده، صرفاً اتلاف منابع است (تأیید فرضیه H4).

در وظایفی تشتت (Distract)، تفکر بیشتر صحت را به‌طور معناداری پایین نیاورد (فرضیه H2 تأیید نشد)، اما ماهیت خطاها را تغییر داد. تمام پاسخ‌های غلط، «بیش‌-شمار» (over-count) بودند؛ هیچ مدلی هرگز پاسخ کمتری از مقدار واقعی نداد. مدل‌ها در حالت high دچار سردرگمی در مورد اینکه چه چیزی متعلق به آن‌هاست نشدند، بلکه صرفاً از محاسبات اضافی خود برای اضافه کردن اعداد نامرتبطِ تشتت به مجموع نهایی استفاده کردند.

به عنوان مثال، یک مدل مسئله تکالیف یک همکلاسی را که در پرامپت گنجانده شده بود حل کرد و آن را به جای شمارش ابزارها به عنوان پاسخ گزارش داد. پاسخ‌های طولانی‌تر به‌طور مداوم پاسخ‌های غلط بودند. در حالت high، پاسخ‌های غلط gpt-5.4-mini در وظایف تشتت به‌طور میانگین ۴۱۲ توکن مصرف کردند، در حالی که برای پاسخ‌های صحیح ۹۱.۵ توکن مصرف شد. gpt-oss-120b این روند را شدیدتر نشان داد: ۵۷۷۶ توکن برای پاسخ‌های غلط در مقابل ۷۴۷ توکن برای پاسخ‌های صحیح.

یافته چهارم: ناهنجاری‌های عملکردی

مدل gpt-oss-120b در تنظیمات بالا نوسانات شدیدی نشان داد. در یک مورد، این مدل ۲۱,۸۷۵ توکن مصرف کرد و نزدیک به چهار دقیقه (۲۳۵ ثانیه) پردازش انجام داد تا پاسخ «۶» را بدهد، در حالی که پاسخ صحیح «۵» بود.

همچنین ثبات مدل با افزایش تلاش کاهش یافت. در وظایف تشتت در حالت high، این مدل برای ۴۵٪ از آیتم‌ها در دو تکرار یکسان، پاسخ‌های متفاوتی داد، در حالی که این نرخ در حالت low صفر بود. این موضوع یادآور رفتارهای غیرقابل‌پیش‌بینی در مدل‌های دیگر است، مانند عدم قطعیت مدل Kev-4B هنگام مواجهه با ورودی‌های دسته‌ای که منجر به شکست در دترمینیسم مدل در محیط‌های عملیاتی می‌شود. این نشان می‌دهد که اگرچه صحت ممکن است به‌طور معناداری کاهش نیابد، اما قابلیت اطمینان (reliability) خروجی کاهش می‌یابد وقتی به مدل فضای بیشتری برای بیش-محاسبه داده شود.

تحلیل برای متخصصان فنی

این داده‌ها این فرض را که «محاسبات بیشتر برابر است با نتایج بهتر» برای استدلال در زمان استنتاج به چالش می‌کشد. برای بخش فنی، این بدان معناست که reasoning_effort باید به عنوان یک هایپرپارامتر در نظر گرفته شود که برای هر وظیفه به‌طور جداگانه تنظیم (tune) شود، نه یک تنظیمات کلی.

این واقعیت که Claude Haiku 5.5 و Gemini-3.7-flash در پایین‌ترین تنظیمات به سقف دقت (به ترتیب ۹۷.۵٪ و ۱۰۰٪) در پازل‌های منطقی رسیدند، نشان می‌دهد که برای بسیاری از وظایف منطقی رایج، سربار استدلال از قبل در مسیر سریع (fast-path) مدل پایه گنجانده شده است. پرداخت هزینه برای تلاش high در این موارد، یک ناکارآمدی معماری است.

درس‌های زیرساختی و سهمیه (Quota)

این مطالعه همچنین رفتارهای بحرانی API را برجسته کرد. پروکسی Kaggle پیش از اجرای هر فراخوانی، حداکثر هزینه ممکن را علیه سهمیه رزرو می‌کند (هزینه ورودی به علاوه ۱۲۸,۰۰۰ توکن خروجی). برای gpt-5.4-mini، این مبلغ حدود ۰.۵۸ دلار در هر فراخوانی است. این موضوع منجر به ۳۷۸ مورد رد سهمیه (HTTP 403) در طول اجراهای موازی اولیه شد، با وجود اینکه هزینه واقعی بسیار کمتر از سقف بود. پژوهشگر یک قانون پیش‌ثبت وضع کرد که خطای 403 سهمیه را به عنوان «داده مفقود» در نظر بگیرد، نه رفتار مدل، تا از ایجاد یافته‌های جعلی مبنی بر شکست مدل در حالت high جلوگیری کند.

مدل Claude Sonnet 5 را باید به‌طور کامل از لیست حذف کرد زیرا رزرو سهمیه آن (حدود ۱.۲۸ دلار در هر فراخوانی) هنگام اجرای ۸ فراخوانی موازی، از سهمیه روزانه ۱۰ دلاری فراتر می‌رفت. در تحلیل، این مورد به عنوان «حذف شده (رزرو سهمیه پلتفرم)» گزارش شده است.

گام‌های بعدی

توسعه‌دهندگان باید ابتدا حجم کاری خاص خود را در تنظیمات none یا low بنچ‌مارک کنند و سپس به مقیاس بالاتر بروند. اگر حالت none شکست خورد، حالت low اغلب بیشترین جهش در عملکرد را فراهم می‌کند، پیش از آنکه بازدهی نزولی (diminishing returns) آغاز شود.

پژوهش‌های آینده باید بر موارد زیر تمرکز کنند:

  • آیتم‌های سخت‌تر استنتاج (Deduce): افزایش تعداد افراد و سرنخ‌ها برای خارج کردن Haiku و Gemini از سقف دقت.
  • مجموعه‌های گسترده‌تر تشتت (Distract): افزایش نمونه‌ها برای آزمایش دقیق‌تر inverse scaling پیش‌بینی شده در H2، با توجه به نرخ تغییر ۴۵ درصدی gpt-oss-120b.
  • تحلیل تأخیر (Latency): استفاده از رکوردهای latency_s و backend_latency_ms که در فراخوانی‌ها ثبت شده‌اند.

برای مشاهده مجموعه داده کامل، شامل ۱,۹۶۴,۳۷۸ توکن خروجی تحلیل شده و کد بازتولید، به مخزن گیت‌هاب Reasoning Dial مراجعه کنید.

چرا این موضوع مهم است؟

این یافته‌ها نشان می‌دهد که بسیاری از سازمان‌ها در حال پرداخت هزینه‌های اضافی برای قابلیت‌هایی هستند که هیچ ارزش افزوده‌ای در خروجی ایجاد نمی‌کند. تکیه بر اعتبار داده‌های Kaggle ثابت می‌کند که بهینه‌سازی هزینه استنتاج باید جایگزین اعتماد کورکورانه به تنظیمات پیش‌فرض سازندگان مدل شود.

تأثیر برای ایران

برای توسعه‌دهندگان ایرانی که با محدودیت بودجه دلاری برای APIها مواجه‌اند، تنظیم دقیق reasoning_effort می‌تواند هزینه‌های عملیاتی را تا ۳ برابر کاهش دهد بدون اینکه کیفیت محصول تغییر کند.

·نگاه ما
تحریریه دات‌هوش

این داده‌ها این فرض رایج را که «محاسبات بیشتر در زمان استنتاج لزوماً به نتایج بهتر منجر می‌شود» به چالش می‌کشد. در واقع، reasoning_effort را نباید یک تنظیم کلی دانست، بلکه باید به عنوان یک ابرپارامتر (hyperparameter) در نظر گرفت که برای هر وظیفه به‌طور مجزا تنظیم شود. وقتی مدل‌هایی مثل Haiku در پایین‌ترین سطح استدلال به سقف دقت می‌رسند، پرداخت هزینه برای حالت high صرفاً یک ناکارآمدی معماری است.

منابع

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

گفتگو

پنج‌شنبه‌های هوش‌محور

بسته‌ی هفتگی دات‌هوش

۵ خبر، ۲ ابزار، ۱ پرامپت در هر شماره. به‌زودی راه‌اندازی می‌شود — هر پنج‌شنبه صبح.

خبر کلیدی
ابزار کاربردی
پرامپت حرفه‌ای
تحلیل پژوهش
به‌زودی
زاویه‌ی ایرانی
به‌زودی
تمرین این هفته
به‌زودی

راهنماهای دات‌هوش

راهنماهای کاربردیِ دات‌هوش برای کار با هوش مصنوعی — از همین‌جا شروع کنید:

دات‌هوش

راهنمای فارسی هوش مصنوعی — با نگاه به ایران

اخبار روزانه، معرفی ابزارها و مدل‌ها، و آموزشِ کار با هوش مصنوعی؛ همیشه با این پرسش که از ایران چه چیزی کار می‌کند و چه چیزی نه.