Manuales escaneados y tickets con fotos: cómo un grafo de conocimiento pone fin a la búsqueda de soporte de 22 minutos

Conclusiones clave

• El 70% de una biblioteca de soporte de 12.000 documentos no tiene capa de texto — para un fabricante de bombas de 460 empleados, unas 126.000 páginas son invisibles por igual para la búsqueda por palabras clave y para un índice vectorial solo de texto.
• Los pplx-embed-v2-late de Perplexity alcanzaron un 92.4% de precisión de respuesta en MADQA — un agente respondió 500 preguntas sobre 800 PDF del mundo real que abarcan más de 18.000 páginas buscando en páginas renderizadas directamente, sin canal de OCR, lanzado el 7 de octubre de 2026.
• El codificador de consultas de 0.6B puede consultar un índice construido con el modelo de 9B — el espacio de embeddings compartido empareja una indexación de páginas offline costosa con consultas en vivo baratas, y el modelo de 0.6B son 594M de parámetros bajo licencia MIT.
• El despliegue en producción de GraphRAG de LinkedIn mejoró la precisión de recuperación un 77.6% — las aristas estructurales de un grafo de conocimiento son lo que un índice vectorial no puede ver.
• Una regla de cita de página cambia el modo de fallo — ninguna respuesta sale del agente sin su página de documento, número de pieza y rango de serie; todo lo no verificable escala a una persona en lugar de enviarse a un cliente.

Trescientos de los 950 tickets que recibe cada semana un fabricante de bombas y equipos hidráulicos de mercado medio no son quejas de producto. Son preguntas de documentos: qué impulsor encaja en una SP-200 de 1998 construida con el número de serie 43-11092, qué boletín de servicio sustituye a la tabla de pares del manual de O&M, qué compuesto de junta pide la revisión de 2014 — cada una llega con la foto de una placa de características o el escaneo de una página de manual adjunto. La biblioteca técnica detrás de esas preguntas guarda 12.000 documentos y unas 180.000 páginas. Cerca del 70% es papel escaneado sin capa de texto, que data de los años setenta, y el buscador de Zendesk no lee nada de ello.

El coste aparece en dos colas. Internamente, seis técnicos de soporte promedian una búsqueda manual de 22 minutos por cada pregunta de documento — abriendo PDF tras PDF, cotejando la foto de un teléfono con una curva de bomba a ojo. Externamente, los distribuidores escriben a la bandeja de soporte y esperan una mediana de 14 horas por una respuesta. Dos técnicos senior atienden el 55% de las preguntas de documentos escaladas, absorbiendo unas 19 horas semanales de las búsquedas de otros. Y el peor fallo no es el lento: un esquema mal leído envía el cartucho equivocado, cuesta un ciclo de reposición más una segunda visita y le costó a esta empresa unos 38.000 dólares el año pasado en flete y gestión de reposición.

Este artículo traza la solución de tres capas — un grafo de conocimiento a nivel de página sobre la biblioteca documental, embeddings de interacción tardía que buscan en páginas PDF renderizadas sin paso de OCR, y un flujo agéntico que responde con la página exacta adjunta — cada capa anclada a su fuente primaria: la publicación del 7 de octubre de 2026 de Perplexity y el despliegue en producción de GraphRAG de LinkedIn.

El problema: la biblioteca en la que todo el mundo dejó de buscar

Todo fabricante con pasado en papel tiene esta biblioteca. Los manuales de los últimos cinco años nacieron digitales. Todo lo anterior llegó por escáner: curvas de bombas, esquemas eléctricos, planos de despiece, tablas de dimensiones. Algunas páginas tienen texto legible; muchas son escaneos degradados con taladros, líneas de plegado y anotaciones manuscritas en los márgenes. El 30% con texto buscable es la parte fácil; el otro 70% es un muro de imágenes etiquetado solo por nombre de archivo, y por eso la búsqueda por palabras clave y un índice vectorial solo de texto fallan del mismo modo: ambos necesitan un texto que no existe.

La solución obvia — «simplemente haz OCR del archivo» — murió la muerte de siempre. Los errores del OCR se acumulan en los escaneos degradados y caen justo donde está el valor de negocio: los ejes de las curvas de bomba se convierten en caracteres extraños, las tablas de dimensiones se desalinean, las columnas de las listas de piezas se fusionan. Ese es el canal de analizar-primero-luego-buscar que el equipo de Perplexity llama «caro y con pérdidas» — descarta «maquetación, estructura de tablas, figuras y relaciones espaciales» antes de que la recuperación vea la página. Una reconstrucción con OCR de esta biblioteca se presupuestó en seis cifras y no se volvió a financiar.

Un piloto de búsqueda vectorial fracasó por otra razón: el texto con embedding devolvía la forma correcta de la curva de bomba para la revisión equivocada, una especificación de junta de un manual que no corresponde a la máquina del cliente. Nada en un índice vectorial sabe que un impulsor sustituye a otro o que una tabla de pares fue retirada para un rango de serie — resultados plausibles, erróneos con confianza, exactamente la respuesta que envía la pieza equivocada. El asistente se archivó; los dos técnicos senior seguían siendo el sistema de registro. El artículo anterior de soporte con grafo de conocimiento de este sitio muestra el mismo modo de fallo en documentación de software; en bibliotecas de hardware escaneado escoge la página equivocada en lugar de la solución provisional equivocada.

La solución agéntico-orquestada: un grafo bajo las páginas, embeddings sobre las páginas

El patrón que funciona mantiene cada capa haciendo solo aquello en lo que es buena.

Capa 1 — un grafo de conocimiento a nivel de página. Cada documento se convierte en un nodo; cada página dentro de él también es un nodo, con su imagen renderizada almacenada una sola vez. Piezas, modelos de bomba, rangos de serie y revisiones son nodos, y las aristas son los hechos que responden preguntas: el manual 4412 documenta el modelo SP-200; la página 118 contiene la tabla de impulsores; el impulsor 88-114 sustituye al 88-114A para series superiores a 43-0850; el boletín 91-07 retira la tabla de pares de la página 40; y — extraído del historial de pedidos de NetSuite — la serie 43-11092 se envió a un distribuidor concreto en 1998 y su propietario tiene un contrato de servicio. Nada de esto exige que las páginas sean texto. El grafo se construye a partir de catálogos, registros de pedidos y fichas de revisión que la empresa ya mantiene.

Capa 2 — embeddings a nivel de página sobre las páginas renderizadas. El 70% escaneado nunca necesita OCR: la familia pplx-embed-v2-late de Perplexity, lanzada el 7 de octubre de 2026, «gestiona la recuperación de texto a imagen, permitiendo buscar directamente en páginas PDF renderizadas sin requerir OCR ni texto procesado». Ambos tamaños — 0.6B y 9B, con licencia MIT en Hugging Face — producen un vector de 128 dimensiones por token y puntúan con MaxSim al estilo ColBERT, lo que preserva el detalle que necesita una pregunta de bomba: «impulsor», «SP-200» y un diámetro de eje dibujado coinciden con regiones distintas de la misma página renderizada. En MADQA — 800 PDF heterogéneos del mundo real, más de 18.000 páginas, 500 preguntas escritas para que no puedan responderse con conocimiento general — el modelo de 9B responde correctamente el 92.4% y el de 0.6B el 90.1%; en el benchmark ViDoRe(v3) de documentos visuales, el modelo de 0.6B iguala a modelos con cinco veces sus parámetros activos. Como ambos modelos comparten un único espacio de embeddings, la biblioteca se indexa una vez con el modelo de 9B mientras las consultas en vivo de los tickets pasan por el codificador de 0.6B — que puede ejecutarse íntegramente en hardware que el fabricante controla, un detalle que importa cuando los manuales llevan confidencialidad del sitio del cliente.

Capa 3 — el flujo agéntico que termina en una cita, no en un párrafo. Los módulos conector que hablan Model Context Protocol (MCP) envuelven Zendesk (ticket, solicitante, adjuntos), NetSuite (pedidos, historial de series, estado de garantía) y la herramienta de consulta del grafo. El flujo: el agente lee el ticket y su foto adjunta, consulta los embeddings en busca de páginas renderizadas candidatas, y después recorre el grafo para confirmar lo que la página candidata afirma — la revisión correcta, el rango de serie correcto, el estado de sustitución correcto — y responde con la página PDF real adjunta, el número de pieza en texto y la autoridad declarada («según el boletín 91-07, tabla en la página 40»). La regla de gobernanza es una línea y es estructural: sin cita de página, no se envía — el ticket escala a una persona. Una pregunta de compra entrega el control a un motor de RFQ que mantiene disponibilidad en vivo sobre la pieza de recambio, cerrando la resolución con una oferta con precio; las solicitudes de distribuidores delegan a través de un agente A2A con alcance, y cada paso de recuperación y de grafo queda registrado bajo el patrón del estándar de código de módulos. La guía de implementación cubre la construcción del grafo en sí; este es el patrón operativo, no una garantía para cualquier archivo.

Los dos técnicos senior permanecen en el bucle a otra altitud: aprueban todo lo relevante para la seguridad, revisan la cola señalizada de baja confianza y gestionan lo que el grafo no puede fundamentar. Dejan de ser el índice de la biblioteca.

El resultado

El mismo ticket, dos formas de resolverlo — la búsqueda manual de hoy frente al flujo agéntico-orquestado que responde con la página exacta adjunta:

Objetivos representativos para un despliegue de esta forma al volumen de esta empresa, con la evidencia de benchmark sobre la que se apoya el patrón:

Métrica	Antes	Objetivo agéntico-orquestado
Primera respuesta a preguntas de documentos	14 horas (mediana del correo de distribuidores)	Menos de 2 minutos, cita de página + render adjunto
Tiempo medio de gestión interna	22 minutos de búsqueda manual	3 minutos — el técnico verifica la página adjunta
Carga de escalada sobre técnicos senior	55% de las preguntas de documentos (~19 h/semana)	Menos del 20% de las preguntas de documentos
Envíos de pieza equivocada	9 en el trimestre (38.000 dólares/año)	1 en el trimestre piloto
Páginas con búsqueda	54.000 (el 30% con capa de texto)	~180.000, páginas renderizadas tal cual

La evidencia detrás del patrón: QA agéntica sobre PDF escaneados del mundo real con un 92.4% de precisión sin canal de OCR, recuperación estructurada en grafo con la mejora del 77.6% medida en precisión de recuperación en LinkedIn, y un perfil que el despliegue del grafo de conocimiento de soporte demostró desde el lado del software (28 horas de resolución a 7; escalada del 45% al 18%). Marcador honesto de alcance: MADQA es un benchmark, no una promesa para todos los archivos — por eso la regla de cita y la revisión humana permanecen en el bucle.

El cambio más profundo es que la biblioteca deja de decaer: qué documento sustituye a cuál, qué pieza sustituye a cuál y qué máquina recibió qué revisión queda registrado en el grafo en lugar de en dos cabezas que algún día se retirarán.

Lecturas relacionadas

• Soporte al Cliente con Resolución de 7 Horas: Cómo un Grafo de Conocimiento Reduce el Tiempo de Ticket en un 75% — el caso hermano desde el lado del software
• Guía de Implementación de GraphRAG: De Documentos de Texto a Recuperación de Grafos de Conocimiento en Producción — el canal de cinco etapas que construye el grafo a nivel de página
• GraphRAG para Soporte al Cliente: Cómo un Grafo de Conocimiento Responde Preguntas que su Base de Datos No Puede — cuándo la recuperación estructurada vale su coste

---

Un fabricante de bombas con 12.000 documentos, el 70% de ellos escaneados, pierde 22 minutos en cada búsqueda documental y envía de vez en cuando la pieza equivocada porque ningún sistema puede leer una curva de bomba. Un grafo de conocimiento a nivel de página, embeddings que buscan en páginas renderizadas sin OCR y un agente que responde con la página exacta adjunta — limitado por sin-cita-no-se-envía — hacen que la biblioteca vuelva a responder, y el motor de RFQ convierte «qué pieza encaja» en una oferta con precio y reserva.

Solicite una construcción delimitada

Una semana de descubrimiento. Usted obtiene un inventario de sistemas, un mapa de flujos de trabajo y un alcance fijo — independientemente de si construye con nosotros.