这次的话题不是又一个本地推理模型而是 Perplexity 在 AI 搜索里做的一个细节功能开发新的粒度“努力程度选择器”。所谓“努力程度”通俗讲就是让系统在回答一个问题之前愿意花多少计算量——是先给一个快速答案还是先拆解问题、多次搜索、逐步验证再给你一份更完整的结论。这个“选择器”本身不算全新概念OpenAI 在推理模型里提供过reasoning_effort参数Anthropic 也有扩展思考预算。但 Perplexity 把它放到 AI 搜索场景中并强调“新粒度”意味着它可能不只是三档开关而是更细的任务难度控制什么类型的问题用低档什么类型的问题用高档甚至可以细化到每个搜索请求分配多少推理预算。这篇文章不涉及本地部署也不需要什么显卡。我会先讲清楚“努力程度选择器”到底是什么、为什么 AI 搜索需要它再从技术角度拆解细粒度实现思路然后给出一套通用 API 接入和测试验证方法最后聊一聊成本控制、资源消耗和常见坑。适合正在做 AI 搜索集成、Agent 应用和 RAG 系统的工程师阅读。1. 核心概念速览能力项说明项目类型AI 搜索 / Agentic Search 中的推理控制功能核心功能让用户或调用方控制 AI 搜索时的推理深度、搜索次数和答案长度相关技术reasoning effort、推理预算、Agentic Search、RAG、模型路由开发方Perplexity按标题信息主要使用方式Web 界面 / API 参数以实际产品文档为准档位粒度从简单的三档开关向更细粒度档位演进按标题描述涉及硬件不需要本地 GPU主要依赖云端推理服务适合场景快速问答、深度调研、代码排查、论文阅读、企业知识库问答主要风险高档位导致延迟和成本上升、档位语义不明确、缓存命中率下降“努力程度选择器”这个名称技术本质是把一个搜索任务要消耗的推理算力显式暴露给用户。传统搜索引擎只给一个相关性排序传统聊天机器人只给一个生成结果。而 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_keyyour_api_key, base_urlhttps://api.example.com/v1 ) response client.chat.completions.create( modelreasoning-search-model, messages[ {role: user, content: 解释一下 RAG 系统中的混合检索为什么比纯向量检索更稳}, ], reasoning_effortmedium, max_completion_tokens2048 ) 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_tokens3000”是什么意思。设计上应该用任务场景来描述档位比如档位界面文案适用场景fast快速回答天气、时间、事实查询、网址查找normal标准搜索日常问题、中等难度解释deep深度分析对比选型、方案设计、代码排查research研究报告论文综述、市场调研、多源验证如果要做更细粒度可以在 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 fsearch:{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 评估指标建议记录以下指标指标说明端到端延迟从请求发出到收到最终答案的秒数搜索次数系统实际发起的搜索请求数推理 token 数中间思考和规划消耗的 token 量引用准确率答案中引用的链接是否真实存在且相关答案覆盖率参考答案中的关键点是否被覆盖主观质量分按 1 到 5 分评估答案的可用性重点观察一个趋势从 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. 常见问题与排查方法问题现象可能原因排查方式解决方案传入 effort 参数后答案没有变化参数名不对或后端未识别查看请求日志中是否记录了 effort 字段查阅官方 API 文档确认字段名和取值响应超时高档位搜索次数过多或外部检索源慢检查耗时分布确认卡在检索还是推理降低档位、缩短超时、增加搜索并发成本飙升默认档位过高或 query 分级不准按档位聚合账单和 token 消耗重写 query 分类规则降低默认档位简单问题也走高档位自动分类器判断偏差抽样查看分类日志增加规则兜底例如包含明确问句则走 fast缓存结果和当前档位不匹配缓存 key 未包含 effort检查缓存 key 生成逻辑将 effort 写入缓存 key答案变差但耗时才高一些追问逻辑把问题带偏查看 reasoning 中间步骤限制 follow-up 最大次数增加相关性判断配额限制导致请求失败达到供应商每分钟请求上限观察 429 状态码添加客户端限流和重试退避补充一个比较隐蔽的坑把“努力程度”和“答案长度”划等号。长答案不等于高质量答案。很多团队把 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 搜索的成本和质量第一次有了精确的调节旋钮。