Pitch: Construí um orquestrador open-source para pipelines RAG que sobrevive ao "Erro 429" da OpenAI

Se você já brincou com RAG (Retrieval-Augmented Generation), sabe que fazer um "Hello World" lendo um PDF de 2 páginas usando LangChain ou LlamaIndex é quase mágico. Leva 5 linhas de código.

Mas se você já tentou colocar isso em produção, sabe que o pesadelo começa rápido.

Você joga um edital de 500 páginas no pipeline, a taxa de requisições sobe e, de repente, a API de embeddings da OpenAI (ou qualquer outro provedor) te devolve um lindo 429 Too Many Requests. O pipeline quebra, o documento fica pela metade, e quando você tenta de novo, acaba pagando em dobro para processar (e vetorizar) os chunks que já tinham dado certo.

Foi para resolver exatamente essa dor que passei os últimos tempos desenvolvendo o CARQ (Context-Aware RAG Processing Queue).

O que é o CARQ?
Em resumo, é um sistema de orquestração de ingestão de documentos enterprise-grade desenhado para RAG. Ele processa PDFs, faz o chunking semântico e despacha para a API de embeddings, garantindo alta disponibilidade (testado com +10.000 chunks/minuto) sem colapsar a rede.

3 Decisões de Arquitetura que guiaram o projeto:
Em vez de empilhar dezenas de microsserviços, foquei em resiliência e facilidade de self-host:

1. Zero Brokers Externos (Viva o Postgres)
   A primeira tentação ao fazer filas em Python é subir um Celery + RabbitMQ ou Redis. Para simplificar a stack de quem vai rodar a infra, joguei tudo pro PostgreSQL. Ele atua como o banco relacional, a fila assíncrona (com status tracking) e o banco vetorial (via extensão pgvector).

2. Rate Limit Adaptativo e Circuit Breaker
   O sistema tem um rate limiter inteligente. Quando os workers detectam o código 429 (Too Many Requests), em vez de falhar a tarefa, o circuit breaker desarma, aplica um backoff exponencial com jitter e pausa as filas daquele worker temporariamente. Os dados não se perdem na memória.

3. Reprocessamento Cirúrgico (Idempotência)
   Se um documento falhar em 99% do processo por conta de uma instabilidade de rede ou erro no provedor LLM, o CARQ não joga tudo fora. Usando deduplicação baseada em hash do conteúdo, ele envia para a DLQ (Dead Letter Queue) apenas o chunk que falhou. Você refaz só o necessário.

Stack Técnica
Runtime: Python 3.11+

Web/Async: FastAPI + asyncio + aiohttp

Database: PostgreSQL 15+ (pgvector) + SQLAlchemy 2.0

Deploy: Docker, K8s (Imagens publicadas no Docker Hub e GHCR baseadas em Semantic Versioning)

Onde encontrar
Acabei de automatizar a esteira de CI/CD pelo GitHub Actions e a versão principal v1 já está disponível.

🔗 Repositório: https://github.com/whispering3/CARQ
🐳 Docker Hub: docker pull choquelnews/carq:1

Quero ouvir vocês
Publiquei esse projeto open-source para a comunidade e adoraria receber críticas sinceras.

Como vocês estão lidando com a ingestão de dados em larga escala para RAG hoje? Alguém mais sofre com os limites de concorrência das APIs? Se puderem dar uma olhada na arquitetura (tem um README bem detalhado lá) e me dizer onde eu posso melhorar, vou ficar muito agradecido.

E claro, se acharem a ferramenta útil, uma ⭐️ no repositório ajuda bastante!