Han Xiao
DeepSearch/DeepResearch の実装ガイドを既にお読みの方は、品質を大きく向上させる詳細についてさらに深く掘り下げていきましょう。この投稿では、2 つの重要な課題に焦点を当てます：長いウェブページからスニペットを選択するための埋め込みの活用とクロールする URL の優先順位付けにリランカーを使用することです。
以前の結論で「埋め込みは STS タスク（意味的テキスト類似性）のようなクエリの重複排除にのみ有用で、リランカーは当初の DeepSearch 実装には含まれていなかった」と述べたことを覚えている方もいるでしょう。しかし、実は両方とも依然として非常に価値があることがわかりました - ただし、従来の期待とは異なる方法で。私たちは常に可能な限りシンプルな方法を追求してきました。埋め込みやリランカーのプロバイダーとしての存在価値を正当化するためだけに、コンポーネントを追加することはしません。私たちは検索が本質的に必要とするものに基づいています。
数週間の実験と改良を重ねた結果、DeepSearch/DeepResearch システムにおける両者の一般的ではないが効果的な使用方法を発見しました。これらを適用することで、Jina DeepSearch の品質を大幅に向上させました（ぜひお試しください）。この分野で働く実践者の皆様と、これらの知見を共有したいと思います。
tag長いコンテンツからスニペットを選択する
問題は次のとおりです：Jina Reader を使用してウェブページのコンテンツを読み取った後、それを推論のためにエージェントのコンテキストに知識項目として追加する必要があります。完全なコンテンツを LLM のコンテキストウィンドウにダンプすることが最も簡単な方法ですが、トークンコストと生成速度を考慮すると最適ではありません。実際には、コンテンツのどの部分が質問に最も関連しているかを特定し、それらの部分のみをエージェントのコンテキストに知識として選択的に追加する必要があります。
LLM ベースのフィルタリングには同様のコストと遅延の問題があるため、より小さなモデルのソリューションを見つけましょう：より小さく安価で、しかもマルチリンガルなモデルが必要です - クエリもドキュメントも常に英語であるとは限らないため、これは重要な要素です。
一方にはクエリ（元のクエリまたはギャップクエリ）があり、もう一方には大部分が関連性のない大きなマークダウンコンテンツがあります。クエリに最も関連性の高いスニペットを選択する必要があります。これは 2023 年以来 RAG コミュニティが取り組んできたチャンキングの問題に似ています - 要約のためのコンテキストウィンドウに配置する関連チャンクのみを retriever モデルを使用して取得することです。ただし、私たちのケースには 2 つの重要な違いがあります：
- 限られた数のドキュメントからの限られたチャンク。各チャンクが約 500 トークンを含む場合、典型的な長いウェブドキュメントは約 200,000 トークン（p50）から 1,000,000 トークン（p99）を含み、各ステップで Jina Reader を使用して 4-5 個の URL を取得すると、数百のチャンク - つまり数百の埋め込みベクトルと数百のコサイン類似度が生成されます。これはベクターデータベースなしで JavaScript のメモリ内で簡単に管理できます。
- 効果的な知識スニペットを形成するために連続したチャンクが必要です。
[1-2, 6-7, 9, 14, 17, ...]のような散在する文を組み合わせたスニペットは受け入れられません。より有用な知識スニペットは[3-15, 17-24, ...]のようなパターンに従い、常に連続したテキストを維持します。これにより、LLM が知識ソースからコピーして引用しやすくなり、幻覚が減少します。
残りは実践者が指摘してきた注意点すべてです：埋め込みモデルは長いコンテキストを適切に処理できないため、各チャンクは長すぎてはいけません；チャンキングはコンテキストの損失を引き起こし、チャンク埋め込みを i.i.d にします；そして読みやすさとセマンティクスの両方を維持する最適な境界キューをどのように見つけるのか？これらの問題について知っているなら、RAG の実装でこれらの問題に悩まされた経験があるでしょう。
しかし長い話を短くすると - late-chunking と jina-embeddings-v3 が 3 つの問題すべてを見事に解決します。Late chunking は各チャンクのコンテキスト情報を維持し、境界キューに影響されにくく、jina-embeddings-v3 自体が非対称な多言語検索タスクで SOTA です。詳細に興味のある読者は私たちのブログ投稿や論文をご覧ください。以下が全体的な実装です。
Conv1Dと同様に動作するスニペット選択アルゴリズムを示しています。プロセスは長いドキュメントを固定長のチャンクに分割することから始まり、その後 late-chunking トグルをオンにしたjina-embeddings-v3で埋め込みます。各チャンクとクエリ間の類似度スコアを計算した後、スライディングウィンドウが類似度スコアを移動して、最高の平均値を持つウィンドウを見つけます。
Han Xiao
Saba Sturua
Michael Günther
function cherryPick(question, longContext, options) {
if (longContext.length < options.snippetLength * options.numSnippets)
return longContext;
const chunks = splitIntoChunks(longContext, options.chunkSize);
const chunkEmbeddings = getEmbeddings(chunks, "retrieval.passage");
const questionEmbedding = getEmbeddings([question], "retrieval.query")[0];
const similarities = chunkEmbeddings.map(embed =>
cosineSimilarity(questionEmbedding, embed));
const chunksPerSnippet = Math.ceil(options.snippetLength / options.chunkSize);
const snippets = [];
const similaritiesCopy = [...similarities];
for (let i = 0; i < options.numSnippets; i++) {
let bestStartIndex = 0;
let bestScore = -Infinity;
for (let j = 0; j <= similarities.length - chunksPerSnippet; j++) {
const windowScores = similaritiesCopy.slice(j, j + chunksPerSnippet);
const windowScore = average(windowScores);
if (windowScore > bestScore) {
bestScore = windowScore;
bestStartIndex = j;
}
}
const startIndex = bestStartIndex * options.chunkSize;
const endIndex = Math.min(startIndex + options.snippetLength, longContext.length);
snippets.push(longContext.substring(startIndex, endIndex));
for (let k = bestStartIndex; k < bestStartIndex + chunksPerSnippet; k++)
similaritiesCopy[k] = -Infinity;
}
return snippets.join("\n\n");
}問題に関して最適なスニペットを選択するために、後期チャンキングと Conv1D のような平均プーリングを使用します。
Jina Embeddings API を呼び出す際は、以下のように retrieval task、late_chunking、truncate を設定してください：
await axios.post(
'https://api.jina.ai/v1/embeddings',
{
model: "jina-embeddings-v3",
task: "retrieval.passage",
late_chunking: true,
input: chunks,
truncate: true
},
{ headers }); 質問を埋め込む際は、task を retrieval.query に変更し、late_chunking をオフにしてください
完全な実装は Github で確認できます：
jina-ai
tag次に読むべき URL のランク付け
問題は次の通りです：DeepSearch セッション中に、検索エンジン結果ページ（SERP）から多くの URL を収集し、個々のウェブページを読むたびにさらに多くの URL（ページ内のリンク）を発見することになります。ユニークな URL の総数は簡単に数百に達する可能性があります。ここでも、すべての URL を単純に LLM のコンテキストに直接投入するのは非効率です - 貴重なコンテキストウィンドウのスペースを無駄にし、さらに問題なのは、LLM が本質的にランダムに URL を選択することがわかっています。 必要な回答を含む可能性が最も高い URL に LLM を導くことが重要です。
curl https://r.jina.ai/https://example.com \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-H "X-Retain-Images: none" \
-H "X-Md-Link-Style: discarded" \
-H "X-Timeout: 20" \
-H "X-With-Links-Summary: all"DeepSearch で Jina Reader を使用してページをクロールする最適なオプション。これにより、すべてのページ内リンクが別の links フィールドに収集され、content フィールドから削除されます。
この問題を、セッション中に数百の URL の重み付けが必要なコンテキスト内 PageRank として考えてください。私たちは、最終更新時間、ドメインの頻度、パス構造、そして最も重要なクエリへの意味的関連性を組み合わせて複合スコアを作成し、それに基づいて URL のランク付けを行います。URL を実際に訪問する前に利用可能な情報のみを使用することを忘れないでください：
頻度シグナル：異なるソースで複数回出現する URL は追加の重みを受けます。検索結果で頻繁に出現するドメインの URL はブーストを受けます。人気のあるドメインには権威のあるコンテンツが含まれていることが多いためです。
パス構造：コンテンツクラスターを識別するために URL パスを分析します。共通のパス階層内の URL はより高いスコアを受け、より深いパスには減衰係数が適用されます。
意味的関連性：質問と各 URL のテキスト情報の間の意味的関連性を評価するために jina-reranker-v2-base-multilingual を使用します。これは典型的な再ランキング問題です。各 URL のテキスト情報は以下から得られます：
- SERP API 結果のタイトルとスニペット（
https://s.jina.ai/と'X-Respond-With': 'no-content'を使用） - ページ内 URL のアンカーテキスト（
https://r.jina.aiと'X-With-Links-Summary': 'all'を使用）
最終更新時間：一部の DeepSearch クエリは時間に敏感であるため、最近更新された URL は古い URL よりも価値があります。Google のような主要な検索エンジンではない場合、最終更新時間を確実に判断することは困難です。私たちは、必要に応じて新しいコンテンツを優先する信頼度スコア付きのタイムスタンプを提供する、以下のシグナルを組み合わせた多層アプローチを実装しています。
- SERP API フィルター（s.jina.ai の最新性でフィルタリングする
tbsパラメータなど） - HTTP ヘッダー分析（Last-Modified、ETag）
- メタデータ抽出（メタタグ、Schema.org タイムスタンプ）
- コンテンツパターン認識（HTML 内の可視日付）
- WordPress、Drupal、Ghost などのプラットフォーム固有のインジケータ
ゲートコンテンツ：ソーシャルメディアプラットフォームの一部のコンテンツはゲート制または単純に有料壁の背後にあり、ログインせずに、または利用規約に違反せずに、このコンテンツを取得する正当な方法はありません。アクセスできないコンテンツに時間を無駄にしないよう、問題のある URL とホスト名のリストを積極的に維持し、それらのランキングを下げるべきです。
ドメインの多様性：場合によっては、最も重み付けの高い URL がすべて同じホスト名から来ていることがあり、これによって DeepSearch がローカルな最適解に陥り、最終的な結果の品質が低下する可能性があります。上記の例では、上位の URL がすべて StackOverflow からのものです。多様性を改善するために、各ホスト名から上位 k 個のランク付けされた URL を選択する探索-活用アプローチを実装できます。
URL ランキングの完全な実装は Github で確認できます。
jina-ai
<action-visit>
- Crawl and read full content from URLs, you can get the fulltext, last updated datetime etc of any URL.
- Must check URLs mentioned in <question> if any
- Choose and visit relevant URLs below for more knowledge. higher weight suggests more relevant:
<url-list>
+ weight: 0.20 "https://huggingface.co/docs/datasets/en/loading": "Load - Hugging FaceThis saves time because instead of waiting for the Dataset builder download to time out, Datasets will look directly in the cache. Set the environment ...Some datasets may have more than one version based on Git tags, branches, or commits. Use the revision parameter to specify the dataset version you want to load ..."
+ weight: 0.20 "https://huggingface.co/docs/datasets/en/index": "Datasets - Hugging Face🤗 Datasets is a library for easily accessing and sharing datasets for Audio, Computer Vision, and Natural Language Processing (NLP) tasks. Load a dataset in a ..."
+ weight: 0.17 "https://github.com/huggingface/datasets/issues/7175": "[FSTimeoutError] load_dataset · Issue #7175 · huggingface/datasetsWhen using load_dataset to load HuggingFaceM4/VQAv2, I am getting FSTimeoutError. Error TimeoutError: The above exception was the direct cause of the following ..."
+ weight: 0.15 "https://github.com/huggingface/datasets/issues/6465": "`load_dataset` uses out-of-date cache instead of re-downloading a ...When a dataset is updated on the hub, using load_dataset will load the locally cached dataset instead of re-downloading the updated dataset."
+ weight: 0.12 "https://stackoverflow.com/questions/76923802/hugging-face-http-request-on-data-from-parquet-format-when-the-only-way-to-get-i": "Hugging face HTTP request on data from parquet format when the ...I've had to get the data from their data viewer using the parquet option. But when I try to run it, there is some sort of HTTP error. I've tried downloading ..."
</url-list>
</action-visit>URL の重みをエージェントのコンテキストに入れ、LLM にその重みを尊重するよう指示することを忘れないでください。
tag結論
DeepSearch システムの 2025 年 2 月 2 日のリリース以降、品質を大幅に向上させた 2 つの実装の詳細を発見しました。興味深いことに、どちらも多言語エンベディングとリランカーを「インコンテキスト」方式で活用しており、これらのモデルが通常必要とする事前計算されたインデックスよりもはるかに小規模で動作します。これが私たちが最初に見落としていた理由です。
これは検索技術の未来における興味深い二極化を示唆しています。カーネマンの二重過程理論に類似したフレームワークを考えてみましょう：
- 高速思考（grep、BM25、SQL）：最小限の計算要求で、素早く、ルールに基づいたパターンマッチング。
- 遅速思考（LLM）：深い文脈理解を伴う包括的な推論で、かなりの計算を必要とする。
- 中速思考（エンベディング、リランカー）：リンボ状態？ 単純なパターンマッチングには高度/意味的すぎるが、真の推論能力は欠如。
軽量で効率的な SQL/BM25 が初期コンテンツ検索を処理し、直接強力な LLM に送って深い処理を行う二分化されたアーキテクチャの人気を目の当たりにしているのかもしれません。これらの LLM は、以前は特殊な中間レベルのモデルを必要とした意味的機能を increasingly 組み込んでいます。中速思考モデルの残された役割は、フィルタリング、重複排除、完全な推論が非効率的な場合の限定的な操作など、特殊なインコンテキストタスクにシフトしています。
それにもかかわらず、重要なスニペットの選択と URL のランク付けは、DeepSearch/DeepResearch システムの品質に直接影響を与える基本的なコンポーネントであり続けています。私たちの知見が皆様の実装の改善のきっかけとなることを願っています。
クエリ拡張は引き続き重要な品質決定要因です。基本的なプロンプトベースの書き換えから、小規模言語モデルや推論ベースの手法まで、複数のアプローチを積極的に評価しています。この分野における新しい発見にご期待ください。続報をお待ちください。
