¿Tu RAG funciona de verdad? Evaluar sistemas de IA en producción

La pregunta que no puedes responder

Seamos directos: la mayoría de los equipos que operan un sistema RAG o un agente de IA en producción no pueden responder una pregunta simple. ¿Es bueno? Tienen una demo que impresionó a alguien, unos cuantos ejemplos escogidos a mano y una vaga sensación de que los usuarios parecen contentos. Eso no es evaluación, es esperanza. Y la esperanza no te dice si el cambio de la semana pasada mejoró las cosas o las empeoró en silencio.

Evaluar IA es más difícil que evaluar software tradicional porque rara vez hay una única salida correcta. Una recuperación puede ser parcialmente correcta, una respuesta puede ser plausible pero errónea, y la misma entrada puede producir salidas distintas. Pero más difícil no significa imposible. Mides la calidad de la IA igual que mides cualquier cosa que no puedes juzgar a ojo: construye un conjunto de pruebas, define métricas, puntúa contra ellas y vigila los números en el tiempo. Esta guía te enseña cómo.

Si no puedes decir si tu IA mejoró o empeoró después de un cambio, no estás operando un sistema, estás esperando lo mejor de uno. La evaluación es lo que convierte la esperanza en ingeniería.

Construimos IA medible, y ejecutamos confidence scoring y un bucle de revisión en nuestra propia plataforma Exfinity. Esta guía es esa disciplina. Para la arquitectura de recuperación en sí, mira nuestra guía de sistemas RAG empresariales, y esto es trabajo central de nuestros servicios de IA.

A quién le importa qué

Dos tipos de evaluación

Hay dos modos, y necesitas ambos.

La evaluación offline corre contra un conjunto de pruebas fijo, antes de lanzar. Tienes preguntas conocidas y buenas respuestas conocidas, y puntúas el sistema contra ellas. Es tu gate de regresión: te dice si un cambio ayudó o perjudicó antes de que los usuarios reales lo sientan.

La evaluación online corre contra tráfico real, después de lanzar. Los usuarios reales preguntan cosas inesperadas, y mides cómo le va al sistema en la vida real mediante puntuaciones de confianza, feedback y resultados. Esto atrapa lo que tu conjunto de pruebas no anticipó.

El error es hacer solo uno. Solo offline se pierde lo que los usuarios reales preguntan de verdad. Solo online significa que encuentras las regresiones después de que golpean a los clientes. Nuestra guía de observabilidad de IA cubre el lado online en profundidad.

Construye primero el conjunto de pruebas

Todo empieza con un conjunto de pruebas: preguntas representativas emparejadas con cómo se ve una buena respuesta. Es lo de mayor apalancamiento que puedes construir, porque sin él toda evaluación es subjetiva.

Un buen conjunto de pruebas no son cien preguntas fáciles. Es una mezcla deliberada.

1. Casos comunes. Las preguntas que los usuarios realmente hacen más.
2. Casos difíciles. Preguntas ambiguas, de varias partes o límite donde el sistema probablemente tropiece.
3. Fallos conocidos. Cada bug que hayas encontrado alguna vez, añadido como comprobación de regresión permanente.
4. Casos adversariales. Preguntas diseñadas para provocar alucinación o fuga de datos.

Mantenlo bajo control de versiones, hazlo crecer cada vez que encuentres un fallo nuevo y córrelo con cada cambio. Esto convierte "creo que está mejor" en "el recall subió dos puntos y nada retrocedió". Nuestra guía de prototipo a producción cubre cómo construir esto desde el principio.

Mide recuperación y generación por separado

Una respuesta RAG puede ser mala por dos razones muy distintas: la recuperación trajo los documentos equivocados, o la recuperación estuvo bien y el modelo escribió una mala respuesta a partir de buenos documentos. Si solo mides la respuesta final, no puedes saber cuál fue, y no puedes arreglar lo que no puedes localizar.

Mide las dos etapas por separado.

Cuando la calidad cae, esta separación te dice dónde mirar. Métricas de recuperación a la baja significa arreglar chunking, embeddings o búsqueda híbrida, cubierto en nuestra guía de arquitectura de búsqueda vectorial. Métricas de generación a la baja con buena recuperación significa arreglar el prompt o el modelo. Nuestra guía de fiabilidad de RAG en producción cubre los modos de fallo.

Un ejemplo práctico: una entrada del conjunto de pruebas

Haz la evaluación concreta con un solo caso de prueba, porque toda la disciplina se construye a partir de estos.

Una entrada del conjunto de pruebas es una pregunta, los documentos que deberían recuperarse y lo que contiene una buena respuesta.

Question:        "What is the cancellation policy for same-day tours?"
Should retrieve: policy-doc-cancellations (chunk 3)
Good answer:     states same-day tours are non-refundable, cites the policy

Ahora ejecuta un cambio, digamos una nueva estrategia de chunking, y puntúa el sistema contra ella.

Retrieval:   was the right chunk in the top k?        yes  -> recall ok
Rank:        where did it land?                        rank 1 -> good
Faithfulness: did the answer stick to the chunk?       yes -> no invention
Relevance:   did it actually answer the question?      yes
Attribution: did it cite the source?                   yes

Un caso en verde no prueba nada. Cien de estos, abarcando preguntas comunes, difíciles, cada bug pasado e intentos adversariales, te dan un número: este cambio subió el recall de recuperación dos puntos y nada retrocedió, o rompió en silencio el caso del tour del mismo día que antes pasaba. Esa es la diferencia entre "se siente mejor" y "esto es lo que cambió". Cada bug que encuentres se convierte en una entrada permanente aquí, para que el mismo error no pueda volver sin ser visto. Nuestra guía de sistemas RAG empresariales cubre el ajuste de la recuperación que estas métricas miden.

Confidence scoring: evaluación que corre en vivo

Las métricas offline necesitan respuestas conocidas. En producción no las tienes, así que necesitas una señal que el sistema pueda calcular en cada respuesta sin una verdad de referencia. Esa señal es una puntuación de confianza.

Una puntuación de confianza práctica es un compuesto de factores que puedes medir en tiempo de ejecución. En Exfinity, cada respuesta se puntúa en cuatro: si la recuperación devolvió resultados útiles, si la respuesta pasó las comprobaciones de política, si es sustancial en lugar de un esbozo, y si hubo suficiente profundidad de conversación para fundamentarla.

confidence = retrieval * 0.4      // ¿las herramientas devolvieron resultados útiles?
           + policy * 0.2         // avisos de validación
           + completeness * 0.2   // sustancial, no un esbozo
           + memory * 0.2         // suficiente contexto para estar fundamentado

Una respuesta por debajo de un umbral se marca como de baja confianza y se enruta a revisión humana antes de confiar en ella, y el sistema clasifica por qué fue baja: un fallo de recuperación, un bloqueo de política, una señal de alucinación como una fecha pasada presentada como actual. Esto te da una señal de calidad en vivo en cada respuesta, no solo en tu conjunto de pruebas. Es evaluación que corre en producción, continuamente.

Cierra el bucle: revisión que mejora el sistema

Una puntuación de confianza que solo marca problemas es una luz de advertencia. Una puntuación de confianza cableada a un bucle de revisión es un sistema que mejora.

Cuando una respuesta es de baja confianza, un humano la revisa. Si la respuesta debería haber sido buena, la respuesta aprobada se reinyecta en la base de conocimiento, para que la misma pregunta recupere una buena respuesta la próxima vez. En Exfinity, este bucle de autoaprendizaje incluso ajusta su propio umbral: si los revisores aprueban casi todo lo marcado, el umbral baja para atrapar más; si rechazan mucho, sube para recortar ruido. El sistema mejora de forma medible por ser usado, en lugar de solo acumular. Este es el patrón human in the loop aplicado a la calidad misma, y conecta con los patrones de memoria de nuestra guía de memoria de agentes.

Conviértelo en un gate, no en un informe

La evaluación que produce un informe que nadie lee no cambia nada. La evaluación que condiciona un despliegue lo cambia todo. Cablea tu conjunto de pruebas offline en la pipeline para que un cambio que baje la calidad por debajo del listón haga fallar el build, igual que lo hace un test unitario que falla.

Este es el cambio de "evaluamos a veces" a "no podemos lanzar una regresión". Es la práctica que más separa a los equipos cuya calidad de IA mejora de los equipos cuya calidad deriva. Nuestra guía de observabilidad de IA cubre cómo cablear las métricas online en las alertas de la misma manera.

Cómo empezar

1. Construye un conjunto de pruebas. Casos comunes, difíciles, de fallos conocidos y adversariales. Versiónalo.
2. Separa las métricas. Mide recuperación y generación por separado para saber dónde mirar.
3. Añade una puntuación de confianza. Una señal en vivo en cada respuesta, con un umbral de revisión.
4. Cierra el bucle. Enruta la baja confianza a revisión humana, reinyecta las buenas respuestas.
5. Condiciona el despliegue. Haz fallar el build ante una regresión de calidad, no solo ante un test roto.

Esto es por etapas y encaja con nuestra metodología. Nuestros equipos de software a medida y consultoría construyen IA medible. Empieza en contacto o consigue un presupuesto acotado.

Formas comunes en que esto sale mal

1. Sin conjunto de pruebas. Toda evaluación es subjetiva. Construye uno y versiónalo.
2. Medir solo la respuesta final. No puedes saber si falló la recuperación o la generación. Sepáralas.
3. Solo offline o solo online. Offline se pierde las preguntas reales, online encuentra las regresiones tarde. Haz ambos.
4. Una puntuación de confianza sin bucle. Marcar sin arreglar no cambia nada. Enruta a revisión, reinyecta.
5. Un informe que nadie lee. Condiciona el despliegue a la calidad, para que una regresión no pueda salir.

Quién construye esto

Oronts es una empresa de software liderada por su fundador, con sede en Múnich. Refaat Al Ktifan, nuestro fundador y arquitecto de soluciones, lidera un equipo senior que construye IA que puedes medir. Nuestra propia plataforma Exfinity puntúa cada respuesta, enruta la baja confianza a revisión y mejora gracias al bucle. Construimos el conjunto de pruebas, las métricas, el confidence scoring y el bucle de revisión, y te entregamos un sistema cuya calidad puedes ver y defender de verdad. Mira nuestras páginas de servicios y soluciones.

Conclusiones

• Si no puedes decir si tu IA mejoró o empeoró tras un cambio, estás esperando, no haciendo ingeniería.
• Construye un conjunto de pruebas versionado de casos comunes, difíciles, de fallos conocidos y adversariales.
• Mide recuperación y generación por separado para saber cuál arreglar.
• Añade una puntuación de confianza en vivo con un umbral de revisión, y cierra el bucle para que el sistema mejore.
• Condiciona el despliegue a la calidad para que una regresión no pueda lanzarse.

La evaluación no es una fase que haces una vez. Es el panel de instrumentos con el que pilotas el sistema. Constrúyelo pronto, condiciona siempre sobre él, y tu IA mejorará en lugar de derivar.

¿No estás seguro de si tu IA funciona de verdad? Cuéntanos qué estás ejecutando. Empieza en contacto o consigue un presupuesto acotado.