> For the complete documentation index, see [llms.txt](https://docs.mindee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.mindee.com/v2/fr/modeles-extraction/data-schema-best-practices.md). # Bonnes pratiques du Schéma de données {% hint style="info" %} Nous vous recommandons de consulter [Aperçu du Schéma de données](/v2/fr/modeles-extraction/data-schema.md) d’abord.\ Cela vous aidera à comprendre les termes utilisés sur cette page. {% endhint %} Pour obtenir les meilleures données d’extraction d’un modèle, l’essentiel est de vous assurer que le Schéma de données que vous utilisez est clair et optimisé. Toutes les fonctionnalités supplémentaires que vous activez pour améliorer la précision, comme [Apprentissage continu (RAG)](/v2/fr/modeles-extraction/optional-features/improving-accuracy.md) ou [Score de confiance et exactitude améliorée](/v2/fr/modeles-extraction/optional-features/automation-confidence-score.md) reposeront fortement sur le Schéma de données. ## **Bonnes pratiques pour les champs** Le cœur du Schéma de données. Les différentes propriétés des champs jouent toutes un rôle pour obtenir la meilleure précision possible. ### **Nom et titre du champ** Le champ *Nom* est généré automatiquement à partir du champ *Titre*. Vous pouvez également modifier le *Titre* par la suite. Les deux *Nom* et *Titre* sont utilisés pendant le traitement (inférence). Utilisez des noms clairs et simples qui décriront précisément le champ que vous souhaitez extraire.\ L’objectif est d’éviter toute confusion possible entre les points de données présents dans le document. À titre d’exemple, extrayons le nom de l’entreprise qui a émis une facture. Dans notre Schéma de données, nous avons utilisé le champ *Nom*: `supplier_name`\ Cela indique clairement au modèle d’extraire uniquement le nom du fournisseur de la facture. :white\_check\_mark: vous pourriez aussi utiliser `vendor_name`, il a une signification similaire et une précision équivalente. :warning: `fournisseur` pourrait fonctionner, mais c’est trop large : quelle information sur le fournisseur est nécessaire, exactement ? :warning: `nom_de_l'entreprise` pourrait fonctionner, mais est ambigu : nous savons que vous avez besoin du nom de l’entreprise, mais nous ne savons pas si « company » désigne le fournisseur ou le client. :x: `entreprise` ne fonctionnera probablement pas comme prévu : nous ne savons ni quelles informations vous sont nécessaires ni quelle entreprise est concernée. ### Type de champ Essayez d’utiliser l’un des [Aperçu du Schéma de données](/v2/fr/modeles-extraction/data-schema.md#field-types) qui correspond le mieux à la façon dont le champ est utilisé et à son apparence dans le document. Par exemple, même si vous pourriez utiliser une chaîne pour `due_date`, un type de champ date est clairement préférable. ### Description du champ La description du champ *Description* a un impact sur les performances du modèle. Utilisez-la pour décrire ce que le champ représente, et/ou son utilité pour vous. Par exemple, le `supplier_name` champ pourrait contenir : > Le nom du fournisseur. > > Utilisé dans le traitement interne pour faire correspondre notre identifiant de fournisseur avec le nom trouvé sur le document. ### Consignes d’extraction des champs Parfois, modifier le nom et le type du champ ne suffit pas pour expliquer ce dont vous avez besoin pour un champ.\ Dans ce cas, vous pouvez ajouter des consignes d’extraction *Consignes* au champ. Utilisez un langage naturel pour expliquer comment extraire correctement les données, et/ou toute étape supplémentaire comme le formatage. Par exemple, avec `supplier_phone_number`, ajouter les consignes d’extraction suivantes pourrait être utile : > Si vous trouvez plusieurs numéros de téléphone dans le document, utilisez le numéro de téléphone du siège du fournisseur. > > Reformatez toujours les données pour correspondre au format international des numéros de téléphone, comme suit : +1-212-867-5309 ## Importance relative des propriétés des champs Toutes les propriétés des champs n’ont pas la même importance ni le même poids lorsqu’il s’agit de la manière dont les modèles traitent les fichiers. De plus, tous les types de champs ne sont pas traités de la même manière. Dans le tableau suivant, « Champs normaux » désigne ceux qui extraient des informations textuelles du document (texte, dates, nombres, etc.), qu’il s’agisse de champs simples, de listes ou de champs d’objet imbriqués. « Détection d’objets » désigne un traitement spécifique visant à extraire les polygones de différents éléments du document, tels que des signatures, des photos d’identité, etc.
PropriétéUtilisation pour les champs normauxUtilisation pour la détection d’objets
NomLa plus importanteNon utilisé
TitreImportantLa plus importante
DescriptionComplémentaireNon utilisé
ConsignesComplémentaireNon utilisé
Valeurs de classificationTrès important (uniquement pour les champs de classification)Non utilisé
## Moins, c’est mieux Il peut être tentant de donner des instructions très détaillées dans les consignes et les descriptions. Cependant, dans de nombreux cas, cela est en réalité contre-productif et entraînera une baisse de précision. Voici un exemple avec trop de détails (ne faites pas cela) : > Le numéro de commande se trouve généralement à côté des mots « n° de commande » sur la facture, mais parfois il n’y a pas de numéro de commande, auquel cas il se trouve à côté des mots « n° de facture client ». Il est généralement présent sur la première page, dans un encadré vert. Qu’est-ce qui ne va pas ici ? Eh bien, la première chose à comprendre est que vous ne donnez pas d’instructions à un humain, mais à une machine. Les machines préfèrent des consignes concises. En revanche, cette machine a été entraînée sur des millions de documents et est parfaitement capable de déterminer elle-même l’emplacement d’un champ de valeur. Il ne reste donc que l’instruction concernant le *facture client* et *numéro de commande*. Une version plus simple et meilleure serait : > Utilisez la valeur de « numéro de facture client » si « numéro de commande » est absent du document. ## Supprimez l’ambiguïté avec des champs supplémentaires Dans certains cas, il peut être utile d’ajouter des champs supplémentaires dont vous n’avez pas réellement besoin afin de lever l’ambiguïté sur les données dont vous avez réellement besoin. Supposons que vous traitiez des factures et que vous deviez extraire le « numéro de référence ». Lors du traitement des factures, vous remarquez que, parfois, le « numéro de commande » est détecté comme numéro de référence. Une première étape logique serait d’ajouter une consigne, du genre *« N’utilisez JAMAIS le « numéro de commande » pour renseigner ce champ »*. Bien que cela devrait fonctionner dans **la plupart** des cas, la distinction entre une référence et une commande peut ne pas être parfaitement claire pour le modèle. Ajouter davantage de texte ou des informations plus détaillées est potentiellement [contre-productif](#less-is-more). Une solution possible consisterait à ajouter le champ « numéro de référence » à votre Schéma de données, en plus du champ « numéro de commande ». Ainsi, l’ambiguïté est levée et il est désormais très clair pour le modèle qu’il s’agit de points de données distincts. Ensuite, dans votre flux de traitement des données, ignorez simplement le champ supplémentaire. Pour rappel, le nombre de champs dans le Schéma de données n’a aucun impact sur la tarification. ## Bonnes pratiques pour différentes régions ou langues Il est important de distinguer d’abord *représentation* et *contenu*. La représentation signifie qu’un contenu équivalent peut être montré ou affiché différemment (pour une langue, il s’agit d’une traduction). Le contenu signifie que la structure des données est différente, quelle que soit sa représentation (langue). Dans le contexte d’un Schéma de données, la configuration optimale dépend principalement du fait que les données que vous devez extraire (le contenu) changent ou non selon la région ou la langue. En général, la question suivante est : dois-je utiliser un seul modèle ou plusieurs modèles ? ### Quand utiliser différents modèles Si les données changent considérablement, il sera avantageux d’avoir différents modèles pour différentes régions.\ Par exemple : * des lignes/calculs de taxe différents sur les factures * des champs spécifiques sur les documents d’identité * des modes de présentation différents sur les factures d’énergie Disposer de différents modèles pour mieux adapter les données à extraire fournira généralement des résultats plus précis.\ Cela permettra également d’avoir des [#field-extraction-guidelines](#field-extraction-guidelines "mention"). ### Quand utiliser un seul modèle En revanche, si les données à extraire ne varient pas significativement, même lorsque la langue change, il n’est généralement pas nécessaire d’avoir différents modèles.\ Par exemple : * même document, langue différente (pays multilingues comme la Belgique, le Canada, l’Inde, etc.) * mêmes données à extraire, même si le document change (seul un sous-ensemble de données est requis) ## Foire aux questions ### Quand dois-je utiliser les consignes du Schéma de données par rapport aux consignes RAG ? Les deux fonctionnent de la même manière pour fournir un contexte supplémentaire au modèle afin de mieux identifier les données et les extraire. La principale différence réside dans *quand* elles sont appliquées : Si la consigne doit s’appliquer à tous les documents ⇒ utilisez la consigne du Schéma de données. Si la consigne s’applique uniquement à un gabarit spécifique ⇒ utilisez la consigne RAG. ### Le modèle peut-il interpréter correctement des positions comme le haut, le bas, etc. ? Les modèles Mindee sont multimodaux, ce qui signifie qu’ils utilisent à la fois des informations textuelles et visuelles. Il est donc possible de rédiger des consignes transmettant des informations de position, par exemple : > Le logo du fournisseur sera toujours en haut de la page. ### Puis-je faire référence à un emplacement ou à un texte spécifique sur la page ? Chaque page du document est traitée dans son ensemble, et les modèles disposent à la fois d’un composant visuel et d’un composant textuel (modèles multimodaux). Il est donc possible de faire référence à d’autres emplacements et textes de la page dans les consignes. C’est particulièrement utile pour lever l’ambiguïté lorsque des données similaires se trouvent à plusieurs endroits sur la page. Faire référence à un autre emplacement : > Le bon numéro de téléphone se trouve sous le nom du client. Spécifier un emplacement et un texte : > Le bon nom du client se trouve sur la première ligne de l’adresse de livraison. ### Le modèle fonctionne-t-il mieux avec des informations de champ en anglais ? Dans nos propres tests, les principales langues européennes comme le français, l’espagnol ou l’allemand sont comparables à l’anglais en termes de précision du modèle. Dans certains cas, cela *peut* être avantageux de définir le Schéma de données, par exemple les noms et descriptions des champs, dans la langue présente dans le document. Cela peut aider à améliorer la précision, en particulier lorsque des termes difficilement traduisibles sont utilisés dans la définition du champ. Par exemple, un modèle pour des factures françaises peut utiliser « TVA Intracommunautaire » comme nom de champ plutôt que « TVA intracommunautaire », même si les deux fonctionneront. Le mieux est d’essayer les deux en utilisant le [Live test](/v2/fr/models/live-test.md) fonctionnalité. ## Étapes suivantes Une fois que vous serez satisfait de votre Schéma de données, vous voudrez probablement utiliser l’un de nos [Intégrations](/v2/fr/integrations/api-overview.md) pour connecter votre modèle à votre plateforme. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.mindee.com/v2/fr/modeles-extraction/data-schema-best-practices.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.