Список из эндпоинта models даёт только имена доступных вариантов, а выбор модели OpenAI для рабочего сервиса делает одинаковый набор ваших запросов, прогнанный через каждого кандидата. Платформа предлагает много моделей, и разница между ними заметна на конкретных вопросах компании, а в общих рейтингах она размывается. Для разового эксперимента хватит любой доступной модели, а модель для постоянного сервиса без такого набора выбирается наугад.
Что даёт список
Эндпоинт GET /models возвращает идентификаторы доступных моделей и служебные поля, а размер контекста и возможности модели читают на её странице в документации.
Запрос списка выглядит как обычный вызов с ключом проекта в заголовке Authorization. По справочнику OpenAI, в ответе приходит массив data, и у каждой модели есть идентификатор id, значение object, время создания created, владелец owned_by и необязательная дата shutdown_date. Размера контекста и перечня возможностей в этом списке полей нет.
Отсюда два практических вывода. Первый: список показывает доступные модели в момент запроса, и это точнее любого пересказа из статей. Второй: поле с датой отключения полезно как сигнал для мониторинга. Если у модели, на которой работает сервис, появилась такая дата, у команды есть время подготовить замену, и сравнивать кандидатов придётся на том же наборе запросов, который описан ниже.
Представьте отдел закупок с внутренним помощником, который отвечает на вопросы о регламенте согласования договоров. Ответ строится по выдержке из регламента, которую подставляет сервис, а модель формулирует понятный текст. Вопрос выбора здесь звучит узко: какая модель аккуратнее всех держится выдержки. Про получение ключа и доступ к проекту рассказано в статье про выдачу ключа и управление доступом.
Тестовый набор
Набор строят из реальных вопросов, и придумывать их в расчёте на хорошие ответы незачем. Для помощника закупок достаточно тридцати формулировок, собранных из обращений сотрудников и очищенных от личных данных. Часть вопросов типовая, часть пограничная: ответа в выдержке нет, регламент противоречит сам себе, вопрос задан на сленге, просьба выходит за полномочия помощника.
Для каждого вопроса автор набора записывает эталон: какие факты должны прозвучать, какие утверждения запрещены, в каком случае помощник обязан отказаться и отправить к специалисту. Эталон пишет человек, знающий регламент, и языковую модель к этой работе привлекать нельзя: иначе проверка превращается в самопроверку. Версию набора храните рядом с кодом и меняйте с записью причины.
Критерии оценки заранее разнесите по пунктам: точность фактов, соблюдение границ, читаемость русского текста, формат ответа. Каждый пункт оценивается по короткой шкале, а итог по вопросу получается из пунктов, и один ответ читают двое сотрудников, чтобы выявить расхождения в оценке. Общий приём описывает термин оценка моделей.
Качество и задержка
Каждого кандидата прогоняют через набор одинаковым способом: одна инструкция, одни входные данные, одни настройки генерации. Меняется единственная переменная — идентификатор модели. Результаты складывают в одну таблицу, чтобы решение было видно целиком.
| Кандидат | Верные факты | Соблюдение границ | Задержка p95 | Замечания рецензента |
|---|---|---|---|---|
| Модель A | доля ответов с верными фактами | доля корректных отказов | замер на наборе | типовые ошибки |
| Модель B | доля ответов с верными фактами | доля корректных отказов | замер на наборе | типовые ошибки |
| Модель C | доля ответов с верными фактами | доля корректных отказов | замер на наборе | типовые ошибки |
Колонки заполняются вашими замерами, и готовых чисел в таблице умышленно нет: они зависят от длины выдержек, нагрузки и времени суток. Задержку фиксируйте по хвосту распределения, потому что сотрудник запоминает самые медленные ответы и забывает средние. Подробнее о показателе рассказывает термин задержка p95.
Прогоняйте набор минимум дважды на каждого кандидата: ответы модели варьируются, и расхождение между двумя прогонами одного и того же вопроса говорит о стабильности столько же, сколько средняя оценка. Модель, которая то отказывается отвечать, то уверенно отвечает на тот же вопрос, для регламента опаснее честного середняка.
Стоимость сравнивайте после качества. Цена за токены публикуется на странице цен вендора и меняется, поэтому в таблицу записывайте количество токенов на вход и выход по каждому прогону, а пересчёт делайте по актуальному прайсу в день решения. Если разница в качестве мала, тогда и только тогда выбирайте по цене и задержке.
Контекст и параметры
Допустимая длина входа и выхода берётся из документации выбранной модели и проверяется в вашем сценарии. Выдержка из регламента иногда вырастает вдвое, когда в неё попадают приложения; тогда решает размер контекста, а общее качество отходит на второй план. Для вывода есть отдельный потолок, который задаётся параметром max_tokens или его аналогом в выбранном интерфейсе; смысл параметра объясняет термин лимит токенов.
Совместимость параметров проверяйте вызовом, чтение примеров тут слабая опора. Модели могут принимать разные настройки, и сервис, привыкший передавать один и тот же набор, при смене модели может получить отказ по параметру. Ниже порядок проверки, который укладывается в один рабочий прогон.
- Возьмите тот набор параметров, который сервис отправляет сегодня, и выполните по одному вызову на каждого кандидата с короткой фразой.
- Сохраните коды ответов и тексты ошибок. Отказ по параметру — сигнал убрать или заменить настройку для этой модели.
- Повторите вызов с самой длинной выдержкой из набора и убедитесь, что вход и выход помещаются в контекст.
- Проверьте формат ответа, если сервис ждёт JSON: разбирается ли результат вашим кодом без ручных правок.
- Запишите итог по каждой модели в одну строку: принимает параметры, влезает по длине, формат сохраняется.
Отдельный пункт — интерфейс вызова. Если вы работаете через Responses API, детали собраны в статье про вызов под один бизнес-сценарий, и тестовый набор остаётся тем же, меняется лишь клиент, а сами запросы переходят из прогона в прогон без правок. Значит, набор можно собирать уже сегодня, до выбора интерфейса.
Какие запросы вашего сервиса станут основой тестового набора?
Выбор и пересмотр
Решение о модели записывается как короткий документ: версия набора, перечень кандидатов, результаты по критериям, выбранный идентификатор, условия пересмотра. Выбор закрепляется в конфигурации сервиса, а название модели хранится в единственной настройке. Тогда замена сводится к смене одной настройки и повторному прогону набора.
Пересмотр происходит по событиям: у используемой модели появилась дата отключения, изменился регламент, выросла доля плохих ответов в журнале, вышла новая модель, которую хочется проверить. Каждый раз команда запускает тот же набор и сравнивает новые результаты со старыми. Так выбор остаётся управляемым процессом и перестаёт зависеть от чужих советов.
Храните рядом с решением и сырые ответы всех кандидатов: через месяц понадобится понять, почему вариант B отклонили, и пересказ памяти окажется хуже файла. Файл с ответами лежит в закрытом хранилище, доступном владельцу процесса и разработчику, поскольку в выдержках из регламента бывают внутренние условия компании.
Заранее решите, кто принимает итог выбора. Обычно это владелец процесса закупок вместе с разработчиком сервиса: первый оценивает смысл ответов, второй отвечает за технические пределы. Подобный подход к тестовому набору описан и для кода в материале про выбор моделей в Claude Code. Когда выбирать модель нужно сразу для нескольких сервисов, подход к такой работе описан на странице про внедрение ИИ в рабочие сервисы.
Прежде чем открывать документацию моделей, напишите эталоны к пятнадцати вопросам, ответ на которые вам известен, и добавьте пять провокационных, где помощник обязан отказаться. Эталон, подогнанный под уже полученные ответы, обесценивает весь прогон. Первой метрикой станет доля ответов без выдуманных фактов.