Архитектура RAG-бота: как настроить нейросеть для ответов по внутренним документам
VC.ru AI · оригинал
Материал подготовлен автоматизированной редакционной системой. Факты можно сверить по указанному первоисточнику.
Материал описывает техническую реализацию Telegram-бота, использующего технологию RAG для поиска информации в корпоративных базах знаний. Статья детализирует выбор стека технологий, алгоритмы обработки документов и критерии контроля качества ответов.
Технология RAG позволяет интегрировать актуальные внутренние данные компании в работу LLM, снижая риск галлюцинаций и обеспечивая прозрачность источников. Понимание архитектурных решений, таких как векторный поиск и валидация ссылок, критически важно для разработчиков, внедряющих ИИ-ассистентов в бизнес-процессы.
Внедрение искусственного интеллекта в корпоративные процессы часто сводится к созданию ассистентов, способных отвечать на вопросы по внутренним базам знаний. В основе такой системы лежит технология RAG (Retrieval-Augmented Generation), которая предполагает двухэтапный процесс: сначала система ищет релевантные фрагменты информации в базе данных, а затем генерирует ответ на их основе. Такой подход позволяет нейросети опираться на проверенные факты компании, а не только на общие знания из предобучения.
Для реализации такого Telegram-бота рекомендуется использовать современный стек технологий. В качестве основы выступает Python версии 3.11 или выше в связке с библиотекой aiogram 3 для работы с мессенджером. Хранение векторных представлений документов осуществляется через локальный режим Qdrant, что упрощает деплой. Генерация эмбеддингов выполняется с помощью FastEmbed и модели intfloat/multilingual-e5-large, обеспечивающей поддержку мультиязычности. Хотя LlamaIndex может использоваться для загрузки и нарезки документов, логика поиска и сборки финального ответа реализуется вручную для большей гибкости. Языковая модель подключается через OpenRouter, а весь сервис запускается в контейнеризированной среде Docker Compose.
Ключевым аспектом является правильная подготовка данных. Исходные документы сохраняются в отдельной директории, что позволяет пересоздавать индекс без повторного скачивания файлов. HTML-контент конвертируется в текст с сохранением структуры заголовков и списков. Документация нарезается на фрагменты размером около 500 токенов с небольшим перекрытием для сохранения контекста. Каждый фрагмент снабжается метаданными: названием документа, ссылкой, датой и типом источника. Для обеспечения идемпотентности процесса обновления идентификаторы фрагментов генерируются детерминированно, чтобы повторная загрузка перезаписывала старые данные, а не создавала дубликаты.
Алгоритм работы бота при получении запроса включает несколько шагов. Сначала языковая модель переформулирует вопрос пользователя в два-три поисковых запроса. Система выполняет поиск и собирает от 20 до 25 кандидатов. Лучшие фрагменты вместе с их метаданными передаются обратно в LLM, которая формирует ответ строго на основе предоставленных данных, вставляя ссылки на источники. Если релевантной информации не найдено, бот возвращает фиксированное сообщение об отсутствии ответа. Важным этапом безопасности является проверка всех ссылок в ответе: они должны вести только на разрешенные домены компании.
Разработчикам предостерегают от ряда типичных ошибок. Не рекомендуется индексировать сырые сообщения из чатов; вместо этого следует извлекать из переписки отдельные факты с указанием авторов. Также нельзя добавлять в базу вопросов к боту и его собственных ответов, чтобы избежать цикличности. Слишком малое количество кандидатов на этапе поиска (например, 5 штук) часто приводит к тому, что нужный документ не попадает в выдачу. Переранжирование результатов следует включать только после тщательного тестирования, так как оно может замедлять ответ и исключать релевантные фрагменты.
Для повышения безопасности взаимодействия с LLM найденные фрагменты и вопрос пользователя оборачиваются в отдельные теги, а модели явно указывается, что это данные, а не команды. Контроль качества обеспечивается созданием набора из 15–20 реальных вопросов с известными правильными ответами, включая кейсы, где ответа в базе нет. Автоматизированный скрипт прогоняет этот набор через бота, а отдельная модель-судья оценивает полноту, релевантность и корректность источников. Такой подход позволяет отслеживать деградацию качества при каждом изменении конфигурации.