تنظیمات «حداکثر تلاش» (max effort) در Claude Opus 5، قیمت یک درخواست معمولی را از ۰.۷۶ دلار به ۱۹.۲۱ دلار افزایش می‌دهد، در حالی که اساساً همان خروجی عملکردی را ارائه می‌دهد. این هزینه اضافی در واقع صرف یک مرحله بازبینی داخلی می‌شود، نه یک راهکار بهتر؛ و تنها در وظایفی که با پوشش تست (test coverage) پایینی شروع می‌شوند، سود قابل اندازه‌گیری نشان می‌دهد.

آنچه آزمایش نشان داد

این آزمایش سطح تلاش پیش‌فرض Claude Opus 5 را با تنظیم «حداکثر تلاش» در دو نوع پرامپت مقایسه کرد: کارهای روزمره برنامه‌نویسی و مسائل عمداً دشوار.

  • برای یک وظیفه معمولی، اجرای با تلاش کم در دو دقیقه تمام شد و ۰.۷۶ دلار هزینه داشت. بالا بردن تنظیمات به حالت حداکثر، صورت‌حساب را به ۱۹.۲۱ دلار رساند، با این حال امتیاز پوشش الزامات (requirement-coverage score) — معیاری که مدل برای گزارش میزان موفقیت خود در اجرای دستورالعمل‌ها ارائه می‌دهد — بدون تغییر باقی ماند.
  • متن گفتگو (transcript) نشان‌دهنده تغییر رویکرد از «خلق کردن» به «بازبینی» است. مدل از تولید کدهای جدید دست کشید و شروع به صیقل دادن آنچه قبلاً نوشته بود کرد. تعداد ویرایش‌ها ۲.۴ برابر بیشتر از نوشته‌های جدید بود. فراخوانی ابزار read هجده برابر و فراخوانی ابزار bash شش برابر افزایش یافت. در عمل، مدل ماژول‌ها را دوباره خواند، تست‌های خودش را مجدداً اجرا کرد، عملیات linting و حتی تست جهش (mutation testing) را بدون اینکه از او خواسته شود، انجام داد.

تنظیم «حداکثر تلاش» الگوریتم جدیدی معرفی نمی‌کند؛ بلکه صرفاً بودجه‌ای را که مدل می‌تواند خرج کند، افزایش می‌دهد. زمانی که بودجه به اندازه کافی بزرگ باشد، مدل به حالت خودبازبینی (self-audit) تغییر وضعیت می‌دهد و به دنبال هر تغییری می‌گردد که بتواند هزینه‌کرد آن را توجیه کند.

چرا هزینه‌ها جهش می‌کنند

وقتی مدل تصمیم به بازبینی می‌گیرد، هر فراخوانی اضافی برای read یا bash به صورت‌حساب اضافه می‌شود و اثرات ضرب‌شونده، هزینه کل را به سرعت بالا می‌برند.

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

چه زمانی تلاش بیشتر منطقی است

حالت بازبینی تنها زمانی می‌درخشد که خروجی اولیه فضا برای بهبود داشته باشد. در یک پروژه Go با پوشش تست ۰.۷۳، افزایش تلاش به حالت حداکثر، پوشش را به ۰.۸۸ رساند.

در مقابل، یک وظیفه در Python که از قبل به پوشش ۰.۹۸ رسیده بود، با افزایش بودجه هیچ تغییری نکرد. مدل صرفاً همان کد باکیفیت را دوباره بررسی کرد و بدون افزودن ارزش، هزینه را بالا برد.

معایب احتمالی

  • افزایش ناگهانی هزینه‌ها – کاربرانی که به قیمت‌های حالت تلاش کم عادت کرده‌اند، ممکن است از افزایش بیست و پنج برابری برای همان خروجی، غافلگیر شوند.

راهنمای کاربردی برای توسعه‌دهندگان

  • پرامپت‌های روتین را در سطح تلاش پیش‌فرض نگه دارید. شما با کسری از قیمت، همان نتیجه عملکردی را دریافت می‌کنید.
  • حالت «حداکثر تلاش» را برای کدهایی رزرو کنید که در رسیدن به یک آستانه کیفی مشخص شکست می‌خورند؛ مانند پوشش تست پایین، هشدارهای linting یا سایر شکاف‌های قابل اندازه‌گیری.
  • با این تنظیم مانند یک حالت مجزا برخورد کنید: یک مرحله بازبینی اختیاری، نه یک دکمه افزایش سرعت برای دریافت پاسخ‌های بهتر.

نتیجه‌گیری

سوئیچ max-effort در Claude Opus 5، پول را با یک بررسی کیفیت داخلی معاوضه می‌کند، نه با کد بهتر. از آن به ندرت و تنها زمانی استفاده کنید که نتایج پایه شما دارای یک شکاف قابل اندازه‌گیری باشد؛ در غیر این صورت، حالت پیش‌فرض و ارزان، همان نتیجه را بدون هزینه سنگین حالت بازبینی تحویل می‌دهد.

Source: https://dev.to/adrianco_54/retort-thinking-level-results-what-opus-actually-does-with-the-extra-time-55f7

Community discussion: https://t.me/GyaanSetuAi