Как КРОК внедрил внутреннего AI‑ассистента на базе RAG‑архитектуры для поиска по корпоративным знаниям в закрытом контуре

В КРОК работает больше 3000 сотрудников в более чем 20 департаментах. У каждого подразделения, а иногда у отдельных команд, были собственные базы знаний, в которых хранились нормативные материалы, документация и проектные артефакты. Кроме того, в компании уже существовали крупные корпоративные системы, которые тоже содержали большие массивы данных.

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

Поэтому задачу нужно было решать сразу в нескольких плоскостях:

1. Объединять распределенные источники
2. Учитывать сложный контекст проектных знаний
3. Обеспечивать безопасную работу с конфиденциальной информацией

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

Со временем стало ясно, что компании нужен инструмент, который помогает находить подходящий фрагмент информации, даже если пользователь не знает, как именно он сформулирован в документе. Так появился CAFY — Croc Assistant For You, внутренний ассистент по корпоративным документам и рабочим материалам.

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

Дополнительным ограничением стала чувствительность данных. Важен был не только вопрос хранения, но и сам факт контроля над инфраструктурой: система должна была работать на собственных мощностях компании.

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

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

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

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

Решение разделили на два контура: создание ассистента и работу с ним.

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

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

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

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

Но в корпоративной среде это не так просто. Источники в КРОК были архитектурно разными: корпоративный портал, база знаний, личные файлы, пространства подразделений. Поэтому для каждого типа данных пришлось делать отдельные коннекторы и парсеры. Команда не стала перекладывать обработку ссылок и структур данных на RAG-ядро, чтобы не перегружать его и не терять контроль над качеством входных данных.

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

Вики-страницы с многослойной структурой

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

Таблицы и числовые данные

Без специализированных инструментов LLM нестабильно справляется с вычислениями, агрегацией и интерпретацией табличных фрагментов, из-за чего один и тот же запрос к Excel-данным мог давать разные ответы. Для корпоративной эксплуатации это серьезное ограничение: если пользователь ожидает точный и воспроизводимый ответ, только LLM-логики может быть недостаточно.

Визуальные структуры и оргструктуры

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

PDF и сканы

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

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

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

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

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

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

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

Именно на этом этапе особенно заметной стала проблема «черного ящика». Обновления могли непредсказуемо влиять на качество ответов, а логика связки между RAG и встроенной LLM оставалась непрозрачной.

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

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

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

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

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

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

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

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

1. Сначала определяется список доступных пользователю ассистентов.
2. Затем ядро оценивает релевантность их коллекций и индексов по семантическому сходству.
3. В итоге пользователю предлагается наиболее подходящий набор под его конкретный запрос.

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

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

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

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