Contexte et limites des approches actuelles

Les solutions de mémoire d’agent se répartissent en trois familles distinctes. La première lie l’utilisateur à un environnement propriétaire, ce qui contraint le modèle à extraire les souvenirs depuis l’historique de conversation et à négliger les connaissances du monde. La deuxième repose sur une pile technologique lourde : pgvector, Neo4j et un LLM dédié à la sélection des faits à retenir. Cette complexité augmente le temps d’administration et introduit des appels supplémentaires qui ralentissent le modèle. La troisième, dite « high‑modernist », transforme la mémoire en graphe logique, mais elle isole les informations dans des nœuds qui perdent leur contexte, rendant la récupération peu fiable. Toutes ces architectures traitent la mémoire comme un processus dynamique plutôt que comme un jeu de données statiques.

Architecture du format memoryfield

Le format memoryfield se matérialise sous forme d’une archive ZIP contenant des fichiers Markdown (*.md) et, de façon optionnelle, une base SQLite nommée nomic-embed-text-v1.5.sqlite3. Chaque page Markdown possède un en‑tête YAML qui décrit les métadonnées essentielles : titre, horodatage de création et de mise à jour, identifiant UUID et résumé. Le texte du corps suit immédiatement l’en‑tête. Cette structure impose une taille maximale d’environ 8 KB, soit près de 2 000 tokens, afin que chaque page puisse être encodée en un vecteur d’embedding utilisable par le moteur de recherche sémantique.

---
title: Carbon Fibre Woks
created: '2026-03-01T09:00:00Z'
updated: '2026-08-22T14:30:00Z'
uuid: 6aa615f0-486f-48a7-a210-ba4f5ff18c8b
summary: Thermal properties of carbon fibre cookware
---
Carbon fibre woks conduct heat evenly, but...

Le choix du Markdown garantit la lisibilité directe par le modèle, éliminant le besoin de découpage en fragments ou de résumés intermédiaires. La présence d’une base SQLite vectorielle permet d’effectuer une recherche sémantique en une seule requête, sans recourir à un graphe de liens hypertexte.

Mécanisme de recherche sémantique et performance

Contrairement aux wikis de type Karpathy, où l’agent doit parcourir chaque nœud du graphe – chaque étape nécessitant un appel d’outil d’une durée estimée à 2‑3 secondes – le memoryfield utilise un index vectoriel pour identifier les pages pertinentes en un appel de recherche, suivi d’un appel de lecture parallèle. Ainsi, le nombre maximal d’appels d’outil passe de N+1 (avec N profondeur de graphe) à 2, réduisant le temps d’attente de plusieurs dizaines de secondes dans les scénarios profonds. Cette réduction du nombre d’interruptions minimise également l’injection de tokens non pertinents dans la fenêtre de contexte du modèle.

Contraintes et perspectives d’évolution

Le principal compromis du format réside dans la limite de 8 KB par page : les documents volumineux doivent être fragmentés manuellement, ce qui impose une discipline de rédaction à l’agent. De plus, la qualité de la recherche dépend de l’embedding utilisé ; un modèle d’embedding plus petit réduira la précision, tandis qu’un modèle plus grand augmentera le coût de calcul. La dépendance à SQLite impose également une gestion de concurrence limitée, ce qui peut devenir un goulot d’étranglement dans des environnements multi‑agents. Malgré ces restrictions, le memoryfield offre une solution portable, indépendante de toute plateforme propriétaire, et exploite directement la capacité du LLM à générer et consommer du texte structuré.