Подготовка данных для RAG: технический процесс создания базы знаний

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

Этап 1. Сбор и аудит данных

Принципы отбора источников

Релевантность данных определяет границы компетенций вашей RAG-системы. Для корпоративного помощника это внутренние регламенты, процедуры, базы знаний. Для службы поддержки — FAQ, инструкции по продуктам, история решений тикетов.

Важно учитывать жизненный цикл документов. Устаревшие версии политик компании или неактуальные прайс-листы создают больше проблем, чем отсутствие информации. Система будет генерировать ответы на основе неверных данных.

Источники данных

Структурированные источники: Базы данных, CRM-системы, ERP, корпоративные wiki. Преимущество — четкие метаданные, недостаток — может потребоваться извлечение неструктурированного текста из полей.

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

Неструктурированные источники: Email-переписка, чаты, заметки. Высокое информационное содержание, но сложности с извлечением релевантных фрагментов.

Этап 2. Очистка и нормализация контента

Удаление технического шума

Веб-страницы содержат множество элементов, не относящихся к основному контенту: меню навигации, рекламные блоки, ссылки "поделиться", колонтитулы. Для автоматического извлечения основного содержания используются инструменты типа Readability.js или библиотека Trafilatura для Python.

PDF-документы часто содержат артефакты сканирования, водяные знаки, служебную информацию. Требуется OCR для отсканированных документов и постобработка для удаления повторяющихся элементов.

Стандартизация форматов

Единообразие представления данных критично для качества поиска. Например, денежные суммы должны быть в одном формате: "1000 рублей", а не смесь "1000 руб", "тысяча рублей", "1k RUB".

Даты, номера телефонов, адреса также требуют нормализации. Это улучшает как семантический поиск (через эмбеддинги), так и лексический (через точные совпадения терминов).

Обработка дубликатов

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

• Точное совпадение текста
• Семантическое сходство (косинусное расстояние между эмбеддингами > 0.95)
• Сходство на уровне n-грамм

Этап 3. Стратегии чанкинга

Чанкинг — разбиение больших документов на фрагменты, с которыми может работать система поиска и генерации. Выбор стратегии влияет на релевантность найденной информации.

Фиксированный размер (Fixed-size chunking)

Деление текста на равные блоки по количеству токенов с опциональным перекрытием.

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

Пример параметров: размер чанка 300 токенов, перекрытие 50 токенов (16.7%)

Рекурсивное разбиение (Recursive chunking)

Использование иерархии разделителей: сначала параграфы, затем предложения, затем слова.

Преимущества: Сохранение естественной структуры текста
Недостатки: Неравномерный размер чанков
Применение: Структурированные документы с четкими разделами

Семантическое разбиение (Semantic chunking)

Анализ эмбеддингов соседних предложений для определения границ тем.

Преимущества: Чанки содержат семантически связанную информацию
Недостатки: Высокие вычислительные требования
Применение: Критически важные документы, где контекст принципиален

Разбиение по структуре документа

Использование заголовков, списков, таблиц как естественных границ.

Преимущества: Логическая целостность фрагментов
Недостатки: Требует хорошо структурированных документов
Применение: Техническая документация, регламенты, инструкции

Этап 4. Метаданные для контекстной фильтрации

Метаданные превращают простой поиск в умную систему фильтрации. Они позволяют ограничивать поиск по релевантным критериям до семантического анализа.

Обязательные метаданные

• source_url: Ссылка на исходный документ для верификации
• title: Заголовок документа или раздела
• creation_date/last_modified: Временные метки для фильтрации по актуальности
• document_type: Тип контента (инструкция, FAQ, политика, новость)

Контекстные метаданные

• department: Отдел-владелец документа (HR, IT, Sales, Legal)
• access_level: Уровень доступа (public, internal, confidential)
• language: Язык документа для многоязычных систем
• version: Версия документа для отслеживания изменений

Автоматически извлекаемые метаданные

• key_entities: Имена людей, названия продуктов, номера документов
• topics: Автоматически определенные темы через NLP
• sentiment: Тональность текста (для отзывов, обращений)
• reading_level: Сложность текста для адаптации ответов

Этап 5. Генерация и хранение эмбеддингов

Выбор модели эмбеддингов

Качество эмбеддингов определяет точность семантического поиска. Для русского языка рекомендуются:

• intfloat/multilingual-e5-large: 1024 измерения, хорошее качество для большинства задач
• sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2: 384 измерения, баланс качества и скорости
• cointegrated/rubert-tiny2: 312 измерений, оптимизирован для русского языка

Доменная специфика

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

Векторные базы данных

• Pinecone: Облачное решение, простота интеграции, автоматическое масштабирование
• Weaviate: Open source, поддержка гибридного поиска, встроенная векторизация
• Qdrant: Высокая производительность, Rust-based, хорошо для self-hosted решений
• Chroma: Легковесное решение, подходит для прототипов и небольших проектов

Этап 6. Оптимизация конвейера извлечения

Гибридный поиск

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

Переранжирование результатов

После первичного поиска модель переранжирования (например, Cohere Rerank) пересортировает результаты с учетом более сложного понимания запроса. Это особенно эффективно для многоаспектных вопросов.

Контекстное окно и релевантность

Языковые модели имеют ограничения на размер входного контекста. Важно передавать только наиболее релевантные фрагменты, а не просто первые N результатов поиска. Используйте метрики релевантности для отсечения слабо связанных с запросом документов.

Мониторинг качества данных

Метрики системы

• Context Precision: Доля релевантных чанков среди возвращенных системой
• Context Recall: Полнота покрытия релевантной информации
• Answer Relevancy: Соответствие ответа запросу пользователя
• Faithfulness: Соответствие ответа источникам без галлюцинаций

Типичные проблемы

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

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