AI搜索体验与成本如何平衡？细粒度努力程度选择器技术解析

这次的话题不是又一个本地推理模型，而是 Perplexity 在 AI 搜索里做的一个细节功能：开发新的粒度“努力程度选择器”。所谓“努力程度”，通俗讲就是让系统在回答一个问题之前愿意花多少计算量——是先给一个快速答案，还是先拆解问题、多次搜索、逐步验证，再给你一份更完整的结论。

这个“选择器”本身不算全新概念，OpenAI 在推理模型里提供过reasoning_effort参数，Anthropic 也有扩展思考预算。但 Perplexity 把它放到 AI 搜索场景中，并强调“新粒度”，意味着它可能不只是三档开关，而是更细的任务难度控制：什么类型的问题用低档，什么类型的问题用高档，甚至可以细化到每个搜索请求分配多少推理预算。

这篇文章不涉及本地部署，也不需要什么显卡。我会先讲清楚“努力程度选择器”到底是什么、为什么 AI 搜索需要它；再从技术角度拆解细粒度实现思路；然后给出一套通用 API 接入和测试验证方法；最后聊一聊成本控制、资源消耗和常见坑。适合正在做 AI 搜索集成、Agent 应用和 RAG 系统的工程师阅读。

1. 核心概念速览

“努力程度选择器”这个名称，技术本质是把一个搜索任务要消耗的推理算力显式暴露给用户。传统搜索引擎只给一个相关性排序，传统聊天机器人只给一个生成结果。而 AI 搜索的每个回答可能包含多轮网页检索、多次阅读抽取、多次自我校验，计算量是弹性的。选择器就是要管理这个弹性空间：简单问题少花钱，复杂问题不省力。

2. 为什么 AI 搜索需要“努力程度”选择器

如果你用过 Perplexity 这类产品，会发现同一个问题可能有两种完全不同的处理路径。问“今天北京天气如何”和问“对比三篇论文在扩散模型采样加速上的方法差异”，系统做的内部步骤完全不一样，前者可能一次搜索就能回答，后者需要拆解问题、多路搜索、交叉验证，最后还要组织长答案。这就是“努力程度”的差异。

从系统设计角度看，做这个选择器要解决的痛点有三类。

延迟与体验的平衡。高档位必然带来更长的响应时间。如果所有请求都用最高档，用户等一个简单问题可能要几十秒，体验直接崩。如果所有请求都用低档，深度研究问题又得不到靠谱答案。选择器让用户根据问题难度主动选择档位，等于把“延迟预算”的控制权交给了用户业务侧。

成本控制。AI 搜索的成本不只是生成 token，还包括搜索请求次数、网页抓取、内容抽取、中间推理 token。一个 agentic 搜索可能发出 5 到 10 次搜索请求，这也是钱。细粒度选择器可以约束单次任务最多搜索几次、最多阅读多少网页、最多生成多少推理 token，从而把成本控制在业务可接受范围内。

质量与可信度。低努力可能只给一个表面答案，高努力会给出结构化分析、多方来源对比和明确的结论边界。深度研究类用户愿意为质量等待；简单问答用户则希望快速结束。没有粒度控制，产品很难同时满足这两类需求。

从行业现状来看，Perplexity 做这个方向是顺理成章的。搜索场景天然存在“简单查询”和“复杂任务”的分布差异，一个固定的推理预算无法同时覆盖两端。新粒度意味着系统要在“几乎不用推理”和“完整 agentic 推理”之间拉开更多可选档位，让用户或上层应用可以更精确地分配资源。

3. 细粒度控制的实现思路

“新粒度”如果落到工程实现上，大致有四种设计方向。实际产品可能会组合使用，这里按通用原理拆解。

3.1 离散档位

最简单的方式，类似推理模型中常见的low / medium / high，在 AI 搜索场景里可以扩展为更多档位，比如fast / normal / deep / research。每一档对应一组内部配置，例如搜索次数上限、阅读网页数上限、是否允许多轮追问、最终答案目标长度。

离散档位的优点是语义明确、容易实现、前端也好做。缺点是不够精准：用户很难说清“今天这个问题到底算 medium 还是 high”。所以更细粒度的做法是按任务类型自动映射，而不是让用户做选择题。

3.2 连续数值

把努力程度变成一个连续值，比如 0 到 10，或者 0 到 1。系统内部将数值映射到搜索预算、推理预算和输出长度上。连续数值的好处是上层应用可以结合任务难度动态调参，比如根据 query 复杂度打分后直接映射到对应数值。

这里可以给一个 JSON 配置示例，模拟连续数值到任务配置的映射逻辑：

{ "effort_level": 7, "effort_config": { "max_search_rounds": 6, "max_webpages_per_search": 8, "max_reasoning_tokens": 4000, "allow_follow_up": true, "max_output_tokens": 1600, "timeout_seconds": 45 } }

这段配置的逻辑是：当 effort 值为 7 时，系统允许最多 6 轮搜索，每轮最多 8 个网页，推理 token 上限 4000，允许追问，最终答案目标长度约 1600 token，超时上限 45 秒。真正的产品中，这个映射表会由服务端配置，而不是由客户端传一堆参数。

3.3 预算型控制

与档位不同，预算型控制直接把“努力”定义为可量化的资源上限。常见参数包括：最大推理 token 数、最大搜索次数、最大阅读网页数、最大执行时间。这种方式更适合 API 开发者，因为可以预先估算成本。

比如一个匿名化的接口请求参数示意：

{ "query": "对比 LoRA 和 QLoRA 在显存占用上的区别", "budget": { "max_searches": 5, "max_read_pages": 10, "max_reasoning_tokens": 5000, "max_total_time_seconds": 60 } }

预算控制的问题是用户很难感知“5000 推理 token”到底意味着什么。所以产品前台仍然需要档位或评分这样的抽象层，预算只是后端转换结果。

3.4 自动路由与手动覆盖

更完整的形态是“系统自动选择档位 + 用户可覆盖”。系统先对 query 做复杂度分类，简单事实性问题走低档，多步推理、对比分析、时效性敏感问题走高档。用户可以在界面上手动拉高或降低档位，覆盖自动决策。

从标题“开发新粒度努力程度选择器”来看，Perplexity 很可能就是在往这个方向走：不是简单让用户选低中高，而是提供一个更细腻的资源分配界面，同时让高级用户和 API 调用方获得更精准的控制能力。具体细节还是要以官方发布为准，这里只是结合行业通用实现逻辑做推演。

4. 外部 API 接入：通用 reasoning effort 调用示例

Perplexity 有面向开发者的 Sonar API 体系，但本篇文章不假设其官方接口的具体字段。这里给出目前业界通用的 reasoning effort 接入方式，如果你要对接 Perplexity 或类似 AI 搜索 API，可以按同样的思路去适配。

先看一个基于 OpenAI 风格接口的普通推理请求：

from openai import OpenAI client = OpenAI( api_key="your_api_key", base_url="https://api.example.com/v1" ) response = client.chat.completions.create( model="reasoning-search-model", messages=[ {"role": "user", "content": "解释一下 RAG 系统中的混合检索为什么比纯向量检索更稳"}, ], reasoning_effort="medium", max_completion_tokens=2048 ) print(response.choices[0].message.content)

如果 API 支持更细粒度的 effort 数值，可以传一个枚举值或数值字符串：

curl https://api.example.com/v1/chat/completions \ -H "Authorization: Bearer YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "reasoning-search-model", "messages": [ {"role": "user", "content": "分析三家云厂商对象存储的计费差异，给出选型建议"} ], "reasoning_effort": "high", "search_budget": 5, "max_completion_tokens": 4096 }'

返回结果可能会包含一个reasoning字段，用于查看模型的思考过程和检索摘要，便于调试：

{ "id": "resp_12345", "choices": [ { "message": { "role": "assistant", "content": "最终答案内容...", "reasoning": [ {"stage": "query_analysis", "detail": "将问题拆解为计费项对比"}, {"stage": "search_plan", "detail": "计划检索 3 次，覆盖三家厂商官方文档"}, {"stage": "validation", "detail": "检查引用链接是否可访问"} ] } } ], "usage": { "prompt_tokens": 240, "completion_tokens": 1800, "reasoning_tokens": 1200, "total_searches": 3 } }

注意：上述模型名、字段名都是通用示例，真实接口需要以 Perplexity 官方 API 文档为准。但接入逻辑是通用的：先确认有没有reasoning_effort或等价参数，再确认返回值里是否带reasoning和检索统计字段，最后用这些字段判断“努力”是否真的发生了。

如果你使用的 API 不支持这种风格的参数，也可以采用另一种方式：把努力程度写进 prompt，约束系统的搜索和推理行为。比如：

你是一个深度研究助手。本次任务请按照 high effort 模式执行： 1. 先拆解问题，列出需要验证的子问题。 2. 至少进行 3 次独立搜索。 3. 每次搜索后检查来源可靠性。 4. 最终答案需要包含对比维度、证据和限制条件。

这种方法不依赖特殊参数，兼容性更好，但稳定性不如原生 effort 配置，因为模型可能忽略 prompt 约束。工程上建议优先使用原生参数。

5. 在 AI 搜索产品中如何设计“努力程度”档位

这一节从系统设计角度展开。如果你自己也在做 AI 搜索应用，可以参考以下设计思路。

5.1 前端：让用户低成本理解档位

“努力程度”不能直接暴露成技术参数。普通用户不理解“max_reasoning_tokens=3000”是什么意思。设计上应该用任务场景来描述档位，比如：

如果要做更细粒度，可以在 deep 和 research 之间加滑条，用任务时长预估提示用户，例如“预计多花 20 秒，检索更多来源”。

5.2 后端：统一配置中心

不要在前端把每个档位的细节写死。后端起一个配置中心，按档位返回搜索轮数、网页数、推理 token 上限、超时时间。这样产品调参时不用发版，只需要修改云端配置。

伪代码示例：

EFFORT_CONFIG = { "fast": {"max_searches": 1, "reasoning_tokens": 500, "timeout": 15}, "normal": {"max_searches": 3, "reasoning_tokens": 2000, "timeout": 30}, "deep": {"max_searches": 6, "reasoning_tokens": 5000, "timeout": 60}, "research": {"max_searches": 10, "reasoning_tokens": 9000, "timeout": 120}, } def resolve_effort(request): if request.get("effort"): return EFFORT_CONFIG[request["effort"]] score = classify_query_complexity(request["query"]) if score < 0.3: return EFFORT_CONFIG["fast"] if score < 0.6: return EFFORT_CONFIG["normal"] if score < 0.85: return EFFORT_CONFIG["deep"] return EFFORT_CONFIG["research"]

这个配置中心还应该支持按用户等级、业务线、时间段动态调整，比如高峰期将默认档位降一档，降低系统压力。

5.3 缓存策略：努力程度和缓存需要绑定

同一个 query 在高档位和低档位下，答案质量差异很大。缓存键不能只包含 query，还要包含 effort 档位。如果你做了缓存，建议把档位写进缓存 key 的一部分：

cache_key = f"search:{effort}:{normalized_query}:{lang}"

不然会出现一个严重问题：用户先用 low 档搜索过，缓存了简略答案；下一次用 high 档搜索同一个问题，命中了 low 档缓存，努力程度选择器等于失效。更稳妥的做法是，只有在当前档位大于等于缓存档位时才允许命中。

5.4 模型路由

细粒度档位还意味着需要多模型配合。低档可以走更小的模型，响应快、成本低；高档走更大更强的模型，甚至可以走带推理能力的模型。做一个路由层，把档位映射到具体模型策略。比如 fast 档直接用小模型加少量检索，research 档启用大模型加 agentic 搜索循环。

6. 功能测试与效果验证

无论你是使用 Perplexity API，还是在自研搜索系统中实现类似功能，都需要一套验证方法。重点不是“档位有没有生效”，而是“更高努力是否真的带来更好的结果”。

6.1 测试问题集设计

建议准备三组测试问题：

• 简单事实类：适合 fast。例如“Python 3.12 什么时候发布的”“什么是 RFC 9110”。预期答案短、准确、快速。
• 中等分析类：适合 normal 或 deep。例如“解释向量数据库中的 HNSW 索引和 IVF 索引主要区别”“A/B 测试中如何规避新奇效应”。预期答案包含多个维度，有来源支撑。
• 深度研究类：适合 research。例如“对比 2024 年发表的 5 篇长文本 RAG 论文，分析它们的评估方法差异”“评估三家主流向量数据库在亿级数据下的写入性能，给出选型建议”。预期答案结构完整，包含对比表格、引用来源、结论限制。

每组准备 10 到 20 个问题，保证测试可重复。

6.2 评估指标

建议记录以下指标：

重点观察一个趋势：从 fast 到 research，延迟和成本上升了多少，回答质量上升了多少。如果质量上升不明显，说明该问题集并不需要高努力；如果质量上升明显，说明用户值得为它等待。

6.3 测试记录模板

| 问题ID | 问题类型 | 档位 | 延迟(s) | 搜索次数 | 推理token | 引用准确率 | 覆盖率 | 质量分 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Q001 | 简单事实 | fast | 2.1 | 1 | 120 | 100% | 100% | 4.5 | | Q001 | 简单事实 | research | 18.4 | 8 | 5600 | 100% | 100% | 4.5 | | Q005 | 深度研究 | fast | 3.0 | 1 | 200 | 40% | 30% | 2.0 | | Q005 | 深度研究 | research | 42.7 | 9 | 7800 | 92% | 85% | 4.2 |

上面的示例数据只用于说明表格怎么用，不是真实测出来的结果。实际测试中，你应该重点对比“简单问题用高档位是否浪费”“复杂问题用低档位是否质量崩塌”这两组差异。

6.4 判断档位是否生效

有两个标志性信号。

第一，搜索次数明显不同。fast 档通常只做一次检索，research 档应该有多轮搜索。

第二，推理内容可见。如果 API 返回 reasoning 字段，检查其中是否包含 query 拆分、检索计划、来源筛选、自我校验等步骤。如果高 effort 档位下 reasoning 字段依然是空的，说明你的请求参数可能没有传对，或后端没有真正启用推理链路。

7. 资源消耗与性能观察

虽然这个功能不需要本地 GPU，但在线上系统中，资源消耗依然是核心问题。

7.1 观察什么

在 API 网关和日志系统里，按 effort 档位维度聚合：

• 平均响应时间
• P95 响应时间
• 单次请求平均成本
• 搜索请求成功率
• 缓存命中率
• 超时率

对比不同档位的数据，你会得到一张类似这样的成本曲线：fast 档成本最低，但复杂问题上的用户投诉率也最高；research 档成本可能是 fast 档的 5 到 10 倍，但能解决深度用户的核心诉求。这个数字关系因产品和问题分布而异，上线前要压测。

7.2 怎么降低资源消耗

优先推荐四个手段。

第一，query 分级路由。在进入搜索流程前先判断问题复杂度，减少不必要的流量和算力损耗。简单问题自动落 fast 档，复杂问题才走深链路。

第二，缓存优先。同一问题在固定时间窗口内重复出现时，直接返回缓存结果，不重复执行搜索和推理。注意把档位写进缓存 key，避免不同档位互相污染。

第三，超时熔断。高档位任务可能因为外部搜索源响应慢而拖垮整体服务。设置 total_timeout，超时后强制返回当前已收集的中间结果，或降级到低一档重新执行。

第四，动态降级。高峰期自动将默认档位下调一档，非高峰期恢复。可以在配置中心里做开关，不需要改代码。

7.3 显存和本地算力

需要明确一个事实：这类功能主要由云端推理服务承担，本地开发阶段如果你的代码里只做 API 调用，本机不需要 GPU 和大型模型，普通开发机完全够用。但如果你模拟搜索后端，本地会跑检索服务、rerank 模型等组件，这时候才需要考虑显存。建议分流处理：小规模 rerank 模型用 CPU 即可，大规模向量检索建议上 GPU 或直接使用托管服务。

8. 常见问题与排查方法

补充一个比较隐蔽的坑：把“努力程度”和“答案长度”划等号。长答案不等于高质量答案。很多团队把 high effort 简单映射成“生成更多的最终 token”，结果模型为了凑长度写了很多车轱辘话。正确的做法是，高 effort 不是让模型多写字，而是让系统多做检索、多拆解问题、多验证来源，最终答案应该是信息密度更高的结构化内容。

9. 最佳实践与使用建议

如果你要把类似能力落到自己的系统里，下面这些建议可以直接用。

第一，上线前先做成本基线测试。选定 50 个代表性问题，分别在 fast、normal、deep、research 四个档位下连续跑三轮，记录平均延迟和成本。用这个数据反推默认档位和用户配额，不要靠猜。

第二，默认档位宁低勿高。对大多数产品而言，用户能感知的是“慢”而不是“深”，所以默认档位可以偏保守，把高努力作为可选项开放。尤其对免费用户，提供 fast 档可以显著降低服务成本；付费用户再允许切换到 deep 或 research 档。

第三，把选择权做成“建议 + 覆盖”。系统根据 query 自动判断难度，但把推荐的档位展示给用户，允许手动调整。这样既减少用户决策成本，又保留高级用户和 API 调用方的控制能力。

第四，日志里一定要记录 effort 档位和中间搜索过程。排查“答案为什么差”时，没有检索过程日志很难定位是搜索不准、推理不足，还是模型生成阶段出错。

第五，注意数据边界和隐私。AI 搜索会把用户的 query 发送给第三方检索服务和模型推理服务。如果你的业务涉及企业经营数据、未公开代码或个人隐私，需要确认数据是否会被供应商用于模型训练，必要时脱敏后再发请求。涉及个人信息、商业机密的查询，尽量通过私有化检索链路完成，不要把所有数据都交给外部搜索 API。

第六，高努力不代表可以放松合规。需要标注引用来源、给出信息时效、避免让 AI 对敏感决策事项给出绝对化结论。比如金融、医疗、法律类查询，即使走 research 档，也要在答案中说明信息不构成专业建议。

10. 最值得关注的三个点

“努力程度选择器”这个功能，最值得关注的不是 UI 上多了一个滑块，而是它把 AI 产品的资源分配从“黑盒”变成“可调参数”。这背后意味着三层变化。

第一，产品经理可以把“调研深度”作为一个产品特性来运营，而不是让所有用户被同样的响应时间绑架。

第二，API 开发者可以直接根据任务难度动态调整请求参数，无需自己做复杂的 agentic 编排就能在一定程度上控制系统的搜索深度。

第三，系统可以积累足够多的档位使用数据，反过来训练一个自动路由模型，最终实现“不用用户选，系统也知道该花多少力气”。

如果你要去验证这类功能，最先做的是“同一问题、两档对比”：用同一个复杂问题分别用 fast 档和 high 档跑一次，对比搜索次数、推理 token、答案结构和引用数量。这个实验能让你直观感受到档位机制的实际价值。最容易踩的坑则是把档位只做成输出长度控制，导致成本涨了、质量没涨，所以测试时一定要盯住中间推理步骤，而不是只看最终答案长度。

后续可以扩展的方向包括：按用户历史行为自动调整默认档位、按业务线配置不同档位上限、在 API 中开放预算型控制参数，以及把档位信息和缓存、计费、配额体系打通。这个方向的价值不在于“选择器”本身，而在于它让 AI 搜索的成本和质量第一次有了精确的调节旋钮。