En este artículo
- Por qué evaluar tu chatbot no es opcional
- Paso cero: define qué significa «éxito» para ti
- Construye un «conjunto de datos de referencia» (golden dataset)
- ¿Qué mides exactamente? Las dimensiones clave
- Los tres métodos de evaluación
- Evaluación offline frente a online
- Un flujo de trabajo práctico para poner en marcha la evaluación
- Errores comunes que hacen inútil la evaluación
- Herramientas que ayudan
- El papel de Origami
- Fuentes
Por qué evaluar tu chatbot no es opcional
Hoy en día lanzar un chatbot de IA es fácil; saber si realmente es bueno es lo difícil. Los modelos de lenguaje son probabilísticos por naturaleza: la misma pregunta puede dar dos respuestas distintas, y «lo probé y parecía ir bien» con un puñado de prompts no significa que esté listo para miles de clientes. La evaluación es la forma sistemática de responder a una pregunta: ¿hace el bot su trabajo con precisión, seguridad y coherencia, antes de lanzarlo y después de cada cambio?
La regla es sencilla: no puedes mejorar lo que no mides. Sin un sistema de evaluación, cada ajuste del prompt o actualización del modelo se convierte en una apuesta en la que no sabes si has mejorado algo o has roto otra cosa sin darte cuenta.
Paso cero: define qué significa «éxito» para ti
Antes de cualquier métrica, responde a esto: ¿qué tarea debe cumplir el bot? Un bot de soporte tiene éxito cuando resuelve el problema o lo deriva correctamente. Un bot de ventas tiene éxito cuando cualifica al cliente potencial y recoge los datos adecuados. Un bot interno para empleados tiene éxito cuando responde con precisión y basándose en tus políticas. Vincula la evaluación a un objetivo de negocio, no a una vaga sensación de que la respuesta se lee bien.
Construye un «conjunto de datos de referencia» (golden dataset)
La base de cualquier evaluación seria es un conjunto fijo de ejemplos contra el que pruebas cada vez. Recógelo de tres fuentes:
- Preguntas reales de registros de chat reales (tras eliminar los datos personales).
- Casos límite: preguntas vagas, incompletas o fuera de alcance, o en dialectos diferentes.
- Casos adversarios: intentos de llevar al bot más allá de sus límites o de filtrar información.
Empieza con 50–100 ejemplos que cubran tus escenarios más importantes en lugar de miles de ejemplos aleatorios. Para cada uno, define, en la medida de lo posible, la respuesta de referencia o el criterio que hace que una respuesta sea correcta.
¿Qué mides exactamente? Las dimensiones clave
«Calidad» es una palabra difusa, así que divídela en dimensiones medibles:
- Éxito de la tarea: ¿logró realmente el usuario su objetivo? Es la métrica más importante y la más cercana al valor de negocio.
- Fidelidad (sin alucinaciones): en sistemas basados en tus fuentes (RAG), ¿la respuesta se construye solo sobre los documentos recuperados o el bot se inventó algo?
- Relevancia: ¿la respuesta aborda de verdad la pregunta del usuario o solo da rodeos sobre el tema?
- Calidad de la recuperación: en RAG, ¿extrajo el sistema los fragmentos correctos de tu base de conocimiento? (precisión y exhaustividad del contexto). La mayoría de los fallos de RAG provienen de una recuperación deficiente, no del modelo en sí.
- Corrección: ¿coincide la respuesta con una referencia conocida?
- Seguridad y cumplimiento: ¿rechaza las solicitudes peligrosas? ¿Protege los datos personales? ¿Mantiene el tono y las políticas de la marca? ¿Resiste los intentos de jailbreak?
- Coste y latencia: una respuesta excelente que tarda 30 segundos o cuesta demasiado por conversación puede ser un fracaso comercial. Mide siempre los tokens y el tiempo.
Los tres métodos de evaluación
- Evaluación humana: el estándar de referencia en calidad, pero lenta, cara y difícil de escalar. Úsala para construir tu referencia y para calibrar los métodos automatizados.
- LLM como juez: utilizas un modelo potente para puntuar las respuestas del bot según una rúbrica clara, o comparando dos respuestas. Es rápido y escalable, y el enfoque más común hoy en día, siempre que lo calibres frente al juicio humano y vigiles sus sesgos (como favorecer la respuesta más larga).
- Métricas automatizadas basadas en referencias: como la coincidencia exacta para preguntas de respuesta cerrada, o la similitud semántica mediante embeddings. Baratas e instantáneas, pero limitadas para respuestas abiertas.
En la práctica: combina los tres. Métricas automatizadas rápidas como primera barrera, un LLM juez para las dimensiones cualitativas y una revisión humana periódica de una muestra.
Evaluación offline frente a online
Hay dos tipos complementarios, y necesitas ambos:
- Offline: ejecutas el bot contra tu conjunto de datos de referencia en cada cambio, idealmente dentro de un pipeline de CI/CD para que ninguna actualización llegue a producción si las puntuaciones bajan. Es la prueba de regresión que te impide romper lo que ya funcionaba.
- Online: con usuarios reales: pruebas A/B entre dos versiones, un botón de valoración (👍/👎) y métricas de control (tasa de derivación a un humano, preguntas repetidas, abandono de la conversación). Supervisa la producción de forma continua, porque el comportamiento real de los usuarios revela lo que ningún conjunto de prueba puede.
Un flujo de trabajo práctico para poner en marcha la evaluación
- Define las 3–5 dimensiones que de verdad te importan (por ejemplo, éxito de la tarea, fidelidad, seguridad).
- Construye un conjunto de referencia pequeño pero representativo (50–100 casos).
- Redacta una rúbrica de puntuación clara para cada dimensión: qué merece un 5 y qué merece un 1.
- Automatiza la ejecución: un script que pase el bot por el conjunto y calcule las puntuaciones (humano + LLM juez).
- Intégralo en el pipeline de despliegue: cualquier puntuación por debajo del umbral bloquea el lanzamiento.
- Añade un ciclo de producción: recoge las valoraciones de los usuarios y los casos fallidos, y sigue añadiéndolos a tu conjunto de referencia.
Errores comunes que hacen inútil la evaluación
- Probar solo el camino feliz e ignorar los casos límite y adversarios.
- Un conjunto de prueba demasiado pequeño o que no representa a tus usuarios reales.
- Confiar en un LLM juez sin calibrarlo frente al juicio humano.
- Ignorar el coste y la latencia y centrarse solo en la calidad.
- Evaluar una sola vez en el lanzamiento en lugar de convertirlo en un proceso continuo con cada actualización.
El valor no está en lanzar un bot que habla, sino en contar con un sistema que te diga, en números, si ha mejorado o empeorado después de cada cambio.
Herramientas que ayudan
Existen herramientas de código abierto y comerciales que acortan la construcción de un pipeline de evaluación, entre ellas: Ragas y DeepEval para sistemas RAG; LangSmith, Braintrust y Arize Phoenix para supervisión y evaluación; y OpenAI Evals y promptfoo para escribir pruebas. Elige la herramienta que encaje con tu stack, pero recuerda que la metodología importa más que la herramienta.
El papel de Origami
En Origami somos una empresa tecnológica que construye sistemas de IA y los mide antes de entregarlos: diseñamos un conjunto de datos de referencia adaptado a tu sector, construimos un pipeline de evaluación automatizado conectado al despliegue y añadimos supervisión en producción que detecta las regresiones a tiempo y mantiene el coste bajo control. El objetivo es un bot en cuyos números puedas confiar, no solo una demo.
Fuentes
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023): arxiv.org/abs/2306.05685
- Documentación de Ragas sobre métricas de evaluación de RAG (fidelidad, relevancia, calidad del contexto): docs.ragas.io
- Documentación de evaluación de LangSmith: docs.smith.langchain.com
- OpenAI Evals: github.com/openai/evals
- Guía de Anthropic sobre cómo construir evaluaciones: docs.anthropic.com
Preguntas frecuentes
¿Cuál es la diferencia entre la evaluación offline y la online?
La evaluación offline ejecuta el bot contra un conjunto de datos de referencia fijo en cada cambio, idealmente en tu pipeline de CI, para detectar regresiones antes del lanzamiento. La evaluación online se hace con usuarios reales mediante pruebas A/B, botones de valoración y métricas de control. Necesitas ambas: la offline te protege antes de publicar, mientras que la online revela lo que solo el uso real deja al descubierto.
¿Cuántos ejemplos necesito en mi conjunto de prueba?
Empieza con 50 a 100 ejemplos bien elegidos que cubran tus escenarios más importantes y de mayor riesgo, no con miles de ejemplos aleatorios. Un conjunto pequeño, representativo y bien etiquetado supera a uno grande y ruidoso, y lo vas ampliando con el tiempo añadiendo fallos reales de producción.
¿Puedo confiar en que un modelo de IA se evalúe a sí mismo?
El LLM como juez es rápido, escalable y muy utilizado, pero tiene sesgos (como favorecer las respuestas más largas) y debe calibrarse frente al juicio humano sobre una muestra. Úsalo para las dimensiones cualitativas, mantén una revisión humana periódica y nunca tomes su puntuación como verdad absoluta sin comprobarla.
¿Con qué métrica debería empezar?
Con el éxito de la tarea, es decir, si el usuario logró realmente su objetivo, porque es la más cercana al valor de negocio. Para sistemas basados en tus documentos (RAG), añade la fidelidad para evitar alucinaciones y, después, incorpora seguridad, coste y latencia.
¿Con qué frecuencia debo volver a evaluar?
En cada cambio relevante (una edición del prompt, una actualización del modelo o una actualización de la base de conocimiento) y de forma continua en producción. La evaluación no es un filtro único antes del lanzamiento; es un proceso continuo que te dice si cada cambio ayudó o perjudicó.
Sigue a Origami en Google
Añade Origami como fuente preferida y nuestros artículos te aparecerán primero en la Búsqueda de Google y en las Noticias destacadas.
