Structured Outputs и function calling: как агенты стали работать с JSON и SQL

Ещё пару лет назад заставить модель вернуть валидный JSON было упражнением на терпение: просишь «ответь только объектом», а получаешь объект, обёрнутый в объяснение, с оборванной запятой в конце. В 2024 году OpenAI выкатила режим Structured Outputs — гарантию, что ответ модели строго соответствует переданной JSON Schema. Anthropic и Google пошли похожим путём через tool use и response schema. С этого момента разговор об «агентах, работающих с данными» перестал быть маркетингом: модель теперь можно встроить в конвейер, где на выходе ждут не текст, а строку, которую разберёт парсер без try/except на каждый вызов.

Что именно изменилось

Раньше связка «модель плюс данные» держалась на промпт-инжиниринге и регулярках. Теперь три механизма делают её предсказуемой:

• Function calling (tool use) — модель не выполняет действие сама, а возвращает имя функции и аргументы в формате, который вы описали заранее. Ваш код вызывает функцию, отдаёт результат обратно, модель продолжает рассуждение.
• Structured Outputs / JSON mode — ответ жёстко валидируется по схеме на стороне провайдера. У OpenAI при включённом строгом режиме модель физически не может вернуть поле, которого нет в схеме, или пропустить обязательное.
• Генерация SQL — частный случай: модель по описанию таблиц и вопросу на естественном языке собирает запрос. Здесь гарантий формата меньше, потому что SQL — это не схема, а язык, и ошибку ловит уже сама СУБД.

Почему JSON надёжнее SQL

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

Гарантированный JSON убирает класс ошибок парсинга. Но он ничего не говорит о том, что внутри полей — правда. Валидная схема с выдуманными числами выглядит убедительнее, чем сбивчивый текст, и это ловушка.

Как это работает на практике

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

Для JSON-задач цикл короче: описываете схему ответа, передаёте её в поле response_format (термины у провайдеров различаются), получаете объект. Это удобно для извлечения данных из текста: распарсить резюме в поля, вытащить из письма сумму и реквизиты, классифицировать обращение.

RAG как источник структуры

Часто агент сначала достаёт факты через RAG*, а затем раскладывает их по схеме. Разделение полезное: поиск отвечает за то, откуда данные, а Structured Outputs — за то, в каком виде они уйдут дальше. Но если поиск вернул мусор, схема его аккуратно оформит и передаст дальше как достоверный результат.

Сравнение подходов у крупных провайдеров

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

Ни один из провайдеров не даёт «SQL-режим» как отдельную гарантированную фичу — генерация запросов везде остаётся задачей приложения поверх обычной генерации текста или function calling. Это осознанно: последствия неверного SQL слишком зависят от вашей схемы и прав доступа.

Кому это пригодится, а кому нет

Пригодится, если:

• Вы извлекаете поля из неструктурированного текста — писем, PDF, чатов — и хотите положить их в таблицу без ручной разметки регулярками.
• Строите внутренний BI-инструмент, где сотрудник спрашивает «сколько заказов за март по региону N», а агент собирает SELECT к витрине только на чтение.
• Нужен слой между моделью и API: function calling позволяет модели «попросить» вызов, а вы контролируете, что и с какими правами исполнится.

Не пригодится или опасно, если:

• Агент имеет доступ к базе на запись без ревью запросов — риск порчи данных выше любой экономии времени.
• Цена ошибки высока и её нельзя проверить: финансовые расчёты, где неверный JOIN даёт правдоподобную, но ложную сумму.
• Данные конфиденциальны, а вы отправляете схему и содержимое в облачную модель без проверки условий обработки — здесь сначала юрист и служба безопасности, потом эксперименты.

Что стоит держать в голове перед внедрением

1. Дайте модели доступ только на чтение и через отдельного пользователя БД с минимальными правами.
2. Логируйте каждый сгенерированный запрос до выполнения — это ваша единственная защита от тихой семантической ошибки.
3. Ставьте лимиты: тайм-аут на запрос, ограничение числа строк, запрет на DELETE/UPDATE/DROP на уровне прав.
4. Для JSON проверяйте не только валидность схемы, но и бизнес-правила: схема пропустит отрицательную цену, если тип поля — число.
5. Считайте стоимость. Каждая итерация цикла «запрос — ошибка — повтор» — это токены. На больших схемах БД контекстное окно** и счёт растут быстро.

* RAG (retrieval-augmented generation) — подход, при котором модель перед ответом получает найденные во внешнем источнике фрагменты и опирается на них, а не только на то, что «запомнила» при обучении.

** Контекстное окно — максимальный объём текста (в токенах), который модель обрабатывает за один запрос: и ваш ввод, и её ответ. Описание большой схемы БД съедает часть этого лимита.