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

В RAG легко переоценить сам retrieval и недооценить подготовку данных. На практике плохой OCR, повторяющиеся блоки, сломанные таблицы и шумные HTML-страницы влияют на ответы сильнее, чем выбор красивого интерфейса чата.

PFRAG закрывает именно этот слой: он приводит документы к более чистому Markdown до того, как они попадут в LightRAG.

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

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

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

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

Markdown extraction

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

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

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

Поэтому PFRAG разделяет raw_md и clean_md. Это помогает не терять исходник и при этом иметь отдельную версию для индексации.

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

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

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

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 до chunking важно: заголовки, таблицы и абзацы помогают разрезать текст более осмысленно.

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

Хороший retrieval зависит не только от embeddings и graph traversal. Он зависит от того, что именно было положено в индекс.

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

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