Anthropic engineer: "Most people will use Sonnet 5 and Fable 5 wrong. You can set them up right in one afternoon and stop overpaying every single day."

Сегодня мы будем говорить о выборе правильной модели. Концептуально это кажется очень простым процессом, но чем глубже мы погружаемся в него, тем сложнее становится эта задача. Давайте рассмотрим следующий сценарий: когда Anthropic выпускает новую модель, вокруг этого события традиционно возникает много шума. Вместе с запуском модели мы выпускаем model card (карточку модели), предоставляем руководства по промптингу, публикуем показатели тестирования (бенчмарки) с результатами. Вы также увидите много «горячих» мнений в X (Twitter) — от заявлений, что «AGI уже здесь», до утверждений, что «Anthropic обречены». В интернете появляется множество публикаций, дающих критическую оценку качеству нашей новой модели.

Однако ключевой вопрос для вас заключается в следующем: что это означает для вашего конкретного сценария использования? Что это значит для вашего бизнеса? Стоит ли вам просто интегрировать эту новую модель в ваш продукт, и даст ли это прирост производительности? Или, если вы создаете проект с нуля (Greenfield), какую модель выбрать для старта? Чтобы ответить на эти вопросы, нам необходимо построить повторяемый процесс — что-то, к чему вы сможете возвращаться раз за разом, и что даст вам четкое решение «да» или «нет» относительно выбора новой модели. Другими словами, нам нужно создать eval (систему оценки).

Возвращаясь к исходной задаче: концептуально всё очень просто. Когда вам нужно больше интеллекта, вы выбираете Opus. Когда вам нужна меньшая задержка или более низкая стоимость, вы выбираете Haiku. Когда вы хотите найти баланс между этими двумя факторами, вы можете использовать Sonnet. Но как насчет уровней усилий? Это вносит в проблему немного больше глубины. Стоит ли нам выбирать Sonnet с максимальным «мышлением» (max thinking)? Или, возможно, Opus с низким уровнем «мышления»? Или сравнить Haiku с Sonnet без какого-либо «мышления»? И это касается не только Anthropic. Многие из вас будут сравнивать модели не только из линейки core models (основных моделей), но и от других провайдеров. Поэтому возникает вопрос: как нам структурировать это решение? Я считаю, что существует действительно три «столпа», которые большинство людей принимают во внимание при выборе модели.

При выборе модели для решения задачи следует ориентироваться на три основных критерия, которые лежат в основе оценки. Первый критерий — это качество модели (model quality), которое показывает, насколько эффективно модель справляется с конкретной задачей. Сюда входят такие показатели, как коэффициент завершения задач (task completion rate), точность (accuracy) модели и другие метрики, которые вы можете отслеживать. Второй критерий — это задержка (latency), что становится особенно важным для сценариев использования, ориентированных на конечных клиентов. Третий критерий — это стоимость (cost), которая также является значимым фактором для многих клиентов. Рассматривая выбор через призму этих трёх «столпов» — качества, стоимости и задержки, — можно построить процедуру оценки (eval), которая поможет принять информированное решение о том, какую модель действительно стоит использовать.

Существует три ключевых вывода, которые стоит усвоить. Во-первых, даже небольшая, но грамотно спроектированная процедура оценки (eval) будет значительно полезнее для выбора подходящей модели, чем использование любых существующих публичных бенчмарков. Во-вторых, модель, которая лучше всего подходит для вашего случая использования, — это не обязательно та, что является самой дешевой или быстрой в расчете на один токен, а та, которая является самой дешевой в расчете на успешный результат. Более подробно этот вопрос будет рассмотрен далее в ходе выступления.

В-третьих, существует множество «ручек и переключателей» (knobs and dials), которые можно вращать и настраивать, чтобы перемещаться по границе стоимости и точности (cost-accuracy frontier) с более тонким контролем. Если рассматривать кривую Парето (Pareto curve) производительности модели в соотношении со стоимостью, то при правильном подходе мы можем полностью сместить эту кривую. Существует ряд стратегий, позволяющих это сделать.

При оценке соотношения производительности модели и стоимости мы можем полностью изменить эту кривую. Существует ряд стратегий для достижения этого результата. Однако стоит немного поразмышлять о том, что именно дают нам публичные бенчмарки, а чего они не показывают.

В целом эти бенчмарки предоставляют нам некоторое понимание того, улучшилась ли модель в написании кода или других различных задачах. Поэтому при выпуске наших моделей мы часто включаем результаты тестирования на таких бенчмарках, как SWE-bench verified или BrowseComp (сокращение на слух, по контексту имеется в виду Browsing Evaluation или аналогичный), которые по сути говорят сами за себя: насколько модель в целом хороша в программировании и насколько она хороша в исследовательских задачах.

Тем не менее, ни один из этих тестов, как правило, не соответствует вашему конкретному кейсу использования. Если рассмотреть работу кодинг-агента (coding agent) в продакшене, то ему часто необходимо найти специфическую информацию об SDK в интернете, а затем использовать её для реализации кода. Таким образом, мы уже выходим за рамки одного бенчмарка. Ваши рабочие нагрузки часто выглядят гораздо более гетерогенными, чем предложенные варианты.

Вы можете выполнять задачу по написанию кода, но ваша конкретная задача может сильно отличаться от того, что представлено в SWE-bench. Например, вы можете использовать языки программирования, которые вообще не встречаются в SWE-bench.

Суть в том, что публичные бенчмарки дают лишь общее направление и позволяют составить некоторое представление о том, каковы лучшие модели на текущий момент. Однако для вашей конкретной рабочей нагрузки невероятно важно выстраивать собственные методы оценки (own evals).

Для создания собственных тестов (evals) необходимо построить их структуру, состоящую из множества задач. Задача (task) представляет собой некую атомарную единицу теста, которая включает набор входных данных (inputs) и критерии успеха (success criteria). Таким образом, процесс создания eval заключается в формировании набора данных из таких задач.

Эвристика, помогающая понять структуру тестов, заключается в сравнении их с экзаменом по математике. Как и в школьной задаче, у вас есть вопрос и ответ, который необходимо получить правильно. Однако очень важно продемонстрировать ход решения («показать работу») в процессе. Это особенно актуально для задач, связанных с генерацией текста, где при оценке производительности модели нужно думать об этом именно в таком ключе.

Итоговый набор данных должен содержать вопросы или входные данные для вашей системы. Важно проверять не только то, что агент пришел к правильному конечному результату, но и то, что он предпринял правильные шаги, чтобы достичь его. «Ход решения» (working) так же важен, как и сам результат.

Рассмотрим пример из реальной жизни. Если вы создаете агента для службы поддержки, вы можете разработать eval, где LLM as a judge (языковая модель в роли судьи) проверяет, соответствует ли финальный ответ ожидаемому результату. Но, помимо этого, вы можете привлечь LLM as a judge для проверки того, правильно ли агент обратился к базе данных для поиска сведений о клиенте.

Метод LLM as a judge довольно полезен, так как он обладает определенной гибкостью. Например, если ваш агент пишет SQL-запрос, он может синтаксически немного отличаться, но модель-судья заметит это, и пока извлекаются нужные данные, оценка останется устойчивой к таким различиям.

Помимо этого, можно использовать детерминированные тесты на основе кода (code-based evals). Это нужно для гарантии того, что агент всегда вызывает необходимый инструмент для поиска, например, во внутренних регламентах, или для проверки того, что при выполнении поиска агент добавляет аргумент, локализующий поиск для конкретной страны, в которой находится клиент.

Таким образом, для каждой задачи необходимо создать набор оценщиков (graders). Вам предстоит проделать много сложной работы по формированию таких наборов данных, самостоятельно определяя заранее, что является верным решением, что является верным исходом и какие именно шаги необходимы для его достижения.

Цель создания набора оценочных данных (reference set of evals) — создание основы для принятия более обоснованных, ориентированных на данные решений при выборе подходящей модели. В Anthropic накоплен значительный опыт в разработке таких оценок, и в этом процессе выделяют несколько типичных ошибок и режимов сбоев, на которые стоит обратить внимание.

Первая проблема — это путаница между шумом и сигналом (mistaking noise for signal). Чтобы избежать этого, после того как вы определили и запустили свою оценку, необходимо выполнить её несколько раз на каждой задаче, чтобы убедиться в устойчивости результата. Если наблюдается высокая вариативность в полученных метриках и результатах, это может быть сигналом того, что задача определена не совсем корректно или что ваши оценки не полностью выровнены (not fully aligned).

Вторая проблема — инфраструктурные сбои (infra failures). Иногда вы можете увидеть результаты оценки и заметить, что цифры выглядят странно, например, показатели модели Opus резко снизились. При детальном изучении транскриптов процесса вы можете обнаружить большое количество сбоев API или ошибок вызова инструментов. Важно четко отделять такие случаи от собственно оценки модели: это именно инфраструктурные проблемы, а не проблемы самой модели. Поэтому крайне полезно изучать транскрипты, чтобы определить, где именно произошел сбой: получил ли модель низкий балл на бенчмарке из-за того, что действительно плохо справилась с задачей, или из-за технического сбоя инфраструктуры. Эту работу часто упускают из виду, так как проще запустить оценку, получить результат и принять решение, однако погружение в транскрипты является эффективным использованием времени.

Третья проблема — репрезентативность данных (salient saturation). Самый важный момент здесь — иметь набор данных, который действительно репрезентативен по отношению к тем данным, которые вы увидите в продакшене. Он должен отражать типы вопросов, которые реальные люди могут задавать вашей системе. Эффективно создавать цикл обратной связи, особенно после запуска продукта: собирать логи (traces), смотреть, что пользователи спрашивают у системы, выявлять режимы сбоев, где ваш агент или сценарий использования LLM дает осечку, и возвращать эти примеры обратно в ваш набор для оценки (eval set). Таким образом вы получаете репрезентативную и разнообразную выборку тех типов входных данных, с которыми должна справляться ваша система.

Наконец, стоит учитывать, что каждая модель обладает уникальными нюансами и специфичными особенностями поведения (quirky behavioral changes). При выпуске каждой новой модели компания подготавливает руководство по промптингу (prompting guide), и стоит потратить время на его изучение — или даже загрузить это руководство в Claude и попросить обновить ваши промпты соответствующим образом.

В качестве примера можно привести случай из работы с инструментом внутри Claude AI. С моделью Opus 4.5 этот инструмент недоактивировался (drastically under-triggered), а с версией Opus 4.6 тот же инструмент с тем же самым промптом начал, наоборот, слишком часто активироваться (drastically over-triggered). Вывод из этого заключается в необходимости делать небольшую донастройку (fine-tuning) и корректировать свои промпты в зависимости от используемой модели. Claude неизбежно будет работать немного по-разному в зависимости от вариантов модели, и, очевидно, будет работать иначе, чем GPT, поэтому здесь всегда требуется ручная доводка.

Необходимо регулярно изучать транскрипты того, что делает агент или модель на разных этапах работы системы. Этот процесс следует сделать максимально простым, для чего нужно настроить качественную observability (наблюдаемость). Для этого можно использовать такие платформы, как Langsmith, Braintrust или любые другие существующие аналоги.

При создании агента важно обеспечить полное логирование всех действий: от system prompts (системных промптов) до tool calls (вызовов инструментов), которые делает агент, и результатов, которые он получает обратно. Основная цель заключается в том, чтобы иметь возможность в любой момент провести глубокий анализ и точно увидеть, что именно «видела» модель и как она вела себя в конкретной ситуации. По сути, это основной инструмент для отладки любых возникающих проблем.

В качестве примера можно привести случай, когда проводилась оценка (eval) Claude на одном из бенчмарков по программированию. На первый взгляд казалось, что Claude демонстрирует очень хорошие результаты. Однако при детальном изучении транскриптов выяснилось, что модель обращалась к истории Git, смотрела, что она делала в предыдущих попытках, и извлекала ответ непосредственно оттуда. Если бы внимание было сосредоточено только на ключевых метриках результатов оценки (headline metrics), можно было бы ложно решить, что в работе модели достигнуто значительное улучшение. Только глубокое погружение в транскрипты позволяет увидеть реальные возникающие закономерности и именно те вещи, которые требуют исправления. Следовательно, чем ближе вы работаете с «сырыми» данными (raw data), тем лучше.

Если подвести итог, создание private eval (собственной оценки) исключительно важно для принятия обоснованных решений на основе данных при выборе подходящей модели. Также ранее мы затрагивали аспекты цикла выполнения при непосредственной разработке агентов.

Ранее мы обсуждали процесс создания цикла оценки (eval loop) и некоторые типичные ошибки, возникающие при этом. Теперь стоит подробнее остановиться на инструментах и рычагах, доступных для перемещения по границе производительности, где необходимо искать баланс между стоимостью, качеством или задержкой (latency) и качеством.

Команда начала с использования модели Haiku 3.5 (в транскрипте указано как Haiku 4.5, основываясь на контексте моделей Anthropic и специфике ошибок распознавания, скорее всего, речь о модели Haiku 3.5) без включения функции «мышления» (thinking) и получила результат в 92%, что можно видеть на экране. Команда стремилась достичь показателя 100%, поэтому они активировали функцию «мышления», и это позволило добиться желаемого результата. Это был довольно простой конвейер.

Затем они решили повторно провести оценку, используя модели Sonnet и Opus. Как видно на экране, обе модели также достигли показателя 100%, однако, что парадоксально, потребовали гораздо меньше времени на выполнение задачи. Мы не были сильно ограничены в бюджете на эту задачу, мы просто хотели, чтобы она выполнялась как можно быстрее.

Ситуация весьма интересная. На первый взгляд кажется, что модель Haiku должна быть значительно быстрее, но на самом деле более «интеллектуальные» модели могут быть намного эффективнее с точки зрения времени. Это происходит потому, что они способны выполнять действия за меньшее количество шагов (terms). Они могут эффективнее планировать свои действия стратегически, и им не требуется тратить так много времени на исследования, чтобы подтвердить правильность того, что они собираются сделать.

Исходя из этого опыта, мы можем начать экспериментировать с настройками, включая режим «мышления» и уровни усилий, чтобы по-настоящему извлечь максимум ценности для нашего конкретного случая использования.

Стоит подробнее разобраться, что представляют собой эти параметры управления, поскольку над ними проводилось много экспериментов. Существуют разные типы мышления и разные типы усилий. Начиная с класса моделей Sonnet 4.6 и далее, в работу внедрено Adaptive thinking — адаптивное мышление. В этом режиме сама модель определяет, сколько именно ей необходимо размышлять над поставленной задачей. По сути, это работает как Scratchpad: модель «думает» перед тем, как приступить к выполнению работы. Это классический пример System 2 thinking (мышления второго типа), требующего более глубокого анализа.

Помимо мышления, существует параметр Effort (усилия). Он определяет, какой объём работы должен проделать Claude, учитывая все компоненты: процесс мышления, вызов инструментов и финальные ответы. Параметры можно комбинировать гибко: например, можно установить низкий уровень мышления при высоком уровне усилий. Или вовсе отключить мышление, но при этом использовать параметры усилий. Effort по своей сути задаёт Claude объем работы или степень усердия, которую он должен приложить к выполнению задачи. В то время как Thinking предоставляет модели «черновик» (scratchpad), чтобы обдумать задачу перед началом действий. Используя эти две настройки как «регуляторы», можно получить довольно точный контроль над положением на кривой соотношения точности и стоимости (accuracy-cost curve).

Ещё один пример, демонстрирующий контринтуитивный момент, связан с моделью Opus 4.5. На графике она обозначена оранжевой линией. Эта модель способна выполнять задачи с уровнем точности выше, чем Sonnet, при этом используя значительно меньшее количество выходных токенов (tokens). Если бы вы руководствовались лишь интуицией, что «меньшая модель работает быстрее», вы бы, вероятно, не выбрали Opus, зная, что, по факту, Opus может завершать задачи быстрее и с меньшим числом токенов.

На этом же графике можно заметить разброс параметров Opus между различными уровнями усилий. Это позволяет эффективно балансировать: оптимизировать ли работу под меньшее количество выходных токенов или под более высокую точность. Если вам нужна более высокая точность, можно выбрать более высокие уровни Effort; если же приоритетна меньшая задержка (latency), можно выбрать более низкие уровни усилий. Таким образом, параметр Effort позволяет получить гораздо больше контроля, чем простой выбор одной модели из линейки.

Существует возможность не просто перемещаться по уже существующей кривой, а сдвинуть саму границу эффективности, и для этого существует пара «хаков».

Первый из таких способов — это prompt caching (кэширование промптов).

Prompt Caching — это стратегия, которая позволяет существенно снизить затраты на работу с моделями. Суть метода заключается в том, что когда вы используете префикс промпта, который уже был сохранен, предварительно вычислен и закэширован, стоимость входных токенов снижается до одной десятой от стандартной цены.

Благодаря этому можно получать качество модели Opus по цене Sonnet, или качество Sonnet по цене Haiku. Это одна из самых эффективных стратегий, активно используемая в продуктах компании (например, в Cloud Code и Co-work).

Для измерения эффективности этой стратегии существует понятие prompt cache hit rate (частота попаданий в кэш промптов). Ориентиром для лучших ИИ-систем и приложений на сегодняшний день являются показатели hit rate на уровне 80–90%. К таким цифрам стоит стремиться.

Использование Prompt Caching открывает принципиально новые возможности для разработчиков:

1. Становятся доступными сценарии использования, которые ранее были слишком дорогими (например, использование модели Opus при ограниченном бюджете).
2. За счет значительной экономии высвобождаются бюджеты на новые типы задач.

В API и SDK компании возвращаются метрики токенов, включающие не только показатели «сырых» потребленных токенов, но и данные по токенам из prompt cache на входе. Это сделано для того, чтобы разработчикам было максимально просто измерять prompt cache hit rate. Рекомендуется постоянно отслеживать этот показатель, оптимизировать систему (hill climb) и стараться удерживать его на максимально высоком уровне.

Стратегия «Append-only» (только добавление)

Для тех, кто занимается созданием агентов, существует простая и эффективная стратегия работы с кэшированием — подход append-only. Рекомендуется избегать большого количества динамических переменных в системном промпте. Самая распространенная ошибка, приводящая к поломке кэша, — это вставка переменной даты или времени (date time variable) в системный промпт. При таком подходе с каждым новым шагом взаимодействия время меняется, что каждый раз делает кэш невалидным.

Эффективный подход заключается в том, чтобы рассматривать массив сообщений (messages array), отправляемый в API, как immutable (неизменяемый). Как только базовая часть промпта (контекст) определена, к массиву сообщений следует только добавлять новые элементы, не меняя предыдущие. Это самый надежный способ гарантировать, что кэш не будет сброшен.

Важно отметить, что Тарек (Tarek), один из ведущих инженеров команды Cloud Code, подробно писал о том, как реализовать этот подход. Стоит изучить материалы, опубликованные им, о том, как данная стратегия применялась в Cloud Code.

Люди тратят слишком много времени на размышления о сверхсложных мультиагентных системах оркестрации и недостаточно времени на простые вещи, которые действительно работают — хорошую гигиену контекста (context hygiene) и инженерию контекста (context engineering). Если мы можем улучшить эффективность токенов (token efficiency) в ответах наших инструментов, мы можем сэкономить большое количество токенов, которые подаем в модель, тем самым сокращая расходы и улучшая латентность (latency). Существует также вторичный эффект: благодаря тому, что мы предоставляем Claude более чистые и эффективные данные, ответы модели, как правило, становятся лучше и точнее.

В качестве примера рассмотрим инструмент, возвращающий спортивные данные, например, результаты матчей Премьер-лиги. Есть несколько изменений, которые мы можем сделать в этом случае. Во-первых, стоит использовать markdown вместо JSON. Во-вторых, вместо длинных и неэффективных отметок времени нужно использовать очень простую отметку даты. Также мы добавляем день недели, чтобы Claude понимал суть гораздо проще, вместо того чтобы тратить «мыслительные ресурсы» на анализ того, на какой день недели приходится каждая игра. Просто очистив этот ответ, мы получаем сокращение количества токенов в ответе инструмента на 66,4%. Эти показатели суммируются каждый раз, ведь если у вас есть агент, выполняющий несколько шагов, ваш ответ инструмента появляется не один раз, а на каждом этапе диалога. Такие маленькие вещи, связанные с гигиеной данных, действительно оказывают огромное влияние.

Я работал и над другими примерами. Например, в одном кейсе с веб-поиском мы эффективно дедуплицировали статьи, полученные из одного и того же поиска или даже из разных поисковых запросов. Этот прием — взятие статей и их дедупликация перед тем, как они будут возвращены в Claude, — привел к сокращению количества входных токенов, которые получал Claude, на 77%, к снижению затрат на 65%, а точность Claude фактически выросла на 9%, потому что модели приходится рассуждать (reasoning) над меньшим объемом данных. Эти метрики могут звучать так, будто они взяты с потолка, но мы можем измерить их, потому что изначально создали evals (системы оценки). Это дает колоссальные возможности: если вы можете сэкономить 65% бюджета, просто занимаясь хорошей инженерией контекста, это открывает возможность использовать более интеллектуальную модель или запускать совершенно новые сценарии использования в рамках вашего бюджета.

Я призываю вас не просто брать ответ API и пропускать его через свой инструмент обратно в модель. Поскольку многие инструменты являются «обертками» над API, будьте немного более вдумчивы. Очищайте тот JSON-ответ, который получаете от API, прежде чем передавать его обратно в Claude. Подобно общению с человеком, сделайте это настолько простым и легким для чтения, насколько возможно. Поступая так, вы сократите количество токенов, предоставляемых Claude, и в то же время добьетесь вторичного эффекта — повышения точности во многих используемых вами сценариях.

Перед переходом к воркшопу следует выделить три главных вывода, которые необходимо усвоить.

Во-первых, небольшая и хорошо спроектированная система оценки (eval) даст вам гораздо больше информации о том, какую модель следует использовать, чем любой существующий публичный бенчмарк. Поэтому стоит потратить время на инвестиции в создание такой оценки.

Во-вторых, правильная модель — это не та, которая является самой дешёвой в пересчёте на токен. Правильная модель — это та, которая является самой дешёвой в пересчёте на успешный результат. Как только вы создадите свою систему оценки, вы сможете эффективно запускать её с использованием множества различных моделей и конфигураций, увидеть границу Парето (Pareto frontier) и на основе этого сделать выбор, где именно на этой кривой вы хотите находиться.

В-третьих, используйте доступные «рычаги управления» (dials): effort (усилия), thinking (мышление), prompt caching (кэширование промптов) и context engineering (инженерия контекста). Это позволит вам получить гораздо более тонкий контроль над тем, где вы хотите оказаться на этой границе Парето, или даже позволит полностью сместить саму границу.

Если вы сможете выполнить эти три действия, вы окажетесь в довольно выгодном положении при выборе подходящей модели для вашего сценария использования. Это поможет вам даже открыть новые варианты применения технологий, получив доступ к более высокому уровню интеллекта модели при меньших затратах.

Для выполнения практического задания необходимо перейти по ссылке cwc26.short.gy/workshops, где находятся все необходимые материалы.

В рамках этого семинара мы будем работать с инструментом, который был подготовлен специально для аудита существующих оценок (evals). Этот инструмент выполняет комплексное сканирование настроенной вами оценки и инструментирует её таким образом, чтобы она запускалась по нескольким направлениям: с использованием различных моделей, с включенным или выключенным режимом «мышления» (thinking) и с применением разных уровней усилий (effort levels). Полученные результаты система автоматически собирает, строит по ним графики и сохраняет в удобном формате. Это дает возможность увидеть эффективность (performance) вашей оценки в разрезе разных моделей, уровней мышления и уровней усилий.

В данном случае в качестве примера мы используем TauBench — бенчмарк, ориентированный на сценарии использования агентов в сфере клиентской поддержки. Мы будем фокусироваться на авиационном сегменте TauBench.

В файле README данного семинара вы найдете инструкции, которые разбиты на несколько этапов:

1. Загрузка и настройка: Инструкции по скачиванию и установке TauBench. Вы можете скопировать соответствующий промпт и передать его модели Claude — она выполнит настройку за вас.
2. Инструментарий: Запуск навыка (skill), который выполняет инструментирование кода для последующего автоматического прогона оценки по разным моделям, уровням мышления и уровням усилий.
3. Запуск оценки: Непосредственно исполнение самой оценки (eval).

Сейчас мы попросим Claude выполнить эти действия. Лектор уточняет у аудитории, хорошо ли виден экран или необходимо масштабировать изображение, после чего подтверждает, что Claude успешно загрузил навык. Далее мы перейдем непосредственно к результатам.

Были проведены тесты для трёх моделей: Haiku, Opus 4.7 и Sonnet 4.6. Исследование охватывало различные конфигурации, включая включение и выключение функции «мышления» (thinking on/off) и использование настроек effort levels (уровней усилий). Результаты оказались весьма неожиданными.

В первом анализируемом графике отображается pass rate (коэффициент прохождения задач) в зависимости от среднего количества output tokens (выходных токенов) на задачу. Как и ожидалось, модель Opus 4.7 с включенным «мышлением» и высоким уровнем усилий (high effort) показала самый высокий pass rate. Однако неожиданным стало то, что она достигла этого результата, используя меньшее количество токенов, чем Sonnet для аналогичного сценария использования.

Переходя ко второму графику, мы видим, что, хотя Opus с настройкой high effort показал наилучшую производительность, он также является самым дорогим. Таким образом, если приоритетом является чисто pass rate, следует выбирать Opus с активным «мышлением». Однако логика меняется при необходимости оптимизации затрат: результаты показывают, что Haiku с включенным «мышлением» способна выполнять задачи с эффективностью, сопоставимой с Sonnet при активном «мышлении» и высоком уровне усилий.

На финальном графике наблюдается схожая, но очень интересная закономерность касательно задержки (latency). Модель Opus с высоким уровнем усилий и включенным «мышлением» работала быстрее, обеспечивая меньшую задержку, чем Sonnet при аналогичном уровне «мышления».

Эти графики в совокупности предоставляют данные для принятия обоснованных решений при выборе модели и конфигурации. Они позволяют выявить неочевидные свойства моделей на разных уровнях «мышления» и сделать выбор, взвешивая критерии, которые наиболее важны для конкретной задачи: задержка, стоимость или качество модели.

Для выбора наиболее подходящей модели необходимо в первую очередь создать eval (систему оценки) для конкретного сценария использования. Команда Anthropic и специалисты по Applied AI готовы оказать помощь в разработке таких инструментов оценки.

Вторым ключевым выводом является необходимость оптимизации под параметры, которые наиболее важны для вашего конкретного кейса. После того как вы построили систему оценки и начали принимать решения, опираясь на данные, вы можете сделать выбор в пользу приоритетных критериев: оптимизировать модель под intelligence (интеллектуальные способности), latency (задержку) или cost (стоимость).

Третий важный момент заключается в том, что вы можете радикально изменить кривую производительности при помощи context engineering. Используя такие стратегии, как prompt caching, вы получаете возможность выжать из модели гораздо больше эффективности.