Cómo crear recomendaciones de artículos usando solo Jina Reranker API

Introdujimos la API Reranker hace dos semanas, estableciéndola como una solución líder de reordenamiento en el mercado. Jina Reranker supera el rendimiento de las líneas base populares en varios benchmarks, demostrando un aumento significativo de hasta +33% en la tasa de aciertos sobre los resultados de BM25. Si bien el rendimiento es impresionante, lo que realmente me emociona es el potencial de la API Reranker. Su interfaz sencilla permite ingresar una lista de consulta-documentos y devuelve directamente los resultados top-k reordenados. Esto significa que, en teoría, uno podría construir un sistema de búsqueda o recomendación usando únicamente el Reranker—eliminando la necesidad de BM25, embeddings, bases de datos vectoriales o cualquier pipeline, logrando así una funcionalidad end-to-end.

Este concepto me intrigó tanto que me sentí impulsado a experimentar con él. Así que aquí está: ahora al navegar a cualquier página de noticias de nuestro sitio web, como la que estás leyendo actualmente, presiona la tecla @ y haz clic en el botón "obtener los 5 artículos más relacionados", recibirás los cinco artículos más relevantes al actual en aproximadamente 5 segundos, usando el modelo jina-reranker-v1 (un poco más para el modelo jina-colbert-v1). Todos los cálculos se realizan en línea y son gestionados completamente por la API Reranker. A continuación hay un video que demuestra cómo funciona:

tagImplementación

La implementación es muy simple: para encontrar los artículos más relacionados con un artículo dado en jina.ai/news/, usamos el artículo que se está leyendo actualmente como la consulta y todos los otros 230+ artículos (¡usando su texto completo!) en nuestro sitio de noticias como los documentos, excluyendo el actual por supuesto. Luego enviamos este $(q, d_1, d_2, \cdots, d_{230})$ como payload a la API Reranker. Una vez que se recibe la respuesta, usamos el índice de documentos ordenado para mostrar los resultados. Por lo tanto, el código subyacente es el siguiente:

const getRecommendedArticles = async () => {
  
  const query = `${currentNews.title} ${currentNews.excerpt}`;
  const docs = newsStore.allBlogs.filter((item) => item.slug !== currentNews.slug);
  
  const data = {
    model: modelName,
    query: query,
    documents: docs,
    top_n: 5,
  }

  const rerankUrl = 'https://api.jina.ai/v1/rerank';
  const headers = {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${apiKey}`,
  };
  const modelName = 'jina-reranker-v1-base-en';
  
  const res = await fetch(rerankUrl, {
    method: 'POST',
    headers: headers,
    body: JSON.stringify(data),
  });

  const resp = await res.json();

  const topKList = resp.results.map((item) => {
    return docs[item.index];
  });

  console.log(topKList);
}
Copiar

Reranker API

Maximize the search relevancy and RAG accuracy at ease

Y así de simple, verás los resultados, que son bastante prometedores para una primera iteración, especialmente considerando que el proceso de implementación toma aproximadamente 10 minutos.

Si bien los lectores pueden tener preocupaciones sobre esta implementación, algunas críticas pueden estar sobreestimadas, mientras que otras pueden ser válidas:

• Las preocupaciones sobre textos demasiado largos y la necesidad de fragmentación pueden estar sobreestimadas: el modelo jina-reranker-v1 puede procesar consultas de hasta 512 de longitud y documentos de longitud arbitraria, mientras que el modelo jina-colbert-v1 puede manejar hasta 8192 tanto para consultas como para documentos. Por lo tanto, ingresar el texto completo a la API Reranker probablemente sea innecesario. Ambos modelos manejan eficientemente contextos largos, así que no hay necesidad de preocuparse. La fragmentación, aunque posiblemente sea el aspecto más engorroso y heurístico del pipeline embedding-vector-search-rerank, es menos problemática aquí. Sin embargo, los contextos más largos asumen más tokens, lo cual es algo que nuestros usuarios pagos de la API pueden necesitar considerar. En este ejemplo, debido a que usamos el texto completo de los 233 artículos, una consulta de reordenamiento cuesta más de 300K tokens.
• El impacto de los datos crudos versus limpios en la calidad. Agregar limpieza de datos podría llevar a mejoras. Por ejemplo, hemos observado que simplemente eliminar las etiquetas HTML (es decir, docs.map(item => item.html.replace(/<[^>]*>?/gm, '')) mejora significativamente la calidad de las recomendaciones para el modelo jina-reranker-v1, aunque el efecto es menos pronunciado para el modelo jina-colbert-v1. Esto sugiere que nuestro modelo ColBERT fue entrenado para ser más tolerante con texto ruidoso que el modelo jina-reranker-v1.
• La influencia de diferentes construcciones de consultas en la calidad. En la implementación anterior, usamos directamente el título y el extracto del artículo actual como consulta. ¿Es este el enfoque óptimo para construir la consulta? ¿Agregar un prefijo como "What is the most related article to..." o
"Te daré $20 de propina si recomiendas el mejor artículo," similar a los prompts utilizados con modelos de lenguaje grandes, ¿sería beneficioso? Esto plantea una pregunta interesante, probablemente relacionada con la distribución de datos de entrenamiento del modelo, que planeamos explorar más a fondo.
• Basándonos en el punto anterior sobre la construcción de consultas, sería interesante investigar más a fondo las capacidades composicionales de la consulta, como usar el historial de navegación reciente de un usuario para recomendaciones personalizadas. Es particularmente interesante considerar si el sistema podría entender no solo ejemplos positivos en la consulta sino también negativos, por ejemplo, operaciones NOT_LIKE, "No me recomiendes artículos como este" o "Quiero ver menos como este". Profundizaremos más en esto en la siguiente sección.

tagEstudio Empírico sobre la Escritura de Consultas

En nuestra exploración de diferentes formas de escribir consultas con la API de Jina Reranker, centrándonos en los 10 primeros resultados, realizamos una evaluación cualitativa mediante etiquetado humano (es decir, evaluado por nosotros mismos), lo cual tiene sentido ya que tenemos el conocimiento completo de todo el contenido publicado en nuestro sitio web. Las estrategias en la escritura de consultas que examinamos incluyeron:

• Usar el Título del artículo, el Extracto, y una combinación de Título + Extracto.
• Adoptar instrucciones tipo "Prompt" como "más como este," "no como este," y "¿cuál es el artículo más estrechamente relacionado?"

Para probar la eficacia del reranker, seleccionamos dos artículos no triviales como nuestros sujetos de consulta, con el objetivo de identificar los artículos más relevantes entre nuestro extenso catálogo de más de 200+ publicaciones—un desafío inspirado en "la aguja en el pajar" en LLMs. A continuación, resaltamos estas "agujas" en verde para mayor claridad.

tagResumen

Basados en los resultados de las pruebas, hemos hecho algunas observaciones y resúmenes:

1. Combinar el Título y el Extracto produce los mejores resultados de reordenamiento, siendo el Extracto un factor significativo en la mejora de la calidad del reordenamiento.
2. Incorporar instrucciones tipo "prompt" no conduce a ninguna mejora.
3. El modelo reranker actualmente no procesa efectivamente los calificadores positivos o negativos. Términos como "más como", "menos como", o "no como" no son comprensibles por el reranker.

Las perspectivas de los puntos 2 y 3 ofrecen direcciones intrigantes para futuras mejoras del reranker. Creemos que permitir el prompting en tiempo real para cambiar la lógica de ordenamiento podría expandir significativamente las capacidades del reranker, desbloqueando nuevas aplicaciones potenciales como la curación/recomendación de contenido personalizado.