Прибыль:
- Возможность устанавливать уровни проверки вывода на основе схемы и правил.
- Способность осмысленно требовать участия человека в процессе принятия важных решений
- Возможность разработать маршрутизацию на основе проверки и порога доверия с помощью второй модели.
Языковая модель обеспечивает плавность, убедительность и зачастую точность, но «убедительно» — это не то же самое, что «правильно». Модель может автоматически вписывать сумму, дату или поле JSON; Это называется галлюцинацией (модель уверенно выдает информацию, которой нет в реальности). В корпоративной системе, если эти выходные данные переходят на следующий шаг — платеж, электронное письмо, запись в базу данных — ошибка перерастает в реальный мир. В этом модуле мы научимся фильтровать выходные данные с помощью уровней проверки перед тем, как они попадут в систему, и требовать участия человека в процессе принятия важных решений.
Почему требуется проверка вывода?
Вывод модели может быть поврежден двумя основными способами: формат (не соответствует ожидаемой схеме JSON, поле отсутствует/избыточно) и содержимое (формат правильный, но значение неправильное — несуществующий код продукта, нелогичная дата). Существует третье измерение безопасности: вредоносный вывод (злонамеренная команда, созданная в результате внедрения или утечки). Надежная система останавливает всех троих у двери.
Внимание: «Модель в целом точна» не является производственным критерием. В системе без проверки даже одна ошибка из тысячи означает 100 ошибочных транзакций в день на 100 000 запросов в день.
Уровни аутентификации: шаг за шагом
- Проверка схемы. Проверьте с помощью машины, что вывод соответствует ожидаемой структуре: присутствуют ли поля, правильны ли их типы, заполнены ли обязательные поля?
- Проверка правил/бизнес-логики. Соответствуют ли значения бизнес-правилам? (Сумма > 0, дата не в будущем, код товара принадлежит каталогу.)
- Контроль ссылок/источников. Если модель выдает утверждение, можно ли связать его с источником? (Цитата RAG действительно присутствует в документе?)
- Проверка по второй модели (LLM-судья). Независимая модель оценивает результат как «правильный/неполный/рискованный».
- Порог доверия и ориентация. Если модель или валидатор сообщает о низкой достоверности, выходные данные не проходят автоматически; направлено на человека.
- Человеческий контроль. Результат с высокой эффективностью или низкой безопасностью зависит от одобрения эксперта.
Четыре копируемых шаблона
Схема + «придумай, если не знаешь» вместе:
Возвращайте ответ ТОЛЬКО в следующей схеме JSON: напишите «низкий». НИКОГДА не записывайте оценку так, как если бы она была точной.
Проверка со второй моделью (подсказка судьи):
Вы являетесь независимым валидатором. Ниже приведен текст <source> и <claim>. Проверьте, встречаются ли в источнике КАЖДОЕ число и дата в утверждении дословно. Для каждого скажите: «проверено | нет в источнике | противоречит источнику». Если хотя бы один из них «отсутствует/конфликтует», отметьте результат как «ТРЕБУЕТСЯ ПРОВЕРКА ЧЕЛОВЕКОМ».
Правило маршрутизации «Порог доверия»:
Правило маршрутизации: - emin_misin = «высокий» И сумма < 10 000 TL -> автоматическая обработка - emin_misin = «средний» ИЛИ сумма 10 000–100 000 TL -> проверка второй модели - emin_misin = «низкий» ИЛИ сумма > 100 000 TL -> требуется одобрение человека
Сводная карта человеческого аудита (ускоряет проверку):
Представляя решение человеку, предъявите эту карточку: - Что предлагается? (одно предложение)- На каком источнике это основано? (ссылка на статью/документ) – Каковы 2 самых слабых предположения? – Если они будут одобрены, можно ли их отменить? (да/нет)
Слабая подсказка/Сильная подсказка
плохой подход
Сильный подход
«Вычесть сумму из счета» (произвольный текст)
Строгая схема JSON + значение null + поле доверия
Запись вывода напрямую в платежную систему
Схема → правило → одобрение человека (при необходимости)
Просто говорю модели: «Будь уверена».
Проверка номера/даты со второй моделью
Обработка каждого вывода с одинаковой уверенностью
Маршрутизация, основанная на влиянии и доверии
Сильный подход не надеется, что модель правильна; Он создает дверь, которая поймает вас, если вы ошибетесь.
Три мини-кейса
Случай 1. Одной схемы было недостаточно. Автоматизация бухгалтерского учета извлекала сумму из счетов-фактур в формате JSON. Схема была правильной, но в счете-фактуре модель выдавала «125 000» вместо «1 250,00» (десятичный сдвиг). Схема не смогла это уловить; проверка правила («сумма должна соответствовать сумме позиций счета на ±1%)» была обнаружена и неправильная запись на сумму 112 500 TL была предотвращена.
Случай 2. Вторая модель уловила галлюцинацию. «Уведомление о расторжении за 30 дней», — сказал помощник по юридической поддержке в резюме контракта; Однако в контракте было 90 дней. Когда независимый судья пометил модель как «конфликтующую с источником», выходные данные были отправлены человеку и исправлены. Если бы это было автоматически, клиент уведомил бы об отмене, основываясь на неправильной дате.
Случай 3 — Маршрутизация снизила нагрузку на 70%. Система страховых возмещений автоматически одобряла претензии с низкой суммой и высокой степенью защиты и отправляла эксперту только те, которые превышают пороговый уровень/низкой степени защиты. Из 3200 ежедневных потребностей только 950 достались людям; эксперты посвятили свое время действительно рискованным 30%, при этом среднее время транзакции сократилось с 4 часов до 40 минут.
Совет: не устанавливайте человеческий контроль так, чтобы «люди могли видеть все» — это утомит людей, и одобрение станет штампом. Вместо этого направляйте к человеку только высокоэффективные и ненадежные результаты; Это концентрирует внимание на том, что действительно важно.
Придаем смысл человеческому контролю
«Человек в цикле» — это не просто установка флажка на бумаге. Рецензент должен иметь (1) контекст, позволяющий понять решение, (2) доступ к источнику и (3) право сказать «нет». В противном случае контроль останется косметическим. Карточка обзора (четвертый шаблон выше) предназначена для предоставления именно такого контекста.
Распространенные ошибки
- Просто выполняю проверку схемы и пропускаю ошибки содержания/значения.
- Думая, что, говоря модели «убедись», вы проводите настоящую проверку.
- Автоматически реализуйте важные и необратимые решения.
- Ставить человеческий контроль над каждым результатом и превращать одобрение в бессмысленный штамп.
- Сказать рецензенту «одобряю» без указания источника и контекста.
- Обработка всех выходных данных с одинаковым риском без установления порога доверия и маршрутизации.
В заключение
- Вывод поврежден тремя способами: формой, содержанием и злонамеренным намерением; надежная система останавливает всех троих у двери.
- Уровни: проверка схемы, правила/бизнес-логика, контроль версий, вторая модель (LLM-как судья) и маршрутизация по порогу доверия.
- Участие человека в процессе должно быть обязательным для результатов с высоким уровнем воздействия и низкой безопасностью.
- Человеческая оценка должна быть значимой: у рецензента должен быть контекст, доступ к ресурсам и право сказать «нет».
- И безопасность, и эффективность достигаются за счет направления на людей только рискованных результатов, а не всех результатов.
Задача приложения
Возьмите пример из результатов вашего собственного ИИ. Сначала определите схему JSON и принудительно выведите в нее вывод. Затем напишите как минимум два бизнес-правила (например, «сумма соответствует общему количеству товаров»). Наконец, настройте таблицу маршрутизации: какая комбинация доверия/влияния передается автоматически, какая — второй модели, какая — человеку? Создайте дефектный образец и наблюдайте, где каждый слой его фиксирует.
контрольный список
- [ ] Я определяю строгую схему вывода и проверяю ее на машине.
- [ ] Я добавил как минимум одну проверку бизнеса/правил (логика значений).
- [ ] Я могу связать утверждения с источником и проверить их.
- [ ] Доступна вторая модель или проверка на людях для результатов с высоким уровнем воздействия и низкой безопасностью.
- [ ] Правило маршрутизации определяется на основе доверия и влияния.
- [ ] Рецензенту предоставляется контекст, источник и полномочия для отклонения.