De l'ingestion aux agents : comment les équipes IA exploitent le Document Intelligence — Adit Abraham, Reducto
Transcript
00:00:00Bonjour, vous m'entendez tous ? Super. Nous avons 20 courtes minutes devant nous, alors je propose de plonger
00:00:20directement au cœur du sujet. Je m'appelle Deet, je suis cofondateur et PDG de Reducto, et aujourd'hui, nous voulions parler
00:00:25de l'un des aspects les plus pratiques, bien que peut-être moins glamour, de la création d'agents réellement fonctionnels dans le monde réel : les données. J'imagine que vous avez déjà vu beaucoup de présentations sur les données aujourd'hui. Notre priorité est de créer une infrastructure pour tous ceux qui travaillent avec des sources de données particulièrement complexes, à savoir les images non structurées, les PDF, les feuilles de calcul, tout ce que les humains utilisent au quotidien. Est-ce que certains d'entre vous ont déjà utilisé ou essayé Reducto ? Super.
00:00:55Pour situer un peu le contexte, nous sommes une plateforme d'agents de traitement de documents. Nous aidons plusieurs des plus grandes équipes d'IA au monde à concevoir des applications et des flux de travail basés sur l'IA, selon leurs besoins.
00:01:08Cela inclut de nombreuses entreprises « AI-native » que vous connaissez sans doute. Comme Harvey, Ligor ou Rogo, mais aussi certaines des plus grandes entreprises mondiales. Et je pense que c'est un contexte important pour notre sujet d'aujourd'hui.
00:01:19Nous travaillons avec les plus grands groupes technologiques, des institutions financières internationales, des compagnies d'assurance... des acteurs qui possèdent des décennies de données historiques, mais qui étaient jusqu'ici extrêmement difficiles à exploiter en dehors d'une démo.
00:01:34Au total, nous avons traité plusieurs milliards de documents pour nos clients. Je suis devenu un peu paresseux avec le signe « plus » à la fin, mais comme ce chiffre ne cesse de grimper, nous allons en rester là.
00:01:46Mais le plus important, c'est la leçon que nous en avons tirée, et ce sur quoi je souhaite me concentrer aujourd'hui ne concerne pas le produit Reducto en lui-même.
00:01:51Ce sont toutes les subtilités de notre expérience, que vous pourrez, je l'espère, réutiliser et appliquer dans vos propres projets.
00:01:58Une grande partie de nos travaux et de nos apprentissages s'inscrit dans un cadre plus vaste : la portée des applications d'IA a considérablement évolué récemment.
00:02:07On est passé de simples outils de synthèse d'informations à de véritables agents autonomes capables d'exécuter des tâches.
00:02:13Et avec cette évolution, nous avons constaté que plusieurs points méritent d'être abordés.
00:02:16D'abord, la formulation du problème en lui-même, le goulot d'étranglement auquel on se heurte et la raison pour laquelle les PDF restent si complexes, bien que vous ayez probablement vu passer des dizaines d'outils de traitement de PDF sur Twitter.
00:02:26Ensuite, l'analyse des forces et des faiblesses des différents outils.
00:02:31Selon nous, la vision par ordinateur classique et les VLM ont chacun leur rôle à jouer.
00:02:35Et enfin, ce qui est encore plus captivant : la seconde moitié de cette présentation sera consacrée aux nouvelles frontières.
00:02:40À ce qu'il devient possible d'accomplir grâce à l'intégration d'agents dans la boucle.
00:02:43Aux découvertes réalisées grâce à l'utilisation d'environnements de test adaptés à différents types de tâches.
00:02:47Et à ce que nous avons appris sur les évaluations lors du passage du RAG aux produits basés sur des agents.
00:02:53Mais je vais commencer par le tout premier point, qui a sans doute déjà été très largement abordé.
00:02:58Si vous assistiez à un événement AI Engineer il y a quelques années, le mot-clé incontournable de toutes les conférences était « RAG ».
00:03:04Tout le monde développait une forme ou une autre d'application RAG.
00:03:07Pendant un certain temps, toutes les applications se résumaient à de la synthèse d'informations, n'est-ce pas ?
00:03:12Vous extrayez des données d'un certain contexte, qu'il s'agisse d'un prompt parfait ou d'un fichier téléversé par l'utilisateur.
00:03:19Et vous obteniez un produit de recherche.
00:03:22Vous aviez de la recherche d'entreprise.
00:03:23Vous aviez un chatbot capable d'effectuer des questions-réponses simples sur le contenu.
00:03:27Et c'était tout.
00:03:28Mais aujourd'hui, le mot à la mode que vous avez probablement entendu un million de fois, c'est « agents ».
00:03:34Et pour les ingénieurs parmi vous, vous avez sans doute déjà confié une grande partie de votre travail de bout en bout à Claude Code ou à un outil similaire.
00:03:41Et cette même transition commence à s'opérer dans tous les métiers du secteur tertiaire.
00:03:46Que ce soit dans la finance, l'assurance ou la santé, on commence à leur confier des prises de décisions autonomes.
00:03:51On cherche à créer des livrables complets, pas seulement à répondre à des questions sur un PDF, mais aussi à générer et modifier ces documents.
00:03:58C'est une perspective totalement différente.
00:04:00Les outils requis et les défis rencontrés changent radicalement par rapport à la simple création d'une plateforme de recherche.
00:04:06Et le fil conducteur de tout cela, c'est que ce problème devient encore plus crucial à résoudre dès lors qu'on met en place ces pipelines à étapes multiples.
00:04:18Quand on fait de simples questions-réponses, le risque se limite évidemment à la réponse fournie.
00:04:24Mais lorsque des agents prennent plusieurs décisions successives qui s'accumulent au fil du traitement d'un ensemble de fichiers, en recoupant plusieurs sources de données, le risque lié à de mauvaises données d'entrée devient omniprésent dans le pipeline.
00:04:36Et c'est précisément là-dessus que nous nous concentrons.
00:04:38Parce qu'au bout du compte, la valeur des modèles linguistiques dans le monde réel dépend entièrement du contexte dans lequel vous appliquez cette intelligence.
00:04:48Pour beaucoup d'entreprises, les données ne sont pas structurées, elles sont éparpillées et multimodales.
00:04:53On ne parle pas d'un espace de stockage parfaitement ordonné.
00:04:56Vous avez des équipes indépendantes dans différents départements qui stockent des éléments au hasard sur Google Drive, Box ou ailleurs.
00:05:04Vous vous retrouvez avec des formats de données par nature non structurés.
00:05:07Vous ne savez pas nécessairement ce que contient votre corpus d'informations.
00:05:11Et cela entraîne toutes sortes de problèmes en aval.
00:05:14Certains problèmes concernent la précision du traitement et de l'extraction, ce qui est évidemment primordial.
00:05:18Mais la question est aussi de savoir si vous récupérez le bon contexte.
00:05:22Il s'agit de comprendre comment interagir efficacement avec ce contexte et lui apporter des modifications.
00:05:27Et ce que vous avez probablement entendu répéter par Reducto et d'autres acteurs du secteur, c'est que les PDF restent, de manière surprenante, un problème très complexe.
00:05:36Je ne sais pas si vous suivez Surge, un laboratoire de données qui collabore avec de nombreuses entreprises de modèles fondations.
00:05:42Ils ont créé un excellent benchmark nommé GDP PDF, où même Fable, qui représente la pointe actuelle de l'intelligence des modèles, n'atteint qu'environ 30 % de réussite.
00:05:52Et tout repose sur cette idée : les modèles peuvent-ils analyser le contenu de documents comme des PDF et prendre des décisions fondées dessus ?
00:06:01Et la raison de cette difficulté — je reviendrai à ce benchmark dans un instant —, c'est qu'en tant que format de fichier, le PDF est à la fois très ancien et a été conçu pour un usage complètement différent.
00:06:11J'ai rencontré des personnes qui travaillaient sur le traitement de PDF depuis plus longtemps que je ne suis au monde.
00:06:16J'ai échangé avec ceux qui ont développé les pilotes d'impression pour imprimer des PDF au début des années 1990.
00:06:21Et c'était ça, l'objectif.
00:06:22Il s'agissait de reproduire fidèlement le rendu visuel du document original pour pouvoir l'imprimer sans altération.
00:06:30Aujourd'hui, les priorités ne sont plus du tout les mêmes.
00:06:33En réalité, nous cherchons plutôt une représentation en Markdown, un format sur lequel les agents peuvent raisonner efficacement.
00:06:39Or, dans le monde réel, les humains intègrent une quantité énorme de contexte par le visuel.
00:06:44Un jeune analyste financier qui débute en banque d'investissement ne va pas se demander si un agent sera capable de lire sa présentation.
00:06:54Il va concevoir des diapositives particulièrement créatives.
00:06:57Vous avez sûrement vu les présentations de SoftBank avec l'oie qui pond des œufs d'or.
00:07:01Ces détails ont toute leur importance.
00:07:02N'est-ce pas ?
00:07:03Une grande partie des données à analyser prend la forme de tableaux sans quadrillage net pour séparer les cellules fusionnées.
00:07:10On y trouve des graphiques et des courbes.
00:07:12Des écritures manuscrites parfois si désordonnées qu'un humain peinerait à les déchiffrer.
00:07:17C'est précisément ce genre de cas limites qu'il faut savoir gérer.
00:07:22Nous avons fondé l'entreprise en 2023 avec la conviction qu'une véritable rupture technologique était en train de se produire ici.
00:07:29Pendant longtemps, le traitement de PDF reposait systématiquement sur une variante de pipeline NLP.
00:07:37On effectuait une première passe d'OCR simple, puis on tentait d'appliquer un post-traitement au texte.
00:07:41Et cela fonctionnait tant que la mise en page restait parfaitement constante.
00:07:44N'est-ce pas ?
00:07:45Si vous savez qu'un formulaire fiscal conserve toujours la même structure, le périmètre est restreint et peut être automatisé par des modèles d'extraction.
00:07:51Mais l'intérêt des VLM réside dans leur nature fondamentalement polyvalente.
00:07:56Pour la première fois, on peut appliquer ce principe : lire le document exactement comme le ferait un humain.
00:08:01On peut enfin chercher à traiter la grande variété des cas particuliers.
00:08:04Nous avons constaté leur efficacité remarquable sur le texte manuscrit, là où l'OCR traditionnel échouait systématiquement.
00:08:12Cependant, nous ne pensons pas qu'il s'agisse d'une solution universelle pour autant.
00:08:16Si vous devez résoudre ce problème à grande échelle, pour une entreprise qui traite des centaines de millions de documents,
00:08:21de nombreux facteurs secondaires entrent en jeu, comme le déterminisme.
00:08:25L'efficacité de votre traitement devient alors une priorité absolue.
00:08:27C'est pourquoi la vision par ordinateur classique conserve de vrais atouts sur certaines tâches.
00:08:33Et cet aspect a été sous-estimé alors que la recherche sur les véhicules autonomes progressait.
00:08:37Les techniques comme la détection d'objets sont aujourd'hui bien plus sophistiquées qu'il y a dix ans.
00:08:42Des modèles de moins de 100 millions de paramètres s'avèrent ainsi très performants pour détecter la mise en page d'un document.
00:08:48Il est possible d'obtenir d'excellents résultats sans même recourir à un grand modèle fondation.
00:08:52Et ces modèles peuvent tourner directement sur un processeur.
00:08:54On peut les exécuter à grande échelle.
00:08:55On peut identifier précisément, zone par zone, les éléments complexes à traiter.
00:09:00Et les VLM apportent cette dimension sémantique.
00:09:03Ils permettent de repérer et d'imputer les erreurs susceptibles de se glisser dans votre chaîne de traitement.
00:09:09Grâce à cette compréhension sémantique, lorsqu'on décompose le problème et qu'on identifie clairement les zones complexes,
00:09:18une fois le texte de la page segmenté et l'écriture manuscrite localisée,
00:09:21il devient possible d'intégrer une forme d'agent dans la boucle.
00:09:25Là où l'on faisait autrefois appel à des équipes de relecture humaines pour annoter et corriger les erreurs,
00:09:29les VLM permettent aujourd'hui d'envisager ce que nous appelons l'OCR agentique.
00:09:33En pratique, si vous avez déjà utilisé un outil comme Cursor pour appliquer des modifications rapides dans votre environnement de développement,
00:09:41le principe est celui du décodage spéculatif, qui applique des corrections au niveau des tokens sur votre résultat.
00:09:45On peut transposer ce principe ici : il ne s'agit pas simplement d'envoyer l'OCR à Gemini,
00:09:51en rédigeant un prompt très élégant qui lui demande poliment de ne pas trop s'éloigner du document d'origine.
00:09:56Car en s'appuyant uniquement sur cette prédiction du token suivant,
00:09:58on introduit de nouvelles failles : des modèles pourtant très intelligents
00:10:02vont se mettre à corriger des éléments en s'éloignant du texte réel du document.
00:10:05En voyant le mot « total », si une erreur s'est glissée dans le tableau d'origine,
00:10:08certains modèles vont parfois recalculer eux-mêmes les sommes du tableau.
00:10:13Ce qu'il faut, c'est cibler précisément les ajustements de tokens nécessaires.
00:10:16Corriger une virgule prise pour un point, ou un zéro confondu avec un O...
00:10:19Ce genre de détail a une importance capitale.
00:10:21Toute la question est de savoir comment restituer fidèlement ce qu'un humain aurait vu
00:10:25en lisant ce document.
00:10:27De notre point de vue, l'OCR agentique équivaut à cette présence humaine dans la boucle,
00:10:34où une première passe associe vision par ordinateur et VLM,
00:10:39suivie d'une couche de vérification et de correction garantissant un résultat très fiable.
00:10:44Mais comme je l'indiquais plus tôt, les enjeux dépassent le simple cadre de l'analyse et de l'extraction.
00:10:50Il est essentiel d'examiner en détail chaque étape de votre chaîne de traitement,
00:10:56même si vous disposez d'un excellent convertisseur de documents vers le Markdown.
00:10:59Un bon exemple : si vous avez déjà conçu une plateforme RAG,
00:11:04vous avez probablement dû réfléchir à la gestion des tableaux.
00:11:07Il y a beaucoup de choses qu'on peut bien encoder au format Markdown.
00:11:13Mais avec ce genre de tableau, où les cellules fusionnées contiennent beaucoup de sens,
00:11:18il est essentiel de préserver cette structure.
00:11:20Et ce n'est pas une limitation du modèle.
00:11:22Les LLM sont excellents pour analyser la structure HTML d'un même tableau,
00:11:26mais vous gâchez aussi beaucoup de tokens, et ça devient vite coûteux.
00:11:29Et évidemment, à l'inverse,
00:11:31vous ne voulez pas non plus encoder des tableaux simples en HTML,
00:11:35parce qu'on se retrouve avec plein de balises HTML superflues.
00:11:38On a donc abordé cela comme un problème dynamique :
00:11:42pour un tableau simple, parfait, on peut approximer ces données en Markdown.
00:11:47Pour un tableau plus complexe, il vaut mieux utiliser le HTML,
00:11:50mais les modèles de langage ne sont pas le seul élément à prendre en compte.
00:11:55Si vous faites du vectoriel (embeddings),
00:11:57vous aurez aussi le problème secondaire de la recherche de ce contexte.
00:12:01Ce même tableau que je vous montrais tout à l'heure,
00:12:03sa représentation HTML est vraiment très illisible.
00:12:08La grande majorité de l'extrait n'est composée que de balises HTML.
00:12:11Elles ne servent qu'à classifier la structure du document.
00:12:14Et le problème, c'est que là où dans des évaluations globales,
00:12:17on peut avoir du contenu qui mâche le travail du modèle
00:12:22en indiquant exactement ce qu'on cherche,
00:12:24un utilisateur réel ne va pas lister toutes les valeurs du tableau.
00:12:28Il va juste demander : “Comment le chiffre d'affaires a-t-il évolué ?”
00:12:30En partant du principe qu'on va retrouver le bon tableau au bon moment.
00:12:34Et même si les LLM arrivent à analyser ce texte efficacement,
00:12:37si l'on cherche dans un grand corpus,
00:12:39on remarque que les modèles d'embedding ont du mal à faire le lien entre cette requête humaine
00:12:44et ce bloc confus de chiffres et de balises HTML.
00:12:47Une excellente chose à faire, qui demande très peu d'effort,
00:12:51est de créer une représentation pensée pour le modèle d'embedding lui-même.
00:12:55En reprenant le même tableau,
00:12:56on crée une description en langage naturel de ce tableau,
00:12:58pour avoir le meilleur des deux mondes.
00:13:00Quand on transmet les données au modèle pour le raisonnement,
00:13:02on utilise la version HTML du tableau,
00:13:04et quand il s'agit de récupérer les bons extraits,
00:13:07on utilise ce bloc en langage naturel.
00:13:12Au-delà de ça, il y a aussi l'idée qu'il reste plein d'aspects qui dépassent le simple parsing.
00:13:18L'industrie s'est beaucoup concentrée sur le parsing et l'extraction par le passé,
00:13:22parce qu'on pense vraiment qu'il y a un énorme gain à faire là.
00:13:25Et je vous ai parlé plus tôt du benchmark GDP PDF,
00:13:30qui est selon moi un très bon exemple illustratatif de ce qu'on peut obtenir
00:13:34en améliorant son pipeline de données.
00:13:37Ce qu'on a constaté, c'est qu'en reprenant exactement le même benchmark,
00:13:40malheureusement nous n'avons pas pu le tester sur Fable,
00:13:43notre accès ayant été coupé.
00:13:46Mais si vous testez d'autres modèles en leur fournissant le PDF d'origine
00:13:50ainsi qu'une représentation structurée de ce PDF,
00:13:52comme les résultats parsés ici, vous verrez que quel que soit le modèle,
00:13:55que ce soit Gemini, Anthropic ou OpenAI,
00:13:58les performances finales du LLM s'améliorent simplement avec de meilleures données en entrée.
00:14:04À tel point que des modèles comme GPT-5.5 et Opus
00:14:09surpassent Fable nativement,
00:14:12non seulement en précision, mais parce que grâce à des entrées de meilleure qualité,
00:14:17les modèles ont besoin de moins de tokens de raisonnement.
00:14:20Ils se concentrent moins sur la mise en forme et plus sur les résultats.
00:14:24Résultat : cela réduit la latence
00:14:27et permet d'obtenir la bonne réponse plus rapidement.
00:14:30Mais même une fois ce pipeline mis en place,
00:14:33et qu'on a tout inspecté en détail
00:14:37dans la couche d'analyse, il reste beaucoup de travail humain
00:14:41pour comprendre l'étendue de ce qu'on a dans le corpus,
00:14:44l'orienter vers le bon pipeline et décomposer le problème,
00:14:48ou même, à la fin, éditer et modifier les documents.
00:14:51On a donc essayé d'aborder ce problème sous cet angle :
00:14:54comment s'assurer que chaque interaction du modèle de langage
00:14:57avec le document soit aussi efficace que si un humain l'avait faite ?
00:15:00Si vous remplissez un formulaire, comment garantir la précision
00:15:03dans la saisie des champs ?
00:15:05Un très bon exemple de cela du côté de l'orchestration,
00:15:08c'est que le découpage par classification est un moyen sous-estimé
00:15:12d'obtenir le meilleur d'un LLM.
00:15:14Évidemment, on peut juste fournir autant de contexte qu'on veut.
00:15:17Et si c'est pour un test d'aiguille dans une botte de foin,
00:15:19ça peut convenir.
00:15:20Mais en pratique, on constate une baisse de qualité
00:15:24au-delà du coût en jetons, quand on transmet trop d'informations.
00:15:28Au lieu de cela, on gagne énormément en efficacité
00:15:33en réfléchissant à la manière d'orienter les bons documents
00:15:36vers le bon type de pipeline.
00:15:38Et même pour les gros documents, comment s'assurer qu'on transmet
00:15:41les extraits réellement pertinents ?
00:15:43On voit des cas d'usage avec du courrier papier,
00:15:47et ces paquets de courrier peuvent faire des centaines de pages.
00:15:50On ne sait pas nécessairement ce qu'ils contiennent.
00:15:53Quelqu'un a pu mélanger le contenu des documents,
00:15:57et demander au modèle d'effectuer ce tri le distrait
00:16:01du véritable objectif à atteindre,
00:16:03qui peut être d'extraire les données du courrier,
00:16:05d'analyser ou de prendre une décision.
00:16:10Comme je l'ai mentionné plus tôt, la seconde partie est,
00:16:13selon moi, la plus intéressante : c'est une fois qu'on a
00:16:16la couche initiale de classification et de découpage,
00:16:20et qu'on a résolu le tri.
00:16:22Ce qui nous passionne vraiment au sein de l'équipe,
00:16:26c'est que les structures d'agents ouvrent une voie très prometteuse
00:16:29pour dépasser des problèmes historiquement complexes et non résolus.
00:16:34Un bon exemple dont je vais parler dans un instant,
00:16:37ce sont les graphiques linéaires.
00:16:39On travaille avec les plus grands fonds d'investissement au monde,
00:16:41et les graphiques linéaires ont toujours été très difficiles
00:16:43à traiter, d'abord parce qu'ils sont au format image.
00:16:46Mais aussi parce qu'il y a une précision au niveau du pixel
00:16:49qu'un encodeur visuel classique
00:16:52va probablement perdre.
00:16:53Vous obtiendrez la tendance générale des revenus,
00:16:55mais pas les points de données individuels.
00:16:57On a donc réfléchi à la façon de donner aux agents
00:17:00les bons outils pour résoudre le type de problème spécifique
00:17:04auquel vous faites face.
00:17:05Dans le cas de l'extraction, le graphique de gauche contient
00:17:09un tableau massif de données.
00:17:11S'il fallait tracer chaque pixel un par un,
00:17:14ce serait extrêmement difficile.
00:17:16Et ce serait aussi difficile pour un modèle d'estimer
00:17:19les subtilités des lignes intermédiaires.
00:17:22Et aucun modèle ne peut faire ça directement
00:17:24en une seule tentative.
00:17:25Ce que vous voyez à droite est une reconstruction
00:17:28du tableau Markdown généré
00:17:30à partir du graphique linéaire initial.
00:17:32Et le seul moyen d'y parvenir
00:17:34a été d'utiliser un agent doté de toutes sortes d'outils.
00:17:36Il possède son propre interpréteur de code.
00:17:37Il peut visualiser le graphique qu'il génère,
00:17:40et il avance de manière itérative.
00:17:41Il repère les erreurs dans le graphique encore et encore,
00:17:45jusqu'à obtenir le résultat final.
00:17:47Cela s'applique aussi à l'extraction structurée,
00:17:51où, depuis un moment, nous avons cette fonction
00:17:53de conversion de document en données structurées.
00:17:55Mais on peut aller encore plus loin
00:17:57en articulant un agent autour de ce type de tâche.
00:18:00Un agent parent peut définir des critères de validation
00:18:03que les sous-agents devront suivre.
00:18:05Ainsi, sur un formulaire douanier CBP
00:18:09comprenant des dizaines de milliers de champs,
00:18:11c'est typiquement là qu'apparaissent
00:18:13de nombreux problèmes invisibles.
00:18:15On oublie du contenu, on saute des lignes.
00:18:17Et MicroOne a publié un excellent benchmark
00:18:20dans ce domaine ce matin, montrant une division
00:18:23sur le marché.
00:18:24Les modèles de pointe à fort raisonnement sont très précis.
00:18:28Tant qu'ils ont extrait une ligne,
00:18:30il y a peu de chances qu'elle soit hallucinée.
00:18:31Elle est généralement correcte.
00:18:33Mais ils omettent silencieusement beaucoup de contenus.
00:18:37Leur taux de rappel est très faible.
00:18:39À l'inverse, les services dédiés au traitement de documents
00:18:42sont en retrait par rapport aux grands modèles en précision,
00:18:46mais rattrapent leur retard sur le rappel.
00:18:48Il y a donc toujours eu ce compromis.
00:18:51Et c'est seulement grâce à une architecture d'agents
00:18:54qu'on a pu atteindre ce maximum local de précision
00:18:57et de rappel pour ce genre de tâche.
00:19:00Enfin, et c'est peut-être le point le plus important,
00:19:04je pense qu'au bout du compte, les évaluations doivent guider
00:19:09toutes vos décisions.
00:19:10C'est au cœur de la conception de notre produit.
00:19:12Cela vaut pour les jeux de données standards d'évaluation,
00:19:16mais aussi pour le suivi en production en temps réel.
00:19:19Car vos données réelles seront différentes
00:19:21de ce que vous avez dans vos jeux d'essais.
00:19:25Il est vraiment essentiel de ne pas voir les évaluations
00:19:28comme une simple vue d'ensemble macro,
00:19:30car les meilleures équipes avec lesquelles nous travaillons
00:19:33les analysent en détail à chaque étape de leur pipeline.
00:19:36La première chose est de s'assurer
00:19:38que les données d'entrée du pipeline sont excellentes.
00:19:40Il faut bien sûr évaluer votre pipeline de parsing.
00:19:43Mais un parsing parfait avec un mauvais système de recherche
00:19:47ne servira à rien si le bon contexte n'est pas transmis.
00:19:50Il est donc crucial de peaufiner les détails
00:19:52comme votre pipeline de recherche d'information,
00:19:54votre formatage en sortie de pipeline,
00:19:56et surtout, le point le plus important,
00:19:58parvenez-vous à améliorer les performances globales de l'agent ?
00:20:03Je vais conclure en résumant notre direction
00:20:06et les évolutions que nous observons dans le secteur.
00:20:08À mesure que les agents s'améliorent,
00:20:12on peut s'éloigner des pipelines déterministes
00:20:15utilisés il y a encore quelques années.
00:20:17Beaucoup de nos clients créent une sorte de système de fichiers
00:20:20dans lequel leur agent peut naviguer
00:20:22en le laissant choisir lui-même les outils à utiliser.
00:20:25Nous créons donc une CLI où, plutôt que de définir un flux fixe
00:20:28où les documents suivent toujours le même parcours,
00:20:32l'agent décide s'il doit lire un certain type de document,
00:20:35et séparera les données en deux ensembles.
00:20:38L'un contient le texte brut, consultable par l'agent selon ses besoins,
00:20:41et l'autre rassemble toutes les métadonnées utiles.
00:20:44Si vous gérez des citations, vous voudrez des zones de délimitation,
00:20:47et ainsi de suite.
00:20:50Je vais passer la partie sur l'édition.
00:20:52Des travaux très intéressants sont en cours ici.
00:20:54Nous en avons déjà publié une partie, mais ces prochains mois,
00:20:57nous nous tournerons de plus en plus vers la génération de documents.
00:21:01Pour résumer aujourd'hui, et je vous remercie de votre attention,
00:21:04un : je vous recommande vivement de décomposer le problème de parsing.
00:21:08Dans la mesure du possible, choisissez le bon outil pour chaque tâche
00:21:11afin d'atteindre l'équilibre optimal entre précision, coût et latence.
00:21:16Deux : la vérification par agent est la plus grande avancée du secteur depuis un moment,
00:21:21et c'est une excellente occasion de concevoir des pipelines fiables en production.
00:21:26Trois : cela demande peu d'efforts, mais apporte un vrai plus de soigner les détails,
00:21:31comme adapter le formatage de la donnée à son destinataire.
00:21:34Quatre : il est crucial de penser non seulement au traitement des données,
00:21:39mais aussi à leur orchestration.
00:21:41Considérez toujours la classification et le découpage
00:21:44comme des moyens d'enrichir votre pipeline.
00:21:46Cinq : assurez-vous d'évaluer vos résultats à chaque étape.
00:21:49Et six : réfléchissez à ce que sera votre prochaine étape,
00:21:52car la plupart des entreprises performantes aujourd'hui ont beaucoup évolué
00:21:56par rapport aux pratiques d'il y a deux ou trois ans.
00:21:59Si vous avez des questions, n'hésitez pas à nous contacter à tout moment.
00:22:03Mon e-mail est simplement prenom@reducto.ai.
00:22:06Vous pouvez aussi nous écrire via notre site web si nous pouvons vous être utiles.
00:22:10Merci.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video