Imagina intentar armar un armario complejo de IKEA, pero en lugar de un manual, tienes cincuenta versiones diferentes escritas por cincuenta personas distintas que tienen ideas completamente distintas sobre lo que es un “paso”. Algunas usan viñetas, otras usan prosa narrativa, y algunas simplemente ponen una foto de un tornillo y esperan que lo averigües. Esto es esencialmente la pesadilla de lidiar con las Hojas de Datos de Seguridad (SDS). Son los requisitos legales del mundo químico, diseñados para decirte si una sustancia derretirá tu piso o hará explotar tu laboratorio, pero están formateadas con una energía caótica que haría ruborizar a un poeta posmoderno.
El reciente artículo sobre Benchmarking Large Language Models for Safety Data Extraction aborda exactamente este desastre. El objetivo es ver si los LLMs pueden realmente extraer información estructurada de estos documentos mejor que los sistemas tradicionales basados en reglas. Para quienes han pasado tiempo en las trincheras de los datos industriales, “basado en reglas” es una forma educada de decir “un archivo de regex de diez mil líneas que se rompe cada vez que un proveedor cambia su fuente a Arial.” El estudio básicamente confirma lo que sospechábamos: los LLMs son significativamente mejores para manejar la heterogeneidad de estos documentos porque no entran en pánico cuando una tabla está ligeramente desplazada o el encabezado de una sección está mal escrito.
Pero aquí está el problema que a la comunidad de benchmarking le encanta ignorar: el “impuesto del PDF”. Puedes tener el modelo más capaz del planeta, pero si tu pipeline de ingestión convierte un PDF de varias columnas en una cadena lineal de galimatías, el modelo solo está alucinando basándose en basura (principalmente porque los PDFs son un crimen contra la humanidad). ¿Por qué seguimos fingiendo que la capacidad de razonamiento del modelo es el cuello de botella cuando la verdadera lucha es simplemente meter el texto en el prompt sin perder la relación entre una propiedad química y su valor? Si el OCR tropieza con un salto de línea, la “extracción estructurada” se convierte en un juego de adivinanzas.
El paso de reglas frágiles a LLMs probabilísticos es un mal necesario, pero introduce un nuevo tipo de fricción. En un contexto de seguridad, una tasa de precisión del 95% es un fracaso. Si un modelo pasa por alto una advertencia de “altamente inflamable” porque estaba enterrada en un pie de página con un formato extraño, el resultado no es un informe de error: es un incendio. Aquí es donde golpea el costo de propiedad. Para lograr ese último 5% de precisión, no solo estás pagando por tokens; estás pagando por un sistema de verificación con humano en el lazo que probablemente cueste más que la propia implementación del LLM. Además, la latencia de ejecutar una ventana de contexto masiva solo para encontrar un valor de punto de inflamación es una píldora difícil de tragar para aplicaciones industriales en tiempo real.
Sospecho que actualmente estamos en la fase de “fuerza bruta” de este problema. Estamos lanzando modelos de propósito general contra documentos industriales de nicho y actuando sorprendidos cuando luchan con la jerga específica de la seguridad química. Es como usar un cuchillo suizo para realizar una cirugía: técnicamente tiene las herramientas, pero no es el instrumento adecuado. Para el primer trimestre del próximo año, veremos la aparición de un “Safety-LLM” especializado y de código abierto, o un adaptador altamente ajustado que supere a GPT-4 en la extracción de SDS al menos un 15%, porque ha sido entrenado en el diseño visual real de estos documentos, no solo en el texto limpiado.
Las herramientas son mejores, pero los documentos siguen siendo un desastre.
Hasta entonces, solo estamos evaluando qué tan bien un modelo puede adivinar el contenido de una búsqueda del tesoro digital. Podemos celebrar los números del benchmark, pero la verdadera victoria ocurre cuando dejamos de tratar al PDF como un archivo de texto y empezamos a tratarlo como un mapa visual.
