🤖 AI

OLAF: Towards Robust LLM-Based Annotation Framework in Empirical Software Engineering

Este artículo de posición propone OLAF, un marco conceptual que trata la anotación basada en LLM en la ingeniería de software empírica como un proceso de medición riguroso mediante la definición de constructos clave como la fiabilidad, la calibración y la deriva para mejorar la transparencia y la reproducibilidad.

Autores originales: Mia Mohammad Imran, Tarannum Shaila Zaman

Publicado 2026-01-27

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Mia Mohammad Imran, Tarannum Shaila Zaman

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás intentando organizar una enorme biblioteca de notas manuscritas desordenadas. En el pasado, habrías contratado a un equipo de bibliotecarios humanos para leer cada nota, decidir a qué categoría pertenece (como "Reporte de Error", "Solicitud de Funcionalidad" o "Spam") y escribir una etiqueta en ella. Esto es lento, costoso y, a veces, dos bibliotecarios podrían no estar de acuerdo con la misma nota.

Ahora, imagina que contratas a un robot súper inteligente (una IA o un Modelo de Lenguaje Grande) para hacer el etiquetado por ti. Es rápido y barato. Pero aquí está el problema: ¿Está el robot haciendo realmente un buen trabajo, o solo está adivinando?

Este artículo, titulado OLAF, argumenta que debemos dejar de tratar a estos robots como cajas negras mágicas que simplemente "hacen el trabajo". En su lugar, debemos tratarlos como herramientas de medición científicas, tal como un termómetro o una báscula. Si usas una báscula para pesar los ingredientes de un pastel, necesitas saber si la báscula es precisa, si se descalibra con el tiempo y si da el mismo resultado cada vez que la usas.

Aquí está el desglose de las ideas del artículo utilizando analogías sencillas:

1. El Problema: La trampa de la "Caja Mágica"

Actualmente, muchos investigadores usan IA para etiquetar datos pero no nos dicen cómo lo hicieron.

La Analogía: Imagina que un panadero dice: "Usé un horno especial para hornear este pan". Pero no te dice la temperatura, el tiempo, ni la marca del horno. Si intentas hornear el mismo pan, podría salir quemado o crudo.
La Realidad: Los investigadores suelen olvidar mencionar detalles pequeños como las palabras exactas que escribieron a la IA (el "prompt"), la versión específica de la IA o la configuración que utilizaron. Debido a esto, nadie más puede repetir su experimento para ver si obtiene los mismos resultados.

2. La Solución: OLAF (El marco de "Control de Calidad")

Los autores proponen un nuevo marco llamado OLAF. Piensa en OLAF como un lista de verificación para el control de calidad que debes usar antes de confiar en las etiquetas del robot. Trata a la IA no como un trabajador, sino como un instrumento de medición que necesita ser calibrado.

OLAF te pide que verifiques seis cosas específicas (Constructos):

Fiabilidad (La verificación de "Consistencia"): Si le pides al robot que etiquete la misma nota cinco veces, ¿da la misma respuesta? ¿O cambia de opinión?
Consenso (La verificación del "Abrazo Grupal"): Si usas tres robots diferentes, ¿están todos de acuerdo con la etiqueta? Si todos dicen "Error", es una señal fuerte. Si no están de acuerdo, la tarea podría ser demasiado confusa.
Agregación (El sistema de "Votación"): ¿Cómo combinas las respuestas? ¿Simplemente tomas el voto de la mayoría? ¿O utilizas una fórmula matemática sofisticada para determinar qué robot es más confiable?
Transparencia (La verificación del "Recibo"): ¿Lo anotaste todo? ¿El nombre del robot, el número de versión, las palabras exactas que escribiste? Sin este "recibo", el trabajo es inútico para otros.
Calibración (La verificación de la "Confianza"): Si el robot dice: "Estoy 99% seguro de que esto es un error", ¿es realmente acertado el 99% de las veces? ¿O es solo excesivamente confiado? Esto verifica si la confianza del robot coincide con la realidad.
Deriva (La verificación de los "Postes de Meta que se Mueven"): Los modelos de IA cambian con el tiempo. Un robot que funciona perfectamente hoy podría actuar de forma diferente el próximo mes porque la empresa actualizó su software. OLAF verifica si el comportamiento del robot ha "derivado" o cambiado inesperadamente.

3. Cómo usar al Robot (Las Seis Configuraciones)

El artículo también explica que no siempre tienes que dejar que el robot lo haga todo. Sugiere seis formas de mezclar humanos y robots, como diferentes recetas:

Humano en el Bucle (Human-in-the-Loop): El robot hace una primera pasada, pero un humano revisa doblemente aquellos casos en los que el robot no está seguro. (Como un estudiante haciendo la tarea y un profesor calificando las partes difíciles).
Modelo en el Bucle (Model-in-the-Loop): El robot sugiere una respuesta y otro robot o un humano la verifica.
Verificador en el Bucle (Verifier-in-the-Loop): Un segundo robot actúa como "árbitro" para verificar si la respuesta del primer robot es buena antes de que un humano la vea.
Filtro (Filter): El robot descarta rápidamente la basura obvia (como correos electrónicos de spam) para que los humanos solo tengan que mirar lo importante.
Juez (Judge): El robot actúa como un árbitro, calificando el trabajo de otras IA basándose en un conjunto de reglas.
Anotador (Annotator): El robot hace todo el trabajo solo. (Esto es rápido, pero arriesgado si el robot comete un error).

4. El Problema (Limitaciones)

Los autores admiten que esta no es una solución perfecta todavía.

La Analogía: No puedes confiar plenamente en un termómetro si no sabes cómo fue construido o si la fábrica cambia el diseño cada semana.
La Realidad: Muchos modelos de IA populares (como los de las grandes empresas tecnológicas) son "cajas negras". No conocemos sus datos de entrenamiento y podrían cambiar sin avisar. OLAF intenta medir qué tan estables son, pero no puede garantizar que no cambiarán mañana.

Resumen

El artículo dice: "Deja de tratar el etiquetado por IA como magia. Empieza a tratarlo como ciencia".

Si quieres usar la IA para etiquetar datos en la ingeniería de software, necesitas un marco (OLAF) que te obligue a verificar si la IA es consistente, si es honesta sobre su confianza y si has registrado exactamente cómo la utilizaste. Sin esto, tus resultados de investigación podrían ser poco fiables, como un pastel hecho con un horno no medido.

Resumen Técnico: OLAF – Hacia un marco de trabajo robusto para la anotación basada en LLM en la Ingeniería de Software Empírica

Declaración del Problema
La Ingeniería de Software Empírica (ESE) depende cada vez más de los Modelos de Lenguaje de Gran Escala (LLM) para automatizar o asistir en tareas de anotación, tales como el etiquetado de informes de errores, la clasificación de intenciones de commits o la identificación de deuda técnica autoadmitida. Sin embargo, el rigor metodológico de estas prácticas sigue estando subdesarrollado. Los estudios actuales suelen tratar la anotación basada en LLM como una actividad puramente automatizada en lugar de un proceso de medición, lo que genera varias brechas críticas:

Falta de Estandarización: No existen medidas estandarizadas para la fiabilidad, la calibración o la deriva (drift) en los estudios de anotación con LLM.
Reporte Fragmentado: Con frecuencia se omiten detalles de configuración esenciales (por ejemplo, plantillas de prompts, parámetros de decodificación, versiones del modelo), lo que dificulta la reproducibilidad.
Sensibilidad de la Configuración: Cambios menores en los prompts, en los ajustes de temperatura o en las actualizaciones del modelo pueden alterar drásticamente los resultados (un fenómeno denominado "prompt drift" o "LLM hacking"), aunque estas sensibilidades rara vez se cuantifican.
Constructos No Definidos: Conceptos abstractos como la "precisión de la etiqueta" carecen de definiciones operacionales formales que los vinculen con procedimientos medibles, lo que amenaza la validez de constructo, interna y externa.

Metodología y Marco de Trabajo (OLAF)
El artículo propone el Marco de Trabajo de Operacionalización para la Anotación Basada en LLM (OLAF). En lugar de ofrecer un nuevo algoritmo o un resultado experimental específico, OLAF es un marco conceptual diseñado para tratar la anotación con LLM como un proceso medible y auditable. Operacionaliza la anotación a través de seis constructos clave y los mapea con métricas específicas y enfoques de reporte (resumidos en la Tabla 1 del artículo):

Fiabilidad del Anotador (Annotator Reliability): Mide el acuerdo entre los anotadores individuales (humanos o modelos) utilizando estadísticas corregidas por el azar (por ejemplo, $\kappa$ de Cohen, AC1 de Gwet, $\alpha$ de Krippendorff).
Consenso (Consensus): Refleja el acuerdo a nivel de grupo para determinar si los anotadores convergen en un juicio compartido o si la tarea contiene una ambigüedad inherente.
Agregación (Aggregation): Define métodos para combinar múltiples anotadores en una sola etiqueta, distinguiendo específicamente entre agregación probabilística (por ejemplo, Dawid–Skene, GLAD, MACE) y votación por mayoría.
Transparencia (Transparency): Exige la documentación completa de identificadores de modelos, parámetros, prompts y configuraciones (siguiendo prácticas como Datasheets y Model Cards) para asegurar la reproducibilidad.
Calibración (Calibration): Evalúa la corrección de las probabilidades predichas comparando las puntuaciones de confianza con la precisión empírica utilizando métricas como el Error de Calibración Esperada (ECE) y la puntuación de Brier.
Deriva (Drift): Captura la estabilidad del comportamiento midiendo cuánto cambia el comportamiento del modelo bajo variaciones de prompt o contexto, cuantificado mediante distancias de activación (L2, coseno), métricas de distribución de salida (divergencia de Jensen-Shannon) o índices de sensibilidad de prompt (POSIX).

El marco también categoriza seis flujos de trabajo de anotación comunes (Tabla 2) para contextualizar dónde se aplican estas métricas:

Humano en el bucle (Human-in-the-Loop - HitL)
Modelo en el bucle (Model-in-the-Loop - MitL)
Verificador en el bucle (Verifier-in-the-Loop - VitL)
LLM como filtro de pre-selección (LLM-as-a-Pre-screen-Filter)
LLM como Juez (LLM-as-a-Judge - LLMaaJ)
LLM como Anotador (LLM-as-an-Annotator)

Contribuciones Clave

Cambio Conceptual: El artículo argumenta a favor de reconceptualizar la anotación con LLM de una tarea de automatización a un proceso de medición, que requiere el mismo rigor de validación que las métricas de código tradicionales.
Definiciones Operacionales: Proporciona el primer conjunto estructurado de definiciones operacionales para la fiabilidad, el consenso, la deriva y la calibración, adaptadas específicamente a la anotación con LLM en la Ingeniería de Software (SE).
Guías para la Práctica: Los autores proporcionan directrices concretas para investigadores, incluyendo:
- Declarar explícitamente la configuración de la anotación (por ejemplo, HitL frente a LLM-como-Anotador).
- Documentar todos los detalles del modelo y del prompt.
- Seleccionar métodos de agregación apropiados basados en el acuerdo observado.
- Implementar el seguimiento de la deriva utilizando subconjuntos de calibración fijos (por ejemplo, re-anotar entre 50 y 100 elementos etiquetados por expertos cuando cambian los parámetros).
Provisión de Recursos: Los autores han establecido un sitio web complementario (se-llm-annotation-olaf.github.io) con guías detalladas y ejemplos.

Resultos y Reivindicaciones
Como artículo de posición, OLAF no presenta nuevos datos experimentales ni resultados empíricos que validen la eficacia del marco. En su lugar, sus "resultados" son la síntesis de la literatura existente (citando trabajos de Ahmed et al., Baumann et al., Wagner et al., etc.) para demostrar la actual falta de rigor.

El artículo sostiene que:

Las prácticas actuales de anotación con LLM son insuficientes para entornos de seguridad crítica o sensibles al cumplimiento debido a la falta de definición en la fiabilidad y la calibración.
Los seis constructos propuestos proporcionan una base necesaria para la investigación reproducible, permitiendo a los investigadores seleccionar las dimensiones relevantes para su tarea específica (por ejemplo, las tareas deterministas pueden no requerir las seis dimensiones).
El marco reconoce las limitaciones, particularmente respecto a los modelos propietarios (por ejemplo, GPT, Claude) donde los datos de entrenamiento y los calendarios de actualización son opacos, haciendo que la "estabilidad restringida" sea el objetivo realista en lugar del comportamiento determinista.

Significancia
La significancia de OLAF reside en su potencial para elevar los estándares metodológicos de la Ingeniería de Software Empírica. Al proporcionar un vocabulario estructurado y un enfoque de medición, busca:

Motivar discusiones metodológicas respecto a la validez de las etiquetas generadas por LLM.
Permitir que el trabajo empírico futuro sea más transparente y reproducible.
Evitar que la naturaleza de "caja negra" de la anotación con LLM socave la validez de los hallazgos de la investigación en SE.

Los autores posicionan a OLAF como un paso inicial, con la planificación de evaluar empíricamente el impacto del marco en la reproducibilidad y de desarrollar ejemplos operacionales específicos para la SE en el futuro.