Перейти к основному содержимому

Как обрабатывать необработанную цепочку рассуждений в gpt-oss

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

Обработка в шаблоне Harmony / чата

Модель кодирует свою необработанную цепочку рассуждений как часть нашего формата ответа harmony. Если вы создаёте свои собственные шаблоны чата или работаете с токенами напрямую, обязательно сначала ознакомьтесь с руководством по harmony.

Краткое резюме:

  1. CoT будет выведен в канал analysis
  2. После сообщения в канал final в следующем цикле выборки все сообщения в analysis должны быть удалены. Вызовы функций в канал commentary могут оставаться
  3. Если последнее сообщение ассистента было вызовом инструмента любого типа, сообщения анализа до предыдущего сообщения final должны сохраняться в последующей выборке до момента отправки сообщения final

Chat Completions API

Если вы реализуете Chat Completions API, в опубликованных спецификациях OpenAI нет официального стандарта обработки цепочки рассуждений, поскольку наши размещённые модели пока не предоставляют такую функцию. Мы просим вас следовать следующей конвенции от OpenRouter, включая:

  1. Необработанный CoT будет возвращён как часть ответа, если в запросе не указан reasoning: { exclude: true }. См. подробности здесь
  2. Необработанная цепочка рассуждений доступна как свойство reasoning в сообщении вывода
  3. Для событий дельты у дельты есть свойство reasoning
  4. В последующих циклах вы сможете получать предыдущие рассуждения (как reasoning) и обрабатывать их в соответствии с поведением, описанным в разделе про шаблоны чата выше.

В случае сомнений, пожалуйста, придерживайтесь конвенции / поведения реализации OpenRouter.

Responses API

Для Responses API мы расширили спецификацию для этого случая. Ниже приведены изменения спецификации в виде типовых определений. В целом:

  1. Вводим новое свойство content в reasoning. Это позволяет возвращать рассуждения summary, которые могут быть показаны конечному пользователю одновременно с необработанным CoT (который показывать не следует, но он может быть полезен для исследований интерпретируемости).
  2. Вводим новый тип содержимого под названием reasoning_text
  3. Вводим два новых события: response.reasoning_text.delta для потоковой передачи дельт необработанного CoT и response.reasoning_text.done для указания завершения шага цепочки рассуждений
  4. В последующих циклах вы сможете получать предыдущие рассуждения и обрабатывать их согласно поведению, описанному в разделе шаблонов чата выше.

Изменения в типах элементов

<<<FENCE_0>>>

Изменения в событиях

<<<FENCE_1>>>

Пример вывода ответов

<<<FENCE_2>>>

Отображение необработанного CoT конечным пользователям

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