Architecture (vue d’ensemble)

Aurora Nexus est une plateforme RAG auto‑hébergée composée de services spécialisés et d’un socle de stockage. L’objectif est de fournir :

• une ingestion robuste (multi‑formats),
• une recherche vectorielle + citations,
• un passage unique des appels LLM (Gateway + cache + observabilité),
• une UI d’administration et d’usage (multi‑langue).

1) Services (qui fait quoi)

• UI (ui/) : dashboard Next.js (admin + assistant + documents + observabilité).
• API (api/) : FastAPI (ingestion, query RAG, administration, auth, logs, settings).
• Ingestion (ingestion/) : worker Docling (conversion, chunking, embeddings, écritures DB/MinIO/Qdrant).
• Gateway (aurora_gateway/) : proxy LLM de production (cache + observabilité + providers BYOK).
• Stockage
  • Postgres : source de vérité (documents, jobs, settings, audit, logs, cache exact).
  • Qdrant : index vectoriel (chunks embeddings) + cache sémantique optionnel.
  • MinIO : stockage objet (uploads + artefacts ingestion + backups).
  • Redis : broker/back‑end Celery (tâches Gateway / tâches API).

2) Flux “ingestion”

1. Upload d’un fichier via UI/API → objet stocké dans MinIO (bucket uploads).
2. Création d’un job d’ingestion en base (Postgres).
3. Worker ingestion/ :
   • récupère le fichier (MinIO),
   • convertit/normalise (Docling),
   • chunking,
   • embeddings,
   • écrit les chunks dans Qdrant (payload + vecteurs),
   • écrit les artefacts (MinIO bucket artifacts) + métadonnées (Postgres).

3) Flux “requête RAG”

1. UI/API appelle POST /api/query (question + filtres).
2. L’API :
   • détermine la requête de retrieval (condense follow‑up si nécessaire),
   • interroge Qdrant (vector search + filtres),
   • compose un prompt déterministe (QUESTION + CONTEXT délimité),
   • appelle le LLM via Aurora Gateway (cache + observabilité),
   • renvoie la réponse + citations,
   • loggue l’exécution dans queries_log.

4) Observabilité & “enterprise safety”

• queries_log : statut, latence, modèle, coûts, cache, diagnostics retrieval.
• “No context” safe : si retrieval vide, la réponse doit rester utile sans inventer.
• “Follow‑ups” robustes : stockage d’état minimal par thread + résolution de références (ex: “point B”).