RAG вместо GPT: как мы сделали внутреннего ассистента для корпоративных данных

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

Мы построили внутренний RAG-ассистент в закрытом контуре: изоляция данных, контроль доступа, бенчмарки качества и долгая  работа с вендором. В статье — архитектура, переговоры  с вендором, ошибки ^[1], компромиссы и выводы для тех, кто думает о корпоративном ИИ всерьёз.

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

Откуда возникла задача

Если коротко — мы хотели, чтобы сотрудники перестали тратить много времени на поиск информации.

Так появился Croc Assistant For You (CAFY) — внутренний ассистент по корпоративным документам: он ищет не конкретные слова, а находит подходящие по смыслу фрагменты и с их помощью формирует контекст.

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

До запуска ассистента у нас уже были крупные корпоративные системы, в которых хранились знания. Они используются для ведения проектной деятельности, хранения документации и нормативных материалов. У каждой из этих систем есть встроенный поиск. Более того, мы пытались его донастраивать.

Проблема была в том, что информация распределена по нескольким системам. У каждой — своя логика ^[2] хранения, своя структура, свой поиск. Объединить это в одном инструменте на уровне существующих решений не получалось.

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

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

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

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

Отдельно стоял вопрос чувствительности данных. Речь идёт о внутренних документах, которые по разным причинам нельзя выносить во внешние сервисы. Поэтому всё разворачивали внутри компании. Данные не передаются вовне, доступ к ним ограничен, а сама архитектура построена так, чтобы снизить риск утечек.

Нам нужен был не «ИИ ради тренда», а управляемый корпоративный ассистент, который объединяет разрозненные знания компании и позволяет работать с ними быстрее и точнее.

Почему RAG и почему сейчас

Что мы понимаем под RAG в этой статье: мы индексируем внутренние документы (формируем поисковый/векторный индекс), извлекаем релевантные фрагменты и только их отдаём в LLM, чтобы она собрала ответ. Модель работает с нашим контекстом, а не «знает всё сама».

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

Ключевым ограничением «классических» чат-ботов и GPT-подобных решений в корпоративной среде стала чувствительность информации. Передача данных во внешний контур, даже при формальных гарантиях, мы считали риском. Важны были не только вопросы хранения, но и сам факт контроля над инфраструктурой: система должна разворачиваться внутри компании, работать на собственных мощностях и не отдавать данные третьим сторонам.

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

RAG оказался самым практичным под эти ограничения, потому что позволял:

• хранить документы внутри инфраструктуры;

• извлекать релевантный контекст вместо «скармливания» всего массива;

• контролировать индексацию и выдачу;

• снижать риск галлюцинаций за счёт опоры на источники.

Когда стало ясно, что нам нужен управляемый доступ к знаниям в закрытом контуре, выбор в пользу RAG оказался очевидным.

Как это выглядело на практике

Если говорить не в общем, а на уровне повседневной работы, у сотрудников было несколько типовых проблем.

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

Вторая —  сложность самого поиска. Классический поиск умеет находить и документы, и конкретные места в них, но опирается на точные совпадения слов. Если формулировка запроса не совпадает с текстом, нужный фрагмент легко «теряется».

CAFY задумывался как поиск по смыслу: не «найти файл», а «найти нужное место в документе», даже если запрос сформулирован иначе.

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

Отдельный слой сложности — сами источники знаний.

Где RAG спотыкается в реальных данных

На практике сложнее всего оказались следующие типы источников:

• вики-страницы с разметкой и вложенной структурой;

• сложная ролевая модель доступа;

• документы с таблицами и числовыми данными;

• страницы с визуальной структурой (схемы, оргструктуры);

• PDF с графикой и текстом в виде изображений.

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

Мы недооценили объём ручной работы на этапе чистки данных. Это стало ясно только после первых индексаций.

Визуальные структуры. Модель не видит граф связей. После индексации оргструктуры LLM может путать департаменты и руководителей, потому что визуальные отношения для неё неочевидны.

Таблицы и числа. Без специализированных инструментов LLM нестабильно справляется с вычислениями и агрегацией. Один и тот же запрос к Excel может давать разные ответы от запуска к запуску.

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

Ролевая модель доступа. ACL в разных системах реализован по-разному и может быть очень гибким. При индексации пользователь должен видеть только те данные, к которым имеет доступ в исходной системе. Из-за этого для части источников мы отказались от совместных ассистентов и перешли к персональным — изоляция оказалась важнее удобства.

Попытки централизации до этого

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

Поиск документа, а затем поиск внутри него превращались в отдельную задачу. В какой-то момент стало ясно: дело не в «плохом поиске», а в самом подходе к хранению и навигации по большим массивам знаний.

Что было бы, если ничего не менять

Если оставить всё как есть, проблема продолжала бы расти. Количество артефактов увеличивается, пространства разрастаются, и вместе с этим растут трудозатраты на поиск. 

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

Какие ограничения задали архитектуру

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

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

Что нельзя было нарушить:

• всё разворачивается внутри компании;

• никаких внешних сервисов для чувствительных данных;

• права доступа должны совпадать с исходными системами;

• данные должны сохраняться, а инфраструктура — быть под нашим контролем.

Некоторые решения пришлось пересматривать по ходу проекта.

Изначально предполагалось, что точкой входа станет только корпоративный мессенджер на базе Express — единый закрытый интерфейс внутри периметра. Логично, безопасно, контролируемо (на первый взгляд).

Что пошло не так с единой точкой входа

Как всегда практика внесла коррективы. У сотрудников были разные привычки, и переход на единый канал оказался не мгновенным.

Поэтому на этапе тестирования мы открыли веб-доступ через браузер. Это был временный шаг, чтобы снизить порог входа и быстрее собрать обратную связь. С самого начала его рассматривали как инструмент пилота, а не как финальное решение.

Если обобщить, архитектуру определили не технологические амбиции, а ограничения:

• чувствительность данных;

• строгая модель доступа;

• управляемость решения;

• ускорение работы, а не внедрение «ИИ ради ИИ».

Дальше все инженерные решения принимались уже внутри этих рамок.

Выбор платформы: почему не стали писать всё сами

Мы, конечно, пробовали делать RAG самостоятельно. Внутри компании собирались прототипы, на это ушло немало ресурсов.

Довольно быстро стали понятны две вещи.

Во-первых, полноценный RAG — это отдельная специализация. Компании, которые делают такие продукты, фокусируются конкретно на этом решении. Это не просто «поднять модель и прикрутить векторную базу».

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

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

Как выбирали вендора

Мы тестировали несколько решений. Смотрели не на презентации, а на поведение ^[3] системы в реальных сценариях.

Критерии были простыми:

• скорость внедрения и наличие интеграций;

• условия пилота;

• качество ответов на наших тест-кейсах.

Для оценки мы подготовили собственные наборы документов и список типовых вопросов. По ним измеряли качество.

Интересный момент: при on-prem-развёртывании результаты почти всегда были чуть хуже, чем на облачных стендах. Причина — различия в моделях, конфигурации и доступных вычислительных ресурсах. Это пришлось учитывать при выборе.

Работа с «чёрным ящиком»

Даже после выбора RAG-платформы основная инженерная работа только начиналась.

Архитектуру мы проектировали параллельно с исследованием рынка. После покупки «коробки» пришлось:

• настраивать интеграции с внутренними системами;

• организовывать передачу файлов;

• подключать корпоративный мессенджер;

• выстраивать весь контур вокруг RAG-ядра.

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

Что оказалось больнее всего в «коробке»:

• апдейты, которые меняли качество (метрика 85% — 70%);

• непрозрачная логика связки RAG — LLM;

• конфликт ^[4] ожиданий пользователей с природой ранжирования.

К концу года стало ясно: коробка для нас — это «чёрный ящик». Мы не могли управлять тем, как именно RAG взаимодействует с LLM.

Поэтому попросили реализовать дополнительный интерфейс между RAG и моделью. Это позволило забирать найденный контекст и самостоятельно решать, в какую LLM его отправлять и как обрабатывать дальше.

Так система перестала быть жёстко привязанной к одной встроенной модели.

Самая сложная часть — не код

Неожиданно самым сложным оказалась не техника, а процессы.

Обновления, которые вендор выпускал для других клиентов, могли влиять на наше качество. Пришлось выстроить:

• регулярные статусы;

• прозрачность поставок;

• понятную схему согласования изменений.

Отдельная сложность — ожидания пользователей.

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

Эти кейсы приходилось разбирать отдельно — и внутри команды, и с вендором.

В итоге работа с вендором превратилась не в покупку коробки, а в совместную эволюцию ^[5] решения. С итерациями, метриками, откатами версий и постоянной обратной связью. Именно в этом формате система и дошла до рабочего состояния.

Архитектура внутреннего RAG-ассистента

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

Первый архитектурный вызов — интерфейс для пользователя. Логичным вариантом выглядел Telegram: мобильный мессенджер, привычный формат диалога. Но Telegram — внешняя система, а значит, сообщения сначала попадают на его серверы. Для нас это неприемлемо. Поэтому точкой входа стал корпоративный мессенджер, построенный на базе Express. Вся коммуникация остаётся внутри компании.

Два контура: создание и диалог

Дальше возникла необходимость разделить процессы создания ассистента и работы с ним. Мы реализовали два контура.

Первый контур — система управления ассистентами (СУА). Через бот в корпоративном мессенджере пользователь может создать ассистента, передать ссылку на корпоративный портал, ссылку на пространство в базе знаний или прикрепить файлы. Данные сначала поступают в СУА. Там проверяются права доступа, запускаются соответствующие парсеры, формируются файлы для индексирования. Только после этого данные отправляются в RAG-движок. Когда индексация завершена, пользователь получает уведомление и может начинать работу.

Второй контур — диалоговый. Чат подключён к нашей корпоративной шине взаимодействия с LLM (единая точка API для работы с языковыми моделями). Бот в корпоративном мессенджере передаёт запрос в шину; далее через неё вызывается LLM, а RAG-движок предварительно извлекает релевантный контекст и передаёт его вместе с запросом в модель. При этом СУА дополнительно проверяет права доступа пользователя к данным, с которыми работает ассистент.

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

Коннекторы и предобработка

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

Мы сознательно не отдавали обработку ссылок и структур данных на откуп ядру RAG, чтобы не перегружать его. Предварительная обработка происходит в отдельных сервисах, после чего в индексатор передаются уже подготовленные данные.

ACL и изоляция данных

Используемый RAG-движок не реализует полноценную корпоративную ролевую модель с учётом сложных ACL, поэтому контроль доступа и проверка прав были вынесены в отдельный слой. 

Когда пользователь создаёт ассистента, СУА фиксирует его права в исходной системе. При каждом обращении к ассистенту снова проверяется, есть ли доступ к соответствующим данным. Если нет — ответа не будет.

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

Качество и эксплуатационные ограничения

Со временем возник «зоопарк» ассистентов: у сотрудника могло быть несколько корпоративных и личных — под разные проекты. Чтобы пользователь не вспоминал вручную, какой ассистент к чему относится, мы реализовали ранжирование: СУА определяет доступных ассистентов, затем ядро оценивает релевантность их коллекций/индексов по семантическому сходству (эмбеддинги), и пользователю предлагается наиболее подходящий набор.

Качество ответов контролируется через бенчмарки. Мы формируем эталонные документы и вопросы, прогоняем систему по этим сценариям и измеряем метрику качества. Сначала ответы сравнивались вручную, затем эту функцию взяла на себя отдельная LLM, сличающая фактический ответ с ожидаемым по заданным критериям. По результатам корректируются параметры индексирования и работы ядра, а пользовательские кейсы пополняют библиотеку тестов.

Отдельное архитектурное решение касалось структуры хранения. Идея единой коллекции выглядела эффективно, но несла риск некорректного разграничения доступа. В итоге мы выбрали модель изолированных коллекций: это менее оптимально с точки зрения ^[6] дублирования данных, но безопаснее.

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

С точки зрения инфраструктуры ограничений по ресурсам не возникло: в опытной эксплуатации загрузка вычислительных мощностей не превышала 30%, а архитектура изначально рассчитана порядка на три тысячи ассистентов. Пока мы к этим значениям не приблизились, поэтому масштабирование не является узким местом.

Точка входа в систему

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

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

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

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

Главные грабли проекта

• Начать с технологии, а не с потребности ^[7]. Почти гарантированный способ получить дорогую систему с низким использованием.

• Ожидать от RAG «полного поиска». RAG ранжирует вероятные фрагменты и не гарантирует полный перечень всех вхождений.

• Недооценить ACL. Если не вынести контроль доступа в отдельный слой, можно быстро столкнуться с рисками утечки внутри контура.

• Считать коробку готовым решением. Без архитектурного слоя вокруг RAG (коннекторы, изоляция коллекций, бенчмарки) продукт остаётся слабо управляемым: сложно контролировать качество ответов, изолировать данные и понимать, как система ведёт себя в разных сценариях.

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

Планы по развитию и выводы

Изначально проект делали под ограничения — безопасность, доступы, управляемость. И развивался он не потому, что «так делают все», а потому что появлялись конкретные задачи.

Архитектура формировалась вместе со сценариями: это сразу задало фокус: не «игрушка с ИИ», а система под реальные задачи.

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

Следующий шаг — подключение структурированных данных: SQL, CRM и других внутренних систем. Параллельно — полноценная поддержка сложной ролевой модели корпоративного портала.

Архитектуру при этом приходится синхронизировать с изменениями у вендора — так, чтобы не ломать безопасность и модель доступа.

Интересно, как вы решаете похожие задачи у себя: строите вокруг RAG отдельную архитектуру или используете коробочные решения как есть? Где в итоге оказалось больше боли ^[8] — в качестве ответов, доступах или интеграции с источниками?