> 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 %} Les modèles Mindee ne sont pas « entraînés » à l’aide de documents annotés manuellement ; à la place, le Schéma de données est ajusté. Cela signifie que, pour obtenir les meilleures données d’extraction possibles à partir d’un modèle, l’essentiel est de veiller à ce que le Schéma de données soit clair et optimisé. Toute fonctionnalité supplémentaire 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) dépendra fortement du Schéma de données. ## **Optimisation automatisée** Avant de modifier le Schéma de données manuellement, commencez d’abord par lancer notre outil d’optimisation assisté par IA. L’outil analysera vos documents et déterminera dans quelle mesure le Schéma de données leur correspond. À partir de là, il vous proposera des suggestions pour améliorer la précision des extractions. Le processus est entièrement automatisé ; il vous suffit de fournir quelques documents d’exemple. ### Lancement de l’analyse Pour lancer l’analyse, téléversez d’abord au moins 5 documents à l’aide du [Live test](/v2/fr/models/live-test.md). Ensuite, allez à la page Schéma de données et cliquez sur le ":message: Assistant IA" bouton :
AI Assistant Button
Dans la boîte de dialogue, cliquez sur le ":wand-magic-sparkles:" (baguette magique) bouton :
AI Assistant Auto Optimize Button
Vous pouvez maintenant vous détendre, prendre une tasse de thé et attendre la fin de l’analyse. Le Schéma de données du modèle sera temporairement verrouillé pendant ce processus. Vous pouvez quitter sans risque la page du modèle ; l’analyse continuera de s’exécuter en arrière-plan. ### Application des résultats de l’analyse Une fois l’analyse terminée, la fenêtre de discussion affichera toutes les améliorations proposées. Pour chaque champ, vous verrez : * une case à cocher * la description et les consignes « Baseline » actuelles, en rouge * les modifications « Optimized » proposées, en vert Pour appliquer les modifications proposées, cochez chaque champ pour lequel vous souhaitez les appliquer. Lorsque vous avez sélectionné tous les champs que vous souhaitez modifier, cliquez sur le bouton « Apply Selected » :
AI Assistant Optimize Apply Changes Button
Vous recevrez un message de confirmation dans la fenêtre de dialogue une fois les modifications appliquées. ### Tester le Schéma de données optimisé Pour tester et valider les modifications, rendez-vous sur Live test, puis cliquez sur l’onglet « Documents History ». À partir de là, ouvrez les documents et cliquez sur le bouton « Rerun Document » (c’est une icône de redémarrage) :
Rerun the Document Button
## **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 automatiquement généré à partir du champ *titre*. Vous pouvez également modifier le *titre* par la suite. Le *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.\ Le but est d’éviter toute confusion possible entre les données présentes 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`\ Il indique clairement au modèle d’extraire uniquement le nom du fournisseur de la facture. :white\_check\_mark: vous pourriez également utiliser `vendor_name`, il a une signification similaire et une précision équivalente. :warning: `supplier` pourrait fonctionner, mais c’est trop vague : de quelles informations sur le fournisseur avez-vous exactement besoin ? :warning: `company_name` pourrait fonctionner, mais c’est ambigu : nous savons que vous avez besoin du nom de l’entreprise, mais nous ne savons pas si l’entreprise désigne le fournisseur ou le client. :x: `company` ne fonctionnera probablement pas comme prévu : nous ne savons ni quelles informations vous нужны ni de quelle entreprise il s’agit. ### Type de champ Essayez d’utiliser l’un des [types de champ](/v2/fr/modeles-extraction/data-schema.md#field-types) qui correspond le mieux à l’utilisation du champ et à son apparence dans le document. Par exemple, même si vous pourriez utiliser une chaîne pour `due_date`, un type de champ de date est nettement meilleur. ### Description du champ La *Description* du champ a un impact sur les performances du modèle. Utilisez-la pour décrire ce que le champ représente et/ou à quoi il vous sert. Par exemple, le `supplier_name` champ pourrait avoir : > Le nom du fournisseur. > > Utilisé dans le traitement interne pour faire correspondre notre identifiant fournisseur au nom trouvé dans le document. ### Consignes d’extraction des champs Parfois, modifier le nom et le type du champ ne suffit pas à expliquer ce dont vous avez besoin pour un champ.\ Dans ce cas, vous pouvez ajouter des consignes d’extraction *Consignes* au champ. Utilisez le 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`, l’ajout des 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 social 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 du champ Toutes les propriétés des champs n’ont pas la même importance ni le même poids dans 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, les « Normal Fields » sont 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’objets imbriqués. « Object Detection » désigne un traitement spécifique visant à extraire les polygones de divers éléments du document, tels que les signatures, les 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 conduit à une diminution de la 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 « order no » sur la facture, mais parfois il n’y a pas de numéro de commande, et il se trouve alors à côté des mots « customer invoice no ». 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 des instructions à un humain, mais à une machine. Les machines préfèrent les instructions concises. En revanche, cette machine a été entraînée sur des millions de documents et est capable de déterminer elle-même l’emplacement d’un champ de valeur. Il ne reste donc plus que l’instruction concernant le *customer invoice* et *order number*. Une version plus simple et meilleure serait : > Utilisez la valeur de « customer invoice number » si « order number » est absent du document. ## Lever 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 besoin. Imaginons que vous traitiez des factures et que vous deviez extraire le « Reference Number ». Lors du traitement des factures, vous constatez que, parfois, le « Order Number » est récupéré comme numéro de référence. Une première étape logique serait d’ajouter une consigne, quelque chose comme *« NE JAMAIS utiliser le "Order Number" pour alimenter 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 d’informations plus détaillées est potentiellement [contre-productif](#less-is-more). Une solution possible serait d’ajouter le champ « Reference Number » dans votre Schéma de données, en plus du champ « Order Number ». Ainsi, l’ambiguïté est levée et il est maintenant 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 faire d’abord la distinction entre *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 de savoir si les données que vous devez extraire (le contenu) changent selon la région ou la langue. La question suivante est généralement : 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 : * différentes lignes/calculs de taxe sur les factures * des champs spécifiques sur les documents d’identité * un reporting différent sur les factures d’énergie Avoir 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 de manière significative, même lorsque la langue change, il n’y a généralement pas besoin 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ême donnée à 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 plutôt que les 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 est *le moment où* 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 modèle 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. À ce titre, il est possible de rédiger des consignes qui transmettent 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 précis 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. Cela 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. Préciser un emplacement et un texte : > Le bon nom du client se trouve dans la première ligne de l’adresse de livraison.
Le modèle fonctionne-t-il mieux avec des informations de champ en anglais ? Lors de nos propres tests, les grandes 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, il *peut* être utile de définir le Schéma de données, par exemple les noms et les descriptions des champs, en utilisant la langue présente dans le document. Cela peut aider à améliorer la précision, notamment lorsque des termes difficilement traduisibles sont utilisés dans la définition du champ. Par exemple, un modèle pour des factures en français peut utiliser « TVA Intracommunautaire » comme nom de champ plutôt que « Intra-Community VAT », même si les deux fonctionneront. Le mieux est d’essayer les deux à l’aide de la [Live test](/v2/fr/models/live-test.md) fonctionnalité.
## Étapes suivantes Une fois que vous serez satisfait des résultats de votre Schéma de données, vous voudrez [connecter votre plateforme](/v2/fr/integrations/api-overview.md) et commencer à traiter des documents. --- # 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, and the optional `goal` query parameter: ``` GET https://docs.mindee.com/v2/fr/modeles-extraction/data-schema-best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.