Крок показал, как построил внутреннего RAG-ассистента для корпоративных данных

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

Почему выбрали RAG

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

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

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

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

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

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

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

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

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

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

Где возникли проблемы Самые неприятные сложности оказались не в интерфейсе, а в данных и процессах.

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

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

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

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

Что это значит

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