La recherche vectorielle arrive souvent avec une infrastructure : service a deployer, reseau, memoire, authentification et systeme distribue a maintenir. Cela se justifie a certaines echelles, mais pas toujours pour un notebook, une application desktop, un appareil edge, un CLI ou un petit service RAG.
zvec adopte le modele de la base embarquee. Cette base vectorielle Apache-2.0 d’Alibaba tourne dans le processus : installez un SDK, ouvrez une collection locale et interrogez les vecteurs sans serveur. Elle combine similarite dense et sparse, plein texte natif, filtres scalaires, recherche hybride, stockage persistant et indexes en memoire ou sur disque.
La bonne question est moins « zvec contre toutes les bases vectorielles » que « quand la recherche vectorielle doit-elle etre une bibliotheque plutot qu’un service ? »
Les embeddings denses capturent le sens ; les vecteurs sparse preservent les signaux lexicaux. L'index determine vitesse, rappel, memoire et cout de construction.
Le FTS natif traite les termes exacts que les embeddings peuvent diluer sans moteur externe.
MultiQuery fusionne vecteur, texte et contraintes structurees dans un meme plan de recherche.
Ce qui distingue zvec
zvec tourne dans le meme processus que l’application. Aucun serveur de base ni saut reseau : une collection vit dans un chemin local et s’ouvre par SDK.
Cela simplifie developpement, packaging, execution offline et edge, et permet aux donnees de rester sur la machine. Des SDK officiels existent pour Python, Node.js, Go, Rust et Dart/Flutter.
Cette architecture definit aussi ses limites. Une bibliotheque embarquee n’apporte pas automatiquement API distante, controle multi-noeuds, replication inter-region, sauvegardes gerees ou scaling horizontal des ecritures. Ces responsabilites restent dans l’application.
Une collection en une minute
pip install zvec
import zvec
schema = zvec.CollectionSchema(
name="docs",
vectors=zvec.VectorSchema(
"embedding", zvec.DataType.VECTOR_FP32, 4
),
)
collection = zvec.create_and_open("./docs.zvec", schema=schema)
collection.insert([
zvec.Doc(id="a", vectors={"embedding": [0.1, 0.2, 0.3, 0.4]}),
])
results = collection.query(
zvec.VectorQuery("embedding", vector=[0.4, 0.3, 0.3, 0.1]),
topk=10,
)
Un schema reel ajoute champs scalaires et textuels, vecteurs sparse ou multiples et indexes. Dimension et type doivent correspondre au modele d’embedding utilise a l’ingestion et a la requete.
Dense, sparse et plein texte
Les embeddings denses trouvent des formulations differentes d’un meme concept. Les representations sparse et le plein texte conservent la precision lexicale necessaire aux codes produit, noms de fonction, termes juridiques ou messages d’erreur.
zvec prend en charge dense et sparse. La version 0.5 ajoute l’indexation plein texte native sur les champs string. Une application locale n’a donc plus a choisir entre semantique et mots-cles, ni a deployer un second moteur.
Recherche hybride avec MultiQuery
Une recherche de support peut exiger similarite, code d’erreur exact, filtre produit, date et isolation du tenant. Le chemin hybride de zvec combine vecteurs, plein texte et filtres scalaires via MultiQuery.
Le defi devient la fusion des scores et l’effet des filtres sur les candidats. Evaluez sur des requetes annotees avec rappel, MRR ou nDCG, pas sur quelques exemples convaincants.
Indexes en memoire et DiskANN
Les indexes ANN echangent de l’exactitude contre vitesse et efficacite. Les indexes en memoire offrent une faible latence mais deviennent chers lorsque volume et dimension augmentent.
La version 0.5 introduit DiskANN, qui garde l’essentiel de l’index sur disque pour reduire la RAM. La latence du stockage, le cache, la construction et les parametres de rappel deviennent alors importants.
L’affirmation « milliards de vecteurs en millisecondes » depend du materiel, de la configuration, de la dimension, du rappel et de la concurrence. Reproduisez le benchmark sur la machine et les donnees cibles.
Durabilite et concurrence
zvec utilise un write-ahead log pour resister aux crashes et coupures. Le WAL ne remplace pas sauvegardes, restauration testee, surveillance disque et plan de deploiement.
Plusieurs processus peuvent lire une collection, mais les ecritures sont exclusives a un seul processus. Ce modele convient aux services locaux read-heavy ; ce n’est pas un cluster multi-writer. Coordonnez l’ecrivain et testez redemarrages et mises a jour.
Place dans un stack RAG
zvec est la couche de stockage et recherche. Il ne parse pas les PDF, ne choisit pas les chunks, ne genere pas les embeddings et n’applique pas seul les autorisations.
Il faut encore ingestion, identite et suppression des chunks, versionnement du modele, filtres d’acces, evaluation, reranking, citations, sauvegarde et lifecycle.
Le modele in-process convient aux outils desktop, assistants embarques, agents de code locaux, tests, petits services et applications edge.
Comparaison
Face a FAISS : FAISS est une excellente bibliotheque de similarite. zvec ajoute schemas, documents, filtres, persistence, WAL, plein texte et requetes hybrides.
Face aux extensions vectorielles SQLite : SQLite excelle en relationnel. zvec est specialise dans les indexes ANN, vecteurs multiples et fusion semantique/texte.
Face a une base hebergee : le service heberge apporte acces distant, operations, replication et scaling. zvec supprime la frontiere de service et donne le controle local.
Checklist securite et operations
Les fichiers locaux peuvent fuiter. Protegez le dossier par permissions OS et chiffrement disque. Appliquez les filtres tenant et document avant que les resultats n’entrent dans le prompt.
Planifiez sauvegarde atomique, restauration, migrations d’embeddings, duree des rebuilds, suppressions, vecteurs invalides, monitoring du WAL et compatibilite des upgrades.
Conclusion
zvec rend la recherche vectorielle proche d’un SQLite embarque : installez, definissez un schema, ouvrez un chemin et interrogez localement. Dense, sparse, plein texte, filtres et DiskANN rendent ce modele utile au-dela des demos.
Il convient surtout aux applications mono-noeud qui privilegient faible overhead, donnees locales et recherche hybride plutot qu’un controle distribue gere. Mesurez le workload complet, respectez la limite d’un seul ecrivain et assumez persistence et autorisation dans l’application.
Si ces contraintes correspondent au produit, zvec peut retirer un service entier de l’architecture tout en conservant les primitives requises par le RAG moderne.