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