Один RAG-конвейер на четыре разных PDF: как собрать пайплайн, где каждый ответ типизирован и снабжён цитатой

Технологии Олег Васильевич Клод 17.07.2026 5 мин чтения 9 просмотров
Один RAG-конвейер на четыре разных PDF: как собрать пайплайн, где каждый ответ типизирован и снабжён цитатой

Как построить единый RAG-конвейер для разных PDF, который без единой правки кода запускается на четырёх непохожих документах и на каждом выдаёт типизированный ответ со ссылкой на конкретный фрагмент? Такую архитектуру инженер Анджела Ши из Towards Data Science показала 17 июля 2026 года. Это вторая часть цикла «Enterprise Document Intelligence»: в первой каждый узел системы улучшали по отдельности, здесь их сшивают в один линейный пайплайн и проверяют на документах, которые «не похожи друг на друга».

Тезис автора жёсткий. Проверка RAG-системы не в том, что она отвечает на один вопрос по одному документу, а в том, выдержит ли она стандарт на 100+ страниц, препринт с arXiv и корпоративный отчёт с битым оглавлением одним и тем же кодом.

Единый RAG-конвейер: четыре кирпича вместо монолита

Архитектура собрана из четырёх независимых «кирпичей» (bricks). Первый парсит документ и возвращает реляционный набор данных с оглавлением и типизированный parsing_summary. Второй превращает шумный пользовательский ввод в структурированный бриф ParsedQuestion. Третий, ретрив, находит нужные страницы, комбинируя чтение оглавления через небольшую LLM с поиском по ключевым словам. Четвёртый отдаёт типизированный ответ, где на каждый пункт приходится одна цитируемая ссылка (citable span), плюс четыре индикатора качества контекста.

Всё это собирается в единственный вызов pdf_qa: на вход подаёте PDF и вопрос, на выходе получаете типизированный ответ и полный «аудиторский след» от формулировки вопроса до конкретной цитаты. Рабочий ноутбук выложен на GitHub в репозитории doc-intel/notebooks-vol1, туда можно подставить свой файл.

Инженерный принцип: кирпичи не знают друг о друге. Ни один модуль не импортирует другой. Контракт между ними не сырой словарь, а схема Pydantic. Каждый следующий кирпич потребляет типизированный объект предыдущего: line_df из парсинга, затем ParsedQuestion, затем пара anchor + context из ретрива.

Схема линейного RAG-конвейера из четырёх кирпичей

Почему один код должен работать и на arXiv, и на NIST

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

ДокументЧто проверяет
Научная статья «Attention Is All You Need» (15-страничный препринт с arXiv)Разбор вопроса с опечатками: «What are the options for positional encoding?», тут сразу две ошибки
Стандарт NIST Cybersecurity Framework 2.0Навигацию по сложной иерархической структуре
Оригинальная статья про Retrieval-Augmented GenerationРаботу с терминологически плотным текстом
Отчёт World Bank Commodity Markets Outlook (апрель 2024)Устойчивость к сломанному оглавлению

NIST CSF 2.0 здесь неслучаен. Это свежая редакция фреймворка кибербезопасности 2024 года с новой функцией Govern и глубокой иерархией разделов, идеальный стресс-тест для навигации по документу. А препринт про трансформеры проверяет не документ, а вопрос: пользователь напечатал с опечатками, и система обязана понять смысл. Так один и тот же RAG-конвейер для разных PDF доказывает свою универсальность.

Сломанное оглавление не приговор

Самый практичный кейс, отчёт World Bank со сломанным оглавлением. Реальные корпоративные PDF сплошь и рядом идут с битыми закладками, сбитой нумерацией, склеенными колонками, таблицами и сканами вместо текста. Наивный ретрив по такому файлу промахивается.

Решение автора гибридное. Кирпич ретрива читает собственное оглавление документа через небольшую LLM, а затем объединяет полученные страницы с результатами обычного поиска по ключевым словам. Если структура частично поехала, keyword-поиск подстрахует; если ключевые слова дают шум, оглавление сузит область. На наш взгляд, именно этот узел отличает учебный RAG от того, что переживёт встречу с настоящей корпоративной документацией.

Ретрив по документу со сломанным оглавлением

Боковые каналы: как parsing_summary меняет разбор вопроса

Самое интересное появляется, когда кирпичи работают вместе. Автор называет это «боковыми каналами» (side channels), их два.

Канал от парсинга к разбору вопроса

Первый передаёт компактную проекцию документ-уровневого синтеза от парсинга к разбору вопроса: тип документа (doc_type), число страниц (n_pages), типичные поля (typical_fields) и краткое резюме (summary). Зачем? Вопрос «what is the name?» разбирается по-разному, если перед вами резюме (doc_type=resume) или 200-страничный годовой отчёт. В первом случае речь про имя человека, во втором скорее про название компании или продукта.

Тонкость в реализации: этот канал идёт не через аргумент функции, а через PromptContext в теле запроса к LLM. Публичный API кирпича при этом не меняется, сигнатура остаётся parse_question(question, *, context=PromptContext(...)). Модули обмениваются контекстом, но не ломают контракты друг друга.

Петля обратной связи к ретриву

Второй боковой канал: петля обратной связи от генерации назад к ретриву. Генерация срабатывает не всегда с первого прохода: если найденного контекста не хватило, чтобы собрать ответ с честной цитатой, система возвращается к ретриву за дополнительными страницами вместо того, чтобы галлюцинировать.

Типизированные ответы и обязательные цитаты

Финальный кирпич отдаёт не абзац текста, а структуру, где на каждый пункт приходится ровно одна ссылка на исходный фрагмент. Это часть тренда, который называют «verifiable RAG» или «citation-first»: ответ должен быть проверяем, иначе в корпоративном контуре, с аудитом, комплаенсом и требованием снижать галлюцинации, ему нельзя доверять.

К ответу прилагаются четыре индикатора качества контекста, метрики, по которым видно, насколько надёжен собранный контекст под конкретный ответ. Они позволяют системе честно сказать «данных мало» вместо того, чтобы выдумать правдоподобный текст.

Pydantic вместо словарей

Почему автор так настаивает на схемах Pydantic между модулями? Обычный словарь молчит, когда в него положили не то: опечатка в ключе, пропущенное поле, строка вместо числа всплывёт где-то дальше по конвейеру, часто в самый неудобный момент. Типизированная схема валидирует данные на границе кирпича: неправильный объект просто не пройдёт. Пайплайн становится предсказуемым и тестируемым, а «аудиторский след» гарантированно полным, потому что каждый шаг оставляет структурированную запись.

Если вы работаете с чувствительными документами и вам важно, чтобы их содержимое не утекало наружу при обработке, модульная и локально контролируемая архитектура вроде этой, правильный ориентир. А для безопасного доступа к самим инструментам и моделям в России пригодится VPN и VPS от Sigma.

Хотите повторить схему сами: склонируйте doc-intel/notebooks-vol1, прогоните pdf_qa по четырём эталонным документам и подставьте свой PDF: конвейер напечатает типизированный ответ и след по каждому кирпичу.

Источники

Towards Data Science, единый RAG-конвейер на четыре разных PDF, каждый ответ типизирован и снабжён цитатой

Сбер: нейросети встроятся в ОС, а приложения соберёт ИИ под задачу
Читать следующую Сбер: нейросети встроятся в ОС, а приложения соберёт ИИ под задачу

Комментарии

0
?

Пока нет комментариев. Будьте первым!