LangChain вернул правильный JSON, но данные неверны: что проверять

Правильная структура JSON не гарантирует правильные сведения. После проверки схемы нужны ограничения предметной области: существует ли дата, допустим ли переход статуса, принадлежит ли объект нужному клиенту. Эти проверки выполняет приложение, даже если модель поддерживает строгий структурированный вывод.

Пример: дата формально выглядит правильно

В учебном сценарии модель извлекает дату доставки и возвращает {"delivery_date":"2026-02-31"}. Строка соответствует шаблону YYYY-MM-DD, но такого календарного дня нет. Преобразование обычным JSON-парсером пройдёт: он не знает правил календаря.

from datetime import date
value = "2026-02-31"
try:
    date.fromisoformat(value)
except ValueError:
    print("invalid date")

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

Разделите три уровня проверки

  1. Формат: удалось ли разобрать ответ в нужную структуру?
  2. Схема: есть ли обязательные поля, правильны ли типы и диапазоны?
  3. Бизнес-правила: возможны ли такие значения вместе и разрешено ли действие?

Например, существующая дата тоже может быть недопустимой: доставка в прошлом, склад не работает по воскресеньям или пользователь не подтвердил перенос. Эти условия нельзя проверить одним регулярным выражением. Они зависят от текущих данных и правил приложения.

Как проверить обработчик

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

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

Этот разбор подготовлен Latorn. Если вы уже знаете основы Python и API и хотите практиковать такие решения системно, сравните программу платного курса LangChain 1.0.x со своей задачей. Открытый пример выше можно проверить самостоятельно; он не заменяет полный проект.

Технические источники: LangChain structured output, Python datetime. Учебные ситуации и числа в статье придуманы для объяснения механизма.

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

Продолжить на практике

  • LangChain 1.0.x: c нуля до продакшн LLM-приложений ↗

    Практический курс по LangChain. Соберёте продакшн LLM-бота: RAG по PDF с цитатами, веб-поиск и трекинг заказов, многошаговый агент для анализа CSV и финальное веб-приложение (UI + API). Плюс профессиональные блоки: PromptOps и версионирование промптов, метрики качества RAG, гибридный поиск с реранком, observability/стоимость, надёжность (ретраи, таймауты), guardrails и отдельный модуль по LangGraph для устойчивых workflow. P.S. Полностью обновили материалы на актуальную версию LangChain