Base vectorielle et embeddings

Ces deux briques déterminent la qualité de la recherche documentaire. Ce sont aussi les deux choix les plus coûteux à modifier après coup.

Le mécanisme

1. Chaque fragment de document est transformé en vecteur par le moteur d'embeddings — une liste de nombres représentant son sens.
2. Ces vecteurs sont stockés dans la base vectorielle.
3. À la question, celle-ci est vectorisée par le même moteur, puis comparée aux vecteurs stockés.
4. Les fragments les plus proches sont retenus et fournis au modèle.

D'où la contrainte centrale : tous les vecteurs d'un index doivent provenir du même moteur d'embeddings. Deux moteurs différents produisent des représentations incomparables.

Le moteur d'embeddings

Réglages → Préférence d'embeddings.

Moteur intégré (par défaut) — s'exécute localement, ne demande aucune clé, aucune sortie réseau. Convient à la grande majorité des usages, y compris multilingues.

Moteurs externes — plusieurs fournisseurs sont pris en charge. Ils peuvent apporter un gain sur des corpus multilingues exigeants ou très spécialisés, au prix d'une sortie réseau à chaque indexation et à chaque question, et d'un coût à l'usage.

Changer de moteur invalide tous les index existants. Aucun message d'erreur ne le signalera : les recherches deviendront simplement mauvaises. Il faut réindexer l'intégralité des espaces. Décidez au démarrage.

Découpage du texte

Réglages → Découpage du texte règle deux paramètres :

• Taille des fragments — plus court, plus précis mais moins contextuel ; plus long, l'inverse.
• Recouvrement — le texte repris d'un fragment au suivant, pour ne pas couper une idée en deux.

Les valeurs par défaut conviennent à la plupart des corpus. Un changement n'affecte que les documents indexés ensuite.

Quand ajuster : des documents très structurés et courts (fiches, questions et réponses) gagnent à des fragments plus petits ; des textes argumentatifs longs (contrats, jurisprudence) gagnent à des fragments plus grands.

La base vectorielle

Réglages → Base vectorielle.

Base locale intégrée (par défaut) — stockée dans le répertoire de l'installation. Aucun service à exploiter, aucune sortie réseau, sauvegardée avec le reste. Elle tient sans difficulté des corpus de plusieurs dizaines de milliers de fragments, ce qui couvre la plupart des organisations.

Bases externes — plusieurs solutions du marché sont prises en charge, en version auto-hébergée ou en service géré. → Liste complète

Quand envisager une base externe

• Le volume dépasse ce que la base locale traite confortablement.
• Une base existe déjà dans votre organisation et vous souhaitez la mutualiser.
• Plusieurs applications doivent partager le même index.
• La haute disponibilité est requise.

Dans les autres cas, la base locale est le meilleur choix : moins de pièces mobiles, aucune sortie réseau, sauvegarde unifiée.

Un service géré signifie que vos vecteurs et leurs métadonnées sortent de votre périmètre. Sur une installation dont l'exigence est la souveraineté, cela annule le bénéfice d'un modèle local.

Organisation des index

Chaque espace de travail dispose de son propre espace de noms dans la base. C'est ce qui garantit qu'une recherche dans un espace ne peut atteindre les documents d'un autre.

Le Second Brain de chaque utilisateur dispose également du sien, séparé des espaces de travail.

Opérations de maintenance

Réindexer un espace. Nécessaire après un changement de moteur d'embeddings, ou lorsqu'un index est suspecté incohérent. L'opération retire les vecteurs et les recalcule à partir des documents.

Réinitialiser un espace. Efface les vecteurs de l'espace. Les documents restent dans la bibliothèque et doivent être réajoutés.

Vérifier le nombre de vecteurs. L'administration affiche le total indexé — utile pour confirmer qu'une indexation s'est bien déroulée.

Diagnostiquer une mauvaise recherche

Les seuils et le nombre de fragments se règlent par espace de travail. → Conversations