Implementación de IA, el oficial de cumplimiento de nuestro cliente nos hizo una pregunta que no pudimos responder.
"¿Cómo sabes que tu agente no está alucinando los síntomas del paciente?"
Teníamos pruebas unitarias. Tuvimos pruebas de integración. Teníamos un modelo que funcionó maravillosamente en el conjunto de datos de demostración. Lo que no teníamos era un instrumento de evaluación que pudiera medir la tasa de alucinaciones, la fidelidad al contexto o la precisión de la selección de herramientas en la producción.
Esa brecha casi acaba con el proyecto. Seis semanas después, teníamos un marco de evaluación de 12 métricas que se ejecutaba en cada respuesta de los agentes, cada llamada a la herramienta y cada operación de recuperación. El equipo de cumplimiento aprobó. El agente envió.
En las más de 100 implementaciones de agentes de IA empresarial que hemos enviado desde entonces, ese marco ha evolucionado hasta convertirse en el siguiente manual. Si está creando agentes de IA de producción, este es el instrumento de evaluación que desearíamos haber tenido el primer día.
El marco de 12 métricas de un vistazo
Tres categorías cubren las operaciones internas del agente (recuperación, generación y comportamiento del agente). La cuarta categoría mide lo que le importa a la producción (costo y latencia). Omita cualquiera de estas categorías bajo su propio riesgo.
Por qué la mayoría de los equipos se saltan la evaluación (y la pagan más tarde)
En los proyectos que hemos auditado, tres patrones explican por qué los equipos envían agentes de IA sin una infraestructura de evaluación adecuada.
Patrón 1: "Agregaremos evaluación después del MVP".
Este es el patrón más común y más caro. Para cuando se envía el MVP, el equipo ha creado una interfaz de usuario, una API, integraciones y clientes incorporados. Ahora tienen que agregar infraestructura de evaluación a un sistema que ya está en producción, en el que los usuarios envían consultas impredecibles. La modernización tarda entre 4 y 6 semanas. El retraso en la recopilación de datos significa que no pueden detectar una regresión durante días. Para entonces, el daño a la confianza ya está hecho.
Patrón 2: "La precisión es suficiente".
La precisión en un equipo de prueba mantenido es necesaria pero no suficiente. Un agente de RAG puede tener un 95 % de precisión en las preguntas de referencia y aun así alucinar el 30 % del tiempo en consultas de usuarios reales que quedan fuera de la distribución de referencia. El tráfico de producción siempre es diferente de su conjunto de evaluación. Sin fidelidad, tasa de alucinaciones y métricas de selección de herramientas, estás volando a ciegas.
Patrón 3: “Las comprobaciones manuales al azar están bien”.
La revisión manual funciona con 100 consultas por día. Se rompe en 10.000. Los equipos que intentan ampliar la revisión manual agotan a sus ingenieros o aceptan que en realidad no están revisando el volumen que afirman. La evaluación automatizada no es opcional una vez que se realizan unos pocos miles de consultas por día.
El siguiente marco aborda los tres patrones. Constrúyalo antes de enviarlo, instrumente cada capa y deje que las métricas le digan lo que sus revisiones manuales no pueden decir.
Para los equipos que crean agentes de IA para la automatización empresarial, el mecanismo de evaluación a menudo determina si el proyecto llega a producción.
El marco de 12 métricas
El marco agrupa 12 métricas en cuatro categorías. Cada categoría responde a una pregunta diferente sobre el desempeño de su agente.
Categoría 1: Métricas de recuperación (4)
Si su agente utiliza la recuperación (RAG, búsqueda en la base de conocimientos, búsqueda de documentos), la calidad de la recuperación es la base. Una mala recuperación en sentido ascendente significa que ninguna cantidad de indicaciones inteligentes en sentido descendente puede salvar la respuesta.
1. Relevancia del contexto
Qué mide: ¿Qué fracción de los fragmentos recuperados son realmente relevantes para la consulta del usuario?
Por qué es importante: La mayoría de las fallas de RAG que vemos en la producción se remontan a la recuperación más que a la generación. El modelo sólo puede funcionar con lo que le das de comer. Si recupera 10 fragmentos y solo 3 son relevantes, ha contaminado el contexto y obligado al modelo a filtrar la señal del ruido.
Cómo lo medimos: para cada consulta, un evaluador de LLM como juez califica cada fragmento recuperado en una escala de relevancia de 0 a 1 en relación con la consulta. Promediamos los k fragmentos recuperados top.
Umbral objetivo: >0,85 de relevancia promedio en los 10 segmentos principales. Por debajo de 0,7 indica un problema de recuperación que vale la pena investigar antes de buscar mejoras en el modelo.
Nota de producción: cuando vemos que la relevancia del contexto cae por debajo de 0,75 en producción, la causa casi siempre es una de tres cosas: desviación del índice (documentos nuevos no fragmentados correctamente), cambio de intención de la consulta (los usuarios hacen preguntas diferentes a las del conjunto de evaluación) o discrepancia en la estrategia de fragmentación (fragmentos demasiado grandes o demasiado pequeños para el tipo de consulta).
2. Recuerdo del contexto
Qué mide: ¿Recuperamos TODA la información necesaria para responder la consulta o nos perdimos partes relevantes?
Por qué es importante: la recuperación es el asesino silencioso de los sistemas RAG. Un recuerdo bajo significa que la respuesta está incompleta o es incorrecta, pero el modelo no tiene forma de indicar "No tengo suficiente contexto". Generará con confianza a partir de información parcial.
Cómo lo medimos: esto requiere un conjunto de evaluación etiquetado en el que los evaluadores humanos hayan identificado todos los fragmentos que contienen información relevante para una consulta de referencia. Luego calculamos la fracción de esos fragmentos "relevantes de la verdad fundamental" que nuestra recuperación realmente arrojó.
Umbral objetivo: >0,90 de recuperación en consultas de referencia. Por debajo de 0,80 significa que se está perdiendo información sistemáticamente, lo que conduce a respuestas seguras pero incorrectas.
Nota de producción: las caídas de recuperación suelen ser un síntoma de una falta de coincidencia en el modelo de incrustación (su modelo de incrustación no captura la semántica de su dominio) o de problemas con el tamaño de los fragmentos (la información se divide en fragmentos de manera que anulan la búsqueda de similitudes). La solución suele ser volver a fragmentar, no remodelar.
3. Precisión del contexto
Qué mide: De los fragmentos recuperados, ¿los más relevantes están clasificados en la parte superior?
Por qué es importante: la mayoría de los sistemas RAG de producción pasan solo los 3 a 5 fragmentos superiores a la ventana de contexto LLM debido a los presupuestos de tokens. Si su fragmento principal es irrelevante pero el relevante está en la posición 7, efectivamente no ha recuperado nada útil.
Cómo lo medimos: Calculamos el rango recíproco medio (MRR): la posición promedio del primer fragmento relevante en los resultados de recuperación clasificados.
Umbral objetivo: MRR >0,80: su primer fragmento relevante debe estar en la posición 1 o 2 la mayor parte del tiempo.
Nota de producción: la precisión mejora drásticamente cuando agrega un reordenador después de la búsqueda de vector inicial. Hemos visto el MRR saltar de 0,55 a 0,92 al agregar un reordenador BGE además de la recuperación de pgvector. El costo de latencia es de ~50 ms; la ganancia de precisión vale la pena.
4. Latencia de recuperación
Qué mide: tiempo desde la recepción de la consulta hasta que los fragmentos recuperados están listos, medido en p95.
Por qué es importante: El tiempo de respuesta de los agentes de un extremo a otro está dominado por la recuperación a escala. Si la recuperación tarda 800 ms, el usuario espera 800 ms antes de que el LLM empiece a pensar.
Cómo lo medimos: Monitoreo estándar del rendimiento de la aplicación en el servicio de recuperación. Registramos el tiempo de recuperación de cada consulta e informamos p50, p95 y p99.
Umbral objetivo: latencia de recuperación de p95 <200 ms. p99 <500ms.
Nota de producción: los picos de latencia generalmente se correlacionan con uno de los siguientes: crecimiento del tamaño del índice sin volver a ajustar los parámetros HNSW, saltos de red entre el servicio integrado y la base de datos vectorial o errores de caché de inicio en frío. Investigue cuál de los tres antes de asumir que necesita una base de datos vectorial más rápida.
Categoría 2: Métricas de Generación (3)
Una vez que se recupera el contexto correcto, la calidad de la generación determina si el usuario recibe una respuesta útil. Aquí importan tres métricas.
5. Responda Fidelidad
Qué mide: ¿La respuesta generada refleja con precisión el contexto recuperado, o contradice o fabrica información?
Por qué es importante: Esta es la métrica más importante para cualquier agente de IA que preste servicios a industrias reguladas. Una respuesta infiel en contextos sanitarios, fintech o legales es una falta de cumplimiento. Incluso fuera de la regulación, la fidelidad determina directamente la confianza del usuario.
Cómo lo medimos: para cada respuesta generada, un evaluador de LLM como juez extrae afirmaciones atómicas de la respuesta y luego compara cada afirmación con el contexto recuperado. La puntuación de fidelidad es la fracción de afirmaciones respaldadas por el contexto.
Umbral objetivo: >0,95 de fidelidad en industrias reguladas. >0,90 en casos de uso general. Cualquier valor por debajo de 0,85 necesita una investigación inmediata.
Nota de producción: Las caídas de fidelidad generalmente indican una de tres causas: configuraciones de temperatura demasiado altas (bájelas a 0.0-0.3 para producción), desbordamiento de la ventana de contexto (los fragmentos recuperados más el mensaje exceden los límites del contexto y el modelo alucina a partir de los datos de entrenamiento) o una plantilla de mensaje que fomenta la extrapolación (“Según el contexto, ¿qué piensas…”).
6. Relevancia de la respuesta
Qué mide: ¿La respuesta generada realmente aborda lo que preguntó el usuario o se sale del tema?
Por qué es importante: La relevancia es distinta de la fidelidad. Una respuesta puede ser 100% fiel al contexto pero no abordar la pregunta real del usuario. Ambas métricas deben ser altas simultáneamente para una buena respuesta.
Cómo lo medimos: el evaluador de LLM como juez genera de 3 a 5 preguntas cuya respuesta sería una buena respuesta, luego calcula la similitud semántica entre esas preguntas generadas y la consulta original del usuario.
Umbral objetivo: >0,90 de relevancia. Por debajo de 0,80, el agente responde preguntas adyacentes, no la pregunta del usuario.
Nota de producción: Los problemas de relevancia a menudo se remontan a pasos de reescritura de consultas en flujos de agente. Si su agente reescribe "¿Cómo cancelo mi suscripción?" en "¿Cuál es la política de cancelación?" y luego responde la consulta reescrita, la intención original se pierde.
7. Tasa de alucinaciones
Qué mide: ¿Con qué frecuencia el modelo genera hechos, nombres, números o afirmaciones que no tienen base en el contexto recuperado o en la realidad verificable?
Por qué es importante: la tasa de alucinaciones es la métrica sobre la que le preguntará su CTO. La fidelidad mide la fidelidad al contexto; La tasa de alucinaciones mide la fabricación más allá del contexto. Se superponen pero no son idénticos: un modelo puede ser fiel a un mal contexto o infiel de manera benigna.
Cómo lo medimos: tomamos muestras del 5% de las consultas de producción diariamente y las ejecutamos a través de un proceso de detección de alucinaciones dedicado que señala las afirmaciones que requieren verificación de datos y luego revisa por humanos el subconjunto marcado.
Umbral objetivo: <2% de tasa de alucinaciones para agentes de producción. <0,5% para implementaciones industriales reguladas.
Nota de producción: picos de alucinaciones según tipo de consulta. Las preguntas abiertas alucinan más que el sí/no. Las preguntas numéricas alucinan más que las categóricas. Cree una clasificación de tipo de consulta en su proceso de evaluación para que pueda orientar la investigación.
Categoría 3: Métricas específicas del agente (3)
Si su sistema de IA es un agente (de varios pasos, que utiliza herramientas, dirigido a objetivos) en lugar de un simple canal RAG, tres métricas adicionales son importantes.
8. Precisión en la selección de herramientas
Qué mide: cuando el agente puede elegir entre herramientas, ¿elige la adecuada para la intención del usuario?
Por qué es importante: Los agentes modernos tienen acceso a docenas de herramientas: búsqueda, calculadoras, calendarios, consultas de bases de datos y llamadas API. La selección de herramientas incorrectas se produce en cascada: el agente luego intenta hacer que una clavija cuadrada encaje en un orificio redondo, lo que genera resultados incorrectos en el futuro.
Cómo lo medimos: cree un conjunto de evaluación etiquetado de pares (consulta, herramienta_correcta). Ejecute el agente según las consultas y calcule la precisión de la selección de herramientas en el primer punto de decisión.
Umbral objetivo: >0,92 para opciones de herramientas binarias. >0,85 para elegir entre más de 5 herramientas.
Nota de producción: La precisión de la selección de herramientas disminuye a medida que aumenta la cantidad de herramientas disponibles. Hemos visto una precisión del 95 % con 3 herramientas que se reduce al 70 % con 12 herramientas. La solución suele ser descripciones de herramientas más claras, menos herramientas por agente (descompuestas en subagentes especializados) o ajustes en los seguimientos de uso de herramientas desde la producción.
9. Éxito en la ejecución de la herramienta
Qué mide: De las llamadas a la herramienta que realiza el agente, ¿qué fracción se ejecuta correctamente (argumentos correctos, respuestas válidas, sin errores)?
Por qué es importante: un agente puede elegir la herramienta adecuada y aún así llamarla incorrectamente: formato de argumento incorrecto, campos obligatorios faltantes, entrada con formato incorrecto. El éxito de la ejecución de la herramienta aísla este modo de falla.
Cómo lo medimos: realice un seguimiento de cada llamada de herramienta en producción con estado de éxito/error, categorización de errores y reintentos. Calcule la tasa de éxito por herramienta, por tipo de consulta y por ventana de tiempo.
Umbral objetivo: tasa de éxito de ejecución de herramienta >0,98. Por debajo de 0,95 indica problemas sistemáticos de construcción de argumentos.
Nota de producción: el modo de error más común es que el agente construya con confianza argumentos en un formato que no coincide con el esquema real de la herramienta (por ejemplo, pasar una cadena de fecha cuando la API espera ISO 8601). La solución es la aplicación de salida estructurada (llamada a función, validación de esquema JSON) en el límite de la herramienta.
10. Coherencia de varios pasos
Qué mide: cuando el agente ejecuta un plan de varios pasos, ¿el flujo lógico permanece coherente en todos los pasos?
Por qué es importante: La precisión de un solo paso es necesaria pero no suficiente para el comportamiento agente. Un agente que elige la herramienta correcta en el paso 1, obtiene un buen resultado y luego olvida que el resultado del paso 4 ha fallado, a pesar de que cada paso individual tuvo éxito.
Cómo lo medimos: evaluación a nivel de traza. Para cada seguimiento de varios pasos, un evaluador de LLM como juez califica si cada paso se basa en pasos anteriores de manera coherente y si el resultado final refleja la cadena de razonamiento completa.
Umbral objetivo: >0,85 de coherencia en trazas de más de 4 pasos. Por debajo de 0,75, su agente básicamente realiza múltiples consultas desconectadas de un solo paso.
Nota de producción: la coherencia disminuye con la longitud del trazo. Vemos que una coherencia superior al 95 % en trazados de 2 pasos colapsa al 60 % en trazados de 6 pasos. La solución es la descomposición (dividir una tarea de 6 pasos en 2 tareas separadas de 3 pasos con una transferencia explícita) o la arquitectura de la memoria (estado persistente entre los pasos en lugar de volver a solicitar el historial completo cada vez).
Categoría 4: Métricas de producción (2)
Las primeras diez métricas miden lo que hace el agente. Estas dos métricas miden lo que le importa a la producción.
11. Costo por consulta
Qué mide: Costo total (costo del token + costo de infraestructura + costos de llamadas de herramientas) por consulta de usuario, promediado entre el tráfico de producción.
Por qué es importante: Los agentes de IA tienen un perfil de costos único: una sola consulta de usuario puede desencadenar entre 5 y 15 llamadas de LLM (reescritura, recuperación de calificación, selección de herramientas, generación, verificación). La expansión de tokens convierte una consulta de $0,02 en una consulta de $0,30 sin que nadie se dé cuenta hasta que llega la factura mensual.
Cómo lo medimos: instrumentamos cada llamada de LLM con un registro de uso de tokens, cada llamada de herramienta con costos API asociados y cada dependencia de infraestructura con costo prorrateado. Agregado por consulta, luego por tipo de consulta y luego por ventana de tiempo.
Umbral objetivo: varía según el caso de uso. Herramientas internas para empleados: <$0,10/consulta es aceptable. Productos orientados al cliente: <$0,05/consulta para economía sostenible. En las industrias reguladas, el costo importa menos que otras métricas.
Nota de producción: los picos de costos generalmente se deben a uno de los siguientes: crecimiento de la duración del aviso (el aviso de su sistema creció con el tiempo), tormentas de reintentos (fallas que desencadenan bucles de reejecución) o inflación de la ventana de contexto (los fragmentos recuperados se hacen más largos a medida que crece su base de conocimientos). Los tres son fáciles de instrumentar y arreglar.
Para los equipos que ven que el costo por consulta tiene una tendencia ascendente de manera insostenible, la decisión de construir versus comprar a menudo se desplaza hacia una infraestructura personalizada con costos limitados en lugar de precios de API por token.
12. Latencia P99
Qué mide: tiempo de un extremo a otro desde la consulta del usuario hasta la respuesta final, medido en el percentil 99.
Por qué es importante: La latencia promedio oculta los modos de falla que frustran a los usuarios. Un sistema con una latencia promedio de 1 segundo pero p99 de 15 segundos hace que los usuarios abandonen las sesiones después de 4 o 5 respuestas lentas. P99 es lo que recuerdan los usuarios.
Cómo lo medimos: Monitoreo estándar del rendimiento de las aplicaciones. Registramos la latencia de un extremo a otro para cada consulta e informamos p50, p95, p99 y máx. Realizamos un seguimiento de estos por tipo de consulta porque las consultas conversacionales deberían ser mucho más rápidas que las consultas analíticas.
Umbral objetivo: p99 <3 segundos para agentes conversacionales. p99 <10 segundos para agentes analíticos que realizan razonamiento de varios pasos. Más allá de los 10 segundos, los usuarios se desconectan.
Nota de producción: la latencia P99 casi siempre está dominada por una de tres cosas: recuperación (caché en frío de base de datos vectorial), llamadas a herramientas (tiempos de espera de API externos) o generación de LLM para salidas largas (lo que afecta a los cuellos de botella de transmisión token por token). Identifique la causa dominante antes de optimizar la capa incorrecta.
Un árbol de decisiones: qué métricas priorizar primero
Doce métricas son muchas para instrumentar simultáneamente. Así es como secuenciamos la implementación en las fases del proyecto.
Fase 1 (prelanzamiento – Semana 0-2): implementar métricas de recuperación (relevancia del contexto, recuperación, precisión) más fidelidad de las respuestas. Estos cuatro detectan los modos de falla previos al lanzamiento más comunes.
Fase 2 (lanzamiento suave: semana 3 a 6): agregue la tasa de alucinaciones, la relevancia de las respuestas y la precisión de la selección de herramientas. Estos detectan problemas que solo surgen con el tráfico de usuarios reales.
Fase 3 (Producción estable – Semana 7+): agregue costo por consulta, latencia P99, éxito en la ejecución de la herramienta, coherencia de varios pasos y latencia de recuperación. Estos optimizan el sistema en ejecución en lugar de detectar fallas que bloquean el lanzamiento.
Modificadores de casos de uso:
Industria regulada (atención sanitaria, tecnología financiera, legal): priorizar la fidelidad y la tasa de alucinaciones por encima de todo. Apunte a una fidelidad >0,97 y una tasa de alucinaciones <0,5% desde el primer día. Producto de consumo de gran volumen: priorice el costo por consulta y la latencia P99. La fidelidad importa, pero no a expensas de la economía unitaria. Herramientas internas para empleados: priorice el éxito de la ejecución de las herramientas y la coherencia de varios pasos. Los empleados perdonan las respuestas lentas pero no los flujos de trabajo interrumpidos.
Cómo se compara este marco con las herramientas existentes
No es necesario crear las 12 métricas desde cero. Varias herramientas comerciales y de código abierto cubren subconjuntos de este marco.
Ragas cubre bien la relevancia del contexto, el recuerdo, la precisión, la fidelidad y la relevancia de las respuestas. Es el punto de partida de código abierto más sólido para métricas específicas de RAG. No cubre métricas específicas del agente ni el estado de la producción.
TruLens cubre métricas RAG similares con herramientas de observabilidad más sólidas. Mejor integración con LangChain y LlamaIndex. Requiere más configuración que Ragas.
DeepEval ofrece una biblioteca de métricas más amplia con buen soporte específico para agentes (selección de herramientas, fidelidad). Más nuevo que Ragas, comunidad más pequeña.
LangSmith proporciona seguimiento y evaluación de la producción para los agentes basados en LangChain. Fuerte en seguimiento y observabilidad, más débil en evaluación comparativa fuera de línea.
Por qué construimos nuestro propio marco: Ninguna de las herramientas existentes cubre las 12 métricas en un solo lugar, y las métricas específicas del agente (precisión de la selección de herramientas, coherencia de varios pasos) están particularmente desatendidas. Usamos Ragas para métricas RAG, evaluadores personalizados para métricas de agentes y herramientas APM estándar (Datadog, OpenTelemetry) para métricas de estado de producción. El marco anterior es la visión unificada de los tres.
Realidad de la implementación: lo que realmente cuesta construir esto
Configurar el marco completo de 12 métricas requiere de 2 a 3 semanas de esfuerzo de ingeniería enfocado, suponiendo que ya tenga configurado un evaluador de LLM.
Desglose del tiempo:
Construcción del conjunto de evaluación (consultas etiquetadas + verdad sobre el terreno): 4 a 6 días Implementación de métricas (Ragas o personalizada): 3 a 5 días Integración de CI/CD (ejecutar evaluación en cada PR): 2 a 3 días Instrumentación de monitoreo de producción: 3 a 5 días Paneles de control y alertas: 2 a 3 días
Herramientas que utilizamos en todas las implementaciones:
Orquestación de evaluación: Ragas + evaluadores personalizados en Python LLM como juez: GPT-4 para evaluación de alto riesgo, Claude Sonnet para evaluación sensible a los costos, Llama 3 70B para entornos de cumplimiento totalmente autohospedados Almacenamiento: PostgreSQL para resultados de evaluación, S3 para seguimientos sin procesar Paneles de control: Grafana para métricas de producción, Streamlit para informes de evaluación fuera de línea Alertas: integración de PagerDuty para violaciones de umbrales
Errores comunes que hemos visto enfrentar a los equipos:
Utilizando el mismo modelo para generación y juicio. Esto produce puntuaciones infladas. Utilice una familia de modelos diferente para el juez que para el generador. Saltando el conjunto de evaluación etiquetado. Sin etiquetas de verdad sobre el terreno, no se puede calcular la recuperación ni medir la regresión. El coste del etiquetado es real pero se amortiza en el primer mes. Ejecutar eval solo en casos de éxito. Necesita casos de falla en su conjunto de evaluación, o nunca detectará regresiones. Muestreo de fallas de producción de manera agresiva. Tratar las puntuaciones de evaluación como absolutas. Realice un seguimiento de tendencias y deltas, no de puntuaciones absolutas. Una puntuación de 0,85 que cae a 0,78 en una semana es más significativa que el número absoluto.
Preguntas frecuentes
¿Cuál es la configuración de evaluación mínima para un nuevo proyecto de agente de IA?
Para un nuevo proyecto, implemente la relevancia del contexto, la fidelidad de las respuestas y la precisión de la selección de herramientas. Estos tres detectan el 70 % de los fallos previos al lanzamiento con una mínima sobrecarga de configuración. Omita las métricas de producción hasta que tenga tráfico de producción real.
¿Con qué frecuencia debemos ejecutar la suite de evaluación completa?
Ejecute una evaluación sin conexión (contra un conjunto de puntos de referencia etiquetados) en cada cambio de código que afecte la recuperación, las indicaciones o la lógica del agente. Ejecute evaluaciones en línea (tráfico de producción de muestra) continuamente, con informes acumulativos diarios. Las repeticiones completas de los índices de referencia son costosas, pero deberían realizarse al menos semanalmente para detectar las regresiones.
¿Deberíamos utilizar un LLM como juez o una evaluación humana?
Ambos están secuenciados. Utilice LLM como juez para escalar (evalúe el 100 % del tráfico de producción a bajo costo), utilice la evaluación humana para la calibración (evalúe una muestra del 1 al 2 % para verificar que el juez de LLM esté de acuerdo con el consenso humano). Cuando el juez de LLM y la evaluación humana diverjan, vuelva a capacitar al juez.
¿Cuál es la diferencia entre la evaluación en línea y fuera de línea?
La evaluación fuera de línea se compara con un conjunto de datos de referencia etiquetados con respuestas correctas conocidas. La evaluación en línea va en contra del tráfico de producción real, donde no se conoce de antemano la respuesta real, por lo que se miden señales indirectas (fidelidad, relevancia, alucinaciones) en lugar de precisión. Ambos son necesarios. Sin conexión detecta las regresiones antes de enviarlas. Online detecta problemas que surgen del comportamiento real del usuario.
¿Cómo manejamos la evaluación de agentes no deterministas?
Ejecute cada consulta de evaluación de 3 a 5 veces e informe la media y la varianza de las puntuaciones. Una variación alta indica que el comportamiento del agente es inestable, lo que en sí mismo es una señal que vale la pena investigar. Para el tráfico de producción, tome muestras suficientes para superar el ruido de la variación.
¿Qué métricas son más importantes para los sistemas RAG versus Agentic?
Sistemas RAG puros: priorice las cuatro métricas de recuperación más la fidelidad. Sistemas agentes: agregue precisión en la selección de herramientas, éxito en la ejecución de herramientas y coherencia de varios pasos además de las métricas RAG. Las métricas de producción (costo, latencia) son igualmente importantes para ambos.
¿Cómo medimos la satisfacción del usuario en Eval?
La satisfacción del usuario depende de las 12 métricas anteriores. Si sus métricas de fidelidad, relevancia y latencia están todas dentro del rango objetivo, se realizará un seguimiento de la satisfacción. Las señales directas de satisfacción (pulgar hacia arriba o hacia abajo, preguntas de seguimiento, abandono de sesión) son útiles como indicadores de salud de la producción, pero van por detrás de las métricas que las causan.
¿Cuál es el costo de la evaluación? ¿Vale la pena?
La evaluación de un LLM como juez cuesta aproximadamente entre el 30% y el 50% de su costo de inferencia (cada consulta de producción también es evaluada por un LLM). Para un presupuesto de inferencia de 4.000 dólares al mes, espere entre 1.200 y 2.000 dólares al mes en costos de evaluación. El retorno de la inversión está evitando un solo incidente de producción cuya depuración costaría semanas a los ingenieros o recuperación de daños a la confianza. Después del primer incidente evitado, eval se amortiza indefinidamente.
Pensamiento final
Los equipos que envían agentes de IA con éxito en 2026 no son los que tienen los mejores modelos. Son los que tienen la mejor infraestructura de evaluación. Los modelos son mercancías. La evaluación es diferenciación.
Si está creando agentes de IA de producción y desea una segunda opinión sobre su marco de evaluación basado en más de 100 implementaciones, el equipo de Intuz estará encantado de ayudarle.
Recursos
Pratik K Rupareliya es cofundador y director de estrategia de Intuz, donde lidera la estrategia de IA empresarial en más de 100 implementaciones que abarcan atención médica, tecnología financiera, manufactura y comercio minorista. Conéctese con él en LinkedIn.