Сотрудники спрашивают ИИ о отпусках, регламентах, продуктах и внутренних процедурах — и получают уверенный, но выдуманный ответ. Проблема не в «плохой модели», а в отсутствии связи с корпоративными знаниями. RAG (Retrieval Augmented Generation) решает это: сначала поиск по вашим источникам, затем генерация ответа с опорой на найденные фрагменты.
Ниже — как спроектировать корпоративный RAG так, чтобы им можно было пользоваться в проде: с доступами, оценкой качества и контролем через AI Gateway. Контур знаний обычно связывают с платформой AIaaS и сценариями из каталога решений.
Когда нужен RAG, а когда достаточно промпта
Если ответ должен опираться на внутренние документы, версии политик, продуктовые спецификации или базу service desk — нужен RAG. Если задача общая (переформулировать письмо, набросать план) — достаточно модели из каталога без retrieval.
Смешивать эти режимы в одном чате можно, но политики должны быть разными: для RAG выше требования к аудиту источников и ACL.
Практический критерий: если без корпоративного документа ответ нельзя проверить — включайте retrieval. Если задача чисто языковая — не тратьте бюджет на индекс.
Архитектура корпоративного RAG
Типовой контур: коннекторы к источникам → очистка и чанкинг → эмбеддинги → векторный индекс → retriever с фильтрами доступа → LLM через gateway → ответ со ссылками на источники → логирование.
Критичный элемент — фильтрация по правам до генерации. Пользователь не должен получать фрагмент документа, к которому у него нет доступа в исходной системе.
Добавьте слой наблюдаемости: логируйте query, найденные chunk id, применённые ACL-фильтры, модель и стоимость. Без этого нельзя отличить плохой retrieval от плохой генерации.
- Источники: Confluence/Wiki, SharePoint, файловые хранилища, ITSM KB, регламенты PDF
- Метаданные: владелец, гриф, дата актуальности, язык, продукт/процесс
- Чанкинг с учётом структуры (заголовки, таблицы), а не слепая нарезка
- Hybrid search: вектор + ключевые слова для кодов, артикулов, номеров политик
Качество корпуса важнее размера модели
Мусор на входе даст мусор на выходе даже с сильной LLM. Перед пилотом проведите инвентаризацию: какие документы актуальны, где дубли, кто владелец. Устаревшие инструкции по VPN или кадровым процессам — главный источник «уверенных ошибок».
Введите статус «утверждено для ИИ». В индекс пилота попадают только такие материалы. Остальное — в бэклог нормализации.
Удалите или пометьте черновики, личные пространства и дубликаты «копия (1)». Иначе retriever будет тасовать противоречивые версии одной политики.
Чанкинг, метаданные и hybrid search на практике
Слепая нарезка по N токенам ломает таблицы, списки процедур и юридические определения. Режьте по структуре: заголовок + абзацы, сохраняя соседний контекст для связности.
Метаданные решают половину качества: продукт, регион, дата актуальности, гриф, язык, тип документа. Фильтры по метаданным часто полезнее увеличения top-k.
Hybrid search обязателен для идентификаторов: номер политики, код ошибки, артикул, название системы. Чистый векторный поиск на таких запросах нестабилен.
- Overlap 10–20% между чанками для связности процедур
- Отдельная обработка таблиц и списков шагов
- Поле «supersedes» для устаревших версий
- Буст свежих утверждённых документов в ранжировании
Оценка качества ответов
Соберите золотой набор из 50–150 вопросов бизнеса с эталонными ответами и допустимыми источниками. Без него вы спорите о вкусе, а не управляете качеством.
Гоняйте eval после каждого изменения чанкинга, эмбеддингов или промпта генерации. Иначе «улучшение» в одном домене ломает другой.
- Faithfulness: ответ опирается на найденные фрагменты, а не домыслы
- Relevance: найдены правильные документы
- Citation quality: ссылки кликабельны и ведут на нужный раздел
- Refusal: система отказывается, когда в базе нет данных
- ACL tests: негативные кейсы на запрещённые документы
Безопасность и compliance
RAG увеличивает поверхность данных: в индекс могут попасть персональные данные и коммерческая тайна. Нужны классификация, DLP на этапе ингеста и маскирование в логах. См. DLP и 152-ФЗ при работе с LLM.
Храните эмбеддинги и сырье в согласованном контуре. Разделите индексы по грифам или бизнес-юнитам, если это требует модель угроз.
Проверяйте, что удаление документа в источнике приводит к удалению/пометке в индексе в согласованный SLA. «Забыли переиндексировать» — частый путь к утечке через ответ ИИ.
Встраивание в продукты, а не только «умный поиск»
Максимальная ценность — когда RAG встроен в рабочие процессы: подсказки агенту в service desk, ответы оператору в контакт-центре, пояснения по регламенту при разборе документов в Document AI.
Отдельный портал «спроси базу» полезен, но эффект выше у ассистента внутри уже используемого инструмента.
Для каждого канала задайте свой system prompt и политику отказов: сотрудник и клиентский оператор не должны получать одинаковый уровень детализации внутренних процедур.
Антипаттерны корпоративного RAG
Индексация «всего SharePoint» без ACL. Отсутствие цитат. Слишком большой top-k «на всякий случай». Fine-tuning вместо наведения порядка в документах. Один индекс на все грифы. Игнорирование отказа, когда данных нет.
Ещё один антипаттерн — оценивать успех только по «вау» на демо-вопросах руководства. Демо-вопросы редко совпадают с реальным long-tail запросов сотрудников.
Эксплуатация: кто владеет знаниями
Назначьте владельцев доменов знаний и KPI актуальности. ИИ-команда поддерживает пайплайн; бизнес-подразделения отвечают за контент. Иначе индекс деградирует за один-два квартала.
Настройте мониторинг: доля ответов без источника, доля отрицательных оценок пользователей, время обновления индекса после изменения документа.
Введите регламент: изменение критичной политики = задача на переиндексацию + выборочный eval из 10 связанных вопросов.
Экономика и выбор моделей
В RAG стоимость складывается из эмбеддингов, хранения индекса и генерации. Для генерации часто выгодно маршрутизировать простые вопросы на более дешёвые модели, оставляя тяжёлые рассуждения для сложных кейсов — см. Kimi, Qwen, DeepSeek и биллинг AI-кредитов.
Контролируйте top-k и размер контекста: избыточный контекст дорог и иногда ухудшает точность.
Считайте стоимость успешного ответа (с цитатой и положительной оценкой), а не только стоимость вызова. Дешёвый, но бесполезный ответ дороже для бизнеса.
Пилотный план RAG на 6 недель
Ограниченный домен важнее «полного покрытия компании». Возьмите один процесс — например, HR-регламенты или ITSM KB — и доведите его до измеримого качества.
Параллельно с инженерией индекса готовьте change-management: кто отвечает на негативные оценки пользователей и кто правит исходный документ, а не только промпт.
- Неделя 1: инвентаризация корпуса, ACL, владельцы
- Неделя 2: пайплайн ингеста, чанкинг, hybrid search
- Неделя 3: eval-набор и базовые метрики faithfulness/ACL
- Неделя 4: assist в одном канале через AI Gateway
- Неделя 5: разбор ошибок и доработка корпуса
- Неделя 6: go/no-go и план следующего домена
Чеклист запуска пилота RAG
Ограничьте домен, согласуйте ACL, соберите eval-набор, подключите gateway с лимитами, запустите assist-режим в одном канале. Через 4–6 недель решите, масштабировать ли на смежные базы.
Если нужен управляемый контур под ключ, начните с платформы и обсудите источники данных через контакт.
Не масштабируйте индекс, пока refusal и citation quality не стабильны. Широкий плохой RAG хуже узкого хорошего: он быстрее разрушает доверие к корпоративному ИИ.
- Утверждённый корпус и владельцы
- Матрица доступов и тест на утечки
- Метрики качества и дашборд расхода
- Процесс обновления документов и переиндексации
- Золотой набор вопросов и регулярный eval
Частые вопросы
RAG проще обновлять: изменили документ — переиндексировали. Fine-tuning дороже, дольше и хуже объясняет источник ответа. Для регламентов, политик и продуктовых знаний чаще начинают с RAG.
Технически да, организационно — опасно. Начните с утверждённого корпуса и матрицы доступов. Иначе модель будет цитировать устаревшие или конфиденциальные черновики.
Критичные политики — почти сразу после публикации (минуты/часы). Справочные материалы — по расписанию раз в сутки или при событии изменения. Главное — SLA обновления, согласованный с владельцами контента.
В корпоративном контуре — да, как минимум для регламентов и продуктовых правил. Цитата повышает доверие и ускоряет разбор ошибок: сразу видно, какой документ «соврал» или устарел.