Представим вполне реалистичный пилот.
Компания хочет автоматизировать обработку обращений клиентов. Есть внутренние правила: в каких случаях положена компенсация, когда обращение нужно передать руководителю, когда достаточно стандартного ответа, а когда требуется дополнительная проверка.
Для теста берут сто старых обращений. Одной ИИ-системе поручают принять решение по каждому случаю. Второй — независимо проверить те же самые обращения.
На большей части примеров ответы совпадают. Но в нескольких случаях одна система предлагает компенсировать клиенту расходы, а другая считает, что оснований для этого нет.
Можно подключить третью модель. Можно взять более дорогую. Можно попросить обе системы ещё раз внимательно подумать.
Но иногда после этого выясняется гораздо более неприятная вещь: сотрудники компании сами не могут однозначно сказать, какой ответ правильный.
Один опытный специалист считает, что компенсацию нужно дать. Другой уверен, что правила этого не позволяют. Руководитель объясняет, что «вообще обычно делаем так, но здесь есть нюанс».
И в этот момент проблема перестаёт быть проблемой искусственного интеллекта.
Оказывается, компания пытается автоматизировать решение, которое сама принимает непоследовательно.
ИИ нельзя оценивать без эталона правильного ответа
Когда тестируют распознавание документа, всё относительно просто. В документе написана сумма 125 000 рублей. Модель вернула 125 000 — правильно. Вернула 152 000 — неправильно.
С классификацией бизнесовых ситуаций всё сложнее.
Что считать хорошей заявкой в отделе продаж?
Когда клиенту положен возврат?
Какое расхождение в документе допустимо?
Когда заявка должна проходить автоматически, а когда отправляться на ручную проверку?
Кому передать нестандартный запрос?
Если на эти вопросы нет однозначного ответа внутри компании, невозможно объективно сказать, хорошо ли работает модель.
Можно посчитать, насколько часто она совпадает с решениями сотрудников. Но если сами сотрудники регулярно принимают разные решения в одинаковых ситуациях, такое совпадение мало что говорит о качестве.
Пока правила не зафиксированы, спор двух моделей мало чем отличается от спора двух сотрудников.
Получается фундаментальная проблема: прежде чем автоматизировать решение, нужно определить, что именно компания считает правильным решением.
В бизнесе огромное количество правил существуют только в головах сотрудников
Формально процесс может выглядеть хорошо описанным.
Есть регламент. Есть инструкция. Есть таблица с условиями. Есть должностные обязанности.
Но реальная работа почти всегда содержит слой неформальных знаний.
«Таким клиентам обычно идём навстречу».
«Если сумма небольшая, можно согласовать без руководителя».
«Этого поставщика лучше дополнительно проверить».
«Если запрос пришёл от постоянного клиента, действуем немного иначе».
«По регламенту нужно отказать, но в таких случаях мы обычно делаем исключение».
Для человека, который работает с процессом несколько лет, эти правила кажутся очевидными. Он даже может не воспринимать их как отдельные правила. Просто «так принято».
Когда появляется задача автоматизации, оказывается, что эту неформальную систему решений нужно каким-то образом передать машине.
И здесь очень легко ошибиться. Компания думает, что внедряет ИИ для автоматизации процесса, а на самом деле впервые начинает подробно выяснять, как этот процесс вообще устроен.
Две модели могут быть одновременно разумными и при этом давать разные ответы
Это тоже важно понимать.
Если две ИИ-системы принимают разные решения, это не обязательно означает, что одна из них плохая.
Представим обращение клиента. Товар формально не подпадает под стандартные условия возврата, но из переписки видно, что менеджер ранее дал клиенту неверную информацию.
Одна модель строго следует формальному регламенту и предлагает отказать.
Другая учитывает историю коммуникации и считает, что компания должна сделать исключение.
Оба рассуждения могут выглядеть логично.
Вопрос не в том, какая модель «умнее».
Вопрос в том, какую политику хочет проводить сама компания.
Если организация считает обещание сотрудника достаточным основанием для исключения, это должно стать частью правил.
Если нет — модель должна знать, что формальный регламент имеет приоритет.
ИИ может помочь применить правило. Но он не должен незаметно изобретать корпоративную политику вместо руководства.
Третья модель не создаёт истину
Кажется естественным решением привлечь ещё один ИИ.
Первая система сказала «да», вторая — «нет». Пусть третья выступит арбитром.
Такой подход действительно может быть полезен как дополнительная проверка. Но фундаментальную проблему он не решает.
Третья модель может выбрать одну из позиций. Может предложить третий вариант. Может убедительно объяснить, почему обе предыдущие системы неправильно поняли ситуацию.
Но от этого у компании не появляется эталон правильного ответа.
Мы всего лишь получили ещё одно мнение.
Третья модель добавляет ещё одно мнение, но не создаёт эталон правильного ответа.
Если вопрос касается общеизвестного факта, модель можно проверить по внешнему источнику. Если нужно вычислить сумму, есть формула. Если проверяется формат документа, существуют формальные правила.
Но если вопрос звучит как «должны ли мы дать этому клиенту компенсацию», правильный ответ определяется не устройством языковой модели, а правилами конкретной компании.
Именно поэтому проверка одного ИИ другим полезна только после того, как определён критерий правильности.
Особенно хорошо эта проблема видна в поддержке
Клиентская поддержка кажется очевидным кандидатом на автоматизацию.
Есть обращения, история клиента, внутренние инструкции и набор типовых действий. Модель способна прочитать всё это за секунды и предложить ответ.
Но довольно быстро появляются пограничные ситуации.
Клиент просит вернуть деньги позже стандартного срока, потому что долго ждал ответа поддержки.
Другому ранее пообещали скидку, которой формально нет в правилах.
Третий несколько раз столкнулся с одной и той же неисправностью и требует компенсацию больше стандартной.
Сотрудники поддержки часто решают такие случаи, исходя из опыта, контекста и негласной политики компании.
Если автоматизировать процесс без предварительного разбора этих решений, модель начнёт делать примерно то же самое: интерпретировать ситуацию на своё усмотрение.
Только делает она это гораздо быстрее и в значительно большем масштабе.
Поэтому перед автоматизацией поддержки полезно сначала проверить не модель, а согласованность решений самой команды.
В продажах происходит то же самое
Возьмём задачу оценки входящих заявок.
Компания хочет, чтобы ИИ автоматически определял, какие лиды перспективные и должны попадать к менеджерам в первую очередь.
На первый взгляд всё понятно.
Но затем оказывается, что разные менеджеры понимают «хорошего лида» по-разному.
Один смотрит прежде всего на бюджет.
Другой — на размер компании.
Третий считает ключевым наличие конкретной потребности.
Руководитель отдела при этом говорит, что иногда нужно брать даже небольшие проекты, если у клиента высокий потенциал дальнейшего роста.
Как должна вести себя модель?
Можно обучить её на исторических данных. Но тогда она унаследует фактическое поведение менеджеров вместе со всеми противоречиями.
Можно написать инструкцию. Но если реальные решения команды регулярно расходятся с инструкцией, проблема останется.
Поэтому автоматизация оценки лидов должна начинаться с ответа на гораздо менее технологичный вопрос:
По каким признакам компания действительно хочет определять приоритет заявки?
Проверка документов тоже не всегда настолько формальна, как кажется
Даже в документообороте встречаются решения, которые нельзя свести только к распознаванию реквизитов.
Допустим, автоматизация обнаружила расхождение между документом и данными в системе.
Что делать дальше?
Одно расхождение можно исправить автоматически.
Другое требует запросить новый документ.
Третье допустимо в рамках внутренних правил.
Четвёрто выглядит несущественным, но юридически блокирует операцию.
Опытный сотрудник обычно знает такие различия. Но до автоматизации они могут нигде явно не быть описаны.
Модель в этом случае не просто распознаёт документ. Она фактически начинает воспроизводить профессиональное решение специалиста.
А значит, к её проверке уже нельзя подходить как к OCR: сравнить поле с исходником и посчитать процент совпадений.
Сначала нужно зафиксировать, какое решение компания считает правильным для каждого класса ситуаций.
Как понять, готов ли процесс к автоматизации
Есть довольно простой практический тест.
Возьмите, например, сто реальных исторических случаев из процесса, который хотите автоматизировать.
Дайте их независимо двум опытным сотрудникам и попросите принять решение так, как будто они работают в обычном режиме.
Затем сравните результаты.
Если решения почти всегда совпадают, это хороший признак. Вероятно, внутри процесса существуют достаточно устойчивые правила, даже если они пока не полностью записаны.
Если же сотрудники регулярно расходятся во мнениях, сначала полезнее разобраться именно с этими расхождениями.
Не нужно стремиться к стопроцентному согласию. В некоторых задачах объективно остаются ситуации, требующие профессионального суждения.
Но тогда эти ситуации нужно явно выделить как отдельный класс и не требовать от ИИ полностью автономного решения.
Так появляется нормальная граница:
типовые случаи проходят автоматически;
пограничные отправляются человеку.
Спорные примеры ценнее очевидных
При подготовке контрольной выборки часто хочется взять много простых примеров.
Это создаёт красивую статистику.
Если из ста ситуаций девяносто очевидны, модель легко может показать 95% совпадения с эталоном.
Но для бизнеса гораздо важнее оставшиеся десять случаев.
Именно там находятся исключения, высокая цена ошибки и реальные различия в трактовке правил.
Поэтому после первого тестирования стоит собрать отдельный набор сложных ситуаций.
Что вызвало разногласие?
Какое решение в итоге принял ответственный руководитель?
Почему?
Какое правило из этого следует?
Нужно ли вообще автоматизировать такой случай?
Со временем именно из этих примеров формируется наиболее полезный набор для проверки новых версий системы.
Он показывает не способность модели справляться с очевидным, а её поведение на границе допустимой автономности.
Эталон должен утверждать бизнес, а не разработчик
Есть ещё одна частая ошибка.
Команда внедрения сама формирует набор «правильных ответов», исходя из имеющейся документации.
Технически это удобно. Но разработчик или специалист по ИИ не должен самостоятельно решать, кому компания возвращает деньги, какую заявку считать приоритетной или какое отклонение в процессе является допустимым.
Эти правила должны принадлежать владельцу бизнес-процесса.
Именно он должен разрешать спорные примеры.
Разработчик может помочь их систематизировать, найти противоречия и превратить решения в формальные условия.
Но итоговое правило — управленческое решение.
Иначе компания рискует получить очень последовательную автоматизацию политики, которую никто на самом деле не утверждал.
Не всё нужно превращать в промпт
После того как правила определены, появляется ещё один важный вопрос: что из них вообще стоит отдавать модели?
Допустим, существует точное условие:
если сумма операции выше определённого лимита, требуется подтверждение руководителя.
Нет причин спрашивать языковую модель, нужно ли подтверждение.
Это обычное детерминированное правило.
Модель полезна там, где нужно понять человеческий язык, классифицировать нестандартную ситуацию, извлечь смысл из документа или сопоставить несколько неструктурированных источников.
А финальное применение формальных правил лучше оставлять обычному коду.
Это снижает пространство для разных трактовок.
Получается полезное разделение:
ИИ понимает ситуацию, а система применяет правила компании.
Чем больше решений можно построить таким образом, тем предсказуемее автоматизация.
Уверенность модели не решает проблему неоднозначности
Можно попросить ИИ оценивать собственную уверенность.
Например:
«Компенсация положена. Уверенность — 92%».
Но высокий процент не означает, что корпоративное правило действительно применено правильно.
Модель может быть очень уверена в разумном решении, которое просто не соответствует политике компании.
Гораздо полезнее фиксировать другие признаки.
Какое правило применено?
Какие данные повлияли на решение?
Есть ли противоречие между источниками?
Относится ли этот случай к уже известному типу?
Есть ли похожий утверждённый пример?
Если система не может связать своё решение с понятным правилом или эталонным случаем, возможно, её действительно стоит остановить и привлечь человека.
Качество нужно измерять отдельно для простых и сложных случаев
Допустим, модель совпадает с утверждёнными решениями в 95% примеров.
Звучит отлично.
Но эта цифра почти ничего не говорит без понимания структуры ошибок.
Если пять процентов ошибок приходятся на незначительные классификации, качество может быть вполне приемлемым.
Если система безошибочно выполняет 95 простых случаев, а затем ошибается во всех пяти ситуациях, связанных с финансовыми последствиями, это уже совсем другая картина.
Кому компания возвращает деньги — решает владелец процесса, а не модель и не разработчик.
Поэтому при приёмке полезно делить случаи по риску.
Обычные.
Неоднозначные.
Финансово значимые.
Юридически значимые.
Требующие обязательного человеческого решения.
Для каждого класса можно установить собственный допустимый уровень автономности.
Это значительно полезнее одной красивой средней цифры точности.
Иногда лучший результат пилота — обнаружить плохой процесс
Есть интересный побочный эффект ИИ-аудита.
Компания приходит с задачей автоматизировать принятие решений, а в процессе выясняется, что одни и те же ситуации разные сотрудники обрабатывают по-разному.
На первый взгляд кажется, что внедрение остановилось.
На самом деле компания получила очень ценную информацию.
Если решения непоследовательны до появления ИИ, значит проблема существовала и раньше. Просто она была распределена между людьми и поэтому не так хорошо заметна.
Автоматизация заставляет сделать эти противоречия явными.
После этого можно привести в порядок правила, определить владельца решения и только потом возвращаться к технологии.
Иногда это приносит пользу ещё до первой строки интеграционного кода.
С чего начинать
Если компания хочет автоматизировать решение, которое сейчас принимают сотрудники, я бы не начинал с выбора модели.
Сначала стоит взять реальные исторические примеры и посмотреть, насколько последовательно этот процесс выполняют люди.
Выделить случаи, где ответ однозначен.
Отдельно разобрать случаи, где сотрудники расходятся во мнениях.
Для спорных ситуаций определить владельца процесса, который имеет право принять окончательное решение.
Зафиксировать не только ответ, но и причину.
После этого появляется контрольная выборка, на которой уже можно нормально тестировать ИИ.
И тогда вопрос «какая модель лучше?» становится измеримым.
Одна правильно обрабатывает 90% утверждённых примеров.
Другая — 95%.
Третья хуже на обычных случаях, но лучше распознаёт ситуации, которые нужно передать человеку.
Это уже нормальное сравнение.
До появления эталона спор двух моделей мало чем отличается от спора двух сотрудников.
Главный вопрос перед автоматизацией
ИИ способен очень быстро применять правила, искать закономерности и принимать решения на основе большого количества информации.
Но он не решает за компанию, какими должны быть её правила.
Поэтому перед внедрением системы, которая будет что-то одобрять, отклонять, классифицировать или рекомендовать, полезно задать простой вопрос:
Если два наших лучших сотрудника получат этот случай независимо друг от друга, они примут одинаковое решение?
Если да — процесс, скорее всего, уже достаточно зрелый для автоматизации.
Если нет — сначала нужно разобраться, почему.
При ИИ-аудите я бы именно с этого и начинал: не с моделей и не с промптов, а с реальных решений сотрудников, спорных случаев и критериев правильного результата.
Потому что самое сложное во внедрении ИИ иногда оказывается не научить машину принимать решения.
Сначала компании приходится самой решить, какое решение она считает правильным.
