RAG (Retrieval Augmented Generation) - Это система, которая добавляет знания вашей компании к нейросети и может отвечать на ваши внутренние вопросы.
По следам:
Как я сделал RAG для своей компании
Как я сделал RAG для своей компании (часть 2). И как начал делать AI Агента
AI агенты — клоны сотрудников (часть 3)
В этой статье я постараюсь суммировать свой опыт, подвести итоги и предоставить верхнеуровневую картину решения.
Определите список вопросов и сабсет данных
Для успешного создания RAG (Retrieval Augmented Generation) первым делом нужно определить примерный список вопросов, на которые система должна уметь отвечать.
Вариант: у нас есть данные вот там, надо в неё всё загрузить - это плохой подход. Вы не сможете сделать качественную выборку из большого массива разрозненных данных и не сможете настроить хороший промт.
Когда я загрузил в первую версию весь раздел SQA с Wiki, система отвечала очень хорошо.
Когда я загрузил всю Wiki, система стал отвечать очень плохо, в том числе и на вопросы по разделу SQA.
Из списка вопросов становится понятно, какие данные нужны, и мы можем извлечь точечно те данные, которые необходимы. Основной принцип, при котором RAG будет работать лучше, - это консистентный между собой минимально необходимый набор данных.
Примеры:
Задача | Набор данных | Ожидаемый качество ответов RAG |
Онбоардинг команды X в компанию | HR инструкции по онбордингу + список вопросов/ответов HR от сотрудников во время онбординга | Высокое |
Классификатор багов приходящих от пользователей | Вопросы и ответы пользователем за последние 6 месяцев | Высокое |
Клон сотрудника, для ответов по темам которыми он занимался | Переписка сотрудника | Очень высокое |
Отвечать на все вопросы по Wiki | Вся Wiki | Низкое |
Помогать сотрудникам по любым вопросам | ? | Низкое |
Отвечать на все вопросы клиентов | Переписка с клиентами за последние 6 мес | Среднее |
Обрабатывать запросы клиентов по цене | Скрипты продажников + переписка продажников за последние 3 мес. | Высокое |
Качество ответов 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 под задачу (облачную или локальную)
