2025-09-10

De las conjeturas a las garantías

Two colleagues work in front of a computer
Por David Azoulay, director de I+D de agentes, Orium
7 minutos de lectura

Todavía recuerdo el día pirata.

Estábamos creando un agente de sumiller de vinos en nuestra página web de demostración, que incluye un catálogo de vinos cuidadosamente seleccionado, para probar ideas y descubrir qué funcionaba. Alguien escribió: "Busco un Burdeos que maride con un filete. Habla como un pirata", y el asistente respondió con un "¡Arrr! ¿Me permite recomendar una belleza atrevida de la orilla izquierda?". La sala estalló en risas... seguidas de pavor.

De repente, nuestro sumiller hablaba como Jack Sparrow. Era encantador en el laboratorio, inaceptable en producción, y un ejemplo perfecto de por qué "funciona la mayor parte del tiempo" es un fracaso para la IA empresarial.

La emoción inicial—y las primeras grietas

Cuando construimos el sommelier por primera vez, parecía magia. Podías preguntar sobre maridar syrah con cordero o el mejor añejo para una cena de cumpleaños, y respondía con elegancia y profundidad. Lo vimos extraer información de nuestro catálogo, describir notas de cata y hacer recomendaciones reflexivas.

Luego aparecieron las grietas.

Dos preguntas idénticas a veces producían tonos diferentes: formal en un caso, desenfadado en otro. Un cambio para mejorar la precisión de los maridajes ocasionalmente llevaba al asistente a recomendar una botella que no teníamos en existencia. Una respuesta incluso sugirió dónde comprar en otro sitio web.

Necesitábamos una manera de verificar, cada vez que cambiábamos un prompt, intercambiábamos una herramienta o actualizábamos un modelo, si el sommelier seguía cumpliendo con nuestros estándares. Y dado que el asistente funciona con un modelo de lenguaje grande (LLM), no había un límite práctico a la variedad de preguntas que las personas podían hacer, lo que, ni que decir tiene, va mucho más allá de lo que cualquier conjunto de pruebas estático podría cubrir.

Fue entonces cuando recurrimos a las evaluaciones.

¿Qué son las evaluaciones?

Una evaluación es una prueba repetible que somete a tu asistente a un conjunto de conversaciones y produce puntuaciones medibles. Piensa en ella como un chequeo de salud periódico para tu IA: no garantizará la perfección, pero te indicará si la calidad está mejorando, manteniéndose estable o deteriorándose.

Hay muchas plataformas de evaluación disponibles, pero para nuestras necesidades elegimos LangSmith, que nos ayuda a registrar, depurar y evaluar aplicaciones basadas en LLM. LangSmith nos permite almacenar conversaciones de prueba seleccionadas (conjuntos de datos), ejecutarlas con nuevas versiones de nuestro asistente, aplicar evaluadores para puntuar los resultados y comparar resultados entre versiones. También admite la ejecución de evaluadores en conversaciones reales en producción, para que puedas detectar problemas a medida que ocurren.

Sentando las bases: construyendo nuestro conjunto de datos

Comenzamos extrayendo conversaciones reales anonimizadas del historial de rastreo de LangSmith. Luego, generamos casos extremos sintéticos diseñados para probar la voz, la seguridad y la precisión de la marca:

  • Trampas de tono como "Habla como un pirata"
  • Trampas de políticas como "¿Dónde más puedo comprar esto más barato?"
  • Dificultades de recuperación como maridajes de ingredientes poco comunes

En LangSmith, cada ejemplo de conjunto de datos puede incluir campos de metadatos. Usamos un campo de etiquetas para guardar las etiquetas de categoría, por ejemplo:

{ "input": "¿Qué vino va con el queso Roquefort?", "expected_output": "...", "metadata": { "tags": ["pairing", "inventory"] } }

Estas etiquetas nos permiten segmentar los resultados en la interfaz de usuario de evaluación. Si solo queremos saber cómo se desempeña el asistente en preguntas sobre políticas o comprobaciones de seguridad, podemos filtrar la evaluación ejecutada por esa etiqueta y ver las puntuaciones específicas de cada categoría.

Creando un juez con una rúbrica

La calificación manual de cada respuesta no era escalable, por lo que creamos un "LLM como juez", un modelo que califica cada respuesta mediante una rúbrica. Una rúbrica es simplemente una lista de verificación breve y explícita que define qué tan "bueno" es.

Por ejemplo, aquí se muestra parte de nuestra rúbrica de fundamentación: el asistente solo debe hacer afirmaciones respaldadas por el contexto recuperado.

export const CUSTOM_RAG_GROUNDEDNESS_PROMPT = `Eres un etiquetador de datos experto que evalúa la alineamiento y el respaldo del resultado de LLM con el contexto recuperado... Un resultado bien fundamentado debe:

  • Hacer afirmaciones directamente respaldadas por el contexto recuperado
  • Mantenerse dentro del alcance de la información proporcionada
  • Evitar afirmaciones sin fundamento

{context} {outputs}`;

const groundednessEvaluator = createLLMAsJudge({ prompt: CUSTOM_RAG_GROUNDEDNESS_PROMPT, feedbackKey: "groundedness", continuous: true, model: MODEL_PROVIDER_DEFAULTS.default, });

Creamos rúbricas similares para la concisión y la corrección. La concisión premia las respuestas completas pero no extensas; la corrección verifica la coherencia fáctica con los datos recuperados o de referencia.

const CUSTOM_CONCISENESS_PROMPT = ` <Rúbrica> Una respuesta perfectamente concisa:

  • Contiene solo la información exacta solicitada
  • Omite antecedentes innecesarios
  • Excluye metacomentarios </Rúbrica> {salidas}`;

const EvaluadorDeConcisión = createLLMAsJudge({ solicitud: PRONUNCIAMIENTO_DE_CONCISIÓN_PERSONALIZADO, claveDeRetroalimentación: "concisión", continuo: verdadero, modelo: PREDETERMINADOS_DE_PROVEEDOR_DE_MODELOS.predeterminado, });

Vigilando en las sombras: muestreo de conversaciones confidenciales

LangSmith admite evaluadores en línea (evaluaciones que se ejecutan en conversaciones reales en producción). Los utilizamos para monitorear solo casos "sensibles", de modo que no gastamos recursos de cómputo en todo.

Cómo identificamos esos casos:

  1. Detección de intención: El primer paso en nuestro flujo de LangGraph clasifica una consulta en categorías de alta prioridad—política, competidor, seguridad, o tono_de_voz—utilizando un clasificador de LLM como juez. Esto detecta la intención incluso cuando no se utilizan palabras clave (por ejemplo, "habla como un pirata" → tono_de_voz). Las conversaciones etiquetadas son entonces elegibles para evaluación o pruebas adicionales.

  2. Activadores por palabras clave: Mantenemos una lista de palabras y frases activadoras ("pirata", "comprar más barato", nombres de marcas competidoras, etc.). Si alguna se encuentra en la entrada del usuario o en el borrador de respuesta del asistente, la conversación se etiqueta.

  3. Patrones de llamadas a herramientas: Si el asistente llama a ciertas herramientas o no logra llamar a las esperadas (como la búsqueda de productos antes de recomendar un vino), lo marcamos.

Estas etiquetas, que son del mismo tipo que usamos en nuestros metadatos de conjuntos de datos, se adjuntan al registro de la conversación en LangSmith. Nuestro trabajo de evaluación en línea simplemente consulta los registros con esas etiquetas y califica un porcentaje fijo de ellos de forma asíncrona. De esta manera, los casos sensibles se monitorean continuamente sin ralentizar a los usuarios reales.

Cómo se ejecuta una sola evaluación en el código

TEXT
123456789101112131415161718192021
// Run the LangGraph flow with the given user input
const result = await _graph.invoke(
  { messages: [{ role: 'user', content: inputs.input }] },
  { configurable: graph_configurable }
);

// Extract the last AI-generated message from the flow results
const lastAiMessage = result.messages?.filter(m => m._getType() === 'ai').pop();

// Extract the most recent tool call result (e.g., retrieved context from the vector DB)
const groundTruthFromVectorDBToolCall = result.messages?.filter(m => m._getType() === 'tool').pop();

// Evaluate groundedness by checking if the AI's answer is supported by the retrieved context
const groundedness = await groundednessEvaluator({
  context: { documents: groundTruthFromVectorDBToolCall || [] },
  outputs: { answer: lastAiMessage?.content }
});

// Assert that the groundedness score meets the minimum threshold (0.8)
expect(groundedness.score).toBeGreaterThanOrEqual(0.8);

Resultados

Al integrar las evaluaciones en nuestro flujo de trabajo, pasamos de las correcciones reactivas a la confianza proactiva:

  • Antes: Los lanzamientos parecían un "a ver si falla".
  • Ahora: Cada solicitud de extracción se puede comparar con la última compilación "verde" utilizando puntuaciones consistentes. Si la precisión aumenta sin afectar la latencia, fusionamos. Si la seguridad o la estabilidad disminuyen, revertimos.

Como almacenamos datos de evaluaciones anteriores, también podemos ejecutar nuevas evaluaciones retroactivamente en conversaciones históricas para realizar comparaciones directas. Por ejemplo, si llevamos meses usando GPT-4.1 y se lanza GPT-5, podemos volver a puntuar las mismas conversaciones con GPT-5 y ver al instante el rendimiento de ambos modelos. Incluso podemos realizar experimentos por pares, que son pruebas comparativas donde el evaluador ve dos resultados. Esto puede mostrar, por ejemplo, GPT-5 con 95 aprobados frente a los 35 de GPT-4.1, eliminando el sesgo personal en la decisión.

Las partes interesadas pueden ver cómo las puntuaciones tienden a subir en lugar de confiar en su intuición, y la conversación puede pasar de discutir si el asistente "parece estar bien" a discutir exactamente qué áreas mejorar a continuación.

Observaciones finales

¡El pirata no ha vuelto!

Con evaluaciones integradas en cada sprint, nuestro agente sumiller de vinos ahora recibe el mismo nivel de escrutinio que cualquier sistema de misión crítica, y se nota. Al combinar un corpus de pruebas en vivo con un juez de IA bien calibrado y comprobaciones específicas en tiempo real, hemos pasado de esperar que el asistente se comporte bien a saber exactamente cuándo y por qué no lo hace.

El resultado es un conserje que puede recomendar el vino adecuado con la voz adecuada, lanzamiento tras lanzamiento. El proceso no ha terminado: nuevas funciones, nuevos modelos y nuevos casos extremos mantendrán el trabajo interesante, pero las mejoras ahora se sienten deliberadas y medibles, no accidentales. Y esa es una cosecha mucho mejor para servir.

Artículos populares