原作者：Amanda Iglesias Moreno

当通过 LLM API 检索信息时，一个常见错误是：如果 AI 搜索工具给出的结果不好，就升级推理模型。

但大多数时候，这种做法是错误的。

在实践中，要实现良好的信息检索，仅仅拥有强大的推理能力是不够的；模型在网上找到的信息质量，远比模型在分析信息和提取结论时有多强大更重要。

如果信息根本没有被检索出来，那么你的推理能力就是无用的。

在本文中，我们将详细解释：当通过 API 使用 LLM 在网络上搜索信息时，检索和推理之间有什么区别。这里会以 Perplexity 的 Sonar API 为例，并说明如何提升二者的质量。

我们将探讨常见错误，也会介绍一些策略和技术，帮助你更有效地从网络上收集信息。

搜索与推理这对组合

当人们使用 LLM 在线收集信息时，往往会低估检索组件的重要性。

他们在使用 RAG 系统时也会犯同样的错误。

用户常常认为，如果结果不好，那么解决方案就是升级推理模型。

他们错了。

在大多数情况下，如果结果不好，是因为信息没有被正确地从网上检索出来。

成功的网页搜索同时需要有效的搜索和推理。

二者的区别在于：搜索，是获得信息；推理，是恰当地分析这些信息，并从中得出结论。

搜索组件会从网络上收集相关的外部知识，例如网页、文档和报告。

推理组件则会分析这些文档中可用的信息，提供一个简洁的答案，同时剔除文档中同样存在的所有无关信息。

LLM 如何处理网页搜索：fast search 与 pro search

要进行有效的信息检索，我们首先需要理解 LLM 是如何处理网页搜索的。

信息搜索可以只通过一次搜索完成：LLM 会把你的用户查询转换成一到两个适合关键词搜索的查询语句，提交给搜索引擎，然后从网络上获得摘要片段，并用这些片段生成答案。

在其他情况下，LLM 不只是把你的查询改写后交给搜索引擎，而是会把它拆解成多个子查询，并运行多次搜索，以收集更多相关信息。

这些搜索可以并行进行，也可以顺序进行。

模型会评估中间结果，并在必要时运行后续查询。

随后，只有从网站中检索出的相关文本块，才会被 LLM 用来生成最终答案。

LLMs如何执行搜索

这正是 Perplexity 的 Sonar API 中 search_type: "fast" 与 search_type: "pro" 之间的区别：

fast 是单轮搜索，并返回分块结果。

pro 则会进行顺序查询，并返回经过排序的分块结果。

其他 API，例如 Gemini，也提供了类似的 fast 和 pro 搜索模式。

选择 search_type: "fast" 还是 search_type: "pro"，取决于你想收集的信息有多复杂。

对于简单问题，单轮搜索就足够了。

例如，询问 Python 3.9 是什么时候发布的，只需要一次查询就能得到准确答案。

但对于更复杂的问题，例如验证某个特定企业是否提供多种服务，就需要多查询方法，也就是收集多个

来源，以便得到最终回答。

无论你使用哪种搜索类型，都不要忘记：用户提示词始终是收集准确结果的最关键因素。

让我解释一下为什么。

用户提示词：每一次网页搜索的基础

一个经过优化的查询，也就是用户提示词，对于成功的信息检索至关重要。

LLM 会把你的用户提示词当作蓝图，用来生成搜索查询。

模糊或不完整的用户提示词，会导致子查询缺乏焦点，最终无法收集到包含目标信息的文本块。

如果你的用户提示词很模糊，那么无论模型运行多少次查询，你都很可能找不到需要的信息。

假设我们想收集 X 公司的产品或服务。

像“告诉我更多关于 X 公司的信息”这样的提示词太宽泛了，没有给模型任何明确焦点。

而“X 公司自 2020 年以来推出了哪些产品或服务？”这样的提示词，则会产生目标更明确的子查询，并返回直接相关的结果。

用户提示词在搜索中的重要性

一个常见错误是：在 system prompt 中指定你想搜索什么，然后在 user prompt 中使用一个模糊的问题。

system prompt 应该定义规则，例如角色定义、输出格式、语气等。

而你真正想问的问题，应该写在 user prompt 中。

因为触发查询生成的是 user prompt。

请始终记住：花时间定义一个聚焦的用户提示词。

优化网页搜索的策略

在接下来的部分，我会介绍一些可以用来优化 LLM 网页搜索的策略，并以 Perplexity API 作为参考模型。

不过，同样的原则也可以应用于其他 LLM。

1. 定义清晰、简洁的用户提示词

在网页搜索中，清晰、简洁的用户提示词是最重要的因素。

如果你的用户提示词设计得不好，那么生成出来的查询就无法收集到你想要的信息。

花时间写一个好的用户查询。

2. 评估你想收集的信息有多难获取

并不是所有问题都需要相同的搜索深度。

简单问题只需要一个查询就能回答。

而更复杂的问题，则需要多查询方法，甚至需要 agentic query capabilities，也就是能够迭代式重新定义搜索的智能体查询能力。

对于使用 Perplexity API 进行网页搜索来说，这就意味着需要在 search_type: "fast" 和 search_type: "pro" 之间做选择。

重要的是：

不要在不需要复杂搜索能力的时候使用它们。

因为它们会消耗更多 token，并且显著增加每次请求的成本。

search_type 参数会影响每次请求的费用，这笔费用是在 token 成本之外另行收取的，并且会随着上下文大小，也就是 low、medium 或 high 而变化。你可以在下表中看到这一点。

Per-Request Fees by Search Type with Sonar（作者制图）

除了 fast 和 pro 两种搜索类型之外，Perplexity API 还引入了一个 context 参数，它可以帮助复杂的信息检索获得更好的结果。

3. 为复杂信息检索增加信息源数量

search_type，也就是 fast 和 pro，控制的是搜索如何执行。

换句话说，它控制运行多少个查询，以及模型是否会在查询之间进行推理，从而调整查询策略。

相比之下，search_context_size 控制的是检索多少文档，并因此决定有多少文档会被传递给推理模型，用来生成答案。

它们是相互独立但互补的参数。

对于复杂信息检索，你可以把 pro search 和 high context size 结合起来使用。

下表解释了不同的组合策略。

我的建议是：

首先分析你的检索需求到底有多复杂。

因为正如定价表中所显示的，随着这两个参数复杂度的增加，成本也会上升。

How search_type and search_context_size Work Together（作者制图）

4. 运行测试用例，评估哪些参数效果最好

我推荐的策略是：

从你的数据集中选择一个小样本，并测试不同检索策略的组合，以评估在不同策略下结果质量如何。

一旦你找到了表现最好的设置，就可以用这些参数运行整个数据集。

对于你的具体用例来说，这是一种在质量和成本之间取得平衡的好策略。

啊，Voilà！通过遵循这些策略，你可以在平衡质量和成本的同时，获得非常好的检索结果。

并且永远不要忘记：

设计良好的用户提示词，仍然是最重要的事情。

总结

使用 LLM 进行网页搜索的用户，往往会低估检索组件的重要性，并经常认为结果不好是因为模型的推理能力不足。

本文解释了在进行网页搜索时，搜索与推理之间的区别，也介绍了你可以采用哪些策略，在不让简单搜索承担过高成本的情况下，提升复杂信息检索的能力。

永远不要忘记：找到，胜过思考。

感谢阅读！