RAG Content Pipeline: от сырых документов к базе знаний
RAG-система начинается не с чата. До первого вопроса нужно привести документы к виду, который можно стабильно индексировать: достать текст, убрать мусор, сохранить структуру, удалить повторы и только потом отправить материал в retrieval-слой.
В этой связке PFRAG работает как входной цех для контента, а RAG — как индекс и API для вопросов по базе знаний.
Какие источники попадают в pipeline
PFRAG подтверждённо работает с ручной загрузкой файлов и парсингом сайтов. Входной контент может прийти из разных мест:
- PDF, DOCX и PPTX-документы;
- изображения PNG, JPG и JPEG, где нужен OCR;
- HTML и TXT-файлы;
- Markdown после первичной обработки;
- URL и сайты, которые обходятся BFS-парсером с ограничением глубины и числа страниц;
- документы, найденные на страницах сайта.
Для RAG-контента это важное отличие от простого upload endpoint. Источники редко бывают аккуратными: сайт может содержать навигационный шум, PDF — картинки и таблицы, а несколько документов могут повторять одни и те же регламенты.
Шаг 1. Приём и учёт файлов
После загрузки или парсинга сайта PFRAG сохраняет файл, создаёт запись в PostgreSQL и ведёт статус обработки. Статусная модель помогает не смешивать сырые файлы, черновой Markdown, очищенный Markdown и уже проиндексированные материалы.
Типичный путь файла:
uploaded— файл принят, но ещё не обработан.processing_primary— идёт OCR или извлечение текста.ready_to_ai— черновой Markdown готов к LLM-очистке.processing_final— идёт нормализация текста.ready_to_ingest— материал готов к отправке в RAG.ingested— файл добавлен в LightRAG.
Так проще понимать, где именно сломался документ: на OCR, на LLM-очистке, на dedup или при загрузке в индекс.
Шаг 2. Primary processing
Primary processing превращает файл в черновой Markdown. Для PDF, DOCX и PPTX используются инструменты извлечения текста и OCR, для изображений — распознавание, для HTML — извлечение текста через парсинг страницы.
У этого этапа есть два режима:
default— обычное извлечение текста;pdf— извлечение текста вместе с картинками и плейсхолдерами вида[[IMG_###]].
PDF-режим нужен, когда документ важно не только проиндексировать, но и потом восстановить в читаемый PDF с картинками после очистки или перевода.
Шаг 3. Final processing
На этапе Final processing PFRAG берёт черновой Markdown и прогоняет его через LLM. В проекте предусмотрены именованные промпты, настройки модели и параметры генерации: temperature, top_p, top_k, repetition_penalty, presence_penalty, max_tokens.
Практический смысл этого этапа — не «улучшить текст вообще», а привести материал к более ровному виду для индексации:
- убрать служебный шум;
- нормализовать таблицы;
- сохранить важные заголовки и структуру;
- не сломать плейсхолдеры картинок в PDF-режиме;
- получить
clean_md, который можно безопаснее отправлять в RAG.
Шаг 4. Дедупликация
Перед индексом важно убрать повторы. В PFRAG есть несколько режимов дедупликации:
vector_and_line— векторная и построчная дедупликация;vector_only— поиск похожих чанков по embeddings, cosine similarity и Jaccard;line_only— удаление повторяющихся строк;template_only— удаление строк по шаблону;full_dupl— удаление файлов, помеченных как полные дубликаты.
Это особенно полезно для сайтов, инструкций и выгрузок, где одинаковые блоки могут повторяться на многих страницах. Если такие блоки попадут в индекс, они начнут вытеснять более полезный контекст.
Шаг 5. Ingestion в RAG
После очистки PFRAG отправляет clean_md в RAG-контур. Если очищенной версии нет, может использоваться raw_md, но рабочая идея pipeline — доводить материал до ready_to_ingest и только потом индексировать.
RAG-сервер принимает документы через ingestion endpoint, проверяет дубликаты по хешу, извлекает текст для поддержанных форматов и запускает фоновую индексацию в LightRAG. На этом этапе текст разбивается на чанки, получает embeddings, сохраняется в Qdrant, а графовые сущности и связи уходят в Neo4j.
Шаг 6. Чат и API
После индексации база знаний становится доступна через чат. RAG-контур поддерживает обычный JSON endpoint, SSE-стриминг и WebSocket. Это позволяет подключить web-чат, Telegram-бота, внутренний сервис или API-to-API интеграцию.
Для пользователя весь сложный путь выглядит проще: загрузить документы, дождаться обработки и задать вопрос. Но качество ответа зависит от каждого предыдущего этапа: OCR, очистки, дедупликации, чанкинга и режима поиска.
Что получается на выходе
RAG Content Pipeline — это не один endpoint для загрузки файла, а цепочка с понятными зонами ответственности. PFRAG делает контент пригодным для индексации. RAG превращает подготовленный текст в базу знаний и отвечает на вопросы с учётом векторного и графового поиска.