Урок 4: RAG на русском — LlamaIndex + T-Pro 2.0 + pgvector + PaddleOCR

Чему вы научитесь

• Собирать русскоязычный RAG-стек без внешних SaaS-зависимостей
• Выбирать инструменты для parsing, OCR, embeddings, vector storage и generation без лицензионных сюрпризов
• Отличать Document AI для research от инструментов, которые можно безопасно тащить в production
• Строить retrieval по ГОСТам, ТУ, регламентам и внутренним инструкциям с источниками и ссылками
• Понимать, где в RAG-пайплайне начинаются риски по ПД и как их заранее отрезать

На русском языке RAG почти всегда упирается не в LLM, а в грязный вход. Плохо распарсили PDF, потеряли таблицу, разрезали пункт ГОСТа пополам, смешали header с body — и дальше уже никакой top-k=10 не спасёт. Поэтому в production-grade RAG надо проектировать не «чат по документам», а полный pipeline: parsing → OCR → chunking → embeddings → vector search → grounded answer.

Базовый стек для RU RAG

Что брать для parsing и OCR

Unstructured — нормальная стартовая точка

unstructured хорош тем, что это не очередной «волшебный OCR», а зрелый ETL-слой для документов: PDF, DOCX, HTML, email, PPTX и т.д. Официальный репозиторий открыт под Apache-2.0, телеметрия у core-библиотеки выключена по умолчанию, а коммерческая платформа живёт отдельно (Unstructured-IO/unstructured). Для корпоративного on-prem стека это правильная конструкция.

PaddleOCR — практически стандарт для multilingual RAG

Официальный репозиторий PaddleOCR прямо пишет про 100+ языков, Apache-2.0 и структурированный разбор документов для AI-пайплайнов (PaddleOCR repo). Для русского корпуса это один из самых практичных open-source OCR-инструментов: ГОСТы, техусловия, сканы с таблицами, смешанные layout’ы.

Donut и Nougat — только под специальные типы документов

Donut силён на формах и layout-heavy документах, но не заменяет весь OCR-стек (clovaai/donut). Nougat очень хорош для научных PDF и формул, но сам репозиторий отдельно говорит: код под MIT, а веса под CC-BY-NC, то есть для коммерческого production такой путь надо проверять особенно внимательно (facebookresearch/nougat).

LayoutLMv3 — research-only история

В research-паке LayoutLMv3 фигурирует как полезный Document AI инструмент. Но для production в корпорации ключевой вопрос — лицензия. Она не про enterprise deploy, а про non-commercial research. Поэтому в реальном промышленном контуре его разумнее рассматривать как исследовательский baseline, а не как боевой компонент — нужна проверка на конкретном usage scenario.

Retrieval: LlamaIndex, LangChain или Haystack

На практике эти инструменты не исключают друг друга.

• LlamaIndex силён именно в retrieval-heavy сценариях, индексах, node parser’ах и RAG-контурах (run-llama/llama_index).
• LangChain полезен как общий orchestration layer, особенно если проект уже использует его экосистему интеграций (langchain-ai/langchain).
• LangGraph нужен, когда RAG превращается в stateful workflow: retrieval → verification → human review → answer (langchain-ai/langgraph).
• Haystack хорош для команд, которым нравится явный pipeline-style и regulated/on-prem архитектура (deepset-ai/haystack).

В research-паке фигурирует оценка ~92% retrieval accuracy (по сторонним сравнениям 2026 года) у LlamaIndex против ~85% у LangChain на стандартных RAG-тестах. Но на 20 апреля 2026 года я не вижу открытой воспроизводимой официальной методики, на которую можно честно опереться как на строгий benchmark. Поэтому инженерный вывод надо формулировать аккуратнее: LlamaIndex часто удобнее именно как retrieval-специализированный слой, а LangChain/LangGraph — как orchestration.

Почему pgvector обычно лучше старта с отдельной vector DB

pgvector хорош по прозаической причине: он позволяет не вводить новую инфраструктуру там, где у предприятия уже есть PostgreSQL. Официальный репозиторий показывает HNSW, cosine / IP / L2 и обычный SQL вокруг векторного поиска (pgvector/pgvector).

Для корпоративного RAG это означает:

• меньше новых сервисов;
• понятная backup / DR-модель;
• проще согласование с ИТ;
• проще TCO — что важно для логики из урока p.4/01.

Qdrant разумно подключать позже — если вам действительно нужны отдельный vector-service, высокая интенсивность поиска или гибридная схема под много команд (qdrant/qdrant).

Архитектура RAG по ГОСТам и регламентам

flowchart LR
    A[ГОСТы, ТУ, регламенты, PDF-сканы] --> B[PaddleOCR / Unstructured]
    B --> C[Нормализация текста и метаданных]
    C --> D[Hierarchical chunking]
    D --> E[Embeddings]
    E --> F[pgvector / Qdrant]
    G[Запрос пользователя] --> H[Retrieval top-k]
    F --> H
    H --> I[T-Pro 2.0 / Qwen 3 14B]
    I --> J[Ответ со ссылками на документы]

На русской нормативке почти всегда лучше начинать с hierarchical chunking — иерархического разбиения по структуре документа, а не с наивного фиксированного куска по N символов. Причина простая: документ уже имеет структуру — раздел, подраздел, пункт, подпункт, таблица, приложение. Если её уничтожить на входе, retrieval начинает возвращать бессмысленные обрывки.

Точный claim про «в 2–3 раза лучше, чем naive chunking» из research-пака как универсальная цифра требует проверки. Но инженерно тезис верный: при нормативных и технических документах hierarchical chunking часто даёт существенно лучшие grounded answers — по исследованиям эффект может доходить до нескольких раз по метрикам релевантности в зависимости от корпуса — чем тупой split по длине.

Пошагово: как собрать первый русский RAG

1. Соберите корпус и очистите типы документов. Не смешивайте сразу всё: отдельно PDF-сканы, отдельно DOCX, отдельно HTML и письма.

2. Пропустите документы через parsing / OCR слой. Для сканов и таблиц — PaddleOCR; для обычных digital PDF и DOCX — Unstructured.

3. Сделайте нормализацию структуры. Сохраните название документа, номер, редакцию, раздел, страницу, заголовок, таблицу, приложение.

4. Чанкуйте по структуре, а не только по длине. Разделы и подпункты должны сохранять смысловую целостность.

5. Начните с pgvector. Для первой версии этого почти всегда достаточно и дешевле по TCO.

6. Поставьте генератор, который умеет по-русски. Для RU-корпуса лучше сразу брать T-Pro 2.0 (33B, на базе Qwen3-32B), а Qwen 3 14B держать как лёгкий билингвальный fallback.

7. Отдавайте ответ только со ссылкой на источник. RAG без цитаты на документ быстро превращается обратно в обычный чат.

Где начинаются риски по ПД

Очень часто RAG делают не только по ГОСТам, но и по внутренним документам: кадровые положения, претензии клиентов, письма, сервис-деск, протоколы комиссий. В этот момент retrieval становится не только технической, но и правовой системой.

Если в базе есть персональные данные или чувствительные сведения, сначала вернитесь к уроку p.3/01 про персональные данные. У RAG в этом смысле два типовых провала:

• в индекс попадают документы, которые не должны индексироваться целиком;
• в ответе модель цитирует чувствительные данные только потому, что retrieval их нашёл.

Поэтому production-RAG почти всегда требует document-level policy: что индексировать, что redaction’ить, что вообще держать вне поискового слоя.