Decisions API, детекторы галлюцинаций и память агента: AI решает, человек подтверждает

OpenAI вывел в общий доступ Decisions API: быстрые ответы на вопросы с ограниченным набором вариантов, да или нет, один из списка, оценка по шкале. IBM собрала такие же решения вместе с чатом и распознаванием речи в одну модель, а n8n за два дня выпустил три разбора о том, как ловить выдумки модели и где хранить её память. Для владельца бизнеса это один вопрос: какие решения можно доверить модели, а какие должен подтвердить сотрудник.

Что вышло

OpenAI 22 октября объявил о выходе Decisions API из беты. Разработчик задаёт вопрос и допустимые ответы, передаёт текст, картинку или JSON и получает один из трёх типов ответа: вероятность от 0 до 1, выбор из списка с уверенностью или оценку по шкале. OpenAI пишет, что ответ приходит до 10 раз быстрее, чем у той же модели GPT-6 Luna через обычный Responses API. Box классифицирует документы и направляет их дальше: на 30 страховых сертификатах маршрут выбирался примерно в 5 раз быстрее при той же точности, а документы с низкой уверенностью уходят на проверку людям. Sierra выбирает следующее действие в живом разговоре с клиентом меньше чем за 280 мс и платит за вызов на 90 % меньше.

IBM 15 октября в блоге Hugging Face показала Granite Switch 4.1 на 8B и 30B параметров. Идея другая. Вместо отдельного сервиса адаптеры поверх одной базовой модели: адаптер решений, адаптер Guardian для проверки на вред и встроенная речевая модель Turbo CTC занимают на GPU примерно столько же памяти, сколько база без них. Адаптеры делят KV-кэш, поэтому решение после ответа модели стоит почти ничего. Для тех, кто держит модель у себя, это прямой ответ на Decisions API.

n8n 22 октября разобрал методы обнаружения галлюцинаций в агентных процессах. Там четыре типа ошибок: выдуманный факт, ответ не по переданному контексту, додуманные детали и противоречие самому себе. И пять способов их ловить, от проверки опоры на контекст до порогов уверенности с передачей человеку. Главная фраза для меня: порог должен отражать цену ошибки. Внутренняя сводка переживёт неточность, а изменение записи клиента нет.

В тот же день n8n сравнил stateful и stateless подход в агентах: модель сама ничего не помнит между запросами, поэтому состояние живёт снаружи, в базе или кэше, а обработчики запросов остаются без состояния. На следующий день, 23 октября, вышел гостевой разбор памяти агентов от Велько Ковача из Cognee: кратковременная память в текущей сессии, долговременная в отдельном хранилище. RAG читает и не записывает обратно; память агента начинается там, где агент пишет.

Зачем это бизнесу

Возьмём прокат автомобилей. В почту приходит письмо с фотографией и текстом «вот машина после поездки». Первые решения мелкие: это возврат, жалоба или вопрос об оплате; есть ли на фото видимое повреждение; насколько оно серьёзное по шкале от царапины до вмятины. Для таких вопросов Decisions API и подобные модели и сделаны: ответ дешёвый и быстрый, его можно сразу положить в поле заявки. Но следующее решение, списывать ли с депозита клиента, стоит денег и отношений. Его подтверждает сотрудник. Модель готовит заявку, человек нажимает кнопку.

Отсюда вывод: разделите решения по цене ошибки. Классификация и маршрутизация идут автоматически с порогом уверенности. Всё, что меняет деньги, договор или запись клиента, идёт через подтверждение.

Как это устроено у меня

В парсерах документов для PDR-компании в США я к этому пришёл на практике. Они читают страховые сметы, акты и фото с VIN. Я начал делать их в 2023 году, и с середины 2023-го они в работе: тогда около половины документов проходили без ручной правки. В 2024 году я перешёл на новые способы распознавания, и без правки проходило около 75 %. В 2025-м добавил новые данные и расчёты, доля выросла примерно до 95 %. В 2026 году я подключил AI-валидаторы и выпустил релизную версию: около 99,9 % документов проходят без ручной правки.

Валидаторов три, на сервисах Anthropic, OpenAI и Gemini, каждый под свою задачу. Как устроена проверка внутри, я не раскрываю. Принцип тот же, что описывает n8n: несколько независимых проверок вместо одной оценки, а последнее слово за сотрудником, который видит итог и подтверждает его. Парсеры освобождают около 60 часов ручной работы в неделю. Decisions API я у себя не пробовал; проверил бы его на маршрутизации входящих документов, где нужен ответ «что это и куда» до основного разбора.

Что я бы сделал

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

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

Хранил бы состояние снаружи модели: в базе, с номером заявки и историей шагов. Тогда сотрудник видит, что модель решила и почему.

Начал бы с одного типа решения и одной очереди на проверку человеком. Остальное подключал бы, когда первая очередь перестанет удивлять.

Связанные материалы

Про проверку результата модели: статья AI в обработке данных: извлечение и проверка и на странице AI в процессе, где результат можно проверить. Кейс про парсеры: PDR-компания в США экономит около 60 часов в неделю. Из обзоропо той же теме: извлечение данных из документов в 2026 году, что AI запомнил о клиенте и модель поверх вашей базы. Раньше я писал о надёжности AI-агентов и контроле над процессом и о том, как проверять AI-агента. Если в вашем процессе есть решения, которые сотрудник принимает по шаблону, расскажите, какие. Обсудить задачу.