Как построить проверяемые решения на ИИ: пошаговый разбор подхода «модель предлагает - код решает» на открытой библиотеке solvi

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

1. Выберите одно решение с ценой ошибки. Самый частый тип обращения, где ошибка стоит денег: возврат, скидка, отсрочка, отгрузка без предоплаты. Сузьте до одной формулировки — например, «возврат в течение 14 дней при сохранной упаковке». Проверяемый результат: записано одно решение с частотой (сколько раз в неделю) и ценой ошибки в рублях или часах.
2. Запишите правило так, как объяснили бы новому сотруднику. Пять–десять строк, без слов «обычно», «в общем», «если клиент нормальный». Проверяемый результат: правило читается вслух за минуту и не оставляет двух толкований; спорный случай прямо описан как эскалация, иначе правило не готово к автоматизации.
3. Перечислите факты, на которые опирается правило: не оценки, а проверяемые обстоятельства — дата покупки, сумма, статус заказа, наличие вскрытой упаковки, повторность обращения. Проверяемый результат: список из трёх–восьми фактов, и для каждого указано, где он лежит в ваших системах.
4. Разделите роли письменно: модель предлагает факты, код проверяет, код решает. Проверяемый результат: у каждого факта помечен источник — модель (извлекает из текста обращения) или система (отдаёт точное значение); один факт не приходит из двух источников сразу.
5. Опишите схему фактов: поле, тип и признак обязательности — дата покупки дата, сумма число, упаковка сохранена да/нет/неизвестно. Проверяемый результат: схема показывает, какие ответы полны, а какие неполны и требуют доизвлечения или эскалации.
6. Подключите маленькую модель к извлечению фактов: её работа — превратить текст письма в заполненную схему, а не вынести вердикт. Проверяемый результат: на двадцати реальных обращениях модель возвращает факты в структуре, а не свободным текстом; неполные случаи видны сразу.

Первые шесть шагов дают разделение ответственности: модель отвечает за понимание текста, код — за соответствие правилу. Дальше появляется то, ради чего контур строится: проверка и след.

1. Напишите проверку фактов обычным кодом: сумму сверьте с платежами, дату — с окном возврата из правила, статус заказа — с фактическим. Проверяемый результат: функция, которая по каждому факту возвращает «подтверждён» или «не подтверждён» и причину отказа (не нашлось в базе, расходится, значение недопустимо).
2. Напишите решающую функцию — детерминированную, без обращения к модели. На входе подтверждённые факты, на выходе одно из трёх: одобрить, отклонить, отдать человеку. Проверяемый результат: повторный прогон даёт тот же ответ; в функции нет ни одного вызова модели.
3. Сохраните след по каждому решению: входные данные, модель и версия промпта, что модель предложила, что показала проверка кодом, итоговое решение и причина. Проверяемый результат: по решению месячной давности вы восстанавливаете цепочку целиком, не спрашивая сотрудника, что он имел в виду.
4. Прогоните контур на исторических случаях: сто–двести закрытых обращений прошлого периода против фактических решений сотрудников. Проверяемый результат: три числа — сколько совпало, сколько разошлось из-за правила, сколько из-за неполных фактов.
5. Введите порог эскалации: неподтверждённый факт, неполная схема или расхождение — решение уходит человеку, а не отклоняется и не одобряется «на всякий случай». Проверяемый результат: список причин эскалации и доля случаев, которые контур закрывает без человека.
6. Замерьте экономику: время на одно решение до и после, стоимость прогона модели, число ошибок, доведённых до клиента. Проверяемый результат: три числа в журнале, а не ощущение «стало быстрее» — часы, рубли за прогон, доля ошибок.
7. Расширяйте по одному решению за раз: новое правило — отдельный модуль со своими фактами, проверками и тестами, общий каркас и журнал прежние. Проверяемый результат: новое решение работает и оставляет след, не ломая уже работающее.

Где подход пока не работает — это важно проговорить до старта. Если критерий решения нечеткий («клиент проблемный», «случай неуважительный»), проверять кодом нечего, и контур превратится в чат с красивым журналом. Если факты нельзя получить из своих систем, модель начнёт достраивать даты и суммы, а проверка будет отклонять её предложения пачками — это сигнал сначала оцифровать источник данных. И отдельно: проверяемость не равна справедливости. Код подтверждает соответствие вашему правилу, но правильно ли само правило — по-прежнему решает человек, который его написал.