Індексація документів для 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, тощо), проектуємо пайплайн.
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 років на ринку, гарантія якості на кожен етап.

Чому дата-інжиніринг визначає успіх ML-моделі

Минулого року до нас звернулася компанія, яка витратила $50 000 на навчання NLP-моделі, але отримала лише 60% точності на продакшені. Причина — data leakage через випадковий split часових даних. Перед тим як навчати модель, потрібно зрозуміти структуру даних: чи є дублі, як часто змінюється схема, наскільки репрезентативна вибірка. Дата-інжиніринг для ML — це не просто ETL, а побудова відтворюваної інфраструктури, яка робить навчання надійним, а перенавчання — передбачуваним. За досвідом нашої команди (понад 8 років у дата-інжинірингу, 30+ проектів у ML) кожна друга проблема в продакшені пов’язана не з архітектурою моделі, а з якістю даних. Замовте аудит ваших даних — оцінимо поточний пайплайн безкоштовно.

Як ETL-пайплайни для ML відрізняються від BI

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

Інструменти. Apache Spark для великих обсягів (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% якості моделі на валідації. Temporal split best practices (scikit-learn docs)

Інкрементальні пайплайни. Модель перенавчається щотижня на нових даних. Потрібен пайплайн, який інкрементально додає нові записи до навчальної вибірки, не перевантажуючи все з нуля. 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 — економія склала $15 000 на 100 000 розмічених прикладів.

Синтетичні дані. Коли реальних даних мало або отримати їх дорого. Для 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.

Типові помилки при побудові пайплайнів

• Пропуск перевірки свіжості даних. Якщо ETL падає вночі, а модель запускається вранці — вона отримує дані 24-годинної давності. Рішення: алерт при затримці > 30 хвилин.
• Відсутність версіонування даних. Не можна відтворити експеримент, бо дані змінилися. DVC або Delta Lake time travel виправляють це.
• Забувають про schema evolution. Нове поле з’являється, а пайплайн падає. Автоматичне виявлення змін схеми через Great Expectations.

Active learning дозволяє скоротити бюджет на розмітку до 50–70%. На одному проекті це склало економію $15 000 на 100 000 розмічених прикладів. Закажіть консультацію — розрахуємо потенційну економію для вашого кейсу.

Що входить у проект з дата-інжинірингу для ML

Ми надаємо повний цикл:

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

Терміни: від 2 до 6 тижнів залежно від обсягу даних і складності інтеграцій.

Як ми будуємо пайплайн: покроково

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

Чому варто довірити це нам

Ми займаємося дата-інжинірингом та ML з понад 8-річним досвідом. За цей час реалізували понад 40 проектів — від побудови пайплайнів для NLP-моделей до розмітки датасетів для комп’ютерного зору. Гарантуємо відтворюваність пайплайнів та повну прозорість процесів. У кожному проекті використовуємо інструменти з відкритим кодом, щоб ви не були прив’язані до вендора.

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