Déployer un pipeline RAG en production

Le Retrieval-Augmented Generation (RAG) est devenu le pattern de référence pour construire des applications IA qui répondent avec précision sur un corpus documentaire privé. Voici un retour d'expérience sur la mise en production d'un pipeline complet.

Les 5 étapes du pipeline

1. Query — Capture de la question

La requête utilisateur est capturée et nettoyée. On extrait les entités clés, on normalise la langue. Quelques millisecondes.

2. Embed — Conversion en vecteur

La question est transformée en vecteur dense via un modèle d'embedding (OpenAI ext-embedding-3-small ou
omic-embed-text en local). Ce vecteur encode le sens sémantique de la question.

s const { data } = await openai.embeddings.create({ model: "text-embedding-3-small", input: query, }); const queryVector = data[0].embedding; // 1536 dimensions

3. Retrieve — Recherche vectorielle

On compare le vecteur de la question aux vecteurs de tous les chunks du corpus via une recherche cosine similarity. pgvector sur PostgreSQL permet de faire ça directement en SQL :

sql SELECT content, 1 - (embedding <=> ) AS similarity FROM documents ORDER BY embedding <=> LIMIT 5;

Les 3 à 5 chunks les plus proches sémantiquement sont sélectionnés.

4. Generate — Prompt augmenté + LLM

Les chunks récupérés sont injectés dans le prompt système. Le LLM génère une réponse en se basant exclusivement sur ce contexte — ce qui évite les hallucinations sur des données inconnues.

s const response = await openai.chat.completions.create({ model: "gpt-4o-mini", stream: true, messages: [ { role: "system", content: Contexte :\n }, { role: "user", content: query }, ], });

5. Stream — Réponse en temps réel

Le streaming SSE (Server-Sent Events) renvoie les tokens au fur et à mesure. La latence perçue est quasi nulle — l'écran s'affiche dès le premier token (180–300 ms).

Pièges à éviter en production

Chunking naïf

Découper un document tous les 500 caractères coupe souvent une phrase en deux. Résultat : des chunks sans contexte, des réponses incohérentes. Préférez un chunking sémantique par paragraphe ou section, avec un overlap de 20 %.

Pas de re-ranking

La recherche vectorielle n'est pas parfaite. Les 5 premiers résultats ne sont pas forcément les 5 meilleurs. Un re-ranker (Cohere Rerank, ColBERT) améliore significativement la qualité des réponses.

Contexte trop long

Injecter 10 chunks dans le prompt rallonge la latence et augmente les coûts. 3 chunks bien choisis valent mieux que 10 chunks bruités.

Pas de cache

Les embeddings sont coûteux à calculer. Mettez en cache les vecteurs des questions fréquentes. Côté LLM, le prompt caching d'Anthropic peut réduire les coûts de 90 % sur les prompts système répétés.

Métriques de production

Étape	Latence cible	Coût pour 1000 requêtes
Embedding query	< 50 ms	.02
Vector search (pgvector)	< 10 ms
LLM generation (streaming)	< 300 ms TTFT	.15–.80
Total	< 400 ms	.17–.82

Architecture de ce boilerplate

Ce projet implémente exactement ce pipeline via /api/search. Le endpoint reçoit une question, retourne un JSON structuré avec la réponse, les sources et la latence. La réponse peut être streamée ou retournée d'un bloc selon le cas d'usage.

Tout est open-source, auto-hébergeable, et configurable avec n'importe quel LLM compatible OpenAI (Ollama, Mistral, Anthropic via proxy).