From Law to Gherkin: A Human-Centred Quasi-Experiment on the Quality of LLM-Generated Behavioural Specifications from Food-Safety Regulations

Este estudio presenta la primera evaluación sistemática con sujetos humanos que demuestra que, aunque los modelos de lenguaje grandes pueden generar especificaciones Gherkin de alta calidad a partir de normativas de seguridad alimentaria, la presencia de omisiones y alucinaciones hace indispensable una revisión humana sistemática en dominios críticos.

Lo esencial

Imagina que las leyes y regulaciones son como recetas de cocina muy antiguas y escritas en un idioma muy complicado. Son precisas, pero están llenas de tecnicismos legales que un chef (o un programador de software) tiene dificultades para entender y seguir al pie de la letra. Si el chef se equivoca al cocinar, la comida puede ser peligrosa para los comensales.

En este mundo digital, los "cocineros" son los desarrolladores de software que crean sistemas para asegurar que la comida sea segura (por ejemplo, sistemas que controlan la temperatura de los huevos o la higiene en las fábricas). El problema es que traducir esas "recetas legales" a instrucciones claras para el software es lento, aburrido y propenso a errores.

Aquí es donde entran los Modelos de Lenguaje Grande (LLMs), como Claude y Llama. Piensa en ellos como asistentes de cocina superinteligentes que han leído millones de libros. La pregunta de los investigadores era: ¿Podemos pedirle a este asistente que traduzca la receta legal complicada en una lista de instrucciones paso a paso, clara y lista para usar?

La Receta Especial: Gherkin

Para que las instrucciones sean útiles, los investigadores usaron un lenguaje llamado Gherkin. Imagina que Gherkin es como una tarjeta de receta simplificada que cualquiera puede entender, con una estructura fija:

• Dado (Given): El contexto (ej. "Tenemos un huevo líquido").
• Cuando (When): La acción (ej. "El inspector mide el peso").
• Entonces (Then): El resultado esperado (ej. "El sistema debe verificar que tenga al menos 23.5% de sólidos").

El Experimento: Una Competencia de Cocina

Los investigadores organizaron una especie de "concurso de cocina" (un experimento quasi-controlado):

1. Los Ingredientes: Tomaron 30 reglas reales sobre seguridad alimentaria (como las que regulan los huevos en Canadá).
2. Los Chefs: Usaron dos asistentes de IA diferentes (Claude y Llama) para convertir esas reglas en las tarjetas de receta Gherkin.
3. Los Críticos: Contrataron a 10 personas (estudiantes expertos en software) para que probaran estas recetas generadas por la IA. No eran chefs legales, sino expertos en cómo se escribe el software.
4. El Juicio: Los críticos evaluaron las recetas en 5 categorías:
   • ¿Es relevante? (¿Dice lo que dice la ley?).
   • ¿Es clara? (¿Se entiende sin dudas?).
   • ¿Está completa? (¿Falta algún ingrediente?).
   • ¿Es singular? (¿Cada receta hace una sola cosa, o mezcla todo en un caos?).
   • ¿Ahorró tiempo? (¿Fue más rápido usar la IA que escribirlo a mano?).

Los Resultados: ¡Casi Perfecto, pero con Trampas!

Lo bueno (El sabor principal):
¡Fue un éxito rotundo! Las recetas generadas por la IA fueron excelentes.

• Los críticos dijeron que eran claras y relevantes casi el 100% de las veces.
• Ahorraron mucho tiempo (como si el asistente hubiera pre-cortado todas las verduras).
• No hubo diferencia significativa entre los dos asistentes (Claude y Llama cocinaron casi igual de bien).

Lo malo (Las trampas en la cocina):
Aunque las recetas parecían perfectas a primera vista, al revisarlas con lupa, los críticos encontraron algunos problemas peligrosos:

1. Ingredientes que no existen (Alucinaciones): A veces, la IA inventaba pasos que la ley nunca pidió. Ejemplo: La ley dice "medir el peso", pero la IA escribió "el sistema debe mostrar una advertencia roja". ¡La ley nunca pidió una luz roja!
2. Ingredientes olvidados (Omisiones): A veces, la IA se saltaba una parte importante de la ley. Ejemplo: La ley dice "importado por X", pero la receta generada olvidó mencionar quién es X.
3. Recetas mezcladas: A veces, la IA ponía dos o tres reglas diferentes en una sola tarjeta, haciendo que fuera confusa saber qué estaba pasando.

La Conclusión: El Asistente es Genial, pero el Chef debe Vigilar

El mensaje principal de este estudio es muy simple: La IA es un excelente ayudante para hacer el primer borrador de las reglas, pero no puedes dejarla sola en la cocina.

Si confías ciegamente en la IA para temas de seguridad alimentaria (donde un error puede enfermar a la gente), podrías tener un desastre. La IA puede ser rápida y creativa, pero a veces "alucina" o se olvida de detalles vitales.

La analogía final:
Usar la IA para crear especificaciones de software es como tener un asistente de cocina que corta las verduras increíblemente rápido. Pero, si no revisas lo que cortó, podría haber dejado un trozo de piel de patata (omisión) o haber añadido sal en lugar de azúcar (alucinación). Por eso, siempre necesitas a un chef humano experto que revise el trabajo antes de servirlo a los comensales.

En resumen: La IA acelera el proceso, pero la supervisión humana es obligatoria para garantizar la seguridad.

Resumen técnico

Resumen Técnico: De la Ley a Gherkin

1. Planteamiento del Problema

En dominios regulados como la seguridad alimentaria, las leyes y normativas influyen directamente en el diseño, desarrollo y aseguramiento de la calidad del software. Sin embargo, existe un desafío fundamental:

• Ambigüedad y Neutralidad Tecnológica: Las disposiciones legales se redactan en un lenguaje agnóstico a la tecnología para mantener su vigencia a largo plazo, lo que dificulta su traducción a especificaciones concretas, requisitos verificables y criterios de aceptación.
• Costo del Proceso Manual: La conversión manual de textos legales a artefactos de ingeniería de software es laboriosa, propensa a errores e inconsistente, aumentando el riesgo de incumplimiento normativo.
• Brecha de Automatización: Aunque la investigación previa ha abordado la extracción y clasificación de requisitos legales, hay poca atención en la transformación sistemática de textos legales en especificaciones de comportamiento estructuradas y legibles por máquinas (como las de Desarrollo Dirigido por Comportamiento - BDD).

El objetivo de este estudio es evaluar si los Modelos de Lenguaje Grandes (LLM) pueden automatizar esta traducción, generando especificaciones en Gherkin (el lenguaje de dominio específico para BDD) a partir de regulaciones de seguridad alimentaria.

2. Metodología

El estudio emplea un diseño cuasi-experimental con sujetos humanos, ya que un experimento controlado completo resultó inviable debido a la variabilidad en los horarios de los participantes y la necesidad de mantener la validez externa con un grupo diverso.

• Participantes: Se reclutaron 10 participantes (estudiantes de ingeniería de software, desde últimos años de grado hasta doctorado) con conocimientos en BDD, sintaxis Gherkin y redacción de casos de prueba.
• Modelos Evaluados: Se compararon dos LLMs de última generación: Claude 3.7 Sonnet y Llama 3.3 70B Instruct.
• Datos de Entrada: Se utilizaron 30 disposiciones legales extraídas de las Regulaciones de Alimentos Seguros para Canadá (SFCR) y documentos relacionados.
• Proceso de Generación:
  • Se utilizó un prompt estandarizado que incluía un glosario de conceptos relevantes para el software (extraído de trabajo previo de los autores), la disposición legal y una instrucción para generar especificaciones en formato Given-When-Then.
  • Se generaron 60 especificaciones Gherkin en total (30 por modelo).
• Evaluación Humana:
  • Cada especificación fue evaluada por dos participantes independientes (totalizando 120 evaluaciones).
  • Se utilizaron cinco criterios de calidad en una escala ordinal de 5 puntos:
    1. Relevancia: Grado de coincidencia con el comportamiento descrito en la ley.
    2. Claridad: Ausencia de ambigüedad.
    3. Completitud: Inclusión de todas las funciones y características implícitas sin omisiones.
    4. Singularidad: Cada escenario debe tener un único propósito (evitar escenarios de "propósito mixto").
    5. Ahorro de Tiempo: Percepción de eficiencia en la reutilización del artefacto generado.
  • Además, se realizó una verificación de plausibilidad (binaria: sí/no) para detectar comportamientos físicamente imposibles o ilógicos.

3. Contribuciones Clave

1. Primera Evaluación Sistemática con Sujetos Humanos: Es el primer estudio que evalúa cuantitativa y cualitativamente la capacidad de LLMs para derivar especificaciones de comportamiento (Gherkin) directamente desde textos legales.
2. Marco de Evaluación Adaptado: Define y aplica criterios de calidad específicos para el contexto legal-BDD (Relevancia, Completitud, Claridad, Singularidad y Ahorro de Tiempo).
3. Análisis de Fallos Críticos: Identifica patrones de error específicos en dominios de seguridad crítica, como alucinaciones, omisiones de cláusulas y la mezcla de intenciones en escenarios.
4. Repositorio de Datos Abierto: El estudio incluye un paquete de replicación completo con el conjunto de datos, resultados estadísticos y scripts de evaluación.

4. Resultados Principales

Cuantitativos:

• Ratings Altos: Las especificaciones generadas obtuvieron puntuaciones uniformemente altas en las dos categorías superiores de la escala:
  • Claridad: 100% (Mayoría "Totalmente clara").
  • Relevancia: 95% (Mayoría "Totalmente/Muy relevante").
  • Completitud: 94.2%.
  • Singularidad: 93.4%.
  • Ahorro de Tiempo: 91.7%.
• Comparación de Modelos: No se observaron diferencias estadísticamente significativas entre Claude y Llama en ninguno de los cinco criterios (pruebas de Mann-Whitney U y Wilcoxon).
  • Tendencia observada: Llama mostró ligeramente mejor consistencia en claridad y completitud, mientras que Claude mantuvo una adherencia más estricta a la singularidad de los escenarios.
• Plausibilidad: Solo se identificaron 3 especificaciones únicas como "no plausibles" por los participantes (ej. suposiciones físicas irrealistas sobre la temperatura de líquidos).

Cualitativos (Feedback de los Participantes):
A pesar de las altas puntuaciones, el análisis de los comentarios reveló problemas críticos:

• Alucinaciones: Los modelos a veces añadían requisitos que no existían en el texto legal (ej. suponer que el sistema debe mostrar una advertencia visual cuando la ley no lo exige).
• Omisión de Cláusulas: En disposiciones complejas o largas, los modelos omitían detalles específicos o sub-cláusulas enteras (ej. condiciones de importación o términos bilingües obligatorios).
• Propósito Mixto: En lugar de dividir requisitos complejos en múltiples escenarios atómicos, los LLMs tendían a combinar múltiples objetivos en un solo escenario, violando el principio de singularidad de BDD.

5. Significado y Conclusiones

• Viabilidad como "Borrador": Los resultados sugieren que los LLMs actuales pueden actuar eficazmente como co-autores de borradores para especificaciones legales, reduciendo significativamente el esfuerzo de redacción inicial.
• Necesidad de Supervisión Humana: Debido a los riesgos de omisión y alucinación en dominios de seguridad crítica (como la seguridad alimentaria), no se puede confiar en la automatización total. Se requiere un flujo de trabajo de "humano en el bucle" (Human-in-the-Loop) donde expertos revisen y corrijan los borradores generados.
• Implicaciones para la Práctica:
  • Las organizaciones deben adoptar un enfoque de revisión y trazabilidad en lugar de generación automática pura.
  • Se recomienda el uso de glosarios de dominio y prompts controlados para mejorar la fidelidad.
  • Las especificaciones generadas deben tratarse como artefactos provisionales sujetos a validación rigurosa antes de su implementación.

Conclusión Final:
El estudio demuestra que la traducción de leyes a especificaciones de software mediante LLMs es técnicamente factible y de alta calidad general, pero los errores sutiles (omisiones y alucinaciones) hacen que la supervisión humana sea indispensable, especialmente cuando el incumplimiento puede tener consecuencias graves para la seguridad pública.