Principe du chunking

Manticore Search propose désormais le paramètre chunk_strategy dans la définition d’une colonne vectorielle. Lors de l’insertion, le moteur découpe automatiquement chaque document en fragments (chunks) avant de générer les embeddings. Cette opération se fait au niveau du CREATE TABLE et ne nécessite ni pipeline d’ingestion externe, ni bibliothèque de découpage, ni table secondaire.

CREATE TABLE docs (
  title   text,
  content text,
  chunks  float_vector_array knn_type='hnsw' hnsw_similarity='cosine'
          model_name='Xenova/all-MiniLM-L6-v2' from='title,content'
          chunk_strategy='sentence' max_tokens='256' overlap_tokens='32'
);

Stratégies et paramètres

Cinq stratégies sont disponibles : truncate (ancienne valeur par défaut), mean, fixed, recursive et sentence. Les trois premières produisent un seul vecteur par document et s’appliquent à une colonne float_vector. Les trois dernières génèrent plusieurs vecteurs et nécessitent une colonne float_vector_array. Le paramètre max_tokens fixe la taille d’un chunk (ex. 256 tokens), overlap_tokens définit le chevauchement entre deux chunks (ex. 32 tokens) et max_chunks impose une limite supérieure de fragments par document.

Évaluation des performances

Sur le manuel Manticore (189 pages, ~298 k mots), le passage du modèle à fenêtre de 512 tokens à la stratégie sentence a fait passer le rappel @5 de 55,1 % à 83,3 % et le MRR de 0,44 à 0,70. Le coût mémoire a augmenté d’environ 2,5 × et le temps d’ingestion d’environ 4 ×, ce qui reste acceptable pour des bases de connaissances où la précision prime sur la latence d’insertion. Les requêtes ne sont jamais découpées : seules les données stockées subissent le chunking, ce qui préserve la rapidité du processus de recherche.

INSERT INTO docs (id, title, body) VALUES
  (1, 'Backup and restore runbook', 'Nightly backups run at 02:00 UTC ...');

Limites et considérations

Le chunking augmente la consommation RAM et le temps d’ingestion, ce qui peut devenir critique sur des clusters à ressources limitées. Le choix du nombre de tokens par chunk doit équilibrer la couverture sémantique et le nombre de vecteurs générés ; un max_tokens trop faible crée de nombreux fragments, augmentant la charge du moteur HNSW. De plus, la stratégie mean agrège les embeddings et ne résout pas le problème de perte d’information au‑delà de la fenêtre du modèle, alors que les stratégies fixed, recursive et sentence conservent chaque fragment séparément. Enfin, la mesure de rappel et de MRR présentée provient d’un seul jeu de données ; d’autres corpus pourraient afficher des gains différents.