Manuels scannés et tickets photo : comment un graphe de connaissances met fin à 22 minutes de recherche support

Points clés

• 70 % d'une bibliothèque support de 12 000 documents n'a pas de couche de texte — pour un fabricant de pompes de 460 salariés, près de 126 000 pages sont invisibles aussi bien pour la recherche par mots-clés que pour un index vectoriel texte seul.
• Les pplx-embed-v2-late de Perplexity ont atteint 92,4 % de précision de réponse sur MADQA — un agent a répondu à 500 questions sur 800 PDF réels couvrant plus de 18 000 pages en cherchant directement des pages rendues, sans pipeline d'OCR, version publiée le 7 octobre 2026.
• L'encodeur de requêtes 0.6B peut interroger un index construit avec le modèle 9B — l'espace d'embeddings partagé couple une indexation de pages coûteuse hors ligne à des requêtes en direct bon marché, et le modèle 0.6B pèse 594M de paramètres sous licence MIT.
• Le déploiement GraphRAG en production de LinkedIn a amélioré la précision de récupération de 77,6 % — les arêtes structurelles d'un graphe de connaissances sont ce qu'un index vectoriel ne voit pas.
• Une règle de citation de page change le mode de défaillance — aucune réponse ne sort de l'agent sans sa page du document, son numéro de pièce et sa plage de série ; tout ce qui n'est pas vérifiable passe en escalade humaine au lieu de partir chez un client.

Trois cents des 950 tickets qu'un fabricant de pompes et d'équipements hydrauliques de taille intermédiaire reçoit chaque semaine ne sont pas des plaintes produit. Ce sont des questions documentaires : quel helice correspond à une SP-200 de 1998 au numéro de série 43-11092, quel bulletin de service remplace le tableau des couples du manuel d'O&M, quel composé de joint l'édition de 2014 prescrit — chacune arrivant avec la photo d'une plaque signalétique ou le scan d'une page de manuel en pièce jointe. La bibliothèque technique derrière ces questions détient 12 000 documents et environ 180 000 pages. Près de 70 % sont du papier scanné sans couche de texte, datant des années 1970, et le moteur de recherche de Zendesk n'en lit rien.

Le coût apparaît dans deux files. En interne, six techniciens de support passent en moyenne 22 minutes de fouille manuelle par question documentaire — ouvrant des PDF les uns après les autres, rapprochant une photo de téléphone et une courbe de pompe à l'œil. En externe, les revendeurs écrivent à la boîte support et attendent une médiane de 14 heures avant une réponse. Deux techniciens seniors traitent 55 % des questions documentaires escaladées, absorbant environ 19 heures par semaine des fouilles des autres. Et la pire défaillance n'est pas la lenteur : un schéma mal lu expédie la mauvaise cartouche, entraîne un cycle de réapprovisionnement plus une seconde visite, et a coûté à cette société environ 38 000 $ l'an dernier en fret et gestion des retours.

Cet article décrit la solution à trois couches — un graphe de connaissances au niveau de la page posé sur la bibliothèque documentaire, des embeddings à interaction tardive qui cherchent dans des pages PDF rendues sans étape d'OCR, et un flux agent qui répond avec la page exacte en pièce jointe — chaque couche ancrée à sa source primaire : la publication de Perplexity du 7 octobre 2026 et le déploiement GraphRAG en production de LinkedIn.

Le problème : la bibliothèque où tout le monde a cessé de chercher

Chaque fabricant avec un passé papier possède cette bibliothèque. Les manuels des cinq dernières années sont nés numériques. Tout ce qui est plus ancien est arrivé au scanner : courbes de pompes, schémas de câblage, dessins éclatés, tableaux de dimensions. Certaines pages ont un texte lisible ; beaucoup sont des scans dégradés avec trous de classeur, pliures et annotations manuscrites en marge. Les 30 % avec un texte cherchable sont la partie facile ; les 70 % restants sont un mur d'images étiqueté seulement par le nom de fichier — c'est pourquoi la recherche par mots-clés et un index vectoriel texte seul échouent de la même façon : tous deux exigent un texte qui n'existe pas.

La solution évidente — « passe simplement l'archive à l'OCR » — est morte de la mort habituelle. Les erreurs OCR se cumulent sur les scans dégradés et retombent là où se situe la valeur métier : les axes des courbes de pompes deviennent des caractères parasites, les tableaux de dimensions se désalignent, les colonnes des nomenclatures fusionnent. C'est le pipeline analyser-puis-chercher que l'équipe Perplexity qualifie d'« coûteux et destructif » — qui jette « la mise en page, la structure des tableaux, les figures et les relations spatiales » avant même que la récupération voie la page. Une reconstruction OCR de cette bibliothèque a été chiffrée à six chiffres et n'a pas été financée une seconde fois.

Un pilote de recherche vectorielle a échoué pour une autre raison : le texte embarqué rendait la bonne forme de courbe de pompe pour la mauvaise révision, une spécification de joint d'un manuel que la machine du client ne correspond pas. Rien dans un index vectoriel ne sait qu'un helice succède à un autre ou qu'un tableau des couples a été retiré pour une plage de série — des résultats plausibles, confiants et faux, exactement la réponse qui expédie la mauvaise pièce. L'assistant a été mis au placard ; les deux techniciens seniors restaient le système d'enregistrement. L'article précédent de ce site sur le graphe de connaissances support montre le même mode de défaillance sur de la documentation logicielle ; sur des bibliothèques matérielles scannées, il choisit la mauvaise page au lieu du mauvais contournement.

La solution orchestrée par agents : un graphe sous les pages, des embeddings sur les pages

Le modèle qui fonctionne fait faire à chaque couche uniquement ce en quoi elle est bonne.

Couche 1 — un graphe de connaissances au niveau de la page. Chaque document devient un nœud ; chaque page qu'il contient aussi, avec son image rendue stockée une seule fois. Pièces, modèles de pompes, plages de série et révisions sont des nœuds, et les arêtes sont les faits qui répondent aux questions : le manuel 4412 documente le modèle SP-200 ; la page 118 contient le tableau des helices ; l'helice 88-114 remplace la 88-114A pour les séries supérieures à 43-0850 ; le bulletin 91-07 retire le tableau des couples de la page 40 ; et — extrait de l'historique des commandes NetSuite — le série 43-11092 a été expédié à un revendeur précis en 1998 et son propriétaire détient un contrat de service. Rien de tout cela n'exige que les pages soient du texte. Le graphe est bâti à partir des catalogues, des registres de commandes et des fiches de révision que l'entreprise tient déjà.

Couche 2 — des embeddings au niveau de la page sur les pages rendues. Les 70 % scannés n'ont jamais besoin d'OCR : la famille pplx-embed-v2-late de Perplexity, publiée le 7 octobre 2026, « gère la récupération texte-vers-image, permettant de chercher directement dans des pages PDF rendues sans exiger d'OCR ni de texte analysé ». Les deux tailles — 0.6B et 9B, sous licence MIT sur Hugging Face — produisent un vecteur de 128 dimensions par token et notent par MaxSim à la ColBERT, ce qui préserve le détail qu'exige une question de pompe : « helice », « SP-200 » et un diamètre d'arbre dessiné correspondent à des régions différentes de la même page rendue. Sur MADQA — 800 PDF hétérogènes réels, plus de 18 000 pages, 500 questions rédigées pour ne pas être résolubles par la connaissance générale —, le modèle 9B répond correctement à 92,4 % et le 0.6B à 90,1 % ; sur le benchmark documentaire visuel ViDoRe(v3), le modèle 0.6B égale des modèles dotés de cinq fois ses paramètres actifs. Comme les deux modèles partagent un même espace d'embeddings, la bibliothèque est indexée une fois avec le 9B tandis que les requêtes en direct des tickets passent par l'encodeur 0.6B — qui peut tourner intégralement sur du matériel sous le contrôle du fabricant, un détail qui compte quand les manuels portent la confidentialité du site client.

Couche 3 — le flux agent qui finit en citation, pas en paragraphe. Des modules connecteurs parlant le Model Context Protocol (MCP) enveloppent Zendesk (ticket, demandeur, pièces jointes), NetSuite (commandes, historique des séries, statut de garantie) et l'outil d'interrogation du graphe. Le flux : l'agent lit le ticket et sa photo jointe, interroge les embeddings pour des pages rendues candidates, puis traverse le graphe pour confirmer ce que la page candidate affirme — la bonne révision, la bonne plage de série, le bon statut de remplacement — et répond avec la page PDF réelle en pièce jointe, le numéro de pièce en texte et l'autorité énoncée (« selon le bulletin 91-07, tableau en page 40 »). La règle de gouvernance tient en une ligne et elle porte la charge : pas de citation de page, pas d'envoi — le ticket passe en escalade humaine. Une question d'achat passe la main à un moteur de RFQ qui maintient une disponibilité en direct sur la pièce de rechange, clôturant la résolution par un devis chiffré ; les demandes des revendeurs sont déléguées par un agent A2A à périmètre borné, et chaque étape de récupération comme de graphe est journalisée sous le modèle du standard de code de modules. Le guide d'implémentation couvre la construction du graphe lui-même ; ceci est le modèle d'exploitation, pas une garantie valable pour toute archive.

Les deux techniciens seniors restent dans la boucle à une autre altitude : ils approuvent tout ce qui touche à la sécurité, examinent la file des faibles confiances signalée et traitent ce que le graphe ne peut pas fonder. Ils cessent d'être l'index de la bibliothèque.

Le résultat

Le même ticket, deux façons de le résoudre — la fouille manuelle d'aujourd'hui face au flux orchestré par agents qui répond avec la page exacte jointe :

Cibles représentatives pour un déploiement de cette forme au volume de cette entreprise, avec les preuves de benchmark sur lesquelles le modèle repose :

Métrique	Avant	Cible orchestrée par agents
Première réponse aux questions documentaires	14 heures (médiane du mail des revendeurs)	Moins de 2 minutes, citation de page + rendu joint
Temps de traitement interne médian	22 minutes de fouille manuelle	3 minutes — le technicien vérifie la page jointe
Charge d'escalade sur les seniors	55 % des questions documentaires (~19 h/semaine)	Moins de 20 % des questions documentaires
Mauvaises pièces expédiées	9 dans le trimestre (38 000 $/an)	1 dans le trimestre pilote
Pages cherchables	54 000 (les 30 % avec couche de texte)	~180 000, pages rendues en l'état

Les preuves derrière le modèle : une QA agentique sur des PDF scannés réels à 92,4 % de précision sans pipeline OCR, une récupération structurée en graphe valant 77,6 % d'amélioration de précision mesurée chez LinkedIn, et un profil démontré côté logiciel par le déploiement du graphe de connaissances support (28 heures de résolution à 7 ; escalade de 45 % à 18 %). Marqueur honnête de périmètre : MADQA est un benchmark, pas une promesse pour toute archive — c'est pourquoi la règle de citation et la revue humaine restent dans la boucle.

Le changement le plus profond est que la bibliothèque cesse de se dégrader : quel document remplace lequel, quelle pièce se substitue à laquelle, et quelle machine a reçu quelle révision est désormais consigné dans le graphe au lieu de l'être dans deux têtes qui partiront à la retraite.

Lectures connexes

• Support client à 7 heures de résolution : comment une base de connaissances graphique réduit le temps des tickets de 75 % — le cas sœur côté logiciel
• Guide d'Implémentation GraphRAG : Des Documents Textuels à la Récupération par Graphe de Connaissance en Production — le pipeline en cinq étapes qui construit le graphe au niveau de la page
• GraphRAG pour le support client : comment un graphe de connaissances répond aux questions que votre base de données ne peut pas traiter — quand la récupération structurée vaut son coût

---

Un fabricant de pompes avec 12 000 documents dont 70 % sont des scans perd 22 minutes à chaque fouille documentaire et expédie de temps en temps la mauvaise pièce parce qu'aucun système ne sait lire une courbe de pompe. Un graphe de connaissances au niveau de la page, des embeddings qui cherchent dans des pages rendues sans OCR, et un agent qui répond avec la page exacte jointe — borné par « pas de citation, pas d'envoi » — rendent la bibliothèque à nouveau apte à répondre, et le moteur de RFQ transforme « quelle pièce convient » en devis chiffré et réservé.

Demandez un build au périmètre défini

Découverte en une semaine. Vous obtenez un inventaire des systèmes, une cartographie des flux de travail et un périmètre figé — que vous construisiez avec nous ou non.