Как создать рекомендации статей, используя только Jina Reranker API

Две недели назад мы представили Reranker API, утвердив его как ведущее решение для переранжирования на рынке. Jina Reranker превосходит популярные базовые решения в различных тестах, демонстрируя значительное увеличение показателя попаданий до +33% по сравнению с результатами BM25. Хотя производительность впечатляет, что действительно захватывает меня, так это потенциал Reranker API. Его простой интерфейс позволяет подавать на вход список запрос-документ и напрямую получать топ-k переранжированных результатов. Это означает, что теоретически можно построить систему поиска или рекомендаций, используя только Reranker — устраняя необходимость в BM25, эмбеддингах, векторных базах данных или каких-либо пайплайнах, тем самым достигая сквозной функциональности.

Эта концепция так заинтриговала меня, что я почувствовал необходимость её протестировать. Итак: теперь при переходе на любую новостную страницу нашего сайта, включая ту, которую вы сейчас читаете, нажмите клавишу @ и кликните на кнопку "получить топ-5 похожих статей", и вы получите пять наиболее релевантных статей к текущей примерно за 5 секунд, используя модель jina-reranker-v1 (немного дольше для модели jina-colbert-v1). Все вычисления выполняются онлайн и полностью управляются Reranker API. Ниже представлено видео, демонстрирующее, как это работает:

tagРеализация

Реализация очень проста: чтобы найти наиболее связанные статьи для данной статьи на jina.ai/news/, мы используем текущую читаемую статью как запрос и все остальные 230+ статей (используя их полный текст!) на нашем новостном сайте как документы, исключая, конечно, текущую статью. Затем мы отправляем этот $(q, d_1, d_2, \cdots, d_{230})$ как полезную нагрузку в Reranker API. После получения ответа мы используем отсортированный индекс документов для отображения результатов. Таким образом, базовый код выглядит следующим образом:

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);
}
Копировать

Reranker API

Maximize the search relevancy and RAG accuracy at ease

И вот так просто вы увидите результаты, которые довольно многообещающие для первой итерации, особенно учитывая, что процесс реализации занимает примерно 10 минут.

Хотя у читателей могут быть опасения по поводу этой реализации, некоторые критические замечания могут быть надуманными, в то время как другие могут быть обоснованными:

• Опасения по поводу слишком длинного полного текста и необходимости разбиения могут быть надуманными: модель jina-reranker-v1 может обрабатывать запросы длиной до 512 и документы произвольной длины, в то время как модель jina-colbert-v1 может обрабатывать до 8192 как для запросов, так и для документов. Поэтому подача полного текста в Reranker API, вероятно, не является необходимой. Обе модели эффективно справляются с длинными контекстами, так что беспокоиться не о чем. Разбиение на части, хотя и является, возможно, самым сложным и эвристическим аспектом пайплайна embedding-vector-search-rerank, здесь менее актуально. Однако более длинные контексты предполагают больше токенов, что может быть важно для платных пользователей нашего API. В этом примере, поскольку мы используем полный текст всех 233 статей, один запрос на переранжирование стоит более 300 тысяч токенов.
• Влияние необработанных данных по сравнению с очищенными на качество. Добавление очистки данных действительно может привести к улучшениям. Например, мы заметили, что просто удаление HTML-тегов (т.е. docs.map(item => item.html.replace(/<[^>]*>?/gm, '')) значительно улучшает качество рекомендаций для модели jina-reranker-v1, хотя эффект менее выражен для модели jina-colbert-v1. Это говорит о том, что наша модель ColBERT была обучена быть более устойчивой к зашумленному тексту, чем модель jina-reranker-v1.
• Влияние различных конструкций запросов на качество. В приведенной выше реализации мы напрямую использовали заголовок и отрывок текущей статьи как запрос. Является ли это оптимальным подходом к построению запроса? Улучшит ли добавление префикса вроде "What is the most related article to..." или

tagЭмпирическое исследование составления запросов

В нашем исследовании различных способов написания запросов с использованием Jina Reranker API, фокусируясь на топ-10 результатах, мы провели качественную оценку с помощью человеческой разметки (то есть оценивали сами), что имеет смысл, поскольку мы обладаем полным знанием всего контента, опубликованного на нашем сайте. Изученные стратегии составления запросов включали:

• Использование заголовка статьи, отрывка и комбинации заголовка + отрывка.
• Применение инструкций в стиле "промптов", таких как "больше похожих", "не такие" и "какая статья наиболее тесно связана?"

Чтобы проверить эффективность переранжировщика, мы выбрали две нетривиальные статьи в качестве тестовых запросов, стремясь найти наиболее релевантные статьи среди нашего обширного каталога из более чем 200+ постов — задача, вдохновленная поиском "иголки в стоге сена" в LLM. Ниже мы выделили эти "иголки" зеленым цветом для ясности.

tagИтоги

На основе результатов тестирования мы сделали несколько наблюдений и выводов:

1. Комбинация заголовка и отрывка дает наилучшие результаты переранжирования, причем отрывок играет значительную роль в повышении качества переранжирования.
2. Включение инструкций в стиле "промптов" не приводит к улучшению результатов.
3. Модель переранжирования в настоящее время не эффективно обрабатывает положительные или отрицательные квалификаторы. Термины вроде "больше похожих", "меньше похожих" или "не похожие" не понятны переранжировщику.

Выводы из пунктов 2 и 3 предлагают интересные направления для будущих улучшений переранжировщика. Мы считаем, что возможность использования промптов на лету для изменения логики сортировки могла бы значительно расширить возможности переранжировщика, открывая новый потенциал для таких приложений, как персонализированная курация/рекомендация контента.