Как подключить AI-агента к базе знаний через RAG

Запросы в духе «сделайте нам чат-бота по внутренним регламентам» перестали быть экзотикой: и коробочные платформы, и open-source обвязки позволяют собрать такого помощника за дни, а не месяцы. Суть у всех решений одна — RAG[1]: перед тем как ответить, модель ищет релевантные куски ваших документов и отвечает уже на их основе. Это отсекает часть галлюцинаций и позволяет держать данные у себя, не заливая их в дообучение чужой модели. Ниже — как это устроено, из чего выбирать и во что обходится.

Что такое агент по базе знаний и чем он отличается от обычного чата

Обычная модель отвечает из того, что запомнила при обучении. Она не знает вашего регламента отпусков за 2024 год и честно это не признает — придумает правдоподобный ответ. Агент[2] с доступом к базе знаний работает иначе: получив вопрос, он сначала ищет подходящие фрагменты в ваших файлах, а потом просит модель ответить строго по найденному, приложив ссылки на источники.

Практическая разница в двух вещах. Первое — актуальность: обновили документ, переиндексировали, ответы поменялись без переобучения. Второе — проверяемость: если ассистент возвращает цитату и ссылку на страницу PDF, его ответ можно проверить за десять секунд, а не поверить на слово.

Три способа собрать такого агента

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

• Коробочные ассистенты с загрузкой файлов. ChatGPT (кастомные GPT и Projects), Claude Projects, NotebookLM от Google. Загружаете документы через интерфейс, спрашиваете. Ничего программировать не надо, но данные уходят к провайдеру, а объём и типы файлов ограничены.
• Платформы для сборки без глубокого кода. Например, конструкторы на базе API OpenAI, Azure AI Search или готовые low-code-инструменты. Больше контроля над источниками и правами доступа, но нужен человек, который это настроит и будет поддерживать.
• Свой стек на open-source. Фреймворк вроде LlamaIndex или LangChain, векторная база (Qdrant, Weaviate, pgvector), модель — облачная по API или локальная. Максимум контроля и приватности, максимум работы и требований к команде.

Сравнение подходов

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

Как это подключить: шаги

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

1. Соберите документы в одном месте. Регламенты, инструкции, FAQ, база тикетов. Уберите устаревшие версии — иначе агент будет цитировать отменённый приказ.
2. Разбейте на фрагменты (chunking). Документы режут на куски по несколько сотен слов с перекрытием. Слишком крупные куски снижают точность поиска, слишком мелкие теряют контекст. В коробочных решениях это делается автоматически.
3. Постройте эмбеддинги и индекс. Каждый фрагмент превращается в вектор и кладётся в векторную базу. На своём стеке это отдельный шаг, в платформах — часть загрузки.
4. Настройте поиск и промпт. На запрос система достаёт top-k релевантных фрагментов и передаёт их модели с инструкцией «отвечай только по этим данным, если ответа нет — так и скажи».
5. Добавьте ссылки на источники. Обязательный пункт: без цитат ответам нельзя доверять, а с цитатами их можно проверять.
6. Проверьте на реальных вопросах. Соберите 30-50 типовых запросов сотрудников и прогоните. Смотрите не только на верные ответы, но и на то, честно ли агент отказывается, когда данных нет.

Главный признак хорошо настроенного агента — не идеальные ответы, а честное «в базе знаний этого нет». Ассистент, который никогда не признаёт незнания, опаснее отсутствия ассистента.

Приватность и доступ: где чаще всего ошибаются

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

Вторая — не проверить, что провайдер делает с загруженными данными. У корпоративных тарифов API обычно есть условие, что данные не используются для обучения, но это нужно читать в договоре и политике конкретного сервиса, а не предполагать по умолчанию.

Кому это пригодится, а кому нет

Пригодится:

• Поддержке и HR, которые отвечают на одни и те же вопросы по регламентам сотни раз в месяц.
• Компаниям с большой, но разрозненной документацией, где найти нужный пункт вручную дольше, чем спросить.
• Онбордингу новичков: агент отвечает на «а как у нас принято» без отвлечения коллег.

Скорее не пригодится:

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

Сколько это стоит

Три статьи затрат: вызовы модели (оплата за токены при облачном API либо серверы под локальную модель), векторная база (open-source бесплатны, управляемые облачные — по подписке) и труд на настройку и поддержку. Коробочные ассистенты укладываются в стоимость обычной подписки на сервис. Цены и на подписки, и на токены меняются каждые несколько месяцев — актуальные смотрите на страницах тарифов провайдеров, а не в обзорах полугодовой давности.

[1] RAG (Retrieval-Augmented Generation) — подход, при котором модель перед ответом ищет релевантные фрагменты в вашей базе и генерирует ответ на их основе, а не только из того, что запомнила при обучении.

[2] Агент — программа поверх языковой модели, которая не просто отвечает текстом, а выполняет шаги: ищет данные, вызывает инструменты, проверяет результат и решает, что делать дальше.