Evaluar las respuestas
Sin dos métricas separadas, optimiza a ciegas
Evaluar las respuestas de un sistema RAG
Ha modificado la fragmentación, ha cambiado de modelo de embeddings y ha añadido un reordenador. El sistema parece mejor. Un usuario señala una regresión en una pregunta que funcionaba la semana pasada. No puede confirmarlo ni desmentirlo, porque su único método de validación consiste en escribir cuatro preguntas que conoce de memoria y dar por buenas las respuestas. No sabe cuál de sus tres cambios ayudó, cuál perjudicó, ni si la media ha mejorado.
Esta es la situación por defecto de casi todos los proyectos RAG, y es lo que los estanca. Un sistema RAG tiene dos etapas que fallan por razones distintas y se arreglan con medios distintos: la recuperación y la generación. Una única métrica global las mezcla, de modo que nunca le dice qué corregir. La disciplina mínima consiste en medir ambas por separado, sobre un conjunto de preguntas fijo, antes de cada cambio.
Construir el conjunto de referencia
Apunte a entre 50 y 150 preguntas. Por debajo de 40, el ruido estadístico supera las diferencias que intenta medir. Por encima de 200, el coste de anotación se vuelve disuasorio sin una ganancia proporcional.
Comentarios
Los comentarios funcionan con GitHub Discussions
Inicia sesión con GitHub para participar en la discusión