Начинать внедрение искусственного интеллекта (ИИ) на предприятии стоит с одного рабочего сценария, а не с выбора модели или покупки лицензий. Хорошая первая задача часто повторяется, опирается на понятные источники, а результат в ней можно проверить на реальных примерах предприятия. До разработки определяют критерий качества и собирают контрольный набор примеров; решение о запуске принимают по результатам проверки, а не по впечатлению от демонстрации.
Руководителю сегодня предлагают ИИ с разных сторон: поставщики показывают чат-ботов, сотрудники уже пользуются публичными сервисами, интегратор предлагает пилот. Демонстрации убедительны, но через несколько месяцев часто выясняется, что пилот завершён, а в работе ничего не изменилось. Разберём, почему так происходит и как выбрать задачу, с которой ИИ действительно войдёт в работу.
Почему пилоты ИИ не доходят до работы?
Обычно причина не в модели. Языковые модели хорошо справляются с текстом, но пилот проверяет не только модель, а весь сценарий: откуда берутся сведения, кто проверяет ответ, куда попадает результат и что происходит при ошибке.
Типичные разрывы повторяются. Задача сформулирована как «попробовать ИИ», и нет критерия, по которому пилот считается успешным. Данные лежат в разных местах, и для пилота их собрали вручную, а в работе так делать никто не будет. Не определено, кто отвечает за ответ, поэтому сотрудники либо не доверяют результату, либо принимают его без проверки. Наконец, решение живёт в отдельном окне и не связано с учётной системой: им пользуются, пока о нём напоминают.
Каждый из этих разрывов можно закрыть до разработки. Для этого первая задача должна быть выбрана так, чтобы на ней было видно весь путь — от источника до результата в работе.
Признаки хорошей первой задачи
| Признак | Почему это важно |
|---|---|
| Действие повторяется часто | Есть на чём проверить качество, и эффект заметен в повседневной работе. |
| Источники понятны и доступны | Решение опирается на документы и данные, которые предприятие может предоставить и обновлять. |
| Ошибку можно обнаружить | Сотрудник или правило проверяет результат до того, как он повлияет на учёт, клиента или безопасность. |
| Есть владелец процесса | Кто-то отвечает за сценарий, принимает результат и решает, что делать с ошибками. |
| Результат сравним с текущей работой | Можно сопоставить время, качество и число исправлений до и после. |
Неудачная первая задача — та, где цена ошибки высока, а проверить ответ трудно: например, решения о допуске продукции или финансовые обязательства без участия ответственного. Такие задачи не исключены навсегда, но начинать с них рискованно.
Хорошими кандидатами часто оказываются поиск по технической и нормативной документации, разбор входящих документов поставщиков и клиентов, подготовка типовых ответов и справок, первичная классификация обращений. Подходит ли конкретная задача, определяется не названием, а признаками из таблицы.
Учебный пример: спецификации поставщиков
Учебный пример. Ситуация создана для объяснения метода и не описывает конкретное предприятие.
Служба снабжения получает от поставщиков коммерческие предложения и спецификации в разных форматах. Специалист вручную переносит позиции в учётную систему, сопоставляет их с номенклатурой предприятия и проверяет цены и сроки. Это повторяется ежедневно, источники понятны, а ошибку видно при сверке.
Первая задача формулируется узко: извлечь из документа позиции, количество, цену и срок поставки и предложить соответствие номенклатуре. Решение о закупке по-прежнему принимает специалист. Критерий успеха задаётся до разработки: какая доля позиций распознаётся верно, сколько времени уходит на проверку и какие ошибки недопустимы.
Как оценить результат ИИ до разработки?
Основной инструмент — контрольный набор: несколько десятков реальных документов или вопросов, для которых известен правильный ответ. Его готовят вместе со специалистами, которые выполняют эту работу сейчас. В набор включают не только типичные случаи, но и трудные: плохие сканы, нестандартные формы, неоднозначные формулировки.
На этом наборе проверяют подход ещё до полноценной разработки. Смотрят не только на долю верных ответов, но и на характер ошибок. Ошибка, которую сотрудник легко замечает, допустима. Правдоподобная ошибка, которая проходит незамеченной, требует изменения сценария: дополнительной проверки, ограничения области применения или отказа от этой задачи.
Тот же набор используют после запуска и после каждого существенного изменения — модели, источников или настроек. Так качество измеряется на примерах предприятия, а не на общих тестах поставщика.
Какие решения принимает руководитель
Технические детали — задача исполнителя. Руководителю остаются решения, без которых проект не войдёт в работу:
- какой сценарий выбран первым и по какому критерию будет принято решение о запуске;
- кто владелец сценария и кто проверяет ответы;
- какие сведения можно передавать во внешние сервисы, а какие должны обрабатываться внутри предприятия;
- какое время специалисты выделят на подготовку контрольного набора и приёмку;
- что считается достаточным результатом, чтобы расширять применение.
Отдельно стоит решить вопрос о данных. Выбор между облачным сервисом, российской платформой и моделью внутри предприятия зависит от характера сведений, требований закона и условий договора с сервисом. Его лучше сделать до разработки, а не после пилота на открытом сервисе.
Что происходит после запуска
Запуск — не конец проекта. Источники обновляются, появляются новые формы документов, меняются правила. Нужны ответственный за качество, порядок обновления источников и периодическая проверка на контрольном наборе. Без этого точность постепенно снижается, и доверие сотрудников уходит быстрее, чем появилось.
Если первый сценарий дал результат, следующий выбирают по тем же признакам. Часто удобно расширять применение вдоль одного процесса: от разбора спецификаций к сопоставлению с номенклатурой, затем к проверке условий поставки.
С чего начать на практике
Выберите два-три кандидата по признакам из таблицы и для каждого ответьте на вопросы: откуда берутся сведения, кто проверяет результат, куда он попадает и как мы поймём, что стало лучше. Задача, на которую ответы получились самыми ясными, и будет первой.
Иногда на этом шаге выясняется, что задача надёжнее и дешевле решается обычной автоматизацией: правилами, шаблонами или доработкой учётной системы. Это тоже полезный результат — ИИ нужен там, где он лучше других способов, а не везде.
Как устроен полный цикл — от выбора сценария до запуска и проверки качества — описано на странице «Внедрение ИИ».