Почему JSON Schema не делает ответ LLM надёжным

В сфере искусственного интеллекта произошло заметное событие. simonov_tech 9 минут назад Объяснить с Почему JSON Schema не делает ответ LLM надёжным Простой 7 мин 131 Go * SaaS / S+S * Кейс После того как LLM начинает возвращать structured output, интеграция внезапно становится очень похожей на обычный backend. Больше не нужно вырезать JSON из Markdown, надеяться, что модель не добавит перед ним «Конечно, вот результат», чинить потерянные кавычки и повторять запрос из-за случайной запятой. Мы описываем схему, модель возвращает объект, десериализуем его в Go-структуру — и кажется, что самая неприятная часть интеграции закончилась.

Например:type Invoice На выходе получаем:{ "number": "INV-2026-1842", "currency": "USD", "total": 148000 }JSON валиден. Unmarshal ошибок не вернул. Именно в этот момент очень легко начать относиться к результату LLM как к результату обычного API.

Технические детали

Но структурная корректность ответа ничего не говорит о том, действительно ли в исходном документе был счёт INV-2026-1842 на $1480. Модель могла вернуть идеальный JSON с неправильными данными. Для production-систем это различие намного важнее, чем кажется.

Мы проверили форму, а не фактВ обычном backend schema validation действительно даёт довольно сильную гарантию. Если API принимает:{ "quantity": 3, "price": 1200 }мы можем проверить типы, обязательные поля, диапазоны и затем сами посчитать итоговую сумму. Источник истины при этом находится внутри нашей системы.

С LLM ситуация другая. Когда модель извлекает данные из договора, PDF, письма или пользовательского сообщения, мы обычно используем её именно потому, что заранее не знаем правильного результата. Получается интересная конструкция:неструктурированные данные ↓ LLM ↓ structured output ↓ JSON Schema ↓ Go structПоследние два этапа проверяют только то, что результат выглядит так, как мы ожидали.

Отраслевые последствия

Они не проверяют первый переход:исходный документ → фактыА именно там и находится большая часть риска. У ответа на самом деле несколько уровней корректностиЯ бы разделял как минимум три разных понятия. Первое — syntactic validity.

Можно ли вообще разобрать ответ:if err := json. Unmarshal(data, &result); err ! = Второе — structural validity.

Есть ли обязательные поля, допустимые enum, корректные типы и диапазоны:currency ∈ total >= 0 invoice_number ! = ""И только третье — semantic validity. Соответствует ли значение реальности.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.