Как сделать RAG для своей компании

По следам:

Как я сделал RAG для своей компании

Как я сделал RAG для своей компании (часть 2). И как начал делать AI Агента

AI агенты — клоны сотрудников (часть 3)

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

Определите список вопросов и сабсет данных

Для успешного создания RAG (Retrieval Augmented Generation) первым делом нужно определить примерный список вопросов, на которые система должна уметь отвечать.

Вариант: у нас есть данные вот там, надо в неё всё загрузить – это плохой подход. Вы не сможете сделать качественную выборку из большого массива разрозненных данных и не сможете настроить хороший промт.

Когда я загрузил в первую версию весь раздел SQA с Wiki, система отвечала очень хорошо.

Когда я загрузил всю Wiki, система стал отвечать очень плохо, в том числе и на вопросы по разделу SQA.

Из списка вопросов становится понятно, какие данные нужны, и мы можем извлечь точечно те данные, которые необходимы. Основной принцип, при котором RAG будет работать лучше, – это консистентный между собой минимально необходимый набор данных.

Примеры:

Качество ответов RAG

Составьте список тестовых вопросов к RAG. Этот список должен отражать основные моменты, которые RAG должен извлекать из выборки данных. Он будет нужен в момент настройки сабсета данных, промпта и прочих параметров LLM. Желательно этот список не менять.

Подготовка данных

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

Простой пример – когда я загрузил всю Wiki в RAG-систему, а там документы за 7–9 лет, система начала выдавать неверные ответы на вопросы. Причина проста – на один вопрос в данных может быть три ответа: один пятилетней давности, другой двухлетней, а третий – этого года.

Как системе понять, где правда, а где нет? Никак – она выберет топ X векторов, и все три ответа скорее всего будут в топ-3. Из них она попробует сделать один ответ, но у неё не получится, например, потому что данные противоречат друг другу.

По идее нужно перед началом проводить:

• Чистку данных (удалять устаревшие и противоречивые документы)

• Разметку и структурирование данных

Это может быть достаточно трудоёмко, это как делать уборку в шкафу или на балконе. Есть способы автоматизации по разметке (NER) и поиску взаимосвязей между документами (graphDB). В любом случае это минимум дни, а скорее недели работы.

Есть очень простой способ, который у меня сработал – просто отрезаем все данные старше X лет. Когда для Wiki я сделал загрузку только документов, которые обновлялись за последние два года, количество документов резко упало (~400 вместо ~3000), а качество ответов резко возросло. По сути, я срезал много неактуального.

Перед загрузкой данных в RAG нужно провести форматирование данных. То есть выполнить очистку от старого формата (например, от HTML, если данные с сайта). Лучше бы еще добавить целевую разметку (например, Markdown). Это часть предварительной обработки, которая преобразует необработанные данные в чистый, согласованный формат, подходящий для эффективного извлечения и использования в RAG-системе.

Если данные содержат личную информацию (например, переписка клиентов с support), то её нужно анонимизировать, то есть заменить на mock-данные или полностью удалить. Удалять или замещать будет зависеть от целей RAG.

Дизайн, разработка и внедрение системы RAG

Здесь всё зависит от ваших потребностей и ограничений. Мы выбрали OpenAI с их AI Assistants и использованием threads, так как компания работает в Европе и Америке.

Если вы находитесь в России, учитывая блокировки и ограничения доступа к зарубежным сервисам, возможно, лучше использовать локальных облачных провайдеров LLM, таких как Яндекс (YandexGPT) и Сбер (GigaChat).

Если вы вообще не хотите передавать никакие данные за контур вашей организации, то можно поставить локальную LLM. В том числе есть решения, которые могут работать на “компьютере вашего бухгалтера“, то есть вам не обязательно иметь мощный сервер с GPU.

Качество работы RAG в первую очередь зависит от качества самих данных и вашего промпта, а в меньшей степени – от выбранной LLM. Для наших целей одинаково хорошо работали Google Gemini, OpenAI и Grok. Для русскоязычных текстов хорошо подходят OpenAI, Gemini, Яндекс и GigaChat.

Этот шаг займет несколько недель, тут нужно будет еще прикрутить интерфейсы к вашим чатам (Slack, Telegram, WhatsUp и т.д.), то есть это интерфейс через который вы будете общаться с RAG. Здесь же может понадобится MCP сервер для обработки и роутинга запросов через ваши интерфейсы.

MCP по сути – это роутер, который асинхронно получает запросы из разных чатов (для каждого чата есть свой адаптер) и направляет их нужной RAG-системе.

Мы реализовали три варианты MCP:

• С роутингом через HTTP (FastAPI) + OpenAI без LangChain

• С роутингом внутри кода + LangChain + Telegram + Slack + OpenAI

• С роутингом внутри кода + LangChain + Telegram + Slack + Yandex/Gigachat

Подготовка и тюнинг промта

Это важная стадия – промт (то есть инструкция для LLM) будет играть вторую по важности роль после самих данных.

Здесь важно использовать один и тот же набор вопросов, чтобы оценивать качество ответов после изменений.

Тут же мы настраиваем параметры модели, такие как:

• Температура (то есть креативность от 0 до 1)

• Top_k (сколько выбрать совпадающих текстов из векторной базы)

• Top_p (жадность выборки токенов, это опять про разнообразие в ответах модели)

Нужно провести множество тестов и подобрать подходящий промпт и параметры для конкретной RAG.

Например, для выборки из Wiki мы сразу поставили температуру в 0, потому что не хотим, чтобы LLM изобретала. Но для клонов сотрудников, с целью сохранения их стиля ответов, мы экспериментально подобрали температуру 0.4, при этом добавили в промт явное указание отвечать «Не знаю», если выборка не находит данных, относящихся к вопросу в истории переписки сотрудника.

Реальные точные промты могут быть размером в несколько страниц.

ИИ-агенты

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

В нашем случае, например, BugBot классифицирует баги в переписке, уточняет детали и затем заводит багу в JIRA через JIRA API.

В рамках MCP-сервера можно создать сущности, которые по сути являются API-интерфейсами, они обычно называются тулами (tools). Если у нас есть, например, три агента, то любой из них может пользоваться существующими тулами, вызывая необходимые функции через стандартизированный интерфейс MCP. 

Про наши эксперименты с ИИ пишем в канале @aigentto. В следующей статье планирую рассказать технические детали описанного и выложить код на github.

Заключение

• Делайте отдельные RAG системы и ИИ-агентов под каждую задачу

• Используйте MCP сервер для роутинга между запросам пользователей, RAG, агентами и тулами

• Очень точно настраивайте промт под задачу

• Используйте LLM под задачу (облачную или локальную)