Chunking et embeddings

L'essentiel

• Le chunking découpe chaque document en passages de quelques centaines de tokens ; c'est l'unité que l'on retrouve, que l'on cite et que l'on protège.
• Point de départ retenu (hypothèse) : découpage par structure (articles, clauses, titres) via Docling, taille cible 400 à 800 tokens, chevauchement 10 à 15 %, en gardant page et section dans les métadonnées.
• Chaque chunk porte dossier_id et acl_groups : c'est ce qui rend le filtre de permissions possible.
• Modèle d'embeddings : multilingue, sous licence MIT ou Apache 2.0, exécutable en local. Candidats : bge-m3, multilingual-e5-large, Qwen3-Embedding, nomic-embed-text v2 ; jina-embeddings-v3 est écarté (CC BY-NC) ⁵. Le choix se fera par mesure sur un corpus français.
• Ordre de grandeur mémoire : 1 million de chunks à 1 024 dimensions en float32 = environ 4 Go de vecteurs bruts, plus l'index. Changer de modèle d'embeddings oblige à tout réindexer.

Stratégies de chunking

Valeurs typiques trouvées dans les sources, toutes issues d'articles d'éditeurs et non d'études peer-reviewed ² Communauté :

• 256 à 512 tokens pour les questions factuelles ; 512 à 1 024 pour l'analyse et le multi-hop ;
• « start at 512 with 10 to 20% overlap » ;
• Open WebUI : 1 000 caractères, overlap 100, par défaut ³ ; LibreChat RAG API : 1 500 caractères, overlap 100 ⁴. Ces défauts sont en caractères, pas en tokens (environ 4 caractères par token en français : estimation grossière).

Cas particuliers

• Tableaux : un chunk par tableau ou par groupe de lignes avec en-tête répété ; conversion en Markdown pour l'embedding.
• Mails : un chunk par message (sans le fil cité) ; le sujet et la date sont préfixés au texte pour l'embedding.
• Très courts documents (courrier d'une page) : un seul chunk.
• Enrichissement contextuel : préfixer chaque chunk d'une ligne « Dossier X, pièce Y, section Z » avant vectorisation améliore souvent la recherche (pratique répandue, non mesurée ici) ; à tester.

Métadonnées par chunk

Le schéma complet est dans ingestion. Pour la recherche et la sécurité, les champs qui doivent être indexés dans la base vectorielle sont : dossier_id (filtre principal, index de partition), acl_groups (filtre secondaire), type, date_document, langue. Les champs d'affichage (chemin, page, section, bbox, texte) sont stockés dans le payload mais pas indexés.

Modèles d'embeddings candidats

Le français juridique est le critère ; la licence et l'exécution locale sont des prérequis. Les caractéristiques ci-dessous ne sont pas issues de nos recherches sauf pour jina-embeddings-v3 ; elles sont données de mémoire et marquées à vérifier Non vérifié. Les fiches détaillées sont dans la collection modèles.

Critères de choix

1. Qualité en français sur nos documents : mesurée par recall@10 et MRR sur le jeu de questions du corpus fictif, pas par un classement MTEB générique.
2. Longueur de contexte : 512 tokens suffisent si les chunks font 400 à 800 tokens ; un contexte plus long n'est utile que pour le parent-enfant.
3. Coût d'inférence : l'ingestion initiale vectorise des centaines de milliers de chunks ; la requête vectorise une phrase. Un modèle de 0,5 à 1 milliard de paramètres tient sur CPU en secours et sur GPU sans gêner le LLM (estimation à mesurer sur la machine candidate, voir inférence).
4. Sparse natif (bge-m3) : permet une recherche hybride sans moteur BM25 séparé, ce qui pèse dans Q-004.
5. Licence : MIT ou Apache 2.0 uniquement pour une Box commercialisée.

Coût mémoire des index

Calcul (estimation, arithmétique simple) : un vecteur de d dimensions en float32 pèse 4 × d octets.

À ajouter : l'index HNSW (liens du graphe, de l'ordre de quelques dizaines de pourcents du volume des vecteurs selon m : estimation), les métadonnées et le texte des chunks (souvent plus gros que les vecteurs), l'index BM25. pgvector rappelle que l'index doit tenir en mémoire pour être performant et que maintenance_work_mem conditionne sa construction ⁷. Qdrant propose la quantification scalaire, binaire ou produit et le stockage on-disk, avec un claim éditeur de réduction mémoire « up to 97% » ⁶ Constructeur.

Pour un cabinet, l'ordre de grandeur réaliste est de quelques centaines de milliers de chunks (hypothèse) : quelques gigaoctets, négligeable face aux 60 à 90 Go du LLM sur la machine candidate. Les modèles à 4 096 dimensions (Qwen3-Embedding-8B) multiplient tout par quatre sans gain garanti : à réserver aux tests.

Réindexation

Changer de modèle d'embeddings, de taille de chunk ou de parseur oblige à tout revectoriser : les vecteurs de deux modèles ne sont pas comparables. Prévoir dès le départ :

• une version de pipeline stockée dans chaque chunk (pipeline_version) ;
• une réindexation en double : nouvelle collection construite en arrière-plan, bascule atomique, ancienne conservée le temps de vérifier, puis supprimée ;
• une fenêtre de maintenance : sur CPU, revectoriser un million de chunks prend des heures (à mesurer) ; sur GPU, cela entre en concurrence avec le LLM ;
• le jeu d'évaluation rejoué avant bascule.

Questions ouvertes

Ce qu'il reste à tester

• Comparer les modèles d'embeddings sur du français juridiqueSur des questions juridiques en français, bge-m3 et multilingual-e5-large atteignent un recall@10 comparable ; le reranker bge-reranker-v2-m3 apporte un gain de MRR supérieur à celui du changement de modèle d'embeddings ; la recherche hybride (BM25 + vecteurs, RRF) bat chacune des deux recherches seules.À tester