Es un tipo especial de charla trivial, que normalmente se observa en espacios de oficina alrededor de un enfriador de agua. Allí, los empleados comparten con frecuencia todo tipo de chismes corporativos, mitos, leyendas, opiniones científicas inexactas, anécdotas personales indiscretas o mentiras descaradas. Todo vale. En mis publicaciones sobre Water Cooler Small Talk, analizo opiniones extrañas y generalmente científicamente inválidas que yo, mis amigos o algún conocido mío hemos escuchado en su oficina y que literalmente nos han dejado sin palabras.
Entonces, aquí está la opinión del enfriador de agua de la publicación de hoy:
Hemos creado una aplicación RAG que está funcionando muy bien. Ahora estamos en la etapa de evaluación y va muy bien porque a través de todas las pruebas seguimos identificando problemas y solucionándolos. Ya estamos en una puntuación del 97%.
Ahora quiero que hagas una pausa por un segundo y pienses en lo que podría estar mal en esta afirmación. 🤔 Porque superficialmente suena perfectamente razonable. Encontrar problemas y solucionarlos parece exactamente lo que debería hacer un buen proceso de evaluación, ¿no es así? Responsable, incluso. Entonces, ¿qué está pasando realmente?
El problema aquí es sutil pero fundamental. Si está utilizando su proceso de evaluación para identificar problemas y luego solucionarlos y luego reevaluar en el mismo conjunto de pruebas, desafortunadamente ya no está evaluando. El conjunto de evaluación tiene una propiedad clave que lo hace tan útil: el modelo nunca lo ha visto antes. Cada vez que realiza un ajuste fino en función de sus resultados y luego vuelve a evaluar en el mismo conjunto, elimina un poco más de esa propiedad. En otras palabras, el conjunto de evaluación se ha convertido silenciosamente en parte del proceso de desarrollo y ahora es más un conjunto de capacitación.
Pero hacer esto correctamente es más fácil decirlo que hacerlo. En la práctica, ejecutar correctamente el proceso de evaluación puede resultar realmente agotador. En particular, cuando se habla de ejecutar evaluaciones para aplicaciones RAG, lo que significa que el conjunto de evaluación es un conjunto de preguntas y pares de respuestas, en lugar de un conjunto de datos históricos, hacerlo de la manera correcta puede resultar muy agotador y llevar mucho tiempo. No obstante, no ejecutar las evaluaciones correctamente da como resultado un problema de ML muy familiar: el sobreajuste.
¿Qué pasa con el sobreajuste?
Demos un paso atrás y hagamos un pequeño desvío hacia los conceptos básicos de ML.
En el aprendizaje automático, un modelo se construye utilizando datos que normalmente se dividen en un conjunto de entrenamiento, un conjunto de validación y un conjunto de prueba. Más específicamente, el modelo se ajusta primero al conjunto de entrenamiento, que son los datos utilizados para indicar qué tipo de modelo necesitamos usar y, en consecuencia, ajustar los parámetros del modelo. En su forma más simple, el conjunto de entrenamiento consta de pares de datos xey, y nuestro objetivo es crear un modelo y = f(x) que se ajuste de manera óptima a los datos xey disponibles.
Una vez hecho esto, el modelo entrenado se utiliza para predecir resultados en el conjunto de validación. En particular, para cada x en el conjunto de validación, generamos una y = f(x) prevista en función del modelo seleccionado, luego verificamos cómo se compara con la y real del conjunto de validación y luego ajustamos nuestro modelo en consecuencia.
Al final, y después de haber decidido qué modelo queremos proceder en última instancia en función del paso de validación, también lo ejecutamos en el conjunto de prueba. El objetivo del conjunto de pruebas es ver qué tan bien el modelo final generaliza datos que nunca antes había visto calculando sus puntuaciones, y es por eso que el conjunto de pruebas solo debe usarse una vez.
Hacemos todo esto porque nuestro objetivo no es ajustarnos al conjunto de entrenamiento, sino más bien lo que representa el conjunto de entrenamiento. De esta manera, podemos crear modelos que aprendan los patrones subyacentes lo suficientemente bien como para hacer predicciones precisas sobre datos nuevos e invisibles (el conjunto de prueba).
Desafortunadamente, a veces no lo hacemos y, en lugar de crear modelos que se ajusten al caso general, creamos modelos que simplemente se ajustan a un conjunto de entrenamiento limitado sin generalizar. Esto es lo que llamamos sobreajuste. Como resultado, el modelo funciona excepcionalmente bien en el conjunto de entrenamiento, logrando puntuaciones impresionantes, pero pobre en cualquier cosa nueva.
El truco aquí es que el conjunto de prueba es significativo sólo si el modelo realmente nunca lo ha visto antes. En el momento en que lo usas para tomar una decisión sobre el modelo, incluso una aparentemente pequeña, lo comprometes y esencialmente lo fusionas con el conjunto de entrenamiento.
Pero después de este pequeño desvío por los conceptos básicos de ML, volvamos a nuestra opinión original sobre el enfriador de agua.
Sobreajuste en la evaluación RAG
Aquí es donde las cosas se vuelven particularmente relevantes para quienes creamos y evaluamos aplicaciones de IA.
En mi serie sobre la evaluación de pipelines RAG, hablamos mucho sobre métricas de recuperación: Precision@k, Recall@k, MRR, NDCG@k, etc. Sin embargo, todas esas métricas sofisticadas son tan útiles como el conjunto de evaluación al que las aplicas. Resulta que la línea entre los conjuntos de evaluación y prueba en RAG puede desdibujarse con sorprendente facilidad. Atribuiría esto en parte al hecho de que, a diferencia de un modelo de regresión simple, los modelos de IA y los pipelines RAG están lejos de ser intuitivos para nosotros. Tenemos poca intuición real sobre cómo el modelo se ajusta realmente a los datos y, como resultado, podemos dejarnos llevar y ajustar el sistema según el conjunto de prueba sin siquiera darnos cuenta de que lo hicimos.
El equipo de nuestra historia sobre el enfriador de agua está haciendo exactamente esto. Identifican problemas durante la evaluación, los solucionan y vuelven a evaluar con los mismos pares de preguntas y respuestas. Naturalmente, en cada iteración, los puntajes de evaluación mejoran porque esencialmente ahora se adaptan a la aplicación de IA en el conjunto de prueba.
En particular, estas son las formas más comunes en que esto puede suceder en RAG:
Indicaciones de ajuste en el conjunto de evaluación: este es probablemente el patrón más común y es exactamente lo que sucedió en nuestra historia del enfriador de agua. Ejecuta una evaluación, observa que ciertos tipos de preguntas fallan constantemente y ajusta el mensaje del sistema o la lógica de recuperación para solucionarlos. Luego vuelves a evaluar en el mismo set. Por supuesto, las puntuaciones mejoran; incluso puedes conseguir una impresionante puntuación del 100%. Preguntas selectivas que el sistema ya maneja bien: una versión más sutil del mismo problema. Al crear un conjunto de evaluación, es tentador incluir ejemplos en los que ya sabe que el sistema funciona bien, especialmente aquellos que ha probado informalmente a lo largo del camino. Con el tiempo, el conjunto de evaluación se acerca a las fortalezas del sistema y se aleja de sus puntos ciegos. Las métricas parecen excelentes, pero en realidad nadie sabe cuál es el rendimiento real. Construya sus preguntas de prueba a partir de los mismos documentos que indexó: si las preguntas de su conjunto de evaluación se escriben observando de cerca los documentos que ya están en su base de conocimientos, es muy probable que estén implícitamente determinadas por lo que ya sabe que es recuperable. En otras palabras, las preguntas nunca fueron verdaderamente independientes de los datos, pero nuevamente, esto es especialmente difícil de entender ya que hablamos de preguntas y respuestas en lenguaje natural en lugar de solo números x e y.
La solución simple pero difícil para todos esos casos es la misma que la solución clásica de aprendizaje automático: mantener un conjunto de pruebas genuinamente disponible que toque lo menos posible, construir sus preguntas independientemente del comportamiento conocido del sistema y tratar las métricas sospechosamente buenas con escepticismo. Un sistema RAG que funciona maravillosamente en un conjunto de evaluación pequeño, cuidadosamente seleccionado y reutilizado con frecuencia se parece mucho al estudiante que memorizó los exámenes anteriores pero no está en absoluto preparado para la primera pregunta real que no se parece exactamente a las que ya ha visto.
Si desea comprobar la cordura de su propia configuración de evaluación RAG, aquí tiene una breve lista de preguntas que vale la pena considerar y plantearse honestamente:
Cuando construí mi conjunto de evaluación, ¿escribí las preguntas independientemente de los documentos en mi base de conocimientos, o miré los documentos primero y escribí preguntas que ya sabía que tenían respuesta? ¿Alguna vez eliminé o reemplacé una pregunta de mi conjunto de evaluación porque la aplicación seguía fallando? ¿Sé aproximadamente cómo funciona mi sistema en preguntas que nunca antes se han probado, o sólo en el mismo conjunto fijo que sigo reutilizando? ¿Hay alguna parte de mi conjunto de evaluación que no ha sido tocada ni vista por mí durante un tiempo?
Si respondiste que no a la última pregunta, es posible que ya seas el equipo de la historia del enfriador de agua de hoy. 😉
Sobreajuste en la vida real: ley de Goodhart
La Ley de Goodhart, acuñada por el economista Charles Goodhart en 1975, es algo así como un proverbio que dice lo siguiente:
Cuando una medida se convierte en un objetivo, deja de ser una buena medida.
Esta idea surgió originalmente de la política monetaria, pero se generaliza mucho más allá de la economía y aparece en casi todos los lugares donde se utiliza un número para juzgar el desempeño, como los KPI, los presupuestos y todo tipo de números. Imagine que un vendedor de automóviles recibe una recompensa por la cantidad de automóviles que vende cada mes y luego comienza a vender más automóviles, incluso con pérdidas; hospitales que intentan reducir la duración de la estancia de los pacientes y luego terminan dándoles el alta demasiado pronto; las citas cuentan con publicaciones científicas que son engañadas, etc.
Todos estos ejemplos funcionan exactamente con el mismo mecanismo subyacente: se introduce una medida cuantitativa para realizar un seguimiento de algo importante. Por un tiempo, la medida y lo real se mueven juntos, y parece que ahora podemos confiar en la evolución de la medida para realizar un seguimiento de la evolución de lo real. Luego, las personas (o los sistemas) comienzan a optimizar directamente para la medida en lugar de para el elemento importante subyacente, y ambos se separan silenciosamente. Entonces la medida comienza a mejorar sin que la importancia subyacente que debía representar mejore de la misma manera.
Específicamente en la IA, este modo de falla se llama hackeo de recompensas, que ocurre cuando un sistema de IA optimiza una recompensa mal especificada sin alcanzar realmente el resultado previsto. De manera similar, en el ML clásico, el sobreajuste es lo que le sucede a un modelo cuando la señal de entrenamiento deja de representar el patrón subyacente real. La Ley de Goodhart es lo que nos sucede a nosotros, los humanos que diseñamos el sistema, cuando nuestra señal de evaluación deja de representar lo que realmente nos importa.
en mi mente
Lo que encuentro más interesante sobre el sobreajuste, particularmente en aplicaciones RAG, es que en realidad no es un problema técnico. Es principalmente un problema de comprensión y apego al proceso. Es tentador poner en peligro ese proceso y optimizar directamente las puntuaciones, especialmente con conjuntos de datos RAG que no se parecen mucho a los conjuntos de datos a los que estamos acostumbrados en el ML clásico.
Sin embargo, este patrón se manifiesta mucho más allá del aprendizaje automático y la inteligencia artificial. En la vida real y en el aprendizaje automático, el antídoto es el mismo: ser constante y nunca perder de vista lo que realmente estás tratando de lograr. En ML e IA, lo importante es que el modelo funcione genuinamente y produzca resultados significativos una vez que esté en producción y se enfrente a datos del mundo real, no solo para lograr puntuaciones altas durante la evaluación.
El equipo de nuestra historia sobre el enfriador de agua no está haciendo nada malicioso. Por el contrario, lo que hacen se siente como ser responsables y ajustar la aplicación en función de los resultados de la evaluación. Y eso es exactamente lo que hace que el sobreajuste sea tan peligroso. No parece un error mientras sucede. Sólo lo parece en retrospectiva, una vez que el sistema se encuentra con el mundo real y las puntuaciones dejan de mantenerse.
✨ ¡Gracias por leer! ✨
Si llegaste hasta aquí, Puede que te resulten útiles los pialgoritmos. — una plataforma que hemos estado construyendo y que ayuda a los equipos a gestionar de forma segura el conocimiento organizacional en un solo lugar.
¿Te encantó esta publicación? Únase a mí en 💌Substack y 💼LinkedIn
Todas las imágenes del autor, salvo que se indique lo contrario.