Искусственный интеллект уже стал частью бизнес-процессов и играет все более заметную роль в работе компаний. Сегодня ИИ используется во множестве направлений — от анализа данных до улучшения клиентского сервиса и автоматизации поддержки.
По мере роста бизнеса нагрузка на службу поддержки обычно увеличивается быстрее, чем сама команда. Количество обращений растет, продуктовая документация обновляется, а специалисты все больше времени тратят на ответы на одни и те же вопросы.
На первых этапах проблему может частично решить FAQ, который поддерживается вручную. Однако со временем его становится все сложнее сохранять актуальным: новые функции продукта порождают новые вопросы, старые ответы устаревают, а нужная информация оказывается распределена между документацией, справочными разделами и внутренними ресурсами.
Именно с такой задачей мы столкнулись в одном из проектов СКЭНД. Нам требовалось создать ИИ-чат-бота для клиентской поддержки, который отвечал бы на вопросы пользователей на основе существующей базы знаний заказчика, а не заранее подготовленного вручную списка вопросов и ответов.
В этой статье расскажем, как мы подошли к решению задачи, почему выбрали RAG-архитектуру, как организовали синхронизацию базы знаний с сайтом заказчика и какие технологии использовали при разработке.
Проблема: почему статичные FAQ плохо масштабируются
Традиционные разделы FAQ хорошо работают, пока продукт относительно небольшой, а документация меняется нечасто. Сложности начинаются по мере роста объема и сложности информации. У статичного FAQ обычно есть несколько ограничений:
- Служба поддержки снова и снова отвечает на одни и те же вопросы. Пользователи могут спрашивать о тарифах, функциях, интеграциях, настройках аккаунта, устранении неполадок или правилах, хотя эта информация уже есть в документации.
- Поддерживать FAQ приходится вручную. Необходимо отслеживать новые вопросы, готовить ответы, пересматривать существующий контент и публиковать обновления.
- Информация быстро устаревает. Страница продукта может измениться, а в FAQ по-прежнему останется ссылка на старую функцию, процесс или правило.
- Пользователи формулируют вопросы не так, как они записаны в FAQ. Например, клиент может спросить: «Можно ли изменить подписку после перехода на другой тариф?», хотя в документации используется совсем другая формулировка.
- Одна страница FAQ не охватывает всю базу знаний. Полезная информация часто распределена между документацией, статьями поддержки, страницами продукта и другими ресурсами.
Традиционные FAQ-системы помогают публиковать и управлять часто задаваемыми вопросами, но не всегда решают основную задачу — быстро находить нужную информацию.
Нам нужен был чат-бот, который мог бы понимать вопрос пользователя, находить наиболее релевантные сведения в постоянно обновляющейся базе знаний на сайте и формировать ответ на их основе. Для этого потребовался более продвинутый подход к разработке чат-бота.
Что такое FAQ-чат-бот на базе RAG
FAQ-чат-бот на базе RAG объединяет семантический векторный поиск с большой языковой моделью (LLM). Система находит релевантную информацию в базе знаний, а затем использует ее как контекст для формирования ответа на вопрос пользователя.
В отличие от традиционных FAQ-систем, которые обычно работают с заранее заданным набором вопросов и ответов, чат-бот на базе RAG может искать информацию по гораздо более широкой базе знаний. В качестве источников можно использовать различные типы документов — TXT, Word, Excel, PDF и другие форматы.
С точки зрения пользователя такой чат-бот выполняет функцию FAQ и отвечает на вопросы службы поддержки. Однако технически он не ограничен сопоставлением запроса с фиксированным списком заранее подготовленных вопросов.
Для создания подобных решений разработка RAG-систем позволяет объединить корпоративные источники знаний с ИИ-поиском и генерацией ответов.
FAQ-чат-бот и чат-бот на базе знаний: в чем разница
Хотя термины «FAQ-чат-бот» и «чат-бот на базе знаний» часто используют как взаимозаменяемые, они описывают немного разные подходы к организации и предоставлению информации. Оба решения могут использоваться в клиентской поддержке, однако работают с информацией по-разному.
FAQ обычно представляет собой заранее подготовленный набор типовых вопросов и ответов:
Вопрос → заранее заданный ответ
База знаний охватывает гораздо больше информации. В нее могут входить продуктовая документация, инструкции по устранению неполадок, правила и регламенты, обучающие материалы, описания функций и другие структурированные и неструктурированные данные:
Вопрос пользователя → релевантная информация → сгенерированный ответ
В нашем чат-боте именно база знаний выступает основным источником информации. С точки зрения архитектуры это принципиальное отличие. Вместо того чтобы строить систему вокруг статичного списка FAQ, мы разработали процесс, который загружает контент со всех страниц официального сайта заказчика, преобразует его в формат, пригодный для поиска, находит релевантный контекст и передает его LLM.
В результате ИИ-чат-бот может отвечать на вопросы даже в тех случаях, когда их точной формулировки нет в исходных материалах. В отличие от традиционных FAQ-ботов, основанных на заранее заданных вопросах и ответах, такой подход позволяет обрабатывать более широкий спектр обращений и формировать более релевантные ответы.
При этом база знаний не остается статичной. Система отслеживает изменения на сайте заказчика и передает обновленные данные в векторное хранилище, благодаря чему информация, которую использует чат-бот, синхронизируется с исходным контентом. По своей логике такое решение уже приближается к ИИ-агенту для клиентской поддержки, который может постоянно обращаться к актуальным корпоративным данным и использовать их при формировании ответов.
Наш подход: архитектура чат-бота
Мы построили решение как чат-бот на базе RAG, который объединяет существующую базу знаний заказчика с LLM. Вместо обучения модели на фиксированном наборе FAQ система при каждом вопросе пользователя находит актуальную информацию в базе знаний и использует ее как контекст для формирования ответа.
Архитектура включает пять основных этапов: обнаружение новой информации, загрузку и структурирование исходного контента, векторизацию и поиск релевантных данных, генерацию ответа с помощью LLM и синхронизацию базы знаний с изменениями на сайте заказчика.
Загрузка и подготовка базы знаний
Первый этап — обнаружение нового или измененного контента, например статей и страниц. Для этого система периодически обращается к API сайта на WordPress и проверяет наличие обновлений. Если обнаружена новая страница, статья или изменение существующего материала, контент передается на следующий этап обработки.
Далее существующую и новую документацию заказчика необходимо преобразовать в структурированный машиночитаемый формат. Базы знаний и сайты могут содержать разные типы контента — заголовки, абзацы, списки, таблицы и ссылки, поэтому простого извлечения текста недостаточно для качественного поиска.
Для разбора и структурирования исходных материалов мы использовали Docling, сохраняя иерархию документа и смысловые связи между его элементами. Затем обработанный контент разделялся на логические фрагменты с перекрытием, которые можно было независимо индексировать и использовать при поиске.
Процесс загрузки и обработки данных можно представить так:
Сайт и документация заказчика → Docling → структурированный контент → фрагменты документов → векторизация
Такой подход позволяет чат-боту работать с уже существующими материалами заказчика, не требуя от службы поддержки создавать отдельную базу вопросов и ответов специально для чат-бота.
Векторизация и поиск
После структурирования контента следующим шагом было сделать поиск не только по точным ключевым словам, но и по смыслу.
Система преобразует содержимое базы знаний в векторные представления и сохраняет их для семантического поиска. Когда пользователь задает вопрос, его запрос также преобразуется в вектор, после чего система находит фрагменты контента, наиболее соответствующие смыслу и намерению пользователя.
Например, клиент может спросить: «Можно ли изменить подписку до окончания текущего расчетного периода?»
При этом в базе знаний может быть статья с заголовком «Управление подпиской». Несмотря на различия в формулировках, семантический поиск позволяет определить релевантный раздел и передать его чат-боту в качестве контекста.
Процесс поиска можно представить так:
Вопрос пользователя → векторизация запроса → семантический поиск → релевантный контент из базы знаний → контекст для LLM
Этот уровень поиска — одна из ключевых частей ИИ-чат-бота, поскольку позволяет системе отвечать на вопросы, даже если пользователь формулирует их иначе, чем в исходной документации.
Генерация ответа
После того как система находит наиболее релевантную информацию, вопрос пользователя и выбранный контекст передаются LLM.
В этом проекте в качестве инфраструктуры для работы с LLM мы использовали Groq и Ollama. Groq обеспечивает высокую скорость инференса, что особенно важно для оперативного взаимодействия с пользователями, а Ollama позволяет запускать совместимые модели локально или в собственной инфраструктуре.
LLM получает инструкцию формировать ответ на основе найденной информации, а не только на своих общих знаниях. Это помогает сохранять ответы релевантными конкретным продуктам, правилам и документации заказчика.
В упрощенном виде процесс выглядит так:
Вопрос пользователя + найденный контекст + системные инструкции → LLM → ответ пользователю
Разделение поиска и генерации также делает архитектуру более гибкой. База знаний и поисковый конвейер могут оставаться без изменений, тогда как саму LLM можно заменить с учетом требований к производительности, стоимости, конфиденциальности или способу развертывания.
Синхронизация базы знаний
Одна из ключевых особенностей нашего подхода заключается в том, что чат-бот не зависит от разовой загрузки документации заказчика.
Сайты и базы знаний постоянно меняются: появляются новые функции, обновляются инструкции, устаревшая информация удаляется. Если эти изменения не отражаются в данных чат-бота, даже технически продвинутый ИИ-ассистент может давать неактуальные ответы.
Чтобы избежать этого, мы реализовали процесс синхронизации, который отслеживает изменения на сайте заказчика через API и соответствующим образом обновляет векторное хранилище.
В упрощенном виде процесс выглядит так:
Изменения на сайте → обнаружение обновленного контента → обработка контента → повторная векторизация → обновление векторного хранилища
Если релевантная страница изменяется, обновленный контент можно повторно обработать и проиндексировать без необходимости заново перестраивать всю базу знаний.
Такая синхронизация особенно важна для FAQ-чат-бота в клиентской поддержке, где точность ответов напрямую зависит от актуальности исходной документации. В результате чат-бот работает как диалоговый интерфейс поверх постоянно обновляемой базы знаний, а не как статичный набор заранее подготовленных ответов.
Используемый технологический стек
Для создания ИИ-чат-бота недостаточно просто подключить LLM к списку вопросов и ответов. Необходим полноценный конвейер для обработки документов, поиска информации, оркестрации рабочих процессов, хранения данных и генерации ответов.
Для этого проекта мы выбрали технологический стек, который позволил сохранить архитектуру гибкой, оптимизировать затраты и упростить адаптацию решения под инфраструктуру разных заказчиков.
| Компонент | Назначение |
| LangChain | Построение конвейера поиска и взаимодействия с LLM |
| LangGraph | Оркестрация многоэтапных сценариев чат-бота, автоматическое суммирование и управление ссылками на источники |
| PostgreSQL | Постоянное хранение данных приложения |
| Docling | Разбор и структурирование исходной документации |
| Groq | Высокоскоростной инференс LLM, GPT OSS 120B |
| Ollama | Локальный запуск LLM или развертывание в собственной инфраструктуре |
| Векторный поиск | Поиск семантически релевантной информации в базе знаний |
LangChain и LangGraph
LangChain предоставляет набор компонентов для объединения поиска по документам, промптов, моделей и других элементов системы. LangGraph, в свою очередь, используется для оркестрации более сложных сценариев, где чат-боту требуется последовательное выполнение отдельных этапов и управление состоянием.
Вместе эти инструменты создают гибкую основу для RAG-архитектуры и позволяют выстраивать систему из отдельных компонентов, не объединяя всю логику в один монолитный модуль.
PostgreSQL
PostgreSQL обеспечивает надежное постоянное хранение данных приложения и при необходимости может использоваться в архитектуре векторного поиска с помощью соответствующих расширений, например pgvector.
Использование PostgreSQL позволяет сохранить привычный и удобный в эксплуатации слой хранения данных, одновременно поддерживая требования ИИ-приложения к поиску релевантной информации.
Docling
Docling отвечает за загрузку и обработку документов в системе. Этот инструмент особенно полезен, когда исходные материалы сложнее обычного набора текстовых файлов и содержат различную структуру и типы контента.
Корректное извлечение структуры документов позволяет передавать в систему поиска более чистые и информативные данные, что напрямую влияет на качество последующего поиска релевантного контента.
Groq и Ollama
Мы использовали Groq и Ollama для разных сценариев запуска LLM. Groq подходит для случаев, когда приоритетом является высокая скорость инференса. Ollama, в свою очередь, позволяет запускать совместимые модели локально или в собственной инфраструктуре.
Разделение поиска и генерации также дает возможность развивать и изменять уровень LLM без необходимости перестраивать всю архитектуру загрузки и обработки базы знаний.
Результаты: чего удалось достичь
В результате мы получили экономичную с точки зрения затрат и ресурсов архитектуру клиентской поддержки, которая превращает существующую базу знаний в диалоговый интерфейс. Вместо того чтобы вручную создавать и поддерживать сотни ответов для чат-бота, система использует информацию, которую заказчик уже ведет и обновляет в своих источниках.
Архитектура также дает несколько практических преимуществ:
- Меньше ручной работы с FAQ. Контент для поддержки остается в существующих источниках знаний заказчика.
- Более быстрый доступ к информации. Пользователи могут задавать вопросы в диалоговом формате вместо поиска по нескольким страницам документации.
- Лучшее понимание естественного языка. Пользователю не нужно формулировать вопрос точно так же, как он записан в исходных материалах.
- Синхронизация базы знаний. Изменения на сайте заказчика автоматически передаются в поисковый слой системы.
- Гибкий выбор способа запуска модели. Для генерации ответов можно использовать как облачный инференс, так и локально развернутые модели.
- Переиспользуемая архитектура. Тот же подход можно адаптировать под разные базы знаний и сценарии клиентской поддержки.
При этом некорректно указывать для такого проекта универсальные показатели точности или экономии без подтвержденных данных заказчика. Фактическая эффективность ИИ-системы поддержки зависит от качества исходной документации, настроек поиска, выбранной модели и методики оценки.
Когда готового решения достаточно, а когда нужен собственный чат-бот
Далеко не каждой компании нужен ИИ-чат-бот, разработанный с нуля. В некоторых случаях готового решения или стандартной FAQ-системы вполне достаточно, чтобы автоматизировать ответы на типовые обращения и обрабатывать простые запросы пользователей.
Однако по мере усложнения базы знаний, интеграций или требований к безопасности ограничения готовых продуктов становятся более заметными. Выбор подхода зависит от объема и структуры базы знаний, необходимого уровня адаптации, а также от того, насколько глубоко чат-бот должен быть интегрирован с существующими системами и процессами клиентской поддержки.
Когда готового решения достаточно
Готовый чат-бот или стандартная FAQ-система часто становятся оптимальным выбором, если требования к решению относительно простые. Такой вариант стоит рассмотреть, если:
- FAQ содержит сравнительно небольшое количество вопросов;
- информация обновляется нечасто;
- чат-бот нужно запустить в короткие сроки;
- достаточно стандартных интеграций;
- не требуется собственная логика поиска или обработки запросов;
- предусмотрены простые роли пользователей — например, администраторы контента и обычные пользователи;
- достаточно хранения истории чатов и сообщений;
- использование инфраструктуры и ИИ-моделей поставщика соответствует требованиям компании.
Например, небольшой SaaS-компании с несколькими десятками типовых вопросов, скорее всего, не потребуется собственная RAG-архитектура. Готовый FAQ-чат-бот можно настроить сравнительно быстро и без значительных затрат на разработку, при этом он уже способен обеспечить удобное взаимодействие с пользователями.
Готовые базовые решения также могут стать практичным способом автоматизировать повторяющиеся обращения до перехода к более сложной системе. Если большинство запросов в службу поддержки простые и предсказуемые, такого чат-бота может быть достаточно, чтобы заметно снизить нагрузку на команду.
Когда лучше выбрать заказную разработку чат-бота
Заказная разработка становится более оправданной, когда чат-бот должен работать с существующей инфраструктурой компании и постоянно обновляемой базой знаний. Такой подход стоит рассмотреть, если требуется:
- интеграция с существующей базой знаний или сайтом;
- сложная система ролей и разграничение информации для разных групп пользователей;
- автоматическая синхронизация изменений в документации;
- собственная логика загрузки и обработки документов;
- расширенный семантический или гибридный поиск;
- интеграция с внутренними бизнес-системами;
- локальное или самостоятельно развернутое LLM-решение;
- собственные механизмы аутентификации и управления доступом, включая интеграцию с корпоративной системой аутентификации;
- полный контроль над процессом поиска и генерации ответов;
- контроль расхода токенов;
- аудит действий пользователей и анализ наиболее востребованных тем;
- поддержка сложных или специализированных рабочих процессов.
Заказные решения особенно полезны, когда система должна понимать разные формулировки пользовательских запросов, а не просто сопоставлять их с заранее заданными фразами.
Технологии обработки естественного языка и машинного обучения позволяют чат-боту распознавать разные способы сформулировать один и тот же вопрос и находить информацию, которая лучше всего соответствует намерению пользователя.
Заказной чат-бот также можно интегрировать с клиентскими данными, платформами поддержки и другими бизнес-системами. Например, он может учитывать информацию из предыдущих обращений или истории взаимодействия с клиентом, если при этом соблюдаются необходимые требования к конфиденциальности и разграничению доступа.
Это позволяет сделать взаимодействие с клиентами более персонализированным, а специалистам поддержки сосредоточиться на сложных случаях, где действительно требуется участие человека.
| Требование | Готовое решение | Заказной чат-бот |
| Быстрый первоначальный запуск | ✓ | — |
| Простой FAQ | ✓ | — |
| Ограниченная кастомизация | ✓ | — |
| Небольшая и стабильная база знаний | ✓ | — |
| Большая или сложная база знаний | — | ✓ |
| Автоматическая синхронизация контента | Ограниченно | ✓ |
| Собственная логика поиска | Ограниченно | ✓ |
| Семантический поиск | Зависит от поставщика | ✓ |
| Самостоятельное развертывание LLM | Зависит от поставщика | ✓ |
| Заказные интеграции | Ограниченно | ✓ |
| Собственная аутентификация и управление доступом | Ограниченно | ✓ |
| Полный контроль над инфраструктурой | — | ✓ |
| Специализированные процессы поддержки | Ограниченно | ✓ |
| Работа с конфиденциальными источниками знаний | Зависит от поставщика | ✓ |
| Гибкость в долгосрочной перспективе | Ограниченно | ✓ |
| Меньшие первоначальные затраты на разработку | ✓ | — |
| Аудит и анализ контента | — | ✓ |
| Максимальная адаптация под задачи бизнеса | — | ✓ |
Готовое решение и заказной чат-бот: ключевые различия
FAQ-чат-бот для сотрудников
Ту же архитектуру можно использовать не только для клиентской поддержки, но и для внутренних задач компании. FAQ-чат-бот для сотрудников позволяет в диалоговом формате получать доступ к внутренней документации по HR, IT и операционным процессам.
Вместо поиска информации по нескольким внутренним порталам сотрудник может задать вопрос и получить ответ на основе актуальных корпоративных правил и процедур.
Например:
- «Как оформить отпуск?»
- «Как заменить рабочий ноутбук?»
- «Где найти правила компенсации расходов?»
- «Как получить доступ к нужному внутреннему сервису?»
Базовая RAG-архитектура при этом практически не меняется: внутренние документы загружаются и индексируются, для каждого запроса система находит релевантную информацию, а LLM формирует ответ на основе найденного контекста.
Главное отличие заключается в источниках данных и правилах доступа. Клиентский FAQ-чат-бот должен использовать только публичную информацию, тогда как внутренний чат-бот может работать с конфиденциальной документацией и учитывать права доступа для разных ролей и групп сотрудников.
Для более сложных внутренних ассистентов, которые должны не только отвечать на вопросы, но и работать с несколькими системами и выполнять действия, возможности чат-бота можно расширить за счет разработки ИИ-агентов.
Компаниям со строгими требованиями к конфиденциальности или соответствию нормативным требованиям также могут подойти услуги по разработке частных LLM, которые дают больше контроля над развертыванием моделей и работой с чувствительными корпоративными данными.
Примеры вопросов для FAQ-чат-бота
Ниже приведены примеры вопросов, с которыми может работать чат-бот поддержки на базе RAG. Они сформулированы в обобщенном виде и не являются дословными примерами из переписки с реальными клиентами.
Пример 1: управление аккаунтом
Клиент:
«Как изменить адрес электронной почты в аккаунте?»
Чат-бот:
«Чтобы изменить адрес электронной почты, откройте настройки профиля и укажите новый адрес в разделе с данными аккаунта. Перед сохранением изменений может потребоваться подтвердить новый адрес.»
Пользователю не нужно формулировать вопрос точно так же, как он записан в документации. Чат-бот находит релевантную информацию об управлении аккаунтом и выдает ее в удобном диалоговом формате.
Пример 2: подписка
Клиент:
«Можно ли перейти на другой тариф в середине расчетного периода?»
Чат-бот:
«Изменение тарифа возможно в соответствии с условиями подписки. Доступные варианты и порядок перерасчета зависят от того, какой тариф вы используете сейчас.»
В рабочей версии чат-бот использовал бы актуальную документацию заказчика по подписке, чтобы предоставить конкретные условия и пошаговые инструкции.
Пример 3: устранение неполадок
Клиент:
«После изменения настроек API интеграция перестала работать. Что нужно проверить?»
Чат-бот:
«Сначала проверьте учетные данные API и параметры конфигурации, которые использует интеграция. Если с ними все в порядке, ознакомьтесь с требованиями к подключению и аутентификации в руководстве по устранению неполадок.»
Эти примеры показывают, почему список вопросов и ответов для чат-бота необязательно формировать вручную. Фактическая информация может поступать из исходной документации, а ИИ-уровень адаптирует ее под формулировку конкретного запроса пользователя.