RAG: корпоративный ИИ, который не ошибается

Представьте ситуацию: новый инженер выходит на работу. Первые несколько дней он пытается разобраться в том, как устроены процессы. Он понимает, что нужная информация где-то есть — в Confluence, в Google Drive, в тикетах Jira, в Slack-тредах годичной давности. Но он не знает ни структуры пространств, ни имен авторов, ни кодовых названий проектов: ищет, не находит, спрашивает коллег, те отвечают по памяти и часто с ошибками — такой себе онбординг.

Классический выход — корпоративный портал, единая база знаний, регламенты в Confluence. Но чем больше и динамичнее компания, тем быстрее такие системы превращаются в кладбища документов: формально все есть, фактически — никто этим богатством не занимается и не пользуется, поэтому найти нужное невозможно. Отсюда повсеместная практика задавать вопросы причастным и создавать решение заново.

У нас в WB‑Tech было так-же, пока мы не попробовали ИИ для работы с внутренним контекстом. Эта статья о преимуществах такого решения, путях реализации и результатах нашего опыта. Спойлер: мы в восторге!

Что такое RAG

Как работает интеллектуальный поиск

Примеры RAG: кейсы и цифры

Почему умный корпоративный поиск выгоднее, чем переученная модель

Где RAG реально меняет процессы

Безопасность — не надстройка, а фундамент

RAG, ИИ и WB-Tech: а как у нас

RAG, как новый слой корпоративной инфраструктуры

RAG — Retrieval-Augmented Generation, «генерация с поиском» — это подход, при котором языковая модель в первую очередь ищет ответ в актуальной базе данных компании.

Большие языковые модели (LLM). GPT-4, Llama, Mistral обучаются на огромных массивах данных из интернета. В результате они много знают об устройстве мира и умеют писать код, но слабо понимают, как устроены процессы в вашей компании, каков ее внутренний регламент и как зовут ответственного за инфраструктуру в московском офисе.

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

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

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

Начинается всё с подключения источников. Это могут быть Confluence и Jira, Google Drive, Slack, GitHub, GitLab и другие сервисы, в которых ваши сотрудники каждый день создают документы, обсуждают решения и фиксируют рабочий контекст. Система собирает эти материалы и систематизирует, чтобы с ними было удобно работать.

Важно! Базу необходимо поддерживать в актуальном состоянии. Новые документы должны попадать в нее автоматически и сразу, а устаревшие или удалённые — переставать влиять на ответы. Иначе искусственный интеллект станет опираться не на текущее состояние компании, а на архивную версию реальности.

Дальше, поиск — это то, что происходит в момент, когда пользователь обращается к базе. Система преобразует запрос в вектор и ищет ближайшие по смыслу фрагменты. Современный подход чаще предполагает гибридный вариант, когда классический поиск по ключевым словам (BM25) комбинируется с векторным поиском по смыслу.

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

Поверх описанной логики всегда работает безопасность. Правильная RAG-система обязана учитывать права доступа, тщательно хранить от лишних глаз закрытые документы и вести логи. Для бизнеса это один из ключевых моментов: корпоративный ИИ должен не только искать, но делать это без риска для внутренней информации. Именно поэтому в корпоративных сценариях нередко используют self-hosted модели (расположенные на собственных серверах) — они значительно сокращают риски передачи конфиденциальных данных посторонним.

Крупнейший публичный пример RAG в энтерпрайзе — Microsoft 365 Copilot. Microsoft описывает его архитектуру через semantic index: Copilot строит лексический и семантический индекс по данным организации и использует его как основу для поиска релевантного контекста в SharePoint, OneDrive, Teams, Exchange и других источниках Microsoft 365. При этом Copilot сохраняет ту же модель доступа, что и остальная экосистема Microsoft 365: если у сотрудника нет прав на файл или письмо, система не должна использовать этот контент при формировании ответа.

На уровне исследований картина тоже показательная. Медицинский RAG-фреймворк MEGA-RAG, разработанный для работы с клиническими данными, продемонстрировал снижение частоты галлюцинаций более чем на 40% по сравнению с базовыми LLM-моделями и стандартными RAG — при одновременном улучшении точности и полноты ответов.

В онкологической информатике использование RAG с верифицированными источниками резко снизило количество ложных утверждений и увеличило долю ответов в формате «данных недостаточно» — что само по себе значительно честнее, чем уверенная выдумка. Поиск по проверенным источникам дает галлюцинации лишь в 2% ответов, тогда как чат-бот с Google-поиском показывает 18%, а обычный генеративный чат-бот — 39%!

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

Когда в компании впервые задумываются о собственном корпоративном ИИ, часто звучит вопрос: а может, просто дообучить модель на наших данных? Дообучение (fine-tuning) — мощный инструмент, но попытки прикрутить его к бизнес-процессам связаны с ограничениями.

Во-первых, любая адаптация модели под новые условия — это всегда снимок знаний на момент оптимизации. Как только появляются новые регламенты, решения по архитектуре или обновленные продукты — модель снова устаревает, и нужен новый цикл обучения. Если бизнес динамичен — это становится проблемой: поддержание актуальности базы требует постоянных вложений в ML-инфраструктуру, сбор датасетов и мониторинг деградации.

Логика RAG элегантнее: знания хранятся в индексе отдельно от модели. Добавили документ — ИИ-ассистент сразу начинает его использовать, удалили устаревшую политику — она перестала влиять на ответы. Никакого переобучения и связанных с ним расходов.

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

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

Проще говоря, дообучение полезно там, где нужно изменить стиль, формат или поведение модели. Но если задача компании — дать ИИ доступ к актуальным знаниям, внутренним документам и рабочему контексту, то RAG в большинстве случаев оказывается более удобным, прозрачным и жизнеспособным решением.

Самый очевидный сценарий — онбординг. Новый сотрудник больше не бесит коллег элементарными вопросами и не выпадает из рабочего процесса на полдня, погружаясь в «картографию» Confluence, а идет, например, в Slack, где получает мгновенный и точный ответ с ссылками на источники. «Как у нас ведётся согласование технических решений?», «Где шаблон postmortem?», «Кто отвечает за CI/CD в проекте X?» «Когда обед?» — RAG-система отвечает за секунды.

Поддержка первого уровня — и внутренняя (helpdesk, IT-support), и внешняя (клиентская) — страдает от одной и той же болезни: масса повторяющихся вопросов, вынуждающих оператора или админа тратить время на поиск и ответ. RAG-бот, обученный на базе знаний и тикетах, способен автоматически закрывать до 80% типовых обращений, всегда ссылаясь при этом на актуальные документы, а не придумывая ответ по памяти.

Отдел разработки получает ассистента, который знает именно вашу кодовую базу, архитектуру и обсуждения. И это не просто GitHub Copilot с автодополнением — это система, которая может ответить, почему принято то или иное решение, где это зафиксировано, кто это обсуждал. Это как разница между общим списком FAQ для гостей и предметным диалогом с человеком, который глубоко в теме.

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

Любой серьезный разговор об умном поиске в корпоративной среде рано или поздно упирается в тему безопасности. Подключить базы знаний к ИИ и дать ему доступ к внутренним данным — это же огромный риск! Да, если делать как попало. Однако с правильным проектированием RAG-система так же безопасна, как компьютер, физически отключенный от сети.

Современный ландшафт угроз для RAG-систем хорошо известен:

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

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

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

Хорошая RAG-система, по нашему мнению, начинается не с модели, а с правильного выбора источников. На первом этапе имеет смысл подключать только те инструменты, в которых обычно концентрируются рабочие знания: продукты Atlassian (Confluence, Jira), Google Workspace (Docs, Drive), Slack и репозитории — как облачный GitHub, так и self-hosted GitLab. Это не исчерпывающий список, вы можете использовать свой вариант, главное здесь не бренд, а способность инструмента обрабатывать необходимый именно вам объем контента.

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

Интерфейс: если персонал уже в нем, лучше оставить как есть, ограничившись минимально необходимыми изменениями. Пример нашего подхода — slash-команда в Slack: пользователь написал запрос, бот ответил в треде текстом, при необходимости прикрепив список ссылок на найденные артефакты. Никакого отдельного фронтенда, никакого обучения. Чем меньше новых действий требует система, тем выше шанс, что ею реально будут пользоваться.

И главное — не пытайтесь объять необъятное! Цель — сделать не идеального чат-бота, а получить надежный рабочий инструмент: который хорошо ищет, не выдумывает то, чего нет, всегда знает источники и не провоцирует дыры в безопасности.

RAG — это не экспериментальная технология из академических статей и не инструмент, доступный исключительно компаниям с огромными ML-командами. Это зрелый подход, который уже сегодня применяется в самых разных отраслях — от IT и финансов до ритейла и юриспруденции. Единственное ограничивающее условие для его внедрения — наличие накопленного контекста: документов, процессов, знаний, которые уже есть в компании.

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

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