Activer la recherche sémantique

La recherche plein texte (FTS) de Notarium fonctionne toujours, sans aucune configuration. La recherche sémantique (vectorielle) est une fonctionnalité optionnelle : elle ajoute un classement hybride par le sens, mais elle entraîne une lourde pile native (onnxruntime + sqlite-vec, ~660 Mo sur le disque) ainsi qu'un modèle d'embeddings local qui se télécharge à la première activation (~600 Mo sur le disque et des centaines de Mo de RAM). Voilà pourquoi elle est désactivée par défaut et ne s'active que délibérément. Pour le fonctionnement interne de la recherche, voir Concepts : recherche.

Deux interrupteurs indépendants

Il est utile de distinguer deux niveaux — l'installation et l'exécution :

Installation — la présence ou non de la pile vectorielle native dans node_modules. L'image Docker l'embarque toujours, si bien que l'activer dans le conteneur ne demande aucune reconstruction. En exécution depuis les sources, le make deps standard ne l'installe pas (un node_modules local est ainsi ~660 Mo plus léger) — pour un travail vectoriel local, il faut make deps-vector.
Exécution — la variable VECTOR_SEARCH. Dans l'image publiée, elle vaut off par défaut.

Pour la recherche sémantique sous Docker, il suffit de basculer l'interrupteur d'exécution — la pile est déjà en place.

Activation

docker run -d --name notarium \
  -p 3000:3000 \
  -v notarium-data:/data \
  -e VECTOR_SEARCH=on \
  docouno/notarium:latest

(Un unique volume /data conserve tout l'état — la base de métadonnées, les index, vos notes, les artefacts d'export ; comme lors d'un lancement classique, voir Installation. Ici, il ne gagne que VECTOR_SEARCH=on.)

À la première activation, le modèle par défaut (bge-m3) se télécharge (~600 Mo sur le disque) et mobilise des centaines de Mo de RAM. L'indexation s'effectue en arrière-plan : la recherche plein texte est disponible tout de suite, pendant que les vecteurs se mettent à niveau.

Paliers de modèles

Le modèle se choisit via le couple EMBED_MODEL + EMBED_DIMENSIONS (la dimensionnalité doit correspondre au modèle) — c'est un réglage d'exécution sur une seule image, pas une build distincte :

Palier	Variables	RAM	Quand
off	`VECTOR_SEARCH=off`	0	Une machine peu puissante, ou la recherche par mots-clés suffit. Valeur par défaut de l'image.
compact	`VECTOR_SEARCH=on`, `EMBED_MODEL=Xenova/multilingual-e5-small`, `EMBED_DIMENSIONS=384`	~120 Mo	Homelab, un petit VPS.
full	`VECTOR_SEARCH=on` (par défaut : bge-m3, 1024)	~600 Mo	Une machine puissante ; plus de 100 langues, contexte long.

Modèles e5 asymétriques

Le palier compact (e5) exige les préfixes EMBED_QUERY_PREFIX="query: " et EMBED_PASSAGE_PREFIX="passage: " — les oublier revient à dégrader silencieusement la qualité de la recherche. Pour le bge-m3 symétrique, c'est l'inverse : il ne faut pas définir ces préfixes du tout.

Ressources sur une machine à l'étroit

Sur un hôte sans swap et doté de ~6 Go de RAM, la première indexation avec bge-m3 peut se heurter au plafond de mémoire. Deux leviers : opter pour le palier compact (e5-small), ou définir EMBED_CPU_MEM_ARENA=off — cela maintient la consommation autour de ~1,9 Go au prix d'un léger ralentissement. Pour la liste complète des paramètres d'embedding, voir la Référence.

Repli sur la recherche plein texte

Si VECTOR_SEARCH=off, ou si la pile native échoue à se charger pour une raison quelconque, la recherche continue de fonctionner en plein texte — sans erreur, et les résultats ont la même allure. La recherche sémantique n'est qu'un canal de classement supplémentaire par-dessus le FTS toujours actif, pas une dépendance obligatoire. Une instance sans vecteurs est une instance pleinement fonctionnelle.