ИИ-чат-бот по вашей базе знаний: отвечает клиентам вместо оператора, а данные не покидают офис

Полгода назад ко мне пришёл клиент с классической болью: два оператора весь день отвечают на одни и те же вопросы по телефону и в мессенджере. Сроки поверки, состав документов, где забрать акт. Я предложил не увольнять операторов, а поставить перед ними ИИ-бота, который читает внутренние документы и отвечает первым. Расскажу, как это работает, во что реально обходится и почему я категорически against отправки клиентской базы в ChatGPT.

Почему обычный чат-бот с ChatGPT тут не подойдёт

Первое, что предлагают на рынке — подключить готовый API OpenAI или того же ChatGPT, скормить ему инструкцию и радоваться. Работает, чего уж там. Но есть нюанс: чтобы бот отвечал точно, ему нужно скормить ваши документы. Прайсы, регламенты, договорные шаблоны, персональные данные клиентов из истории обращений. И вот это всё улетает на сервера в другую юрисдикцию.

Для медклиники это прямое нарушение 152-ФЗ — персональные данные пациентов за пределами России передавать нельзя, точка. Для юрфирмы это утечка адвокатской тайны, если в базе есть переписка с клиентами. У бухгалтерской конторы там могут лежать реквизиты счетов и суммы сделок конкурентов. Я видел, как один смежник радостно залил в облачный бот прайс-лист с персональными скидками для VIP-клиентов — и через месяц эти скидки конкурент знал наизусть.

Отдельная история — стабильность. Если у вас 200 запросов в день и OpenAI решит поднять цены втрое (что уже бывало) или обрубить доступ из России (тоже бывало), бизнес-процесс встаёт колом. Локальная модель этого риска лишена в принципе — она у вас в серверной, а не в чужом дата-центре в Дублине.

Что такое RAG простыми словами — без наукообразия

RAG расшифровывается как Retrieval-Augmented Generation, но эта аббревиатура вам ничего не даёт, поэтому забудьте. Суть в другом: у вас есть нейросеть, которая умеет складно писать по-русски, и есть поисковик по вашим документам. Когда клиент спрашивает 'сколько стоит поверка манометра', система сначала ищет в базе релевантные куски текста — прайс, регламент, — а потом отдаёт их модели с вопросом: ответь клиенту, опираясь именно на эти абзацы.

Разница с обычной болтливой нейросетью колоссальная. Без RAG модель может честно 'придумать' цену — нейросети умеют это делать с абсолютно убедительной интонацией, называется галлюцинация. С RAG она физически не может ответить мимо документа, потому что ей просто нечем — она видит только тот кусок текста, который нашёл поисковик, и генерирует ответ по нему.

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

Из чего это собирается технически

Железо. Для базы знаний среднего размера — до пары тысяч документов — хватает одного сервера с видеокартой уровня RTX 4090 или чуть скромнее, если модель поменьше. Речь о 150-250 тысячах рублей на оборудование одноразово, если брать новое; можно и б/у карту взять, дешевле раза в полтора. Крутить это всё можно и на CPU-сервере, но ответ будет ждать секунд 30-40 вместо 3-4, для живого клиента на телефоне это уже перебор.

Модель. Мы используем открытые модели — семейство Llama от Meta или российский GigaChat в локальном исполнении, в зависимости от требований по локализации данных. Крутится это через Ollama или vLLM — обвязка, которая позволяет модели работать локально почти как облачное API, только без интернета наружу. Обновлять модель раз в полгода-год, когда выходит версия получше, — процедура на пару часов, не революция.

База документов. Тут всё загружается через векторную базу данных — условно, ChromaDB или Qdrant, которые превращают ваши документы в математические 'отпечатки смысла' и по ним ищут. Загрузка полутора тысяч документов клиники занимает у нас часа три, дальше система индексирует новые файлы автоматически по расписанию, например раз в сутки, если документооборот активный.

Реальный кейс: медклиника вместо третьего администратора

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

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

Итог через два месяца: бот закрывает порядка 70% типовых вопросов без участия человека. Администраторы освободились для реальной работы — записи, работы с недовольными пациентами, звонков по забытым визитам. Экономия на зарплате не нанятого третьего администратора — около 55 тысяч рублей в месяц, окупили железо и настройку за четыре месяца.

Где бот обязательно налажает — и как это обойти

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

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

Третье — не надо ждать от такой системы человеческой эмпатии. Она отлично справляется с фактами: цена, сроки, состав документов, режим работы. Но 'успокоить расстроенного клиента' — это не про RAG-модель, как её ни настраивай. Тут я советую честно закладывать это ограничение в сценарий с самого начала, а не разочаровываться потом.

Сколько это стоит и когда окупается

Под ключ для компании на 15-30 рабочих мест такой проект у нас обычно укладывается в 300-450 тысяч рублей: сервер, настройка модели, интеграция с телефонией или мессенджером, загрузка и разметка базы документов, две-три недели обкатки с живой поддержкой. Дальше — только электричество и раз в год пересмотр модели, никаких лицензионных платежей за токены, как у облачных решений.

Для сравнения: облачный вариант через API того же OpenAI на похожем объёме трафика — это от 15 до 40 тысяч рублей в месяц в зависимости от числа обращений, плюс риск роста цены и юридические вопросы с персональными данными, о которых я говорил выше. За два-три года локальное решение выходит в разы дешевле, а данные всё это время не покидают вашу серверную.

Окупаемость считаем просто: сравниваем стоимость проекта с зарплатой одного оператора, которого не нужно нанимать, плюс с временем существующих сотрудников, освободившимся от рутины. У большинства моих клиентов на 20-40 рабочих мест это 4-8 месяцев. Дальше — чистая экономия плюс клиенты, которые получают ответ в 23:00 в субботу, а не в понедельник утром.

С чего начать, если решили пробовать

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

Соберите статистику: о чём спрашивают клиенты сейчас, посмотрите логи звонков или переписки за пару месяцев. Это даст точный список того, что должно попасть в базу знаний в первую очередь, а не гадание на кофейной гуще. Обычно 80% вопросов укладываются в 15-20 тем — вот с них и начинать.

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

Частые вопросы

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

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

Можно ли подключить бота к телефонии, а не только к мессенджерам?
Да, через голосовой шлюз с распознаванием речи бот отвечает и по телефону, но тут добавляется модуль синтеза и распознавания голоса — это плюс 15-20% к стоимости проекта и чуть более сложная настройка. Для старта я обычно советую мессенджеры и сайт, а телефонию подключать вторым этапом, когда обкатали сценарии.

Что будет, если бот ответит клиенту неправильно?
Система всегда показывает источник ответа — конкретный документ и абзац, поэтому ошибку легко найти и разобрать её причину: либо документ устарел, либо формулировка вопроса была нестандартной. На практике за счёт порога уверенности и эскалации сложных случаев человеку доля ощутимых ошибок держится в районе 2-3%, и это в разы меньше, чем у уставшего оператора в конце смены.