Как проектировать ETL vs ELT для RAG?

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

Выбор между ETL и ELT для RAG — это компромисс между контролем качества данных на этапе загрузки и гибкостью трансформаций после загрузки. ETL (Extract-Transform-Load) предпочтительнее для небольших и средних объёмов (<1M документов), когда парсинг и чанкинг — дорогие операции, которые не хочется повторять. ELT (Extract-Load-Transform) подходит для больших объёмов (>10M документов), когда важна скорость загрузки raw-данных и возможность перестраивать чанкинг без повторной загрузки. На практике в RAG-системах часто используют гибридный подход: ETL для первичной индексации и ELT для обновлений и A/B-тестирования стратегий.

1. Определения: ETL и ELT

ETL (Extract-Transform-Load) — классический пайплайн данных]]: сначала извлекаем (Extract) данные из источников (файлы, БД, API), затем трансформируем (Transform) — парсинг, очистка, чанкинг, создание эмбеддингов — и только после этого загружаем (Load) в целевое хранилище (векторную БД, S3, Data Warehouse).

ELT (Extract-Load-Transform) — сначала извлекаем (Extract) и сразу загружаем (Load) сырые данные в промежуточное хранилище (Data Lake, S3, HDFS), а трансформации (Transform) выполняем уже внутри хранилища средствами MPP-движков (Spark, Dask, Snowflake) по расписанию или под запрос.

2. Архитектурные различия

3. Почему в RAG традиционно выбирают ETL?

Парсинг и чанкинг — дорогие операции. Они требуют:

• загрузки full-text документа (может быть PDF → OCR → text → структура);
• применения правил разделения (paragraph chunking, chunking|semantic chunking);
• вычисления эмбеддингов (дорогой вызов модели или API).

Если делать это многократно (как в ELT при каждом пересчёте), нагрузка растёт. ETL позволяет выполнить трансформацию один раз, проверить качество и загрузить готовые векторы.

Контроль качества на входе В ETL проще добавить валидацию: проверить, что чанки корректно дедуплицированы, что метаданные заполнены, что размер чанков в допустимом диапазоне. Если ошибка — пайплайн падает до загрузки в product-хранилище.

Небольшие объёмы Для RAG-систем до 1M документов ETL-подход экономит ресурсы: не нужно разворачивать кластер Spark, достаточно одного Python-скрипта на Airflow.

4. Когда ELT становится привлекательным для RAG?

Гигантские объёмы (10M+ документов). Выгрузить сырые документы в S3 — операция линейная и быстрая. Трансформация с помощью Spark/Dask масштабируется горизонтально, не блокируя конвейер.

Гибкость экспериментов Data Scientist хочет попробовать разные стратегии чанкинга (например, 256 токенов vs 512 vs semantic). В ELT достаточно написать новый SQL/Python-трансформ, не трогая этап загрузки. Можно параллельно хранить несколько версий одних и тех же сырых документов.

Инкрементальные обновления При добавлении новых документов в ELT можно:

• Load = залить raw файлы в S3.
• Transform = запустить Spark-джоб, который обработает только новые/изменённые документы (data skipping через метаданные).

5. Гибридный подход для RAG

На практике большинство продакшн-систем используют комбинацию:

Пример из реального проекта (опыт автора):

• Extract: документация из Confluence и PDF из Google Drive.
• Load (raw): копирование в S3 bucket с префиксом /raw/2025-01-01/.
• Transform (ELT): Spark Structured Streaming читает raw, парсит Markdown/PDF, чанкует (recursive character splitter), вычисляет эмбеддинги через HuggingFace и сохраняет векторы в Pinecone.
• При изменении стратегии чанкинга — просто перезапускаем Spark-джоб с новыми параметрами, raw данные уже в S3.

6. Инструменты для реализации

6.1 ETL-стек для RAG

• Оркестрация: Airflow, Prefect, Dagster.
• Трансформация: Python-скрипты (PyMuPDF, Unstructured.IO), LangChain Document Loaders.
• Чанкинг: LangChain RecursiveCharacterTextSplitter, semantic chunking (NLTK, spaCy).
• Эмбеддинги: sentence-transformers, OpenAI API, FastEmbed.
• Векторное хранилище: Qdrant, Pinecone, Weaviate.

6.2 ELT-стек для RAG

• Оркестрация: Airflow (с SparkSubmitOperator) или Dask Distributed.
• Хранилище raw: S3, MinIO, ADLS, GCS.
• Движок трансформации: Spark (PySpark), Dask, Triton Inference Server.
• Управление версиями данных: Delta Lake, Iceberg, Hudi (для time-travel и rollback).
• Собственно чанкинг и эмбеддинги: UDF на Spark (ONNX, HuggingFace Spark NLP).

7. Критерии выбора: ETL или ELT для RAG

8. Ошибки при проектировании ETL/ELT для RAG

• Смешивать подходы без чёткой границы Когда чанкинг делается и в ETL, и в ELT — возникает размножение чанков и конфликт версий.
• Загружать эмбеддинги дважды Если эмбеддинги вычисляются в трансформе, а потом повторно в хранилище — потратите бюджет впустую.
• Игнорировать метаданные В ELT важно сохранить при каждом raw-документе версию источника, timestamp и hash, чтобы отслеживать дедупликацию и инкрементальность.
• Не учитывать стоимость хранения raw-данных Для 10M документов S3 с Glacier может оказаться дороже, чем хранение только векторов.

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

Задача Спроектировать гибридный ETL/ELT пайплайн для корпуса технических отчётов (PDF, ~50k документов).

Инструменты

• Docker Compose (локальное окружение)
• MinIO (S3-совместимое хранилище)
• Airflow (оркестрация)
• LangChain + PyMuPDF (парсинг и чанкинг)
• FastEmbed (эмбеддинги на CPU)
• Qdrant (векторная БД)
• PostgreSQL (для метаданных raw-файлов)

Шаги:

1. Развернуть MinIO, Airflow, Qdrant и PostgreSQL в Docker.
2. Реализовать DAG ETL: Extract (PDF через API MinIO), Transform (парсинг → чанки → эмбеддинги), Load в Qdrant. Положить raw-копию в MinIO с префиксом /raw/.
3. Реализовать DAG ELT: Extract (новые raw из MinIO → парсинг → эмбеддинги), замена старых чанков в Qdrant.
4. Добавить параметр chunk_size (256, 512, 1024) в Transform, который можно менять через Airflow Variable.
5. Написать тест: запустить ETL для 100 документов, потом переключить chunk_size на 512 и запустить ELT — проверить, что чанки обновились без повторной загрузки raw.

Ожидаемый результат Работающий гибридный пайплайн, где первичная загрузка выполняется через ETL (контроль качества, однократная трансформация), а обновления и эксперименты — через ELT (гибкость, скорость). Вы научитесь управлять версиями raw-данных и перестраивать стратегию чанкинга без перезагрузки всего корпуса.

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

11. Навигация

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

Навигация

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