RAG-система нужна, когда компании важно отвечать на вопросы по собственным документам без обучения модели на этих данных. Она извлекает релевантные фрагменты из базы знаний и передаёт их LLM как контекст для ответа.
Так корпоративный AI-поиск отвечает по регламентам, договорам, FAQ и тикетам, ссылается на источник, обновляется без переобучения модели и учитывает права доступа. Это основа для ИИ-поддержки, внутренних ассистентов и поиска по документам.
RAG (retrieval augmented generation) — это связка «поиск + генерация». Вместо того чтобы зашивать знания в саму модель, система в момент запроса находит релевантные фрагменты в вашей базе знаний и передаёт их LLM как контекст. Модель формирует ответ на основе этих фрагментов и может сослаться на источник.
Из этого следует три практических свойства: знания можно обновлять без переобучения модели, ответ опирается на конкретные документы (а не на «память» модели), и доступ к фрагментам можно разграничивать по правам.
RAG выигрывает, когда важны свежие и проверяемые факты по вашим документам. Fine-tuning меняет стиль и поведение модели, но плохо подходит для часто меняющихся знаний. Подробное сравнение — на странице RAG vs fine-tuning.
RAG подключается к тем источникам, где уже живут знания компании, и приводит их к единому индексу.
Документы нормализуются, очищаются от дублей и устаревших версий и разбиваются на осмысленные фрагменты (chunks) с метаданными об источнике, разделе и правах доступа.
Фрагменты переводятся в векторные представления (embeddings) и индексируются в векторной базе — pgvector или Qdrant. Для on-prem используется локальная модель эмбеддингов.
Гибридный поиск (BM25 + dense) находит кандидатов, reranking упорядочивает их по релевантности. Фильтр по правам доступа применяется до передачи фрагментов модели.
LLM формирует ответ строго на основе найденных фрагментов, с цитированием источника и отказом при недостатке контекста. Это ограничивает галлюцинации.
К каждому фрагменту привязаны метаданные доступа; retrieval возвращает пользователю только разрешённые ему фрагменты, поэтому ответ не строится на закрытых документах.
Эталонные вопросы и ответы, офлайн-оценки на релизах и онлайн-метрики на трафике, дашборды качества, latency и стоимости. Подробнее — evals и guardrails.
Качество RAG измеряется отдельно для поиска и для ответа — это разные точки отказа.
Обезличенный пример: клиенты под NDA, метрики приведены диапазонами и проверяются на пилоте под конкретную базу знаний.
Сотрудники и поддержка тратят время на поиск ответов в разрозненной документации; часть ответов устаревает быстрее, чем обновляется память сотрудников.
RAG по объединённой базе знаний с hybrid-поиском, цитированием источника, учётом прав доступа, eval-датасетом и мониторингом качества.
Рост доли вопросов с корректным ответом по базе после настройки retrieval и evals; сокращение времени поиска ответа; знания обновляются без переобучения модели.
Качество ответов ограничено качеством базы знаний; темы вне документов не покрываются; точные цифры считаются после разбора источников.
Можно ли подключить закрытые документы?
Да. RAG работает по внутренним документам компании — регламентам, договорам, базе знаний, тикетам — без публикации их наружу. При чувствительных данных система разворачивается в закрытом контуре, где документы и запросы не покидают инфраструктуру компании.
Как система понимает, кому что можно видеть?
Права доступа учитываются на этапе retrieval: к каждому фрагменту привязаны метаданные (источник, отдел, уровень доступа), и поиск возвращает пользователю только те фрагменты, которые ему разрешены. Так ответ не строится на документах, к которым у пользователя нет прав.
Чем RAG отличается от fine-tuning?
RAG не обучает модель на ваших данных, а в момент запроса находит релевантные фрагменты и передаёт их LLM как контекст. Это позволяет менять и обновлять знания без переобучения, показывать источник ответа и разграничивать доступ. Fine-tuning меняет поведение и стиль модели, но плохо подходит для часто меняющихся фактов.
Что делать, если база знаний плохо структурирована?
Это типичная стартовая ситуация. На этапе подготовки данные нормализуются, дубли и устаревшие версии вычищаются, документы разбиваются на осмысленные фрагменты. Качество ответов напрямую зависит от качества базы, поэтому ревизия контента — часть внедрения, а не предусловие.
Можно ли развернуть RAG on-prem?
Да. Embeddings, векторная база и inference разворачиваются в закрытом контуре (vLLM, llama.cpp, Ollama, локальная vector DB). Это нужно при требованиях 152-ФЗ, банковской тайны или внутренней безопасности, когда данные не должны уходить во внешние API.
Как измерять качество ответов?
Через eval-датасет с эталонными вопросами и ответами и набор метрик: точность ответа, точность и полнота retrieval, доля ответов, опирающихся на источник (groundedness), покрытие тем, latency и стоимость запроса. Метрики считаются офлайн на релизах и онлайн на реальном трафике.