← blog
article2025-11-21·9 min de lecture

Knowledge Extraction on Semi‑Structured Content : toujours utile pour le Question Answering à l’ère des LLMs ?

Illustration minimaliste : page web encombrée, entonnoir triant des blocs S-R-O, robot LLM casqué assemblant un graphe de connaissances, avec bulle

Lecture du papier « Knowledge Extraction on Semi‑Structured Content: Does It Remain Relevant for Question Answering in the Era of LLMs? » (Sun et al., 2025).


Pourquoi ce papier attire l’œil

Dans le petit monde des systèmes de question‑réponse (QA, Question Answering) branchés sur le Web, une question tourne en boucle : faut‑il encore extraire des connaissances (les célèbres triples sujet—relation—objet) quand on possède des LLMs (Large Language Models) si doués pour « lire » des pages ? Le papier de Kai Sun et al. attaque frontalement ce dilemme. Et sa réponse n’est pas binaire : oui, l’extraction reste utile — mais pas partout, pas toujours, et surtout pas de la même façon qu’avant.

Imaginez des boîtes de LEGO. Les pages Web semi‑structurées (tables HTML, fiches produit, listes, infoboxes) sont des boîtes à moitié triées. Les LLMs d’aujourd’hui sont de meilleurs constructeurs que jamais : sur une boîte propre, ils assemblent vite le modèle. Mais dès qu’on renverse sur le tapis un vrac de pièces (les « vraies » pages complètes, pleines de pub, de menus et de bruit), ils cherchent plus longtemps. L’extraction de connaissances, c’est le sachet de tri : on pré‑classe les briques en « pièces rouges 2×4 », « fenêtres », « roues ». Le papier montre qu’ajouter ce tri aide encore, surtout quand le vrac est corsé ou quand on a un petit constructeur (petits modèles de LLM).


Résumé vulgarisé : que font les auteurs, et qu’obtiennent‑ils ?

Les auteurs étendent un benchmark existant pour couvrir deux tâches : extraction de triples et question‑réponse sur du contenu semi‑structuré (trois formes : A‑V pour Attribute–Value — attribut/valeur, Hz pour tables horizontales, et F‑F pour Free‑Form, du texte semi‑structuré). Ils testent plusieurs LLMs (petits ≈ 3B paramètres, grands ≈ 70B, et commerciaux type GPT‑4o / Claude Sonnet) dans deux cadres : sur des pages nettoyées (via Trafilatura) et sur des pages complètes telles qu’on les rencontre dans un système RAG (Retrieval‑Augmented Generation).

Trois résultats clés (dit sans jargon)

  1. Extraire est encore dur, surtout à l’échelle du Web. Sur des pages nettoyées, les LLMs atteignent 77 % de F1 pour l’extraction de triples, loin devant d’anciens systèmes (≈ 46 %). Mais sur des pages complètes, la F1 tombe à 28 %. Autrement dit : sur une boîte de LEGO bien triée, ça va ; sur le vrac du salon, c’est la galère.

  2. Le QA brut des LLMs est élevé sur propre, moyen sur réel — et l’augmentation par triples aide. Sur des pages nettoyées, certains LLMs atteignent ≈ 95 % d’accuracy en QA, mais sur des pages complètes, la qualité chute à ≈ 76 %. Ajouter des triples “vérité terrain” (ground‑truth) remonte la précision jusqu’à ≈ 84 % sur les pages complètes. C’est le sachet de tri qui sauve la mise quand le vrac déborde.

  3. Former les modèles à “savoir extraire” améliore le QA — et se combine bien avec l’augmentation. En multi‑tâches (QA + extraction), la qualité QA égale celle obtenue en ajoutant des triples ground‑truth (83,5 % vs 83,8 %), et les cumuler pousse la QA jusqu’à 87 % (sur les pages complètes, le boost total peut atteindre +11 %). Sur nos LEGO : entraîner le constructeur à reconnaître les pièces + lui donner des sachets triés, c’est encore mieux.

Cerise sur le gâteau : les auteurs explorent une piste low‑cost. Plutôt que de payer du calcul LLM pour extraire page par page, ils incitent le modèle à générer des scripts d’extraction à partir de quelques exemples — des « recettes » réutilisables pour des pages au gabarit similaire. Surprise agréable : ces scripts généralisent entre sites et atteignent 61 % de F1 sur des pages nettoyées, avec +5 pts d’accuracy QA par rapport au zéro‑shot. Mais, honnêteté scientifique oblige, « nous n’avons pas vu de succès sur des pages complètes » (où la mise en script est plus dure).


Méthodo, sans se faire mal

Le protocole est raisonnable et transparent. Les auteurs distinguent « cleaned pages » (pages ramenées à l’essentiel via Trafilatura, donc moins de bruit et de tokens) et « whole webpages » (tout le bazar : barres de navigation, pop‑ups, micro‑textes). Sur les pages nettoyées, les LLMs “lisent” déjà très bien ; sur les pages complètes, la limite de contexte et le bruit structurel reviennent en boomerang. Côté formats, A‑V et F‑F sont plus cléments que Hz (tables horizontales) où il y a moins d’invariants visuels entre sites — l’analogie LEGO : moins de repères communs, plus de risques d’assembler la fenêtre à l’envers.

Pour améliorer le QA, ils testent trois leviers : (i) augmentation par triples (on injecte des triples dans le contexte à l’inférence), (ii) fine‑tuning QA seul, (iii) fine‑tuning multi‑tâches (QA + extraction). On observe alors un pattern clair : les petits modèles (≈ 3B) profitent fortement de l’augmentation et du multi‑tâches ; les gros (≈ 70B ou plus) gagnent un peu sur pages propres, davantage sur pages complètes ; et l’addition “apprendre à extraire” + “ajouter des triples” est complémentaire, surtout quand le terrain est difficile (pages complètes, horizontales).


Quelques chiffres saillants (avec un soupçon de contexte)

  • Extraction de triples : 77 % F1 (pages nettoyées) vs 28 % (pages complètes). Traduction LEGO : avec le tapis bien dégagé, on retrouve vite les pièces ; avec des miettes et des notices froissées, on galère.

  • QA (zéro‑shot/fine‑tuning) sur pages nettoyées : les grands modèles (Llama‑70B, GPT‑4o, Claude Sonnet) flirtent avec 95–97 % ; un petit Llama‑3B, une fois fine‑tuné, peut monter jusqu’à 98 % (in‑domain). Sur pages complètes, même les gros modèles descendent (ex. 86 % pour GPT‑4o), laissant de la marge au fine‑tuning multi‑tâches et aux triples.

  • Augmenter avec des triples : sur pages complètes, passer de ≈ 76 % à ≈ 84 % avec des triples ground‑truth ; sur pages nettoyées, gains notables surtout pour les petits modèles ou les formats Hz/F‑F. Multitâche + triples peut cumuler les bénéfices (jusqu’à 87 %).

  • Scripts d’extraction générés : 61 % F1 sur nettoyées, +5 pts d’accuracy QA en zéro‑shot ; peu concluant sur pages complètes (le monde réel aime le chaos).


Pourquoi c’est intéressant (et pas que pour les chercheurs)

Pour l’IA pratique et le RAG en prod. Si votre pipeline RAG aspire des pages entières (et non des fragments déjà nettoyés), vous êtes dans la zone où l’extraction aide vraiment. Deux options complémentaires : entraîner le modèle à extraire (il apprend à repérer les « pièces » dans le vrac) et ajouter des triples à l’inférence (vous lui donnez des « sachets triés »). Les gains sont concrets quand la page ressemble à une page de magasin pleine de sections répétitives, de grilles de specs et de recommandations.

Pour les équipes data/ML à budget mesuré. L’extraction LLM « brute » coûte cher à l’échelle : on fait tourner le modèle page par page. La piste scripts générés est séduisante : pour des sites au gabarit stable, on capitalise sur des « recettes » réutilisables. Certes, ce n’est pas encore la panacée sur tout le Web, mais c’est un chemin scalable. Et on peut aussi indexer ces triples en base (pour de la recherche, de l’intégration, de l’audit) — autre bénéfice mis en avant par les auteurs.

Pour les devs et intégrateurs. On peut imaginer un stack hybride : crawler ➜ nettoyage léger (booster le signal) ➜ extraction scriptée si possible ➜ stockage des triples ➜ RAG qui “voit” la page + les triples ➜ LLM finement ajusté au multi‑tâches. En pratique, ça revient à mettre des garde‑fous sémantiques et structurels autour du modèle. On ne renonce pas au texte brut (parfois il contient des nuances utiles), mais on donne au modèle un « squelette de faits » fiable sur lequel s’agripper.

Pour les créateurs de jeux (oui, oui). Imaginez un codex de votre univers (objets, personnages, règles) exposé en pages semi‑structurées (wikis, fiches). Les triples deviennent des cartes de loot faciles à butiner par un PNJ scribe (votre LLM). Sur des fiches propres, le scribe gère sans aide ; sur un wiki vivant à la structure instable, le tri préalable et l’entraînement multi‑tâches amélioreront la cohérence des quêtes générées (« qui a forgé cette épée ? » ne pointera plus aléatoirement sur le boulanger).


Extraits qui claquent (et parlent d’eux‑mêmes)

« Web‑scale knowledge extraction remains challenging even with LLMs. »

« Augmenting the pages with ground‑truth knowledge triples can increase QA accuracy to 84%. »

« Multi‑task fine‑tuning on both QA and triple extraction [...] is comparable to augmenting webpages with ground‑truth triples (83.5% vs. 83.8%). »

« Such [script‑based] methods can generalize across websites, yielding a 61% F1‑score [...] Additionally, the extracted triples can bring a 5% gain in accuracy over zero‑shot. »

« We have not seen success on whole webpages, where scripting is much harder. »

(Chaque citation a été tenue sous 25 mots.)


Limites (et comment les apprivoiser)

Le papier le dit lui‑même : l’extraction de qualité reste dure à l’échelle du Web réel, et coûteuse quand on la fait par LLM page‑à‑page. Les scripts sont prometteurs mais fragiles dès que la mise en page ou le DOM change. Enfin, sur des pages nettoyées, les LLMs SOTA frisent déjà la saturation — l’utilité marginale des triples diminue. Bref : choisissez votre stratégie selon le terrain. Sur un intranet propre ou un site à structure stable, le multi‑tâches suffira peut‑être. Sur un agrégateur hétéroclite ou des pages longues avec grilles et carrousels, augmentez par des triples (idéalement de bonne qualité) et préparez quelques scripts pour amortir les coûts.

Côté métriques, gardez un œil sur : F1 d’extraction, Accuracy QA, coût par page, robustesse inter‑site et impact par format (A‑V, Hz, F‑F). Dans l’atelier LEGO, c’est l’équilibre entre temps de tri et temps d’assemblage qui fait la différence — pas l’un ou l’autre en absolut.


Conclusion (avec clin d’œil)

Alors, l’extraction de connaissances est‑elle encore pertinente à l’ère des LLMs ? Oui — comme un bon sachet de tri dans une boîte de LEGO géante. Sur des scènes propres, nos « maîtres‑constructeurs » peuvent parfois s’en passer. Dans le monde réel, avec ses pages bavardes et ses tableaux capricieux, le tri reste payant, surtout si l’on apprend au modèle à trier et qu’on lui donne des sachets quand il en a besoin. La prochaine fois que votre QA trébuche sur une fiche produit en spaghetti HTML, pensez « tri + apprentissage multi‑tâches ». Et si votre LLM insiste pour construire la tour à l’envers, rappelez‑lui que les notices, ça se lit.


Acronymes (rappel express)

  • LLM (Large Language Model) : grand modèle de langage.
  • QA (Question Answering) : question‑réponse automatique.
  • RAG (Retrieval‑Augmented Generation) : génération augmentée par récupération.
  • F1 : moyenne harmonique précision/rappel en extraction.
  • A‑V / Hz / F‑F : formats de semi‑structuré (Attribute–Value, Horizontal tables, Free‑Form).

Référence

Sun, K., Huang, Y., Mehra, S., Kachuee, M., Chen, X., Tao, R., Lin, Z., Jessee, A., Shah, N., Betty, A., Liu, Y., Kumar, A., Yih, W., & Dong, X. L. (2025). Knowledge Extraction on Semi‑Structured Content: Does It Remain Relevant for Question Answering in the Era of LLMs? arXiv:2509.25107. https://arxiv.org/abs/2509.25107