Качество данных перед индексацией

В RAG-системах легко смотреть на самую заметную часть: чат, retrieval, embeddings, graph traversal. Но многие странные ответы рождаются раньше — в тот момент, когда в индекс попадает плохо распознанный PDF, повторяющийся footer, разваленная таблица или HTML-страница с навигационным шумом.

PFRAG закрывает именно этот слой подготовки. Он приводит документы к более чистому Markdown до того, как они попадут в LightRAG. Идея простая: если на входе у системы понятный, проверяемый материал, то дальше меньше случайности в embeddings, retrieval и финальном ответе.

OCR и извлечение текста

Первый риск — потерять важный текст ещё на входе. Для человека документ может выглядеть нормально: PDF открывается, слайды читаются, картинка содержит подпись. Для pipeline это всё ещё разные случаи обработки. PDF может оказаться сканом, презентация — хранить важный текст внутри слайдов, а изображение — требовать распознавания. В PFRAG для этого предусмотрен Primary processing:

• PDF, DOCX и PPTX проходят через извлечение текста и OCR-обработку;
• изображения конвертируются в PDF и распознаются;
• HTML разбирается через BeautifulSoup;
• TXT читается напрямую;
• для PDF есть режим с извлечением картинок и плейсхолдерами [[IMG_###]].

Задача этого этапа — не «магически понять» документ, а получить черновой Markdown, который можно открыть, проверить и уже потом отправлять дальше. Это важная пауза между сырым источником и индексом: если ошибка появилась здесь, retrieval потом будет честно искать уже по испорченному материалу.

Markdown extraction

Markdown удобен как промежуточный формат: его можно просмотреть, скачать, объединить, очистить и передать дальше по pipeline. Но сам факт, что текст удалось превратить в Markdown, ещё не делает документ готовым к RAG.

После первичного извлечения часто остаются вещи, которые человек быстро отфильтровал бы глазами, а retrieval воспринимает как равноправный контент:

• повторяющиеся header/footer из PDF;
• строки навигации и меню из HTML;
• таблицы, превращённые в нечитаемые фрагменты;
• разорванные абзацы;
• мусор от OCR;
• одинаковые юридические или служебные блоки на каждой странице.

Поэтому PFRAG разделяет raw_md и clean_md. raw_md сохраняет исходный след обработки, а clean_md становится рабочей версией для индексации. Это помогает не терять источник правды и одновременно не кормить RAG-контур шумом, который заранее можно убрать.

LLM cleanup и именованные промпты

Final processing в PFRAG использует LLM для очистки и нормализации текста. Здесь модель выступает не автором нового содержания, а аккуратным редактором извлечённого материала. В системе есть именованные промпты и настройки модели, которые хранятся в базе, потому что разные типы документов требуют разных правил обработки.

Например, для документа с таблицами нужно сохранить структуру, для PDF с картинками — не менять плейсхолдеры, а для HTML-страницы — убрать навигационный шум. Именованные промпты позволяют не держать эти правила в голове и повторять обработку одинаковым способом, особенно когда похожие материалы проходят через pipeline снова и снова.

LLM cleanup не должен придумывать новые факты. Его роль в pipeline — аккуратно привести уже извлечённый материал к формату, который лучше подходит для дальнейшего поиска: с более понятными абзацами, сохранёнными важными блоками и меньшим количеством случайного мусора.

Dedup modes

Дедупликация влияет на retrieval напрямую. Если одинаковый блок встречается десятки раз, он может снова и снова попадать в контекст ответа и вытеснять фрагменты, ради которых пользователь вообще задавал вопрос.

В PFRAG есть несколько режимов:

• vector_and_line — основной режим, совмещает embeddings и построчную очистку;
• vector_only — ищет похожие чанки через cosine similarity и Jaccard;
• line_only — убирает повторяющиеся строки;
• template_only — удаляет строки, совпадающие с заданным шаблоном;
• full_dupl — удаляет файлы, помеченные как полные дубликаты.

Здесь важен не только сам факт удаления повторов, но и контроль за тем, что именно было удалено. Отчёты dedup показывают состояние до и после обработки: файлы, страницы, токены и удалённые фрагменты. Это снижает риск, что полезная информация исчезнет незаметно под видом «очистки».

Chunking и overlap

Chunking появляется в двух местах. В PFRAG параметры chunk size и overlap используются в дедупликации, а в RAG LightRAG дальше разбивает текст для индексации и извлечения сущностей.

На этом этапе особенно заметно, насколько хорошо подготовлен Markdown. Слишком крупные чанки приносят в контекст лишний шум. Слишком маленькие могут разорвать связь между определением, условием и примером. Заголовки, таблицы и нормальные абзацы помогают разрезать текст более осмысленно — не просто по длине, а ближе к тому, как документ читает человек.

Как качество данных влияет на retrieval

Хороший retrieval зависит не только от embeddings и graph traversal. Он зависит от того, что именно было положено в индекс. Индекс не исправляет источник: он усиливает и распространяет его качество — хорошее или плохое — на все следующие этапы.

Если в базе много дублей, retrieval чаще вернёт повторяющийся контекст. Если таблицы разрушены, ответ может потерять числовую или структурную часть. Если OCR ошибся в ключевых терминах, поиск просто не найдёт нужное место. Если LLM cleanup слишком агрессивен, можно потерять важные детали.

Поэтому PFRAG в этой архитектуре — не второстепенный загрузчик файлов, а слой контроля качества перед индексом. Он делает RAG-контур более предсказуемым, потому что на вход приходит не сырой хаос, а подготовленный Markdown с понятной историей обработки.