Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Fonctionnement des bases de connaissances Amazon Bedrock Les bases de connaissances Amazon Bedrock vous aident à tirer parti de la génération à enrichissement contextuel (RAG), une technique populaire qui consiste à extraire des informations d’un magasin de données pour compléter les réponses générées par les grands modèles de langage (LLM). Lorsque vous configurez une base de connaissances avec votre source de données, votre application peut interroger la base de connaissances pour renvoyer des informations permettant de répondre à la requête soit avec des citations directes provenant des sources, soit avec des réponses naturelles générées à partir des résultats de la requête. Avec les bases de connaissances Amazon Bedrock, vous pouvez créer des applications qui sont enrichies par le contexte reçu lors de l’interrogation d’une base de connaissances. Cela permet de réduire les délais de mise sur le marché en vous évitant les lourdes tâches liées à la construction de pipelines et en vous fournissant une solution RAG prête à l’emploi pour réduire le temps de création de votre application. L’ajout d’une base de connaissances augmente également la rentabilité en évitant d’avoir à entraîner en permanence le modèle afin de tirer parti de vos données privées. Les schémas suivants illustrent grossièrement le fonctionnement du modèle RAG. La base de connaissances simplifie la configuration et la mise en œuvre de RAG en automatisant plusieurs étapes de ce processus. **Prétraitement des données non structurées** Pour permettre une extraction efficace à partir de données privées non structurées (données qui n’existent pas dans un magasin de données structurées), une pratique courante consiste à convertir les données en texte et à les diviser en éléments gérables. Les segments ou fragments sont ensuite convertis en vectorisations et écrits dans un index vectoriel, tout en conservant un mappage avec le document d’origine. Ces vectorisations sont utilisées pour déterminer la similitude sémantique entre les requêtes et le texte provenant des sources de données. L’image suivante illustre le traitement préalable des données pour la base de données vectorielles. ![\[Traitement préalable des données pour une génération augmentée par récupération\]](http://docs.aws.amazon.com/fr_fr/bedrock/latest/userguide/images/kb/rag-preprocess.png) Les vectorisations sont une série de nombres qui représentent chaque partie du texte. Un modèle convertit chaque fragment de texte en séries de nombres, appelées vecteurs, afin que les textes puissent être comparés mathématiquement. Ces vecteurs peuvent être des nombres à virgule flottante (float32) ou des nombres binaires. La plupart des modèles de vectorisation pris en charge par Amazon Bedrock utilisent des vecteurs à virgule flottante par défaut. Cependant, certains modèles prennent en charge les vecteurs binaires. Si vous choisissez un modèle de vectorisation binaire, vous devez également choisir un modèle et un magasin de vecteurs qui prennent en charge les vecteurs binaires. Les vecteurs binaires, qui n’utilisent qu’un bit par dimension, ne sont pas aussi coûteux en stockage que les vecteurs à virgule flottante (float32), qui utilisent 32 bits par dimension. Cependant, les vecteurs binaires ne sont pas aussi précis que les vecteurs à virgule flottante dans leur représentation du texte. L’exemple suivant montre un morceau de texte sous trois formes : **** | Représentation | Valeur | | --- | --- | | Texte | « Amazon Bedrock utilise des modèles de fondation très performants développés par les principales sociétés d’IA et Amazon. » | | Vecteur à virgule flottante | [0.041..., 0.056..., -0.018..., -0.012..., -0.020..., ...] | | Vecteur binaire | [1,1,0,0,0, ...] | **Exécution du runtime** Au moment de l’exécution, un modèle de vectorisation est utilisé pour convertir la requête de l’utilisateur en vecteur. L’index vectoriel est ensuite interrogé pour trouver les segments dont la sémantique est similaire à la requête de l’utilisateur en comparant les vecteurs de documents au vecteur de requête de l’utilisateur. Au cours de la dernière étape, l’invite utilisateur est complétée par le contexte supplémentaire provenant des segments extraits de l’index vectoriel. L’invite associée au contexte supplémentaire est ensuite envoyée au modèle pour générer une réponse pour l’utilisateur. L’image suivante montre comment la génération augmentée par récupération fonctionne au moment de l’exécution pour compléter les réponses aux requêtes des utilisateurs. ![\[Génération augmentée par récupération au moment de l’exécution\]](http://docs.aws.amazon.com/fr_fr/bedrock/latest/userguide/images/kb/rag-runtime.png) Pour découvrir comment transformer vos données en base de connaissances, comment interroger votre base de connaissances après l’avoir configurée et sur les personnalisations que vous pouvez appliquer à la source de données lors de l’ingestion, consultez les rubriques suivantes : **Topics** + [Transformation des données en base de connaissances](kb-how-data.md) + [Extraction d’informations à partir de sources de données à l’aide des bases de connaissances Amazon Bedrock](kb-how-retrieval.md) + [Personnalisation d’une base de connaissances](kb-how-customization.md) # Transformation des données en base de connaissances Pour créer une base de connaissances, connectez-vous à une source de données prise en charge à laquelle vous souhaitez que votre base de connaissances puisse accéder. Votre base de connaissances sera en mesure de répondre aux requêtes utilisateur ou de générer des réponses en fonction des données extraites. Les bases de connaissances Amazon Bedrock prennent en charge divers documents, notamment du texte, des images ou des documents multimodaux contenant des tableaux, des graphiques, des diagrammes et d’autres images. Les données *multimodales* font référence à une combinaison de données textuelles et visuelles. Des exemples de types de fichiers contenant des données non structurées sont le texte, le markdown, le HTML et. PDFs Les sections suivantes décrivent les types de données pris en charge par les bases de connaissances Amazon Bedrock et les services auxquels vous pouvez connecter votre base de connaissances pour chaque type de données : ## Données non structurées Les données non structurées font référence aux données qui ne sont pas intégrées de force dans une structure prédéfinie. Les bases de connaissances Amazon Bedrock permettent de se connecter aux services suivants pour ajouter des données non structurées à votre base de connaissances : + Amazon S3 + Confluence (version préliminaire) + Microsoft SharePoint (version préliminaire) + Salesforce (version préliminaire) + Web Crawler (version préliminaire) + Source de données personnalisée (permet l’ingestion directe des données dans les bases de connaissances sans qu’il soit nécessaire de les synchroniser) Une source de données contient la forme brute de vos documents. Pour optimiser le processus de requête, une base de connaissances convertit vos données brutes en *vectorisations*, une représentation numérique des données, afin de quantifier la similitude avec les requêtes qui sont également converties en vectorisations. Les bases de connaissances Amazon Bedrock utilisent les ressources suivantes pour convertir votre source de données : + Modèle de vectorisation : modèle de fondation qui convertit vos données en vectorisations. Pour les données multimodales contenant à la fois du texte et des images, vous pouvez utiliser des modèles d'intégration multimodaux tels qu'Amazon Titan Multimodal Embeddings G1 ou Cohere Embed v3. + Magasin de vecteurs : service qui stocke la représentation vectorielle de vos données. Les magasins de vecteurs suivants sont pris en charge : + Amazon OpenSearch sans serveur + Amazon Neptune + Amazon Aurora (RDS) + Pinecone + Redis Enterprise Cloud + Atlas MongoDB Le processus de conversion de vos données en vectorisations s’appelle l’*ingestion*. Le processus d’ingestion qui transforme vos données en base de connaissances comprend les étapes suivantes : **Ingestion** 1. Les données sont analysées par l’analyseur que vous avez choisi. Pour en savoir plus sur l’analyse, consultez [Options d’analyse structurée pour votre source de données](kb-advanced-parsing.md). 1. Chaque document de votre source de données est divisé en *fragments*, des subdivisions des données qui peuvent être définies par le nombre de jetons et d’autres paramètres. Pour plus d’informations sur la fragmentation, consultez [Fonctionnement du découpage du contenu pour les bases de connaissances](kb-chunking.md). 1. Le modèle de vectorisation que vous avez choisi convertit les données en vectorisations. Pour le contenu multimodal, les images sont intégrées sous forme de vecteurs visuels tandis que le texte est intégré sous forme de vecteurs de texte, ce qui permet d'effectuer une recherche dans les deux modalités. 1. Les vectorisations sont écrites dans un index vectoriel dans le magasin de vecteurs de votre choix. Une fois le processus d’ingestion terminé, votre base de connaissances est prête à être consultée. Pour plus d’informations sur la manière d’interroger et d’extraire des informations dans votre base de connaissances, consultez [Extraction d’informations à partir de sources de données à l’aide des bases de connaissances Amazon Bedrock](kb-how-retrieval.md). Si vous modifiez une source de données, vous devez synchroniser les modifications afin d’intégrer les ajouts, les modifications et les suppressions dans la base de connaissances. Certaines sources de données prennent en charge l’ingestion ou la suppression directes de fichiers dans la base de connaissances, ce qui évite de traiter la modification et l’ingestion des sources de données comme des étapes distinctes et de toujours effectuer des synchronisations complètes. Pour savoir comment intégrer des documents directement dans votre base de connaissances et dans les sources de données qui la prennent en charge, consultez [Ingestion des modifications directement dans une base de connaissances](kb-direct-ingestion.md). Les bases de connaissances Amazon Bedrock proposent différentes options pour personnaliser la manière dont vos données sont ingérées. Pour plus d’informations sur la personnalisation de ce processus, consultez [Personnalisation d’une base de connaissances](kb-how-customization.md). ## Données structurées Les données structurées font référence aux données tabulaires dans un format prédéfini par le magasin de données dans lequel elles se trouvent. Les bases de connaissances Amazon Bedrock se connectent aux magasins de données structurés pris en charge via le moteur de requête Amazon Redshift. Les bases de connaissances Amazon Bedrock fournissent un mécanisme entièrement géré qui analyse les modèles de requête, l’historique des requêtes et les métadonnées de schéma afin de convertir les requêtes en langage naturel en requêtes SQL. Ces requêtes converties sont ensuite utilisées pour extraire des informations pertinentes à partir de sources de données prises en charge. Les bases de connaissances Amazon Bedrock permettent de se connecter aux services suivants pour ajouter des magasins de données structurés à votre base de connaissances : + Amazon Redshift + AWS Glue Data Catalog(AWS Lake Formation) Si vous connectez votre base de connaissances à un magasin de données structuré, vous n’avez pas besoin de convertir les données en vectorisations. Au lieu de cela, les bases de connaissances Amazon Bedrock peuvent directement interroger le magasin de données structurées. Au cours de la requête, les bases de connaissances Amazon Bedrock peuvent convertir les requêtes des utilisateurs en requêtes SQL afin d’extraire les données pertinentes pour la requête utilisateur et de générer des réponses plus précises. Vous pouvez également générer des requêtes SQL sans extraire de données et les utiliser dans d’autres flux de travail. Par exemple, un référentiel de base de données contient le tableau suivant contenant des informations sur les clients et leurs achats : **** | ID du client | Montant dépensé en 2020 | Montant dépensé en 2021 | Montant dépensé en 2022 | Montant total dépensé à ce jour | | --- | --- | --- | --- | --- | | 1 | 200 | 300 | 500 | 1 000 | | 2 | 150 | 100 | 120 | 370 | | 3 | 300 | 300 | 300 | 900 | | 4 | 720 | 180 | 100 | 900 | | 5 | 500 | 400 | 100 | 1 000 | | 6 | 900 | 800 | 1 000 | 2700 | | 7 | 470 | 420 | 400 | 1290 | | 8 | 250 | 280 | 250 | 780 | | 9 | 620 | 830 | 740 | 2190 | | 10 | 300 | 200 | 300 | 800 | Si une requête utilisateur indique « donnez-moi un résumé des 5 clients les plus dépensiers », la base de connaissances peut effectuer les opérations suivantes : + Convertir la requête en requête SQL. + Renvoyer un extrait du tableau contenant les éléments suivants : + Colonnes du tableau pertinentes « Numéro du client » et « Montant total des achats effectués à ce jour » + Lignes du tableau contenant le montant total des achats pour les 10 clients les plus dépensiers + Générer une réponse indiquant quels clients sont les 5 clients les plus dépensiers et combien ils ont dépensé. Voici d’autres exemples de requêtes pour lesquelles une base de connaissances peut générer un extrait de tableau : + « les 5 meilleurs clients en termes de dépenses en 2020 » + « le meilleur client en termes de montant d’achat en 2020 » + « les 5 meilleurs clients en termes de montant d’achat entre 2020 et 2022 » + « les 5 clients les plus dépensiers en 2020-2022 » + « les clients dont le montant total des achats est inférieur à 10 € » + « les 5 clients les moins dépensiers » Plus une requête est précise ou détaillée, plus la base de connaissances peut affiner les informations exactes à renvoyer. Par exemple, au lieu de la requête « les 10 meilleurs clients en termes de dépenses en 2020 », une requête plus spécifique est « trouvez les 10 clients ayant dépensé le plus haut montant total à ce jour en 2020 ». La requête spécifique fait référence au nom de colonne « Montant total des achats à ce jour » dans le tableau de la base de données des dépenses des clients et indique également que les données doivent être triées selon le « montant le plus élevé ». # Extraction d’informations à partir de sources de données à l’aide des bases de connaissances Amazon Bedrock Après avoir configuré une base de connaissances, vous pouvez configurer votre application pour interroger les sources de données qu’elle contient. Pour interroger une base de connaissances, vous pouvez tirer avantage des opérations d’API suivantes : + [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_Retrieve.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_Retrieve.html) : extrait les fragments ou images sources de vos données qui sont les plus pertinents pour la requête et les renvoie dans la réponse sous forme de tableau. + [https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_RetrieveAndGenerate.html](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_RetrieveAndGenerate.html) : associe `Retrieve` à l’opération [InvokeModel](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime_InvokeModel.html) dans Amazon Bedrock pour récupérer les segments source de vos données les plus pertinents pour la requête et générer une réponse en langage naturel. Inclut des citations vers des segments sources spécifiques à partir des données. Si votre source de données inclut des éléments visuels, le modèle tire parti des informations issues de ces images lors de la génération d’une réponse textuelle et fournit une attribution source pour les images. + [GenerateQuery](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_GenerateQuery.html) : convertit les requêtes utilisateur en langage naturel en requêtes présentées sous une forme adaptée au magasin de données structuré. L’opération `RetrieveAndGenerate` est une action combinée qui utilise de manière sous-jacente `GenerateQuery` (si votre base de connaissances est connectée à un magasin de données structuré), `Retrieve` et `InvokeModel` pour exécuter l’ensemble du processus RAG. Comme les bases de connaissances Amazon Bedrock vous permettent également d’accéder à l’opération `Retrieve`, vous avez la possibilité de découpler les étapes dans RAG et de les personnaliser en fonction de votre cas d’utilisation spécifique. Vous pouvez également utiliser un [modèle de reclassement](rerank.md) lorsque vous utilisez `Retrieve` ou `RetrieveAndGenerate` pour reclasser la pertinence des documents extraits lors d’une requête. Pour savoir comment utiliser ces opérations d’API lors de l’interrogation d’une base de connaissances, consultez [Test de votre base de connaissances avec des requêtes et des réponses](knowledge-base-test.md). # Personnalisation d’une base de connaissances Les bases de connaissances Amazon Bedrock proposent des options pour personnaliser la manière dont vos sources de données sont traitées dans votre base de connaissances, vous offrant ainsi une flexibilité dans la manière dont vos données sont stockées, analysées et renvoyées aux utilisateurs finaux. Sélectionnez l’une des rubriques suivantes pour en savoir plus sur les options de personnalisation que vous pouvez prendre en compte lors de la configuration de votre base de connaissances : **Topics** + [Fonctionnement du découpage du contenu pour les bases de connaissances](kb-chunking.md) + [Options d’analyse structurée pour votre source de données](kb-advanced-parsing.md) + [Utilisation d’une fonction Lambda de transformation personnalisée pour définir la manière dont vos données sont ingérées](kb-custom-transformation.md) + [Intégration de métadonnées dans une source de données pour améliorer les requêtes de la base de connaissances](kb-metadata.md) # Fonctionnement du découpage du contenu pour les bases de connaissances Lorsque de l’ingestion de vos données, Amazon Bedrock divise d’abord vos documents ou votre contenu en fragments faciles à gérer pour une extraction efficace des données. Les segments sont ensuite convertis en vectorisations et écrits dans un index vectoriel (représentation vectorielle des données), tout en conservant un mappage avec le document d’origine. Les vectorisations permettent de comparer quantitativement les textes. **Topics** + [Découpage standard](#kb-standard-chunking) + [Découpage hiérarchique](#kb-hiearchical-chunking) + [Découpage sémantique](#kb-semantic-chunking) + [Découpage de contenu multimodal](#kb-multimodal-chunking) ## Découpage standard Amazon Bedrock prend en charge les approches standard suivantes en matière de découpage : **Note** Les stratégies de découpage de texte s'appliquent uniquement aux documents texte. Pour le contenu multimodal (audio, vidéo, images), le découpage se fait au niveau du modèle d'intégration, et non par le biais de ces stratégies basées sur le texte. + Fragmentation à taille fixe : vous pouvez configurer la taille de bloc souhaitée en spécifiant le nombre de jetons par bloc et un pourcentage de chevauchement, ce qui vous permet de vous adapter à vos besoins spécifiques. Vous pouvez définir le nombre maximum de jetons qui ne doit pas dépasser pour un bloc et le pourcentage de chevauchement entre des blocs consécutifs. **Note** Pour le contenu analysé (tel que le contenu utilisant des analyseurs avancés ou converti à partir du code HTML), les bases de connaissances Amazon Bedrock peuvent découper le contenu afin de l'optimiser et d'obtenir les meilleurs résultats. Le découpeur respecte les limites logiques du document (telles que les pages ou les sections) et ne fusionne pas le contenu au-delà de ces limites, même si l'augmentation de la taille maximale des jetons permettrait d'obtenir des segments plus importants. + Découpage par défaut : divise le contenu en blocs de texte contenant jusqu’à 300 jetons. Le processus de découpage respecte les limites des phrases, garantissant ainsi que les phrases complètes sont préservées dans chaque bloc. Vous pouvez également choisir de ne pas diviser vos documents. Chaque document est traité comme un seul bloc de texte. Vous souhaiterez peut-être prétraiter vos documents en les divisant en fichiers distincts avant de choisir de ne effectuer de découpage comme dans votre stratégie/approche de découpage. Si vous choisissez de ne pas segmenter vos documents, vous ne pouvez pas afficher le numéro de page dans la citation ni filtrer par le champ/attribut de document-page-number métadonnées *x-amz-bedrock-kb-*. ## Découpage hiérarchique Le découpage hiérarchique consiste à organiser les informations en structures imbriquées de segments enfant et parent. Lorsque vous créez une source de données, vous pouvez définir la taille du segment parent, la taille du segment enfant et le nombre de jetons qui se chevauchent entre chaque bloc. Lors de l’extraction, le système extrait initialement les fragments enfants, mais les remplace par des fragments parents plus larges afin de fournir au modèle un contexte plus complet. Les petites vectorisations de texte incorporées sont plus précises, mais l’extraction, vise à fournir un contexte complet. Un système de découpage hiérarchique équilibre ces besoins en remplaçant les fragments enfants extraits par leurs fragments parents, le cas échéant. **Note** Étant donné que les fragments enfants sont remplacés par des fragments parents lors de l’extraction, le nombre de résultats renvoyés peut être inférieur au montant demandé. Le découpage hiérarchique n'est pas recommandé lorsque vous utilisez le compartiment vectoriel S3 comme magasin de vecteurs. Lorsque vous utilisez un nombre élevé de jetons pour le découpage (plus de 8 000 jetons combinés), la taille des métadonnées peut être limitée. Pour le découpage hiérarchique, les bases de connaissances Amazon Bedrock permettent de spécifier deux niveaux ou la profondeur suivante pour le découpage : + Parent : vous définissez la taille maximale du jeton de bloc parent. + Enfant : vous définissez la taille maximale du jeton de bloc enfant. Vous définissez également les jetons de superposition entre les fragments. Il s’agit du nombre absolu de jetons de chevauchement entre des segments parents consécutifs et des blocs enfants consécutifs. ## Découpage sémantique Le découpage sémantique est une technique de traitement du langage naturel qui divise le texte en blocs significatifs afin d’améliorer la compréhension et l’extraction d’informations. Il vise à améliorer la précision de l’extraction en se concentrant sur le contenu sémantique plutôt que sur la structure syntaxique. Ce faisant, il peut faciliter une extraction et une manipulation plus précises des informations pertinentes. Lorsque vous configurez le découpage sémantique, vous avez la possibilité de spécifier les hyperparamètres suivants. + Nombre maximum de jetons : nombre maximum de jetons qui doivent être inclus dans un seul bloc, tout en respectant les limites des phrases. + Taille de la mémoire tampon : pour une phrase donnée, la taille de la mémoire tampon définit le nombre de phrases environnantes à ajouter pour la création de vectorisations. Par exemple, une taille de tampon de 1 entraîne la combinaison et l’intégration de 3 phrases (phrase actuelle, précédente et suivante). Ce paramètre peut influencer la quantité de texte examinée ensemble pour déterminer les limites de chaque bloc, ce qui a un impact sur la granularité et la cohérence des blocs obtenus. Une taille de tampon plus grande peut capturer plus de contexte mais peut également introduire du bruit, tandis qu’une taille de tampon plus petite peut omettre un contexte important tout en garantissant un découpage plus précis. + Seuil de percentile d'arrêt : seuil percentile d'une phrase pour tracer des points de rupture entre distance/dissimilarity les phrases. Un seuil plus élevé nécessite que les phrases soient plus faciles à distinguer afin d’être divisées en différents morceaux. Un seuil plus élevé entraîne une diminution du nombre de blocs et une taille moyenne des blocs généralement plus importante. **Note** L’utilisation du découpage sémantique entraîne des coûts supplémentaires en raison de l’utilisation d’un modèle de fondation. Le coût dépend de la quantité de données dont vous disposez. Consultez [Tarification d’Amazon Bedrock](https://aws.amazon.com/bedrock/pricing/) pour en savoir plus sur le coût des modèles de fondation. ## Découpage de contenu multimodal Pour le contenu multimodal (audio, vidéo, images), le comportement de segmentation est différent de celui des documents texte : + **Nouvelles intégrations multimodales :** le découpage se produit au niveau du modèle d'intégration. Vous pouvez configurer la durée des segments audio et vidéo de 1 à 30 secondes (par défaut : 5 secondes). Pour les fichiers vidéo, seule la durée du segment vidéo s'applique, même si la vidéo contient du son. La durée du segment audio ne s'applique qu'aux fichiers audio autonomes. + **Analyseur Bedrock Data Automation (BDA) :** le contenu est d'abord converti en texte (transcriptions et résumés de scènes), puis des stratégies de découpage de texte standard sont appliquées au texte converti. **Note** Lorsque vous utilisez les intégrations multimodales Nova, les stratégies de découpage de texte configurées dans votre base de connaissances n'affectent que les documents texte de votre source de données, et non les fichiers audio, vidéo ou image. # Options d’analyse structurée pour votre source de données L’analyse structurée fait référence à la compréhension et à l’extraction du contenu à partir de données brutes. Les bases de connaissances Amazon Bedrock proposent les options suivantes pour analyser votre source de données lors de l’ingestion : + **Analyseur par défaut Amazon Bedrock** : analyse uniquement le texte des fichiers texte, y compris les fichiers .txt, .md, .html, .doc/.docx, .xls/.xlsx et .pdf. Cet analyseur n’entraîne aucun frais d’utilisation. **Note** L’analyseur par défaut ne produisant que du texte, nous vous recommandons d’utiliser l’automatisation des données Amazon Bedrock ou un modèle de fondation comme analyseur plutôt que l’analyseur par défaut si vos documents incluent des figures, des graphiques, des tableaux ou des images. L’automatisation des données Amazon Bedrock et les modèles de fondation peuvent extraire ces éléments de vos documents et les renvoyer en sortie. + Amazon Bedrock Knowledge Bases propose les analyseurs suivants pour analyser les données multimodales, y compris les figures, graphiques et tableaux dans des fichiers .pdf, en plus des fichiers image .jpeg et .png. Ces analyseurs peuvent également extraire ces figures, graphiques, tableaux et images et les stocker sous forme de fichiers dans une destination S3 que vous spécifiez lors de la création de la base de connaissances. Lors de la récupération de la base de connaissances, ces fichiers peuvent être renvoyés dans la réponse ou dans l’attribution de la source. + **Automatisation des données Amazon Bedrock** : un service entièrement géré qui traite efficacement les données multimodales, sans qu’il soit nécessaire de fournir des instructions supplémentaires. Le coût de cet analyseur dépend du nombre de pages du document ou du nombre d’images à traiter. Pour plus d’informations sur ce service, consultez [Automatisation des données Amazon Bedrock](bda.md). + **Modèles de fondation** : traite les données multimodales à l’aide d’un modèle de fondation. Cet analyseur vous permet de personnaliser l’invite par défaut utilisée pour l’extraction des données. Le coût de cet analyseur dépend du nombre de jetons d’entrée et de sortie traités par le modèle de fondation. Pour obtenir la liste des modèles prenant en charge l’analyse des données Amazon Bedrock Knowledge Bases, consultez [Modèles et régions pris en charge pour l’analyse](knowledge-base-supported.md#knowledge-base-supported-parsing). **Important** Si vous choisissez l’automatisation des données Amazon Bedrock ou les modèles de fondation comme analyseur, la méthode choisie sera utilisée pour analyser tous les fichiers .pdf de votre source de données, même s’ils ne contiennent que du texte. L’analyseur par défaut ne sera pas utilisé pour analyser ces fichiers .pdf. Des frais sont facturés à votre compte pour l’utilisation de l’automatisation des données Amazon Bedrock ou du modèle de fondation pour l’analyse de ces fichiers. Quand vous choisissez une méthode d’analyse de vos données, tenez compte des points suivants : + Les données sont-elles purement textuelles ou contiennent-elles des données multimodales, telles que des images, des graphiques et des diagrammes, que vous souhaitez que la base de connaissances puisse interroger ? + Souhaitez-vous ou non avoir la possibilité de personnaliser l’invite utilisée pour indiquer au modèle comment analyser vos données ? + Le coût de l’analyseur. L’automatisation des données Amazon Bedrock applique une tarification par page, tandis que les analyseurs du modèle de fondation facturent en fonction des jetons d’entrée et de sortie. Pour plus d’informations, consultez [Tarification d’Amazon Bedrock](https://aws.amazon.com/bedrock/pricing/). + Limite de taille totale du fichier. Lorsque vous utilisez des modèles de base comme analyseur, la taille totale de tous les fichiers ne doit pas dépasser 100 Go. Pour savoir comment configurer la méthode d’analyse de votre base de connaissances, consultez la configuration de connexion de votre source de données dans [Connexion d’une source de données à votre base de connaissances](data-source-connectors.md). # Utilisation d’une fonction Lambda de transformation personnalisée pour définir la manière dont vos données sont ingérées Il est possible de définir une fonction Lambda de transformation personnalisée pour injecter votre propre logique dans le processus d’ingestion de la base de connaissances. Vous avez peut-être une logique de découpage spécifique, qui n’est pas prise en charge de manière native par les bases de connaissances Amazon Bedrock. Utilisez l’option de stratégie d’absence de découpage, tout en spécifiant une fonction Lambda contenant votre logique de découpage. En outre, vous devez spécifier un compartiment Amazon S3 pour la base de connaissances afin d’écrire les fichiers à découper par votre fonction Lambda. Après le découpage, votre fonction Lambda réécrit les fichiers découpés dans le même compartiment et renvoie des références à la base de connaissances pour un traitement ultérieur. Vous pouvez éventuellement fournir votre propre clé AWS KMS pour le chiffrement des fichiers stockés dans votre compartiment S3. **Note** Si des connecteurs Web sont utilisés, un texte Markdown est transmis à Lambda au lieu du HTML. Vous pouvez également spécifier des métadonnées au niveau des segments, tout en demandant à la base de connaissances d’appliquer l’une des stratégies de découpage prises en charge de manière native. Dans ce cas, sélectionnez l’une des stratégies de découpage prédéfinies (par exemple, découpage par défaut ou de taille fixe), tout en fournissant une référence à votre fonction Lambda et à votre compartiment S3. Dans ce cas, la base de connaissances stockera les fichiers analysés et pré-découpés dans le compartiment S3 prédéfini, avant d’appeler votre fonction Lambda pour ajouter des métadonnées au niveau des segments. Après l’ajout de métadonnées au niveau des segments, votre fonction Lambda réécrit les fichiers découpés dans le même compartiment et renvoie des références à la base de connaissances pour un traitement ultérieur. Veuillez noter que les métadonnées au niveau des segments sont prioritaires et remplacent les métadonnées au niveau du fichier, en cas de collision. Pour un exemple d’utilisation d’une fonction Lambda Python pour un découpage personnalisé, consultez [Découpage personnalisé à l’aide de la fonction Lambda](https://github.com/aws-samples/amazon-bedrock-samples/blob/main/rag/knowledge-bases/features-examples/03-optimizing-accuracy-retrieved-results/advanced_chunking_options.ipynb). Pour les contrats d’API et de fichiers, reportez-vous aux structures ci-dessous : **Contrat d’API lors de l’ajout d’une transformation personnalisée à l’aide de la fonction Lambda** ``` { ... "vectorIngestionConfiguration": { "customTransformationConfiguration": { // Custom transformation "intermediateStorage": { "s3Location": { // the location where input/output of the Lambda is expected "uri": "string" } }, "transformations": [{ "transformationFunction": { "transformationLambdaConfiguration": { "lambdaArn": "string" } }, "stepToApply": "string" // enum of POST_CHUNKING }] }, "chunkingConfiguration": { "chunkingStrategy": "string", "fixedSizeChunkingConfiguration": { "maxTokens": "number", "overlapPercentage": "number" } ... } } } ``` **Format d’entrée de transformation Lambda personnalisée** ``` { "version": "1.0", "knowledgeBaseId": "string", "dataSourceId": "string", "ingestionJobId": "string", "bucketName": "string", "priorTask": "string", "inputFiles": [{ "originalFileLocation": { "type": "S3", "s3_location": { "uri": "string" } }, "fileMetadata": { "key1": "value1", "key2": "value2" }, "contentBatches": [{ "key":"string" }] }] } ``` **Format de sortie de transformation Lambda personnalisée** ``` { "outputFiles": [{ "originalFileLocation": { "type": "S3", "s3_location": { "uri": "string" } }, "fileMetadata": { "key1": "value1", "key2": "value2" }, "contentBatches": [{ "key": "string" }] }] } ``` **Le format de fichier pour les objets est référencé sous `fileContents`** ``` { "fileContents": [{ "contentBody": "...", "contentType": "string", // enum of TEXT, PDF, ... "contentMetadata": { "key1": "value1", "key2": "value2" } } ... ] } ``` # Intégration de métadonnées dans une source de données pour améliorer les requêtes de la base de connaissances Lors de l’ingestion de fichiers CSV (valeurs séparées par des virgules), vous pouvez faire en sorte que la base de connaissances traite certaines colonnes comme des champs de contenu plutôt que comme des champs de métadonnées. Au lieu d’avoir potentiellement des centaines ou des milliers de paires de fichiers contenu/métadonnées, vous pouvez désormais disposer d’un seul fichier CSV et d’un fichier metadata.json correspondant, ce qui donne à la base de connaissances des indications sur la manière de traiter chaque colonne de votre fichier CSV. Il existe des limites par fragment pour les champs/attributs de métadonnées des documents. Consultez [Quotas pour les bases de connaissances](https://docs.aws.amazon.com/bedrock/latest/userguide/quotas.html). Avant l’ingestion un fichier CSV, vérifiez les points suivants : + Votre fichier CSV est au format RFC4180 et est codé en UTF-8. + La première ligne de votre fichier CSV inclut les informations d’en-tête. + Les champs de métadonnées fournis dans votre fichier metadata.json sont présents sous forme de colonnes dans votre fichier CSV. + Vous fournissez un fichier fileName.csv.metadata.json au format suivant : ``` { "metadataAttributes": { "${attribute1}": "${value1}", "${attribute2}": "${value2}", ... }, "documentStructureConfiguration": { "type": "RECORD_BASED_STRUCTURE_METADATA", "recordBasedStructureMetadata": { "contentFields": [ { "fieldName": "string" } ], "metadataFieldsSpecification": { "fieldsToInclude": [ { "fieldName": "string" } ], "fieldsToExclude": [ { "fieldName": "string" } ] } } } } ``` Le fichier CSV est analysé ligne par ligne et la stratégie de découpage ainsi que la vectorisation sont appliquées au champ de contenu. Amazon Bedrock Knowledge Bases prend actuellement en charge un champ de contenu. Celui-ci est divisé en fragments, et les champs de métadonnées (colonnes) associés à chaque fragments sont traités comme des valeurs de chaîne. Par exemple, supposons qu’il existe un fichier CSV avec une colonne « Description » et une colonne « Date\$1de\$1création ». Le champ de description est le champ de contenu et la date de création est un champ de métadonnées associé. Le texte de description est divisé en fragments et converti en vectorisations pour chaque ligne du fichier CSV. La valeur de la date de création est traitée comme une représentation de la date sous forme de chaîne et est associée à chaque fragment de la description. Si aucun champ d’inclusion/exclusion n’est fourni, toutes les colonnes sont traitées comme des colonnes de métadonnées, à l’exception de la colonne de contenu. Si seuls les champs d’inclusion sont fournis, seules les colonnes fournies sont traitées comme des métadonnées. Si seuls les champs d’exclusion sont fournis, toutes les colonnes, à l’exception des colonnes d’exclusion, sont traitées comme des métadonnées. Si vous fournissez le même `fieldName` dans `fieldsToInclude` et `fieldsToExclude`, Amazon Bedrock génère une exception de validation. S’il existe un conflit entre inclusion et exclusion, cela se traduira par un échec. Les lignes vides présentes dans un fichier CSV sont ignorées ou sautées.