Doce. Ese es aproximadamente el número de minutos que aguanta un desarrollador al intentar depurar manualmente una forma SHACL compleja antes de empezar a cuestionar cada decisión profesional que lo llevó al RDF. Si has pasado algo de tiempo en el mundo de los grafos de conocimiento, sabes que SHACL (Shapes Constraint Language) es una herramienta potente para validar datos, pero su sintaxis es un auténtico suplicio. Es ese tipo de sobrecarga técnica que mantiene a los expertos de dominio —la gente que realmente entiende los datos— lejos de la implementación real. Tienen los requisitos en la cabeza, pero no hablan el lenguaje de las formas, y los desarrolladores que sí lo hablan a menudo carecen del contexto de dominio para saber cómo deberían ser realmente esas formas.
Esta fricción es exactamente lo que los investigadores detrás de NL2SHACL-Bench intentan resolver. El artículo presenta una suite de benchmarks diseñada para probar qué tan bien pueden los LLM traducir requisitos de lenguaje natural a formas SHACL válidas. La premisa es simple: si podemos cerrar la brecha entre un humano diciendo “toda persona debe tener al menos una dirección de correo electrónico” y el código SHACL correspondiente, democratizamos la validación de grafos de conocimiento. Convierte una tarea de ingeniería especializada en una tarea de prompting. En papel, parece un triunfo para la gente de low-code que quiere el poder de las restricciones formales sin tener que leer la especificación.
El problema es que la traducción es una falsa pista (o al menos una muy distractora). El verdadero cuello de botella en la validación de datos no es la sintaxis de la forma SHACL; es la ambigüedad de los propios requisitos en lenguaje natural. Ya hemos visto esta película antes. Cada vez que llega una nueva herramienta de “lenguaje natural a X”, finge que la intención del usuario es cristalina. En la realidad, los expertos de dominio son notoriamente malos especificando restricciones en inglés. Describen el caso del 80% e ignoran los casos límite que realmente hacen útil una suite de validación. ¿De verdad creemos que un prompt puede reemplazar el proceso riguroso, y a menudo doloroso, de un arquitecto de datos mapeando un esquema?
Es un poco como pedirle a un chef que “le dé sabor a infancia”. Puedes usar las herramientas de cocina más sofisticadas del mundo, pero si la entrada es un recuerdo emocional vago en lugar de una receta precisa, la salida es una apuesta. Traducir una frase vaga en inglés a una restricción lógica rígida no es una tarea de traducción; es una tarea de interpretación. Cuando el LLM rellena los huecos de un requisito mal redactado para que el código compile, no está siendo útil; está alucinando una regla de negocio que puede ser verdadera o no. Estamos automatizando efectivamente la creación de errores con pinta de plausibilidad.
También está el tema de la fricción del mundo real. Incluso si el benchmark muestra alta precisión, desplegar estas traducciones en una pipeline de producción implica los habituales dolores de cabeza del RDF. Sigues lidiando con la latencia de las consultas de grafos y el coste brutal de VRAM de ejecutar un modelo lo suficientemente grande para manejar anidamientos lógicos complejos sin tropezar con sus propios pies. Un benchmark es un entorno estéril. No tiene en cuenta los requisitos desordenados y contradictorios de una base de datos corporativa que ha sido remendada por cinco equipos diferentes a lo largo de una década, donde “dirección de correo electrónico” puede significar tres cosas distintas dependiendo del sistema legacy que estés consultando.
Dicho esto, el benchmark es un mal necesario porque nos da una forma de medir el fracaso. Sin un conjunto estandarizado de pruebas, solo estamos adivinando basándonos en unos pocos ejemplos seleccionados en un README. Sospecho que veremos un modelo especializado y fine-tuned para traducción SHACL alcanzar una tasa de éxito del 90% en este benchmark específico para el Q3 del próximo año. Sin embargo, ese número será una métrica de vanidad. Demostrará que el modelo puede imitar los patrones del benchmark y satisfacer al evaluador, no que pueda resolver el problema fundamental de la ambigüedad humana en la especificación de datos.
Es una venda elegante para una pierna rota.
