EN
Связаться
Глава 9

Форма ответа должна быть контрактом

Мы управляли входом и поведением - осталось зафиксировать выход. Если результат читает программа, не просите "вернуть примерно такой JSON". Используйте structured output или tool schema, а смысл проверяйте уже в доменном коде.

TypeScript
type SupportDecision = {
  intent: "faq" | "account" | "refund" | "technical";
  answerability: "answer" | "clarify" | "escalate";
  answer: string | null;
  clarification_question: string | null;
  source_ids: string[];
  proposed_action: null | {
    type: "preview_refund" | "create_ticket";
    reason: string;
  };
};

Само по себе соответствие схеме - только первая из трёх проверок, и каждую делает свой слой.

  • Синтаксис - есть ли обязательные поля и допустимые enum. Отвечает schema или SDK.
  • Семантика - существуют ли на самом деле этот source_id, order_id, currency. Отвечает доменный код.
  • Полномочия - имеет ли actor право видеть и менять сущность. Отвечает backend policy.

Разделение важно, потому что валидная форма ещё ничего не гарантирует по сути.

Schema не доказывает истинность. Строка, похожая на ID, всё ещё может быть выдумана, а валидный enum не доказывает правильную классификацию. Structured output упрощает интеграцию, но не заменяет evals и проверку данных.

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

Проверка знаний

Ответ модели прошёл валидацию по schema. Что это доказывает?

Ссылки