RAG-система для бизнеса — это приложение, которое перед ответом ищет разрешённые пользователю фрагменты корпоративных источников, передаёт их языковой модели как контекст и показывает основания ответа. В отличие от дообучения модели, знания обновляются через индекс и источники, а не через изменение весов модели.
Рабочий RAG состоит не из одной «векторной базы». Нужны два основных конвейера: загрузка и обновление контента, а также обработка запроса. Над ними действует контрольный контур — права доступа, версии, оценка, наблюдаемость и реакция на инциденты.
Короткий ответ: начинайте с одного процесса, реестра источников и набора вопросов с известными ответами. Сначала докажите, что поиск находит правильный фрагмент и не выдаёт запрещённый; затем проверяйте, что ответ поддержан найденным контекстом. Только после этого оценивайте удобство, скорость и экономику.
Главное за минуту
- RAG подходит для меняющихся или закрытых знаний, но не исправляет плохие источники.
- Права пользователя применяются до поиска и формирования контекста.
- Чанкинг, metadata, hybrid search и rerank проверяют на своих вопросах.
- Retrieval и generation оценивают отдельно: иначе причина ошибки теряется.
- Ссылка в ответе полезна, только если фрагмент действительно подтверждает вывод.
- Система должна уметь уточнить вопрос, отказаться от ответа и передать человеку.
- Свежесть — измеряемый процесс с владельцем, а не обещание «база обновляется».
Содержание
- Когда бизнесу нужен RAG
- Метод КОНТУР RAG
- Три контура архитектуры
- Реестр источников
- Права доступа до retrieval
- Подготовка документов
- Поиск и rerank
- Как формируется ответ
- Как измерять качество
- Свежесть и наблюдаемость
- Безопасность RAG
- План пилота
- Что принять у подрядчика
- Частые вопросы
- Как AI рассвет проектирует RAG-системы
- Вывод
Когда бизнесу нужен RAG
RAG уместен, когда ответ должен опираться на внутренние регламенты, договорные шаблоны, техническую документацию, каталог, историю заявок или другие источники, которые меняются и имеют владельцев. Типовые интерфейсы — помощник сотрудника, поиск по базе знаний, copilot оператора и customer-facing чат с ограниченной областью.
Не начинайте с RAG, если задача решается точным фильтром по базе данных, обычным полнотекстовым поиском или детерминированным бизнес-правилом. Если ответ обязан быть численно точным и уже хранится в структурированном поле, лучше вызвать API и отобразить значение, а не просить модель пересказывать его.
RAG также не лечит противоречивые документы. Если два действующих регламента дают разные ответы, система должна показать конфликт или выбрать источник по заранее заданному приоритету — но приоритет назначает владелец процесса.
Метод КОНТУР RAG
КОНТУР RAG — шесть проверок производственной системы:
- К — Корпус: известны источники, формат, владелец и authoritative priority.
- О — Ограничения: identity, tenant, роль и документные ACL действуют до retrieval.
- Н — Нормализация: parsing, OCR, chunking, metadata и версии воспроизводимы.
- Т — Точный поиск: lexical и semantic candidates объединяются и переранжируются.
- У — Утверждённый ответ: вывод поддержан контекстом, содержит ссылку или отказ.
- Р — Регрессия: frozen eval запускается после изменения данных, модели или конфигурации.
Рамка помогает локализовать проблему. Если нужного фрагмента нет в top-k, смена prompt не исправит retrieval. Если фрагмент найден, но модель делает неподдержанный вывод, это уже ошибка generation или answer policy.
Три контура архитектуры
| Контур | Вход | Ключевые шаги | Выход |
|---|---|---|---|
| ingestion | документ или запись | parse/OCR → chunk → metadata/ACL → embedding/index | версия фрагментов |
| query | пользователь и вопрос | auth → filters → retrieve → rerank → context → generate | ответ, ссылки, статус |
| control | события и оценки | eval → monitoring → review → rollback/reindex | решение и журнал |
Microsoft Architecture Center разделяет поток приложения и поток данных: документы проходят chunking, enrichment, embedding и сохранение в индекс, а запрос — поиск, сбор контекста и вызов модели. Для бизнеса важно добавить к этой схеме identity, ACL, версию корпуса и журнал решения.
Простой RAG делает один поиск по одному индексу. Agentic retrieval может декомпозировать сложный вопрос, выбирать источники и выполнять несколько запросов. Более сложная схема оправдана только после того, как базовый pipeline измерен: дополнительные шаги увеличивают стоимость, latency и число точек отказа.
Реестр источников
До разработки составьте source registry:
| Поле | Зачем |
|---|---|
| source_id и URI | найти оригинал и удалить его из индекса |
| owner | подтвердить содержание и принять исправление |
| authoritative priority | разрешить конфликт версий |
| audience/ACL | не показать чужой документ |
| updated_at/version | проверить свежесть и воспроизвести ответ |
| parser/type | понять риск потери таблиц, сносок и структуры |
| expiry/SLA | исключить просроченное знание |
PDF со сканами, таблица, база заявок и wiki требуют разных обработчиков. Ошибка парсинга может оставить красивую страницу без полезного текста, поэтому выборочно сверяйте индексированный фрагмент с оригиналом.
Практика управления владельцами и жизненным циклом знаний подробнее разобрана в статье о корпоративной базе знаний с ИИ-агентом.
Права доступа до retrieval
Правильная последовательность: аутентифицировать пользователя, получить его атрибуты, сформировать обязательные filters и только потом искать кандидатов. Фильтрация после retrieval опасна: запрещённый текст уже мог попасть в context, лог или промежуточный cache.
Azure AI Search описывает document-level security trimming, наследование permission metadata и фильтрацию на этапе запроса. Конкретная реализация зависит от платформы, но инвариант один: генератор видит только то, что разрешено субъекту запроса.
Проверяйте не только позитивные роли. В eval должны быть пользователь без группы, уволенный сотрудник, смена подразделения, два tenant, закрытый документ с похожим названием и ранее разрешённый документ после отзыва доступа. Для access leakage критерий обычно бинарный: запрещённый фрагмент не должен появиться ни в ответе, ни в citation, ни в отладочном интерфейсе.
Подготовка документов
Chunk — не произвольный отрезок символов, а минимальный фрагмент, который можно найти и понять с достаточным контекстом. Для регламента полезны заголовок раздела, номер пункта, продукт, регион, дата действия и ссылка на оригинал. Для таблицы может потребоваться сохранить заголовки строк и столбцов внутри каждого фрагмента.
Проверяйте несколько стратегий на одном frozen set: по разделам, предложениям, фиксированному окну с overlap или layout-aware parser. Большой chunk даёт больше контекста, но добавляет шум и расходует окно модели; слишком маленький теряет условия и исключения. Универсального размера нет.
Metadata должна поддерживать фильтры и диагностику, а не украшать индекс. Минимум: source, version, section, language, product, access labels и timestamps. Автоматически сгенерированные summary и keywords помечайте как производные данные и пересоздавайте вместе с версией parser/model.
Поиск и rerank
В корпоративных данных встречаются и смысловые вопросы, и точные артикулы, номера договоров, аббревиатуры. Поэтому базовой проверяемой гипотезой часто становится hybrid retrieval: keyword search сохраняет точные совпадения, vector search находит смысловые, а reranker пересортировывает общий набор.
Официальный обзор Microsoft по RAG прямо рекомендует оценивать hybrid queries и semantic ranking. Это не гарантия лучшего результата на любом корпусе: сравните варианты на своих запросах и зафиксируйте конфигурацию эксперимента.
Диагностика retrieval:
- source absent — документ не подключён или не обновлён;
- parse miss — нужный текст потерян;
- chunk miss — условие разделено;
- filter miss — metadata или ACL исключили документ;
- recall miss — кандидат не попал в набор;
- rank miss — кандидат найден, но оказался ниже context cutoff;
- query miss — термин пользователя не сопоставлен с термином документа.
Как формируется ответ
Оркестратор собирает вопрос, разрешённые top fragments, инструкцию, policy и формат ответа. Модель должна различать четыре исхода: answer, clarify, abstain, handoff. Требование «всегда помогать» провоцирует догадки там, где источника нет.
Citation — это provenance, но не автоматическое доказательство. Reviewer проверяет, что процитированный фрагмент поддерживает каждое существенное утверждение, не устарел и относится к нужному продукту или договору. При конфликте система показывает конфликт и версии либо следует опубликованному priority rule.
RAG уменьшает зависимость от знаний, запомненных моделью, но не исключает галлюцинации. GOV.UK AI Insights отдельно перечисляет retrieval quality, hallucinations, latency, security и evaluation как самостоятельные аспекты системы.
Как измерять качество
Не сводите качество к одному проценту. Соберите frozen eval из реальных, синтетических и отрицательных запросов, удалив персональные данные. Для каждого вопроса храните допустимые источники, ожидаемый смысл, роль пользователя, обязательный исход и critical-fail label.
| Слой | Вопрос проверки | Пример сигнала |
|---|---|---|
| retrieval | найден ли допустимый источник | recall@k, rank, filter correctness |
| grounding | поддержан ли вывод контекстом | claim-support review |
| answer | верен и полон ли ответ | rubric reviewer |
| abstention | отказался ли при отсутствии знания | correct abstain |
| access | не раскрыто ли запрещённое | leakage count |
| operations | стабилен ли сервис | latency, errors, cost per accepted answer |
Автоматические judges ускоряют регрессию, но калибруются на человеческой разметке. Microsoft guide предлагает оценивать этапы отдельно и документировать гиперпараметры и результаты. Acceptance thresholds задаёт владелец процесса с учётом цены ошибки; универсальных значений нет.
Свежесть и наблюдаемость
Для каждого изменения полезна цепочка: событие в source → ingest job → parse status → index version → eval → activation. Dashboard показывает lag по источникам, ошибки parsing, документы без owner, просроченные версии, пустые ACL, долю answer/clarify/abstain/handoff и проблемные запросы.
В журнале ответа храните разрешённый минимум: request id, user/role hash, query class, index/model/prompt versions, document ids, scores, outcome и feedback. Содержимое запроса и фрагментов может быть чувствительным, поэтому retention и доступ к логам задаются отдельно.
Rollback должен возвращать согласованный комплект — индекс, parser, retrieval settings, prompt и policy. Откат только модели не поможет, если дефект возник из-за повреждённой индексации.
Безопасность RAG
Retrieved document — недоверенный ввод. Внутри файла может находиться инструкция для модели, намеренная или случайная. OWASP LLM01:2025 отмечает, что RAG и fine-tuning не устраняют prompt injection полностью.
Минимальные controls:
- разделяйте system policy, user query и retrieved content;
- не позволяйте документу изменять список tools и права;
- ограничивайте действия allowlist, schema validation и approval;
- изолируйте tenants и caches;
- сканируйте источники и проверяйте происхождение;
- редактируйте secrets/PII в логах;
- тестируйте indirect injection и poisoned documents;
- имейте kill switch, incident owner и процедуру reindex.
Если RAG используется в клиентском интерфейсе, дополнительные требования к handoff и виджету собраны в статье об ИИ-чат-боте для сайта.
План пилота
- Выберите один процесс и одну группу пользователей.
- Зафиксируйте baseline: время поиска, ошибки, эскалации и стоимость процесса по принятому определению.
- Создайте source registry, owners, ACL и authoritative priority.
- Подготовьте frozen eval с answerable, unanswerable, conflicting и unauthorized запросами.
- Соберите ingestion и проверьте sample chunks против оригиналов.
- Сравните retrieval configurations без генерации.
- Добавьте answer/clarify/abstain/handoff и проверку citations.
- Запустите shadow или ограниченную beta-группу.
- Настройте freshness, monitoring, feedback и incident runbook.
- Примите
scale / revise / stopпо заранее утверждённым критериям.
Начальные источники, ограничения и критерий приёмки можно выявить в рамках аудита бизнес-процессов перед внедрением ИИ.
Что принять у подрядчика
- карту ingestion/query/control и перечень компонентов;
- реестр источников, owners, ACL mapping и version policy;
- описание parser/chunking/metadata и воспроизводимый reindex;
- frozen eval с разметкой и отчётами по слоям;
- threat model, тесты доступа и prompt injection;
- observability dashboard, retention и audit log;
- runbook для stale source, leakage, outage и rollback;
- расчёт CAPEX/OPEX с явно указанными допущениями;
- документацию, доступ к конфигурации и процедуру передачи.
Страница услуги RAG-системы AI рассвет описывает формат разработки и интеграции. Эта статья служит техническим чек-листом для выбора и приёмки решения.
Частые вопросы
RAG — это векторная база данных?
Нет. Vector store — один возможный компонент retrieval. Производственная система также включает ingestion, identity и ACL, orchestrator, генерацию, citations, eval, monitoring и operations.
Всегда ли нужен vector search?
Нет. Для точных кодов и структурированных полей keyword search, фильтр или API могут быть лучше. Выбор подтверждают на representative queries; часто проверяют hybrid вариант.
Устраняет ли RAG галлюцинации?
Нет. Он даёт модели внешний контекст, но поиск может вернуть неверный фрагмент, а модель — сделать неподдержанный вывод. Нужны grounding review, abstention и regression eval.
Как часто обновлять индекс?
По критичности источника и допустимому lag. У политики должен быть owner, trigger, SLO и контроль failed jobs. Единого интервала для всех документов нет.
Можно ли загрузить в RAG все документы компании?
Технически объём можно расширять, но пилот лучше ограничить одним процессом. Массовая загрузка без owners, ACL, версий и приоритетов увеличивает риск конфликтов и утечек.
Как оценить стоимость RAG?
Разделите discovery, подготовку данных, integration, eval и запуск как CAPEX; модели, поиск, storage, reindex, monitoring и knowledge operations — как OPEX. Общая модель сметы есть в статье о стоимости внедрения ИИ.
Как AI рассвет проектирует RAG-системы
AI рассвет может провести аудит процесса и источников, спроектировать ingestion и permission-aware retrieval, подготовить RAG и интеграции, собрать eval, настроить monitoring, запуск, обучение и поддержку.
Безопасный первый шаг — выбрать один процесс, зафиксировать baseline, источники, права, ограничения и один проверяемый критерий приёмки. После этого можно сравнить варианты retrieval на frozen eval и принять решение о пилоте. Обсудить задачу.
Вывод
RAG-система для бизнеса — это управляемый контур знаний, а не связка «эмбеддинги плюс чат». Метод КОНТУР RAG связывает корпус, ограничения, нормализацию, точный поиск, утверждённый ответ и регрессию.
Начните с одного процесса и source registry. Применяйте ACL до retrieval, измеряйте поиск отдельно от генерации, требуйте citations и корректный отказ, управляйте свежестью и версиями. Тогда решение можно принимать по наблюдаемым ошибкам и критериям, а не по впечатлению от удачной демонстрации.