Roadmap production ready RAG

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

В рабочем контуре важно не только подключить LightRAG и открыть красивый endpoint для чата. Нужно понимать, что будет с тяжёлой индексацией, если загрузок станет больше; как откатить изменение схемы; кто имеет право запускать reindex; почему retrieval вернул слабый контекст; что делать при сбое внешнего LLM API. Поэтому здесь появляются очереди, миграции, контроль безопасности, наблюдаемость и понятная стратегия масштабирования.

Этот 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 умеет парсить сайты и скачивать найденные документы. Для пользователя это удобный сценарий: дал URL — система сама забрала материалы и подготовила их для базы знаний. Но для production такой вход нельзя считать безобидным, потому что crawler начинает ходить во внешнюю сеть от имени инфраструктуры сервиса. Поэтому функция требует строгой защиты от SSRF и связанных рисков.

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

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

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

Alembic и миграции

В обоих контурах есть PostgreSQL. Пока система молодая, неявное создание таблиц при старте может казаться удобным. Но в production база быстро становится памятью проекта: документы, промпты, настройки, история чата, отчёты дедупликации. Поэтому нужна воспроизводимая схема миграций, а не скрытая магия на запуске приложения.

Roadmap:

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

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

Monitoring и observability

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

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

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

Логи должны позволять восстановить путь документа: загрузка, primary, final, dedup, ingestion, query usage. Для production это один из ключевых инструментов доверия: если ответ плохой, команда должна видеть, проблема в исходном файле, очистке, индексации, retrieval или уже в генерации.

Re-ranking и metadata filtering

Hybrid retrieval даёт хороший базовый слой, но production-поиск часто требует дополнительной настройки. На демо достаточно получить хоть какой-то релевантный контекст. В реальной базе знаний важнее стабильность: чтобы разные типы документов, источники и владельцы не смешивались там, где пользователю нужен точный ответ.

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

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

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

Scaling

Масштабирование RAG pipeline лучше делать по контурам. У чата, индексации, подготовки документов и хранилищ разные профили нагрузки, поэтому один общий «увеличим сервер» быстро становится грубым и дорогим инструментом:

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

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

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

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

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

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

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