# RAG по документам компании: практическая архитектура

Как построить RAG по внутренним документам: загрузка и очистка, разбиение на фрагменты, embeddings, retrieval, цитаты, права доступа и оценка качества.

Канонический URL: https://llmtokenapi.ru/blog/rag-po-dokumentam-kompanii
Опубликовано: 2026-08-31T14:14:54.527Z
Автор: Команда LLMTOKENAPI

RAG по документам компании строится как поисковая система с генерацией поверх найденных фрагментов. Надёжная схема загружает и очищает файлы, делит их по смыслу, создаёт embeddings, извлекает релевантные части и просит модель отвечать только по ним. Качество чаще зависит от ingestion и retrieval, чем от сложности финального промпта.

## Что даёт RAG и чего он не делает

Retrieval-augmented generation добавляет к запросу внешние знания во время ответа. Подход был формализован в работе [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks](https://arxiv.org/abs/2005.11401): генеративная модель использует извлечённые документы как дополнительную опору. Для компании это означает, что инструкции, регламенты и справочники можно обновлять без обучения новой модели.

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

## Подготовьте документы к индексации

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

При извлечении сохраняйте структуру: заголовки, разделы, списки и таблицы. Header и footer, повторяющиеся на каждой странице PDF, создают шум. Сканированные документы требуют OCR и выборочной проверки. Для каждой нормализованной единицы храните источник, номер страницы или раздел, версию и hash содержимого.

LLMTOKENAPI предоставляет managed-базы знаний с загрузкой файлов, статусом индексации, смысловым поиском и ответом. Маршруты `/v1/knowledge-bases/*` и необходимые scopes описаны в [документации API](/docs). Можно использовать готовый контур или построить собственный поверх `/v1/embeddings`.

## Делите текст по смысловым границам

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

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

Размер chunk выбирают экспериментом. Подготовьте реальные вопросы и измерьте, попадает ли подтверждающий фрагмент в top-k. Универсального числа символов нет: FAQ, юридический документ и техническое руководство имеют разную структуру.

## Стройте retrieval в два этапа

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

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

Не увеличивайте `top-k` бесконечно. Лишние фрагменты занимают контекст и могут внести противоречия. Лучше улучшить chunking, метаданные и формулировку поискового запроса. Если подтверждение не набрало минимальный score, система должна запросить уточнение или сообщить, что ответа в базе нет.

## Формируйте grounded-ответ

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

Отделяйте инструкцию от содержимого документа. Текст внутри загруженного файла является данными, даже если в нём написано «игнорируй предыдущие правила». Это базовая защита от prompt injection через базу знаний. Инструменты и системные действия не должны запускаться по инструкции из найденного фрагмента.

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

## Разграничивайте доступ до поиска

Нельзя сначала найти все документы, а потом скрыть запрещённые ссылки. Даже содержание ответа или длина результата может раскрыть закрытую информацию. Фильтр по организации, роли, проекту и уровню доступа применяется в запросе к индексу. Кэш также должен учитывать тот же контекст авторизации.

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

## Оценивайте систему на реальных вопросах

Разделите оценку на retrieval и generation. Для поиска измеряйте, появился ли правильный фрагмент в top-k и на какой позиции. Для ответа — корректность, полноту, поддержку цитатами и качество отказа. Добавьте вопросы без ответа: система должна распознать отсутствие данных, а не заполнить пробел общими знаниями.

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

Производственный RAG — это управляемый жизненный цикл знаний. Документы получают владельцев и версии, индекс обновляется наблюдаемо, доступ проверяется до retrieval, а каждый ответ остаётся связан с конкретным подтверждением.