Как выбрать данные и критерии качества для ИИ-пилота

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

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

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

Сначала определить, что именно проверяет пилот

Формулировка «проверить возможности ИИ» слишком широкая. У пилота должна быть конкретная гипотеза. Например:

• можно ли автоматически классифицировать входящие обращения и передавать их нужному специалисту;
• способен ли ИИ извлекать определённые поля из документов разных поставщиков;
• сможет ли корпоративный поиск находить нужную информацию в базе знаний;
• способен ли агент самостоятельно закрывать типовые обращения первой линии;
• можно ли автоматически готовить черновик ответа менеджеру на основе данных из нескольких систем.

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

Для пилота нужны реальные, а не только удобные данные

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

Если в реальности компания получает договоры в PDF, сканы, фотографии документов и файлы разных шаблонов, тестировать решение только на аккуратных PDF одного вида недостаточно. Если клиенты задают вопросы с ошибками, используют внутренние названия товаров и объединяют несколько вопросов в одном сообщении, именно такие обращения тоже должны присутствовать в тестах.

Выборка должна отражать реальные условия будущей эксплуатации, включая их неудобные стороны.

Типовые случаи — только часть выборки

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

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

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

Так пилот проверяет не только способность ИИ дать правильный результат, но и его поведение, когда правильного результата получить невозможно.

Редкие случаи могут быть важнее частых

Состав тестовой выборки не всегда должен буквально повторять статистическое распределение данных.

Допустим, 95% счетов поступают в стандартном формате, а оставшиеся 5% — нестандартные документы. Если взять случайную выборку из ста файлов, сложных примеров окажется очень мало. Сделать вывод о работе системы с ними будет трудно. При этом именно на этих документах сотрудники могут тратить больше всего времени.

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

Данные должны соответствовать будущей системе

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

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

Если предполагается работа с несколькими источниками, разными форматами, правами доступа или историческими данными, желательно хотя бы частично воспроизвести эту среду уже во время пилота. Иногда именно качество исходных данных становится главным результатом проверки. Пилот показывает, что проблема не в модели, а в документах, справочниках или процессах, которые нужно привести в порядок до внедрения.

Для теста нужен эталон

Чтобы измерить качество, нужно знать правильный результат.

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

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

Например:

• выбран правильный клиент;
• использованы актуальные данные;
• найден нужный заказ;
• его статус не изменён без подтверждения;
• пользователю передана корректная информация.

Без такого эталона оценка быстро превращается в субъективное «ответ выглядит нормально».

Не использовать тестовые данные для постоянной настройки

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

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

Критерии качества должны следовать из бизнес-задачи

Универсального значения «ИИ работает достаточно хорошо» не существует. Для одной задачи приемлемо автоматически обработать 70% случаев, а остальные передать сотруднику. Для другой даже единичная ошибка может быть слишком дорогой. Поэтому критерии нужно выводить из процесса.

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

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

Одной средней точности обычно недостаточно

Допустим, система правильно обрабатывает 92% документов. Это выглядит хорошо, но неизвестно, где находятся оставшиеся 8%. Если ошибки равномерно распределены по второстепенным полям — ситуация одна. Если система периодически неверно извлекает сумму или ИНН — другая. Поэтому качество желательно смотреть по отдельным критичным элементам и сценариям.

То же относится к ИИ-консультанту. Средний процент правильных ответов может скрывать отличное качество на общих вопросах и плохое — на информации о конкретных заказах.

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

Ошибки нужно разделить по последствиям

Не все неправильные ответы одинаково опасны. Если агент выбрал неидеальную формулировку письма, сотрудник легко её поправит. Если он использовал неверную цену или изменил данные не того клиента, последствия существенно серьёзнее.

Поэтому ещё до пилота стоит определить категории ошибок. Например:

• допустимые отклонения;
• ошибки, требующие ручной корректировки;
• ошибки, из-за которых задача считается невыполненной;
• критические ошибки, которые система не должна совершать.

Тогда два решения с одинаковой общей точностью могут получить совершенно разную оценку. Для бизнеса это намного полезнее абстрактного сравнения процентов.

Нужно измерять способность отказаться от ответа

Хорошая ИИ-система должна не только знать, когда может выполнить задачу, но и корректно вести себя, когда информации недостаточно.

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

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

Кроме качества результата есть скорость и стоимость

Пилот должен отвечать не только на вопрос, может ли ИИ решить задачу технически.

Предположим, агент справляется с ней в 98% случаев, но для каждого результата выполняет десятки обращений к модели и внешним системам. Или обработка одного документа занимает столько времени, что решение невозможно использовать в нужном бизнес-процессе. Поэтому дополнительно могут измеряться:

• время обработки;
• стоимость одной операции;
• количество обращений к модели;
• нагрузка на внешние системы;
• доля задач без участия человека;
• время сотрудника на проверку результата.

Особенно полезно считать не стоимость одного запроса к модели, а стоимость успешно выполненной бизнес-задачи.

Критерий успеха лучше определить до начала пилота

Одна из самых неудобных ситуаций возникает в конце эксперимента: Точность получилась 84%. Это хорошо или плохо?

Если порог не определён заранее, результат легко интерпретировать в любую сторону. Поэтому до запуска стоит зафиксировать, что будет означать успешный пилот. Например:

Что проверяем	Пример критерия
Качество основной задачи	Не менее заданной доли корректно выполненных сценариев
Критические ошибки	Не допускаются или имеют отдельно установленный предел
Сложные случаи	Проверяются отдельно от типовых
Отказ / эскалация	Система корректно передаёт случаи за пределами своих возможностей
Скорость	Укладывается в допустимое для процесса время
Стоимость	Соответствует предполагаемой экономике решения
Ручная работа	Сокращается относительно текущего процесса

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

Результатом пилота может быть не только «да» или «нет»

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

Может выясниться, что качество модели достаточное, но сначала нужно привести в порядок корпоративные данные. Или что решение технически работает, однако его эксплуатационная стоимость пока слишком высока.

Иногда пилот показывает, что для задачи вообще не нужен сложный ИИ и её проще решить обычной автоматизацией. Это тоже полезный результат. Цель пилота — не доказать заранее принятое решение о внедрении, а снизить неопределённость перед более крупными инвестициями.

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