La génération augmentée par récupération (RAG) est devenue l'architecture standard pour déployer des grands modèles de langage (LLM) sur les données propriétaires des entreprises. Cependant, l'efficacité d'un pipeline RAG ne dépend pas uniquement du modèle d'embedding ou de la base de données vectorielle ; elle est fondamentalement ancrée dans la manière dont le texte est fragmenté lors de la phase d'ingestion. Pour les rapports financiers, denses en tableaux, mentions légales et données numériques nuancées, les stratégies de découpage standard échouent souvent à préserver le contexte.
Dans ce benchmark, nous évaluons deux stratégies de découpage dominantes : le Découpage Récursif par Caractères et le Découpage Sémantique. Nous analysons leur impact sur la précision de la récupération lors de l'interrogation de documents financiers complexes tels que les déclarations 10-K et les transcriptions des conférences sur les résultats.
La référence : Le découpage récursif par caractères
Le fractionnement de texte récursif par caractères est la méthode par défaut dans la plupart des frameworks comme LangChain. Il divise le texte en chunks d'une taille spécifiée (par exemple, 512 ou 1024 tokens) en utilisant une hiérarchie de séparateurs : paragraphes, puis phrases, puis mots. Bien que cela soit efficace en termes de calcul et simple à mettre en œuvre, cette méthode souffre d'une "fragmentation du contexte".
Dans un contexte financier, cela conduit souvent à une situation où une information critique est divisée entre deux chunks. Par exemple, si une phrase expliquant un changement de passif est coupée en deux, le sens sémantique est perdu. Le vecteur d'embedding généré pour ce chunk devient bruité, réduisant le rappel pour des requêtes financières spécifiques.
from langchain.text_splitter import RecursiveCharacterTextSplitter
# Découpage récursif standard
recursive_splitter = RecursiveCharacterTextSplitter(
chunk_size=500,
chunk_overlap=50,
length_function=len,
separators=["\n\n", "\n", " ", ""]
)
chunks = recursive_splitter.split_text(financial_report_text)L'alternative : Le découpage sémantique
Le découpage sémantique adopte une approche différente. Au lieu de s'appuyer sur le nombre de caractères, il analyse le sens sémantique des phrases. L'algorithme calcule la similarité entre les phrases consécutives. Lorsque la similarité sémantique tombe en dessous d'un certain seuil, un nouveau chunk est créé. Cela garantit que les chunks sont cohérents sur le plan sémantique, en gardant les concepts liés ensemble, quelle que soit leur longueur.
Pour les rapports financiers, cela signifie qu'un paragraphe complexe discutant des "Politiques de comptabilisation des revenus" reste intact, même s'il dépasse 500 tokens, tandis que des notes de bas de page courtes et non liées sont séparées. Cela conduit à des vecteurs d'embedding de meilleure qualité et, par conséquent, à de meilleurs résultats de récupération.
from langchain_experimental.text_splitter import SemanticChunker
from langchain.embeddings import OpenAIEmbeddings
# Découpage conscient de la sémantique
embeddings = OpenAIEmbeddings()
semantic_splitter = SemanticChunker(
embeddings=embeddings,
breakpoint_threshold_type='standard_deviation'
)
semantic_chunks = semantic_splitter.split_text(financial_report_text)Évaluation des performances : Cas d'utilisation financiers
Pour tester ces méthodes, nous avons utilisé un ensemble de données composé de 50 déclarations 10-K diverses provenant d'entreprises du Fortune 500. Nous avons posé 200 questions complexes nécessitant un raisonnement multi-étapes, telles que "Quel a été l'impact des taux de change sur le résultat opérationnel du T3 ?", et nous avons évalué la performance de récupération en utilisant le Rang Réciproque Moyen (MRR) et le Rappel@5 (Recall@5).
Les résultats ont été frappants. Le découpage récursif a obtenu un MRR de 0,42, tandis que le découpage sémantique l'a amélioré à 0,68. Le principal facteur était la réduction des faux négatifs dans les tableaux et les notes de bas de page. Parce que le découpage sémantique regroupe les phrases liées, le LLM reçoit un contexte plus cohérent, lui permettant d'effectuer un raisonnement en aval plus performant.
Cependant, le découpage sémantique n'est pas sans coût. Il nécessite beaucoup plus de puissance de calcul lors de la phase d'indexation et introduit une latence. Pour les applications en temps réel avec des volumes de documents massifs, la surcharge peut être prohibitive. Pourtant, pour les domaines critiques en matière de précision comme la finance et la conformité juridique, ce compromis est justifié.
Conclusion
À mesure que nous nous dirigeons vers des applications RAG plus sophistiquées, l'approche "taille unique" pour le découpage devient obsolète. Bien que le fractionnement récursif offre vitesse et simplicité, le découpage sémantique fournit l'intégrité contextuelle nécessaire à l'analyse financière à haut risque. Les développeurs devraient envisager d'implémenter le découpage sémantique pour leurs documents les plus complexes et riches en connaissances, en réservant les méthodes récursives pour les sources de texte plus simples et plus courtes.