Pourquoi j'ai créé une mémoire d'agent locale d'abord

Lorsqu’un agent IA a besoin de se souvenir de ce qu’il a fait, la plupart des feuilles de route des produits pointent directement vers les intégrations vectorielles. La promesse est simple : transformer une conversation en un point de grande dimension, le stocker, puis demander au modèle de trouver le point le plus proche. En pratique, cette promesse entraîne de nombreux coûts cachés : latence du cloud, stockage opaque et dépendance à un modèle d'intégration constamment entraîné. En tant qu'ingénieur de données qui passe chaque jour à équilibrer l'efficacité du stockage et la vitesse des requêtes, j'ai trouvé ces compromis difficiles à accepter pour un outil qui devrait être aussi immédiat qu'un fichier local.

Au cours des premiers mois de création de LoreConvo, j'ai cherché à prouver qu'un moteur de recherche en texte intégral bien réglé pouvait donner la même qualité de rappel sans le bagage d'intégrations. Le résultat est une couche de mémoire locale qui réside dans un seul fichier SQLite, fonctionne hors ligne et s'intègre à toutes les principales surfaces d'IA que j'utilise. Ci-dessous, j'examine le problème de la mémoire intégrée uniquement, j'explique pourquoi SQLite + FTS5 est une alternative pratique, je partage ce que j'ai observé en utilisation réelle et je décris les scénarios dans lesquels une approche hybride a toujours du sens.

Les intégrations semblent puissantes, mais elles cachent la complexité

Les modèles d'intégration sont attrayants car ils transforment n'importe quelle chaîne en un vecteur de taille fixe. Une fois que vous avez un vecteur, vous pouvez le déposer dans un index du voisin le plus proche et récupérer des sessions "similaires" avec un seul produit scalaire. Le modèle mental est clair et de nombreux ...
[Courte citation de 8% de l'article original]