Test-Time Scaling چیست؟ افزایش قدرت استدلال مدل‌های زبانی هنگام اجرا

برای افزایش توانایی مدل‌های زبانی معمولاً به سراغ مدل‌های بزرگ‌تر، داده‌های آموزشی بیشتر و هزینه بالاتر Training می‌رویم. اما روش دیگری نیز وجود دارد: اختصاص محاسبات بیشتر به مدل در همان لحظه‌ای که می‌خواهد به یک سؤال پاسخ دهد.

این رویکرد با نام‌های Test-Time Scaling، Inference-Time Scaling یا Test-Time Compute شناخته می‌شود.

در Test-Time Scaling لزوماً وزن‌های مدل تغییر نمی‌کنند. در عوض، سیستم هنگام Inference زمان، توکن یا نمونه‌های بیشتری مصرف می‌کند تا چند مسیر حل را بررسی کند، پاسخ خود را بازبینی کند یا از میان چند پاسخ، بهترین گزینه را انتخاب کند.

این ایده یکی از پایه‌های مهم مدل‌های Reasoning جدید است. به‌جای آنکه مدل بلافاصله اولین پاسخ احتمالی را برگرداند، می‌تواند محاسبات بیشتری برای حل مسئله انجام دهد.

پاسخ کوتاه: Test-Time Scaling چیست؟

Test-Time Scaling مجموعه‌ای از روش‌ها برای افزایش کیفیت پاسخ LLM با اختصاص منابع محاسباتی بیشتر در زمان Inference است.

این منابع می‌توانند به شکل‌های مختلف مصرف شوند:

• تولید توکن‌های بیشتر برای حل مسئله
• ساخت چند پاسخ مستقل
• رأی‌گیری میان پاسخ‌ها
• امتیازدهی پاسخ‌ها با یک Verifier
• بازبینی و اصلاح پاسخ اولیه
• جست‌وجو میان چند مسیر استدلال
• تخصیص Compute براساس سختی هر درخواست
• استفاده از چند Agent برای حل یک مسئله

هدف اصلی این است که بدون آموزش مجدد مدل، کیفیت پاسخ در وظایف دشوار افزایش پیدا کند.

تفاوت Training-Time Scaling و Test-Time Scaling

در Training-Time Scaling منابع محاسباتی پیش از انتشار مدل مصرف می‌شوند. افزایش داده، پارامتر، تعداد مرحله‌های Training یا استفاده از روش‌های Post-Training در این دسته قرار می‌گیرند.

در Test-Time Scaling منابع پس از آموزش مدل و هنگام پاسخ‌گویی به هر درخواست مصرف می‌شوند.

این دو رویکرد جایگزین کامل یکدیگر نیستند. یک مدل قوی‌تر می‌تواند هم‌زمان از Inference-Time Scaling نیز استفاده کند.

چرا محاسبات بیشتر هنگام Inference مفید است؟

مدل زبانی پاسخ را Token‌به‌Token تولید می‌کند. در تولید استاندارد، مدل معمولاً یک مسیر را دنبال کرده و پاسخ نهایی را براساس همان مسیر می‌سازد.

اگر مدل در ابتدای مسیر تصمیم نامناسبی بگیرد، ادامه پاسخ نیز ممکن است اشتباه باشد.

Test-Time Scaling چند امکان جدید ایجاد می‌کند:

• مدل می‌تواند بیش از یک مسیر را آزمایش کند.
• پاسخ‌های نامناسب پیش از نمایش حذف می‌شوند.
• نتیجه می‌تواند توسط مدل یا سیستم دیگری بررسی شود.
• مسائل دشوار Compute بیشتری نسبت به مسائل ساده دریافت می‌کنند.
• احتمال وابستگی به یک Sample تصادفی کاهش می‌یابد.

برای مثال، اگر مدل مسئله‌ای را با یک بار اجرا در ۶۰ درصد موارد درست حل کند، تولید چند پاسخ مستقل و انتخاب نتیجه‌ای که بیشتر تکرار شده است می‌تواند احتمال رسیدن به پاسخ صحیح را افزایش دهد؛ البته به شرطی که خطاهای مدل کاملاً هم‌بسته نباشند.

Test-Time Scaling چه ارتباطی با مدل‌های Reasoning دارد؟

مدل Reasoning مدلی است که برای انجام بهتر وظایف چندمرحله‌ای مانند ریاضی، برنامه‌نویسی، منطق و برنامه‌ریزی بهینه شده است.

در چنین مدل‌هایی، سیستم ممکن است پیش از تولید پاسخ نهایی:

• مسئله را تجزیه کند.
• مسیرهای مختلف را بررسی کند.
• نتیجه‌های میانی را ارزیابی کند.
• اشتباه‌ها را اصلاح کند.
• پاسخ نهایی را بازبینی کند.

با این حال، Test-Time Scaling فقط به مدل‌های دارای حالت Thinking محدود نیست. حتی یک مدل عمومی را نیز می‌توان چند بار اجرا و خروجی‌های آن را با رأی‌گیری یا Verifier ترکیب کرد.

روش‌های اصلی Test-Time Scaling

روش‌های Test-Time Scaling را می‌توان در چند گروه اصلی قرار داد.

تولید پاسخ طولانی‌تر

ساده‌ترین شکل Test-Time Scaling این است که مدل فرصت بیشتری برای بررسی مسئله داشته باشد.

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

• تعداد Tokenهای خروجی
• تعداد مرحله‌های حل
• مدت پردازش
• تعداد بازبینی‌ها

این روش برای وظایفی که واقعاً به تحلیل چندمرحله‌ای نیاز دارند مفید است؛ اما طولانی‌ترشدن پاسخ لزوماً به معنی بهترشدن آن نیست.

مدل ممکن است:

• مطالب تکراری تولید کند.
• از مسیر صحیح منحرف شود.
• پاسخ درست اولیه را تغییر دهد.
• بیش از حد مسئله را پیچیده کند.
• هزینه و Latency را بدون بهبود کیفیت افزایش دهد.

بنابراین «بیشتر فکرکردن» باید با کنترل کیفیت همراه باشد.

Parallel Sampling

در Parallel Sampling چند پاسخ مستقل برای یک سؤال تولید می‌شود.

برای مثال:

ورودی واحد
├── پاسخ شماره ۱
├── پاسخ شماره ۲
├── پاسخ شماره ۳
├── پاسخ شماره ۴
└── پاسخ شماره ۵

این پاسخ‌ها را می‌توان:

• با رأی‌گیری ترکیب کرد.
• با پاسخ مرجع مقایسه کرد.
• توسط Verifier رتبه‌بندی کرد.
• با کمک یک مدل داور ارزیابی کرد.
• برای ساخت یک پاسخ نهایی ادغام کرد.

مزیت این روش، امکان بررسی چند مسیر مستقل است. عیب آن نیز افزایش تقریباً مستقیم هزینه با تعداد Sampleهاست.

Self-Consistency

Self-Consistency روشی است که در آن مدل چند مسیر متفاوت برای حل یک مسئله تولید می‌کند و پاسخی انتخاب می‌شود که در بیشتر مسیرها تکرار شده است.

مراحل ساده Self-Consistency عبارت‌اند از:

1. سؤال چند بار به مدل ارسال می‌شود.
2. مدل پاسخ‌های متنوع تولید می‌کند.
3. جواب نهایی از هر پاسخ استخراج می‌شود.
4. نتایج مشابه گروه‌بندی می‌شوند.
5. پرتکرارترین جواب انتخاب می‌شود.

برای مثال، پنج پاسخ ممکن است نتیجه‌های زیر را تولید کنند:

پاسخ ۱: 42
پاسخ ۲: 42
پاسخ ۳: 38
پاسخ ۴: 42
پاسخ ۵: 40

در این حالت عدد ۴۲ با رأی اکثریت انتخاب می‌شود.

پژوهش Self-Consistency نشان داد نمونه‌برداری از چند مسیر و انتخاب پاسخ پرتکرار می‌تواند عملکرد Chain-of-Thought را در مجموعه‌ای از وظایف محاسباتی و استدلالی بهبود دهد. منبع: پژوهش Self-Consistency

این روش بیشتر برای سؤالاتی مناسب است که پاسخ نهایی مشخصی دارند؛ مانند:

• محاسبات ریاضی
• سؤال چندگزینه‌ای
• طبقه‌بندی
• استدلال منطقی
• تولید خروجی ساختاریافته
• پاسخ کوتاه قابل نرمال‌سازی

Self-Consistency برای محتوای کاملاً باز مانند نوشتن داستان یا ایمیل، نیازمند معیار دیگری برای ادغام نتایج است.

Best-of-N

در روش Best-of-N مدل تعداد N پاسخ تولید می‌کند و سپس بهترین پاسخ انتخاب می‌شود.

تفاوت آن با Self-Consistency در شیوه انتخاب است:

• Self-Consistency معمولاً از تکرار پاسخ یا رأی اکثریت استفاده می‌کند.
• Best-of-N پاسخ‌ها را با یک معیار یا Verifier امتیازدهی می‌کند.

فرایند کلی:

1. تولید N پاسخ
2. محاسبه امتیاز هر پاسخ
3. مرتب‌سازی پاسخ‌ها
4. انتخاب پاسخ دارای بیشترین امتیاز

تابع امتیازدهی ممکن است یکی از موارد زیر باشد:

• یک مدل زبانی دیگر
• Reward Model
• Unit Test
• Compiler
• پاسخ مرجع
• قواعد کسب‌وکار
• معیارهای قطعی
• ترکیبی از چند معیار

Best-of-N زمانی مفید است که تولید پاسخ خوب برای مدل امکان‌پذیر باشد، اما مدل همیشه آن پاسخ را در اجرای اول تولید نکند.

Verifier چیست؟

Verifier سیستمی است که صحت یا کیفیت پاسخ پیشنهادی را بررسی می‌کند.

Verifier ممکن است قطعی باشد. برای مثال:

• اجرای Unit Test روی کد
• بررسی معتبر بودن JSON
• مقایسه نتیجه عددی
• اجرای Query آزمایشی
• بررسی Schema
• استفاده از Compiler
• تطبیق با پاسخ مرجع

در وظایف بازتر، Verifier می‌تواند یک مدل هوش مصنوعی باشد که پاسخ‌ها را براساس Rubric امتیازدهی می‌کند.

Verifier خوب باید بتواند میان پاسخ ظاهراً قانع‌کننده و پاسخ واقعاً صحیح تمایز ایجاد کند. اگر Verifier ضعیف باشد، افزایش تعداد Candidateها ممکن است کمکی نکند؛ زیرا سیستم همچنان پاسخ نامناسبی را انتخاب خواهد کرد.

Outcome Reward Model چیست؟

Outcome Reward Model یا ORM فقط نتیجه نهایی را ارزیابی می‌کند.

برای مثال، در حل یک مسئله ریاضی ORM ممکن است بررسی کند:

• پاسخ نهایی صحیح است یا خیر؟
• احتمال صحیح‌بودن پاسخ چقدر است؟
• پاسخ کامل و مرتبط است یا خیر؟

ORM لزوماً مراحل میانی حل را ارزیابی نمی‌کند.

مزیت آن سادگی بیشتر است، اما ممکن است پاسخ‌هایی را که به‌صورت تصادفی به نتیجه صحیح رسیده‌اند، با پاسخ‌های دارای استدلال معتبر یکسان در نظر بگیرد.

Process Reward Model چیست؟

Process Reward Model یا PRM مراحل میانی حل مسئله را ارزیابی می‌کند.

فرض کنید پاسخ شامل پنج مرحله است. PRM می‌تواند برای هر مرحله یک امتیاز تولید کند:

مرحله ۱: صحیح
مرحله ۲: صحیح
مرحله ۳: دارای خطا
مرحله ۴: مبتنی بر نتیجه اشتباه
مرحله ۵: پاسخ نهایی نامعتبر

این اطلاعات به سیستم اجازه می‌دهد مسیر ضعیف را زودتر متوقف کند یا از مرحله معتبر به مسیر دیگری برود.

در پژوهش Test-Time Compute، جست‌وجو با Verifierهای فرایندمحور یکی از روش‌های اصلی تخصیص Compute در زمان Inference بررسی شده است. نتایج نشان می‌دهند اثربخشی روش‌ها به سختی سؤال و کیفیت مدل پایه بستگی دارد. منبع: Scaling LLM Test-Time Compute Optimally

بازبینی و اصلاح پاسخ

در روش Sequential Revision، مدل ابتدا یک پاسخ تولید و سپس همان پاسخ را نقد و اصلاح می‌کند.

فرایند ممکن است چنین باشد:

1. تولید پاسخ اولیه
2. شناسایی ضعف‌ها
3. پیشنهاد اصلاحات
4. تولید نسخه جدید
5. بررسی شرایط توقف

نمونه پرامپت بازبینی:

پاسخ پیشنهادی را از نظر صحت، کامل‌بودن و رعایت درخواست
بررسی کن. فقط خطاهای مشخص را گزارش بده و سپس نسخه
اصلاح‌شده را ارائه کن.

این روش برای موارد زیر مناسب است:

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

با این حال، مدل ممکن است هنگام بازبینی پاسخ درست را خراب کند. بنابراین بهتر است اصلاح فقط در صورت شناسایی یک مشکل مشخص انجام شود.

Search-Based Inference

در روش‌های مبتنی بر Search، سیستم به‌جای تولید یک پاسخ کامل، فضای چند مسیر احتمالی را بررسی می‌کند.

هر Node می‌تواند یک حالت میانی از حل مسئله باشد:

مسئله
├── مسیر A
│   ├── مرحله A1
│   └── مرحله A2
├── مسیر B
│   ├── مرحله B1
│   └── مرحله B2
└── مسیر C
    ├── مرحله C1
    └── مرحله C2

یک Verifier یا Value Function مشخص می‌کند کدام مسیر ارزش ادامه‌دادن دارد.

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

• Beam Search
• Tree Search
• Monte Carlo Tree Search
• Best-First Search
• Guided Search

این روش‌ها می‌توانند در مسائل پیچیده مؤثر باشند، اما به تعداد فراخوانی بیشتر، مدیریت State و Verifier دقیق نیاز دارند.

Multi-Agent Reasoning

در این رویکرد، چند Agent یا چند نقش مستقل روی مسئله کار می‌کنند.

برای مثال:

• Agent اول راه‌حل پیشنهاد می‌کند.
• Agent دوم خطاهای آن را بررسی می‌کند.
• Agent سوم راه‌حل جایگزین می‌سازد.
• Agent داور نتیجه نهایی را انتخاب می‌کند.

این ساختار می‌تواند تنوع مسیرها را افزایش دهد، اما همیشه بهتر از یک مدل واحد نیست. Agentها ممکن است:

• خطای یکدیگر را تکرار کنند.
• تحت تأثیر پاسخ اولیه قرار بگیرند.
• هزینه زیادی ایجاد کنند.
• مکالمه غیرضروری تولید کنند.
• بدون معیار قطعی به توافق اشتباه برسند.

برای آشنایی بیشتر با ساختار Agentها، مقاله AI Agent چیست؟ را مطالعه کنید.

Adaptive Compute چیست؟

در روش ثابت، تمام درخواست‌ها Compute یکسانی دریافت می‌کنند. برای مثال، برای هر سؤال همیشه هشت پاسخ تولید می‌شود.

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

در Adaptive Compute بودجه محاسباتی براساس سختی یا عدم قطعیت درخواست تنظیم می‌شود.

برای مثال:

• سؤال ساده: یک پاسخ
• سؤال متوسط: سه پاسخ و رأی‌گیری
• سؤال دشوار: چند پاسخ و Verifier
• سؤال بسیار دشوار: Search، بازبینی و تأیید انسانی

پژوهش Scaling LLM Test-Time Compute نشان داد راهبرد مناسب به سطح دشواری سؤال وابسته است و تخصیص تطبیقی Compute می‌تواند از Best-of-N ثابت کارآمدتر باشد. منبع پژوهش

چگونه سختی سؤال را تخمین بزنیم؟

تخمین Difficulty خود یک مسئله مهم است. می‌توان از سیگنال‌های زیر استفاده کرد:

• طول ورودی
• نوع وظیفه
• تعداد محدودیت‌ها
• میزان Confidence مدل
• اختلاف میان پاسخ‌های اولیه
• امتیاز Verifier
• سابقه خطا روی نمونه‌های مشابه
• وجود کد، ریاضی یا منطق چندمرحله‌ای
• نیاز به Tool Calling
• تشخیص یک مدل Router

برای مثال، اگر سه پاسخ اولیه همگی به نتیجه یکسان برسند، سیستم می‌تواند زودتر متوقف شود. اگر پاسخ‌ها متفاوت باشند، Compute بیشتری اختصاص داده می‌شود.

Early Stopping

برای جلوگیری از مصرف غیرضروری منابع، سیستم باید شرایط توقف داشته باشد.

نمونه شرایط توقف:

• سه پاسخ متوالی نتیجه یکسان دارند.
• Confidence از آستانه مشخص بیشتر است.
• Unit Testها با موفقیت اجرا شده‌اند.
• Verifier پاسخ را پذیرفته است.
• بودجه Token تمام شده است.
• تعداد اصلاح‌ها به سقف رسیده است.
• بهبود امتیاز متوقف شده است.

بدون Early Stopping، Test-Time Scaling ممکن است هزینه زیادی ایجاد کند بدون آنکه کیفیت پاسخ بهتر شود.

نمونه پیاده‌سازی Self-Consistency با API درواره

API درواره با ساختار سازگار با OpenAI امکان دسترسی به مدل‌های مختلف را از یک Base URL فراهم می‌کند.

ابتدا کتابخانه موردنیاز را نصب کنید:

pip install openai

کلید API را در متغیر محیطی قرار دهید:

export DARVAREH_API_KEY="YOUR_API_KEY"

کد نمونه:

import os
from collections import Counter

from openai import OpenAI


client = OpenAI(
    api_key=os.environ["DARVAREH_API_KEY"],
    base_url="https://api.darvareh.ir/v1",
)


def generate_candidate(
    question: str,
    model: str,
) -> str:
    response = client.chat.completions.create(
        model=model,
        messages=[
            {
                "role": "system",
                "content": (
                    "مسئله را دقیق بررسی کن و در پایان، "
                    "جواب نهایی را در یک خط با قالب "
                    "FINAL: answer بنویس."
                ),
            },
            {
                "role": "user",
                "content": question,
            },
        ],
        temperature=0.7,
    )

    return response.choices[0].message.content


def extract_final_answer(text: str) -> str:
    for line in reversed(text.splitlines()):
        if line.strip().upper().startswith("FINAL:"):
            return line.split(":", 1)[1].strip().lower()

    return text.strip().lower()


def self_consistency(
    question: str,
    model: str,
    sample_count: int = 5,
) -> dict:
    candidates = [
        generate_candidate(question, model)
        for _ in range(sample_count)
    ]

    final_answers = [
        extract_final_answer(candidate)
        for candidate in candidates
    ]

    counts = Counter(final_answers)
    selected_answer, votes = counts.most_common(1)[0]

    return {
        "answer": selected_answer,
        "votes": votes,
        "total_samples": sample_count,
        "agreement": votes / sample_count,
        "candidates": candidates,
    }


result = self_consistency(
    question="اگر قیمت یک محصول پس از ۲۰ درصد تخفیف ۸۰۰ هزار تومان باشد، قیمت اولیه چقدر بوده است؟",
    model="YOUR_MODEL",
    sample_count=5,
)

print(result["answer"])
print(result["agreement"])

مدل موردنظر را می‌توانید از صفحه مدل‌های درواره انتخاب کنید.

در محیط Production بهتر است پاسخ نهایی دارای ساختار مشخص باشد تا استخراج آن به روش پردازش متن وابسته نباشد. مقاله Structured Outputs چیست؟ در این زمینه مفید است.

پیاده‌سازی Best-of-N با مدل داور

در این روش چند Candidate تولید و سپس توسط یک مدل دیگر ارزیابی می‌شوند.

import json


def select_best_candidate(
    question: str,
    candidates: list[str],
    judge_model: str,
) -> dict:
    formatted_candidates = "\n\n".join(
        f"Candidate {index + 1}:\n{candidate}"
        for index, candidate in enumerate(candidates)
    )

    prompt = f"""
سؤال:
{question}

پاسخ‌های پیشنهادی:
{formatted_candidates}

بهترین پاسخ را فقط براساس معیارهای زیر انتخاب کن:
- صحت
- ارتباط مستقیم با سؤال
- کامل‌بودن
- نبود ادعای بدون پشتوانه

طول بیشتر به‌تنهایی مزیت نیست.

فقط JSON معتبر برگردان:
{{
  "best_candidate": 1,
  "reason": "دلیل کوتاه"
}}
"""

    response = client.chat.completions.create(
        model=judge_model,
        messages=[
            {
                "role": "user",
                "content": prompt,
            }
        ],
        temperature=0,
    )

    return json.loads(
        response.choices[0].message.content
    )

در این ساختار بهتر است مدل تولیدکننده و مدل داور یکسان نباشند. همچنین برای وظایف قابل‌بررسی، Unit Test یا معیار قطعی معمولاً از مدل داور قابل‌اعتمادتر است.

نمونه Adaptive Compute

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

def adaptive_self_consistency(
    question: str,
    model: str,
) -> dict:
    first_result = self_consistency(
        question=question,
        model=model,
        sample_count=3,
    )

    if first_result["agreement"] >= 0.67:
        return {
            **first_result,
            "compute_level": "low",
        }

    second_result = self_consistency(
        question=question,
        model=model,
        sample_count=7,
    )

    return {
        **second_result,
        "compute_level": "high",
    }

در یک سیستم واقعی بهتر است Candidateهای مرحله اول دوباره تولید نشوند و Sampleهای جدید به همان مجموعه اضافه شوند.

انتخاب Temperature مناسب

Temperature روی تنوع Sampleها اثر می‌گذارد.

Temperature بسیار پایین

اگر Temperature صفر یا بسیار پایین باشد، پاسخ‌های مختلف ممکن است تقریباً یکسان شوند. در این حالت Parallel Sampling تنوع کافی ایجاد نمی‌کند.

Temperature بسیار بالا

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

رویکرد عملی

برای Self-Consistency معمولاً به مقداری از تنوع نیاز داریم. مقدار دقیق باید با Evals روی Dataset واقعی انتخاب شود.

همچنین می‌توان:

• برای Candidate Generation از Temperature بالاتر استفاده کرد.
• برای Judge یا Verifier از Temperature پایین استفاده کرد.
• پاسخ‌های تکراری را پیش از داوری حذف کرد.
• میزان تنوع را اندازه‌گیری کرد.

برای آشنایی بیشتر، مقاله Temperature در هوش مصنوعی چیست؟ را بخوانید.

Test-Time Scaling برای برنامه‌نویسی

کدنویسی یکی از مناسب‌ترین کاربردهای Test-Time Scaling است؛ زیرا بسیاری از خروجی‌ها را می‌توان به‌صورت قطعی بررسی کرد.

فرایند پیشنهادی:

1. چند پیاده‌سازی تولید کنید.
2. کدها را در Sandbox اجرا کنید.
3. Unit Testها را اجرا کنید.
4. پاسخ‌های دارای خطای Syntax را حذف کنید.
5. مصرف حافظه و زمان را اندازه‌گیری کنید.
6. بهترین پاسخ معتبر را انتخاب کنید.
7. در صورت شکست همه نمونه‌ها، Feedback تست را به مدل برگردانید.

در این سناریو، Test Runner نقش Verifier را دارد و معمولاً از قضاوت متنی یک LLM قابل‌اعتمادتر است.

نمونه معیار امتیاز:

score =
    passed_tests * 10
    - failed_tests * 20
    - execution_time_penalty
    - memory_penalty

Test-Time Scaling برای RAG

در سیستم RAG می‌توان Compute بیشتری به مراحل مختلف اختصاص داد:

• بازنویسی چندگانه Query
• اجرای چند Retriever
• بازیابی تعداد بیشتری سند
• Reranking نتایج
• تولید چند پاسخ
• بررسی Faithfulness
• اصلاح پاسخ براساس Context

یک جریان پیشرفته ممکن است به شکل زیر باشد:

1. سه Query مختلف از سؤال تولید شود.
2. برای هر Query جست‌وجو انجام شود.
3. اسناد ادغام و Rerank شوند.
4. چند پاسخ مستقل تولید شود.
5. پاسخ‌ها از نظر وفاداری به منابع بررسی شوند.
6. پاسخ نهایی همراه با Citation ساخته شود.

این روش می‌تواند کیفیت را افزایش دهد، اما تعداد فراخوانی مدل، Vector Database و Reranker را نیز بیشتر می‌کند.

برای آشنایی با ارزیابی این سیستم‌ها، مقاله ارزیابی RAG با معیارهای Retrieval و Generation را مطالعه کنید.

Test-Time Scaling برای AI Agent

در Agentها، Compute فقط به تعداد Token محدود نیست. منابع بیشتر می‌توانند به شکل‌های زیر مصرف شوند:

• Rolloutهای بیشتر
• برنامه‌ریزی چندگانه
• اجرای ابزارهای مختلف
• بازبینی نتیجه ابزار
• مقایسه چند Plan
• اصلاح مسیر پس از خطا
• استفاده از Verifier
• شبیه‌سازی نتیجه اقدامات

اما افزایش بی‌هدف تعداد مرحله‌ها می‌تواند مشکل‌ساز شود. Agent ممکن است زمان زیادی صرف برنامه‌ریزی کند یا Tool Callهای تکراری انجام دهد.

برای Agent بهتر است Budgetهای زیر جداگانه تعریف شوند:

• حداکثر Token
• حداکثر تعداد Step
• حداکثر Tool Call
• حداکثر هزینه
• حداکثر زمان
• حداکثر تعداد Retry

آیا مدل کوچک با Compute بیشتر از مدل بزرگ بهتر است؟

پاسخ به سختی سؤال و کیفیت مدل پایه بستگی دارد.

پژوهش Test-Time Compute نشان داد در برخی مسائل که مدل کوچک توانایی اولیه قابل قبولی دارد، تخصیص بهینه Compute هنگام Inference می‌تواند آن را از یک مدل بسیار بزرگ‌تر پیش بیندازد. اما اگر مسئله برای مدل پایه بیش از حد دشوار باشد، تولید نمونه‌های بیشتر ممکن است فقط خطاهای بیشتری ایجاد کند.

به‌طور خلاصه:

• اگر مدل گاهی پاسخ صحیح تولید می‌کند، Search و انتخاب می‌تواند مفید باشد.
• اگر مدل دانش یا توانایی پایه لازم را ندارد، Compute بیشتر احتمالاً کافی نیست.
• کیفیت Verifier به‌اندازه کیفیت Generator اهمیت دارد.
• یک راهبرد واحد برای تمام سؤالات بهترین نیست.

مفهوم Pass@k

در وظایفی مانند کدنویسی می‌توان بررسی کرد آیا حداقل یکی از k پاسخ تولیدشده صحیح است یا خیر.

اگر از میان ۱۰ پاسخ، حداقل یک پاسخ تمام تست‌ها را پاس کند، مقدار Pass@10 برای آن مسئله موفق در نظر گرفته می‌شود.

Pass@k نشان می‌دهد مدل توانایی تولید پاسخ صحیح را دارد، اما سیستم Production هنوز باید بتواند همان پاسخ صحیح را از میان Candidateها انتخاب کند.

این تفاوت مهم است:

• Generation Capability: آیا پاسخ صحیح در میان نمونه‌ها وجود دارد؟
• Selection Capability: آیا سیستم می‌تواند آن پاسخ را تشخیص دهد؟

افزایش k بدون Verifier مناسب ممکن است قابلیت تولید را بالا ببرد، اما کیفیت پاسخ نمایش‌داده‌شده به کاربر را بهبود ندهد.

هزینه Test-Time Scaling چگونه محاسبه می‌شود؟

هزینه تقریبی به تعداد Candidateها و طول هر پاسخ وابسته است:

[
C_{\text{total}} =
C_{\text{input}} +
N \times C_{\text{generation}} +
C_{\text{verification}}
]

اگر Context برای هر Candidate دوباره ارسال شود، هزینه Input نیز ممکن است چند برابر شود:

[
C_{\text{total}} =
N \times (C_{\text{input}} + C_{\text{output}})

• C_{\text{judge}}
  ]

عوامل مؤثر عبارت‌اند از:

• تعداد Sample
• طول Context
• طول پاسخ
• قیمت مدل Generator
• قیمت مدل Verifier
• تعداد مرحله‌های Revision
• تعداد Tool Call
• Cache
• Parallel یا Sequential بودن اجرا

برای کنترل هزینه می‌توان از Prompt Caching، مدل‌های ارزان‌تر و Early Stopping استفاده کرد. مقاله راهنمای Prompt Caching جزئیات بیشتری ارائه می‌دهد.

تأثیر Test-Time Scaling بر Latency

Parallel Sampling و Sequential Revision اثر متفاوتی روی زمان پاسخ دارند.

اجرای موازی

اگر پنج Candidate هم‌زمان تولید شوند، Latency می‌تواند نزدیک به کندترین Candidate باشد، اما توان محاسباتی و هزینه بیشتری در لحظه مصرف می‌شود.

اجرای متوالی

اگر مدل ابتدا پاسخ بسازد و سپس چند بار آن را اصلاح کند، Latency مراحل با یکدیگر جمع می‌شود.

[
L_{\text{sequential}} =
L_1 + L_2 + L_3 + \cdots + L_n
]

برای کاربردهای تعاملی، Latency ممکن است مهم‌تر از افزایش جزئی کیفیت باشد. برای پردازش Batch یا گزارش‌های آفلاین، می‌توان Compute بیشتری اختصاص داد.

چه زمانی Test-Time Scaling مناسب است؟

این روش برای وظایفی مناسب‌تر است که:

• ارزش پاسخ صحیح بالا باشد.
• امکان ارزیابی Candidateها وجود داشته باشد.
• Latency بیشتر قابل قبول باشد.
• مدل گاهی پاسخ صحیح تولید کند.
• مسئله چندمرحله‌ای باشد.
• خروجی قابل تست یا مقایسه باشد.
• هزینه خطا بیشتر از هزینه Inference باشد.

نمونه کاربردها:

• تولید و اصلاح کد
• مسائل ریاضی
• برنامه‌ریزی
• تحلیل داده
• استخراج ساختاریافته
• پاسخ‌های تخصصی
• RAG سازمانی
• ساخت Query
• حل مسئله منطقی
• تصمیم‌های چندمرحله‌ای

چه زمانی مناسب نیست؟

Test-Time Scaling ممکن است برای این موارد مناسب نباشد:

• پاسخ‌های بسیار ساده
• Autocomplete سریع
• طبقه‌بندی کم‌اهمیت
• کاربردهای حساس به Latency
• درخواست‌های بسیار پرتعداد و ارزان
• وظایفی که Verifier قابل اعتمادی ندارند
• مسائلی که مدل پایه اساساً قادر به حل آن‌ها نیست
• تولید محتوایی که تنوع مهم‌تر از یک پاسخ برتر است

برای سؤال ساده‌ای مانند «پایتخت فرانسه چیست؟» تولید ۱۶ پاسخ و استفاده از داور اتلاف منابع است.

خطر Overthinking

یکی از فرض‌های اشتباه این است که هرچه مدل بیشتر فکر کند، پاسخ حتماً بهتر می‌شود.

در عمل، Compute اضافی ممکن است بازده کاهشی داشته باشد:

• مرحله‌های جدید نکته‌ای اضافه نمی‌کنند.
• مدل پاسخ صحیح را بیش از حد بازبینی می‌کند.
• مسیر حل طولانی و شکننده می‌شود.
• تناقض‌های جدید ایجاد می‌شوند.
• هزینه افزایش می‌یابد اما Accuracy ثابت می‌ماند.

پژوهش‌های جدیدتر نیز نشان می‌دهند طولانی‌ترشدن فرایند Reasoning همیشه به بهبود یکنواخت کیفیت منجر نمی‌شود. منبع: پژوهش Overthinking in LLM Test-Time Compute Scaling

بنابراین باید Marginal Gain یا میزان بهبود حاصل از هر واحد Compute اضافی اندازه‌گیری شود.

چگونه Compute Budget تعیین کنیم؟

بودجه مناسب را نباید براساس حدس انتخاب کرد. بهتر است چند پیکربندی روی Dataset واقعی آزمایش شوند.

برای مثال:

هدف لزوماً بیشترین Accuracy نیست. ممکن است پیکربندی Adaptive با هزینه کمتر، انتخاب بهتری برای Production باشد.

معیارهای ارزیابی Test-Time Scaling

برای مقایسه راهبردها فقط Accuracy کافی نیست. معیارهای زیر را نیز اندازه‌گیری کنید:

• Accuracy
• Pass@k
• Cost per Request
• Cost per Correct Answer
• Median Latency
• P95 Latency
• Token Usage
• Agreement Rate
• Verifier Accuracy
• Tool Call Count
• Retry Count
• Early-Stop Rate

معیار Cost per Correct Answer اهمیت ویژه‌ای دارد:

[
\text{Cost per Correct Answer} =
\frac{\text{Total Cost}}
{\text{Number of Correct Answers}}
]

ممکن است یک روش هزینه هر درخواست را افزایش دهد، اما به دلیل کاهش خطا، هزینه هر پاسخ صحیح آن مناسب‌تر باشد.

معماری پیشنهادی برای Production

یک سیستم Test-Time Scaling می‌تواند اجزای زیر را داشته باشد:

1. Difficulty Estimator: تخمین سختی درخواست
2. Budget Allocator: تعیین Token، Sample و زمان
3. Generator: تولید Candidateها
4. Normalizer: استخراج پاسخ نهایی
5. Verifier: امتیازدهی یا تست پاسخ
6. Aggregator: رأی‌گیری یا انتخاب پاسخ
7. Stopping Controller: مدیریت Early Stopping
8. Fallback: تغییر مدل یا ارجاع به انسان
9. Observability: ثبت هزینه، Latency و کیفیت
10. Evaluator: سنجش دوره‌ای عملکرد سیستم

برای پایش چنین معماری‌ای، مقاله AI Observability چیست؟ را مطالعه کنید.

چک‌لیست پیاده‌سازی Test-Time Scaling

• مشخص کرده‌اید کدام وظایف به Compute بیشتر نیاز دارند.
• Dataset واقعی برای ارزیابی وجود دارد.
• Baseline تک‌پاسخی اندازه‌گیری شده است.
• تعداد Candidateها محدود است.
• روش انتخاب پاسخ مشخص است.
• Verifier جداگانه ارزیابی شده است.
• شرایط Early Stopping تعریف شده‌اند.
• سقف هزینه و Latency وجود دارد.
• پاسخ‌های تکراری حذف می‌شوند.
• Generator و Verifier نسخه‌بندی شده‌اند.
• نرخ توافق Candidateها ثبت می‌شود.
• کیفیت در برابر هزینه مقایسه می‌شود.
• برای مسائل ساده مسیر Fast Path وجود دارد.
• برای شکست Verifier مسیر Fallback تعریف شده است.

اشتباهات رایج

استفاده از Sample بیشتر بدون روش انتخاب

وجود پاسخ صحیح میان ۲۰ Candidate مفید نیست اگر سیستم نتواند آن را پیدا کند.

یک Budget ثابت برای تمام درخواست‌ها

سؤال‌های ساده و دشوار نباید همیشه منابع یکسانی دریافت کنند.

استفاده از همان مدل به‌عنوان داور بدون ارزیابی

مدل ممکن است سبک پاسخ خود را ترجیح دهد یا خطاهای مشابهی داشته باشد.

نادیده‌گرفتن Latency انتهایی

میانگین Latency کافی نیست. P95 و P99 نیز باید اندازه‌گیری شوند.

طولانی‌کردن اجباری پاسخ

Reasoning طولانی همیشه بهتر نیست و می‌تواند Overthinking ایجاد کند.

تغییر هم‌زمان چند مؤلفه

اگر مدل، Prompt، تعداد Sample و Verifier هم‌زمان تغییر کنند، علت بهبود یا افت کیفیت مشخص نخواهد بود.

نبود محدودیت هزینه

یک Loop بازبینی بدون سقف می‌تواند Token و هزینه زیادی مصرف کند.

جمع‌بندی

Test-Time Scaling روشی برای افزایش توانایی مدل‌های زبانی با اختصاص محاسبات بیشتر هنگام Inference است. این Compute می‌تواند برای تولید پاسخ‌های بیشتر، بازبینی، رأی‌گیری، ارزیابی با Verifier یا جست‌وجو میان مسیرهای مختلف استفاده شود.

روش‌های اصلی آن عبارت‌اند از:

• پاسخ طولانی‌تر
• Parallel Sampling
• Self-Consistency
• Best-of-N
• Sequential Revision
• Verifier-Based Selection
• Search-Based Inference
• Multi-Agent Reasoning
• Adaptive Compute

بیشترشدن Compute به‌تنهایی تضمین‌کننده پاسخ بهتر نیست. کیفیت مدل پایه، تنوع Candidateها، دقت Verifier، سختی مسئله و روش تخصیص Budget همگی در نتیجه نقش دارند.

بهترین راهبرد در Production معمولاً یک مسیر تطبیقی است: سؤال‌های ساده با یک پاسخ سریع پردازش می‌شوند و فقط درخواست‌های دشوار Compute بیشتری دریافت می‌کنند.

با استفاده از API درواره می‌توانید مدل‌های مختلف را از طریق یک API آزمایش کنید، Generator و Verifier جداگانه بسازید و راهبرد مناسب Test-Time Scaling را براساس کیفیت، هزینه و سرعت انتخاب کنید.

سؤالات متداول

Test-Time Scaling چیست؟

Test-Time Scaling به روش‌هایی گفته می‌شود که با اختصاص محاسبات، زمان یا Token بیشتر هنگام Inference، کیفیت پاسخ مدل زبانی را افزایش می‌دهند.

تفاوت Test-Time Scaling و Fine-Tuning چیست؟

در Fine-Tuning وزن‌های مدل با داده‌های جدید تغییر می‌کنند. در Test-Time Scaling معمولاً وزن‌ها ثابت می‌مانند و فقط فرایند تولید و انتخاب پاسخ تغییر می‌کند.

Self-Consistency چیست؟

در Self-Consistency چند مسیر مستقل برای حل مسئله تولید می‌شوند و پاسخ پرتکرار یا مورد توافق انتخاب می‌شود.

Best-of-N چیست؟

در Best-of-N تعداد N پاسخ تولید و سپس بهترین پاسخ با یک Verifier، Reward Model یا معیار قطعی انتخاب می‌شود.

آیا تعداد Sample بیشتر همیشه بهتر است؟

خیر. پس از نقطه‌ای مشخص، بازده کاهش می‌یابد و هزینه بیشتر ممکن است بهبود قابل توجهی ایجاد نکند.

Verifier چه نقشی دارد؟

Verifier صحت یا کیفیت Candidateها را بررسی می‌کند و به سیستم کمک می‌کند بهترین پاسخ را انتخاب کند.

آیا مدل کوچک با Test-Time Scaling از مدل بزرگ بهتر می‌شود؟

در برخی وظایف ممکن است مدل کوچک با Compute بیشتر از مدل بزرگ‌تر بهتر عمل کند؛ به‌ویژه اگر مدل کوچک توانایی پایه حل مسئله را داشته باشد. این نتیجه برای تمام وظایف تضمین‌شده نیست.

Adaptive Compute چیست؟

Adaptive Compute بودجه محاسباتی را براساس سختی یا عدم قطعیت هر درخواست تنظیم می‌کند.

Test-Time Scaling چه اثری روی هزینه دارد؟

تولید Candidateهای بیشتر، استفاده از Verifier و بازبینی‌های متوالی مصرف Token و تعداد درخواست‌ها را افزایش می‌دهند. Early Stopping و تخصیص تطبیقی می‌توانند هزینه را کنترل کنند.

بهترین کاربرد Test-Time Scaling چیست؟

این روش برای مسائل ریاضی، کدنویسی، برنامه‌ریزی، RAG، استخراج ساختاریافته و وظایف چندمرحله‌ای که امکان بررسی پاسخ دارند مناسب است.