Capítulo 10 — Frameworks de evaluación líderes

Décima entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. En el que la tríada recibe una caja de herramientas — ocho frameworks en dos sabores — y una admisión honesta sobre la parte de la evaluación que ninguno resuelve todavía.

Por qué existe este capítulo

La tríada del Capítulo 9 dijo qué medir. No dijo nada sobre cómo correr esas mediciones en producción. Las métricas son conceptos. Sus implementaciones son prompts para el juez, lógica de descomposición de afirmaciones, elecciones de embedding para similitud, estrategias de muestreo por coste, dashboards, alertas y bucles de revisión humana. Ningún equipo construye todo esto desde cero.

Los frameworks se han dividido a lo largo de un eje reconocible. De un lado, las librerías metric-first — RAGAS, TruLens, DeepEval — que computan la tríada con metodología documentada y reproducible. Del otro, las plataformas de observabilidad — Braintrust, LangSmith, Phoenix, Galileo, Opik — que parten de las trazas de producción e integran la evaluación como una funcionalidad dentro de un flujo de trabajo mayor. Elegir entre ellas es menos una comparación de funcionalidades que una pregunta sobre qué necesita el equipo que haga el sistema el día siguiente al lanzamiento.

10.1 Las librerías metric-first — RAGAS, TruLens, DeepEval

RAGAS es lo más parecido a una implementación de referencia de la tríada que tiene el campo. Conjunto conservador de métricas, prompts documentados, cada llamada al LLM expuesta. La pipeline de Faithfulness es una cadena de dos etapas — descompón la respuesta en afirmaciones, comprueba cada afirmación contra el contexto — y la lista intermedia de afirmaciones vuelve en el resultado, así que un ingeniero puede señalar la afirmación concreta que el framework decidió que no estaba sustentada. Para investigación, sectores regulados o cualquier equipo que necesite defender su metodología, RAGAS es el valor por defecto. El coste es que se siente académico. Computa métricas; no envía un dashboard.

TruLens se sitúa entre librería de métricas y plataforma de observabilidad. Su énfasis es la instrumentación: el framework envuelve la aplicación a nivel de función, capturando cada llamada de recuperación y cada respuesta del modelo en una Traza estructurada, y luego corre la tríada contra las trazas. Las métricas de la tríada se exponen como funciones de feedback — unidades pequeñas y componibles, fáciles de escribir las tuyas. TruLens es la elección correcta cuando las necesidades de evaluación del equipo van más allá del conjunto estándar, o cuando el flujo de trabajo se centra en inspeccionar fallos individuales en vez de dashboards agregados.

DeepEval adopta una tercera postura: evaluación como pytest. Los casos de prueba se escriben y corren con una CLI tipo pytest; los fallos bloquean el PR; el conjunto de métricas es el más amplio de los tres, incluyendo sesgo, toxicidad y comprobaciones de alucinación además de la tríada. El compromiso es que la amplitud viene con un rigor irregular. Coge una métrica del menú sin leer su implementación y puedes acabar reportando números que no significan lo que crees. La disciplina correcta es elegir un conjunto pequeño, leer los prompts, calibrar contra etiquetas a mano y tratar el resto como inspiración.

10.2 Las plataformas de observabilidad — Braintrust, LangSmith, Phoenix, Galileo, Opik

Las librerías metric-first responden a "cómo computo la tríada". Las plataformas de observabilidad responden a "cómo corro un sistema RAG en producción". Parten del supuesto de que el equipo va a estar escribiendo prompts, comparando versiones de modelo, ingiriendo trazas y vigilando dashboards en el futuro previsible. La evaluación es una funcionalidad; el versionado de prompts, la exploración de trazas, los tests A/B y las alertas son una parte igual del valor.

Braintrust destaca por la experiencia de desarrollador — el experiment, un registro versionado del comportamiento del modelo sobre un dataset, con diffs de puntuación lado a lado en una UI genuinamente agradable. LangSmith es la elección natural para equipos ya metidos a fondo en LangChain; espera estar en el centro de la instrumentación de la aplicación y recompensa ese compromiso con profundidad. Phoenix, de Arize, es la opción open-source, distinguida por el análisis de deriva y clustering de embeddings que las otras subestiman — viable para equipos que no pueden enviar trazas a un endpoint SaaS. Galileo es la plataforma orientada a empresa, con una puntuación de Correctness propietaria y despliegue on-prem para sectores regulados. Opik, de Comet, es el entrante más reciente, open-source-first como Phoenix, pulida como Braintrust, con la ventaja añadida de unificar la observabilidad de LLM y la de ML clásico bajo una sola plataforma.

La elección entre las cinco va menos de funcionalidades que de encaje organizativo. Equipo LangChain tira de LangSmith. Equipo de producto greenfield tira de Braintrust. Equipo open-source-first tira de Phoenix. Empresa regulada tira de Galileo. Equipo Comet tira de Opik. La calidad de las métricas en las cinco es ampliamente comparable — todas implementan la tríada, todas usan LLM-como-Juez, todas arrastran las mismas limitaciones fundamentales que nombró el Capítulo 9. Las diferencias son flujo de trabajo, no medición.

10.3 El Hueco de Evaluación y el patrón de tres bucles

Aquí va el hecho incómodo que el tour de frameworks acaba de obviar. Casi todas las herramientas de arriba evalúan en la capa de inferencia: dado que la recuperación ya ocurrió, ¿honró el modelo los chunks, encajó la respuesta con la pregunta, estaban los chunks en tema? Ninguna, en ningún sentido profundo, te dice si la recuperación encontró los chunks correctos para empezar. La salida del retriever es la entrada de la capa de inferencia, y las métricas de la capa de inferencia miden la salida pero no la entrada. Si la recuperación se pierde sistemáticamente un documento importante, la Fidelidad se queda alta (el modelo honró lo que recibió), la Relevancia de la Respuesta se queda alta (la respuesta encajó con la forma de la pregunta) y los usuarios reciben de todos modos la respuesta equivocada.

Este es el Hueco de Evaluación. La razón estructural es que la evaluación en capa de inferencia es sin referencia, mientras que la evaluación rigurosa en capa de contexto necesita saber cuáles eran los chunks correctos — lo cual requiere o un conjunto etiquetado o uno sintético. Los rodeos — generación de preguntas sintéticas, sondas tipo aguja-en-el-pajar, proxies de impacto aguas abajo, auditoría de recuperación condicionada por consulta, recuperación contra uno mismo — son todos útiles y todos incompletos. El resumen honesto es que la evaluación en capa de contexto es la frontera abierta y los equipos deberían esperar invertir parte de su propia ingeniería directamente en la calidad de recuperación. Los frameworks ayudan con el bucle de inferencia; dejan el bucle de recuperación en gran parte al equipo.

El patrón hacia el que convergen los equipos maduros son tres bucles, no uno. Bucle interior: una librería metric-first (típicamente RAGAS o DeepEval) corre la tríada sobre un conjunto de regresión fijo en cada cambio significativo, rápido y determinista, orientado a captar regresiones. Bucle exterior: una plataforma de observabilidad maneja almacenamiento de trazas de producción, cómputo de métricas online sobre tráfico muestreado, dashboards y alertas — orientada a la deriva que el conjunto de regresión se perderá. Bucle lento: una función pequeña de revisión humana calibra los jueces LLM, audita trazas marcadas y mantiene el conjunto de regresión a medida que el producto evoluciona. Un equipo con sólo el bucle interior envía producción que deriva. Un equipo con sólo el bucle exterior ve la deriva pero no puede depurarla. Un equipo con ambos pero sin revisión humana confía en jueces que en silencio se están torciendo. Los tres son necesarios, y el valor de los frameworks es cuánto de cada bucle hacen fácil.

Lo que prepara el Capítulo 10

Entre la tríada del Capítulo 9 y los frameworks del Capítulo 10, un equipo tiene lo que necesita para medir un sistema RAG: un vocabulario, una rendición de cuentas honesta de lo que el vocabulario se deja fuera, y un pequeño conjunto de herramientas que convierte las mediciones en dashboards. El sistema será legible. Pero la medición es sólo la mitad de la historia de producción. Un sistema que se mide pero no se mantiene se degradará igualmente, porque los documentos cambian, los usuarios cambian y los modelos subyacentes cambian. Saber que la calidad ha caído no es lo mismo que poder restaurarla.

Próximamente — Capítulo 11: Actualizaciones continuas y optimización de la pipeline. CDC e indexación incremental, caché semántica y estratificación de modelos, y el bucle de feedback de cuatro etapas que convierte la telemetría de producción en la clase de sistema que de verdad mejora cuanto más tiempo lleva en marcha.