Нейросеть прислала безупречный JSON. Скобки закрыты. Поля на месте. Сумма сделки — тоже. Только клиент эту сумму не называл. Машина закончила форму, заодно закончила фантазировать за покупателя.
Структурированный вывод нейросети — ответ в заданном контрактом формате: с согласованными полями, типами и допустимыми состояниями. JSON Schema помогает проверить форму данных. Достоверность значений, источник, актуальность и разрешение на запись проверяются отдельно. Для отсутствующих сведений заранее предусматривают неизвестное значение; валидный JSON не является подтверждением выполненной бизнес-операции.
Скобки закрылись. Сделка открылась в параллельной реальности
Условный менеджер попросил агента разобрать разговор. На выходе — контакт, потребность, бюджет и следующий шаг. Выглядит отлично: вместо полотна текста готовая карточка. Единственная неприятность — бюджет клиент не называл. Агент заполнил обязательное поле похожим числом, а интеграция аккуратно сохранила его. Теперь в CRM живёт сделка, которую отдел продаж слегка сочинил.
Эту ошибку легко принять за проблему модели. Однако система могла сама потребовать число в каждом ответе и не дать легального способа сказать «неизвестно». Сервис уверенно проверил, что число действительно число. На этой торжественной ноте валидация закончилась. За пределами церемонии остался факт, что денег никто не обещал.
Структурированные ответы полезны именно потому, что делают результат пригодным для программы. Но вместе с этим меняется цена ошибки. Неправильную фразу в сводке ещё может заметить сотрудник. Неправильное значение в поле автоматически попадёт в отчёт, фильтр и следующее действие. Чем удобнее интерфейс между моделью и приложением, тем яснее должны быть правила приёма.
Задача этой статьи — пройти путь от текста клиента до принятой записи. Мы не выбираем универсально лучший API и не обещаем устранить выдумки одним параметром. Разбираем контракт, который помогает программе отличать полученные данные от хорошо оформленной догадки.
Что действительно даёт схема ответа
Контракт описывает форму: какие поля существуют, какие обязательны, какие значения допустимы, где возможен список, число или отсутствие результата. Если приложение ждёт статус из согласованного набора, строка «ну скорее да, но пока подумает» не должна проходить как новый официальный этап воронки. Свободный человеческий язык остаётся в комментарии; рабочее состояние выбирается по определённым правилам.
Документация Claude о structured outputs описывает ограничение формата генерации через поддерживаемую JSON Schema и строгие входы инструментов. Конкретные ограничения схемы и модели нужно проверять для используемой версии. Наличие механизма ограниченного вывода относится к форме ответа. Оно не проверяет за бизнес, договорился ли покупатель о сроке.
Обычный JSON-режим и соответствие конкретной схеме также не одно и то же. Можно получить синтаксически корректный объект с другими ключами. А можно получить объект с нужными ключами, но неверным содержанием. Проверка требует нескольких ступеней, и ни одна не должна выдавать себя за все остальные.
Удобно разделить четыре вопроса: можем ли разобрать ответ; соответствует ли он структуре; подтверждены ли значения; разрешено ли их использовать в текущей операции. Первые два обычно проверяются автоматически. Третий требует связи с источником и критериев. Четвёртый относится к состоянию бизнеса и полномочиям. Смешайте их — получите зелёную галочку, которая слишком много на себя взяла.
Начинать нужно с получателя, а не с промпта
Перед генерацией полезно посмотреть, что делает система с каждым полем. Если бюджет влияет только на внутреннюю заметку, правила могут быть мягче. Если он меняет прогноз, сегментацию или маршрут согласования, цена неподтверждённого значения возрастает. Один и тот же результат нельзя без обсуждения использовать в трёх местах с разными последствиями.
Для карточки потребности разумно отделить сведения клиента, интерпретацию агента и готовность к записи. Например, названная потребность сохраняется вместе с фрагментом источника. Категория потребности является классификацией по принятому справочнику. Рекомендованный следующий шаг остаётся рекомендацией, пока его не приняли. Поля похожи по виду, но выполняют разную работу.
Не позволяйте интеграции угадывать назначение по имени ключа. «Дата» может означать дату разговора, желательный срок поставки или назначенную встречу. Название должно отражать смысл, а контракт — область и порядок получения. Условие «присылай date» выглядит экономно, пока два подразделения не начинают читать его каждый по-своему.
Заодно решают, какие дополнительные поля запрещены или игнорируются. В руководстве JSON Schema по объектам отдельно описаны properties, required и additionalProperties. Здесь важен принцип: описание свойства само по себе не делает его обязательным, а дополнительные свойства требуют явного решения. Схема — исполняемый договор о форме, а не словарь красивых названий.
Неизвестно, не применимо и ноль — разные ответы
Для бюджета ноль может означать названную клиентом сумму, отсутствие бюджета или некорректную замену пустоты. Эти смыслы нельзя склеивать. Если денег не обсуждали, поле остаётся неизвестным с соответствующим статусом. Если задача не предполагает сумму, это отдельное состояние. Если клиент действительно сказал «бюджет нулевой», источник должен подтверждать именно это.
Похожая ловушка есть у булевых полей. «Возражений нет» и «в доступной расшифровке возражений не найдено» звучат близко. Но первая формулировка относится к реальности, а вторая — к результату анализа источника. Обрыв записи или ошибка распознавания может оставить систему без части разговора. Она должна обозначить ограничение, а не выдать молчание за согласие.
Контракт можно строить вокруг статуса значения: подтверждено источником, предположение, неизвестно, противоречие. Для каждого статуса устанавливается допустимая дальнейшая работа. Это не означает необходимость одного гигантского универсального объекта. Для конкретной функции достаточно простого набора, если его понимают и модель, и программа, и проверяющий человек.
Практическое правило: обязательным может быть статус, а само значение — условным. Тогда модель обязана сообщить, что произошло с извлечением, но не обязана придумать недостающую сумму. С точки зрения формы объект остаётся полным. С точки зрения бизнеса он честно сообщает о нехватке данных.
| Источник | Опасная подстановка | Рабочее представление |
|---|---|---|
| Сумма не названа | Ноль или среднее число | Неизвестно, значение отсутствует |
| Обсуждают два срока | Ближайшая дата | Противоречие, две ссылки |
| Говорят «может быть» | Подтверждённое действие | Предложение, решения нет |
| Не хватило записи | Клиент не возражал | Источник неполный |
Полю нужен источник, а не медаль за уверенность
Полезный результат позволяет проверить происхождение значимого значения. Для разговора это может быть ссылка на запись и временной фрагмент, для документа — идентификатор, версия и участок текста. Самостоятельно написанная моделью цитата не является достаточным доказательством: её нужно сопоставить с реально доступным источником.
В учебном примере агент выделил срок «пятница». Приложение должно понимать, в какой реплике он появился и к чему относится: к отправке предложения, оплате или поставке. Поиск слова в расшифровке подтверждает наличие слова. Отношение слова к нужному событию требует отдельной проверки. Машина вполне может цитировать верно и связать неверно.
Число confidence иногда помогает ранжировать результаты на ручную проверку, но не должно автоматически заменять подтверждение. Если модель сама оценила уверенность, это ещё один её ответ. Порог имеет смысл после проверки на известном наборе задач и с понятной связью с ошибками. Без этого 0,98 — просто красивый костюм, надетый на предположение.
Для принятия данных полезнее установить конкретные критерии. Сумма присутствует в источнике, валюта установлена, субъект совпадает, контекст не отрицает значение. Если критерий не выполнен, поле не проходит соответствующее использование. Человек может принять его отдельно, но решение должно быть видно, а не появляться через тайный перевод «вероятно» в «согласовано».
Нормализация умеет незаметно менять смысл
После получения объекта приложение часто приводит значения к удобному виду. Убирает пробелы, переводит строку в число, подставляет значение по умолчанию. Это полезная инженерная работа, пока она не начинает устранять смысловые различия. Пустая строка, null и ноль могут внезапно стать одним значением. Система перестаёт видеть, что человек вообще ничего не сообщил.
Документация валидатора Ajv предупреждает о поведении опций, изменяющих данные при проверке: удалении свойств, подстановке defaults и приведении типов. Это не повод запретить такие возможности. Это повод согласовать порядок преобразования и наблюдать исходный и принятый результаты там, где различие существенно.
Например, фраза «пятьдесят тысяч, если доставка включена» содержит сумму и условие. Превратить её в число 50000 технически легко. Если при этом условие не попадёт в контракт, новый результат уже изменит смысл предложения. Нормализатор не должен становиться тихим переговорщиком, который отменяет всё после запятой.
Разделяйте извлечённое значение, его нормализованное представление и сопутствующие ограничения. Даты требуют известной точки отсчёта; единицы измерения — принятого справочника; деньги — валюты и контекста. При недостающем основании лучше получить требование уточнения, чем молча выбрать самое удобное значение для базы.
Правильные типы могут собрать невозможный объект
Условная заявка содержит две корректные даты: начало и конец. Каждая соответствует формату, но конец раньше начала. Или количество положительное, единица измерения существует, а выбранный материал продаётся только целыми упаковками. Отдельные поля валидны. Объект как бизнес-состояние недопустим.
Такие проверки относятся к связям и правилам. Цена согласуется с валютой, срок — с событием, ответственный — с доступной командой, идентификатор — с нужным клиентом. Приложение должно проверять их по своей модели. Нейросеть не является владельцем правил учёта и не может своим ответом создавать новые исключения.
Не все проверки можно сделать сразу. Текущий остаток, состояние заказа и доступность сотрудника меняются между анализом и исполнением. Поэтому перед действием читают актуальные данные. Если версия записи изменилась, подготовленный объект может потребовать пересмотра. Внутренняя рекомендация на вчерашнем состоянии — не разрешение переписать сегодняшнюю карточку.
Здесь важно не расширить статью до полного обзора безопасности агента. Границы полномочий разобраны отдельно. Для нашего контракта достаточно принципа: соответствующий схеме результат проходит только те действия, для которых выполнены текущие условия. Форма данных не назначает прав.
Подготовлено, принято и записано — три события
Пришедший объект ещё ничего не изменил в CRM. Сначала он подготовлен моделью. Затем может быть принят человеком или автоматическими правилами. После этого интеграция пытается выполнить операцию и получает результат. Если интерфейс показывает «готово» на первом шаге, пользователь естественно предполагает, что остальные тоже состоялись.
Состояния должны отражать реальность. Предложение подготовлено; нужна проверка; принято; выполняется; записано; отклонено; результат неизвестен. Конкретный набор зависит от процесса. Главное — ошибку подключения нельзя маскировать корректным ответом модели. Интеграция может не найти запись, столкнуться с изменённой версией или получить таймаут.
При неизвестном результате нужен способ восстановить состояние операции. Повторная генерация другого JSON не обязательно решает проблему: предыдущая запись могла уже состояться. Проверяют подтверждение системы-получателя, сохраняют связь с операцией и не создают новое действие только потому, что браузер перестал ждать.
На экране полезно показать разницу между предложенным и сохранённым значениями. Человек понимает, какие поля приняты, какие оставлены без изменений и что требует уточнения. Такой интерфейс скромнее эффектной кнопки «ИИ всё заполнил». Зато отделу не приходится искать, где заканчивается демо и начинается бухгалтерия.
Версия схемы меняет продукт, даже если промпт прежний
Появилось новое обязательное поле. Для разработчика это небольшая правка объекта. Для модели — новое требование. Для старого сохранённого ответа — несовместимость. Для системы-получателя — вопрос о значении по умолчанию. Изменение контракта проходит весь маршрут, хотя команда может считать его косметическим.
Версия нужна не только промпту. Фиксируют используемую схему, способ генерации, обработку отсутствующих значений и правила преобразования. Когда сотрудник показывает неверную карточку, команда должна понимать, по какому контракту её подготовили. Иначе разбор превращается в спор с текущей версией, которая в момент ошибки ещё не существовала.
Совместимость проверяют в обе стороны: новый результат читается получателем; старые записи открываются новым приложением; отложенные задачи не исполняются с неожиданным смыслом. При изменении справочника нельзя просто переименовать статус в одном месте. Нужен понятный переход для накопленных данных и очереди действий.
Для пилота достаточно небольшого явного контракта. Не надо сразу описывать все поля всей CRM. Выберите одну задачу, ограничьте выход и установите правила неизвестного. Когда результат стабильно принимается, контракт можно расширять. Гигантская схема не является свидетельством зрелости. Иногда это просто длинная форма для будущих ошибок.
Испытания, которые нельзя заменить одним удачным ответом
Первый набор — полнота и отсутствие сведений. Один источник содержит все требуемые факты, другой не содержит бюджета, третий обрывается до назначения следующего шага. Проверяют, что агент не заполняет пропуски и правильно обозначает состояние источника. Пустой результат иногда является верным результатом.
Вторая группа — смысловые ловушки: отрицание, условное обещание, два клиента в одном письме, несколько сроков для разных действий, отмена предыдущей договорённости. Проверяют не только итоговый текст, но каждое поле и его источник. Сводка может звучать убедительно, пока одно отрицание не оказалось за бортом.
Третья группа — маршрут исполнения. Запись изменили после анализа; справочник недоступен; получатель отклонил поле; подтверждение потерялось. Нужно увидеть правильное состояние процесса и отсутствие тихих подстановок. Для общей программы проверок есть материал о тестировании ИИ-агента; здесь ключевой объект приёмки — контракт данных между компонентами.
Считайте ошибки по назначению поля. Неверная категория, которой пользуются только для сортировки черновиков, и выдуманный согласованный бюджет неравнозначны. Общая точность на весь объект может скрыть критический дефект. Полезно отдельно наблюдать ложные заполнения, неверные связи с источником и ошибки допуска к записи.
Что должен видеть проверяющий сотрудник
Если человек должен проверять результат, ему нужен материал для проверки. Таблица полей без источников предлагает не контроль, а угадывание. Дайте рядом исходный фрагмент, статус значения, причину уточнения и отличие от действующей записи. Тогда сотрудник тратит внимание на расхождение, а не ищет нужную минуту в часовой записи.
Для одного принятого результата можно сохранить короткий след решения: какие значения подтвердили, какие исправили, какие оставили неизвестными. Не следует объявлять каждую человеческую правку обучением модели. Сохранение исправления и изменение поведения следующей версии являются разными процессами. Они должны быть объяснимы отдельно.
Слишком частое предложение неправильных полей создаёт привычку нажимать «принять всё». Поэтому полезность измеряется не скоростью выдачи формы, а временем получения принятого результата и числом последующих исправлений. Быстрая генерация двадцати спорных полей способна проиграть честному извлечению пяти нужных.
Для рекомендаций по сделкам отдельно полезен разбор работы ИИ-аналитика в CRM. Схема делает рекомендации удобными для приложения, но не освобождает от проверки причин. Самое красивое представление ошибки остаётся ошибкой. Только теперь она ещё и идеально сортируется.
Завтра попросите JSON без неназванной суммы
Начните с одного источника, где важного факта нет. Посмотрите, что агент вернёт и что приложение с этим сделает. Затем добавьте два противоречивых значения. Потом измените карточку между генерацией и записью. Эта короткая последовательность проверяет форму, честность отсутствия и актуальность исполнения.
В задании подрядчику зафиксируйте поля, статусы неизвестного, основания подтверждения, нормализацию, версии и результаты операции. Попросите показать отказ получателя и восстановление после неизвестного исхода. Если демонстрация всегда проходит по счастливой ветке, вы пока видели только красиво заполненную анкету.
Такие контракты обсуждаются при кастомном внедрении ИИ, когда конкретный процесс требует связи с корпоративными данными. Состав интеграции и полномочия определяются отдельно. Не нужно обещать автономность там, где бизнес ещё не согласовал, какие сведения считает подтверждёнными.
Попросите машину оставить неизвестное неизвестным. Если система этого не позволяет, сначала исправьте контракт. Пусть JSON будет чуть менее нарядным. Зато отдел продаж перестанет искать клиента, который согласовал сумму только в воображении агента.