Человек + ИИ | Нейросети для жизни и бизнеса

Зачем ИИ доступ ко всему вашему бизнесу?

Представьте, что вы подключаете ИИ-помощника, который должен отвечать клиентам на вопросы о доставке и оплате.

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

Всё логично.

Но при подключении сервис запрашивает доступ ко всей CRM, корпоративному диску или почте.

И здесь я бы остановился и задал простой вопрос:

А зачем ему столько информации?

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

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

Но это не совсем так.

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

Эти данные просто не относятся к его задаче.

И здесь есть хороший принцип, которым я бы советовал пользоваться.

Давать системе ровно столько доступа, сколько необходимо для работы. Не больше.

Давайте на примере.

Допустим, ИИ-помощнику нужно сообщать клиенту, на каком этапе находится его заказ.

Можно предоставить ему доступ ко всей базе клиентов с возможностью изменять записи.

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

Во втором случае у системы гораздо меньше лишних возможностей.

Причём дело не в том, что ИИ обязательно сделает что-то плохое.

Просто любая дополнительная возможность — это ещё одна вещь, которую придётся контролировать.

Если сервису не нужно удалять записи, зачем разрешать удаление?

Если достаточно читать документ, зачем давать право его редактировать?

Если нужна одна папка, зачем открывать весь корпоративный диск?

Вроде бы элементарные вопросы.

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

Я бы перед выдачей доступа проверял три вещи:

— какие именно данные нужны сервису;

— что он может с ними делать: читать, изменять, удалять или передавать дальше;

— можно ли ограничить доступ конкретной папкой, таблицей или отдельной функцией.

И ещё не стоит забывать про старые подключения.

Сервис могли использовать для одного проекта, потом перестать, а разрешения у него так и остались.

Поэтому предлагаю небольшую проверку.

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

Посмотрите, к каким данным и системам у него есть доступ.

А потом спросите себя:

«Всё ли из этого действительно необходимо для его работы?»

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

На мой взгляд, хороший ИИ-помощник — не тот, которому открыли все двери.

А тот, которому дали нужные ключи для конкретной задачи.

И этого вполне достаточно.

Зачем ИИ доступ ко всему вашему бизнесу?

Представьте, что вы подключаете ИИ-помощника, который должен отвечать клиентам на вопросы о доставке и оплате.

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

Всё логично.

Но при подключении сервис запрашивает доступ ко всей CRM, корпоративному диску или почте.

И здесь я бы остановился и задал простой вопрос:

А зачем ему столько информации?

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

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

Но это не совсем так.

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

Эти данные просто не относятся к его задаче.

И здесь есть хороший принцип, которым я бы советовал пользоваться.

Давать системе ровно столько доступа, сколько необходимо для работы. Не больше.

Давайте на примере.

Допустим, ИИ-помощнику нужно сообщать клиенту, на каком этапе находится его заказ.

Можно предоставить ему доступ ко всей базе клиентов с возможностью изменять записи.

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

Во втором случае у системы гораздо меньше лишних возможностей.

Причём дело не в том, что ИИ обязательно сделает что-то плохое.

Просто любая дополнительная возможность — это ещё одна вещь, которую придётся контролировать.

Если сервису не нужно удалять записи, зачем разрешать удаление?

Если достаточно читать документ, зачем давать право его редактировать?

Если нужна одна папка, зачем открывать весь корпоративный диск?

Вроде бы элементарные вопросы.

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

Я бы перед выдачей доступа проверял три вещи:

— какие именно данные нужны сервису;

— что он может с ними делать: читать, изменять, удалять или передавать дальше;

— можно ли ограничить доступ конкретной папкой, таблицей или отдельной функцией.

И ещё не стоит забывать про старые подключения.

Сервис могли использовать для одного проекта, потом перестать, а разрешения у него так и остались.

Поэтому предлагаю небольшую проверку.

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

Посмотрите, к каким данным и системам у него есть доступ.

А потом спросите себя:

«Всё ли из этого действительно необходимо для его работы?»

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

На мой взгляд, хороший ИИ-помощник — не тот, которому открыли все двери.

А тот, которому дали нужные ключи для конкретной задачи.

И этого вполне достаточно.

Сколько на самом деле стоит автоматизация? И дело не только в подписке

Когда речь заходит об автоматизации, часто первым делом спрашивают:

«А сколько стоит сервис в месяц?»

Вопрос нормальный. Только, на мой взгляд, начинать и заканчивать расчёт одной подпиской — не самая хорошая идея.

Потому что сама программа — это только часть расходов.

Давайте на простом примере.

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

Выбрали сервис, посмотрели тариф, прикинули бюджет.

Вроде всё понятно.

Но дальше начинается работа.

Во-первых, настройка.

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

Кто этим занимается?

Если подрядчик — это отдельная статья расходов.

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

Во-вторых, проверка.

Нужно убедиться, что помощник правильно отвечает, передаёт данные и нормально ведёт себя в нестандартных ситуациях.

На это тоже уходит время.

И если после проверки обнаружились ошибки, их придётся исправлять.

В-третьих, поддержка.

После запуска работа не заканчивается.

Могут меняться цены, услуги, правила и внутренние процессы компании.

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

Кто-то должен этим заниматься.

И, наконец, время сотрудников.

Это вообще интересная статья расходов.

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

Часть работы действительно могла исчезнуть.

Но появилась другая.

И её тоже нужно учитывать.

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

Я бы выписал отдельно:

— подписки на сервисы и дополнительные инструменты;

— первоначальную настройку и подключение;

— подготовку данных и инструкций;

— тестирование и исправление ошибок;

— регулярную техническую поддержку;

— время сотрудников на контроль и обновления.

Причём разовые расходы лучше не смешивать с ежемесячными.

А время сотрудников можно посчитать отдельно: сколько часов они потратили и сколько стоит это рабочее время для бизнеса.

Вот тогда появляется более понятная картина.

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

Вполне возможно, что она себя оправдает.

Но чтобы это понять, сначала стоит честно посчитать затраты.

Без выдуманных процентов экономии и обещаний окупаемости за две недели.

Попробуйте небольшой эксперимент.

Возьмите одну автоматизацию, которая уже работает в вашем бизнесе.

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

Не нужно сразу строить сложную финансовую модель.

Для начала достаточно увидеть полную стоимость, а не только сумму ежемесячной подписки.

Потому что иногда самое интересное в автоматизации находится как раз за пределами тарифа.

Почему неудачный ответ бота мне интереснее правильного

Когда бот отвечает правильно, это, конечно, приятно.

Задали вопрос — получили нормальный ответ. Всё работает, можно двигаться дальше.

Но, если честно, меня гораздо больше интересует другая ситуация.

Когда бот ошибся.

И особенно интересно разобраться, почему он это сделал.

Давайте на простом примере.

Представьте, что клиент пишет:

«Я не хочу отменять заказ, мне нужно только перенести доставку на пятницу».

А бот отвечает:

«Для отмены заказа обратитесь к менеджеру».

Вроде бы обычная ошибка. Не понял клиента.

Можно поправить ответ, ещё раз проверить и забыть.

Но я бы на этом не остановился.

Потому что возникает несколько вопросов.

Почему бот зацепился за слово «отменять», хотя человек прямо написал, что отменять ничего не собирается?

Он не понял смысл сообщения?

В сценарии вообще не предусмотрен перенос доставки?

Или система просто не умеет различать похожие запросы?

Вот это уже интересно.

Причём я бы не стал оправдывать бота тем, что клиент как-то неправильно сформулировал вопрос.

Человек написал вполне понятно.

Значит, разбираться нужно с системой.

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

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

А ошибка может показать, где у него слабое место.

В нашем примере я бы проверил, как он реагирует на похожие сообщения:

— «Хочу изменить дату доставки».

— «Не отменяйте заказ, просто привезите позже».

— «Можно перенести доставку на другой день?»

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

Может быть, нужно уточнить инструкции. Может быть, изменить сценарий. А может, проблема вообще в другом месте.

Без проверки причину не узнать.

Поэтому я считаю, что неудачные ответы не стоит прятать или списывать на особенности нейросети.

На них как раз можно улучшать систему.

Но сначала нужно честно признать: здесь бот не справился.

Без оправданий.

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

Ведь наша задача не в том, чтобы бот красиво выглядел на демонстрации.

Нам нужно, чтобы он нормально работал с реальными людьми.

А теперь мне интересно посмотреть на ваши примеры.

Если у вас есть неудачный ответ ИИ или бота, пришлите его в комментарии. Только уберите личные данные и другую конфиденциальную информацию.

Попробуем разобраться, что именно пошло не так.

Не просто посмеяться над ошибкой, а понять её причину.

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

Я бы завёл журнал ошибок ИИ. И вот зачем

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

Вы заметили ошибку, поправили ответ, проверили. Вроде всё нормально.

Через несколько дней похожая ситуация повторяется.

Только клиент задал вопрос немного по-другому.

И опять приходится разбираться.

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

А ведь у нескольких разных ошибок может быть одна причина.

Давайте на простом примере.

Допустим, в интернет-магазине оплата возможна только заранее.

Клиент спрашивает:

«Можно оплатить при получении?»

Бот отвечает: «Да, конечно».

Вы исправляете ответ.

Через некоторое время другой человек пишет:

«А наличными курьеру можно?»

И бот снова обещает то, чего магазин не предлагает.

Вопросы разные. Ошибка по сути одна.

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

Вот поэтому я бы завёл простой журнал ошибок ИИ.

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

Каждую ошибку можно записывать по четырём пунктам:

1. Запрос клиента: «Можно оплатить при получении?»

Ошибка: бот ответил «Да», хотя магазин работает только по предоплате.

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

Исправление: проверить и дополнить информацию, затем протестировать ответ.

2. Запрос клиента: «Можно заплатить наличными курьеру?»

Ошибка: бот снова разрешил оплату при получении.

Возможная причина: система неправильно использует условия оплаты или причина первой ошибки не устранена.

Исправление: проверить настройки, выяснить причину и повторно протестировать несколько похожих вопросов.

Это условный пример, но сам принцип, думаю, понятен.

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

Со временем подобные записи можно группировать.

Например:

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

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

И вот когда ошибки собраны вместе, уже проще увидеть повторения.

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

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

А после исправления — проверить не только старый вопрос, но и несколько похожих формулировок.

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

Для меня здесь главный смысл простой.

Ошибка ИИ — это не только повод поправить ответ.

Это ещё и информация о том, что в системе может работать неправильно.

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

Поэтому предлагаю небольшую практику.

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

Запишите четыре вещи:

Какой был запрос? В чём ошибка? Почему она могла возникнуть? Что изменили, чтобы она не повторялась?

А через некоторое время посмотрите на накопившиеся записи.

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

Вот с ними и стоит работать.