por Malvina Matlis & Marcos Calvo Lance

Los sistemas de recuperación de información (IR) son omnipresentes en nuestro día a día. Tal vez sea saldar apuestas buscando la respuesta en línea, ubicar tus productos favoritos en Amazon, encontrar algún correo electrónico en Outlook, o tal vez simplemente tengas hambre y quieras cocinar una deliciosa paella auténtica. Probablemente nuestra vida no sería tan fácil (y tampoco tan divertida) sin todos esos cuadros de búsqueda que nos permiten encontrar todo tipo de documentos e información, ya sea escrito, audio, fotos, videos o cualquier otra cosa. Sin embargo, para que un usuario encuentre útil un sistema IR, el sistema debe proporcionar una respuesta relevante de manera oportuna. Por lo tanto, ¿cómo nos aseguramos de que un motor de búsqueda proporcione a los usuarios contenido relevante de acuerdo con sus consultas cuando tenemos un escenario de "arranque en frío", es decir, no hay historial de consultas? ¿Y cómo evaluamos el rendimiento en vivo de un sistema IR cuando ya está en producción?

En esta publicación de blog, demostraremos cómo elegimos evaluar un sistema de este tipo mediante el monitoreo en línea y el análisis de registros con Kusto , una herramienta de consulta de Microsoft, pero estos conceptos también se pueden aplicar a otros lenguajes y pilas tecnológicas.

Evaluación de sistemas IR

La evaluación de los sistemas de IR se ha estudiado y documentado ampliamente, lo que significa que se han definido algunas métricas estándar; se puede encontrar una buena descripción general en Métricas de evaluación para la recuperación de información .
Por ejemplo, algunas de estas métricas estándar son:

Precisión
Cuantifica la proporción de los resultados devueltos por el sistema que son relevantes para la consulta (es decir, término de búsqueda). Por ejemplo, en la imagen de arriba buscamos la receta de una auténtica paella. El motor de búsqueda recuperó 330 millones de documentos. Si tuviéramos una referencia que dijera que 200 millones de dichos documentos son relevantes para la búsqueda de recetas, entonces la precisión de la consulta sería 200/330 = 60,6 %.

Recuperar
Mide la proporción de resultados relevantes que devuelve el sistema del conjunto de todos los resultados relevantes. Volviendo a nuestro ejemplo, ¿qué pasaría si el motor de búsqueda pasara por alto 20 millones de documentos relevantes? Entonces el retiro será 200/(200+20) = 90.9%

Clasificación recíproca (RR)
Mide en qué parte de la lista de resultados devueltos se encuentra el primer documento relevante. Dado que es conveniente tener métricas con valores entre 0 y 1, donde 1 representa una mejor puntuación que 0, la clasificación recíproca se define como 1 sobre el índice más alto de un documento que es relevante para la consulta. Para medirlo sobre un conjunto de consultas, simplemente promediamos el ranking recíproco sobre el conjunto de consultas, obteniendo así el Ranking Recíproco Medio (MRR), o en forma de ecuación:

Como todavía tenemos hambre y no vamos a pasar de 330 millones de recetas, el RR mirará el primer documento que marcamos como relevante. Digamos que fue la quinta receta, entonces el RR para la consulta será 1/5.

Es más fácil decirlo que hacerlo

En cuanto a la mayoría de los problemas de aprendizaje automático, las métricas de evaluación generalmente se calculan en un conjunto de datos de evaluación curado, anotado y predefinido fuera de línea, que es de esperar que sea lo suficientemente representativo del comportamiento del sistema en la naturaleza . Sin embargo, ¿qué sucede si no hay un conjunto de datos disponible que sea suficientemente representativo de las necesidades de los usuarios? ¿O qué pasa si esas necesidades son desconocidas?

Métricas en línea: recopilemos comentarios
Una alternativa al uso de un conjunto de datos de evaluación predefinido para evaluar la calidad del sistema es aprovechar la información sobre el uso del sistema. Al recopilar información sobre el viaje del usuario en el sistema IR, podemos evaluar y monitorear los resultados devueltos. Por el bien de un ejemplo, consideremos el siguiente flujo de usuario en una aplicación:

1. Consulta de entrada: El usuario introduce una consulta (“receta de paella auténtica” en nuestro ejemplo) en la aplicación, que se pasa al buscador.
2. Exploración de documentos: el sistema devuelve una lista de documentos y la aplicación los muestra ordenados por su relevancia.
3. Inspección de documentos: el usuario examina los documentos devueltos en orden y selecciona uno para inspeccionarlo más a fondo.
4. Éxito: si el usuario está satisfecho con el documento inspeccionado, puede informar a la aplicación que la búsqueda ha finalizado. Una opción es calificar el resultado positivamente. Otra es usar métodos proxy para inferir que la búsqueda fue exitosa, como medir el tiempo que el usuario pasó inspeccionando el documento.
5. Si el usuario no está satisfecho con el documento inspeccionado, vuelve a navegar por los resultados (punto 4) y puede seleccionar un nuevo documento para inspeccionar.

Kusto al rescate

Los mecanismos de observabilidad, como el registro, generan una gran cantidad de datos, lo que plantea el desafío adicional de consultarlos.

Los registros se pueden inspeccionar en el portal de Azure AppInsights mediante Azure Data Explorer y, específicamente, su lenguaje de consulta Kusto . Si está familiarizado con SQL, reconocerá bastantes puntos comunes en este lenguaje. Sin embargo, existe una diferencia significativa entre Kusto y SQL: en Kusto, las declaraciones se ejecutan en orden, lo que hace que las consultas sean más breves y legibles que las consultas SQL.

Métricas de evaluación mediante el registro de eventos de usuario

Tradicionalmente, el registro se ha utilizado ampliamente con fines de supervisión e ingeniería. Algunos ejemplos incluyen saber cuántas consultas por unidad de tiempo necesita atender el sistema, cuántos usuarios están consultando el sistema o cuánto tiempo pasa un usuario inspeccionando un documento en promedio. Sin embargo, los científicos de datos también pueden beneficiarse del registro adecuado para calcular los indicadores clave de rendimiento (KPI) y evaluar el rendimiento del sistema en línea de manera continua.

Rango recíproco medio (MRR)

A partir de las métricas de evaluación de IR mencionadas anteriormente, la clasificación recíproca (RR) solo requiere la clasificación del primer resultado relevante en la lista de documentos devueltos, que podemos definir a través de la interacción del usuario final. Por lo tanto, se puede calcular en el tráfico real una vez que se haya realizado el registro adecuado. En nuestro ejemplo, cuando se activa un evento OnSuccess , significa que el usuario consideró un resultado relevante. Desde la perspectiva de la experiencia del usuario, el RR para una consulta determinada nos informa qué tan rápido el usuario podría encontrar un primer documento que sea relevante para sus necesidades.

Luego, el MRR se puede calcular promediando el RR durante un período de tiempo significativo, por ejemplo, un día, en una población de usuarios estadísticamente significativa para que las diferentes consultas y perfiles de usuario se agreguen y representen en la métrica. De esta forma podemos comparar que, por ejemplo, los usuarios de España encuentran la primera receta relevante en el documento 15 de media y los usuarios de Israel la encuentran en el documento 3 de media.

La siguiente consulta de Kusto calcula exactamente eso.

Una rápida hoja de trucos de Kusto a SQL (y recuerde, Kusto se ejecuta en orden):

• [Kusto] -> [SQL]
• donde -> donde
• proyecto -> seleccionar
• resume -> una selección con cualquier función agregada como sum, avg o min, junto con el grupo por columnas
• make-series -> una función no disponible en SQL que convierte el conjunto de datos en un gráfico de serie temporal
• render -> otra característica no disponible en SQL que traza los datos

Dada una consulta “receta de paella auténtica” y 10 documentos que devolvió el buscador, ordenamos los documentos de manera que el documento más similar a la consulta esté en el rango 1 y el menos similar tenga el rango 10. Por el bien del ejemplo , supongamos que nuestros usuarios encontraron relevantes los documentos 3, 6 y 8.

arg_max (ExprToMaximize, * | ExprToReturn [, ...])

Métricas de embudo

La métrica de clasificación recíproca nos ofrece una visión limitada de cómo el usuario está interactuando con el sistema, ya que solo mira el primer documento relevante. Por ejemplo, podemos complementar esta métrica calculando cuántos documentos necesita inspeccionar un usuario en promedio para encontrar todos los documentos que pueda necesitar. En un escenario ideal, nos gustaría que el usuario abra solo aquellos documentos que son realmente relevantes, ya que les estaríamos ahorrando mucho tiempo al revisar documentos irrelevantes.

Usando el registro introducido en este sistema, podemos reformular esta pregunta como una métrica: de esas interacciones que causan un evento onNavigate , ¿cuál es la proporción que también activó un evento onSuccess ? O, más simplemente, ¿con qué porcentaje de los documentos que leyó el usuario interactuó? Podemos escribirlo usando Kusto de la siguiente manera:

Puede echar un vistazo a la hoja de trucos completa de Kusto to SQL para la interpretación de la consulta.

Poniendo todo junto: el tablero

Para realizar un seguimiento de estas y otras métricas, es conveniente construir un tablero. En nuestro ejemplo, monitoreamos las métricas usando la función de tablero de AppInsights. Hacemos un seguimiento de las métricas de monitoreo, así como de las métricas de rendimiento de IR en una sola vista, ya que toda la información se puede obtener fácilmente de los registros del sistema. Todo el código está incluido en el siguiente repositorio de muestras de Azure

Este tablero nos permite rastrear el sistema y las métricas de rendimiento simultáneamente. Sin embargo, no necesariamente nos permite diagnosticar por qué se deteriora el rendimiento de nuestras métricas. Por ejemplo, si “Diario RR” disminuye con el tiempo, es porque:

• ¿Las necesidades del usuario han cambiado?
• ¿Se han indexado nuevos documentos y el nuevo contenido no coincide con el anterior?
• ¿Nuestra biblioteca de documentos está desactualizada y necesita ser actualizada con nuevos documentos?
• ¿La definición de éxito del usuario ha cambiado?
• ¿Los cambios de UX afectan la forma en que los usuarios interactúan con los resultados? Por ejemplo, un widget de tema aparece en la página de resultados y muestra información, eliminando la necesidad de interactuar con un documento específico.
• ¿Estacionalidad?
• ¿Otro?

Conclusión

Nos motivó a escribir este artículo porque nos encontramos con un escenario en el que los datos de evaluación anotados preexistentes para el motor de búsqueda no estaban disponibles. Descubrimos que el seguimiento de las interacciones de los usuarios con el sistema a lo largo del tiempo brinda pistas sobre dónde se necesitan ajustes adicionales. La clasificación recíproca visualiza cuánto debe desplazarse el usuario para encontrar el primer documento relevante, mientras que la proporción entre documentos relevantes y abiertos arroja luz sobre el rendimiento general del motor de búsqueda y la relevancia de los documentos devueltos.

El diseño adecuado de registro y análisis de aplicaciones permite el seguimiento en tiempo real de la calidad del sistema desde el momento en que el sistema se ejecuta en producción. Esto no solo es útil para los casos en los que los recursos de evaluación no están disponibles, sino que también nos permite detectar variaciones en la calidad del sistema a lo largo del tiempo y, por lo tanto, mejorar la experiencia del usuario. Y ahora, vamos a hacer una paella.