RAG система: база знаний, источники и проверка качества

Раздел

RAG и базы знаний

Сложность

средняя

Обновлено

2026-05-22

Короткий ответ

RAG система нужна, когда модель должна отвечать не “из головы”, а по вашим документам, регламентам, базе знаний, тикетам или договорам. Хороший RAG не просто ищет похожий текст. Он показывает источник, уважает права доступа, отказывается при нехватке данных и проходит регулярную проверку качества.

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

Эта статья закрывает запросы RAG система, rag в ии это, система retrieval augmented generation rag, rag и генеративный ии и rag модель ии. Если нужен практический запуск, переходите к созданию RAG системы. Если retrieval нужен внутри tool loop агента, смотрите ИИ-агента с RAG.

Что такое RAG в ИИ

RAG, или retrieval augmented generation, - это подход, при котором генеративная модель перед ответом получает найденные фрагменты из внешнего корпуса. В простых словах: retrieval ищет релевантные источники, а generation формирует ответ на их основе.

Это не отдельная “RAG модель ИИ”. Чаще RAG - архитектурный слой вокруг модели: корпус документов, индекс, поиск, фильтры прав, prompt, citations и проверка качества. Модель остается генератором текста, а знание о продукте, регламентах или клиентах хранится во внешних источниках.

Для бизнеса это различие важно. Если назвать RAG “моделью”, легко ждать, что модель сама знает актуальные правила. На практике система должна доказать, какой документ найден, кто имеет право его видеть, когда он обновлен и почему ответ можно принять.

Когда RAG нужен

RAG подходит, если ответы должны опираться на меняющиеся материалы:

• база знаний поддержки;
• внутренние регламенты;
• договоры и приложения;
• инструкции по продукту;
• база тикетов;
• техническая документация;
• HR-политики;
• процедуры бухгалтерии и документооборота.

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

Архитектура простыми словами

Типовая RAG система состоит из пяти слоев:

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

OpenAI описывает file search как hosted tool для поиска по vector stores, а не как замену политики источников. Даже если поиск встроен в AI-платформу, команде все равно нужны owner документа, access filter, citation, freshness и eval.

Для общего понимания полезно сравнить определения и архитектурные варианты у IBM и AWS: IBM объясняет RAG как связку поиска и генерации в материале What is retrieval augmented generation, а AWS разбирает варианты retrieval в Prescriptive Guidance.

Граница утверждения: внешние материалы объясняют принцип retrieval + generation, но не доказывают качество вашей системы. Для бизнес-решения источником истины остается собственный корпус, права доступа и тестовый набор с правильными документами. Если вопрос нельзя связать с конкретным фрагментом, ответ должен быть отказом или черновиком для человека.

rag_document_metadata:
  owner: support_knowledge_team
  product: billing
  access_level: support_l1
  updated_at: 2026-05-20
  status: approved
  review_cycle_days: 30

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

Подготовка документов

Перед индексом нужно разобрать документы:

• что актуально;
• что устарело;
• где есть дубли;
• какие документы противоречат друг другу;
• какие материалы доступны только отдельным ролям;
• где нужен владелец документа;
• как часто документ обновляется.

Каждому документу полезно добавить метаданные: владелец, дата обновления, отдел, уровень доступа, тип документа, продукт, язык, статус. Без метаданных система не сможет объяснить, почему она выбрала источник и можно ли показывать его конкретному пользователю.

Не загружайте в RAG все подряд. Начните с узкого корпуса: например, 100 статей поддержки или 50 регламентов. Чем меньше корпус на старте, тем проще понять ошибки.

Индексация и фрагменты

RAG ищет не весь документ целиком, а фрагменты. Если фрагмент слишком маленький, он теряет контекст. Если слишком большой, в ответ попадает лишний шум. Поэтому chunking нужно тестировать на реальных вопросах.

Проверяйте:

• находит ли поиск нужный фрагмент;
• хватает ли соседнего контекста;
• не смешиваются ли разные темы;
• сохраняются ли заголовки и таблицы;
• можно ли показать ссылку на исходный документ;
• как обрабатываются PDF, DOCX, HTML и изображения.

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

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

RAG система не должна обходить права. Если сотрудник не имеет доступа к документу, модель не должна использовать этот документ в ответе. Иначе чат станет дырой в безопасности.

Минимальная модель:

1. У пользователя есть роль или группа.
2. Каждый документ имеет уровень доступа.
3. Поиск фильтрует корпус до генерации ответа.
4. Ответ показывает только разрешенные источники.
5. Все обращения пишутся в журнал.

Не полагайтесь на то, что модель “сама не скажет лишнего”. Права должны работать на уровне поиска и данных, а не только в промпте.

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

RAG нужно проверять не одним числом. Оценка состоит из нескольких вопросов:

• найден ли правильный источник;
• использован ли источник в ответе;
• нет ли выдуманных фактов;
• полный ли ответ;
• есть ли отказ при нехватке данных;
• не показан ли запрещенный документ;
• понятен ли ответ человеку.

Соберите 100-200 тестовых вопросов. Для каждого укажите правильный источник, ожидаемый ответ или критерии, и критичные ошибки. Отдельно добавьте вопросы, на которые система должна отказаться отвечать. Это важнее, чем кажется: хороший RAG должен честно говорить “в базе нет данных”.

Метрики вроде faithfulness и answer relevance удобно формализовать заранее; для ориентира можно посмотреть статью RAGAS, указанную в источниках, и затем адаптировать критерии под свои риски, а не копировать академическую оценку без бизнес-контекста.

Метрики

Полезные метрики:

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

План внедрения

1. Выберите один домен: поддержка, регламенты или документы.
2. Назначьте владельца корпуса.
3. Очистите документы от дублей и устаревших материалов.
4. Добавьте метаданные и права.
5. Настройте индекс и поиск.
6. Соберите тестовый набор вопросов.
7. Запустите режим помощника для сотрудников.
8. Считайте ошибки, отказы и ручные правки.
9. Расширяйте корпус только после стабильного качества.

Не начинайте с “RAG по всем документам компании”. Это почти гарантированно даст шум, дубли и проблемы с правами.

Чеклист

• Корпус ограничен и понятен.
• У документов есть владелец и дата обновления.
• Учитываются права доступа.
• Ответы показывают источники.
• Есть тестовый набор вопросов.
• Система умеет отказываться.
• Ошибки попадают в журнал.
• Качество пересматривается после обновления корпуса.

FAQ

RAG убирает галлюцинации?

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

RAG в ИИ - это модель или система?

Обычно система. Модель генерирует ответ, а RAG-контур ищет и передает ей актуальные фрагменты с источниками, правами и metadata.

Чем RAG отличается от обычной базы знаний?

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

Что важнее: модель или база знаний?

На старте важнее корпус. Если документы плохие, модель будет уверенно пересказывать плохие документы.

Можно ли загружать всю корпоративную wiki?

Технически можно, но лучше не начинать с этого. Сначала один домен, чистка документов, права и тестовый набор.

Как часто обновлять индекс?

Зависит от данных. Для поддержки и регламентов нужен регулярный процесс: документ обновился - индекс обновился - тесты прогнаны.

Что читать дальше?

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