С чего начать внедрение ИИ в компании, если вы не разбираетесь в ИИ

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

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

Представим, что руководитель говорит: "Давайте внедрим ИИ в клиентский сервис". Что именно нужно сделать?

Отвечать клиентам? Подсказывать оператору? Проверять качество разговоров? Определять причину обращения? Составлять краткое содержание звонка? Искать нужный пункт во внутреннем регламенте? Варить кофе?

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

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

Покажу на примере:

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

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

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

Это ещё не проект. Но это уже нормальная гипотеза.

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

У хорошего кандидата обычно есть несколько признаков:

• сотрудники регулярно работают с текстом, документами, письмами или записями разговоров;

• на вход поступают похожие, но не полностью одинаковые материалы;

• результат можно проверить;

• ошибки пока способен перехватить человек;

• эффект можно выразить во времени, деньгах, скорости или количестве ошибок.

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

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

Здесь обычно и выясняется, что главная проблема находится не в модели. У документов нет единого формата. Часть файлов приходит в виде плохих сканов. В заявке не заполнены обязательные поля. Правила сверки существуют только в голове опытного сотрудника.

Нейросеть этот беспорядок не исправит. Она просто начнёт работать внутри него.

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

Возьмите реальный пример и последовательно ответьте на вопросы:

1. Что поступает на вход?

2. Что делает сотрудник?

3. В каких системах он работает?

4. Какими правилами руководствуется?

5. Что получается на выходе?

6. Где он чаще всего ошибается или теряет время?

7. Кто отвечает за окончательный результат?

Важно разбирать не идеальный процесс из презентации, а фактический.

В схеме может быть написано, что все обращения регистрируются в CRM. На практике часть приходит в почту, часть в мессенджер, а важные подробности сотрудники записывают в свободном комментарии.

Если этого не увидеть в начале, ИИ-проект будет автоматизировать процесс, которого в реальности не существует.

Поверьте, что "ответы стали качественнее" это плохая метрика. Или то, что сотрудники наигрались.

До запуска проверки нужно зафиксировать исходное состояние.

Например:

• обработка одного документа занимает 12 минут;

• 15% документов возвращаются на повторную проверку;

• оператор тратит пять минут после звонка на заполнение карточки;

• руководитель вручную прослушивает только 2% разговоров;

• ответ по внутреннему регламенту ищут в среднем десять минут.

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

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

Один из главных вопросов нужно решить до прототипа: ИИ помогает сотруднику или принимает решение вместо него? Да, это не одно и то же.

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

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

Для первого проекта я почти всегда выбирал бы первый сценарий.

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

Фраза "у нас точность 95%" сама по себе ничего не гарантирует. Важно знать, что происходит в оставшихся пяти процентах. Иногда это безобидная опечатка. Иногда самая дорогая ошибка во всём процессе.

Для первой проверки не всегда нужна большая система. Возьмите 20–50 обезличенных примеров из реальной работы: документы, обращения, записи разговоров или запросы сотрудников. Подготовьте правильный результат, с которым будете сравнивать ответы ИИ.

Затем проверьте:

• справляется ли модель с типовыми случаями;

• где именно она ошибается;

• можно ли автоматически заметить часть ошибок;

• сколько времени занимает проверка человеком;

• действительно ли новая схема быстрее текущей;

• какие интеграции понадобятся для реальной работы.

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

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

Отрицательный результат здесь тоже полезен. Компания потратила несколько недель и не построила систему, которой никто не будет пользоваться.

Я бы не выбирал первым проектом задачу, в которой ИИ должен:

• заменить целый отдел;

• принимать необратимые решения;

• работать с процессом без понятного владельца;

• опираться на данные, которых фактически нет;

• подключаться сразу к десятку корпоративных систем;

• давать эффект, который никто не умеет измерить.

Чем красивее такая идея выглядит на слайде, тем осторожнее я бы к ней относился.

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

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

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

Выбор модели появится позже, когда станет ясно:

• что система должна получать на вход;

• какой результат от неё ожидают;

• какая точность приемлема;

• где будут находиться данные;

• как сотрудник проверит ответ;

• с какими системами потребуется интеграция.

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

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