Medir modelos de lenguaje pequeños significa demostrar que un modelo más barato y rápido hace un trabajo específico lo suficientemente bien, y mostrar el ahorro en números. Los modelos pequeños como Microsoft Phi, Google Gemma, las variantes más pequeñas de Llama de Meta y Mistral Small pueden ejecutarse de forma económica a través de una API o en su propio hardware. Los KPI que importan son la calidad de la tarea, la latencia, el coste por tarea y el resultado comercial que respalda la tarea.
¿Por qué los modelos de lenguaje pequeños necesitan su propia medición?
Los modelos grandes a menudo se eligen por su reputación. Los modelos pequeños se eligen por un compromiso: aceptas cierta pérdida en la capacidad general a cambio de velocidad, coste y control. Ese compromiso solo es seguro cuando puedes verlo. Sin medición, un equipo paga de más por un modelo grande en tareas simples o implementa silenciosamente un modelo pequeño que se equivoca en una de cada diez respuestas.
Los modelos pequeños también tienden a ser más limitados. Un modelo que etiqueta bien los tickets de soporte puede escribir un mal anuncio. La medición debe realizarse por tarea, no por modelo.
¿Qué debería medir primero?
Comience con cuatro grupos de métricas. Cada uno responde a una pregunta diferente de una persona diferente en el negocio.
- Calidad: ¿el resultado cumple con el estándar? Medido frente a un conjunto de prueba etiquetado.
- Latencia: ¿cuánto tiempo tarda una respuesta? Medido como mediana y tiempo del percentil 95.
- Coste: ¿cuánto cuesta una tarea completada, incluidos los reintentos y las correcciones humanas?
- Impacto empresarial: ¿se movió el KPI posterior, como el tiempo de respuesta, la conversión o las horas ahorradas?
La calidad y el coste suelen ser lo más importante para los equipos de marketing. La latencia es importante para cualquier cosa en la que un cliente espere, como el chat o la búsqueda en el sitio.
Métricas de calidad por tipo de tarea
La métrica de calidad depende del trabajo. Para tareas de clasificación como puntuación de leads, etiquetado de intención o sentimiento, utilice precisión y exhaustividad frente a las etiquetas asignadas por un humano. Para tareas de extracción, cuente la proporción de campos completados correctamente. Para tareas de escritura, utilice una rúbrica calificada por personas o por un modelo más fuerte que actúe como juez, con una muestra verificada por personas para confirmar que el juez está de acuerdo.
Coste por tarea, no coste por token
Los precios de los tokens parecen pequeños y engañan. Calcule el coste por tarea completada: tokens por tarea multiplicados por el precio, más el coste de los reintentos, más los minutos que una persona dedica a corregir resultados incorrectos. Un modelo pequeño que necesita correcciones frecuentes puede costar más en total que un modelo más grande que no las necesita.
¿Cómo se construye un conjunto de evaluación?
Un conjunto de evaluación es una colección fija de entradas reales con resultados conocidos como buenos. Es la base de cada número en su panel.
- Recopile de 100 a 300 ejemplos reales de la tarea, no inventados.
- Haga que una persona etiquete o escriba el resultado correcto para cada uno.
- Incluya casos difíciles: errores tipográficos, idiomas mixtos, categorías límite.
- Congele el conjunto y asígnele un número de versión.
- Ejecute cada modelo candidato y prompt contra el mismo conjunto.
Mantenga un pequeño conjunto separado de nuevos ejemplos recopilados cada mes. Si el rendimiento en datos nuevos cae mientras el conjunto congelado se mantiene estable, sus entradas reales han cambiado y el modelo o el prompt necesita actualización.
¿Cómo es un panel útil?
Un panel para modelos de lenguaje pequeños debe caber en una pantalla y responder a tres preguntas: ¿funciona?, ¿es barato? y ¿ayuda? Looker Studio, Power BI o Grafana funcionan; lo que importa son los datos detrás.
Fila superior: salud
Solicitudes por día, tasa de error, mediana y percentil 95 de latencia. Estos provienen directamente de los registros de la aplicación. Un cambio repentino aquí suele significar un problema técnico en lugar de un problema del modelo.
Fila central: calidad
Puntuación más reciente en el conjunto de evaluación congelado, puntuación en la muestra fresca mensual y la tasa de anulación humana, que es la proporción de resultados que una persona cambió antes de su uso. La tasa de anulación es a menudo la señal de calidad más honesta que tiene en producción.
Fila inferior: valor
Coste por tarea a lo largo del tiempo, horas ahorradas por mes (tareas multiplicadas por minutos ahorrados por tarea, medido una vez cronometrando a las personas) y el KPI de negocio vinculado a la tarea. Para un modelo de etiquetado de leads, eso podría ser el tiempo desde que se completa el formulario hasta el primer contacto de ventas.
¿Cómo se compara un modelo pequeño con uno grande?
Ejecute ambos en el mismo conjunto de evaluación con la misma estructura de prompt. Grafique la calidad frente al coste por tarea. A menudo, el resultado es claro: el modelo pequeño alcanza la mayor parte de la puntuación del modelo grande a una fracción del coste en tareas limitadas, y se queda muy atrás en la escritura o el razonamiento de final abierto. Luego decida por tarea.
Una configuración de enrutamiento es común: el modelo pequeño maneja la tarea primero, y los casos en los que informa baja confianza, o donde una regla simple marca duda, van al modelo más grande. Mida la proporción de tráfico enrutado hacia arriba; si crece, el modelo pequeño ya no es una buena opción.
Cómo Alien Road aplica modelos de lenguaje pequeños y los mide
En un compromiso típico, nuestro equipo de AI Optimization enumera las tareas de IA del cliente y su modelo actual, luego elige las de alto volumen y limitadas como candidatas para un modelo pequeño, como la extracción de atributos de productos, el etiquetado de reseñas o la clasificación de leads.
Construimos el conjunto de evaluación con los propios datos del cliente, probamos dos o tres modelos pequeños contra el actual y configuramos el registro de latencia, coste y anulaciones. El panel se entrega en la propia herramienta de BI del cliente para que no dependa de nosotros.
Los informes son mensuales: calidad en conjuntos congelados y frescos, coste por tarea, tasa de anulación y el KPI de negocio vinculado, con una breve nota sobre cualquier cambio de modelo o prompt realizado ese mes.
¿Qué errores hacen que los números sean engañosos?
El más común es probar con ejemplos inventados, que son más limpios que los datos reales e inflan las puntuaciones. El segundo es ignorar el tiempo de corrección humana, lo que oculta el coste real. El tercero es cambiar el prompt y el modelo al mismo tiempo, por lo que nadie sabe qué cambio ayudó. Cambie una cosa por prueba.
Otra trampa es dejar que un modelo juzgue a otro sin comprobaciones. Un modelo juez tiene sus propios sesgos, incluida una preferencia por respuestas más largas. Verifique una muestra de sus puntuaciones a mano cada mes.
Por dónde empezar esta semana
Elija una tarea de alto volumen que su equipo ya ejecute a través de un modelo grande. Extraiga 100 entradas reales con sus resultados aceptados, ejecute un modelo pequeño contra ellas con el mismo prompt y compare la precisión y el coste por tarea en una hoja de cálculo simple. Esa comparación única le dice si vale la pena construir un panel a continuación.
Siga leyendo: Optimización con IA · Optimización con IA