Проверь измерение
Репрезентативные задачи, согласованный критерий успеха и повторные прогоны нужны ещё до оптимизации.
Как команды build-eval и hillclimb помогают создавать проверки, менять промпты и снижать стоимость, отслеживая переобучение.
Рост балла имеет смысл, если оценка отражает рабочие задачи, проверяющий заслуживает доверия, а улучшение сохраняется на скрытых примерах и превышает шум.
Репрезентативные задачи, согласованный критерий успеха и повторные прогоны нужны ещё до оптимизации.
Выбери цель и то, что разрешено менять: промпт, skill, описание инструмента, модель, effort или код обвязки.
Анализатор читает только ошибки train. Рост train при неизменном test — повод откатить правку.
Eval — набор задач с проверкой результата. Автор выделяет четыре свойства, без которых рост балла легко принять за прогресс.
Выбирайте то, что приложение должно делать в эксплуатации. Простота генерации или проверки примера сама по себе не делает его полезным.
Более способная модель и больший effort обычно должны помогать. Если зависимости нет, проверьте неоднозначные задания и критерии оценки.
Даже сильнейшая модель не должна решать всё. Но вечный провал во всех повторах может указывать на невыполнимое задание или скрытое требование.
Проверьте стабильность проверяющего, применение effort и чистоту окружения. Файлы или история Git от прошлого запуска могут раскрыть ответ.
Такой отбор запоминает частные слабости одной модели. Берите задачи, сложность которых может объяснить человек, реальные сбои из обращений и примеры, где действие выполнять не нужно. При этом один лишь пользовательский трафик тоже может быть слишком лёгким: люди часто пробуют только то, что ожидают получить.
В статье ↗/claude-api build-eval
Приоритет: рабочие трассы после обсуждения хранения и чувствительных данных → баг-репорты и обращения → 5–10 ручных примеров → синтетика по кодовой базе. Claude показывает каждый вход на странице и ждёт подтверждения.
Фиксированные ответы: exact match, допустимая метка, JSON Schema или тесты. Свободные ответы: LLM-as-judge, то есть отдельная модель с набором проверяемых критериев, а не расплывчатой шкалой 1–5.
Прочитайте несколько ответов вместе с выставленными баллами. Модель-судья должна отличаться от проверяемой. Для сравнения с baseline ответы подаются в случайном порядке, без указания, какой из них базовый.
До запуска Claude сообщает объём: примеры × повторы × модели, а также примерное время. Результат включает балл с доверительным интервалом, случаи, проверяющий, runner, JSONL, полные трассы и страницу результатов.
Один и тот же ответ оценивается дважды. Изменившийся вердикт показывает нестабильность grader — механизма выставления оценки.
Тайм-ауты, ошибки API и обрезанные ответы нужно отделить от поведения модели. При baseline около 95% и выше разумнее исследовать стоимость или задержку.
/claude-api hillclimb
Перед началом задайте цель: улучшить качество или снизить стоимость при сохранении качества. Выберите разрешённые изменения. Текстовые промпты и skills удобно менять и откатывать; свободная переделка всей обвязки усложняет поиск причины улучшения.
Claude случайно делит примеры на train и test и проверяет, что шум меньше минимального полезного выигрыша. Если нет, предлагает больше примеров или повторов.
Прочитать трассы и найти причину
Изменить выбранный компонент
Оценить выигрыш и регрессии
Схема конспекта: анализатор получает ошибки train; скрытые примеры test ему недоступны.
В описанном цикле улучшения качества баллы train и test выросли. Правка устраняет причину сбоя; её эффект заметен на фоне шума.
Train вырос, test не изменился — подозрение на переобучение. Регрессия тоже ведёт к откату. Для цели по стоимости результат сравнивают с заданным порогом качества.
После 2–3 раундов без прогресса Claude группирует оставшиеся ошибки train по причинам. Анализ начинается раньше, если ни одна правка не даст измеримого выигрыша. Неоднозначные задания, сбои обвязки и шум требуют исправления оценки; дальнейшая оптимизация работает с подтверждёнными ошибками приложения.
В конце остаётся версия с лучшим результатом test для выбранной цели. Отчёт сравнивает её с baseline и показывает доверительные интервалы. Выигрыш в пределах шума не служит основанием для слияния изменений.
Harness — код вокруг модели: промпты, инструменты и цикл вызовов. Его можно подогнать под особенности бенчмарка так, что балл вырастет без пользы для рабочих задач.
Например, добавление OCR помогает набору с распознаванием текста, но почти бесполезно, если таких задач в эксплуатации мало. Аналогично работают правила для особых путей, формулировок и отдельных сбоев.
Ответы в публичном репозитории, доступные файлы или содержимое провальных примеров внутри промпта дают системе способ обойти саму задачу.
Защита из статьи: отделить train от скрытого test; не копировать содержание провалов в промпт; структурно закрыть доступ к эталонным ответам. Проверка на test помогает обнаружить переобучение, но не устраняет разницу между бенчмарком и рабочим трафиком.
Внутренний бенчмарк содержит 44 обращения: 30 для поиска и 14 скрытых. Сначала убрали обязательные ритуалы вызова инструментов, scratchpad и противоречивые правила, затем меняли модель и effort.
| Конфигурация | Точность | Стоимость токенов / обращение |
|---|---|---|
| Opus 4.8 · high · baseline | 74,4% | 4,6 цента |
| Opus 5.5 · low · после аудита | 87,8% | 1,9 цента |
| Sonnet 5 · low | 88,9% | ≈1 цент |
| Sonnet 5 · правила маршрутизации и возвратов | 98,9% | ≈1 цент |
Финальная конфигурация: примерно пятая часть исходной стоимости.
Часть экономии связана с ценами моделей: автор указывает для Opus 5.5 снижение стоимости входных и выходных токенов на 20%, чтения кеша — на 60% относительно Opus 4.8. Это условия примера из статьи.
В статье ↗Добавили описание восьми недостающих возможностей, затем исправили таблицы типов C# и Java.
Таблица перехода от старых форм API к новым помогла модели использовать инструкции. Затем исправили противоречивые задания и grader вместе с другими частями skill.
После остановки роста анализ обнаружил, что нужные сведения уже были в skill, но модель продолжала писать старые формы API. Подсказки подняли ближе к началу: например, переход от фиксированного бюджета thinking к adaptive thinking. На графике автора — 66,1% в начале и 87,9% к раунду 24.
В статье ↗Практический порядок действий по статье. Отмечайте выполненные шаги.
claude-api skill ↗ — источник команд build-eval и hillclimb, указанный автором.
Train — случаи, по которым ищут улучшения. Test / held-out — скрытые примеры для проверки переноса. Effort — настройка глубины рассуждения. Baseline — исходная конфигурация для сравнения.
В конспекте нет растровых иллюстраций статьи: Firecrawl вернул их адреса, но не файлы или скриншот; браузерный сервис недоступен. Схема процесса составлена для этого конспекта, таблица передаёт числа автора.