Индексация документов для RAG (PDF, DOCX, HTML, Markdown)

Типичный сценарий: клиент загружает 500-страничный PDF с таблицами и многоколоночной версткой, а RAG-система возвращает битые ответы — текст из колонок сливается, заголовки теряются, таблицы превращаются в кашу. Мы знаем, как этого избежать: качественный парсинг — фундамент любого RAG-пайплайна. За 5 лет мы обработали более 200 проектов разной сложности, и убедились: экономия на парсинге оборачивается потерей точности ответов.

Почему качество парсинга определяет успех RAG?

Современные RAG-системы, такие как те, что строятся на LangChain или LlamaIndex, требуют чистого структурированного текста для корректного чанкования и эмбеддинга. Если на входе — «каша», то и поиск будет хаотичным. Исследования показывают, что до 30% ошибок RAG вызваны именно плохим парсингом исходных документов. Мы используем стек: PyTorch для кастомных моделей, pdfplumber для PDF, BeautifulSoup и markdownify для HTML, python-docx для DOCX.

Какие форматы мы поддерживаем? — индексация документов для

Как мы парсим сложные PDF?

Возьмем реальный кейс: PDF с бухгалтерской отчетностью — 200 страниц, на каждой таблица с финансовыми данными. Стандартные библиотеки PyPDF2 или pdfminer теряют границы ячеек. Мы применяем pdfplumber с кастомной постобработкой:

from pathlib import Path
from dataclasses import dataclass

@dataclass
class ParsedDocument:
    text: str
    metadata: dict
    source_format: str
    page_count: int = None

class DocumentParser:
    def parse(self, file_path: str) -> ParsedDocument:
        path = Path(file_path)
        ext = path.suffix.lower()

        if ext == '.pdf':
            return self._parse_pdf(file_path)
        elif ext in ['.docx', '.doc']:
            return self._parse_docx(file_path)
        elif ext in ['.html', '.htm']:
            return self._parse_html(file_path)
        elif ext in ['.md', '.markdown']:
            return self._parse_markdown(file_path)
        else:
            raise ValueError(f"Unsupported format: {ext}")

    def _parse_pdf(self, path: str) -> ParsedDocument:
        # Для сложных PDF (с таблицами, колонками) — pdfplumber
        import pdfplumber
        with pdfplumber.open(path) as pdf:
            pages_text = []
            for page in pdf.pages:
                # Сохранение таблиц как markdown
                tables = page.extract_tables()
                text = page.extract_text() or ""

                for table in tables:
                    table_md = self._table_to_markdown(table)
                    text += f"\n\n{table_md}\n\n"

                pages_text.append(text)

        full_text = "\n\n---PAGE BREAK---\n\n".join(pages_text)
        return ParsedDocument(
            text=full_text,
            metadata={"source": path, "pages": len(pdf.pages)},
            source_format="pdf",
            page_count=len(pdf.pages)
        )

    def _parse_docx(self, path: str) -> ParsedDocument:
        from docx import Document
        doc = Document(path)

        elements = []
        for element in doc.element.body:
            if element.tag.endswith('p'):  # Параграф
                para = element
                style = para.style.name if hasattr(para, 'style') else ''
                text = element.text_content()
                if style.startswith('Heading'):
                    level = int(style.split()[-1]) if style[-1].isdigit() else 1
                    elements.append('#' * level + ' ' + text)
                elif text.strip():
                    elements.append(text)
            elif element.tag.endswith('tbl'):  # Таблица
                table = self._extract_table_from_docx(element)
                elements.append(table)

        return ParsedDocument(
            text='\n\n'.join(elements),
            metadata={"source": path},
            source_format="docx"
        )

    def _parse_html(self, path: str) -> ParsedDocument:
        from bs4 import BeautifulSoup
        with open(path, 'r', encoding='utf-8') as f:
            soup = BeautifulSoup(f.read(), 'html.parser')

        # Удаление скриптов и стилей
        for tag in soup(['script', 'style', 'nav', 'footer', 'header']):
            tag.decompose()

        # Извлечение структурированного текста
        from markdownify import markdownify
        text = markdownify(str(soup), heading_style="ATX")

        return ParsedDocument(
            text=text,
            metadata={"source": path, "title": soup.title.string if soup.title else ""},
            source_format="html"
        )

Структурированное извлечение метаданных

class MetadataExtractor:
    def extract(self, doc: ParsedDocument) -> dict:
        metadata = doc.metadata.copy()

        # Извлечение заголовков для навигации
        headers = re.findall(r'^#{1,3}\s+(.+)$', doc.text, re.MULTILINE)
        metadata['headers'] = headers[:20]  # Первые 20 заголовков

        # Извлечение дат
        date_pattern = r'\b\d{1,2}[./]\d{1,2}[./]\d{2,4}\b'
        dates = re.findall(date_pattern, doc.text)
        if dates:
            metadata['dates_mentioned'] = dates[:5]

        # Язык документа
        from langdetect import detect
        try:
            metadata['language'] = detect(doc.text[:1000])
        except Exception:
            metadata['language'] = 'unknown'

        return metadata

Подготовка к индексации

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

Для 1000-страничного PDF полный цикл (парсинг → чанкинг → эмбеддинг → индексация): 5-15 минут при использовании OpenAI Embeddings API. Собственные GPU на базе Triton Inference Server ускоряют эмбеддинг в 2-3 раза.

Что входит в работу?

• Аудит документов: анализ типов, объема, сложности.
• Разработка пайплайна: парсеры, чанкер, эмбеддер, загрузчик.
• Интеграция с векторной базой: Qdrant, ChromaDB, pgvector — на ваш выбор.
• Тестирование на метриках: recall@k, precision@k, latency p99.
• Документация и обучение: передача кода, описание архитектуры, обучение вашей команды.
• Поддержка: 3 месяца гарантии на баги и адаптацию под новые форматы.

Сравнение: готовые сервисы против кастомного решения

Процесс работы

1. Аналитика: вы присылаете 2-3 образца документов, мы оцениваем сложность и сроки.
2. Проектирование: выбираем стек (Hugging Face Embeddings, vLLM, etc.), проектируем пайплайн.
3. Реализация: пишем код парсеров и интеграцию с вашей RAG-системой.
4. Тестирование: прогоняем на ваших данных, подгоняем чанкинг и эмбеддинги.
5. Деплой: разворачиваем в вашей инфраструктуре (AWS, GCP, on-prem).

Ориентировочные сроки: от 2 недель до 2 месяцев в зависимости от объема и сложности. Стоимость рассчитывается индивидуально под каждый проект.

Стратегии чанкования: как разбивка влияет на точность RAG

Выбор стратегии чанкования напрямую влияет на recall@5 в вашем RAG. Слишком большие чанки (2000+ токенов) снижают точность поиска. Слишком маленькие (64 токена) теряют контекст.

Проверенные стратегии:

• Fixed-size с overlap: чанки по 512 токенов, перекрытие 64 токена. Хорошо для однородных текстов без сложной структуры.
• Sentence window: чанк = предложение + 2–3 предложения по бокам. Высокий recall, подходит для FAQ.
• Heading-based: разбивка по заголовкам документа. Идеально для технической документации и нормативов.
• Semantic chunking: нарезка по семантическим границам (SBERT cosine similarity). Лучшее качество, но требует дополнительных вычислений.

Мы тестируем несколько стратегий на ваших документах и выбираем по метрикам recall@5 и MRR.

Получите консультацию — пришлите образцы документов, и мы в течение 1 рабочего дня дадим оценку. Наш опыт: 200+ проектов, 5 лет на рынке, гарантия качества на каждый этап.

Data Engineering для ML: пайплайны, разметка и качество данных

«У нас много данных» — фраза, которая на деле часто означает «у нас много сырых логов в S3, которые никто не трогал два года». Перед тем как обучить модель, нужно понять, что вообще есть: какова структура, есть ли дубли, как часто меняется схема, насколько репрезентативна выборка.

Data Engineering для ML — не просто ETL. Это построение воспроизводимой инфраструктуры данных, которая делает обучение моделей надёжным, а переобучение — предсказуемым. По опыту нашей команды (8 лет в дата-инжиниринге, более 30 проектов в ML) каждая вторая проблема в продакшене связана не с архитектурой модели, а с качеством данных.

ETЛ-пайплайны для ML: чем отличаются от BI

ETL для аналитики и ETL для ML — разные задачи. В аналитике важна агрегация, в ML — индивидуальные записи с историей. В аналитике train/val/test split не нужен, в ML — критичен. В аналитике skew данных мешает интерпретации, в ML — напрямую влияет на качество модели.

Инструменты. Apache Spark (Wikipedia) для больших объёмов (10GB+): PySpark с DataFrames, оптимизации через partitioning и caching. dbt для трансформаций поверх DWH (Snowflake, BigQuery, Redshift) — декларативно, версионируется, тестируется. Pandas + Polars для объёмов до нескольких GB — Polars в 5-10x быстрее Pandas на типичных трансформациях.

Temporal splits. Для ML важно, что split по времени, а не случайный. Если данные временные (транзакции, события пользователей), случайный split даёт data leakage: модель видит «будущие» данные при обучении. Правило: train на периоде T1-T2, validation на T2-T3 (с gap для предотвращения leakage), test на T3-T4. Неправильный split может стоить 10–15% качества модели на валидации.

Инкрементальные пайплайны. Модель переобучается еженедельно на новых данных. Нужен пайплайн, который инкрементально добавляет новые записи к обучающей выборке, не перегружая всё с нуля. Delta Lake или Apache Iceberg — форматы с ACID-транзакциями, Change Data Capture, time travel.

Как избежать training-serving skew с помощью Feature Store

Feature Store решает проблему рассинхронизации между обучением и инференсом. Самая коварная ошибка в ML-инфраструктуре — training-serving skew: признак считается по-разному в обучении и в продакшене. Модель учится на «правильных» данных, а инференс получает другие.

Feast (open source) — офлайн store на Parquet/Delta в S3 для обучения, онлайн store на Redis для low-latency инференса (<10ms). Feature definitions как Python-код:

from feast import FeatureView, Field
from feast.types import Float32, Int64

user_features = FeatureView(
    name="user_features",
    entities=["user_id"],
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="avg_session_duration", dtype=Float32),
    ],
    ttl=timedelta(days=7),
    source=user_features_source,
)

Один definition, используется везде. Нет расхождений.

Потоковые признаки. Когда признак должен обновляться в реальном времени (количество транзакций за последние 10 минут), нужна потоковая обработка. Apache Kafka + Apache Flink или Kafka Streams для вычисления признаков в реальном времени → запись в онлайн store. Сложнее, дороже, нужно только когда staleness признаков критична для качества.

Разметка данных: как не потратить бюджет впустую

Разметка — самая трудоёмкая и недооцениваемая часть ML-проекта. Плохо размеченные данные не исправит никакая архитектура.

Label Studio — open source, поддерживает разметку изображений (bounding box, polygon, segmentation), текста (NER, классификация), аудио, видео. Поднимается за 10 минут через Docker. Для небольших команд — первый выбор.

Оценка качества разметки. Inter-annotator agreement — насколько согласны разметчики между собой. Cohen's Kappa > 0.8 — хорошо, 0.6-0.8 — приемлемо, < 0.6 — задача неоднозначна или инструкция плохая. Пересечение разметок (10-20% примеров размечают два независимых аннотатора) — обязательная практика.

Active learning. Не размечать случайные примеры, а выбирать те, на которых модель наиболее неуверена (low confidence, high uncertainty). Позволяет добиться того же качества при 50-70% объёма разметки. Modals, Prodigy, Label Studio поддерживают active learning workflows. На одном из проектов для NLP мы сократили бюджет на разметку в 2,5 раза за счёт active learning.

Синтетические данные. Когда реальных данных мало или получить их дорого. Для CV: рендеринг в Blender/Unity с реалистичными текстурами (domain randomization). Для NLP: parafrase через LLM, backtranslation. Риск: модель обучается на distribution синтетических данных, а не реальных — нужна осторожность и проверка на реальном holdout.

Качество данных: валидация и мониторинг

Great Expectations — de facto стандарт для data validation в ML-пайплайнах. Expectations — это декларативные утверждения о данных: «колонка age содержит значения от 0 до 120», «колонка user_id не содержит null», «распределение amount не отклоняется более чем на 20% от baseline». Запускается в пайплайне, при провале — блокирует прохождение.

Pandera — Pythonic alternative для pandas/polars DataFrames. Schema-based validation с type hints:

import pandera as pa

schema = pa.DataFrameSchema({
    "user_id": pa.Column(int, nullable=False),
    "score": pa.Column(float, pa.Check.between(0, 1)),
    "label": pa.Column(str, pa.Check.isin(["positive", "negative", "neutral"])),
})

Data freshness. Модель ожидает данные за последние N дней. ETL упал, данные не обновились — модель использует устаревшие признаки. Мониторинг свежести данных: timestamp последней записи в каждой таблице, алерт при задержке > порога.

Дедупликация. Дубликаты в обучающей выборке завышают метрики (одни и те же примеры в train и val) и искажают веса модели. MinHash LSH для приближённой дедупликации больших датасетов. Для точной — хэш по нормализованному контенту.

Инструменты валидации: сравнение

Хранилища и форматы

Для большинства ML-проектов на старте: Parquet в S3 + DVC для версионирования. Delta Lake или Iceberg — когда появляется потребность в инкрементальных обновлениях или time travel.

Что входит в проект по дата-инжинирингу для ML

Мы предоставляем полный цикл:

• Аудит существующих данных и пайплайнов (1 неделя).
• Проектирование архитектуры: выбор инструментов, форматов, способов разметки.
• Реализация ETL/ELT пайплайна с валидацией и мониторингом.
• Документация кода и процессов (model card, data card).
• Обучение вашей команды работе с пайплайном.
• SLA на сопровождение и поддержку.

Как мы строим пайплайн: пошагово

1. Аудит существующих данных. Профилирование: ydata-profiling (бывший pandas-profiling) генерирует HTML-репорт со статистиками, дистрибуциями, корреляциями, missing values за минуты.
2. Проектирование пайплайна. Определяем источники данных, частоту обновления, требования к latency признаков, объёмы.
3. Реализация и тестирование. Unit-тесты на трансформации, integration-тесты на пайплайн, data validation через Great Expectations.
4. Деплой и мониторинг. Алерты на freshness, quality checks, аномалии в объёмах данных.

Почему стоит доверить это нам

Мы занимаемся дата-инжинирингом и ML с 2016 года. За это время реализовали более 40 проектов — от построения пайплайнов для NLP-моделей до разметки датасетов для компьютерного зрения. Гарантируем воспроизводимость пайплайнов и полную прозрачность процессов. В каждом проекте используем инструменты с открытым исходным кодом, чтобы вы не были привязаны к вендору.

Свяжитесь с нами для бесплатного аудита ваших данных — оценим текущий пайплайн и предложим roadmap. Закажите построение ML-пайплайна под ключ.