«Сложно оценить» — это проблема дизайна: Хамель Хусейн о верификации ИИ-продуктов
Почему «черный ящик» убивает доверие пользователей
При разработке ИИ-продуктов команды сталкиваются с проблемой: результаты работы систем сложно поддаются оценке (evals). Разработчики тратят недели на подбор метрик и настройку ИИ-судей на базе больших языковых моделей. Однако, как отмечает независимый эксперт по внедрению ИИ Хамель Хусейн, если ИИ-артефакт трудно оценить внутренней команде разработчиков, то конечному пользователю проверить его качество будет практически невозможно.
Это явление эксперт называет «продуктовым запахом» (product smell) — явным признаком фундаментальной ошибки в проектировании интерфейса и логики взаимодействия (UX).
При слабом паттерне ИИ-продукт выдает один готовый, монолитный результат. Эксперт вынужден перепроверять его вручную. Если проверка отчета занимает столько же времени, сколько написание с нуля, ценность ассистента стремится к нулю. Это приводит либо к отказу от инструмента, либо к слепому доверию и ошибкам в критических сферах.
Решение этой проблемы лежит не в области усложнения алгоритмов, а в перепроектировании пользовательского опыта. Интерфейс ИИ-продукта должен быть прозрачным. Вместо слепого доверия продукту необходимо предлагать пользователю проверяемые промежуточные шаги, источники данных, сравнения изменений (diff) и небольшие структурные единицы, которые можно легко принять, отклонить или скорректировать по отдельности. Когда интерфейс спроектирован так, что эксперт может быстро верифицировать результат, внутренняя оценка качества работы ИИ для команды разработчиков также становится более простой, дешевой и точной.
Три сценария перепроектирования ИИ-интерфейсов
Чтобы понять, как этот принцип работает на практике, рассмотрим три примера перевода сложных ИИ-продуктов со «слепого» генеративного паттерна на верифицируемый дизайн.
1. Аналитический агент (Data Agent): переход к интерактивным блокнотам
- Как было: Пользователь запрашивает у ИИ-аналитика бизнес-метрику (например, «какова динамика выручки во втором квартале?»). Агент обращается к базе данных и возвращает единственное число: «Выручка выросла на 18%». Проверить это заявление в чате невозможно. Пользователю приходится верить на слово или самостоятельно писать SQL-запросы, чтобы перепроверить расчеты.
- Как стало: ИИ выдает ключевой ответ, но сразу подкрепляет его цепочкой рассуждений (provenance). В интерфейсе отображаются принятые допущения (assumptions), использованные таблицы-источники, сгенерированный SQL-запрос и распределение данных по регионам. Более того, ответ снабжается ссылкой на интерактивный блокнот (например, в среде Hex). В этом блокноте все шаги расчетов представлены в виде отдельных исполняемых ячеек кода. Эксперт может запустить любую ячейку, изменить параметры, проверить промежуточные суммы и убедиться, что логика верна. Верифицированный блокнот затем сохраняется в корпоративной базе знаний как надежный артефакт.
2. Конструктор учебных планов: опора на проверенные шаблоны и сравнение изменений
- Как было: Учитель физкультуры хочет составить план урока для четвертого класса на 45 минут с использованием определенного инвентаря. ИИ-генератор пишет весь план с нуля. Учителю приходится вчитываться в каждое предложение, чтобы оценить безопасность упражнений, хронометраж и соответствие стандартам.
- Как стало: Продукт принципиально меняет подход. Вместо генерации с нуля система осуществляет поиск по базе уже проверенных планов уроков, которые реально используются другими преподавателями. ИИ находит наиболее подходящий базовый план (например, «План Даны Руис для 4 класса, Lincoln Elementary, Austin TX, запущен 30+ раз в год, соответствует стандартам SHAPE, используется в 14 школах») и адаптирует его под новые ограничения. В интерфейсе учитель видит не монолитный текст, а режим сравнения (diff). ИИ подсвечивает ровно два точечных изменения: «разминка сокращена до 8 минут, чтобы уложиться в 45-минутный лимит» и «число станций уменьшено с 4 до 3, так как в спортзале нет достаточного количества баскетбольных мячей». Учитель может одобрить или отклонить каждую правку в один клик. Когнитивная нагрузка падает в разы.
3. Медицинские и экспертные отчеты: сначала проверка фактов, затем сборка
- Как было: Страховой врач должен составить экспертное заключение на 50 страниц на основе 18 различных медицинских карт пациента. ИИ генерирует весь финальный документ. Врач несет юридическую ответственность за каждую строчку, поэтому он вынужден вручную перечитывать все первоисточники, сопоставляя каждое утверждение в отчете с выписками.
- Как стало: ИИ-ассистент работает пошагово. На первом этапе он не пишет отчет, а извлекает из медицинских карт ключевые факты со строгими ссылками на страницы документов. Эти факты группируются в интерфейсе верификации:
- Противоречие (Contradiction): тест на подъем прямой ноги положительный в записях лечащего врача на стр. 31 и отрицательный в предыдущей экспертизе на стр. 22.
- Ключевой факт (Key Fact): в анамнезе зафиксировано растяжение поясничного отдела в 2019 году на стр. 14; дегенеративные изменения в сегменте L4-L5 на стр. 9.
- Открытый вопрос (Open Question): отсутствуют данные МРТ после 18 марта 2025 года. Врач изучает эту интерактивную панель, разрешает противоречия, подтверждает или отклоняет отдельные находки (resolve/include/dismiss). И только после того, как все экспертные факты проверены и утверждены человеком, ИИ собирает финальный связный отчет. Риск подписать красивую, но недостоверную галлюцинацию исключается.
От размытых оценок к бинарным чеклистам
Перепроектирование интерфейса под верификацию меняет и то, как команда оценивает качество работы ИИ на этапе разработки. Самая распространенная ошибка ИИ-команд — использование размытых субъективных шкал (например, «оцените полезность текста от 1 до 5»). Модели плохо справляются с калибровкой таких оценок, а разница между «3» и «4» остается непонятной как для ИИ-судьи, так и для человека.
Вместо этого методология Хамеля Хусейна предписывает использовать четкие бинарные чеклисты (pass/fail). Каждый пункт чеклиста должен описывать конкретный, наблюдаемый признак артефакта. Например, при оценке качества генерации рассылки чеклист может содержать следующие вопросы:
- Начинается ли письмо с правильного личного обращения к клиенту? (Да/Нет)
- Содержит ли вводный абзац крючок длиной менее 150 символов? (Да/Нет)
- Отсутствуют ли в тексте запрещенные штампы и слова-паразиты («AI slop»)? (Да/Нет)
- Имеет ли каждая приведенная цифра прямую ссылку на источник? (Да/Нет)
- Присутствует ли в конце письма обязательный блок отписки (opt-out)? (Да/Нет)
Если модель не проходит хотя бы один пункт, запускается цикл исправления: отдельный агент переписывает конкретный фрагмент текста, нарушающий правило. Отдельный агент-оценщик нужен для того, чтобы избежать ситуации самопроверки (self-review). Такой подход превращает абстрактную оценку в инженерный процесс отладки. Более того, эти же чеклисты можно выносить в пользовательский интерфейс в виде индикаторов соответствия стандартам, делая систему контроля качества прозрачной для клиента.
Как спроектировать путь верификации для вашего продукта
ИИ-командам важно сместить фокус с бенчмарков на проектирование пользовательского пути верификации (user verification path). Опишите: какой артефакт получает пользователь, какие утверждения в нем наиболее рискованны, какие данные их подтверждают и где увидеть доказательства.
Общим знаменателем для всех успешных решений является отслеживаемость (provenance). Пользователь должен видеть происхождение каждой детали. Использование всплывающих подсказок с первоисточниками, раскрывающихся списков с допущениями модели и бинарных индикаторов проверки позволяет соблюсти баланс: интерфейс не перегружается лишней информацией, но детальные доказательства всегда находятся на расстоянии одного клика.
Даже в таких технологически сложных сферах, как автономное программирование, разработчики передовых ИИ-инструментов (таких как Cursor или Devin) внедряют визуальную верификацию. Вместо того чтобы заставлять пользователя изучать тысячи строк измененного кода, эти системы могут записывать короткие видеоролики или генерировать интерактивные схемы, показывающие, как именно изменился интерфейс приложения после правок ИИ.
Внедрение верифицируемого дизайна требует от команд смелости: продукт должен открыто показывать свои сомнения. Открытые вопросы, зоны низкого уровня уверенности (low confidence) и внутренние противоречия данных должны быть первоклассными объектами интерфейса, а не прятаться в сносках. Показывая пользователю потенциально проблемные зоны ИИ-генерации до того, как они попадут в готовый документ, продукт демонстрирует честность и предсказуемость — единственную прочную основу для долгосрочного доверия к технологиям искусственного интеллекта.