
Les modèles d’embeddings généralistes (text-embedding-3, bge, e5) sont excellents sur du contenu courant, mais ils plafonnent dès qu’un domaine métier spécialisé entre en jeu.

Les logs d’une application LLM contiennent typiquement l’intégralité des prompts et des réponses du modèle, incluant les données personnelles que les utilisateurs ont introduites — nommément, incidemment ou en confidence.

Beaucoup d’agents IA développés avec LangGraph se contentent d’un état en mémoire qui disparaît à chaque redémarrage et de tools stateless qui réinitialisent leur contexte à chaque appel.

L’annonce de context windows à 1 million voire 2 millions de tokens a créé l’illusion que le RAG serait bientôt obsolète : il suffirait de tout mettre dans le prompt.

La plupart des pipelines RAG déçoivent en production pour une seule raison : la recherche vectorielle seule remonte souvent les mauvais documents en tête de liste.

La plupart des équipes qui dimensionnent leur infrastructure GPU pour servir un LLM se concentrent sur la taille du modèle, et sous-estiment massivement la consommation du KV cache.

Télécharger un modèle sur Hugging Face et l’intégrer directement dans un pipeline de production, c’est l’équivalent IA d’importer une dépendance npm sans jamais regarder son code source.

Dans tout chatbot ou assistant LLM à volumétrie élevée, une proportion importante des requêtes utilisateur sont sémantiquement équivalentes à des requêtes déjà traitées.

Dire que MCP est un standard d’intégration pour agents IA est une chose ; l’intégrer concrètement dans une application Python en est une autre.

Choisir sa base vectorielle est l’une des premières décisions structurantes d’un projet RAG, et probablement l’une des plus mal instruites.