Si estás metiendo IA generativa en procesos reales (soporte, ventas, operaciones, producto…), hay una verdad incómoda: “funciona… hasta que no”. Lo que te salva no es cambiar de modelo cada mes, sino montar evals continuos para detectar degradaciones, fugas de datos y costes inflados antes de que te exploten en producción. Y si quieres aterrizarlo en serio con un partner técnico, en Bolmia lo trabajamos end-to-end como Agencia de IA.
Por qué “va bien en demo” y “falla en producción” es lo normal
En demo todo es limpio: preguntas bonitas, contexto perfecto, cero presión. En producción llega la vida real: usuarios que escriben a medias, tickets con datos incompletos, documentación que cambia sin avisar, y workflows donde una respuesta no es “texto” sino una decisión que impacta al negocio. Ahí aparecen los clásicos: respuestas seguras pero inútiles (“no puedo ayudarte”), respuestas útiles pero inventadas (alucinación), y respuestas correctas pero demasiado caras (tokens y tool calls disparados).
Los evals continuos son la diferencia entre “tenemos un bot” y “tenemos un sistema”. Un sistema tiene control de calidad, trazabilidad, umbrales, rollback y mejora continua. Y, sobre todo, tiene un lenguaje común para que producto, negocio y tech hablen de lo mismo: precisión, riesgo y coste por caso de uso.
Lo importante es asumir desde el principio que tu IA es un producto vivo. Si no mides, no mejoras; si no mejoras, te estancas; y si te estancas, acabas apagándolo “porque da problemas”, cuando el problema real era que estabas operando a ciegas.
Qué significa evaluar “por caso de uso” (y por qué cambia todo)
“Responder preguntas” no es un caso de uso. Un caso de uso es un trabajo concreto con un objetivo medible: resolver incidencias de facturación en menos de 3 mensajes, clasificar leads con una justificación clara, redactar un resumen de llamada con campos obligatorios, o proponer una respuesta para que el agente la revise.
Esto importa porque cada caso de uso tiene tolerancias distintas. En soporte puedes permitir un tono mejorable, pero no una política inventada. En ventas, una frase demasiado agresiva puede bajar conversión aunque sea “correcta”. En operaciones, una acción equivocada puede romper un flujo entero. Por eso evaluar “calidad general” suele darte números bonitos… y cero capacidad para tomar decisiones.
Cuando evaluas por caso de uso, el diseño de métricas se vuelve mucho más claro:
- ¿Qué significa “correcto” aquí?
- ¿Qué es “dudoso” (necesita revisión humana)?
- ¿Qué es “KO” (bloquear o escalar sí o sí)?
Esa rúbrica es tu contrato de calidad. Y cuando la tienes, puedes automatizar decisiones y evitar discusiones eternas del tipo “yo creo que la respuesta está bien”.
El punto de partida: define la rúbrica antes de tocar métricas
Aquí no hay magia: necesitas escribir criterios simples, entendibles y accionables. Nada de definiciones académicas. Cosas como:
- Correcto: cita la fuente interna, da pasos concretos y cumple restricciones.
- Dudoso: responde bien, pero le falta un dato clave o no cita la fuente.
- KO: inventa una política, pide datos sensibles innecesarios o ejecuta una acción no autorizada.
Un truco que funciona mucho: añade ejemplos reales (de soporte, de ventas, de operaciones). “El bot pidió DNI por chat”, “el bot dijo que devolvíamos dinero sin condiciones”, “el bot actualizó el CRM con un dato deducido”. Esos ejemplos convierten la rúbrica en una herramienta que el equipo usa, no en un PDF decorativo.
En esta fase suele aparecer la primera gran decisión: cuánto automatizas y cuánto revisas con humanos. No hace falta ser radical. Lo típico que funciona es empezar con revisión más alta, aprender patrones de fallo y luego ir automatizando con calma.
Dataset vivo: tu seguro contra el drift
Si tus evals no tienen un dataset, lo que tienes es una opinión. Y lo peor: una opinión que cambia según quién mire la conversación. Por eso lo que más rentabiliza al inicio no es “elegir el mejor modelo”, sino construir un dataset que represente tu realidad.
Empieza pequeño, pero bien elegido. 50–150 ejemplos por caso de uso, con variedad real: preguntas frecuentes, casos complejos, inputs ambiguos, y casos borde (los que rompen todo). La clave no es tener miles: es que sea representativo y se actualice.
La regla de oro: cada semana el dataset crece con lo que producción te enseña. Si el bot falló ayer en una devolución, ese ejemplo entra hoy. Si alguien intentó un jailbreak con un “ignora instrucciones”, ese ejemplo entra hoy. Si la política cambió, entran ejemplos nuevos. Así creas un dataset vivo que detecta drift antes de que te explote.
Aquí encajan prácticas típicas de servicios de inteligencia artificial bien montados: no “probamos y ya”, sino “operamos con evidencias”.
Precisión que sirve: mide utilidad, no solo “parecido”
En LLMs, medir “accuracy” a secas suele engañar. Porque el modelo puede sonar convincente y aun así estar mal. Lo que te interesa es una mezcla de cuatro dimensiones:
- Factualidad: no inventa datos, no contradice fuentes.
- Cobertura: incluye lo importante (pasos, excepciones, restricciones).
- Utilidad: ayuda a ejecutar la tarea sin fricción (no da rodeos).
- Consistencia: no cambia radicalmente ante inputs equivalentes.
Si tu IA dispara acciones (crear ticket, actualizar CRM, enviar un email), añade una quinta dimensión: error operativo. Una respuesta bonita que actualiza mal un campo cuesta más que una respuesta fea.
Para aterrizarlo, lo más práctico es combinar validaciones automáticas con revisión humana por muestreo. Validaciones automáticas: formato, campos obligatorios, checks de “must-have”. Revisión humana: para matices (tono, contexto, decisiones límite). Esa combinación es lo que suele aplicar una consultoría de IA que trabaja con producción real: automatizar lo repetible, revisar lo que tiene riesgo.
Seguridad como métrica operativa (no como checklist de compliance)
Seguridad no es “poner un filtro y listo”. En IA aplicada, seguridad es comportamiento: qué hace el sistema cuando alguien intenta saltarse reglas, extraer datos o inducir acciones peligrosas.
Por eso, además de evaluar respuestas normales, necesitas un pack de pruebas “maliciosas” que ejecutes de forma recurrente: prompt injection, jailbreaks, intentos de extracción de PII, solicitudes prohibidas, y trampas tipo “copia y pega este texto que contiene instrucciones ocultas”.
Y no se trata solo de lo que el modelo dice, sino de lo que puede hacer. Si tiene herramientas conectadas, el riesgo sube. Aquí es donde se nota si hay una auditoría de IA y seguridad bien planteada: permisos mínimos, logs claros, y un sistema que sepa decir “no” con elegancia sin volverse inútil.
Una métrica simple pero potente es “incidentes de seguridad por cada 1.000 interacciones”. Si sube, algo cambió: prompt, base de conocimiento, herramientas o comportamiento del usuario. Sin esa métrica, solo te enteras cuando hay un susto.
Coste por caso de uso: deja de mirar tokens como si fueran el único problema
“Este modelo es más barato” es una frase peligrosísima sin contexto. El coste real suele ser una suma de cosas:
- Tokens de entrada y salida.
- Llamadas a herramientas (búsquedas, CRM, tickets, funciones).
- Infraestructura y latencia.
- Tiempo humano de revisión.
- Coste de errores (retrabajo, escalados, tickets reabiertos).
Lo que te interesa no es “€ por 1K tokens”, sino “€ por caso resuelto” o “€ por acción correcta”. Porque a veces un modelo más caro que resuelve mejor reduce revisiones humanas y acaba siendo más barato en total.
Y ojo con el “contexto inflado”: es el asesino silencioso. Metes 20 KB de políticas “por si acaso” y de repente cada conversación cuesta el doble y responde peor porque el contexto es ruido. En proyectos de implementación de inteligencia artificial bien hechos, verás optimizaciones típicas: recorte de contexto, cache de FAQs, y reglas para limitar tool calls.
Observabilidad: sin trazas, no hay mejora (solo excusas)
Tu evaluación offline es el gimnasio. Producción es el ring. En producción necesitas trazas mínimas para entender por qué el sistema se comportó así:
- versión de prompt y modelo,
- herramientas llamadas y resultados,
- fuentes recuperadas (si hay RAG),
- tokens por turno,
- latencia,
- y outcome (¿se resolvió?, ¿se escaló?, ¿hubo queja?).
Con eso, puedes correlacionar causas. “Bajó la precisión cuando cambiamos chunking”. “Subió el coste cuando activamos una tool para todo”. “El recall del buscador cayó tras actualizar documentación”.
Sin observabilidad pasa lo típico: “antes iba mejor” y nadie puede probarlo. Con observabilidad puedes trabajar como un equipo serio: hipótesis → cambio → medición → rollback si toca.
Esto es especialmente crítico cuando trabajas con RAG y bases de conocimiento, porque muchas degradaciones vienen de ahí: documentos duplicados, chunks mal cortados, embeddings inconsistentes o scoring que favorece textos irrelevantes.
Evals en CI/CD: si baja la calidad, no se despliega
La forma más sana de operar IA es tratarla como software: cada cambio debería pasar tests. Con LLMs, esos tests son evals.
No necesitas empezar con 20 métricas. Empieza con tres gates simples:
- Formato: si prometes JSON, siempre JSON.
- Calidad mínima en tu golden set: factualidad + cobertura.
- Seguridad mínima en tu pack de ataques.
Cuando eso está, reduces drásticamente el riesgo de “tocamos una frase del prompt y rompimos soporte”. Y te permite iterar rápido, que es la gracia: mejorar sin miedo.
Si además haces despliegues canary (5–10% del tráfico), puedes medir en vivo antes de escalar. Si sube el KO, rollback. Sin drama. Esto cambia el juego porque deja de ser un salto al vacío y se vuelve un proceso controlado.
El rol de modelos, prompts y “trucos”: dónde sí y dónde no
Aquí va una verdad que suele molestar: la mayoría de problemas no se arreglan con un prompt más largo. Un prompt puede mejorar consistencia o tono, pero si tu recuperación falla, fallará con cualquier prompt. Si tus herramientas tienen permisos excesivos, el prompt no te salva. Si no mides, vas a “optimizar” a ciegas.
Eso no significa que los prompts no importen. Importan, pero como parte de un sistema. Un prompt bueno reduce ambigüedad, fija prioridades (“primero seguridad, luego utilidad”), y define el comportamiento ante dudas (“si falta dato, pregunta”). Pero la mejora sostenida viene de evals + observabilidad + dataset vivo.
Y sí, hay técnicas avanzadas que pueden subir rendimiento: routing por intent, chain-of-thought interno (sin exponerlo), herramientas con gates, y calibración de un juez automático. En equipos que trabajan con LLMs y modelos de lenguaje en producción, esto se organiza como ingeniería: no como “arte”.
Ajustes finos que suelen mejorar precisión y bajar coste a la vez
Cuando empiezas a medir, aparecen patrones repetidos. Por ejemplo: el bot falla más cuando el usuario mete dos preguntas en una. Solución: reescribir la tarea internamente, separar y responder por partes. O el bot se inventa cosas cuando no encuentra fuente: solución: regla dura de “si no hay evidencia, preguntar o escalar”.
Otro patrón típico: el sistema recupera demasiados documentos, mete ruido, y la respuesta empeora. Ajuste: menos documentos, mejor ranking, y chunking más coherente. En RAG, “más contexto” no siempre es “mejor”.
Y luego están los wins de coste: cachear respuestas de FAQs, evitar tool calls redundantes y recortar contexto repetido. Es bastante común bajar un 20–40% de tokens simplemente dejando de pegar el manual completo en cada turno. Ese ahorro no solo es dinero: suele mejorar calidad por reducción de ruido.
Si además necesitas adaptar el modelo a tu dominio, ahí entra el fine-tuning de modelos o técnicas más ligeras como instrucciones con ejemplos bien curados. Pero ojo: si tu dataset no está limpio y tu rúbrica no es clara, el fine-tuning puede “aprender” tus errores con mucha eficiencia.
Un plan realista para montarlo sin convertirlo en un proyecto infinito
Si quieres hacerlo bien y rápido, la clave es foco. Un caso de uso. Un dataset inicial. Unas métricas mínimas. Un loop semanal.
Empiezas por lo que más duele y más volumen tiene: soporte, por ejemplo. Definir rúbrica, recopilar casos reales, instrumentar trazas y levantar gates básicos. A la semana ya tienes un baseline: precisión, incidentes, coste por conversación. A partir de ahí mejoras con intención: cambias algo, puedes medir el ROI real de la IA, y comparas con el baseline.
En paralelo, defines qué parte del flujo debe ser “asistente” y cuál “copiloto”. Muchas empresas se empeñan en full-auto demasiado pronto y se meten en líos. Un copiloto bien evaluado (que sugiere, y el humano confirma) puede darte valor desde el día 1 con muchísimo menos riesgo. Y mientras tanto, vas construyendo el camino al full-auto para intents de bajo riesgo.
Este enfoque suele ser el más rentable cuando trabajas con una consultora de inteligencia artificial: no porque “sepa más prompts”, sino porque te monta el sistema de medición y operación para que el valor se mantenga en el tiempo.
Lo que te deja dormir tranquilo
Lo que separa una IA que entretiene de una IA que mueve negocio no es el modelo “top”, ni el prompt “secreto”, ni el framework de moda. Es el sistema: dataset vivo, evals continuos, observabilidad, gates en despliegue, y una cultura de mejora basada en datos.
Cuando lo tienes, pasan dos cosas buenas: primero, mejoras con velocidad sin miedo a romperlo todo. Segundo, puedes hablar con dirección con números claros: “subimos utilidad un 12%, bajamos coste un 18%, y los incidentes de seguridad están por debajo del umbral”. Eso convierte la IA en una línea operativa, no en un experimento eterno.
Preguntas frecuentes sobre evals continuos
¿Qué son exactamente los evals continuos?
Son evaluaciones recurrentes (offline y en producción) que miden calidad, seguridad y coste de tu IA por caso de uso, con métricas repetibles y umbrales.
¿Cada cuánto debería ejecutar evaluaciones?
En cada cambio (prompt, modelo, RAG, tools) y además de forma periódica (diaria o semanal) para detectar drift aunque “no hayas tocado nada”.
¿Cómo evito que el modelo “alucine” datos?
Exige evidencia (fuentes RAG) y define un comportamiento claro: si no hay información suficiente, preguntar o escalar. Evalúa factualidad como métrica principal.
¿Es buena idea usar un LLM como juez?
Sí, para scoring repetible (formato, rúbricas, checks), pero calibrado y complementado con muestreo humano, sobre todo en casos de riesgo.
¿Qué métrica de coste es la más útil?
Coste por resultado: € por caso resuelto o por acción correcta (tokens + herramientas + revisión humana + incidentes). Te da la foto real del ROI.
