深入探索DeepSearch与DeepResearch如何高效提升搜索质量。
核心内容聚焦在几个关键环节：利用迟分算法从长网页中提取最相关的文本段落；借助Reranker对收集到的URL进行智能排序；以及贯穿始终的80-20务实原则。
从长网页提取最优文本段：如何通过迟分（Late-Chunking）算法，从冗长的网页内容里精准定位最相关的信息片段。
对收集到的URL进行重排：如何利用重排器（Reranker），让LLM Agent在面对几百个URL时，能聪明地决定优先爬取哪个。
可能还有人记得我们上一篇里的结论：“在DeepSearch中，Embeddings模型仅适用于诸如STS（语义文本相似度）之类的查询去重，而Reranker甚至不在我们最初的DeepSearch编程实现中。”
现在回头看，这两类召回模型的价值其实被低估了。只是用法和常规认知大相径庭。整个搜索系统一直遵循“80-20”原则，不会为了照顾情绪价值，或证明自己作为Embeddings和Reranker提供商的市场存在感而硬上什么模型。80-20，非常务实，务实到了极点——只关心搜索系统最本质的需求。
经过数周反复试验和迭代，一个有意思的发现浮出水面：Embeddings和Reranker在DeepSearch/DeepResearch系统里，有一些非常规但极其有效的应用。
从长文本中选取最优文本段
问题的症结在于：用Jina Reader抓完网页内容后，需要把它作为一条知识塞进Agent的上下文里，供它推理。最简单的做法当然是整篇整篇往里扔，但Token成本和生成速度摆在那里，这显然不是最优解。在实际场景中，必须找出内容里和问题最相关的部分，只把这些片段作为知识添加上去。
需要说明的是，这里指的是即便用Jina Reader清理成干净的Markdown后，内容依然太长的情况。GitHub Issues、Reddit帖子、论坛讨论和博客文章这类长页面，是典型的重灾区。
基于LLM的筛选方案同样面临成本和延迟问题，所以得找找有没有更轻量级的模型：需要更小、更便宜，但仍然支持多种语言的模型。这是一个关键因素，毕竟没法保证问题或文档永远都是中文的。
一边是问题（原始查询或“信息差”问题），另一边是大段的Markdown内容，其中大部分是无关的。需要选出与问题最相关的片段。这很像RAG社区自2023年以来一直在努力解决的分块难题——用检索器模型只捡出相关块，放到上下文窗口中进行总结。
但这里的场景有两个关键区别：
- 有限数量文档中的有限数量的文本块。
假设每个块约500个Token，一个典型的长网页文档大约20万Token（中位数）到100万Token（99分位）。每一步用Jina Reader抓取4-5个URL，总共会产生几百个文本块。几百个向量，几百次余弦相似度计算，用Ja vaScript在内存里就能轻松搞定，完全不需要向量数据库。
- 需要连续的文本块来形成有效的知识摘要。
没法接受像[1-2, 6-7, 9, 14, 17, ...]这样由零散句子拼凑的摘要。更有用的知识摘要应该是[3-15, 17-24, ...]这样的，这样才能保持文本的连贯性。这样，LLM更容易从知识源中复制和引用，同时也能减少“幻觉”。
剩下的就是开发者们常抱怨的那些细节：每个文本块不能太长，因为向量模型处理不了太长的上下文；分块会导致上下文丢失，使得每个文本块的向量都独立同分布；以及，如何找到既保持可读性又保持语义的最佳边界？如果你经历过这些，应该能理解那种抓狂。
所幸，长话短说——使用 jina-embeddings-v3 的迟分（Late Chunking）恰好能解决这三个问题。“迟分”保留了每个块的上下文信息，对边界不敏感，而且 jina-embeddings-v3 本身在非对称多语言检索任务中是当前最先进的。具体实现原理可以参考相关论文，整体思路如下。
☞ 长文本Embedding模型中的“迟分”策略
? https://arxiv.org/pdf/2409.04701
这张图展示了摘要选择算法，它的工作原理类似于一维卷积（Conv1D）。过程是这样的：先把一个长文档分割成固定长度的块，然后用启用了迟分的 jina-embeddings-v3 把它们向量化。计算完每个块和问题之间的相似度分数后，一个滑动窗口在这些分数上移动，以找到平均值最高的窗口。
下面是示意代码，用迟分和类似“一维卷积”的平均池化，挑出与问题最相关的段落。
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 = a verage(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("nn");
}
调用Jina Embeddings API的时候，记得把 task 设置成 retrieval，打开 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上找到。可以参考相关代码仓库。
为“下一步阅读”进行URL排序
另一个问题：在每一次DeepSearch过程中，可能会从搜索引擎结果页（SERP）里收集一堆URL，每打开一个网页，又能顺藤摸瓜找出不少新链接，就算去重之后，也轻松上百个网址。同样地，一股脑全塞给LLM肯定不行，浪费宝贵的上下文长度不说，关键是发现LLM基本就是在瞎选。所以，得想办法引导LLM去挑出那些最有可能包含答案的URL。
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字段里把它们清除干净。
你可以把这个问题看作“上下文内的PageRank”，只不过是在一次会话中对数百个URL打分。
得分综合考虑多个因素：最后更新时间、域名出现的频率、网页路径结构，以及最重要的——与问题的语义相关性。不过，只能使用那些还没点开URL就能拿到的信息。
1. 频率信号：如果某个URL在不同信息源中多次出现，它的权重就会更高。另外，如果某个域名在搜索结果中经常出现，来自这个域名的URL也会被加分。一般来说，热门域名往往包含更权威的内容。
2. 路径结构：会分析URL的路径结构，来判断哪部分内容是聚集在一起的。如果多个网址都属于同一个路径层级，它们的分数会更高；但路径越深，分数加成会逐渐减少。
3. 语义相关性：用 jina-reranker-v2-base-multilingual 来评估问题和每个URL的文本信息（例如标题和摘要）的语义相关性，这是一个典型的重排序问题。每个URL的文本信息来自以下几个地方：
搜索引擎结果页（SERP）API返回的标题和摘要（https://s.jina.ai/ 这个接口，加上 'X-Respond-With': 'no-content'，可以只返回标题和摘要，不返回具体内容）。
页面上URL的锚文本（用 https://r.jina.ai 接口，设置 'X-With-Links-Summary': 'all'，可以返回页面内所有链接的摘要信息，也就是锚文本）。
4. 最后更新时间：DeepSearch的有些查询对时效性要求很高，所以一般来说，越新的URL价值越高。但困难在于，不具备像Google这样的大规模索引能力，很难准确判断网页的最后更新时间。这里用的是一套组合拳，综合考虑以下信号，最终给出一个带有置信度评分的时间戳，以便在需要时优先展示最新的内容：
SERP API提供的筛选功能（比如 s.jina.ai 的 tbs 参数，可以按时间过滤）。
HTTP Header信息分析（比如 Last-Modified 和 ETag 字段）。
元数据提取（比如 meta 标签和 Schema.org 时间戳）。
内容模式识别（识别HTML里可见的日期）。
针对特定CMS平台的指标（比如 WordPress, Drupal, Ghost 这些平台）。
5. 受限内容：某些社交媒体平台的内容是受限的，或者需要付费才能访问。不登录的话，没办法合法地获取这些内容。因此，会积极维护一份黑名单，把这些有问题的URL和域名都记录下来，降低它们的排名，避免在无法访问的内容上浪费计算资源。
6. 域名多样性：有时候，权重最高的几个网址都来自同一个域名，这会让DeepSearch陷入“局部最优”，影响最终结果的质量。为了提高结果的多样性，可以用一种“探索-利用”的策略：从每个域名下选择排名Top K的URL。
URL排序的完整代码实现，可以在相关代码仓库中找到。
- Crawl and read full content from URLs, you can get the fulltext, last updated datetime etc of any URL.
- Must check URLs mentioned in if any
- Choose and visit relevant URLs below for more knowledge. higher weight suggests more relevant:
+ weight: 0.20 "https://huggingface.co/docs/datasets/en/loading": "Load - Hugging FaceThis sa ves 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 ha ve 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/VQA v2, 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 ..."
总结
自2025年2月2日DeepSearch开源以来，有两个工程细节被证明能大幅提高搜索质量。有意思的是，这两个细节都以一种“上下文窗口内”的方式利用了多语言Embedding和Reranker模型。和这些模型通常需要的大规模预计算索引相比，这简直是降维打击。
这可能预示着，未来的搜索技术会朝着两极分化的方向发展。可以借用卡尼曼（Kahneman）的双过程理论来理解这个趋势：
快思考 Fast-think（grep、BM25、SQL）：快速、基于规则的模式匹配，计算量很小。
慢思考 Slow-think（LLM）：全面推理，具有深层次的上下文理解能力，但计算量很大。
中间地带 Mid-think（Embedding，Reranker等召回模型）：具备一定的语义理解能力，优于简单的模式匹配，但推理能力远不及LLM。
有一种可能性：两级分化的搜索架构正变得越来越流行：轻量级、高效的SQL/BM25负责检索的输入，然后直接把结果喂给LLM进行检索输出。中间层模型的剩余价值就转移到了特定的上下文窗口内的任务上：比如过滤、去重、排序等等。在这些场景下，如果用LLM做完整推理反而效率不高。
但无论如何，挑选关键片段 和 URL排序 仍然是直接影响DeepSearch/DeepResearch系统质量的根本环节。希望这些发现能帮你改进自己的系统。
查询扩展（Query expansion）是另一个决定质量的关键因素。正积极评估各种方法，从简单的基于Prompt的重写，到小模型，再到基于推理的方法。后续会分享在这个方向上的研究成果。