Chat Completions API vs Response API

Почти год прошел с появления нового программного интерфейса Response API от Open AI, который должен был вытеснить Chat Completions API, но воз, похоже, и ныне там. Если вы встраивали LLM-сервисы в свои приложения, то наверняка заметили, что про их APIs принято говорить только хорошее. Огромное количество позитивных новостей встречает появление нового или улучшение существующего программного интерфейса. Мало кто осмелится усомниться в их конструкции. Наверное, похожий трепет вызывали первые радиоприемники, приземляющие сигнал из эфира в кухни и комнаты обывателей. Адептов даже не смущают откровения разработчиков о том, что некоторый API, а именно, тот самый Chat Completions API — де-факто текущий стандарт для взаимодействия с LLM-ами, был разработан практически «за выходные» (твит см. ниже, подробности здесь: https://x.com/athyuttamre/status/1899541471532867821). Кстати, появление этого “откровения” и было приурочено к выходу год назад другого интерфейса, названного Response API. Об этих двух APIs и пойдет речь сегодня.

Появление Response API сопровождалось некоторым ажиотажем. Вероятно, OpenAI поскорей хотелось закрыть страницу с Assistant API. С его версией v1, да и с v2 что-то пошло не так. В конечном счете выяснилось, что это вообще было бета-тестирование (см. Assistants API beta deprecation — August 26, 2026 sunset). В общем нужен был новый хороший и правильный API и он появился. Скопирую основные заголовки из статьи в оригинальной документации Migrate to the Responses API:

Responses benefits: Better performance, Agentic by default, Lower costs, Stateful context, Flexible inputs, Encrypted reasoning, Future-proof…

Наверно, все это надо было написать CAPS-ом. Дальше там еще несколько фич в разделе Additional differences, но давайте сосредоточимся на главном. Сравнивая Response API с предшественниками, я бы так расставил приоритеты:

  1. Вызов инструментов сервером (Assistant API тоже вызывал инструменты, но только встроенные)
  2. Сохранение состояния (на самом деле, истории диалога) на стороне сервера.
  3. Управление глубиной рассуждений (reasoning effort)

C reasoning все и началось. Вообще говоря, само появление рассуждений – это очень круто. Напомню, как развивались события. Все началось с работа Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. К середине 2024 года это воплотилось в модель o1 preview, а в дальнейшем и o1, которые катастрофически лучше решали задачки по математики и писали код. См. Learning to reason with LLMs и красноречивый графики их этой статьи

Однако провайдеры моделей не любят делиться рассуждениями. Собственно их шифрование и стало первым вопросом к новому API от OpenAI. См., например, заметку инженера из Австралии Sean Goedecke The whole point of OpenAI’s Responses API is to help them hide reasoning traces

Следующая серия вопросов касалась производительности. См., например Responses API much slower than Chat Completions или Response Api slower than Chat Completion

Но безусловно, главный вопрос был в контроле за оркестровкой. Пожалуй, вот эта реплика проливает свет на существо конфликта Why OpenAI’s Agent Dev Hub Won’t Kill Custom Automation. С одной стороны хранение истории диалога на сервер конечно удобно (я не стану сейчас обсуждать архитектурные особенности реализации этого. В конечном счете для пользователь использующих веб-приложение Open AI все равно это приходится реализовывать). С другой стороны на сторону провайдера следом уезжает множество вопросов касающиеся организации краткосрочной памяти, формирования контекста вызова инструментов, оценки результатов, повторных запросов, параллельного выполнения и в конечном счете выбора подходящих моделей для конкретного шага. По сути, речь идет о том, чтоб отдать Open AI весь касающийся агентов функционал.

Похоже к такому шагу отрасль совсем не готова. Казалось, к 2025 году сложился некоторый паритет между теми, кто строит гигантские датаценты и обучает модели и простыми смертными, которые обогащают запросы актуальными данными через RAG, отлавливают галлюцинации и вообще, адаптируют ИИ к конкретным потребностям конечного пользователя. Нет каких-то других стимулов тащить LLM-ки в корпоративные ландшафты или выстраивать поверх них собственные SaaS сервисы. Но у ИИ-гигантов вероятно другой взгляд на будущее. И в него, кстати, встраиваются все остальные истории. Ну, например, добрую половину прошлого года все кому не лень обсуждали Model Context Protocol aka MCP (странные API, умеют придумывать не только в Open AI). Казалось бы, ну зачем такое нужно. Если мы передаем LLM-ке описание инструмента и получаем от неё команду этот инструмент вызвать, то справимся мы как-нибудь и непосредственно с вызовом инструмента. Но вот если вызов инструмента производится с другой стороны API, то без такого стандарта уже не обойтись. Или другой пример. Помните, как в середине прошлого года консультанты дружно принялись журить корпорации за то, что те не могут продемонстрировать ценность применения ИИ в бизнесе. Пилотов много, пользы – практически нет. Напрашивается очевидный вывод – видимо корпоративные айтишники и их системные интеграторы просто не справляются. То ли не тех агентов пишут, то ли не так. Но как-то и эта история желания размещать агентов со стороны LLM корпорациям не прибавила. Впрочем, наверняка я не знаю. Статистики использования конкретных API я не нашел ни у Open AI, ни у других. (есть только один твит про 70%)

Косвенным свидетельством того, что Response API продвигается не столь быстро, как того кому-то хотелось бы, является появление уже в 2026 году спецификации и сообщества Open Responses (см. заметку на НuggingFace Open Responses: What you need to know)

Теперь то мы точно захотим перевести своих агентов в облако. Вот и уважаемые издания типа TheNewStack об этом пишут Open Responses vs. Chat Completion: A new era for AI apps

The introduction of Open Responses marks the end of the “Chatbot Era” and the beginning of the “Agentic Era.” For too long, developers have struggled with the “Square Peg, Round Hole” problem of forcing autonomous behaviors into conversational APIs. The resulting “Agentic Hell” of brittle, high-latency, client-side loops held back the true potential of AI

и далее:

For the enterprise, the path is clear: Adopt the standard to future-proof applications against vendor lock-in and enable hybrid-cloud deployments…

Но чем громче звучат лозунги, тем больше настороженности они вызывают. Возможно, со временем большинство клиентов и переедет на Response API. (А в MCP уж точно все инструменты обернут, и в agent skills их опишут.) Но вот в том, что агентов разработчики отдадут на сторону Open AI я, честно говоря, сомневаюсь

А вы какой API используете?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *