AI4Fire: una herramienta SQL eleva la precisión de los LLM con bases de datos de incendios del 16% al 88%

Seis modelos de lenguaje base, cinco tareas de gestión de incendios forestales y dos modos de ejecución. Así es AI4Fire, un nuevo benchmark publicado en arXiv, cuya ejecución ampliada suma otros 29 modelos. El resultado principal: conectar una herramienta SQL de solo lectura elevó la precisión en el trabajo con bases de datos en cada uno de los seis modelos base, de un máximo del 16% a un mínimo del 88%. En la previsión de las necesidades de personal ocurre lo contrario: ningún modelo superó la regla de repetir la cifra de hoy.

Cómo se plantea la comparación

Los autores parten de que, en este campo, las estimaciones infladas salen caras: están en juego bienes y vidas. Por eso cada tarea se ejecuta en dos variantes. En el modo «desnudo» (bare), el modelo recibe solo los datos de entrada de la tarea. En el modo «anclado» (grounded), se añade un elemento específico de la tarea. En la detección de humo, es un fotograma sin humo de la misma cámara. En el trabajo con bases de datos, es una herramienta SQL. Todas las ejecuciones son zero-shot, sin ajuste fino ni ejemplos.

La comparación por pares permite medir con claridad la aportación de cada añadido. Según los autores, encontraron en la literatura 138 trabajos sobre tareas relacionadas con incendios, y ninguno combina un conjunto de modelos, una cobertura de tareas y unas ejecuciones por pares como estos. Han publicado los prompts, las respuestas, las evaluaciones, el código y el registro de la revisión de literatura.

• Modelos base: 6, más 29 en la ejecución ampliada
• Tareas de incendios forestales: 5
• Modo: zero-shot, bare y grounded
• Trabajos en la revisión de literatura: 138
• Tarea SQL: de ≤16% a ≥88% en cada modelo base

Dónde funciona el añadido y dónde no

Primera conclusión de los autores: el anclaje ayuda más cuando el propio añadido contiene la respuesta. Un modelo con acceso a la base de datos solo mediante consultas SQL de lectura extrae lo que necesita de las tablas, en lugar de recordarlo o adivinarlo. La brecha entre el 16% y el 88% indica que, sin la herramienta, en la práctica la tarea no se puede resolver.

La segunda conclusión es más sobria. En la previsión del número de efectivos, resultó difícil superar las reglas simples: ningún modelo base mejoró la repetición del valor de hoy. Dos modelos open-weight se dedicaron sobre todo a copiar la mediana de días pasados similares con incendios. Es un pronóstico más débil que el de la regla ingenua. El modelo parece razonar, pero en realidad reproduce una plantilla promediada que resulta peor que la cifra de ayer.

Trampas en los datos públicos

La tercera conclusión afecta a los propios datasets. En una de las publicaciones públicas, la columna con el índice de peligro de incendio separa a la perfección la muestra de validación. Es una fuga de información: una puntuación alta de un modelo en ese conjunto dice casi nada sobre sus capacidades. En otro conjunto, 67 imágenes aéreas de incendios llevan etiquetas de «rescoldo» o «sin fuego» derivadas de un máximo de temperatura recortado (clipped). Si el sensor llegó al techo de su escala, la etiqueta refleja el límite del instrumento, no la realidad.

Cada uno de estos errores infla el resultado, y los autores consideran peligrosas para el sector precisamente esas evaluaciones.

Qué deben hacer los equipos que implantan LLM en los servicios de bomberos

Antes de cualquier piloto, fije una regla base simple, por ejemplo repetir la plantilla actual, y exija que el modelo la supere. Si no lo hace, todavía es pronto para conectarlo a la planificación. Cuando la respuesta está en los datos, dé al modelo una herramienta de acceso en lugar de confiar en su memoria: el SQL de solo lectura aporta una gran mejora con un riesgo mínimo de corromper los datos. Antes de usar datasets públicos, compruebe si hay fugas de variables y de dónde proceden las etiquetas. Basta con preguntarse si una sola columna puede predecir la variable objetivo y si la etiqueta se obtuvo a partir de una señal saturada.

También hace falta cautela. Todas las ejecuciones son zero-shot, y las conclusiones se refieren a un conjunto concreto de cinco tareas. Los resultados de sistemas con ajuste fino o especializados pueden ser distintos. Aun así, las respuestas abiertas y el código permiten verificar las cifras y añadir modelos propios.