L'ordre de grandeur, et pourquoi il surprend
Sur les chaînes documentaires que j'exploite, une réindexation complète consomme l'équivalent de plusieurs mois de requêtes utilisateurs. Le rapport surprend parce que les deux opérations ne se ressemblent pas.
Une requête traite quelques milliers de jetons. Une réindexation traite l'intégralité du corpus : chaque document lu, découpé, transformé en vecteurs. Sur cinquante mille fragments, l'opération représente des dizaines de millions de jetons.
Ce déséquilibre reste invisible tant que personne ne rapproche les deux lignes, parce qu'elles ne tombent pas au même endroit : l'une est une facture d'inférence mensuelle, l'autre un pic ponctuel que l'on attribue au projet plutôt qu'au système.
Les quatre déclencheurs légitimes
Une réindexation complète se justifie dans quatre cas, et dans quatre seulement. Hors de ces cas, elle est une habitude.
Le changement de modèle d'embarquement, d'abord. Les vecteurs produits par un modèle ne sont pas comparables à ceux d'un autre : il faut tout recalculer. C'est ce qui fait de ce choix la décision la moins réversible de la chaîne, comme rappelé dans les embeddings expliqués à une direction.
Le changement de découpage, ensuite, pour la même raison : les fragments ne sont plus les mêmes objets.
La correction d'une erreur systématique d'extraction, troisième cas, quand on découvre que tout un format de document a été mal lu.
Et la reprise d'un corpus dont on ne connaît pas l'état, quatrième cas, qui arrive lors d'une reprise de système. Le diagnostic préalable figure dans reprendre un système d'IA construit par quelqu'un d'autre.
Ce qui doit être incrémental, et ne l'est presque jamais
- Les documents ajoutés, qui ne demandent que leur propre traitement.
- Les documents modifiés, repérés par leur date de dernière écriture ou une empreinte de contenu.
- Les documents retirés, dont les fragments doivent disparaître de l'index sous peine de réponses fondées sur des pièces supprimées.
- Rien d'autre. Un corpus dont deux pour cent des pièces ont bougé ne justifie pas de recalculer les quatre-vingt-dix-huit autres.
Pourquoi les équipes réindexent tout
La reprise intégrale est programmée parce qu'elle est simple à écrire et qu'elle ne peut pas se tromper. C'est un choix de confort d'ingénierie, rarement assumé comme tel.
Une reprise incrémentale demande de savoir ce qui a changé, donc de conserver un état : empreintes, horodatages, journal des suppressions. C'est une centaine de lignes de plus et une source de bogues.
La reprise intégrale, elle, part de zéro à chaque fois. Elle est correcte par construction, et elle coûte cinquante fois plus.
Le bon arbitrage dépend de la volumétrie. En dessous de quelques milliers de fragments, la simplicité l'emporte sans discussion. Au-delà de quelques dizaines de milliers, l'incrémental devient obligatoire, et le refuser revient à payer une rente pour éviter une journée de développement.
Le réglage intermédiaire qui règle la plupart des cas
Incrémental au quotidien, reprise intégrale trimestrielle : ce compromis capte l'essentiel du gain sans exiger un état parfait. C'est la configuration que je déploie le plus souvent.
L'incrémental quotidien traite les ajouts, modifications et suppressions du jour. Il est rapide, peu coûteux, et il peut dériver légèrement : un document oublié, une suppression mal propagée.
La reprise trimestrielle rattrape cette dérive. Elle coûte cher, quatre fois par an au lieu de cinquante-deux, ce qui divise le poste par treize.
Ce rythme s'inscrit naturellement dans le rendez-vous d'entretien décrit dans ce qui occupe l'équipe la deuxième année, où il rejoint le rejeu du jeu de tests et la relecture de la fiche du système.
Le calcul à faire une fois
Multiplier le nombre de fragments par le nombre de reprises intégrales annuelles, et comparer au nombre de jetons envoyés en requêtes sur la même année. Si le premier dépasse le second, le système consomme plus à se maintenir qu'à servir.
Ce que ça change à la décision de découpage
Un découpage plus fin multiplie le nombre de fragments, donc le coût de chaque reprise, et cette conséquence n'apparaît jamais au moment du choix. Elle mérite d'être posée.
Passer d'un fragment par section à un fragment par paragraphe peut multiplier le volume par cinq. La qualité de récupération y gagne parfois ; le coût de maintenance y perd toujours, et de façon récurrente.
Le bon réflexe consiste à chiffrer les deux avant de trancher : le gain mesuré sur le jeu de tests d'un côté, le surcoût annuel de reprise de l'autre. La comparaison prend une heure.
Dans la majorité des cas que j'ai instruits, le découpage plus fin n'apportait rien de mesurable, et il avait été adopté par défaut. Le sujet est traité sous son angle qualité dans découper un document.
Questions fréquentes
Quand une réindexation complète est-elle nécessaire ?
Au changement de modèle d'embarquement, au changement de découpage, après la correction d'une erreur systématique d'extraction, et lors de la reprise d'un corpus dont l'état est inconnu.
Pourquoi les équipes réindexent-elles tout ?
Parce que la reprise intégrale est simple à écrire et correcte par construction, alors que l'incrémental demande de conserver un état. C'est un confort d'ingénierie qui se paie en rente.
Quel rythme adopter ?
Incrémental quotidien pour les ajouts, modifications et suppressions, plus une reprise intégrale trimestrielle qui rattrape la dérive. Quatre reprises par an au lieu de cinquante-deux.
Le découpage influe-t-il sur ce coût ?
Directement : un découpage plus fin multiplie le nombre de fragments et donc le coût de chaque reprise. Cette conséquence doit être chiffrée avant de choisir la maille.