JSON Schema, function calling или обычный текст: что выбрать для ответа нейросети

Один и тот же запрос к модели можно получить в виде абзаца, строгого JSON или вызова инструмента. Снаружи различается формат, но на деле меняется контракт между моделью и программой. Свободный текст хорош для человека. JSON Schema удобна, когда данные должна принять система. Function calling нужен, когда модель не только описывает намерение, но и предлагает реальное действие. Ошибка выбора приводит либо к хрупкому парсеру, либо к опасной автоматизации.

Разберём три подхода на одном примере: входящее обращение клиента нужно классифицировать, выделить номер заказа, подготовить ответ и при необходимости создать задачу оператору.

Свободный текст: максимум гибкости

Модель может написать понятное резюме и объяснить сомнения: «похоже на задержку доставки, но номер заказа не найден». Это удобно оператору и редактору. Формат переживает новые формулировки без изменения схемы. Минус проявляется, когда результат читает код. Заголовок может исчезнуть, значение — поменять порядок, а слово «срочно» оказаться частью цитаты клиента.

Регулярные выражения и поиск подстрок делают демонстрацию быстро, но плохо держат production-нагрузку. Свободный текст оставляйте там, где человек читает весь результат и самостоятельно нажимает следующую кнопку. Для массовой обработки полезнее отделить машинные поля от пояснения.

JSON Schema: проверяемая структура

Схема заранее задаёт поля, типы и допустимые значения: категория из списка, номер заказа как строка или null, уверенность в заданном диапазоне, проект ответа и причина передачи человеку. Валидатор может отклонить отсутствующее поле ещё до записи в CRM. Это снижает класс технических ошибок, но не делает содержание правдивым. Корректный JSON способен содержать выдуманный номер.

Схема должна отражать неопределённость. Поле «не найдено» лучше обязательной строки, куда модель вставит догадку. Для денег храните валюту и единицу отдельно. Для цитаты — исходный фрагмент и координаты, чтобы оператор мог открыть источник. Проверить структуру на практике можно в валидаторе JSON Schema.

Function calling: предложение действия

Вызов функции похож на JSON с именем инструмента: create_ticket, аргументы и идентификаторы. Главное отличие — результат предназначен не только для хранения, но и для выполнения. Поэтому валидность аргументов — лишь первый рубеж. Программа должна повторно проверить права пользователя, область данных, текущий статус заказа и допустимость операции.

Модель не должна получать универсальную функцию «выполни запрос». Узкий инструмент легче ограничить и проверить. draft_refund_request безопаснее, чем issue_refund, если решение требует человека. Для необратимого действия нужен экран подтверждения с точными параметрами. Наш материал о сетевых границах агента дополняет эту схему инфраструктурными ограничениями.

Сравнение по пяти критериям

По удобству чтения выигрывает свободный текст: автор может показать нюанс и оговорку. По стабильности машинной обработки — JSON Schema. По способности связать модель с рабочим процессом — function calling. По цене ошибки последний подход самый требовательный: неверный абзац можно исправить, неверно выполненное действие уже меняет данные.

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

Рабочая гибридная схема

Для обращения клиента разумно вернуть JSON с категорией, найденными фактами и проектом ответа. Интерфейс показывает эти поля человеку. Только после подтверждения отдельная функция создаёт задачу. Модель может предложить function call, но приложение проверяет аргументы и не выполняет его автоматически. Свободное пояснение остаётся рядом, чтобы оператор понимал причину классификации.

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

Как провести сравнение на своём процессе

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

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

Как выбрать

Выбирайте свободный текст для черновика, объяснения и творческой работы, где человек остаётся читателем. Выбирайте JSON Schema для извлечения, классификации и передачи данных между системами. Добавляйте function calling только тогда, когда нужен инструмент и вы готовы контролировать действие вне модели.

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

FAQ

JSON гарантирует правильность фактов?

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

Function calling означает, что действие выполнено?

Нет. Модель лишь формирует предложение вызова. Приложение решает, разрешить ли его, и должно вернуть фактический результат.

Можно ли хранить пояснение внутри JSON?

Да. Добавьте отдельное поле и не смешивайте его с идентификаторами, числами и решениями.

Что внедрять первым?

Для повторяемого процесса — небольшую версионируемую схему и ручное подтверждение. Инструменты подключайте после проверки ошибок на своей выборке.