Architettura per l'enterprise

Un sistema robusto, sicuro e scalabile: utenti locali, workspace personali, connettori dati e RAG isolato per ogni account.

Pipeline RAG completa

Client
Web UI
WordPress Plugin
REST API
Flask
Auth multi-utente
WorkspaceContext
SecretStore cifrato
API keys per workspace
Ingestion
Email IMAP
Microsoft Drive
Rate limiting
RQ Jobs
RAG
Document Processing
Collection per workspace
Diversity + Reranking
Conversation Memory
LLM
Regolo.ai
Mistral AI
Locale (Ollama, vLLM)

Come funziona ogni componente

📄

Document Processing

PDF, TXT, Markdown e audio vengono chunkati automaticamente. Upload manuali e snapshot da connettori finiscono nel workspace corretto, con metadata di origine tracciati.

🔍

Retrieval + Candidate Diversity

Similitudine vettoriale su collection Chroma dedicate per workspace. Source Diversity o MMR selezionano candidati migliori prima del reranking BGE locale, Regolo remoto o custom. Cache namespaced per evitare contaminazioni.

💬

Conversation Memory

Chat contestuali con auto-summary, namespaced per utente e conversazione. Quando la storia supera il threshold, i messaggi più vecchi vengono compressi in un summary.

🎙️

Audio Pipeline

Upload audio → STT (OpenAI-compatible) → indizzazione automatica. TTS per rispondere ad alta voce. Supporto MP3, WAV, M4A, WEBM, FLAC.

🔑

Sicurezza

Utenti locali con ruoli admin/user, password hash, API keys con scope per workspace, SecretStore cifrato per connector, rate limiting, input validation e sanitizzazione XSS.

🚀

Prestazioni

Gunicorn async con thread pool, streaming real-time NDJSON, LRU cache per retrieval, embeddings caching, retry con backoff su provider failure.

Codice che puoi leggere

# Stack principale
Backend: Flask 3.1, Python 3.11+
Auth: UserStore JSON + workspace personali
Vector DB: ChromaDB (persistent)
Embedding: sentence-transformers / Regolo cloud
Candidate selection: none / Source Diversity / MMR
Reranker: BAAI bge-reranker / Regolo / custom
LLM: Regolo.ai, Mistral, OpenAI-compatible
Server: Gunicorn (production)
Frontend: Flask templates + Vanilla JS
Ingestion: Email IMAP + Microsoft Graph
Plugin: WordPress PHP + S2S API calls per workspace

REST API, streaming, e oltre

📡

Endpoints

/api/v1/query, /api/v1/health, /api/v1/files, /api/v1/audio, /api/v1/tts, /api/v1/models

REST JSON OpenAPI
🌊

Streaming

Streaming token-by-token in NDJSON. Meta events con model info, source references e token usage.

NDJSON SSE Real-time
🔑

Auth granulare

API keys con scope: query, ingest, speech. Ogni key risolve sempre un utente e un workspace.

Scoped API Keys Session

Single-server robusto, pronto per crescere

RAGuardian è progettato per scalare da un singolo worker Gunicorn a un runtime multi-process con Redis, mantenendo isolamento per utente, stesse API pubbliche e zero perdita di stato.

🗄️

Stato condiviso con Redis

Rate limiter, retrieval cache, conversation memory, job state e active lock passano su Redis. Fallback in-memory per sviluppo. Nessuna modifica agli endpoint pubblici: cambia solo dove vivono i dati.

⚙️

Job queue non-blocchante

Rebuild dell'indice, upload PDF/audio e trascrizione diventano job asincroni (RQ su Redis). Le query utente non vengono mai bloccate dall'ingest. Admin mostra stato via polling; API restituisce 202 + job_id in modalità ?async=true.

🏎️

Gunicorn scalabile

Default produzione: workers=1, threads=16. Profilo avanzato: 2-4 workers, 8-16 threads dopo load test. Multi-worker sicuro solo con Redis attivo: niente perdita di conversazioni o job.

🧠

Vector store adapter

Interfaccia VectorStore con implementazione Chroma PersistentClient. Pronto per Qdrant, Chroma HTTP o vettore gestito quando i load test lo richiedono. Zero refactoring al momento del switch.

📊

Load test & osservabilità

Suite Locust: 50 utenti concorrenti su query, streaming, ingester rebuild parallelo. Metriche: error rate, p50/p95/p99 latency, queue depth, job time, CPU/RAM, Chroma e LLM latency separate.

🩺

Health & readiness

/api/v1/health include: redis_ready, queue_ready, queue_depth, active_jobs_count. Il tuo orchestrate/monitoring sa sempre se il servizio è pronto e sovraccarico.

📐 Criterio decisionale

Chroma locale resta il vector store iniziale. Il passaggio a Chroma server, Qdrant o vettore gestito avviene solo dopo load test reali che identificano il collo di bottiglia. Nessun premature optimization, solo decisioni basate sui dati.

# Runtime in produzione
$ gunicorn -c gunicorn.conf.py wsgi:application
$ rq worker rag-default
# Redis: required per scaling multi-worker
# Fallback in-memory: OK per sviluppo/test

Approfondisci

Leggi il codice su GitHub, esplora la documentazione API e pianifica il deployment.