Maintenant que vous avez rassemblé vos documents de test et vos requêtes, et que vous avez effectué une analyse des documents lors de la phase de préparation, la phase suivante est le segmentage. La décomposition des documents en une collection de segments de taille adéquate, chacun contenant un contenu sémantiquement pertinent, est un facteur clé de la réussite de votre mise en œuvre de la génération améliorée par récupération (RAG). Passer des documents entiers ou des segments surdimensionnés est coûteux, peut dépasser les limites de jetons du modèle et ne produit pas les meilleurs résultats. La transmission d’informations à un modèle de langage qui n’est pas pertinent pour la requête peut entraîner des hallucinations. Vous devez optimiser le processus de transmission des informations pertinentes et de suppression des informations non pertinentes. Pour ce faire, vous devez utiliser des stratégies de segmentation et de recherche efficaces afin de minimiser les faux positifs et les faux négatifs et de maximiser les vrais positifs et les vrais négatifs.
Passer des segments trop petits et ne contenant pas suffisamment de contexte pour répondre à la requête conduit également à de mauvais résultats. Le contexte pertinent existant sur plusieurs segments peut ne pas être capturé. C’est tout un art de mettre en œuvre des approches de chunking efficaces pour vos types de documents spécifiques et leurs structures et contenus. Il existe différentes approches de chunking à considérer, chacune avec ses propres implications en termes de coût et d’efficacité, en fonction du type et de la structure du document auquel elles sont appliquées.
Cet article décrit diverses approches de chunking et examine comment la structure de vos documents peut influencer l’approche de chunking que vous choisissez.
Cet article fait partie d’une série. Lisez l’introduction.
Économie du chunking
Lorsque vous déterminez votre stratégie globale de segmentation, vous devez tenir compte de votre budget ainsi que de vos exigences en matière de qualité et de débit pour votre corpus de documents. Il y a des coûts d’ingénierie pour la conception et la mise en œuvre de chaque chunking unique et des coûts de traitement par document qui diffèrent selon l’approche. Si vos documents comportent des médias intégrés ou liés, vous devez prendre en compte les aspects économiques du traitement de ces éléments. Dans le cas de la segmentation, ce traitement utilise généralement des modèles de langage pour générer des descriptions des médias, et ces descriptions sont ensuite segmentées. Une autre approche pour certains médias consiste à les transmettre tels quels à un modèle multimodal au moment de l'inférence, mais cette approche n'aurait pas d'incidence sur l'économie du segmentage.
Cette section examine les aspects économiques du segmentage des images et de la solution globale.
Économie du segmentage d'images
L'utilisation d'un modèle de langage pour générer une description d'une image qui est ensuite segmentée a un coût. Par exemple, les services basés sur le cloud, tels qu'Azure OpenAI, sont facturés soit sur la base d'une transaction, soit sur la base d'un approvisionnement prépayé. Les images plus grandes entraînent un coût plus élevé. Grâce à l'analyse de vos documents, vous devriez déterminer les images qu'il est intéressant de segmenter et celles que vous devriez ignorer. À partir de là, vous devez comprendre le nombre et la taille des images de votre solution et évaluer la valeur du segmentage des descriptions d'images par rapport au coût de génération de ces descriptions.
Une façon de déterminer les images à traiter consiste à utiliser un service tel qu'Azure AI Vision pour classer les images, les baliser ou faire de la détection de logos. Vous pouvez ensuite utiliser les résultats et les indicateurs de confiance pour déterminer si l'image ajoute une valeur contextuelle significative et doit être traitée. Les appels à Azure AI Vision peuvent être moins coûteux que les appels aux modèles de langage, de sorte que cette approche pourrait permettre de réaliser des économies. Vous devez expérimenter pour déterminer quels niveaux de confiance et quelles classifications ou balises fournissent les meilleurs résultats pour vos données. Une autre option consiste à créer votre propre modèle de classification. Vous devez prendre en compte les coûts de construction, d'hébergement et de maintenance de votre propre modèle de classification.
Une autre optimisation des coûts est la mise en cache à l'aide du modèle cache-aside. Vous pouvez générer une clé basée sur le hachage de l'image. Dans un premier temps, vous pouvez vérifier si vous disposez d'un résultat mis en cache lors d'une exécution précédente ou d'un document traité antérieurement. Si c'est le cas, vous pouvez utiliser ce résultat. Cette approche vous évite les coûts liés à l'appel d'un classificateur ou d'un modèle de langage. S'il n'y a pas de cache, lorsque vous appelez le classificateur ou le modèle de langage, vous mettez le résultat en cache. Les appels ultérieurs pour cette image utiliseraient le cache.
Un workflow simple intégrant tous ces processus d'optimisation des coûts serait le suivant :
- Vérifiez si le traitement de l'image a été mis en cache. Si c'est le cas, utilisez les résultats mis en cache.
- Exécutez votre classificateur pour déterminer si vous devez traiter l'image. Mettez en cache le résultat de la classification. Ne procédez que si votre logique de classification vous indique de le faire.
- Générez la description de votre image. Mettez le résultat en cache.
Économie de la solution globale
Voici les facteurs à considérer lors de l’examen du coût de votre solution globale :
- Nombre de mises en œuvre de fragmentation uniques : Chaque mise en œuvre unique a un coût d’ingénierie et de maintenance. Vous devez prendre en compte le nombre de types de documents uniques dans votre corpus et les compromis coût-qualité des mises en œuvre uniques pour chacun.
- Coût par document de chaque mise en œuvre : Certaines approches de chunking peuvent conduire à des segments de meilleure qualité mais avoir un coût financier et temporel plus élevé pour générer ces segments. Par exemple, l’utilisation d’un modèle prédéfini dans Azure AI Document Intelligence a probablement un coût par document plus élevé qu’une mise en œuvre de parsing de texte pur, mais peut conduire à de meilleurs segments.
- Nombre de documents initiaux : Le nombre de documents initiaux que vous devez traiter pour lancer votre solution.
- Nombre de documents incrémentaux : Le nombre et le taux de nouveaux documents que vous devez traiter pour la maintenance continue du système.
Chargement et segmentation
Logiquement, lors du segmentage, vous devez d'abord charger le document en mémoire dans un format quelconque. Le code de segmentation opère ensuite sur la représentation en mémoire du document. Vous pouvez choisir de combiner le code de chargement avec le segmentage, ou vous pouvez séparer le chargement dans sa propre phase. L'approche que vous choisissez doit être largement basée sur les contraintes architecturales et vos préférences. Cette section explore brièvement les deux options et vous propose ensuite quelques recommandations générales.
Séparer le chargement et le segmentage
Plusieurs raisons peuvent vous inciter à séparer les phases de chargement et de segmentation. Vous pouvez vouloir encapsuler la logique dans le code de chargement. Vous pouvez vouloir persister le résultat du code de chargement avant le segmentage, en particulier lorsque vous expérimentez différentes permutations de segmentation pour économiser du temps de traitement ou des coûts. Enfin, vous pouvez vouloir exécuter le code de chargement et de segmentation dans des processus distincts pour des raisons architecturales telles que le cloisonnement des processus ou la segmentation de la sécurité impliquant la suppression des informations confidentielles.
Encapsuler la logique dans le code de chargement
Vous pouvez choisir d'encapsuler la logique de prétraitement dans la phase de chargement. Cela simplifie le code de segmentation car il n'a pas besoin d'effectuer de prétraitement. Le prétraitement peut être aussi simple que la suppression ou l'annotation de parties du document que vous avez décidé d'ignorer dans l'analyse du document, telles que les filigranes, les en-têtes et les pieds de page, ou aussi complexe que le reformatage du document. Voici quelques exemples de prétraitement que vous pourriez choisir d'encapsuler dans la phase de chargement :
- Supprimez ou annotez les éléments que vous souhaitez ignorer.
- Remplacer les références d'images par des descriptions d'images. Au cours de cette phase, vous utilisez un LLM pour générer une description de l'image et mettre à jour le document avec cette description. Si vous avez déterminé, lors de l'analyse du document, qu'il existe un texte environnant qui fournit un contexte utile à l'image, transmettez-le, ainsi que l'image, au LLM.
- Téléchargez ou copiez les images dans un espace de stockage de fichiers tel qu'Azure Data Lake pour les traiter séparément du texte du document. Si vous avez déterminé, lors de l'analyse du document, qu'il existe un texte environnant qui fournit un contexte utile à l'image, vous devez stocker ce texte avec l'image dans le stockage de fichiers.
- Reformatez les tableaux pour qu'ils soient plus faciles à traiter.
Conserver le résultat du code de chargement
Vous pouvez choisir de conserver le résultat du code de chargement pour de multiples raisons. L'une d'entre elles est la possibilité d'inspecter les documents après leur chargement et leur prétraitement, mais avant l'exécution de la logique de segmentation. Une autre raison est que vous pourriez vouloir exécuter différentes logiques de segmentation sur le même code prétraité pendant le développement ou la production. La persistance du code chargé accélère ce processus.
Exécutez le code de chargement et de segmentation dans des processus distincts.
La séparation du code de chargement et de segmentation dans des processus distincts permet d'exécuter plusieurs implémentations de segmentation à partir du même code prétraité. Cette séparation vous permet également d'exécuter le code de chargement et de segmentation dans différents environnements de calcul et sur différents matériels. En outre, cette conception vous permet de faire évoluer indépendamment le calcul utilisé pour le chargement et le segmentage.
Combinez le chargement et le segmentage
La combinaison du code de chargement et de segmentation est une implémentation plus simple dans la plupart des cas. La plupart des opérations que vous pourriez envisager de réaliser dans le cadre du prétraitement dans une phase de chargement distincte peuvent être effectuées dans la phase de segmentation. Par exemple, au lieu de remplacer les URL des images par une description dans la phase de chargement, la logique de découpage peut appeler le LLM pour obtenir une description textuelle et segmenter la description.
Lorsque vous avez des formats de document comme HTML qui ont des balises avec des références à des images, vous devez vous assurer que le lecteur ou l'analyseur que le code de découpage utilise ne supprime pas les balises. Le code de segmentation doit être en mesure d'identifier les références aux images.
Recommandations
Voici quelques recommandations à prendre en compte pour déterminer si vous devez combiner ou séparer votre logique de segmentation.
- Commencez par combiner les logiques de chargement et de segmentation. Séparez-les lorsque votre solution l'exige.
- Évitez de convertir les documents dans un format intermédiaire si vous décidez de séparer les processus. De telles opérations peuvent entraîner des pertes.
Approches de chunking
Cette section vous donne un aperçu de quelques approches de chunking courantes. Cette liste n’est pas censée être exhaustive, mais plutôt représenter des approches courantes. Vous pouvez utiliser plusieurs approches dans l’implémentation, telles que la combinaison de l’utilisation d’un modèle de langage pour obtenir une représentation textuelle d’une image avec la plupart des approches répertoriées.
Chaque approche est accompagnée d’une matrice de prise de décision résumée qui met en évidence les outils, les coûts associés et plus encore. L’effort d’ingénierie et les coûts de traitement sont subjectifs et inclus pour une comparaison relative.
Analyse basée sur les phrases
Cette approche simple décompose les documents textuels en segments composés de phrases complètes. Les avantages de cette approche sont notamment qu’elle est peu coûteuse à mettre en œuvre, qu’elle a un faible coût de traitement et qu’elle peut être appliquée à tout document textuel écrit en prose ou en phrases complètes. Un des défis de cette approche est que chaque segment peut ne pas capturer le contexte complet d’une pensée ou d’une signification. Souvent, plusieurs phrases doivent être prises ensemble pour capturer la signification sémantique.
Outils : SpaCy sentence tokenizer, LangChain recursive text splitter, NLTK sentence tokenizer
Effort d’ingénierie : Faible
Coût de traitement : Faible
Exemples d’utilisation : Documents non structurés écrits en prose ou en phrases complètes, et votre corpus de documents contient un nombre prohibitif de différents types de documents pour construire des stratégies de fragmentation individuelles
Exemples : Contenu généré par l'utilisateur, comme des commentaires ouverts provenant d'enquêtes, de messages sur des forums, de critiques, de messages électroniques, d'un roman ou d'un essai.
Parsing de taille fixe (avec chevauchement)
Cette approche divise un document en segments basés sur un nombre fixe de caractères ou de jetons et permet un chevauchement de caractères entre les segments. Cette approche présente de nombreux avantages et inconvénients similaires à ceux de l’analyse basée sur les phrases. Un avantage que cette approche a par rapport à l’analyse basée sur les phrases est qu’il est possible d’obtenir des segments avec une signification sémantique qui s’étend sur plusieurs phrases.
Vous devez choisir la taille fixe des segments et la quantité de chevauchement. Comme les résultats diffèrent selon les types de documents, il est préférable d’utiliser un outil comme le visualiseur de segments HuggingFace pour faire une analyse exploratoire. Des outils comme celui-ci vous permettent de visualiser comment vos documents sont segmentés, compte tenu de vos décisions. Il est recommandé d’utiliser des jetons BERT plutôt que des comptes de caractères lors de l’utilisation du parsing de taille fixe. Les jetons BERT sont basés sur des unités de langue significatives, donc ils préservent plus d’informations sémantiques que les comptes de caractères.
Outils : LangChain recursive text splitter, Hugging Face chunk visualizer
Effort d’ingénierie : Faible
Coût de traitement : Faible
Exemples d’utilisation : Documents non structurés écrits en prose ou non-prose avec phrases complètes ou incomplètes. Votre corpus de documents contient un nombre prohibitif de différents types de documents pour construire des stratégies de chunking individuelles
Exemples : Contenu généré par l'utilisateur, tel que des commentaires ouverts provenant d'enquêtes, de messages sur des forums, de critiques, de messages e-mail, de notes ou de listes personnelles ou de recherche.
Code personnalisé
Cette approche analyse les documents à l’aide de code personnalisé pour créer des segments. Cette approche se montre tr-ès efficace pour les documents textuels où la structure est soit connue soit peut être déduite et un haut degré de contrôle sur la création de segments est requis. Vous pouvez utiliser des techniques de parsing de texte comme les expressions régulières pour créer des segments basés sur des motifs dans la structure du document. L’objectif est de créer des segments de taille similaire et des segments ayant un contenu distinct. De nombreux langages de programmation offrent un support pour les expressions régulières, et certains ont des bibliothèques ou des packages qui offrent des fonctionnalités de manipulation de chaînes plus élégantes.
Outils : Python (re, regex, BeautifulSoup, lxml, html5lib, marko), R (stringr, xml2), Julia (Gumbo.jl)
Effort d’ingénierie : Moyen
Coût de traitement : Faible
Exemples d’utilisation : Documents semi-structurés où la structure peut être déduite
Exemples : Dépôts de brevets, articles de recherche, polices d’assurance, scripts et scénarios
Augmentation du modèle de langage
Les modèles de langage peuvent être utilisés pour créer des blocs. Les cas d’utilisation courants sont l’utilisation d’un grand modèle de langage, comme GPT-4, pour générer des représentations textuelles d’images ou des résumés de tableaux qui peuvent être utilisés comme segments. L’augmentation du modèle de langage est utilisée avec d’autres approches de segmentation telles que du code personnalisé.
Si vous avez déterminé dans la partie images de la section d’analyse de document que le texte avant ou après l’image est nécessaire pour répondre à certaines questions, vous devez passer ce contexte supplémentaire au modèle de langage. Il est important d'expérimenter pour déterminer si ce contexte supplémentaire améliore ou non les performances de votre solution.
Si votre logique de segmentation divise la description de l'image en plusieurs segments, assurez-vous d'inclure l'URL de l'image dans chaque segment. L'inclusion de l'URL de l'image dans chaque segment garantit que les métadonnées sont renvoyées pour toutes les requêtes portant sur l'image, en particulier dans les scénarios où l'utilisateur final doit pouvoir accéder à l'image source par le biais de cette URL ou souhaite utiliser des images brutes lors de l'inférence.
Outils : Azure OpenAI, OpenAI
Effort d’ingénierie : Moyen
Coût de traitement : Élevé
Exemples d’utilisation : Images, tables
Exemples : Générer des représentations textuelles de tableaux et d’images, résumer des transcriptions de réunions, discours, interviews ou podcasts
Analyse de la disposition de documents
Les bibliothèques et services d’analyse de la mise en page des documents combinent les capacités de reconnaissance optique de caractères (OCR) avec des modèles de Deep Learning pour extraire à la fois la structure des documents et le texte. Les éléments structurels peuvent inclure les en-têtes, les pieds de page, les titres, les titres de section, les tableaux et les figures. L’objectif est de fournir une meilleure signification sémantique au contenu des documents.
Les bibliothèques et services d’analyse de la mise en page des documents exposent un modèle qui représente le contenu, à la fois structurel et textuel, du document. Vous devez toujours écrire du code qui interagit avec le modèle.
Remarque
Azure AI Document Intelligence est un service basé sur le cloud qui nécessite de télécharger votre document sur le service. Vous devez vous assurer que vos réglementations de sécurité et de conformité vous permettent de télécharger des documents sur des services tels que celui-ci
Outils : Modèles d’analyse de documents Azure AI Document Intelligence, Donut, Layout Parser
Effort d’ingénierie : Moyen
Coût de traitement : Moyen
Exemples d’utilisation : Documents semi-structurés
Exemples : Articles de presse, pages web, CV
Modèle prédéfini
Il existe des services, tels qu’Azure AI Document Intelligence, qui offrent des modèles prédéfinis dont vous pouvez profiter pour divers types de documents. Certains modèles sont entraînés pour des types de documents spécifiques, tels que le formulaire fiscal américain W-2, tandis que d’autres ciblent un genre plus large de types de documents comme une facture.
Outils : Modèles prédéfinis Azure AI Document Intelligence, Power Automate Intelligent Document Processing, LayoutLMv3
Effort d’ingénierie : Faible
Coût de traitement : Moyen/élevé
Exemples d’utilisation : Documents structurés où un modèle prédéfini existe
Exemples spécifiques : Factures, reçus, carte d’assurance santé, formulaire W-2
Modèle personnalisé
Pour les documents hautement structurés où aucun modèle prédéfini n’existe, vous devrez peut-être construire un modèle personnalisé. Cette approche peut être efficace pour les images ou les documents hautement structurés, les rendant difficiles à utiliser avec des techniques de parsing de texte.
Outils : Modèles personnalisés Azure AI Document Intelligence, Tesseract
Effort d’ingénierie : Élevé
Coût de traitement : Moyen/élevé
Exemples d’utilisation : Documents structurés où un modèle prédéfini n’existe pas
Exemples : Calendriers de réparation et d’entretien automobile, relevés de notes académiques et dossiers, manuels techniques, procédures opérationnelles, directives d’entretien
Structure du document
Les documents varient en termes de structure. Certains documents, comme les formulaires gouvernementaux, ont une structure complexe et bien connue, telle qu’un document fiscal américain W-2. À l’autre extrémité du spectre se trouvent des documents non structurés comme des notes libres. Le degré de structure d’un type de document est un bon point de départ pour déterminer une approche de chunking efficace. Bien qu’il n’existe pas de règles strictes, cette section vous fournit quelques lignes directrices à suivre.
Diagramme montrant les approches de fragmentation par structure de document.
Figure 1. Approche de chunking adaptée par structure de document
Documents structurés
Les documents structurés, parfois appelés documents à format fixe, ont des mises en page définies. Les données dans ces documents sont situées à des emplacements fixes. Par exemple, la date ou le nom de famille du client se trouvent au même endroit dans tous les documents du même format fixe. Des exemples de documents à format fixe sont le document fiscal américain W-2.
Les documents à format fixe peuvent être des images numérisées de documents originaux remplis à la main ou avoir des structures de mise en page complexes, les rendant difficiles à traiter avec une approche de parsing de texte basique. Une approche courante pour traiter des structures de documents complexes est d’utiliser des modèles d’apprentissage automatique pour extraire des données et appliquer une signification sémantique à ces données, dans la mesure du possible.
Exemples : Formulaire W-2, carte d’assurance
Approches courantes : Modèles prédéfinis, modèles personnalisés
Documents semi-structurés
Les documents semi-structurés n’ont pas un format ou un schéma fixe, comme le formulaire W-2, mais ils offrent une cohérence en ce qui concerne le format ou le schéma. Par exemple, toutes les factures ne sont pas disposées de la même manière, cependant, en général, elles ont un schéma cohérent. Vous pouvez vous attendre à ce qu’une facture ait une invoice number et une forme de bill to et ship to nom et adresse, entre autres données. Une page web pourrait ne pas avoir de cohérences de schéma, mais elle a des éléments structurels ou de mise en page similaires, tels que body, title, H1, et p qui peuvent être utilisés pour ajouter une signification sémantique au texte environnant.
Comme les documents structurés, les documents semi-structurés qui ont des structures de mise en page complexes sont difficiles à traiter avec le parsing de texte. Pour ces types de documents, les modèles d’apprentissage automatique sont une bonne approche. Il existe des modèles prédéfinis pour certains domaines qui ont des schémas cohérents comme les factures, les contrats ou les assurances santé. Envisagez de construire des modèles personnalisés pour des structures complexes où aucun modèle prédéfini n’existe.
Exemples : Factures, reçus, pages web, fichiers markdown
Approches courantes : Modèles d’analyse de documents
Structure déduite
Certains documents ont une structure mais ne sont pas écrits en balisage. Pour ces documents, la structure doit être déduite. Un bon exemple est le document de réglementation de l’UE suivant.
Diagramme montrant une réglementation de l’UE comme exemple de document avec structure déduite.
Figure 2 : Réglementation de l’UE montrant une structure déduite
Parce que vous pouvez clairement comprendre la structure du document, et qu’il n’y a pas de modèles connus pour cela, vous pouvez déterminer que vous pouvez écrire du code personnalisé. Un format de document tel que celui-ci peut ne pas justifier l’effort de créer un modèle personnalisé, selon le nombre de différents documents de ce type avec lesquels vous travaillez. Par exemple, si votre corpus est composé uniquement de réglementations de l’UE ou de lois des États-Unis, un modèle personnalisé peut être une bonne approche. Si vous travaillez avec un seul document, comme la réglementation de l’UE dans l’exemple, le code personnalisé peut être plus rentable.
Exemples : Documents juridiques, scripts, spécifications de fabrication
Approches courantes : Code personnalisé, modèles personnalisés
Documents non structurés
Une bonne approche pour les documents avec peu ou pas de structure est l’approche basée sur les phrases ou la taille fixe avec chevauchement.
Exemples : Contenu généré par les utilisateurs comme des retours ouverts de sondages, des publications sur des forums ou des avis, des messages électroniques, et des notes personnelles ou de recherche
Approches courantes : Basée sur les phrases ou basée sur les frontières avec chevauchement
Expérimentation
Bien que les approches de segmentation les mieux adaptées soient énumérées, dans la pratique, n'importe laquelle d'entre elles peut convenir à n'importe quel type de document. Par exemple, le parsing basé sur les phrases peut être approprié pour les documents hautement structurés, ou un modèle personnalisé peut être approprié pour les documents non structurés. Une partie de l'optimisation de votre solution RAG consiste à expérimenter différentes approches de segmentation, en tenant compte du nombre de ressources dont vous disposez, des compétences techniques de vos ressources et du volume de documents que vous devez traiter. Pour atteindre une stratégie de fragmentation optimale, vous devez observer les avantages et les compromis de chacune des approches que vous testez pour vous assurer de choisir l’approche appropriée pour votre cas d’utilisation.