Jina Reranker API だけを使って記事レコメンデーションを構築する方法

2 週間前にReranker API を導入し、市場での主要な再ランキングソリューションとして確立しました。Jina Reranker は、様々なベンチマークで一般的なベースラインを上回る性能を示し、BM25 の結果と比較して最大 +33% のヒット率向上を実現しています。性能は印象的ですが、私が本当に興奮しているのは Reranker API の可能性です。そのシンプルなインターフェースは、クエリとドキュメントのリストを入力し、再ランク付けされた top-k の結果を直接出力することができます。これは理論的には、BM25、埋め込み、ベクトルデータベース、あるいはパイプラインを必要とせず、Reranker のみを使用して検索や推薦システムを構築し、エンドツーエンドの機能を実現できることを意味します。

このコンセプトに非常に興味をそそられ、実験せずにはいられませんでした。そこで、当社のウェブサイトのニュースページ（現在閲覧中のページなど）で、@ キーを押して「関連記事トップ 5 を取得」ボタンをクリックすると、jina-reranker-v1 モデルを使用して約 5 秒以内に（jina-colbert-v1 モデルの場合はやや長く）、現在の記事に最も関連する 5 つの記事が表示されます。すべての計算はオンラインで実行され、完全に 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

検索の関連性と RAG の精度を簡単に最大化

このように、実装にわずか 10 分程度で、最初のイテレーションとしては非常に有望な結果が得られます。

読者の方々はこの実装について懸念を抱くかもしれませんが、一部の批判は考えすぎかもしれず、一方で妥当な指摘もあります：

• 長すぎるフルテキストとチャンキングの必要性に関する懸念は考えすぎかもしれません：jina-reranker-v1 モデルは長さ 512 までのクエリと任意の長さのドキュメントを処理でき、jina-colbert-v1 モデルはクエリとドキュメントの両方で 8192 まで処理できます。したがって、フルテキストを Reranker API に入力することは必要ないかもしれません。両モデルは長いコンテキストを効率的に処理できるため、心配する必要はありません。チャンキングは、埋め込み-ベクトル検索-再ランクパイプラインの中で最も面倒で経験的な側面かもしれませんが、ここではあまり問題になりません。ただし、長いコンテキストはより多くのトークンを必要とし、これは API の有料ユーザーが考慮する必要があるかもしれません。この例では、233 記事すべてのフルテキストを使用するため、1 回の再ランククエリで 30 万以上のトークンを消費します。
• 生データとクリーニング済みデータの品質への影響。データクリーニングを追加することで、確かに改善が見込めます。例えば、単に 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..."のようなプレフィックスを追加することで、"最高の記事を推薦してくれたら 20 ドルのチップを渡します" のような、大規模言語モデルで使用されるようなプロンプトは有効なのでしょうか？これは、モデルの学習データ分布に関連する興味深い疑問を投げかけており、私たちは今後さらに探求していく予定です。
• クエリ構築に関する前述のポイントを発展させると、ユーザーの最近の閲覧履歴を使用したパーソナライズされた推薦など、クエリの構成能力をさらに調査することは興味深いでしょう。特に、システムがクエリ内の肯定的な例だけでなく否定的な例も理解できるか、例えば NOT_LIKE 演算子、"この記事のような内容は推薦しないで" や "このような記事は減らしてほしい" などが理解できるかどうかは興味深い点です。次のセクションでこれについてさらに掘り下げていきます。

tagクエリ作成に関する実証研究

Jina Reranker API を使用したさまざまなクエリ作成の探求において、上位 10 件の結果に焦点を当て、人間によるラベリング（つまり、私たち自身による評価）を通じて定性的な評価を行いました。これは、私たちがウェブサイト上のすべてのコンテンツについて完全な知識を持っているため理にかなっています。私たちが検証したクエリ作成の戦略は以下の通りです：

• 記事のタイトル、抜粋、およびタイトル + 抜粋の組み合わせを使用する。
• "more like this"、"not like this"、"what is the most closely related article?" などの「プロンプト」のような指示を採用する。

リランカーの有効性をテストするため、200 以上の投稿から成る広範なカタログの中から最も関連性の高い記事を特定するという、LLM における「干し草の中の針」にヒントを得たチャレンジとして、2 つの非自明な記事をクエリ対象として選択しました。以下では、これらの「針」を分かりやすくするため緑色でハイライトしています。

tagまとめ

テスト結果に基づいて、以下の観察と要約を行いました：

1. タイトルと抜粋を組み合わせることで最良のリランキング結果が得られ、抜粋がリランキングの品質を向上させる重要な役割を果たしています。
2. 「プロンプト」のような指示を組み込んでも改善は見られませんでした。
3. 現在のリランカーモデルは、肯定的または否定的な修飾子を効果的に処理できません。"more like"、"less like"、"not like" などの用語はリランカーには理解できません。

ポイント 2 と 3 から得られた知見は、リランカーの将来の改良に向けて興味深い方向性を提供しています。並べ替えのロジックを変更するためのオンザフライプロンプティングを可能にすることで、リランカーの機能が大幅に拡張され、パーソナライズされたコンテンツのキュレーション/推薦など、新たな潜在的なアプリケーションが実現できると考えています。