# RAG-система для корпоративной базы знаний

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

- Источник: https://lokai.ru/rag-sistema/
- Организация: Local AI — Внедрение ИИ в закрытом контуре
- Обновлено: 2026-09-21
- Раздел: Главная → Услуги → RAG-система

---

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

## Какие задачи решает RAG-система в компании

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

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

Если требуется извлекать поля, согласовывать документы или запускать операции в учётной системе, это отдельные сценарии. Они могут использовать ту же базу, но требуют своих правил и проверок. Подробнее такие процессы разобраны на странице [ИИ в документообороте](https://lokai.ru/vnedrenie-ii-v-dokumentooborot/). Здесь основной результат — проверяемый ответ на вопрос по корпоративным материалам.

## RAG, обычный поиск и дообучение модели

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

*Как выбрать способ работы с корпоративными знаниями*

| Подход | Когда полезен | Что остаётся проверить |
|---|---|---|
| Обычный поиск | Нужно найти документ по известным словам и реквизитам | Полноту поиска, удобство фильтров и доступ к файлам |
| RAG | Нужен ответ с опорой на найденные фрагменты | Правильность поиска, обоснованность ответа и актуальность источников |
| Дообучение | Требуется изменить устойчивое поведение или формат ответов | Обучающие примеры, качество на отложенной выборке и стоимость поддержки |
| Правила и запросы к данным | Нужен точный расчёт или значение из учётной системы | Корректность формулы, права и свежесть данных |

## Как готовим документы для корпоративной базы знаний

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

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

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

## Локальная RAG-система и права сотрудников

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

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

Отдельно согласуем хранение запросов, резервные копии и доступ администратора. Локальное размещение не отменяет этих задач. Обновление модели, изменение поиска или загрузка нового корпуса способны повлиять на качество, поэтому проходят проверку. Общие требования к инфраструктуре приведены на странице [локального ИИ](https://lokai.ru/lokalnyy-ii/).

## Как проходит внедрение RAG-системы

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

1. **Выбираем процесс и источники**  
   Определяем подразделение, повторяющиеся вопросы и владельца базы. Проверяем, есть ли в документах ответы на эти вопросы. Если знания хранятся только у сотрудников, сначала планируем их описание: поиск не извлечёт правило из отсутствующего документа.
2. **Собираем проверочный набор**  
   Включаем простые, неоднозначные и многошаговые вопросы, а также случаи без ответа и с запретом доступа. Для каждого задаём ожидаемый источник и критерии оценки. Часть примеров не используем при настройке, чтобы проверить перенос на новые задания.
3. **Настраиваем поиск и подготовку ответа**  
   Проверяем обработку документов, подбор фрагментов и формирование выдачи. Отдельно разбираем случаи, когда найден неверный источник, и случаи, когда правильный источник пересказан с ошибкой. У этих проблем разные причины и разные способы исправления.
4. **Проверяем рабочее использование**  
   Сотрудники решают типовые задачи и оценивают пригодность результата. Измеряем время с учётом проверки, долю обоснованных ответов и ошибки доступа. После приёмки фиксируем правила сопровождения базы, обновлений и возврата к предыдущей версии.

## Как измеряем качество ответов по базе знаний

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

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

Показатели обсуждаем вместе с владельцем процесса. Для справочного помощника и технической инструкции цена ошибки различается. Универсальные обещания точности без корпуса, перечня вопросов и метода проверки не используем. Дообучение рассматриваем как отдельный инструмент, если испытание показывает такую необходимость; подробнее — [как дообучаем модели](https://lokai.ru/doobuchenie-modeley/).

## Стоимость разработки RAG и границы проекта

Первичная диагностика бесплатна. Пилот на одном процессе стоит $3–5 тыс. и засчитывается в стоимость внедрения. Его техническая часть занимает 2–4 недели; подготовка корпуса и согласование доступа могут увеличить общий срок. Полная система под ключ — от $30 000, подписка на развитие — $2,5–5 тыс. в месяц.

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

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

## Вопросы о локальной RAG-системе

**Нужно ли заранее переносить все документы в новую систему?**

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

**Можно ли отвечать одновременно по русским и английским материалам?**

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

**Что произойдёт после удаления документа из хранилища?**

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

**Можно ли подключить базу к корпоративному мессенджеру?**

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

**Как подготовиться к первому обсуждению?**

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

---

Бесплатный аудит и расчёт окупаемости на ваших данных: https://lokai.ru/besplatnyy-audit-ii/

Почта: hello@lokai.ru · 123112, Москва, ММДЦ «Москва-Сити» · Пн–Пт, 09:00–19:00 МСК