Как получить проверенный JSON от LangChain-агента через response_format

1. Составьте схему из действительно нужных полей: order_id, days и missing, определите типы и ограничения.
2. Передайте класс BaseModel как response_format для create_agent.
3. Попросите извлечь только явно присутствующие значения и обозначать пропуски; не просите угадывать номер.
4. Читайте structured_response и валидируйте прикладные инварианты после работы модели.
5. Прогоните отрицательный вход без номера заказа, затем сравните результат с ручной разметкой.

Пример ниже предназначен для демонстрационного окружения: установите соответствующий пакет интеграции, настройте ключ через секреты сервера и убедитесь, что модель доступна вашему аккаунту. Если доступ к указанному model ID отсутствует, выберите поддерживаемую модель со сходными возможностями и заново проверьте работу именно на ней. Ни один пример не содержит действующего API-ключа и не разрешает обход ограничений провайдера.

Готовый шаблон на Python

from pydantic import BaseModel, Field
from langchain.agents import create_agent

class ReturnCase(BaseModel):
    order_id: str | None = Field(description="Номер заказа или None")
    days: int | None = Field(description="Явно указанный срок в днях")
    missing: list[str] = Field(description="Не найденные во входе поля")

agent = create_agent(model="openai:gpt-5.5", tools=[],
    response_format=ReturnCase,
    system_prompt="Извлекай лишь факты текста; неизвестное обозначай None.")
result = agent.invoke({"messages": [{"role": "user", "content":
    "Заказ AB-417: возврат возможен в течение 14 дней."}]})
case = result["structured_response"]
assert case.days == 14 and case.order_id == "AB-417"

Конкретные входные и ожидаемые данные

Вход: «Заказ AB-417: возврат возможен в течение 14 дней». Ожидается объект order_id=AB-417, days=14, missing пуст; если на входе только «хочу вернуть заказ», days и order_id должны остаться None, missing перечисляет оба отсутствующих поля. Это критерий бизнес-валидации поверх форматной, а не гарантированный точный вывод каждой модели.

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

Диагностика и границы решения

Структурированный ответ уменьшает работу по парсингу, но не превращает извлечённое значение в подтверждённый факт. Модель может вернуть целое число 14 из контекста, где срок относится к другому товару; поэтому за schema validation должна следовать проверка предметных условий и источника. Если downstream система требует обязательный order_id, не объявляйте поле str с фиктивным значением: лучше явно разрешить None и не запускать действие до получения данных. Проверяйте отдельно тип, пропуски и согласованность полей, включая отрицательный срок и неверный формат ID. При модели без native schema LangChain может использовать ToolStrategy; это не следует скрывать при сравнении задержки и поведения ошибок. Если передаёте JSON Schema словарём, оборачивайте его ProviderStrategy или ToolStrategy в соответствии с документацией, иначе получите не ту автоматическую стратегию. Для Pydantic можно тестировать локальные валидационные ограничения отдельно без сетевого вызова. Сохраните десять размеченных русских сообщений, не только одно корректное; сравните заполнение каждого поля и частоту ложного извлечения. Особенно опасен не синтаксический сбой JSON, а валидный объект с выдуманным номером заказа.

Контрольный эксперимент

Удобный pipeline состоит из трёх разных решений. Сначала модель извлекает кандидаты из входа; затем Pydantic проверяет формат; наконец приложение решает, имеет ли пользователь право видеть или менять конкретный заказ. Ни один из первых двух этапов не заменяет третий. Если текст «14 дней» относится к общему правилу, а пользователь спрашивает о подписке, следует дополнительно подтянуть соответствующий договор. В логах храните ID источника и причину отказа; персональные сообщения лучше редактировать или минимизировать. Для редких ошибок создайте детерминированный набор regression tests: «номер не указан», «два разных номера», «срок дан словами», «отрицание правила». Не переписывайте ожидаемые данные после каждого обновления модели, иначе вы потеряете способность обнаруживать регрессию.

Дополнительный проверочный сценарий

Дополнительно проверьте, как схема ведёт себя при конфликтующих данных. Текст «заказ AB-417 отменён; к заказу AB-418 относится 14 дней» не должен породить связку AB-417 и 14 дней. В таком случае безопаснее возвращать неоднозначность и перечислять оба идентификатора отдельно, чем заполнять один валидный объект неправильной комбинацией. Выделите входные фрагменты для каждого поля и сохраняйте их offset или цитату, если бизнес-сценарий требует аудита. Если у схемы есть поле confidence, не выдавайте самооценку модели за измеренную вероятность: калибруйте её на размеченном корпусе или не используйте для автоматического решения. Применяйте различие между валидацией типов, семантической проверкой и проверкой полномочий при каждом обновлении схемы.