Как вы делаете data quality monitoring для RAG корпуса?

Краткий тезис

Quality Quality Quality|Data quality monitoring для RAG корпуса — это непрерывный процесс проверки документов на соответствие заданным стандартам до индексации и после неё. Основные проверки включают: отсутствие null-значений в обязательных полях, контроль длины текста, детекцию дубликатов, проверку языка и выявление персональных данных (PII). Инструменты вроде Great Expectations и Deequ автоматизируют эти проверки, а интеграция с CI/CD позволяет блокировать загрузку некачественных данных.

1. Термин: Data Quality (качество данных)

Что это Совокупность характеристик данных, определяющих их пригодность для использования. Для RAG это означает, что документы в корпусе должны быть полными, непротиворечивыми, актуальными и безопасными.

Почему это важно для RAG

• Мусор на входе → мусор на выходе: если в корпусе есть битые, дублирующиеся или нерелевантные документы, retrieval найдёт их, и LLM сгенерирует плохой ответ.
• Плохое качество данных подрывает доверие пользователей к системе.
• Quality Quality Quality|Data quality monitoring — это проактивная защита, а не реактивное исправление ошибок.

Термин «Корпус» (corpus) — это вся совокупность документов, которые индексируются и используются для поиска в RAG-системе.

2. Основные проверки data quality для RAG корпуса

2.1 Проверка на null-значения в обязательных полях

Что это Проверка, что каждое поле, необходимое для работы RAG (например, id, text, source, metadata), не пустое.

Пример:

# Псевдокод проверки с Great Expectations
import great_expectations as ge

df = ge.read_csv("documents.csv")
df.expect_column_values_to_not_be_null("text")
df.expect_column_values_to_not_be_null("id")

2.2 Проверка языка документа

Что это Определение языка текста и проверка, что он соответствует ожидаемому (например, русский или английский).

Зачем

• Если в корпус попадёт документ на неожиданном языке, retrieval может найти его по неверному запросу.
• LLM может сгенерировать ответ на смешанном языке.

Инструменты langdetect, fasttext, spacy.

Пример:

from langdetect import detect

def check_language(text, expected_lang="ru"):
    try:
        detected_lang = detect(text)
        return detected_lang == expected_lang
    except:
        return False

2.3 Проверка min/max длины текста

Что это Проверка, что длина документа (в символах или токенах) находится в заданном диапазоне.

Зачем

• Слишком короткие документы (например, < 10 символов) не несут полезной информации.
• Слишком длинные документы (например, > 10000 токенов) могут превышать лимит контекста LLM и ухудшать качество retrieval.

Пример:

MIN_LENGTH = 50   # символов
MAX_LENGTH = 5000 # символов

def check_length(text):
    length = len(text)
    return MIN_LENGTH <= length <= MAX_LENGTH

2.4 Проверка на дубликаты

Что это Поиск и удаление документов с одинаковым или почти одинаковым содержимым.

Зачем

• Дубликаты искажают retrieval: один и тот же документ может быть найден несколько раз, занимая место в контексте.
• Дубликаты увеличивают размер корпуса и замедляют поиск.

Методы

• Exact dedup сравнение хэшей (MD5, SHA256) полного текста.
• Fuzzy dedup использование MinHash или SimHash для поиска похожих документов.

Пример:

import hashlib

def exact_dedup(texts):
    seen = set()
    unique = []
    for text in texts:
        hash_val = hashlib.md5(text.encode()).hexdigest()
        if hash_val not in seen:
            seen.add(hash_val)
            unique.append(text)
    return unique

2.5 PII detection (детекция персональных данных)

Что это Выявление и маскирование или удаление персональных данных (PII) из документов перед индексацией.

Зачем

• Юридические требования (GDPR, 152-ФЗ).
• Безопасность: LLM не должна генерировать ответы, содержащие PII.

Типы PII

• Имена, фамилии
• Номера телефонов
• Email-адреса
• Паспортные данные
• Номера кредитных карт
• IP-адреса

Инструменты presidio, spaCy, регулярные выражения.

Пример:

from presidio_analyzer import AnalyzerEngine

analyzer = AnalyzerEngine()

def check_pii(text):
    results = analyzer.analyze(text=text, language="ru")
    return len(results) > 0  # True, если найдены PII

3. Инструменты для data quality monitoring

3.1 Great Expectations

Что это: Open-source библиотека для валидации данных. Позволяет определять expectations (ожидания) и проверять данные на соответствие.

Особенности

• Поддержка pandas, Spark, SQL.
• Генерация отчётов в HTML.
• Интеграция с CI/CD.

Пример expectations для RAG корпуса

import great_expectations as ge

# Загрузка данных
df = ge.read_csv("documents.csv")

# Определение expectations
df.expect_column_values_to_not_be_null("text")
df.expect_column_values_to_be_between("text_length", min_value=50, max_value=5000)
df.expect_column_values_to_be_unique("id")
df.expect_column_values_to_match_regex("language", "^ru$|^en$")

# Запуск проверки
results = df.validate()
print(results)

3.2 Deequ

Что это: Библиотека для проверки качества данных в Spark. Разработана Amazon.

Особенности

• Масштабируемость на большие датасеты.
• Поддержка метрик: completeness, uniqueness, compliance.
• Генерация отчётов.

Пример:

from deequ import VerificationSuite, SparkSession
from deequ.checks import Check, CheckLevel

spark = SparkSession.builder.getOrCreate()
df = spark.read.csv("documents.csv", header=True)

check = Check(CheckLevel.Error, "RAG corpus quality check")
check.hasCompleteness("text", lambda x: x >= 0.99)
check.hasUniqueness(["id"], lambda x: x >= 1.0)
check.hasMinLength("text", lambda x: x >= 50)

result = VerificationSuite(spark).onData(df).addCheck(check).run()
result_df = VerificationResult.checkResultsAsDataFrame(spark, result)
result_df.show()

4. Процесс data quality monitoring

4.1 Pre-ingestion checks (до индексации)

Что это Проверки, выполняемые перед добавлением документов в корпус.

Шаги:

1. Получение нового документа (из парсинга, API, загрузки).
2. Запуск проверок: null, длина, язык, дубликаты, PII.
3. Если все проверки пройдены → документ добавляется в корпус.
4. Если проверка не пройдена → документ отклоняется или отправляется на ручную проверку.

4.2 Post-ingestion checks (после индексации)

Что это Периодические проверки всего корпуса на предмет деградации качества.

Шаги:

1. Запуск проверок по расписанию (например, раз в день).
2. Генерация отчёта о качестве данных.
3. Автоматическое уведомление команды при падении метрик ниже порога.

4.3 CI/CD интеграция

Что это Автоматизация проверок в пайплайне обновления корпуса.

Пример:

• При каждом pull request с новыми документами запускается пайплайн с Great Expectations.
• Если проверки не пройдены → PR блокируется.
• Если проверки пройдены → документы индексируются.

5. Метрики для data quality monitoring

6. Проблемы и решения

Пет-проект для закрепления

Задача Разработать систему data quality monitoring для корпуса из 10 000 документов (например, статьи из Википедии).

Инструменты

• Great Expectations (валидация)
• Python (скриптинг)
• SQLite (хранение результатов)
• Streamlit (дашборд)

Шаги:

1. Собрать корпус документов (например, через API Википедии).
2. Определить expectations: no null в text, длина от 100 до 5000 символов, язык — русский, уникальность id.
3. Написать скрипт для запуска проверок.
4. Сохранять результаты в SQLite.
5. Создать Streamlit-дашборд для визуализации метрик.

Ожидаемый результат

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

Связь с другими вопросами

Навигация

• Предыдущий: 274
• Следующий: 276
• Индекс: 00. Индекс разборов