2026-08-01T09:31:05.341Z

LLM Evaluación: recorrer cada decisión a la evidencia correcta

Separar evaluaciones fuera de línea, puertas de regresión, controles de calidad en vivo, salud en el tiempo de ejecución y verificación de resultados antes de que una puntuación verde oculte un resultado roto.

La evaluación de LLM es la práctica de comprobar si un sistema de propulsión de modelo cumple un criterio definido en un objetivo definido. El defecto útil es simple: nombrar primero la decisión, y luego recopilar la evidencia más estrecha que pueda apoyarla. Un conjunto de datos seleccionado puede respaldar una afirmación de calidad previa a la publicación. Una comparación de referencia puede apoyar una decisión de regresión. Las ejecuciones de producción muestrada pueden revelar una deriva de calidad en vivo. Ninguno de ellos, por sí solo, prueba que un agente fuera accesible, completó un efecto herramienta, o entregó el artefacto prometido. Ese límite importa porque la evaluación aprobada suena más amplia de lo que es. Una puntuación siempre tiene un objetivo, un reloj y pruebas faltantes. Tratarlo como un veredicto de salud universal crea un verde falso: la respuesta parece buena mientras el proceso o resultado se rompe. Comience con la decisión, no con la métrica. Antes de elegir la coincidencia exacta, una puntuación de incorporación, un juez LLM, o una plataforma, escriba una oración en esta forma: En esta vez , decida esta acción de esta meta usando esta evidencia . Esa frase envía el trabajo a un carril: Decisión de la Comisión Objetivo Reloj Evidencias mínimas Reclamación más fuerte apoyada ¿Es un candidato lo suficientemente bueno? Ejemplos seleccionados Antes del despliegue Dataset, puntuación específica de tarea El candidato cumple el criterio nombrado en este conjunto de datos ¿La liberación ha retrocedido? Línea de base y candidato En el momento de su liberación Las carreras emparejadas, el umbral El candidato no superó el límite de regresión nombrado ¿Está la calidad de la vida a la deriva? Lugares de producción incluidos en la muestra Durante el tráfico Muestra fresca, evaluador de producción Esta muestra cumple o no cumple con el criterio en vivo ¿El agente está sano? Tiempo de ejecución y trabajo esperado En el tiempo de ejecución esperado Pulso cardíaco, horario, recibo de progreso El tiempo de ejecución es alcanzable y el trabajo útil se mueve ¿Se produjo el resultado previsto? Destino externo Tras el plazo de vigencia o finalización Recibo de destino, monto de chequeo, prueba de aceptación El efecto o entregable existe y pasa la verificación Las dos últimas filas no son mejores evaluaciones. Un evaluador puede inspeccionar una respuesta o un rastro; la salud operativa necesita pruebas sobre el proceso que debe ejecutarse; la verificación de resultados necesita pruebas del destino donde debería existir el resultado. La evaluación fuera de línea apoya las reclamaciones preliminares limitadas Orientación de evaluación de OpenAI define un flujo de trabajo útil: establece el objetivo, recopila un conjunto de datos, define métricas, ejecuta comparaciones y continúa evaluando a medida que el sistema cambia. También advierte contra las métricas genéricas y la evaluación basada en vibe. La implicación práctica es que una puntuación fuera de línea necesita una decisión de liberación adjunta a ella. Supongamos que un agente de soporte debe seleccionar la herramienta correcta, pasar el identificador de cuenta correcto y devolver una respuesta conforme a las políticas. No los desplome en un promedio. Utilice tres controles: controles exactos o basados en esquemas para la herramienta y los argumentos seleccionados; una rúbrica de calidad específica de la tarea para la respuesta; una verificación determinista de cualquier campo de salida que el contrato de solicitud requiera. Luego, comparar el candidato actual con la línea de referencia de liberación en los mismos casos. Un candidato que mejora el estilo de respuesta pero reduce la exactitud de la identificación de cuenta no es 0.7% mejor. Cambió una clase de fracaso por otra. La puerta de liberación debe indicar si ese comercio está permitido. Por lo tanto, las pruebas de regresión son un uso particular de la evaluación fuera de línea, no un sinónimo de toda la evaluación. Requiere una línea de base estable, casos emparejados y un umbral vinculado a una acción de liberación. Graba la versión del conjunto de datos, la versión de puntuación, el modelo y la configuración de la solicitud, el recuento de muestras y los desacuerdos. Sin ese manifiesto, no se puede atribuir un cambio de puntaje con seguridad. El piso razonable puede ser pequeño. De cinco a diez ejemplos cuidadosamente revisados por componente crítico son más útiles que un conjunto sintético grande con criterios de aceptación poco claros. Ampliar el conjunto de incidentes reales, casos de borde y desacuerdos entre los revisores. Un conjunto de datos debería ser más difícil porque el sistema te enseñó dónde falla, no porque un panel de control recompone casos. La evaluación en línea observa el comportamiento en vivo, con referencias más débiles Los conceptos de evaluación de LangSmith hace una importante distinción de objetivo. Las evaluaciones fuera de línea se ejecutan sobre conjuntos de datos y ejemplos, a menudo con resultados de referencia. Las evaluaciones en línea se realizan en circuitos de producción o en hilos, donde por lo general no se dispone de una referencia correcta. Eso cambia lo que el veredicto puede significar. Un evaluador en línea puede señalar un patrón de seguridad, una salida malformada, una deriva de tema, una baja satisfacción del usuario o una trayectoria inusual. También puede recoger casos en vivo difíciles para el conjunto de regresión fuera de línea. No puede heredar silenciosamente la confianza de una prueba respaldada por referencia. Su muestra puede ser obsoleta, filtrada, poco representativa o calificada por un juez que se ha desviado. Para cada regla en línea, retenga: la política de muestreo y las exclusiones; el identificador de corriente o hilo, sin filtración de contenido sensible; la versión del evaluador y la rúbrica; el tiempo de observación y la ventana de frescura; la acción desencadenada por un error; un camino para la revisión humana y la captura de desacuerdos. Documentación del kit de desarrollo de agentes de Google separa la evaluación de la trayectoria de uso de las herramientas de la evaluación de la respuesta final. Eso es útil, pero la coincidencia de trayectoria requiere moderación. Dos agentes válidos pueden resolver la misma tarea a través de diferentes secuencias de herramientas. La coincidencia exacta de la trayectoria es apropiada cuando el orden es parte del contrato de seguridad; de lo contrario, verifique los efectos requeridos y las acciones prohibidas en lugar de exigir un camino ideal. El seguimiento de la producción también contiene señales de no evaluación. La latencia, la tasa de errores, el uso de tokens y la integridad del rastro describen el comportamiento del servicio. Un evaluador de la calidad de la respuesta describe el contenido o el comportamiento de la muestra. Ninguno de los dos establece que el trabajador programado de mañana sea accesible. Mantenga estas afirmaciones separadas incluso si una plataforma las muestra juntas. El límite final necesita recibos, no otro juez. Tres casos de la fijación del artículo produjeron la misma trampa: una puntuación genérica LLM pasó, sin embargo, el único veredicto defendible fue UNKNOWN . 1. El caso de salud en tiempo de carrera tenía un horario esperado y un registro de progreso, pero no un nuevo latido cardíaco. El viejo trabajo bueno no demostró la accesibilidad actual. 2. La caja de efecto herramienta tenía una identificación de operación estable, pero no había recibo del destino. Un tiempo de espera podría ocultar o ningún efecto o un efecto completo. 3. El caso de entrega final tenía una definición de prueba de aceptación, pero no una suma de verificación de artefactos. No había nada concreto para probar. Un juez de LLM no puede reparar estas lagunas. Preguntar a un modelo si un trabajador probablemente está vivo no crea un latido cardíaco. Preguntar si un correo electrónico probablemente fue enviado no crea un recibo del proveedor. La pregunta de si un archivo suena completo no demuestra que el archivo exista en el camino requerido. Prefiero evidencia determinista cerca de la frontera: un ritmo cardíaco fresco y un registro de la disponibilidad esperada; un recibo de progreso vinculado a una identificación de ejecución no secreta para su ejecución; una llave de idempotencia más una dirección de destino para un efecto externo; una suma de comprobación, validación de esquema, resultado de ensayo o consulta de destino de un producto entregado; un recibo autorizado de la decisión relativa a una acción irreversible. Las pruebas faltantes deben seguir desapareciendo. UNKNOWN es un estado operacionalmente útil porque realiza investigaciones sin inventar éxito o fracaso. Reproducir la auditoría de enrutamiento de pruebas de ocho casos El artefacto inspectable utilizado para este artículo contiene ocho casos de decisión. Cada caso declara la decisión, la evidencia disponible, el camino esperado y el veredicto esperado. La política central es deliberadamente mecánica: La fijación cubre la calidad de los candidatos, la regresión de liberación, la deriva de la calidad en vivo, la salud en el tiempo de ejecución, los efectos externos, los resultados finales, la revisión subjetiva y la autoridad humana. El funcionamiento producido: Todos los ocho casos alcanzaron el camino esperado de la evidencia. Cinco tenían suficiente evidencia para su reclamo limitado. Tres eran desconocidos, y todos los tres habrían parecido verdes si la póliza hubiera aceptado un puntaje de aprobación genérico. Este no es un estándar universal. Reemplazar el dispositivo con decisiones de un flujo de trabajo real. Añade los nombres exactos de pruebas que su tiempo de ejecución y destinos pueden producir. Mantenga el comportamiento de falla: si una señal requerida está ausente, devuelva desconocido y enumere los campos que faltan. No convierta la ausencia en una puntuación cero, porque cero sugiere que se produjo la medición. Elige el puntero sólo después del objetivo de la evidencia Una vez que el objetivo es correcto, la selección de punteros se hace más fácil. Utilice código cuando la propiedad es determinista: forma JSON, nombre de herramienta, rango de argumentos, suma de comprobación, presencia de archivo, estado de prueba o estado de destino. Utilice un juez LLM cuando la propiedad sea genuinamente cualitativa y tenga una rúbrica clara, un conjunto de calibración y un camino de revisión de desacuerdos. La guía de OpenAI señala que los modelos a menudo son más confiables para discriminar entre opciones que para producir juicios abiertos, por lo que la comparación o clasificación en pares puede ser más fuerte que una puntuación sin restricciones. Utilice la revisión humana cuando la decisión involucre el gusto sin una rubrica estable, autoridad legal o política, ambigüedad de alto impacto, secretos o acción irreversible. Un juez puede resumir la evidencia para el revisor; no puede convertirse en la persona autorizada. Documentación de evaluación de MLflow describe conjuntos de datos, marcadores, funciones de predicción, retroalimentación humana, evaluación sistemática y monitoreo de producción como capacidades relacionadas. Ese es un menú de implementación útil. La regla de enrutamiento todavía pertenece al propietario de la aplicación: la herramienta puede calcular una puntuación, pero sólo el propietario puede definir qué decisión se permite que la puntuación respalde. Mantenga cuatro veredictos en el registro de liberación y operaciones Un registro de evaluación compacto debe responder de forma independiente a cuatro preguntas: ¿Cumplió el candidato sus criterios de calidad fuera de línea? ¿Evitó una regresión prohibida frente a la línea de base? ¿Cumple una muestra de producción fresca con sus criterios en línea? ¿Es saludable el trabajo esperado, y se verifica el resultado prometido? No estimes las respuestas. Un lanzamiento puede pasar una evaluación fuera de línea mientras que la evidencia en vivo aún no está disponible. Una muestra de producción puede verse saludable mientras se pierde una carrera programada. Un rastro puede parecer completo mientras el artefacto final está ausente. Preserva cada veredicto, su tiempo de prueba y su alcance. Esto produce una regla de funcionamiento más tranquila: evaluar el comportamiento del modelo y la aplicación con conjuntos de datos y ejecuciones de muestras; evaluar la salud del tiempo de ejecución con evidencia de accesibilidad, programación, espera y progreso; verificar los resultados externos en su destino. Escala sólo el carril perdido o fallido. Sidewisp se encuentra actualmente en versión preliminar privada. Se está diseñando como una capa de salud para los tiempos de funcionamiento de los agentes existentes, pero generalmente no se envían adaptadores de monitoreo de producción y sistemas de recuperación. Si la distinción entre una carrera de buen aspecto y un resultado verificado es el problema que está tratando de resolver, la lista de espera de vista previa privada es el siguiente paso apropiado.