Roadmap production ready RAG

Текущая связка PFRAG и RAG уже показывает рабочую архитектуру: подготовка документов отдельно, retrieval и чат отдельно. Но production-ready RAG — это не только LightRAG и красивый endpoint для чата. Нужны устойчивые очереди, миграции, контроль безопасности, наблюдаемость и понятная стратегия масштабирования.

Этот roadmap описывает направления усиления. Это не список уже готовых функций, а план доведения pipeline до более надёжной эксплуатации.

Очереди и фоновые задачи

В PFRAG тяжёлые операции уже вынесены в Celery/Redis: OCR, парсинг сайтов, LLM cleanup, дедупликация, PDF export. В RAG ingestion сейчас описан через BackgroundTask FastAPI. Для production логично привести indexing pipeline к такой же устойчивой модели очередей.

Что стоит сделать:

• вынести ingestion и reindex в Celery/Redis или отдельный worker-контур;
• хранить retry policy и dead-letter сценарии;
• разделить очереди для OCR, LLM cleanup, embeddings и indexing;
• добавить лимиты конкурентности по типу задачи;
• показывать оператору не только статус документа, но и состояние очереди.

Это снизит риск, что тяжёлая индексация будет конкурировать с чат-API за ресурсы.

Auth, security и доступы

В RAG уже есть опциональный Bearer-токен и rate limiting. Для production этого мало, особенно если сервис принимает внешние документы и URL.

Нужны отдельные решения:

• нормальная модель пользователей, ролей и API-ключей;
• ограничение CORS конкретными доменами вместо открытой политики;
• аудит действий: кто загрузил документ, кто удалил, кто запустил reindex;
• секреты через vault или защищённое окружение, а не ручное хранение ключей;
• раздельные права на ingestion, chat, admin и document management.

Security claims здесь лучше формулировать осторожно: roadmap должен описывать, что нужно усилить, а не обещать безопасность без проверки.

SSRF protection для URL-парсинга

PFRAG умеет парсить сайты и скачивать найденные документы. Это полезная функция, но для production она требует строгой защиты от SSRF и связанных рисков.

Что стоит добавить:

• запрет private, loopback и link-local IP;
• DNS rebind checks;
• allowlist/denylist доменов;
• лимиты размера ответа и времени скачивания;
• ограничение типов контента;
• отдельную сетевую зону для crawler worker;
• журналирование всех внешних запросов.

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

Alembic и миграции

В обоих контурах есть PostgreSQL. Для production нужна воспроизводимая схема миграций, а не неявное создание таблиц при старте.

Roadmap:

• добавить Alembic для PFRAG и RAG backend;
• зафиксировать миграции для документов, промптов, настроек, истории чата и dedup-отчётов;
• разделить миграции и startup приложения;
• добавить проверку версии схемы при запуске;
• описать rollback-процедуры для критичных изменений.

Это особенно важно, если база знаний уже накопила документы и историю.

Monitoring и observability

Healthcheck RAG уже проверяет PostgreSQL, Qdrant и Neo4j. Следующий шаг — полноценная наблюдаемость.

Нужны метрики по нескольким слоям:

• ingestion latency и ошибки индексации;
• размер очередей и время ожидания задач;
• ошибки LLM/embedding providers;
• количество документов по статусам;
• частота query modes и среднее время ответа;
• доля пустых или слабых retrieval-ответов;
• расход внешних LLM API.

Логи должны позволять восстановить путь документа: загрузка, primary, final, dedup, ingestion, query usage.

Re-ranking и metadata filtering

Hybrid retrieval даёт хороший базовый слой, но production-поиск часто требует дополнительной настройки.

Направления развития:

• re-ranking retrieved chunks перед генерацией ответа;
• metadata filtering по источнику, дате, типу документа, проекту или владельцу;
• отдельные namespaces/collections для разных баз знаний;
• тестовые наборы вопросов для сравнения режимов naive, local, global, hybrid;
• ручная разметка плохих ответов и анализ причин.

Важно не добавлять re-ranking вслепую. Сначала нужны наблюдения: какие запросы ломаются, какой контекст возвращается и где теряются нужные документы.

Scaling

Масштабирование RAG pipeline лучше делать по контурам:

• PFRAG workers масштабировать по тяжёлым batch-задачам;
• RAG chat backend масштабировать отдельно от indexing workers;
• Qdrant и Neo4j настраивать под объём индекса и характер запросов;
• PostgreSQL разделить по нагрузке metadata/history и операционным отчётам;
• статические файлы и исходные документы вынести в объектное хранилище.

Такой подход сохраняет главную архитектурную идею: подготовка контента и ответы пользователю не должны мешать друг другу.

Риски внешних LLM API

Оба контура завязаны на внешние LLM или OpenAI-compatible providers: очистка, embeddings, entity extraction и генерация ответа. Это даёт гибкость, но добавляет риски.

Что нужно учитывать:

• rate limits и временные сбои API;
• стоимость повторной обработки больших документов;
• различия в качестве моделей для cleanup и ответа;
• приватность загружаемых документов;
• необходимость retry, backoff и fallback-политик;
• версионирование промптов и моделей, чтобы понимать, чем был обработан документ.

Production-ready версия должна делать эти зависимости явными. Тогда база знаний будет не просто работать на демо, а оставаться управляемой при росте документов, пользователей и источников.