Почему одинаковый промпт даёт разные ответы: тест top-p
Как проверить разброс ответов на один промпт: совместимость top-p, фиксированный вход, повторные прогоны и оценка ошибок отдельно от разнообразия текста.
Два ответа на один запрос могут различаться без ухудшения качества. Модель переставила предложения, но сохранила факты. Бывает и обратное: текст почти одинаковый, а в одном варианте появилась выдуманная цена. Для проверки повторяемости сначала нужно решить, какое различие действительно мешает работе.
Параметр top-p связан с выбором вероятных продолжений при генерации. Он не является универсальной ручкой «точности». Ниже — протокол проверки, который можно повторить на совместимой модели. Запусков в этой статье нет: таблицы показывают устройство эксперимента и условную оценку ответов.
Не начинайте с ползунка
Откройте документацию именно выбранного API и версии модели. В проверенном 23 октября 2026 года справочнике Claude Create a Message для API version 2026-10-21 параметры top_p и temperature не перечислены в сигнатуре запроса. Старый пример с такими настройками нельзя переносить на эту версию. Для другой версии отдельно подтвердите поддержку и допустимые значения; отсутствие настройки не мешает проверить повторяемость самого результата.
Из этого следуют две ветви. Если параметр поддерживается и меняет поведение выбранной модели, можно сравнить его значения. Если он отклоняется или принимается только для совместимости, тестировать нужно повторяемость при фиксированных настройках. Называть такой прогон экспериментом с top-p было бы неверно.
В приложении с чатовым интерфейсом часть настроек может быть скрыта. В таком случае фиксируйте доступную версию и условия, но не утверждайте, что управляли серверным параметром. История диалога, подключённый поиск и содержимое файлов тоже входят во входные данные.
Одна задача и понятный критерий
Для первого теста я бы выбрал ограниченную операцию: классификацию обращений, извлечение реквизитов из текста или короткую сводку заданного документа. Свободный рекламный текст сложнее оценивать: два разных заголовка не дают готового ответа, какой лучше.
Подготовьте, например, 12 учебных обращений: простые, неоднозначные и с недостающей информацией. Для каждого заранее задайте допустимое решение и признаки ошибки. Это выбранный размер тренировочного набора, не статистический норматив. В руководстве Anthropic и Google Cloud оценка привязана к критериям успеха, пограничным случаям и отдельным данным для проверки.
Вот один готовый учебный вход: «Платёж отклонён банком, товар ещё не отправлен». Доверенная задача: выбрать одну категорию из «оплата», «доставка», «неясно» и коротко назвать основание; не добавлять цену и срок доставки. Эталон — «оплата». «Доставка» считается ошибкой, даже если объяснение звучит убедительно. Для входа «Нужна помощь с заказом» эталон — «неясно»: данных для более точного выбора нет. Сохраните эти входы дословно и дополните набор другими случаями до начала сравнения.
Инструкцию удобно собрать по правилам промпт-инжиниринга, но после начала сравнения её нельзя незаметно улучшать. Иначе результат смешает влияние параметра с влиянием нового текста.
Протокол, который сохраняет сравнимость
- Запишите модель, её точный идентификатор, дату, системную инструкцию, входные файлы и формат ответа. Уберите изменяющиеся внешние источники либо сохраните их снимок.
- Выберите два допустимых значения top-p. Остальные параметры оставьте одинаковыми, если API разрешает такое сочетание. Укажите лимит ответа и поведение инструментов.
- Для каждого из 12 входов выполните по пять независимых повторов на каждую конфигурацию. Это 12 × 5 × 2 = 120 запросов; стоимость и доступный лимит оцените до запуска. Если параметр недоступен, оставьте одну фиксированную конфигурацию: 12 × 5 = 60 запросов, без сравнения значений top-p.
- Чередуйте конфигурации во времени. Сохраняйте каждый ответ, включая ошибки API и обрезанные результаты, а не только понравившиеся варианты.
- Оцените ответы по одному правилу. По возможности скрывайте от проверяющего название конфигурации до выставления оценки.
Идентификатор строки журнала должен связывать вход, конфигурацию и номер повтора. Сохраните также статус завершения и длительность. Повтор после ошибки остаётся новой попыткой; не подменяйте им исходную неудачу.
| Ответ на один учебный вход | Форма | Смысл | Решение |
|---|---|---|---|
| Категория «оплата», краткое объяснение | Ожидаемая | Совпадает с эталоном | Проходит |
| Та же категория, другое объяснение | Отличается текст | Совпадает с эталоном | Проходит; отмечаем вариативность |
| Категория «доставка» при вопросе об оплате | Ожидаемая | Ошибка категории | Не проходит |
| Цена, которой не было во входе | Ожидаемая | Неподтверждённый факт | Не проходит |
Что считать после прогона
Отдельно покажите долю ответов, прошедших критерии, число входов с нестабильным решением и виды ошибок. Если на одном обращении пять повторов дали разные категории, средняя оценка по всем обращениям может скрыть этот участок. Для генерации текста добавьте редакционную оценку, но не смешивайте её с фактической точностью.
Небольшая серия помогает найти поломку; она не доказывает превосходство конфигурации на любых задачах. Перед заменой рабочих настроек проверьте победителя на отложенных входах, которые не использовались при выборе. Для AI-агента важен и следующий шаг: даже хороший текст может оказаться непригодным для автоматического действия.
Закончите эксперимент коротким решением: какую настройку сохраняете, по каким критериям и какие ошибки остались. Если различаются только формулировки, возможно, менять параметр вообще не требуется. Если модель выдумывает отсутствующие сведения, сначала исправляйте задачу и проверку результата.