En la entrada anterior hemos intentado mostrar la arquitectura general de DOCUMENTALIA, finalizando con una pregunta aparentemente sencilla: ¿cómo convertir una colección de artículos científicos heterogéneos en un corpus estructurado para que una «máquina» pueda interpretarla de forma consistente? Podemos contestar que la pregunta ha terminado ocupando buena parte de las primeras semanas de desarrollo centradas casi en exclusiva en el parser. Vamos a intentar explicarlo.
Antes de pasar a generar embeddings, realizar búsquedas semánticas o conectar el proyecto con un LLM, debemos saber qué contiene cada artículo: cuál es su título, identificar los autores, tener claro dónde empieza y termina el resumen, cuáles son sus palabras clave, qué secciones forman el texto o qué referencias bibliográficas contiene (entre otras cosas). Un ser humano reconoce casi inmediatamente esa estructura al mirar una página, en cambio, un programa informático tiene que aprender a reconocerla.
Comenzamos: un artículo es algo más que su texto
Podemos sintetizar el esquema de un artículo científico como: Artículo → metadatos + contenido estructurado + referencias.
Hay que tener claro que la diferencia entre obtener texto y obtener información estructurada es fundamental. Si extraemos de un archivo PDF las palabras que contiene, hemos recuperado su texto, lo que es un primer paso, aunque todavía necesitamos determinar qué palabras corresponden al título, cuáles identifican a los autores, cuáles pertenecen al resumen o dónde comienza una determinada sección: extraer texto es recuperar las palabras de un artículo; extraer su estructura es identificar qué función desempeña cada parte de ese texto.
Esta estructura es importante para casi todo lo que se debe hacer posteriormente: va a permitir almacenar correctamente los artículos, fragmentarlos con mayor criterio, recuperar evidencias dentro de determinadas secciones y, algo muy interesante en este proyecto que sirve para el estudio de la literatura científica, relacionar cada resultado con su fuente original.
El parser: convertir documentos en datos
El programa encargado de realizar esta tarea se denomina parser, aplicación que transforma y preprocesa datos no estructurados. En DOCUMENTALIA utilizamos este término para referirnos al programa que analiza un documento, reconoce los elementos que nos interesan y los transforma en datos estructurados que puedan ser procesados posteriormente. Nosotros intentamos identificar, entre otros elementos: título, revista, año, volumen y número; autores y afiliaciones; DOI y otros identificadores; resúmenes y palabras clave; secciones y subsecciones; y referencias bibliográficas. El esquema básico parece sencillo: Documento → parser → datos estructurados
En la práctica, la salida del parser adopta una estructura organizada en campos. El documento deja de ser únicamente una sucesión de páginas y texto: el título se identifica como título, un autor como autor, cada resumen queda asociado a su idioma y las secciones conservan su posición y nivel dentro del artículo. Así, la información que en el artículos editado en PDF estaba destinada a la lectura por parte de una persona (de muchas a poder ser), pasa ahora a estar identificada, estructurada y preparada para su tratamiento automático.
El problema va a aparecer cuando observamos los documentos de entrada y percibimos los problemas que genera no tener un formato común (o mínimamente común).
XML-JATS y PDF: dos formas muy distintas de representar un artículo
Una parte de los artículos más recientes está disponible en XML-JATS, mientras que la mayor parte del corpus histórico está formada por PDF. Como ya señalamos en la entrada anterior, ambos formatos plantean cuestiones en la extracción diferentes.
JATS (Journal Article Tag Suite) es un estándar XML concebido específicamente para representar artículos científicos. En un documento XML-JATS encontramos estructuras semejantes a «<article-title>El título del artículo</article-title>» donde el propio documento está indicando que ese texto es el título. También existen etiquetas para autores, resúmenes, palabras clave, secciones o referencias bibliográficas. El parser debe interpretarlas, pero dispone de una ventaja fundamental: la estructura está expresada explícitamente en el documento. Con los documentos PDF la situación cambia porque las personas vemos una página y reconocemos el título fácilmente sabiendo que debajo aparecen los autores y que posteriormente comienza el resumen. En este formato, se conserva perfectamente esa apariencia visual sin gtener que decir explícitamente que cada uno de esos elementos cumple esas funciones. Por tanto, en los artículos en formato XML-JATS la estructura está declarada; en los documentos PDF la estructura debe ser reconstruida.
El problema no es solo el formato PDF: son los 30 años de PDFs
Si todos los artículos hubieran utilizado exactamente la misma plantilla, reconstruir esa estructura habría sido bastante más sencillo, pero no ha sido el caso. Anales de Documentación comenzó a publicarse a finales de los años noventa y durante ese tiempo han cambiado sus diseños, las tecnologías utilizadas para la edición y algunas convenciones editoriales, incluso la norma requerida para elaborar las referencias bibliográficas que cambió de ISO-690 a APA 7th. Además, nuestro proyecto incorpora una segunda revista (de vida más corta), Cuadernos de Gestión de Información, con su propia maquetación y con una forma de redactar la bibliografía no muy convencional. Por eso no existe realmente una única estructura sobre la que podamos escribir un conjunto fijo de reglas.
Se han hallado documentos escritos a una o dos columnas; autores y afiliaciones en diferentes posiciones; uno, dos o tres resúmenes; distintas formas de presentar palabras clave; varios sistemas de numeración de secciones; cambios en las referencias bibliográficas; DOI en los artículos recientes y otros identificadores en documentos anteriores. Incluso las reseñas han cambiado el formato de escritura con el paso de los años.
El problema más persistente ha sido que los documentos reales no siempre respetan perfectamente la plantilla editorial que deberían seguir, y no han sido fallos puntuales. Por ello. una diferencia apenas perceptible para una persona puede ser suficiente para que una regla automática interprete incorrectamente un elemento. Eso explica por qué la maquetación a nivel interno de nuestra base de datos, algo que inicialmente parecía secundario, se ha convertido en uno de los principales problemas técnicos del proyecto (el que más ha costado arreglar, de momento).
Durante el desarrollo apareció enseguida una necesidad muy práctica: necesitábamos saber qué estaba leyendo el parser. Antes de introducir automáticamente cientos de artículos en la base de datos teníamos que comprobar qué se estaba realmente interpretando. Por eso incorporamos una salida intermedia en formato JSON para revisarla debidamente, introducir cambios en el algoritmo, volver a validar y, si no ya se veían las deficiencias corregidas, cargar los artículos en la base de datos. El fichero JSON funciona como una especie de «radiografía» de la interpretación realizada por el programa. Con esa información, hemos sido capaces de verificar si el parser había encontrado correctamente el título, cuántos autores había reconocido, qué resúmenes se habían extraído, cómo se habían dividido las secciones o cuántas referencias bibliográficas se identificaban. Además, podíamos saber dónde residía el problema, pedirle a chatGPT que corrigiera el código del script y continuar revisando.
Debemos tener claro que un «OK» en esa revisión no significa necesariamente que todo esté bien. De hecho, esta ha sido una de las lecciones prácticas de DOCUMENTALIA. El parser podía ejecutar un documento sin producir ningún error de tipo informático y, sin embargo, interpretarlo incorrectamente, confundiendo lugar de trabajo con el nombre del autor o autora, incorporando una línea al título, no reconociendo determinadas palabras clave por no estar bien separadas en el texto, cortando una sección antes de tiempo o dividiendo (o uniendo) las referencias bibliográficas incorrectamente. Por eso hemos tenido que contrastar los resultados inciales con el artículo original sucesivamente y el desarrollo del parser ha terminado convirtiéndose en un proceso iterativo:
Aquí aparece además un problema conocido en desarrollo de software: corregir un caso puede estropear otro. Una regla introducida para interpretar correctamente un aspecto de una plantilla específica puede interferir con otra utilizada en artículos de una época diferente. Por ello no ha bastado con volver a procesar el documento que provocó la modificación: ha habido que verificar que la nueva regla no introducía errores en la extracción de información de artículos que antes funcionaba (como dato, vamos a comenzar la carga masiva esta misma semana y ya llevamos 26 versiones del parser).
Existía una solución sencilla, pero poco recomendable: añadir una regla específica para cada documento que falla. Esto no nos servía porque no queremos construir un parser lleno de excepciones. Si el artículo A da problemas y escribimos una excepción para A, luego, al fallar el B, añadimos otra y así sucesivamente, probablemente conseguiríamos que todo el corpus acabara procesándose correctamente, pero estaríamos construyendo un programa para unos documentos concretos, no un parser suficientemente generalizable. Nuestro objetivo es diferente: identificar regularidades documentales y convertirlas en reglas generales evitando, si es posible, recurrir a excepciones particulares.
Lo cierto es que un corpus real contiene anomalías y es posible que algunas tengan que tratarse específicamente. Pero es importante distinguir entre una nueva regularidad no reconocida previamente y una peculiaridad exclusiva de un documento. Esta diferencia determina hasta qué punto el trabajo realizado en DOCUMENTALIA puede reutilizarse posteriormente con otras colecciones.
¿Cuántos artículos tenemos que comprobar?
He aquí otra cuestión práctica. Si nuestro objetivo es automatizar la extracción de varios centenares de artículos, revisar manualmente todos ellos eliminaría buena parte de la ventaja de utilizar un parser, pero testear un reducido grupo de documentos tampoco proporcionaría suficiente certeza de estar haciéndolo bien. La estrategia seguida ha sido construir un muestreo deliberadamente heterogéneo buscando cantidad y variabilidad. Se han seleccionado documentos de diferentes años de ambas revistas, diversas maquetaciones, varios idiomas y tipos documentales diferentes. También han resultado especialmente útiles los artículos próximos a momentos en los que sabemos que cambió el diseño editorial. Cada nueva muestra sirve para responder a la misma pregunta: ¿siguen funcionando las reglas del parser al aplicarlas a documentos diferentes de aquellos con los que fueron diseñadas?
Este cambio de perspectiva es importante porque va más alla de demostrar que el parser funciona con los artículos que ya hemos utilizado para corregirlo. Queremos aumentar nuestra confianza en que funcionará con los documentos que todavía no hemos revisado.
De la prueba artesanal a la prueba masiva
Las primeras fases de afinado se realizaron revisando pequeños grupos de artículos de diferentes años. Viendo que la presencia de singularidades era muy frecuente, se decidió revisar alrededor de cuatro artículos por número editado de las dos revistas. Además de los artículos científicos (el grueso del corpus), se testeó el parser con traducciones y reseñas. En el caso de los ficheros editados en XML-JATS, se han utilizado todos porque sólo llevamos dos números editando con ese formato. Ese procedimiento ha sido indispensable y ha permitido observar con detalle los tipos de errores y entender por qué se producen.
En una fase posterior, previa a la ingesta masiva de documentos a la base de datos, se necesita cambiar de escala. Esto ocurre cuando las reglas básicas parecen razonablemente estables. Hemos ejecutado el parser sobre muestras mucho mayores y se han analizado sistemáticamente los resultados. Este es precisamente el punto en el que nos encontramos mientras escribimos esta entrada: hemos pasado de probar cuidadosamente artículos individuales y pequeños conjuntos a comprobar el comportamiento del parser sobre muestras aleatorias mucho mayores del corpus, algunas de ellas de hasa 200 artículos. El objetivo es localizar errores menos evidentes, regresiones y casos que todavía no habíamos encontrado.
Primero los datos, después la IA
Todo esto ocurre antes de producir un solo embedding. Estamos convencidos de que este trabajo condicionará directamente la calidad de lo que hagamos después (y más en este caso que estamos aprendiendo cómo construir un buscador de esta naturaleza). Una estructura documental fiable permitirá crear mejores fragmentos, conocer de qué sección procede cada evidencia, filtrar por metadatos, relacionar los resultados con sus autores y proporcionar al usuario el DOI o el enlace del artículo original.
La metáfora general puede resumirse así: la calidad de la búsqueda futura depende en buena medida de la calidad de los datos que consigamos extraer ahora.
Un modelo LLM puede interpretar muy bien un fragmento de texto, pero no puede corregir automáticamente todos los problemas provocados por una extracción defectuosa o por la pérdida de contexto documental. Como DOCUMENTALIA aspira a generar respuestas trazables hasta los artículos originales, conservar correctamente la estructura y la identidad de los documentos es apropiado e importante. En la arquitectura ya publicada, el control de calidad y los identificadores persistentes aparecen precisamente como elementos transversales del sistema.
Lo que casi treinta años de artículos están enseñando al parser
El trabajo de extracción ha producido un resultado que no estaba entre los objetivos iniciales del proyecto. Al revisar documentos de diferentes épocas, se ha reconstruido de facto una pequeña historia de las regularidades, cambios y anomalías de maquetación de las revistas. Algunas diferencias eran previsibles: nuevas plantillas, cambios en las normas bibliográficas o la aparición del DOI (hace casi 30 años no existía). Otras lo eran bastante menos: se han encontrado casos en los que una tabla altera la interpretación del documento, reseñas cuya estructura se alejaba completamente de la de un artículo convencional, referencias que requerían reglas diferentes según la época o elementos aparentemente triviales que hacen fallar una extracción que funcionaba perfectamente en decenas de documentos anteriores (muchas veces porque el editor del documento impreso introdujo en un número un texto adicional o un elemento visual que luego no volvió a aparecer). También ha resultado curioso encontrar artículos publicados sin un apartado de bibliografía porque las referencias iban como nota a pie de página.
Esta serie de casuísticas son precisamente los que más han ayudado a mejorar el parser, y también los que mejor permiten explicar cómo se construye realmente un sistema de este tipo. En la próxima entrada profundizaremos en el «laboratorio del parser PDF«: veremos algunos de esos errores reales, cómo los hemos detectado y qué modificaciones nos han obligado a introducir en el código fuente del script.
