Ce que ChatGPT recommandait — et pourquoi nous ne l'avons pas fait
La deuxième critique de ChatGPT portait sur l'absence de RAG (Retrieval-Augmented Generation) et d'embeddings. C'est la recommandation standard dans la littérature IA. Elle est pertinente en théorie. En pratique, elle suppose des contraintes que peu d'architectures B2B peuvent absorber :
- Une base vectorielle (Pinecone, Weaviate, pgvector) ajoute de la latence, de la complexité opérationnelle et un coût d'infrastructure
- Les embeddings doivent être recalculés à chaque mise à jour substantielle du corpus
- La pertinence du retrieval dépend de la qualité du chunking — un travail d'ingénierie non trivial
Notre alternative : la mémoire structurée fichier + DB
Le Synedre utilise une approche différente, plus pragmatique pour notre échelle :
memory/— fichiers Markdown structurés avec frontmatter typé (user, feedback, project, reference). Chargés en contexte au début de chaque session.SESSION_STATE.md— état courant de la session, tâches en cours, décisions prises. Rechargeable en cas de reset.ac_logger— logs structurés JSON Lines par automate, persistés en DB MariaDB. Interrogeables par pattern, date, erreur.- Tables
ps_ac_*— données runtime en base relationnelle, jamais en fichiers JSON.
Quand utiliser RAG vs mémoire structurée
Aristote nous enseigne que la sagesse pratique (phronesis) consiste à choisir le bon outil pour le bon contexte, pas à appliquer aveuglément les meilleures pratiques théoriques.
- RAG : pertinent si votre corpus dépasse 100 000 tokens et doit être interrogé sémantiquement par des utilisateurs finaux
- Mémoire structurée : suffisant si votre système est un agent opérationnel avec un corpus stable, des sessions identifiables, et une équipe technique réduite
La règle de décision : si vous pouvez indexer manuellement votre mémoire et la retrouver en moins de 200ms, vous n'avez pas besoin de RAG.