Evaluación de SLMs y LLMs en Datos Personalizados con Prompt Flow

Introducción

Evaluar modelos de lenguaje grandes, o LLMs, y modelos de lenguaje pequeños, o SLMs, con datos personalizados es una práctica clave antes de llevar una solución generativa a producción. No basta con que un modelo tenga buenos resultados en benchmarks generales: hay que comprobar cómo responde ante los datos, instrucciones, formatos y restricciones reales de la organización.

Azure Prompt Flow, integrado en el ecosistema de Azure Machine Learning y Azure AI, permite construir flujos para experimentar, ejecutar inferencias, comparar variantes y medir resultados de forma más sistemática. El enfoque descrito por Microsoft para la evaluación de SLMs y LLMs con datos personalizados se basa precisamente en usar Prompt Flow como capa de orquestación para probar modelos sobre conjuntos de datos propios y analizar sus respuestas.

Este artículo resume un enfoque práctico y prudente para diseñar ese proceso de evaluación, evitando asumir que un modelo “más grande” será siempre mejor para todos los escenarios.

Por qué evaluar con datos personalizados

Los benchmarks públicos son útiles para comparar capacidades generales, pero no sustituyen una evaluación orientada al caso de uso. En aplicaciones empresariales, el rendimiento real depende de factores como:

El dominio del lenguaje: legal, financiero, sanitario, soporte técnico, industria, administración pública, etc.
La estructura de los datos de entrada.
La calidad de las instrucciones del prompt.
La necesidad de respuestas breves, trazables o justificadas.
El idioma y las variantes lingüísticas.
La tolerancia a errores, ambigüedad o alucinaciones.
Los requisitos de latencia, coste y privacidad.

Por eso, comparar un SLM y un LLM sobre el mismo conjunto de ejemplos permite tomar decisiones más informadas. Un LLM puede ofrecer mayor capacidad de razonamiento o comprensión general, mientras que un SLM puede resultar suficiente en tareas acotadas, con menor coste y menor latencia, siempre que su calidad sea aceptable para el caso de uso.

Qué papel cumple Prompt Flow

Prompt Flow ayuda a estructurar el ciclo de evaluación de aplicaciones basadas en modelos de lenguaje. En lugar de probar prompts de forma manual y aislada, permite definir un flujo reproducible que puede incluir:

Entrada de datos de evaluación.
Preparación o transformación del input.
Llamada al modelo o a la aplicación que se quiere evaluar.
Generación de una respuesta.
Comparación con una referencia, cuando existe.
Cálculo o registro de métricas.
Revisión de resultados para análisis posterior.

Este enfoque es especialmente útil cuando queremos comparar varias alternativas:

Un SLM frente a un LLM.
Diferentes versiones de un mismo prompt.
Distintos parámetros de generación.
Distintos modelos desplegados o disponibles en Azure.
Diferentes estrategias de grounding o recuperación de contexto.

Preparación de la evaluación

Antes de crear el flujo, conviene definir el objetivo de evaluación. No todas las tareas se miden igual.

1. Define el caso de uso

Algunos ejemplos habituales son:

Clasificación de texto.
Extracción de entidades.
Resumen de documentos.
Respuesta a preguntas sobre documentación interna.
Generación de respuestas para soporte.
Reescritura o normalización de contenido.
Análisis semántico de consultas.

Cada caso de uso requiere criterios distintos. Por ejemplo, una tarea de clasificación puede evaluarse con métricas tradicionales si tenemos etiquetas esperadas. En cambio, una tarea de respuesta abierta puede necesitar revisión humana, evaluación asistida por otro modelo o criterios cualitativos más específicos.

2. Construye un dataset representativo

El conjunto de evaluación debe reflejar datos reales o suficientemente cercanos a producción. Un dataset útil debería incluir:

Ejemplos frecuentes.
Casos límite.
Entradas ambiguas.
Variaciones de idioma o tono.
Consultas incompletas o mal formuladas.
Ejemplos donde el modelo debería rechazar responder o pedir aclaración.
Respuestas esperadas, si existen.

Para tareas supervisadas, es recomendable incluir una columna con la respuesta correcta o esperada. Para tareas generativas, puede ser más útil guardar una respuesta de referencia, criterios de aceptación o una rúbrica de evaluación.

Un esquema sencillo podría ser:

Campo	Descripción
`id`	Identificador único del ejemplo
`input`	Texto, pregunta o instrucción enviada al modelo
`context`	Contexto opcional usado por la aplicación
`expected_output`	Respuesta esperada, si aplica
`category`	Tipo de caso o segmento funcional
`notes`	Observaciones para revisión humana

3. Decide las métricas

Las métricas deben elegirse según la tarea. Algunas opciones razonables son:

Accuracy, cuando la salida esperada es una clase cerrada.
Precision, recall y F1, para clasificación o extracción.
Exact match, cuando la respuesta debe coincidir exactamente con un valor esperado.
Similitud semántica, cuando hay múltiples formas válidas de responder.
Relevancia, para comprobar si la respuesta atiende la pregunta.
Coherencia, para valorar si la respuesta es comprensible y consistente.
Groundedness o fundamentación, cuando la respuesta debe basarse en un contexto proporcionado.
Latencia, especialmente importante en aplicaciones interactivas.
Coste estimado, si se comparan modelos con precios o consumos diferentes.
Tasa de errores, incluyendo timeouts, respuestas vacías o formatos inválidos.

No todas las métricas tienen el mismo peso. En escenarios regulados, por ejemplo, puede ser más importante la fundamentación de la respuesta que la fluidez.

Diseño de un flujo de evaluación

Un flujo de evaluación con Prompt Flow puede organizarse de forma conceptual en tres bloques.

Bloque 1: entrada de datos

El flujo recibe cada ejemplo del dataset: pregunta, contexto, metadatos y, si existe, respuesta esperada.

El objetivo es que todos los modelos se evalúen con el mismo conjunto de entradas. Esto reduce sesgos y permite comparar resultados de forma más justa.

Bloque 2: invocación del modelo

En este bloque se ejecuta la inferencia del modelo que queremos evaluar. Si estamos comparando un SLM y un LLM, conviene mantener constantes todas las variables posibles:

Mismo input.
Mismo contexto.
Misma plantilla de prompt, salvo que se esté evaluando precisamente el prompt.
Mismos criterios de formato de salida.
Parámetros de generación comparables, cuando sea posible.

En la práctica, el modelo puede estar expuesto mediante un endpoint, una conexión configurada en el entorno de Azure o una integración soportada por Prompt Flow. Lo importante es no mezclar cambios de modelo con cambios de prompt, datos o lógica de aplicación si queremos atribuir correctamente las diferencias de resultado.

Bloque 3: evaluación y registro

Después de obtener la respuesta, el flujo debe registrar:

Entrada original.
Respuesta generada.
Modelo evaluado.
Versión del prompt.
Métricas calculadas.
Errores de ejecución, si los hay.
Información útil para depuración.

Cuando existe una respuesta esperada, pueden calcularse métricas automáticas. Cuando la respuesta es abierta, puede combinarse evaluación automática con revisión humana sobre una muestra representativa.

Comparación entre SLMs y LLMs

La comparación debe ir más allá de una puntuación única. Para tomar una decisión técnica conviene analizar varios ejes.

Calidad de respuesta

Evalúa si el modelo:

Responde correctamente.
Sigue las instrucciones.
Mantiene el formato requerido.
Evita inventar información.
Usa el contexto proporcionado.
Reconoce cuándo no tiene información suficiente.

Robustez

Comprueba cómo se comporta ante:

Preguntas ambiguas.
Datos incompletos.
Entradas largas.
Lenguaje coloquial.
Errores ortográficos.
Casos fuera de dominio.

Un modelo puede funcionar bien en ejemplos sencillos y fallar en los casos que realmente importan para producción.

Coste y latencia

Los SLMs suelen ser candidatos interesantes cuando la tarea está bien delimitada y no requiere razonamiento complejo. Pueden ofrecer ventajas en:

Tiempo de respuesta.
Coste por inferencia.
Requisitos de infraestructura.
Escalabilidad operativa.

Sin embargo, esas ventajas solo son relevantes si la calidad es suficiente. Un modelo más barato que produce errores críticos puede terminar siendo más caro en operación.

Mantenibilidad

También conviene valorar:

Facilidad de despliegue.
Observabilidad.
Control de versiones.
Integración con el ciclo MLOps o LLMOps.
Capacidad de reproducir evaluaciones.
Facilidad para actualizar prompts, modelos o datasets.

Prompt Flow aporta valor precisamente porque permite estructurar y repetir experimentos de forma más ordenada.

Buenas prácticas para una evaluación fiable

Usa un conjunto de evaluación estable

Mantén un dataset base que no cambie constantemente. Si cada evaluación usa ejemplos distintos, será difícil saber si una mejora se debe al modelo o al cambio en los datos.

Puedes tener varios conjuntos:

Smoke test, pequeño y rápido.
Evaluación funcional, con casos representativos.
Evaluación de regresión, para detectar empeoramientos.
Evaluación adversarial, con casos difíciles o sensibles.

Versiona prompts y configuraciones

Registra siempre qué prompt, modelo y parámetros se usaron. En soluciones generativas, pequeños cambios en una instrucción pueden alterar mucho el resultado.

Como mínimo, guarda:

Nombre del modelo.
Versión o identificador del despliegue, si aplica.
Plantilla de prompt.
Parámetros relevantes de generación.
Fecha de ejecución del experimento.
Dataset usado.

Combina métricas automáticas y revisión humana

Las métricas automáticas aceleran el análisis, pero no siempre capturan matices de calidad, tono, utilidad o riesgo. Para casos de alto impacto, es recomendable incluir revisión humana, al menos sobre una muestra.

La revisión humana puede usar una rúbrica con criterios como:

Criterio	Pregunta de evaluación
Corrección	¿La respuesta es técnicamente correcta?
Relevancia	¿Responde realmente a la pregunta?
Fundamentación	¿Se basa en el contexto disponible?
Claridad	¿Es fácil de entender?
Seguridad	¿Evita instrucciones peligrosas o no permitidas?
Formato	¿Cumple el contrato de salida esperado?

Analiza errores, no solo promedios

Una media alta puede ocultar fallos graves en categorías concretas. Segmenta los resultados por:

Tipo de pregunta.
Categoría de documento.
Idioma.
Longitud de entrada.
Complejidad.
Presencia o ausencia de contexto.
Casos con información insuficiente.

Esta segmentación ayuda a decidir si el problema se resuelve cambiando de modelo, ajustando el prompt, mejorando el contexto o depurando el dataset.

Ejemplo de matriz de decisión

Una forma práctica de comparar modelos es construir una tabla como la siguiente:

Criterio	SLM	LLM	Comentario
Exactitud funcional	Media	Alta	El LLM resuelve mejor casos ambiguos
Latencia	Baja	Media/Alta	El SLM responde más rápido
Coste estimado	Bajo	Mayor	Depende del volumen de uso
Seguimiento de formato	Alto	Alto	Ambos cumplen con prompt estructurado
Casos fuera de dominio	Medio	Alto	El LLM generaliza mejor
Facilidad operativa	Alta	Media	Depende del despliegue y gobierno

La decisión final no debería ser “SLM o LLM” de forma abstracta, sino qué modelo cumple mejor los requisitos del caso de uso con el menor coste y riesgo aceptables.

Riesgos habituales

Al evaluar modelos sobre datos personalizados, conviene evitar algunos errores frecuentes:

Usar un dataset demasiado pequeño o poco representativo.
Evaluar solo ejemplos exitosos.
Cambiar prompt y modelo al mismo tiempo sin registrar versiones.
Medir únicamente fluidez, ignorando corrección factual.
No separar datos de prueba de datos usados para ajustar prompts.
No revisar manualmente respuestas en tareas abiertas.
Ignorar latencia, coste o límites operativos.
Aceptar respuestas plausibles sin comprobar si están fundamentadas.

La evaluación debe diseñarse como parte del ciclo de vida de la aplicación, no como una prueba puntual antes del lanzamiento.

Conclusión

Azure Prompt Flow ofrece una forma estructurada de evaluar SLMs y LLMs sobre datos personalizados, especialmente cuando se necesita comparar modelos, prompts y configuraciones de manera reproducible.

La clave está en definir bien el caso de uso, construir un dataset representativo, elegir métricas adecuadas y analizar los resultados con una combinación de evaluación automática y revisión humana. En algunos escenarios, un SLM puede ser suficiente y más eficiente; en otros, un LLM seguirá siendo preferible por su capacidad de razonamiento, generalización o manejo de ambigüedad.

La mejor elección no depende solo del tamaño del modelo, sino de su rendimiento medido frente a los datos y restricciones reales de la aplicación.

Fuente

Microsoft Tech Community: SLM and LLM Evaluation on Custom Data using Prompt Flow.