← Blog Cuando no funciona
Cómo medimos si un asistente de IA responde bien
Durante tres años construimos y operamos el asistente de una plataforma de lealtad con más de dos millones de usuarios activos en diez países. De ese sistema sale el fallo que cuenta este artículo; de lo que hacemos hoy en cada proyecto, la forma de medirlo.
En resumen
- Un asistente con búsqueda —un RAG— falla en dos lugares distintos: cuando no encuentra el fragmento correcto y cuando, teniéndolo, responde más allá de lo que dice. Cada falla se mide con números propios.
- La búsqueda se mide con recall@k y MRR; la respuesta, con fundamentación, que dice cuánto de lo afirmado está respaldado por lo que el sistema leyó.
- Para medir no hacen falta miles de preguntas: de treinta a cincuenta preguntas reales, con la respuesta correcta escrita por alguien del negocio, ya separan un sistema que funciona de uno roto.
- El fallo que más nos costó en producción fue el fragmento correcto sobre el producto equivocado: una respuesta bien redactada y fundamentada que ninguna métrica de alucinación marca. Se arregló filtrando por entidad antes de rankear.
El fragmento correcto, sobre el producto equivocado
Construimos el pipeline completo de ese asistente: ingesta y normalización de documentos, fragmentación, embeddings, almacén vectorial sobre Azure AI Search y Pinecone, y recuperación con generación fundamentada sobre LangChain. Lo sostuvimos con más del 99% de disponibilidad durante tres años.
El error que más costó resolver no fue de alucinación. El sistema encontraba un fragmento que respondía exactamente la pregunta, pero sobre otro producto: «precio del plan Premium» y «precio del plan Básico» quedan casi encima en el espacio vectorial, porque las dos frases dicen casi lo mismo.
La respuesta salía bien redactada, apoyada en un documento real, y equivocada. Una métrica de fundamentación no la marca, porque el modelo dijo exactamente lo que leyó: el problema estaba antes, en la búsqueda. Lo arreglamos extrayendo metadata estructurada en el momento de la ingesta —a qué producto pertenece cada fragmento— y filtrando por esa entidad antes de rankear, en lugar de confiar solo en la similitud semántica.
Qué mide cada número
| Métrica | Qué mide | Qué significa un mal resultado |
|---|---|---|
| recall@k | Cuántas veces el fragmento correcto está entre los k recuperados | La búsqueda falla. Revisar la fragmentación y probar búsqueda híbrida. |
| MRR | Qué tan arriba aparece el primer fragmento correcto | Lo encuentra pero lo entierra. Hace falta reordenar los resultados. |
| Precisión por entidad | Si el fragmento recuperado es del producto, plan o cliente por el que se preguntó | El fallo del caso: respuesta correcta sobre la cosa equivocada. |
| Fundamentación | Cuánto de la respuesta está respaldado por lo recuperado | El modelo afirma más de lo que leyó. Instrucciones y política de rechazo. |
| Tasa de rechazo | Cuántas veces dice que no sabe | Si es cero, es una alarma, no un logro. |
| Costo por consulta | Lo que cuesta cada respuesta en el proveedor del modelo | Funciona, y no se puede pagar al volumen real. |
Cómo se arma en un día
- Preguntas reales. De tickets de soporte, conversaciones o el correo de ventas. Las preguntas inventadas miden la imaginación de quien las escribió, no lo que va a llegar.
- La respuesta, escrita por alguien del negocio. No por el modelo. Es la parte que no se automatiza, y la razón por la que casi todos se la saltan.
- El fragmento fuente marcado. Qué documento y qué sección contienen la respuesta. Es lo que vuelve calculable el recall@k en vez de opinable.
- Pares de cosas parecidas. Productos, planes o sedes que se describen casi igual. Son las preguntas que detectan el fragmento correcto sobre la cosa equivocada.
- Preguntas sin respuesta. Entre el 10% y el 15% del conjunto no debería estar cubierto por los documentos. Sin ellas no se puede medir si el sistema sabe decir que no sabe.
Cinco señales de que nadie está midiendo
- La tasa de rechazo es cero. Un sistema que siempre encuentra algo que decir está inventando en una parte de los casos.
- La calidad se reporta como un porcentaje sin definición. Nadie dice qué contó como respuesta correcta ni quién lo decidió.
- Nadie sabe el recall@k de hace tres meses. Sin la serie, la degradación es invisible hasta que llega la queja.
- Las preguntas de prueba las escribió el proveedor. Con los mismos documentos que él indexó, la prueba mide lo que el proveedor ya sabía que funcionaba.
- Nunca se calculó el costo por consulta. Nadie sabe cuánto cuesta el volumen multiplicado por diez, y el piloto que funciona no se puede pagar en producción.
Lo que hacemos
- Sistemas RAG Segmentación, reordenamiento y búsqueda híbrida, evaluados con recall@k y NDCG.
- Rescate de proyectos El sistema ya está en producción y responde mal. Lo medimos y determinamos qué corregir.
- Chatbots y asistentes con IA Con el conjunto de evaluación ejecutado antes de la salida a producción.
Preguntas frecuentes
¿Cómo se mide si un chatbot con IA responde bien?
Con un conjunto de preguntas reales cuya respuesta correcta escribió alguien del negocio. Contra ese conjunto se mide la búsqueda —si encuentra el fragmento correcto, con recall@k y MRR— y la respuesta —si está respaldada por lo que leyó, con fundamentación—. De treinta a cincuenta preguntas ya separan un sistema que funciona de uno roto.
¿Qué es recall@k?
Es la proporción de preguntas en las que el fragmento que contiene la respuesta aparece entre los k primeros resultados de la búsqueda. Si el fragmento correcto no está entre los recuperados, ningún modelo puede responder bien, así que es el primer número que hay que mirar.
¿Qué es la fundamentación de una respuesta?
Mide cuánto de lo que afirma la respuesta está respaldado por los fragmentos recuperados. Una fundamentación baja significa que el modelo agrega afirmaciones que los documentos no sostienen, que es lo que se suele llamar alucinación. Se mide aparte de la búsqueda: un sistema puede encontrar el fragmento perfecto y aun así responder de más.
¿Por qué un asistente responde bien sobre el producto equivocado?
Porque la búsqueda semántica empareja por significado, y dos productos descritos casi igual quedan casi en el mismo lugar del espacio vectorial. El arreglo que usamos fue extraer en la ingesta a qué producto pertenece cada fragmento y filtrar por esa entidad antes de rankear, en lugar de confiar solo en la similitud.
¿Cada cuánto hay que volver a medir un asistente de IA?
Mensualmente si los documentos cambian seguido, trimestralmente si son estables, y siempre después de cambiar la fragmentación, los embeddings, la estrategia de búsqueda o el modelo. El objetivo no es el número en sí: es detectar la degradación antes que un cliente.
Escrito por
Equipo de ingeniería de Quarl
Somos un equipo de ingeniería de IA en Medellín. Construimos y operamos sistemas que llegan a producción —automatizaciones, asistentes y agentes— y durante tres años operamos un asistente para dos millones de usuarios en diez países.
Conoce cómo trabajamos →¿Lo quieres aplicar en tu empresa?
En quince minutos te decimos si vale la pena, sin costo y sin venta. La propuesta llega en 48 horas.