Manticore Search : chunking automatique pour le vecteur sur longs documents
En bref
- Manticore Search ajoute le chunking automatique à ses vecteurs : au lieu de perdre les tokens au-delà du contexte du modèle, la base fractionne le document, embeds chaque chunk, et retourne la distance au chunk le plus proche.
- Cinq stratégies disponibles : truncate (défaut), mean, fixed, recursive, sentence.
- Sur le manuel Manticore (189 pages, ~298k mots), le recall@5 passe de 55,1% à 83,3% pour le contenu enfoui au-delà de la fenêtre du modèle, avec un coût : 2,5× la RAM et 4× le temps d'ingestion.
- Le feature s'ajoute simplement à la définition de table, sans pipeline, sans table de chunks, sans GROUP BY à réconcilier.
Ce que dit la source
Manticore expose un problème réel : si un document dépasse la fenêtre d'entrée du modèle d'embedding (par ex. 512 tokens), le contenu au-delà est simplement ignoré sans avertissement, et l'embedding ne représente plus fidèlement le document entier. L'article montre un exemple concret : un runbook de sauvegarde de 900 tokens cherche à se faire indexer avec un modèle limité à 512 tokens, et une requête sur la rotation de certificat TLS échoue parce que cette section est tombée hors de la fenêtre. Jusqu'à présent, l'utilisateur devait lui-même écrire du code pour fractionner, embarquer chaque morceau, puis combiner les résultats.
- Cinq stratégies de chunking : truncate (ancien défaut, abandon du contenu au-delà de la fenêtre), mean (moyenne des embeddings des chunks en un seul vecteur), fixed (taille fixe en tokens), recursive (fractionne sur les délimiteurs sémantiques), sentence (sur les limites de phrase).
- Le max_tokens définit la taille du chunk, overlap_tokens le chevauchement entre chunks consécutifs, max_chunks la limite par document.
- Une requête ne doit jamais être fragmentée : elle est toujours courte et rentre dans la fenêtre du modèle. Seuls les documents stockés sont fractionnés.
- Un document reste un seul résultat de recherche : les chunks concourent individuellement, mais Manticore retourne le document une fois, avec knn_dist() rapportant la distance au chunk le plus proche. k compte les documents, non les chunks.
- Gain mesuré sur le manuel Manticore : recall@5 passe de 55,1% à 83,3% pour le contenu enfoui, MRR de 0,44 à 0,70, au prix d'une RAM accrue (~2,5×) et d'un temps d'ingestion multiplié par ~4.
Dans les commentaires
Débat peu substantiel : les commentateurs reconnaissent l'utilité du feature pour le RAG maison, mais soulèvent rapidement que le problème n'est pas nouveau, les modèles modernes (BGE-M3, etc.) disposent de fenêtres de 8K à 32K tokens, ce qui rend le chunking moins critique. L'un d'eux conteste aussi l'hypothèse implicite de l'article selon laquelle élargir la fenêtre suffirait : même avec 8K tokens, fragmenter reste préférable à tout embarquer dans un vecteur unique, qui dilue le signal.
- Plusieurs commentateurs notent que l'article se concentre sur un problème résolu par les modèles récents : une fenêtre de 512 tokens est aujourd'hui exceptionnelle, les standards modernes étant plutôt 8K à 32K tokens. Le problème du feature n'est pas nouveau, juste désormais moins aigü.
- Un argument récurrent : élargir la fenêtre ne remplace pas le chunking. Même avec 8K tokens, embarquer un document entier dans un seul vecteur dilue le contexte et dégrade la qualité de récupération. Le chunking reste une stratégie valide indépendamment de la taille de la fenêtre.
- Critique sur la rédaction : l'article adopte un ton qui semble accuser la base de données de malhonnêteté (« Nothing anywhere told you »), alors que c'est un comportement attendu et documenté. Cela est décrit comme peu charitable envers le produit ou l'équipe.
Notre lecture
Le feature de chunking automatique simplifie l'ingestion pour les utilisateurs qui ne veulent pas coder leur propre pipeline. Techniquement solide et mesuré sur des données réelles. Cependant, le problème qu'il adresse (fenêtres étroites) est moins pressant qu'il y a deux ans : un utilisateur avec un modèle à 8K+ tokens n'a pas d'urgence à adopter cela. Utile pour le self-hosted RAG où le contrôle et la simplicité importent ; à évaluer sérieusement si vous avez déjà un problème de récupération sur documents longs, moins pertinent si vous avez déjà choisi un modèle avec fenêtre généreuse.