On avait un problème simple : retrouver le contexte d'un client contacté il y a 6 mois. Emails dans Gmail, notes dans Notion, propositions dans Drive. L'information existait, mais dispersée. NEO est notre solution. Un assistant qui indexe tous nos documents et répond en citant ses sources. Voici comment on l'a construit.
Le concept : RAG (Retrieval Augmented Generation)
Le RAG fonctionne en deux étapes :
1. Indexation
On découpe chaque document en morceaux (chunks). Chaque chunk est transformé en vecteur via un modèle d'embedding. Ces vecteurs sont stockés dans une base vectorielle.
C'est comme créer un index de livre, mais au lieu de mots-clés, on indexe le sens.
2. Retrieval + Generation
Quand on pose une question, elle est aussi transformée en vecteur. On cherche les chunks les plus proches (similarité cosinus). Ces chunks sont injectés dans le prompt envoyé au LLM.
Le LLM génère une réponse basée sur ces documents, pas sur sa mémoire générale.
Avantage vs fine-tuning : Les données changent ? On ré-indexe. Pas besoin de ré-entraîner un modèle.
Notre stack technique
Embeddings : OpenAI text-embedding-3-small
1536 dimensions. Bon ratio qualité/coût. ~0.02$/1M tokens.
Vector store : ChromaDB
Open source, tourne en local. Nos données restent sur notre serveur en Suisse. Pas de dépendance cloud pour le stockage.
LLM : Claude 3.5 Sonnet
Pour la génération des réponses. On injecte les chunks pertinents dans le system prompt.
Backend : FastAPI + Python
Simple, rapide à itérer. L'API expose deux endpoints : /index (ajouter des docs) et /query (poser une question).
Résultats mesurés
6,677 documents indexés
Emails, PDF, notes de réunion, propositions commerciales.
Temps de réponse moyen : 0.8s
Dont ~0.3s pour le retrieval, ~0.5s pour la génération.
Précision
Sur un test de 50 questions dont on connaissait la réponse, NEO a trouvé le bon document dans 94% des cas.
Cas d'usage principal
"Donne-moi le contexte sur [Client X]" → Résumé de tous les échanges, dernière proposition, raison du dernier contact.
Ce qu'on a appris
1. La taille des chunks compte
Trop petits (100 tokens) : perte de contexte. Trop grands (1000 tokens) : bruit. On a convergé vers 400-500 tokens avec overlap de 50.
2. Les métadonnées sont précieuses
On stocke la date, le type de document, le client concerné. Permet de filtrer : "Que s'est-il passé avec Client X en 2024 ?"
3. Le prompt engineering du retrieval
On reformule parfois la question avant le retrieval. "Combien on a facturé ?" devient "facture montant tarif prix devis".
4. Les limites
NEO ne raisonne pas. Il retrouve et résume. Pour de l'analyse complexe ("Pourquoi ce client a-t-il refusé ?"), il faut encore un humain.
Ce qu'il faut retenir
- -RAG = Retrieval + Generation. On cherche d'abord, on génère ensuite.
- -ChromaDB permet de garder les données en local. Important pour la confidentialité.
- -Les embeddings transforment le texte en vecteurs. La similarité cosinus trouve les documents proches.
- -Chunk size optimal : 400-500 tokens avec overlap.
- -Le RAG est idéal quand les données changent souvent. Pas besoin de ré-entraîner.