RecSys Semana 3

Comentario: Evaluating Recommendation Systems pdf

Resumen

El escrito tiene dos partes, la primera se enfoca en como comparar sistemas recomendadores en una variedad de propiedades considerando restricciones (memoria, cpu, datos, etc). El exito de un sistema no depende unicamente de su rendimiento en metricas de accuracy sino que influyen ademas otros factores. La evaluacion y comparacion de distintos algoritmos dependera en primer lugar de la forma de validar el rendimiento de los sistemas usados de los que se discuten 3 (offline, user studies y online experiments). Se discuten primero por lo mismo.

Independiente de la forma de comparar recomendadores debe siempre comenzarse desde una hipotesis (a la que estan orientados los experimentos), se deben fijar las variables que no se quieren evaluar, la evaluacion debe medir el poder de generalizacion de los sistemas mas alla de el set de pruebas. Para los experimentos offline (usando datos recolectados previamente, barato) debemos usar datos lo mas parecidos posibles a lo que esperamos encontrar luego del deployment. Una forma de lograr esto es simulando el comportamiento de los usuarios 1) considerando solo datos previos a una fecha para predecir los usando modelos avanzados. Los user studies (evaluamos reclutando usuarios para probar sistema) permiten recolectar medidas cualitativas pero son caros y facilmente pueden contener biases debido a la eleccion de usuarios para el test o porque saben que estan siendo evaluados. Dentro de los user studies que comparan software podemos distinguir entre within (AB testing) y between (todos prueban todas las versiones). Finalmente existe la online evaluation (algunos usuarios sin saberlo estan usando version modificada) que nos permite medir directamente el rendimiento conforme los objetivos generales del sistema.

Propiedades importantes a considerar cuando se elige un recomendador:

  • Preferencia de los usuarios: elegir el que prefieren los usuarios considerando que algunos pueden ser mas importantes.
  • Exactitud en la prediccion: el mas usado pero no por ser mas exacto va a ser prferido por el usuario. Podemos usar metricas como RMSE, MAE. La prediccion apunta a encontrar items que el usuario va a consumir por lo que podemos medir exactitud comparando los items predichos por el sistema por los que sabemos que el usuario consumio y medimos usando precision (at N), recall y false positive rate. A veces el orden y cantidad de predicciones puede infuir y deben usarse metricas que lo tomen en consideracion como NDPM.
  • Cobertura: proporcion de items que sugiere el sistema, diversidad de ventas (medible con metricas de desigualdad), proporcion de usuarios para los que el sistema puede recomendar (segun numero y calidad de interacciones de estos) y cold start (que tan rapido empieza a ser util el sistema).
  • Confianza (del sistema en sus predicciones): sirven al usuario para discriminar entre las alternativas. Pueden compararse dos sistemas diferentes incluso si tienen distintas metricas de confianza comparando los resultados de c/u despues de eliminar los elementos con baja confianza.
  • Confianza (del usuario en el sistema): importante para que el usuario efectivamente utilice las sugerencias.
  • Novedad: si se sugieren elementos desconocidos (para el). Se sugiere un metodo interesante para entrenar sistemas usando offline evaluation con el fin de hacerlos mas novedosos que comentare luego. Con usuarios es trivial, basta con preguntarles (aunque cuidadose de no introducir bias).
  • Serendipia: que tan sorprendentes son los resultados. Notese que una pesima recomendacion seria sorprendente, por lo que debe balancearse siempre con la precision. El autor sugiere (para evaluacion ofline) evaluar esta propiedad recompensando aquellos algoritmos que sugieran elementos distintos a los consumidos (donde la distancia se calcula usando los contextos de los items, ej. distancia cosena de los tf-idf). Nuevamente usando usuarios (user studies) es trivial preguntandoles.
  • Diversidad: a veces al presentar una lista de elementos queremos que sean variados entre ellos (ej. al sugerir hoteles para vacaciones no queremos que todas sean del mismo lugar). Nuevamente podemos ayudarnos usando metricas de distancia para penalizar aquellos algoritmos que entreguen resultados muy similares entre si.
  • Utilidad(es): maximizar utilidades, sea para la empresa dueña del sistema o para el usuario.
  • Riesgo: en algunos casos una recomendacion puede estar asociada a un cierto riesgo (ej. acciones) y el riesgo puede ser algo positivo o negatvo dependiendo del usuario y la situacion. Se recomienda considerar la varianza al comparar dos sistemas.
  • Robustez: es la estabilidad del sistema a informacion falsa, o a cargas elevadas (muchos requests). Podemos simular ataques para comparar sistemas en el primer caso.
  • Privacidad: no revelar las preferencias del usuario.
  • Adaptabilidad: en situaciones donde los intereses cambian rapido (ej. noticias de ultimo momento) es importante que el sistema pueda adaptar sus sugerencias rapido. Podemos usar medidas de desigualdad (Gini, entropia) para validar los cambios en las sugerencias al variar un perfil.
  • Escalabilidad: que el sistema pueda trabajar con datasets grandes, crecientes. Podemos evaluar la complejidad computacional en relacion al tamaño de la BD.

Comentarios:

Mi primer y mas importante comentario es una apreciacion general sobre como el autor enfatiza las diferencias entre los distintos campos de aplicacion de sistemas recomendadores y como no se puede estandarizar una metrica porque para cada uno las necesidades (en terminos de las propiedades arriba) son distintas. Asi se plantean varios ejemplos diferentes donde podemos notar la importancia de una propiedad por encima de otras (privacidad mas importante que exactitud en algunos casos, utilidad del sistema antes de cobertura en otros, etc).

Tambien aprovecho de destacar la sub-seccion que trata sobre la significancia de los resultados usando valores p, intervalos de confianza, y como comparar resultados obtenidos paired o unpaired. Me parece relevante dado que la tendencia general es asumir que aquel sistema con mejor resultado usando una metrica es mejor, pero no se considera la probabilidad de que esa metrica favorezca a un sistema por encima de otro. Aprovecho de conectar esto al articulo de la semana 1 donde usamos el umbral inferior del intervalo de confianza para tener certeza de que la metrica usada representa efectivamente el valor real (ie, la calidad del sistema).

El paper cubre un area sorprendentemente amplia de informacion y logra estructurarla bastante bien. Por ejemplo para la mayoria de las propiedades presentadas el autor menciona formas de medirla y a veces da mas de una para considerar los distintos metodos de evaluacion. El autor logra comunicar sutiliezas de cada una de las propiedades que las hacen dificiles de evaluar y conecta estas a las características propias de datasets de diferentes fuentes (y con distintos enfoques). Ejemplo de esto es cuando sugiere una forma de construir el test set para evaluar el orden de las predicciones donde tenemos datos solo sobre si el usuario oyo una cancion entera, la adelanto, o no la oyo. Otro ejemplo que encuentro notable es la forma de construir el test set para evaluar la novedad de items presentados (penalizando por sugerir elementos que el usuario si consumio, pero en el corto plazo).

Mi unica critica es que el autor no menciona la utilidad de ensamblar modelos con enfoques a distintas propiedades para luego combinar sus resultados. Esta muy relacionado a la materia que estamos viendo actualmente en clases (modelos hibridos) dado que considera aportes de mas de un modelo. Ensamblar, por ejemplo, un modelo que maximice la exactitud de las predicciones y devuelva una lista ordenada de resultados con otro modelo que entregue un resultado novedoso seria una excelente forma de incluir un poco de novedad a las predicciones pero sin perder precision. Justamente esto es lo que hace netflix al sugerir en categorias distintas “parecido a lo que has visto” y “tambien te podria interesar”.

Se entiende que el autor no se explaye en combinaciones de propiedades (por cantidad exponencial de combinaciones que habrian) pero me habria gustado que se mencionara que para cada aplicacion puede ser importante mas de una, y que se abordara a grandes rasgos la forma de combinar varios modelos o varias metricas en una.

Written on August 30, 2018