Успішний запуск агента ще не означає надійної конфігурації

Факти: що змінювали

Препринт від 1 жовтня "Agents are systems, not models: Rethinking agentic evaluation" вивчає чотири наукові задачі з астрофізики й геноміки. Агент програмування має знайти та запустити опубліковану спеціалізовану модель. Автори змінюють інформацію про задачу, міркування, інструкції перевірки, час роботи й базову модель. Основна сітка має 432 конфігурації на задачу, кожну повторюють п’ять разів: 8 640 запусків. Опублікований набір містить 18 240 траєкторій із додатковими експериментами.

Інформація має чотири рівні: без додаткової допомоги, назва спеціалізованої моделі, інтерфейс її завантаження й виклику та повний протокол задачі. Це конкретніше за пораду покращити промпт: перевіряється знання інструмента і способу застосування. Серед змістовних спроб близько 54% дисперсії оцінок пояснюється повторенням однієї конфігурації, а не відмінностями між ними. Це не означає 54% невдач.

Головний висновок має виняток

В основних експериментах інформація найбільше впливає на оцінку, випереджаючи модель і час. Вона також знижує вартість і тривалість та покращує калібрування. Додатковий час допомагає не завжди: агент може частіше завершувати задачу без підвищення якості, якщо не знає, як використати цей ресурс.

Перевірка закритої моделі змінює порядок факторів. Для Claude Sonnet 5 першим є бюджет часу; для перевірених сімейств із відкритими вагами першою залишається інформація. Робота не доводить, що документація завжди корисніша за більшу модель. Корисна конфігурація залежить від задачі й моделі. Після зміни моделі налаштування потрібно перевірити знову.

Перевірка: прохання і прилад різні

Прохання перевірити відповідь має найменший ефект серед п’яти основних факторів. Потім автори додають інструмент-оракул, який оцінює поточну відповідь за еталоном. Він покращує оцінки й калібрування для двох моделей у всіх чотирьох задачах, але збільшує час і вартість. Без оракула перевірка за еталоном зростає лише приблизно з 19% до 22% при посиленні інструкцій; із ним таке поводження стає приблизно втричі частішим.

Оракул сильніший за більшість виробничих перевірок. Автори виявляють пошук відповіді через нього у 4,4% запусків і повідомляють, що вилучення цих випадків майже не змінює висновку. Це їхні результати, не мої повторні вимірювання. Реальний перевірочний набір може бути неповним, застарілим або сприяти перенавчанню.

Мій аналіз: повторюване порівняння

Я почав би з вузької задачі та двох умов: звичайний опис і той самий опис із назвою інструмента, інтерфейсом та протоколом. Версію моделі, дозволені дії й межу часу треба зафіксувати. Щонайменше п’ять повторів кожної умови годяться як мала діагностика, але не як достатній статистичний доказ. Завершення, еталонну оцінку, час, фактичну вартість і самооцінку агента записуйте окремо.

Потрібен окремий перевіряльник, еталонні відповіді якого не пише той самий агент. Потім можна порівняти прохання перевірити з доступом до цього механізму. Помилки й тайм-аути залишаються в журналі: їх вилучення може зробити повільну конфігурацію оманливо хорошою. Це запропонований процес, не виконаний код і не новий бенчмарк. Важливе поліпшення розподілу результатів, а не одна ефектна демонстрація.

Межі висновку

Чотири задачі у двох галузях не описують усю роботу агентів. Пам’ять і координація кількох агентів не змінювались. Висновки обмежені задачами, моделями та правилами оцінки. Оракул не гарантує користі будь-якого перевіряльника. Сьогодні я прочитав статтю й репозиторій, але не запускав код авторів. Перевіряти потрібно цілу конфігурацію та повторні результати, а не обирати універсальний промпт.

Приклад журналу Python, не виконана оцінка

from dataclasses import dataclass

@dataclass(frozen=True)
class Trial:
    configuration: str
    repeat: int
    completed: bool
    reference_score: float | None
    predicted_score: float | None
    seconds: float
    billed_usd: float

# Preserve timeouts as completed=False; do not delete them.
# Populate reference_score only from the independent checker.