Parsing de documents : plusieurs approches, pour le PDF.
Le parsing de documents reste une tâche complexe, même en 2024.
Globalement le "nettoyage", la préparation des données (#dataprep), que ce soit pour des actions de data-analyse, de data-visualisation, pour faire ingérer des données ensuite à un modèle de langage ou pour faire autre chose, n'est pas une petite tâche, surtout dans un monde basé sur la donnée. Oui, c'est un métier !
Si cette #dataprep n'est pas correctement et très précisément effectuée, le sens des résultats qui suivront sera altéré, et toute la chaine qui suit n'aura plus de sens.
Il faut formater, nettoyer, tenter de normer, et parfois prendre en compte des aberrations ou d'autres problématiques complexes (volume de données par exemple), etc...
Cette phase préparatoire, qui se fait "dans l'ombre", un peu "en sous marin", est réellement essentielle.
Tout ceci serait tellement plus facile si on travaillait tous sur des documents formatés grâce #Markdown par exemple, et non pas sur des outils propriétaires, qui possèdent leurs propres normes, biais, aberrations... Mais je m'égare un peu.
Revenons à ce format PDF en particulier - format destiné à l'impression à la base, et donc absolument pas dédié à la manipulation de données : ne l'oublions pas ! Nous ne sommes pas en train de parler d'un CSV...
Si on veut permettre une discussion sur un contexte de données, via par exemple une interface de chat LLM, basée sur du RAG (Retrieval Augmented Generation) il faudra au préalable parser les documents pour en extraire la sève, et surtout en garder le sens, sans rien oublier, sans pondérer un concept contenu dans le document plus qu'un autre, etc...
Les ingénieurs de Cohere ont fait des tests avec les meilleurs solutions qui existent actuellement (NDLR : pour eux). Ce test est disponible sur un Google Colab.
Ils ont fait le test sur les spécifications d'un médicament, pour en sortir la description, les indications, les voies d'administration, sa composition etc...
Autant dire des concepts sur lesquels on ne rigole pas trop quand on travaille dans la pharma ou la santé. 🥃
Ils ne font pas de conclusion.
A nous de voir et de tester en fonction de nos cas d'usage.
Je vous laisse quand même réfléchir un peu aussi... :)
La chose qui est claire : à moins que les entreprises soient prêtes à "se payer" une batterie de "data engineer", il va falloir passer par ces solutions expertes pour extraire la sève de nos données, qu'on soit une agence de communication avec 40T de données, un cabinet expert de je ne sais quoi, une industrie avec des millions de documents, une entité étatique etc... etc...
Ré-inventer la roue, ca ne va pas le faire du tout. Il va falloir aller chercher des solutions robustes en fonction de nos propres paramètres : propriétaire ? open source ?
Je m'arrête là. J'espère que ce post n'est pas trop technique.
Faites le moi savoir sinon.
Echangeons