Un sistema robusto, sicuro e scalabile: utenti locali, workspace personali, connettori dati e RAG isolato per ogni account.
PDF, TXT, Markdown e audio vengono chunkati automaticamente. Upload manuali e snapshot da connettori finiscono nel workspace corretto, con metadata di origine tracciati.
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.
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.
Upload audio → STT (OpenAI-compatible) → indizzazione automatica. TTS per rispondere ad alta voce. Supporto MP3, WAV, M4A, WEBM, FLAC.
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.
Gunicorn async con thread pool, streaming real-time NDJSON, LRU cache per retrieval, embeddings caching, retry con backoff su provider failure.
/api/v1/query, /api/v1/health, /api/v1/files, /api/v1/audio, /api/v1/tts, /api/v1/models
Streaming token-by-token in NDJSON. Meta events con model info, source references e token usage.
API keys con scope: query, ingest, speech. Ogni key risolve sempre un utente e un workspace.
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.
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.
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.
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.
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.
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.
/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.
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.
Leggi il codice su GitHub, esplora la documentazione API e pianifica il deployment.