Un développeur a remplacé avec succès les bases de données vectorielles par le Memory Agent pattern de Google pour son système de prise de notes Obsidian, stockant des mémoires structurées dans SQLite et les alimentant directement à Claude Haiku 4.5. Le système stocke environ 650 mémoires dans la fenêtre de contexte de 250k à environ 300 tokens par entrée de mémoire structurée, éliminant le besoin de Pinecone, Redis, ou des pipelines d'embeddings qui étaient auparavant requis pour donner aux assistants IA une mémoire persistante.

Cette approche remet en question l'hypothèse que la recherche vectorielle est nécessaire pour les systèmes de mémoire IA. Les calculs ont fondamentalement changé — les anciens modèles avec des limites de tokens de 4K-8K nécessitaient une récupération basée sur les embeddings pour trouver des documents pertinents sans tout charger dans le contexte. Mais avec la fenêtre de contexte de 250k de Claude Haiku 4.5, tu peux simplement déverser des centaines de mémoires structurées directement dans le prompt et laisser le modèle raisonner dessus. C'est un retour à une architecture plus simple qui contourne la complexité des pipelines d'embeddings, l'ajustement de recherche de similarité, et l'infrastructure de base de données vectorielle.

Bien que ce soit l'expérience d'un seul développeur plutôt qu'une recherche évaluée par les pairs, ça souligne un changement plus large qui se produit alors que les fenêtres de contexte s'élargissent. L'approche brille particulièrement pour les requêtes temporelles comme "qu'est-ce qui s'est passé le 1er février" ou "récapitule ma dernière réunion avec X" — exactement le genre de récupération structurée, basée sur les dates que les embeddings gèrent mal. Cependant, la limite de 650 mémoires signifie que ce pattern fonctionne pour les outils de productivité personnelle mais ne s'adaptera probablement pas aux bases de connaissances d'entreprise avec des millions de documents.

Pour les développeurs qui construisent des assistants IA, ça suggère que ça vaut la peine de questionner si t'as vraiment besoin d'une infrastructure de recherche vectorielle. Si ton cas d'usage implique des centaines plutôt que des millions de mémoires, et que tu as besoin d'une récupération temporelle ou structurée précise, le raisonnement LLM direct sur SQLite pourrait être plus simple et plus fiable que de construire des pipelines d'embeddings. L'insight clé : parfois la meilleure architecture est celle que tu n'as pas à construire.