RAG-система для бизнеса: поиск и ответы по документам

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

Из каких компонентов состоит RAG

Коннекторы забирают данные из файлов, базы знаний, CRM, wiki и облачных дисков.
Парсер извлекает текст, таблицы, заголовки и структуру документа.
Чанкер делит материал по смыслу и сохраняет метаданные: источник, версия, дата, доступ.
Поиск объединяет ключевые слова и векторную близость.
Reranker отбирает действительно полезные фрагменты.
Модель формирует ответ только из контекста и прикладывает ссылки.

Как выбирать размер фрагмента

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

Права доступа

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

Оценка качества

Метрика	Что измеряет
Recall@k	Попал ли правильный источник в верхние результаты поиска.
Faithfulness	Подтверждается ли ответ предоставленным контекстом.
Answer relevance	Отвечает ли текст на заданный вопрос, без лишней воды.
Citation accuracy	Ведёт ли ссылка именно на подтверждающий фрагмент.
Abstention quality	Отказывается ли система, когда данных недостаточно.

Типовые ошибки

Индексировать сканы без качественного OCR.
Смешивать действующие и архивные версии без дат.
Отдавать модели десятки слабых фрагментов.
Оценивать систему только на придуманных разработчиками вопросах.
Не назначать владельца базы знаний и процесс актуализации.

Практический подход

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

Когда RAG готов к работе

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

Как построить корпоративный RAG, которому доверяют сотрудники

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

Практическая декомпозиция задачи

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

1. Типы данных

PDF, таблицы, сканы, wiki и тикеты требуют разных конвейеров. На старте мы уточняем текущее состояние, доступные данные и ответственного со стороны бизнеса. Затем описываем крайние случаи и способ проверки результата на тестовом контуре. Это позволяет заложить в план не только «счастливый путь», но и реальные ограничения эксплуатации.

2. Права

Фильтрация должна работать до поиска, а не после генерации ответа. На старте мы уточняем текущее состояние, доступные данные и ответственного со стороны бизнеса. Затем описываем крайние случаи и способ проверки результата на тестовом контуре. Это позволяет заложить в план не только «счастливый путь», но и реальные ограничения эксплуатации.

3. Актуальность

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

4. Оценка

Набор вопросов должен покрывать отделы, сложность и опасные случаи. На старте мы уточняем текущее состояние, доступные данные и ответственного со стороны бизнеса. Затем описываем крайние случаи и способ проверки результата на тестовом контуре. Это позволяет заложить в план не только «счастливый путь», но и реальные ограничения эксплуатации.

Как проходит рабочий проект

Диагностика. Собираем фактический процесс, примеры данных и ограничения. Отделяем бизнес-проблему от заранее выбранной технологии и формулируем измеримый baseline.
Проектирование. Описываем архитектуру, роли, состояния ошибок, интеграционные контракты и критерии готовности. Решения с высокой неопределённостью проверяем прототипом.
Первый сквозной контур. Реализуем минимальный путь от входа до полезного результата на тестовых данных. На этом этапе рано выявляются ошибки модели данных и взаимодействия систем.
Проверка на реальных сценариях. Используем контрольные примеры, крайние случаи и негативные тесты. Разбивать документы одинаковыми кусками без учёта структуры. — один из рисков, который должен быть снят до тиражирования.
Пилот и наблюдаемость. Запускаем решение на ограниченной аудитории или участке, собираем события, ошибки, задержки и ручные корректировки. Пилот заканчивается решением по данным, а не демонстрацией.
Масштабирование. После подтверждения качества добавляем сценарии, пользователей и нагрузку, сохраняя совместимость, контроль версий и возможность безопасного отката.

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

Что влияет на бюджет и сроки

Фактор	Практическое влияние
Типы данных	PDF, таблицы, сканы, wiki и тикеты требуют разных конвейеров.
Права	Фильтрация должна работать до поиска, а не после генерации ответа.
Актуальность	Нужны переиндексация, удаление старых версий и контроль источника.
Оценка	Набор вопросов должен покрывать отделы, сложность и опасные случаи.

Риски, которые нужно снять до запуска

Разбивать документы одинаковыми кусками без учёта структуры.
Смешивать архивные и действующие регламенты.
Показывать ответ без цитаты и ссылки на первоисточник.
Считать cosine similarity достаточной оценкой бизнес-качества.

Чек-лист приёмки

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

Какие материалы подготовить до оценки

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

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

Что должно остаться у заказчика

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

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

Частые вопросы

Сколько документов нужно для старта?

Количество не главный критерий. Для пилота важнее ограниченный набор актуальных документов и 100–300 реальных вопросов.

Нужна ли векторная база?

Часто да, но она не заменяет полнотекстовый поиск, фильтры по метаданным и правила доступа.

Можно ли индексировать таблицы?

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

Как обновлять базу?

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

Нужна оценка вашей задачи?

Разберём исходные данные, ограничения и предложим формат первого этапа без лишнего объёма.

Заказать корпоративную базу знаний

RAG-система для бизнеса: ответы по документам без ручного поиска