Проверяющие схемы и правила

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

Первый валидатор проверяет, что вывод соответствует структурному контракту. Собирайте все ошибки, а не только первую, чтобы обратная связь для исправления была полной.

Схемы не могут выразить всё. Схема может указать, что discount — это число, но не то, что оно не должно превышать промежуточную сумму. Валидаторы правил кодируют такие инварианты, связывающие несколько полей и учитывающие предметную область.

Библиотека типизированных моделей, например Pydantic, одновременно служит генератором схем и валидатором, поддерживая специальные валидаторы для правил. Ошибка разбора и есть вердикт.

Для выводов RAG проверяйте, что утверждения подтверждаются предоставленным контекстом. Требуйте от модели указывать идентификаторы источников, затем проверяйте условие exists для каждого указанного идентификатора и убеждайтесь, что цитируемые фрагменты действительно встречаются в источнике. Отклоняйте ответы, в которых указаны отсутствующие или выдуманные источники.

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

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

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

Польза валидатора многократно возрастает, когда его сообщения поступают в цикл исправления. Формируйте ошибки, пригодные для машинной обработки, с указанием пути к полю, нарушенного правила и значения, вызвавшего ошибку, чтобы модель могла точно исправить её за один шаг.

Ошибочный валидатор незаметно пропускает плохой вывод или блокирует хороший. Тестируйте каждое правило модульными тестами на положительных и отрицательных наборах данных, а для числовых инвариантов добавляйте тесты на основе свойств. Набор валидаторов — это критически важный для рабочей системы код, а не скрипт.

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

Валидаторы схем и правил:

• Проверка схемы охватывает структуру, а валидаторы правил — смысл.
• Типизированные модели создают схемы и выполняют проверку в одном месте.
• Для RAG и потоков данных добавляйте проверки опоры на источники, цитат и ссылочной целостности.
• Указывайте критичность, выполняйте проверки начиная с самых дешёвых и передавайте точные ошибки для исправления.
• Тестируйте валидаторы как критически важный для рабочей системы код.

Далее: проверка с помощью самокритики, когда модель проверяет собственный вывод.