memvid : un fichier .mv2 à la place d'une base vectorielle

Le problème : la mémoire d'agent coincée dans une pile de services

Une pile RAG classique suppose un serveur de vecteurs, un pipeline d'ingestion, une base de métadonnées et un mécanisme de synchronisation. Pour un agent qui tourne sur une seule machine, ou qui doit fonctionner sans réseau, cette pile est un coût d'exploitation sans contrepartie. memvid prend le problème par l'autre bout : le README décrit un système qui "packages your data, embeddings, search structure, and metadata into a single file". Le public visé est donc celui des agents de longue durée, des bases de connaissances d'entreprise et des systèmes offline-first, trois cas listés explicitement dans la section Use Cases. Le projet se présente aussi comme model-agnostic et multi-modal, ce qui implique que le choix du modèle d'embedding reste à la charge de l'intégrateur. La promesse n'est pas d'être plus rapide qu'une base vectorielle sur un cluster, mais de supprimer le cluster.

Smart Frames : de l'encodage vidéo appliqué à la mémoire

L'architecture s'inspire de l'encodage vidéo, non pour stocker de la vidéo, mais pour organiser la mémoire en séquence de Smart Frames. Le README définit une frame comme une unité immuable contenant le contenu, un horodatage, une somme de contrôle et des métadonnées de base. Les frames sont regroupées pour permettre compression, indexation et lectures parallèles. Quatre conséquences en découlent, telles que documentées : les écritures sont append-only et ne modifient pas les données existantes, les requêtes peuvent porter sur des états passés de la mémoire, l'évolution des connaissances est inspectable sous forme de timeline, et la sécurité après plantage repose sur des frames validées et immuables. C'est un choix de conception cohérent avec l'idée de capsule partageable, mais il faut noter ce que le README ne dit pas : aucune règle de compaction, de fusion de frames ou de gestion de la croissance du fichier n'est décrite. Un journal append-only qui n'est jamais tronqué grossit, et rien dans le matériel fourni n'indique comment ce point est traité.

Installation : crates, SDK et feature flags

Le README donne quatre points d'entrée. En Rust, il faut Rust 1.85.0 ou plus récent, puis ajouter la dépendance dans le Cargo.toml sous la forme memvid-core = "2.0". Les autres langages passent par npm install -g memvid-cli pour le CLI, npm install @memvid/sdk pour le SDK Node.js, et pip install memvid-sdk pour le SDK Python. La partie Rust est modulaire via des feature flags documentés dans un tableau : lex active la recherche plein texte avec classement BM25 via Tantivy, vec active la recherche par similarité vectorielle avec HNSW et des embeddings de texte locaux via ONNX, clip ajoute les embeddings visuels CLIP pour la recherche d'images, whisper la transcription audio, pdf_extract l'extraction de texte PDF en Rust pur, et api_embed les embeddings via API cloud (OpenAI). Le tableau du README est tronqué après temporal_t, donc la liste complète des flags n'est pas vérifiable à partir de ce matériel. Le point pratique : la recherche vectorielle locale dépend d'ONNX, donc la promesse d'absence d'infrastructure vaut pour les serveurs, pas pour les dépendances natives.

Ce que les chiffres du README ne permettent pas de conclure

Le README met en avant des chiffres précis : +35% sur LoCoMo, +76% en multi-hop, +56% en temporel par rapport à une moyenne sectorielle, 0,025 ms en P50 et 0,075 ms en P99, et un débit 1 372 fois supérieur à "standard". Ces valeurs proviennent du projet lui-même. La méthodologie annoncée est explicite (LoCoMo avec 10 conversations d'environ 26 000 tokens, évaluation open source, LLM-as-Judge), ce qui est un bon signe de reproductibilité, mais aucune de ces mesures n'a été reproduite ici et la "moyenne sectorielle" n'est pas définie dans le matériel fourni. La latence de 0,025 ms mérite en particulier une lecture prudente : elle ne dit rien du coût de génération d'embeddings, qui est souvent le vrai poste de dépense dans une recherche sémantique. Un lecteur qui a besoin de ces chiffres doit refaire l'évaluation plutôt que citer le README.

Une limite structurelle : le fichier unique comme point de contention

Le choix du fichier unique est aussi sa limite. Un .mv2 est décrit comme une capsule auto-contenue, partageable, avec des règles et une expiration. Partager un fichier entre plusieurs processus ou plusieurs machines suppose une stratégie de copie ou de verrouillage, et le README n'en décrit aucune. Les écritures append-only évitent la corruption des données existantes, mais elles n'impliquent pas que deux écrivains concurrents sur le même fichier produisent un résultat correct. Il faut donc considérer memvid comme un magasin à écrivain unique, ce qui le rend inadapté à un agent multi-tenant qui écrirait depuis plusieurs workers. Autre point : le format .mv2 est propre au projet. Un fichier de mémoire n'est lisible que par les outils memvid, à la différence d'un fichier Parquet ou d'une table SQLite que n'importe quel outil peut ouvrir. La portabilité annoncée est donc une portabilité entre machines, pas une portabilité entre écosystèmes.

Face à une base vectorielle embarquée

L'alternative la plus directe n'est pas un serveur de vecteurs, mais une base embarquée. SQLite avec une extension vectorielle, ou LanceDB, stockent elles aussi les vecteurs dans un fichier local et s'utilisent sans démon. La différence d'approche tient à trois points. D'abord, ces moteurs exposent une couche de requête générique (SQL, filtres, jointures) que memvid ne remplace pas : le README ne mentionne ni requête filtrée, ni jointure, ni schéma. Ensuite, leur format de fichier est documenté et souvent lisible par des outils tiers, ce qui n'est pas le cas de .mv2. Enfin, memvid ajoute deux éléments qui leur sont propres : la timeline de frames immuables pour l'inspection d'états passés, et le regroupement de frames inspiré de l'encodage vidéo pour la compression. Ces deux apports sont réels, mais ils répondent à un besoin d'audit et de débogage, pas à un besoin de requêtage analytique. Choisir memvid, c'est choisir la traçabilité plutôt que l'expressivité des requêtes.

Maintenance et licence

Le dépôt est sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions et de l'état des modifications. Le README ne signale aucune clause additionnelle, mais il ne constitue pas un avis juridique et une vérification du fichier LICENSE reste nécessaire avant toute redistribution. Sur le rythme de publication, les trois dernières versions listées (v2.0.140 le 27 mai 2026, v2.0.139 le 13 mars 2026, v2.0.138 le 3 mars 2026) montrent des intervalles irréguliers, de quelques semaines à plus de deux mois, avec un numéro de patch qui progresse vite. Le dépôt n'est pas archivé et le dernier push est daté du 14 juillet 2026. La conséquence pratique pour un intégrateur : la série 2.0 bouge, donc une dépendance figée sur memvid-core = "2.0" peut tirer une version plus récente que celle testée. Épingler une version exacte dans le Cargo.toml est le seul moyen de contrôler ce point, et un fichier .mv2 écrit par une version plus ancienne doit être rouvert après chaque montée de version pour vérifier que le format reste lisible.

Conclusion éditoriale

memvid convient aux agents embarqués ou hors ligne qui doivent transporter leur mémoire dans un artefact unique, et à ceux qui veulent inspecter l'évolution d'un état de mémoire. Il ne convient pas aux équipes qui ont besoin de mises à jour concurrentes, de filtrage par permissions ou d'une mémoire partagée entre plusieurs processus. Avant d'adopter, vérifiez la table des feature flags dans le README, la licence Apache-2.0 du dépôt et la version publiée sur crates.io, puis ouvrez un .mv2 avec le CLI pour confirmer que le format reste lisible sans le SDK.

Sources officielles

1. License: Apache-2.0
2. memvid/memvid on GitHub
3. Project website
4. README
5. Releases