В крупных компаниях поиск информации технически работает, но на практике сотрудники тратят часы, пытаясь вспомнить формулировки, названия документов и места хранения. Мы решили эту проблему, создав внутреннего RAG-ассистента в закрытом контуре — с изоляцией данных, контролем доступа и строгой архитектурой. В статье — как это работает, какие ошибки мы совершили и что получилось в итоге.
До внедрения RAG компания функционировала, но медленно. Это не история про «без ИИ всё рушится», а про оптимизацию: сокращение времени на рутинный поиск и навигацию по массивам знаний.
Откуда возникла задача
Мы хотели, чтобы сотрудники перестали тратить часы на поиск нужной информации. Так появился Croc Assistant For You (CAFY) — внутренний ассистент, который ищет не по словам, а по смыслу. Он находит релевантные фрагменты и формирует на их основе ответ.
CAFY поддерживает подключение групповых и личных хранилищ. Источники — регламенты, методички, договоры, проектная документация, артефакты рабочих групп. Система создавалась для всех сотрудников, а не для одного департамента.
У нас уже были корпоративные системы с встроенным поиском. Но информация распределена по разным платформам — у каждой своя структура, логика хранения и интерфейс. Объединить их на уровне существующих решений не получалось.
Почему обычный поиск перестал работать
Точечные улучшения поиска в отдельных системах не давали эффекта. Главная проблема — люди не всегда помнят точные формулировки. Они помнят смысл, но не ключевые слова. Обычный поиск не справляется с этим: он ищет совпадения, а не понимает контекст.
Нам нужен был инструмент, который работает по смыслу. Можно описать задачу — и получить нужный фрагмент, даже если не помнишь название документа.
Ещё важнее был вопрос безопасности. Внутренние документы нельзя передавать во внешние сервисы. Поэтому всё разворачивалось внутри компании: данные не покидают периметр, доступ строго контролируется, а архитектура минимизирует риски утечек.
Цель была не «ИИ ради тренда», а управляемый корпоративный ассистент, который объединяет разрозненные знания и ускоряет работу с ними.
Почему RAG и почему сейчас
Под RAG мы понимаем: индексация внутренних документов, извлечение релевантных фрагментов и передача только их в LLM для генерации ответа. Модель работает с нашим контекстом, а не «знает всё сама».
На старте рассматривали прямую загрузку документов в LLM. На малых объёмах это работало, но при росте данных возникли проблемы: ограничение контекстного окна, нестабильность ответов, невозможность гарантировать охват источников. Для корпоративных массивов такой подход непрактичен.
Ключевое ограничение — чувствительность данных. Передача во внешние сервисы, даже с гарантиями, считалась риском. Нам нужен был полный контроль: размещение внутри компании, работа на своих мощностях, отсутствие передачи данных третьим сторонам.
Важны были:
- сохранность данных;
- конфиденциальность;
- разграничение доступа — сотрудник видит только то, к чему у него есть права.
RAG оказался самым подходящим решением, потому что позволяет:
- хранить документы внутри инфраструктуры;
- извлекать только релевантный контекст, а не «скармливать» весь массив;
- контролировать индексацию и выдачу;
- снижать риск галлюцинаций за счёт опоры на источники.
Когда стало ясно, что нужен управляемый доступ к знаниям в закрытом контуре, выбор в пользу RAG стал очевидным.
Как это выглядело на практике
У сотрудников было несколько типовых проблем.
Разрозненность данных. Информация лежит в разных системах: корпоративных порталах, подразделенческих пространствах. Нет единой точки входа — нужно сначала понять, где искать.
Сложность поиска. Классический поиск требует точных совпадений. Если формулировка запроса не совпадает с текстом, нужный фрагмент теряется.
CAFY задумывался как поиск по смыслу: не «найти файл», а «найти нужное место в документе», даже если запрос сформулирован иначе.
Человек не всегда помнит, что ищет. Есть ощущение, что информация где-то есть, но не вспоминаются формулировки. Поиск превращается в подбор ключевых слов — особенно сложно при работе с новыми или старыми материалами.
Где RAG спотыкается в реальных данных
На практике сложнее всего оказались:
- вики-страницы с разметкой и вложенной структурой;
- сложная ролевая модель доступа;
- документы с таблицами и числами;
- визуальные структуры (схемы, оргструктуры);
- PDF с графикой и текстом в виде изображений.
Вики-страницы. Много служебных блоков, ссылок, иерархий. Нужно убрать «шум», сохранив смысл. Перевод иерархии в плоский формат для индексирования — нетривиальная задача.
Мы недооценили объём ручной работы по чистке данных. Это стало ясно только после первых индексаций.
Визуальные структуры. Модель не видит граф связей. После индексации LLM может путать департаменты и руководителей, потому что визуальные отношения для неё неочевидны.
Таблицы и числа. Без специализированных инструментов LLM нестабильно работает с вычислениями и агрегацией. Один и тот же запрос к Excel может давать разные ответы.
PDF и сканы. Текст в изображениях требует OCR. Базовый парсинг часто искажает результат.
Ролевая модель доступа. ACL в разных системах реализован по-разному. При индексации пользователь должен видеть только то, к чему у него есть доступ. Из-за этого мы отказались от совместных ассистентов в пользу персональных — изоляция важнее удобства.
Попытки централизации до этого
Корпоративный портал был попыткой собрать знания в одном месте. Но с ростом объёма пользоваться им стало сложнее. Проблема не в объёме, а в формате хранения: при накоплении разрозненных материалов ориентироваться в них трудно.
Поиск документа, а затем поиск внутри него — отдельная задача. Стало ясно: дело не в «плохом поиске», а в самом подходе к хранению и навигации.
Что было бы, если ничего не менять
Проблема продолжала бы расти. Количество артефактов увеличивается, пространства разрастаются, растут трудозатраты на поиск.
Особенно это заметно для новых сотрудников или при работе с незнакомым разделом: когда не знаешь структуру, поиск превращается в отдельную задачу. Мы видели риск постоянного роста времени на работу с информацией — без роста качества или удобства.
Какие ограничения задали архитектуру
Требования формировались с двух сторон: снизу — сценарии из интервью, сверху — корпоративные ограничения. Именно они сильнее всего повлияли на архитектуру.
В какой-то момент мы поняли, что строим «красивую архитектуру ради архитектуры» — и остановились.
Что нельзя было нарушить:
- всё разворачивается внутри компании;
- никаких внешних сервисов для чувствительных данных;
- права доступа должны совпадать с исходными системами;
- данные и инфраструктура — под нашим контролем.
Некоторые решения пришлось пересматривать.
Изначально точкой входа должен был стать корпоративный мессенджер на базе Express — единый закрытый интерфейс. Логично, безопасно, контролируемо.
Что пошло не так с единой точкой входа
Практика внесла коррективы. У сотрудников были разные привычки. Переход на единый канал оказался не мгновенным.
На этапе тестирования мы открыли веб-доступ. Это был временный шаг, чтобы снизить порог входа и быстрее собрать обратную связь. С самого начала он рассматривался как инструмент пилота, а не финальное решение.
Архитектуру определили не технологии, а ограничения:
- чувствительность данных;
- строгая модель доступа;
- управляемость;
- ускорение работы, а не «ИИ ради ИИ».
Все инженерные решения принимались в этих рамках.
Выбор платформы: почему не стали писать всё сами
Мы пробовали собирать RAG самостоятельно. На это ушли значительные ресурсы.
Скоро стало ясно:
Во-первых, полноценный RAG — это отдельная специализация. Компании, которые делают такие продукты, фокусируются именно на этом. Это не просто «поднять модель и прикрутить векторную базу».
Во-вторых, даже у зрелых вендоров есть нерешённые проблемы — например, агрегация информации по множеству документов без потери контекста. Нет гарантии, что внутренняя разработка будет лучше.
Мы выбрали прагматичный путь: взять готовое решение и сосредоточиться на критичном — архитектуре, интеграциях, модели доступа.
Как выбирали вендора
Тестировали несколько решений. Оценивали не по презентациям, а по поведению в реальных сценариях.
Критерии:
- скорость внедрения и наличие интеграций;
- условия пилота;
- качество ответов на наших тест-кейсах.
Для оценки подготовили свои документы и типовые вопросы. Измеряли качество.
Интересный момент: при on-prem-развёртывании результаты почти всегда были хуже, чем в облаке. Причина — различия в моделях, конфигурации и ресурсах. Это учитывали при выборе.
Работа с «чёрным ящиком»
После выбора платформы основная работа только началась.
Пришлось:
- настраивать интеграции с внутренними системами;
- организовывать передачу файлов;
- подключать мессенджер;
- строить весь контур вокруг RAG-ядра.
Совместная работа длилась почти год. Мы формулировали требования — какие источники подключать, как работать с ассистентами, какие сценарии поддерживать. Вендор дорабатывал продукт и выпускал обновления.
Что оказалось больным в «коробке»:
- апдейты, которые падали в качестве (с 85% до 70%);
- непрозрачная логика связки RAG — LLM;
- конфликт ожиданий пользователей с природой ранжирования.
К концу года стало ясно: коробка — это «чёрный ящик». Мы не могли управлять тем, как RAG взаимодействует с LLM.
Поэтому попросили реализовать дополнительный интерфейс между RAG и моделью. Это позволило забирать контекст и самостоятельно выбирать, в какую LLM его отправлять.
Теперь система не привязана к одной встроенной модели.
Самая сложная часть — не код
Самым трудным оказалось не техническое решение, а процессы.
Обновления вендора могли влиять на качество. Пришлось выстроить:
- регулярные статусы;
- прозрачность поставок;
- схему согласования изменений.
Отдельная сложность — ожидания пользователей.
Сотрудники хотели получать все релевантные вхождения. Но RAG оптимизирован под наиболее релевантный контекст, а не под полный перечень совпадений. Это не баг — особенность подхода.
Эти кейсы приходилось разбирать отдельно — и внутри команды, и с вендором.
В итоге работа с вендором превратилась в совместную эволюцию решения: итерации, метрики, откаты версий, постоянная обратная связь. Именно в этом формате система дошла до рабочего состояния.
Архитектура внутреннего RAG-ассистента
Ключевой принцип: всё работает внутри компании и не выходит за периметр. Это определило интерфейс, обработку данных и модель доступа.
Первый вызов — интерфейс. Telegram выглядел логично, но он внешний — сообщения уходят на серверы. Неприемлемо. Поэтому точкой входа стал корпоративный мессенджер на базе Express. Вся коммуникация остаётся внутри.
Два контура: создание и диалог
Мы разделили процессы создания ассистента и работы с ним.
Первый контур — система управления ассистентами (СУА). Через бота пользователь создаёт ассистента, передаёт ссылки или файлы. Данные поступают в СУА. Там проверяются права, запускаются парсеры, готовятся данные для индексирования. После этого — передача в RAG-движок. По завершении пользователь получает уведомление.
Второй контур — диалоговый. Чат подключён к корпоративной шине взаимодействия с LLM. Бот передаёт запрос в шину, RAG извлекает контекст, и он вместе с запросом отправляется в LLM. СУА дополнительно проверяет права доступа к данным.
Взаимодействие с LLM идёт через уже существующую корпоративную шину, поэтому отдельную инфраструктуру не проектировали.
Коннекторы и предобработка
Работа с разными источниками — отдельный вызов. Для каждого (портал, база знаний, личные файлы) реализованы свои коннекторы и парсеры.
Мы не отдаём обработку структур на откуп RAG-ядру. Предварительная обработка — в отдельных сервисах, затем в индексатор передаются уже подготовленные данные.
ACL и изоляция данных
RAG-движок не поддерживает сложную корпоративную ролевую модель. Поэтому контроль доступа вынесен в отдельный слой.
При создании ассистента СУА фиксирует права пользователя. При каждом обращении проверяется, есть ли доступ. Если нет — ответа не будет.
Из-за сложности ACL в некоторых сценариях мы перешли с совместных на персональные ассистенты: пользователь работает только с тем, к чему у него есть доступ.
Качество и эксплуатационные ограничения
Со временем появился «зоопарк» ассистентов: у одного сотрудника — несколько под разные проекты. Чтобы не вспоминать, какой за что отвечает, реализовали ранжирование: СУА определяет доступных ассистентов, ядро оценивает релевантность их коллекций по эмбеддингам, пользователю предлагается наиболее подходящий набор.
Качество контролируется через бенчмарки. Есть эталонные документы и вопросы. Система тестируется по ним, измеряется метрика. Сначала сравнение было ручным, потом его взяла на себя отдельная LLM, оценивающая ответ по критериям. На основе результатов корректируются параметры, а кейсы пополняют тестовую библиотеку.
Изначально рассматривали единую коллекцию, но это несло риски по доступу. Выбрали модель изолированных коллекций: дублирование данных, но безопасность.
Подключение новых источников — через микросервисы: предобработка вне ядра, затем передача подготовленных данных в индексатор.
По ресурсам ограничений нет: загрузка — до 30%, архитектура рассчитана на три тысячи ассистентов. Пока не приблизились к лимитам — масштабирование не узкое место.
Точка входа в систему
Сначала рассматривали Telegram, но он внешний — неприемлем. Основная точка входа — корпоративный мессенджер внутри периметра. Через бота пользователь создаёт ассистентов, загружает данные, получает ответы.
Со временем стало ясно: универсального интерфейса нет. У сотрудников разные привычки. Но приоритет — за мессенджерем: там реализована полноценная модель доступа. Веб-версия используется ограниченно — для пилотов и тестов.
Точка входа — не «единственный мессенджер», а слой, который может меняться, пока сохраняются безопасность и контроль доступа.
Главные грабли проекта
- Начать с технологии, а не с потребности. Путь к дорогой системе с низким использованием.
- Ожидать от RAG «полного поиска». RAG ранжирует вероятные фрагменты, но не гарантирует полный перечень совпадений.
- Недооценить ACL. Без отдельного слоя контроля доступа — риск утечки внутри контура.
- Считать коробку готовым решением. Без архитектурного слоя (коннекторы, изоляция, бенчмарки) продукт слабо управляем.
- Игнорировать процессы с вендором. Обновления могут менять качество — нужны метрики, тесты и откат версий.
Планы по развитию и выводы
Проект создавался под ограничения: безопасность, доступы, управляемость. Развивался не из-за тренда, а из-за реальных задач.
Архитектура формировалась вместе со сценариями — это задало фокус: не «игрушка с ИИ», а система под практику.
Ассистент рос от практики: поддержка проектных команд, доступ к знаниям через единый запрос. RAG здесь — не чат ради чата, а способ достать контекст из разных источников.
Следующие шаги:
- подключение структурированных данных — SQL, CRM и другие системы;
- полноценная поддержка сложной ролевой модели корпоративного портала.
Архитектуру при этом синхронизируем с изменениями у вендора — чтобы не нарушить безопасность и модель доступа.