A principios de 2026, estaba realizando una prueba de valor de gestión de patrimonios en un importante banco norteamericano. El agente en revisión no era un chatbot. Vivía dentro de un flujo de trabajo gobernado: recibía un caso, llamaba a herramientas (recuperación de documentos, controles de detección, consultas de cuentas) y producía una salida estructurada que los pasos de proceso posteriores consumían sin que un humano la leyera primero. Cerca del final de una sesión de trabajo, alguien del lado del cliente hizo la pregunta que toda empresa acaba haciendo: "¿Por qué este modelo? ¿Y cuánto nos costará por caso?" No tenía una respuesta defendible, y el mercado tampoco. Todo lo publicado sobre la calidad de los modelos en ese momento estaba diseñado para la era de los chatbots: puntuaciones MMLU, tablas de clasificación de arena, evaluaciones subjetivas donde alguien pegaba el mismo *prompt* en tres modelos y elegía un favorito. Nada de eso decía si este agente, con estas herramientas, dentro de este proceso, en estos casos, producía campos correctos a un precio predecible. Un Elo de tabla de clasificación no puede decirte si el modelo omitirá silenciosamente una verificación de sanciones cuando el caso parezca rutinario. Así que construí un arnés de evaluación para ello. En ese momento, las "evaluaciones de agentes" no eran una categoría que nadie pidiera; no existían herramientas listas para usar para evaluar un agente incrustado en el proceso, así que tuve que decidir desde cero qué valía la pena medir. Me decanté por cuatro ejes: costo, calidad, fiabilidad de la herramienta y sensibilidad a la temperatura. Desde entonces, los mismos cuatro ejes se han aplicado en muchos proyectos empresariales, y la pregunta que no pude responder en aquella sala ahora surge en casi todas las primeras reuniones. El mercado se puso al día con la pregunta. Esta guía es el método.  ## Por qué las evaluaciones de referencia responden a la pregunta equivocada Un agente incrustado en el proceso difiere de un chatbot de cuatro maneras que invalidan todas las técnicas de evaluación de la era de los chatbots. **Es multiturno por diseño.** Una instancia de proceso es un bucle: el modelo planifica, llama a una herramienta, recibe el resultado, planifica de nuevo. Un solo caso puede implicar dos llamadas al modelo o catorce. Cualquier métrica calculada sobre "un *prompt*, una finalización" mide algo que nunca ocurre en producción. **Llama a herramientas, y las llamadas a herramientas son el trabajo.** La respuesta final es a menudo la parte menos interesante de la transcripción. Si el agente realizó la búsqueda de beneficiario final antes de emitir un veredicto importa más que cómo se formula el veredicto. Una evaluación que solo inspecciona el texto final es ciega a la mayoría de los modos de fallo. **Su salida es estructurada y consumida por máquinas.** El agente emite JSON que los pasos posteriores enrutan. No hay un humano en el bucle para notar que un campo es sutilmente incorrecto. "Suena bien" no es una calificación; o `risk_rating` coincide con la etiqueta de oro o no. **Su costo es una propiedad de todo el bucle, no de la lista de precios por token.** Cada ida y vuelta de la herramienta reenvía el contexto de conversación creciente. Los reintentos por salida mal formada también son llamadas al modelo. Dos modelos con precios por token similares pueden diferir en múltiplos en el costo medido por caso, porque uno de ellos requiere más iteraciones para finalizar. | Dimensión | Evaluaciones de referencia (era de los chatbots) | Evaluaciones de proceso (era de los agentes) | |---|---|---| | Unidad de medida | Un *prompt*, una finalización | Una instancia de proceso, de principio a fin | | Forma de interacción | Preguntas y respuestas de un solo turno | Bucle multiturno con llamadas a herramientas | | Salida juzgada | Texto libre, preferencia humana | Campos estructurados, calificados por campo | | Modelo de costos | Precio por millón de tokens | Costo medido por caso, incluyendo reintentos e idas y vueltas de herramientas | | Modos de fallo visibles | Respuesta incorrecta o inútil | Campo incorrecto, herramienta omitida, herramienta incorrecta, argumentos mal formados o alucinados, respuesta prematura | | Qué significa "bueno" | Posición en la tabla de clasificación | El proceso se completó correctamente a un costo aceptable y predecible | El resto de esta guía aborda los cuatro ejes uno por uno. Cada uno es un conjunto de elementos concretos para registrar y métricas para calcular. Juntos responden las dos preguntas de aquella sala: qué modelo y a qué costo por caso. ## Eje 1: Costo por instancia de proceso La unidad que importa no es el token. Es el caso: una solicitud de préstamo, una revisión KYC, una reclamación. Esa es la unidad con la que la empresa fija precios, dota de personal y presupuesta, por lo que es la unidad en la que su evaluación debe informar. El costo medido por instancia es la suma de cada llamada al modelo que la instancia activó: - La llamada de planificación inicial. - Una llamada por cada ida y vuelta de la herramienta, cada una reenviando el contexto acumulado. En un bucle de agente ingenuo, los tokens de entrada crecen con cada iteración, por lo que los casos con muchas herramientas cuestan desproporcionadamente más de lo que sugiere la primera llamada. - Cada reintento. Si el modelo emite una salida que falla la validación del esquema y la capa de orquestación lo vuelve a *prompt*, ese reintento es dinero real y debe incluirse en la cifra. - Cualquier llamada auxiliar que el patrón requiera: validadores de salida, verificaciones de barandilla (*guardrail checks*), resumen de resultados de herramientas sobredimensionados. Para calcularlo, registre por cada llamada al modelo: identificador del modelo, tokens de entrada, tokens de salida, latencia y motivo de finalización. Registre por instancia: recuento de iteraciones y recuento de reintentos. Multiplique los tokens por los precios actuales del proveedor y sume. Informe la mediana y el p95, porque las distribuciones de costos de los agentes tienen colas largas; el caso que activa tres reintentos y doce llamadas a herramientas es el que aparece en la factura. Una métrica derivada se ha ganado su lugar en cada proyecto desde entonces: el **costo por caso correcto**, que es el costo por instancia dividido por la fracción de instancias que el modelo acertó completamente. Un modelo barato que se equivoca un tercio de las veces no es barato, porque alguien paga por el retrabajo. El hallazgo que hizo famoso este eje en mi propio trabajo: en una tarea de tipo KYC en aquel primer proyecto, un modelo de nivel medio igualó la precisión del modelo *premium* a aproximadamente 1/13 del costo por caso. No un 20 por ciento más barato. Trece veces más barato, sin pérdida de calidad medida en esa tarea. La razón, en retrospectiva, no es emocionante: la tarea era de extracción y seguimiento de reglas con herramientas bien especificadas, no de juicio abierto. Los modelos de nivel medio son buenos en eso ahora. Pero nadie en la sala habría apostado por esa proporción de antemano, y sin un arnés nadie podría haberlo demostrado. Las listas de precios por token predecían una brecha; solo el costo medido por caso la dimensionó.  El escollo en este eje es comparar listas de precios en lugar de medir. Un modelo que cuesta la mitad por token pero que promedia dos iteraciones de bucle adicionales y un reintento por caso puede resultar más caro. He visto esa inversión exacta suceder. Mida el bucle, no la lista. ## Eje 2: Calidad, calificada por campo La calidad para un agente incrustado en el proceso significa: ¿coincide la salida estructurada con lo que un experto competente habría producido para este caso? Eso requiere dos cosas que la mayoría de los equipos omiten: un conjunto de oro construido a partir de casos reales y una calificación por campo. **Construcción del conjunto de oro.** Mi regla de campo: de 10 a 30 escenarios elaborados a partir de casos reales superan a 1.000 sintéticos. Los generadores de casos sintéticos (normalmente otro LLM) reproducen los mismos puntos ciegos que el modelo bajo prueba; generan casos limpios, bien formados y estadísticamente promedio. Los casos reales presentan las complejidades que realmente rompen a los agentes: el nombre con guion que anula una heurística de coincidencia, el cliente con doble ciudadanía, el documento al que le falta una página, la entidad cuya dirección registrada difiere de su dirección operativa. El procedimiento que utilizo: 1. Siéntese con las personas que realizan el proceso hoy y extraiga de 10 a 30 casos reales, que abarquen situaciones rutinarias, de borde y conocidas como difíciles. 2. Anonimícelos estructuralmente: preserve la forma de la dificultad (la guionización, el documento faltante) mientras reemplaza cada valor identificativo. 3. Para cada escenario, pida al experto que anote el valor correcto para cada campo de salida, además de las herramientas que una ejecución correcta debe llamar. Esa segunda anotación alimenta el Eje 3. 4. Pida a un segundo experto que revise las etiquetas. Donde los dos no estén de acuerdo, el campo es ambiguo; o bien ajuste su definición o exclúyalo de la calificación. Las etiquetas de oro ambiguas son la forma en que las evaluaciones le mienten. **Calificación por campo, no por sensación.** Dado que la salida es estructurada, la mayoría de las calificaciones pueden ser deterministas: coincidencia exacta para enumeraciones e identificadores, coincidencia normalizada para nombres y fechas, tolerancia numérica para cantidades. Reserve el LLM-como-juez para los campos de justificación de texto libre, y trate esas puntuaciones como direccionales, no autoritarias (más sobre el sesgo del juez en las limitaciones). Calcule: - Precisión por campo en todos los escenarios, para que pueda ver que `entity_type` está bien pero `source_of_wealth` es débil. - Tasa de campos correctos por escenario, el número que se corresponde con "casos que no necesitan retrabajo". - Precisión de campos críticos como su propio titular. En un proceso de cumplimiento, equivocarse en `pep_flag` no es lo mismo que equivocarse en un matiz de formato. Pondere en consecuencia y dígalo en el informe. El escollo en este eje es la relajación gradual de la calificación. Cuando un modelo obtiene una puntuación baja, la tentación es suavizar el comparador ("suficientemente cerca") en lugar de aceptar la puntuación. Congele las reglas de calificación antes de ejecutar la prueba comparativa, y cámbielas solo con la misma disciplina que aplicaría al cambiar un conjunto de pruebas. ## Eje 3: Fiabilidad de la herramienta, el eje que nadie mide Este es el eje que nunca he visto en la evaluación de nadie más, y es el que ha cambiado la mayoría de las decisiones. Las métricas de los chatbots no tienen concepto de ello, porque los chatbots no tienen herramientas que omitir. A un agente incrustado en el proceso se le dan herramientas con un contrato implícito: para esta clase de caso, usted realiza la verificación de antecedentes, luego la búsqueda de propiedad, y luego responde. El modelo puede incumplir ese contrato de maneras que no producen ningún error, ninguna excepción y ningún artefacto visible en la salida final. Lo peor de esto es la **omisión de herramienta**: el agente no llama silenciosamente a una herramienta que debería haber llamado, y luego produce una respuesta que parece completa. La tasa de omisión es invisible en las demostraciones y fatal en producción. En una demostración, se muestra el caso de ruta feliz, la salida parece plausible y todos asienten. En producción, "el agente no realizó la verificación de sanciones en el 4 por ciento de los casos" es un hallazgo regulatorio, no una métrica de calidad. La única defensa es medirlo, por lo que el conjunto de oro lleva anotaciones de llamadas a herramientas esperadas. Mi frase habitual en los informes: tasas de omisión medidas, no asumidas. > Si su arnés solo registra lo que dijo el agente, está evaluando un generador de texto que está cerca de algunas herramientas. Registre lo que hizo y lo que no hizo. A partir de las transcripciones (que ya está registrando para el eje de costos), calcule por modelo: - **Recuperación de herramientas**: de las llamadas a herramientas que requiere una ejecución correcta, ¿qué fracción realizó el agente? - **Tasa de omisión por herramienta**: ¿qué herramientas específicas se omiten y en qué clases de escenarios? Las omisiones se agrupan; una herramienta que se omite suele ser aquella cuya descripción no hace obvia su necesidad. - **Tasa de herramienta incorrecta**: el agente llamó a algo, pero no a lo correcto. - **Tasa de argumentos mal formados**: llamadas que fallaron la validación del esquema. - **Precisión de argumentos**: llamadas que pasaron la validación pero contenían valores incorrectos. La taxonomía completa de fallos de herramientas, en el orden en que me preocupan: #### Omisión de herramienta El agente debería haber llamado a una herramienta y no lo hizo, y respondió de todos modos. No se produce ningún error en ninguna parte. La detección requiere anotaciones de llamadas esperadas; nada en el tiempo de ejecución se lo dirá. Este es el modo de fallo que justifica todo el eje. #### Respuesta prematura Una variante sistémica de la omisión: el agente inicia la secuencia requerida, luego decide a mitad del bucle que sabe lo suficiente y emite un veredicto con la secuencia incompleta. Común en casos que parecen rutinarios, que es exactamente cuando los revisores no están prestando atención. Detecte comparando la secuencia de llamadas ejecutadas con el conjunto requerido, no solo verificando que cada herramienta aparece en algún lugar. #### Argumentos alucinados La llamada es válida según el esquema y el tiempo de ejecución la acepta, pero se inventó un valor de argumento en lugar de tomarlo del caso: un identificador de cuenta fabricado, una fecha que los documentos no contienen. Este pasa todas las puertas automáticas y contamina los datos posteriores. La detección necesita valores de oro a nivel de argumento o una verificación puntual de un experto; presupueste para ello. #### Selección de herramienta incorrecta El agente llama a la herramienta de historial de cuentas cuando el caso necesitaba la herramienta de detección. Generalmente un síntoma de descripciones de herramientas superpuestas más que de debilidad del modelo. Detectable automáticamente contra las anotaciones. #### Argumentos mal formados La llamada falla la validación del esquema. Ruidoso, barato de detectar y, en su mayoría, un problema de costo de reintento más que un problema de corrección, siempre que su capa de orquestación realmente valide y reintente. Los modelos que con frecuencia malforman argumentos también resultan caros en el Eje 1, que es cómo los ejes se verifican mutuamente. Aquí está la parte que hace que este eje sea accionable en lugar de fatalista: en mis proyectos, una gran parte de los fallos de fiabilidad de las herramientas se remontaban a las especificaciones de las herramientas, no al modelo. Descripciones vagas, nombres superpuestos, enumeraciones indocumentadas, parámetros cuyo propósito solo es claro para la persona que escribió la API. La corrección de las especificaciones movió las tasas de omisión y de herramienta incorrecta más que el cambio de modelos. Escribí la disciplina del lado de las especificaciones por separado en [la guía de contratos de herramientas](/es/guides/tool-contracts/); el arnés de evaluación es cómo se averigua qué contratos están fallando, y los contratos son cómo se soluciona. ## Eje 4: Sensibilidad a la temperatura Añadí este eje esperando que fuera aburrido. Ejecutar la cuadrícula a unas pocas temperaturas, confirmar que la temperatura cero reduce la varianza de la salida, escribir una diapositiva, seguir adelante. Eso no fue lo que dijeron los datos. A temperatura cero, los modelos que probé no solo se volvieron más consistentes. Se volvieron más exhaustivos con las herramientas: mayor recuperación de herramientas, menores tasas de omisión, en los mismos escenarios con los mismos *prompts*. La temperatura estaba cambiando lo que hacía el agente, no solo la repetibilidad con la que lo hacía. Mi explicación de trabajo es mecánica más que misteriosa: en cada punto de decisión, el modelo sopesa "llamar a una herramienta" frente a "responder con lo que tengo", y el muestreo a mayor temperatura ocasionalmente toma el camino de menor probabilidad, que para un agente bien *prompted* es el más perezoso. A temperatura cero, el camino codicioso incluye más a menudo la llamada a la herramienta. Mantengo esa explicación con flexibilidad; las mediciones las mantengo firmemente. Por qué existe este eje: los clientes regulados piden la temperatura cero por su nombre, y los proveedores la presentan rutinariamente como un control de seguridad. Antes de repetir esa afirmación en un banco, debe saber qué hace realmente la temperatura cero a su agente específico, porque "cambia qué herramientas se llaman" es una afirmación materialmente diferente de "reduce la aleatoriedad". > No le diga a un cliente regulado que la temperatura cero es un control de seguridad hasta que haya medido lo que cambia. En mis ejecuciones, cambió qué herramientas se llamaban. Método: ejecute el conjunto de oro completo a cada temperatura candidata (yo uso 0, un valor bajo como 0.2 a 0.3, y el valor predeterminado del proveedor), con cada escenario repetido varias veces por configuración para que pueda separar la varianza del nivel. Informe los otros tres ejes desglosados por temperatura: precisión, recuperación de herramientas, tasa de omisión y costo por caso, además de la discrepancia entre ejecuciones como medida de varianza. Dos advertencias de campo: algunos modelos de clase de razonamiento ignoran o rechazan el parámetro de temperatura por completo, así que verifique que la configuración se esté aplicando realmente; y los hallazgos de temperatura son por modelo y por proveedor, así que vuelva a medir cuando cualquiera de ellos cambie en lugar de trasladar la conclusión. ## Lo que los números hacen a su arquitectura: enrutamiento de modelos Los cuatro ejes no son un boletín de calificaciones para archivar. Son entradas de enrutamiento. Trace cada modelo candidato como un punto: costo medido por caso en un eje, tasa de campos correctos en el otro. Los puntos trazan una curva de costo-calidad, y la forma de esa curva es la decisión. Se repiten tres formas: - **Curva plana.** El modelo de nivel medio se sitúa con la misma calidad que el modelo *premium* a una fracción del costo. Este fue el hallazgo de tipo KYC: la misma precisión, aproximadamente 1/13 del costo. Decisión: ejecute el modelo de nivel medio, mantenga el modelo *premium* como objetivo de escalada y ahorre la diferencia. Las curvas planas son comunes en tareas de extracción y seguimiento de reglas con buenos contratos de herramientas. - **Curva de acantilado.** La calidad cae bruscamente por debajo de un cierto nivel de modelo. Común en tareas que requieren un juicio genuino de varios pasos o síntesis a través de muchos documentos. Decisión: pague por el nivel por encima del acantilado; no deje que compras le convenzan de bajar de él. - **Curva de pagar por nada.** El modelo *premium* es más caro y no es mejor, a veces peor en la recuperación de herramientas (los modelos más grandes no son agentes uniformemente mejores; mida, no asuma). Decisión: obvia. La consecuencia más profunda es el enrutamiento por paso. Un agente incrustado en el proceso no es una decisión de un solo modelo; es una decisión por paso, porque la capa de orquestación (Camunda en mis construcciones, pero Temporal, LangGraph o un bucle de Node.js hecho a mano le dan la misma costura) vincula un modelo a cada tarea de forma independiente. Eso permite la filosofía multimodelos que ahora aplico en cada proyecto: - **Dimensionar correctamente cada paso.** Los pasos de extracción y clasificación de documentos van al modelo de nivel medio que la evaluación demostró ser suficiente. El único paso que requiere sopesar evidencia contradictoria obtiene el modelo *premium*. Ejecute el arnés por paso, no solo por proceso. - **Enrutar al *premium* por señal, no por defecto.** Una baja confianza reportada por el modelo, un fallo en la validación del esquema o una clase de caso difícil identificada por el conjunto de oro pueden enrutar una instancia al modelo *premium*, o a un humano. La decisión de escalada reside en la definición del proceso, donde es visible y auditable, no enterrada en un *prompt*. - **El modelo más barato es ningún modelo.** Si el comportamiento medido por la evaluación de un paso es reproducible por un motor de reglas o una búsqueda, elimine el LLM de ese paso por completo. La evaluación es a menudo cómo se descubre esto: cuando un modelo obtiene un 100 por ciento en un paso en todos los niveles, ese paso probablemente no necesitaba un modelo. El costo por caso a nivel de proceso se convierte entonces en una suma ponderada sobre los pasos, y puede responder a la segunda pregunta de la sala ("¿cuánto costará por caso?") con un número que tiene barras de error en lugar de un encogimiento de hombros. ## Ejecución continua de evaluaciones La primera ejecución del arnés responde "¿qué modelo?". Cada ejecución posterior responde a una pregunta más importante: "¿acabamos de romperlo?" Un agente incrustado en el proceso tiene al menos cinco superficies de cambio, y cada una de ellas puede mover silenciosamente los cuatro ejes: 1. **Ediciones de *prompts*.** El ajuste inocente de la redacción que reduce la recuperación de herramientas en diez puntos. He visto una "clarificación" de *prompt* de una sola frase duplicar una tasa de omisión. 2. **Cambios en las especificaciones de la herramienta.** Renombrar un parámetro, añadir una herramienta, ajustar una descripción. Cualquiera de estos cambios lo que el modelo selecciona y cómo argumenta con el esquema. 3. **Actualizaciones de versión del modelo.** Actualizaciones deliberadas. Nunca asuma que la nueva versión domina a la antigua en los cuatro ejes; verifique la recuperación de herramientas en particular. 4. **Deriva del proveedor.** El mismo alias de modelo comportándose de manera diferente después de una actualización del lado del proveedor de la que no se le informó. Fije versiones exactas del modelo donde el proveedor lo permita; donde no, una nueva ejecución programada del arnés es su detector de deriva. 5. **Cambios de configuración.** Temperatura, límites de tokens, políticas de reintento. El Eje 4 existe porque estos no son neutrales. Así que trate el arnés como una suite de regresión. Versionar el conjunto de oro en el mismo repositorio que los *prompts* y las especificaciones de las herramientas. Selle cada ejecución de evaluación con un *hash* de configuración que cubra la versión del *prompt*, la versión de la especificación de la herramienta, el identificador del modelo y la temperatura, para que cualquier puntuación sea reproducible y cualquier regresión sea biseccionable. Controle los cambios de la misma manera que controla el código: una edición de *prompt* que reduce la recuperación de herramientas debería fallar la revisión antes de llegar a producción, y el informe de evaluación es el artefacto de revisión. Esto es asequible porque el conjunto de oro es pequeño. Veinte escenarios, tres repeticiones, un modelo: eso es una ejecución de "pausa para el café", lo suficientemente barata como para adjuntarla a cada cambio significativo en lugar de guardarla para evaluaciones trimestrales. La disciplina de 10 a 30 escenarios del Eje 2 no se trata solo de la calidad de las etiquetas; es lo que hace que la evaluación continua sea económicamente aburrida, que es lo que hace que realmente suceda. ## Lo que este método no resuelve La sección de honestidad, porque un método en el que confía más allá de sus límites es peor que ningún método. **Los conjuntos de oro caducan.** El proceso cambia, los formatos de documentos cambian, la regulación cambia, y el conjunto de oro deja silenciosamente de representar la producción. Un conjunto de oro es una instantánea del proceso en el momento de su elaboración. Revíselo cada vez que se revise el propio proceso y retire los escenarios que ya no se producen. Un arnés que puntúa en verde contra los casos del año pasado es un falso consuelo. **Una n pequeña le da clasificaciones, no certificaciones.** De diez a treinta escenarios clasificarán modelos de forma fiable y detectarán grandes regresiones. No respaldará un "94.2 por ciento de precisión" en un documento de auditoría; el intervalo de confianza en 20 casos es amplio, y pretender lo contrario es una mala práctica. Utilice el arnés para decisiones de ingeniería. Si una función de cumplimiento necesita un número de precisión certificado, eso es un ejercicio de muestreo más grande y gobernado por separado. **El LLM-como-juez conlleva sesgos conocidos.** El sesgo de verbosidad, el sesgo de posición y la auto-preferencia (un modelo que califica favorablemente la salida de su propia familia) están todos documentados. Por eso el método impulsa la calificación hacia verificaciones deterministas por campo, lo que las salidas estructuradas hacen posible. Donde un juez es inevitable (justificaciones de texto libre), use un modelo de una familia diferente a cualquier candidato bajo prueba, una rúbrica fija y verificaciones periódicas de acuerdo humano. Y mantenga las puntuaciones del juez fuera de los números principales. **Las evaluaciones se sobreajustan como todo lo demás.** Si ajusta los *prompts* contra el conjunto de oro durante semanas, está enseñando para el examen, y la puntuación deja de predecir la producción. Reserve algunos escenarios que nunca informen cambios en los *prompts*, y rote casos reales nuevos a medida que lleguen. Cuando la puntuación reservada y la puntuación de desarrollo diverjan, crea la puntuación reservada. **Cuatro ejes no son todos los ejes.** Este método no dice nada sobre la robustez adversarial, la inyección de *prompts* a través de los resultados de las herramientas, la memoria a largo plazo o la calidad de las transferencias de humano en el bucle. Esos necesitan sus propias evaluaciones. Los cuatro ejes fueron los que respondieron a las preguntas que las empresas realmente me hicieron; son un piso, no un techo. ## La versión de un párrafo Las evaluaciones de la era de los chatbots no pueden decirle qué modelo debe ejecutar un agente incrustado en un proceso gobernado, así que mida el agente de la manera en que la empresa lo experimentará: construya un conjunto de oro de 10 a 30 casos reales anonimizados con salidas esperadas por campo y llamadas a herramientas esperadas, luego puntúe cada modelo candidato en cuatro ejes: costo por instancia de proceso (cada iteración de bucle, reintento e ida y vuelta de herramienta, reportado por caso, donde un modelo de nivel medio una vez igualó a un modelo *premium* a aproximadamente 1/13 del costo), precisión por campo contra las etiquetas de oro (coincidencia determinista, no sensaciones), fiabilidad de la herramienta (tasas de omisión, selección de herramienta incorrecta y argumentos mal formados o alucinados, medidos en lugar de asumidos, porque una verificación de cumplimiento omitida silenciosamente es invisible en una demostración y fatal en producción), y sensibilidad a la temperatura (la temperatura cero cambió la exhaustividad de la herramienta en mis ejecuciones, no solo la varianza, así que mida antes de llamarlo un control de seguridad). Alimente las curvas de costo-calidad resultantes en el enrutamiento de modelos por paso, vuelva a ejecutar el arnés como una suite de regresión en cada cambio de *prompt*, herramienta y modelo, y mantenga los resultados con flexibilidad donde el método es débil: los conjuntos de oro pequeños clasifican modelos pero no los certifican, y los conjuntos de oro caducan. ## Referencias - Anthropic, "Crear evaluaciones empíricas sólidas": [docs.anthropic.com/en/docs/build-with-claude/develop-tests](https://docs.anthropic.com/en/docs/build-with-claude/develop-tests) - Anthropic, "Construyendo agentes efectivos": [anthropic.com/engineering/building-effective-agents](https://www.anthropic.com/engineering/building-effective-agents) - OpenAI, guía de "Evals": [platform.openai.com/docs/guides/evals](https://platform.openai.com/docs/guides/evals) - Zheng et al., "Juzgando LLM-como-juez con MT-Bench y Chatbot Arena" (el tratamiento canónico de los sesgos del juez): [arxiv.org/abs/2306.05685](https://arxiv.org/abs/2306.05685) - Yao et al., "τ-bench: Un *benchmark* para la interacción Agente-Herramienta-Usuario en dominios del mundo real": [arxiv.org/abs/2406.12045](https://arxiv.org/abs/2406.12045) - Tabla de clasificación de llamadas a funciones de Berkeley, para comparaciones públicas de llamadas a herramientas (contexto útil, no un sustituto de su propio conjunto de oro): [gorilla.cs.berkeley.edu/leaderboard.html](https://gorilla.cs.berkeley.edu/leaderboard.html) - Hamel Husain, "Su producto de IA necesita evaluaciones": [hamel.dev/blog/posts/evals](https://hamel.dev/blog/posts/evals/) - Guía complementaria sobre el lado de las especificaciones de la fiabilidad de las herramientas: [Contratos de herramientas](/es/guides/tool-contracts/) - Este método se extrajo del trabajo de prueba de valor en producción con grandes instituciones financieras; los proyectos están generalizados y ningún código de evaluación de clientes es público.