最近 AI 搜索产品的体验其实一直存在一个有点尴尬的矛盾简单问题它给你长篇大论复杂研究它却只回一段摘要。工具无法预先知道你是想“快速查个名词”还是“写一份调研报告”于是只能在同一个黑盒里做折中处理。Perplexity 正在开发的“新粒度努力程度选择器”本质上要解决的就是这件事——把回答的详细程度和推理深度交还给用户。我的判断是这看起来只是一个 UI 上的滑块或档位实际上是 AI 搜索从“一次搜索打天下”走向“可控制推理成本与输出粒度”的信号。如果落地它对产品设计、Agent 开发以及调用 LLM API 的工程实践都有参考价值。这篇文章会从问题本身出发讲清楚粒度与努力程度的区别、Perplexity 为什么要做这个功能、可能的技术实现路径以及开发者如何在自己的产品里借鉴这种“努力程度可调”的设计思路。读完你可以直接产出自己的参数配置方案也能避开几个常见的坑。1. 这篇文章真正要解决的问题先说一个具体的场景开发者在集成 AI 搜索能力时经常会遇到两类失败。第一类是“回答太浅”。你问一个需要跨多个数据源交叉验证的问题比如“某开源协议在商用场景下的限制”搜索引擎只给你一两段摘要缺少案例、法条原文、差异化对比。用户觉得没用产品认为模型不够强。第二类是“回答太啰嗦”。你只是想确认“Redis 默认端口是多少”结果模型给了一份包含安装步骤、集群方案、性能调优的长文。用户反而觉得困惑而且响应时间明显变长成本也更高。问题不在于模型能力而在于系统没有把“回答策略”暴露出来。用户无法告诉系统这次请花多一点时间搜索、推理和展开或者这次请简单直接地回答。Perplexity 的新粒度努力程度选择器就是在产品层面补上这个交互通道。它不是简单的“输出长度滑块”。从产品逻辑看它调整的是一个组合变量搜索轮数、检索来源数量、推理预算、输出结构复杂度等。如果这一功能上线用户选“高努力程度”时系统会以更深的链路完成检索与推理选“低努力程度”时则走最短路径。这篇文章适合三类读者阅读AI 搜索或知识类产品的 PM需要理解为什么“可控粒度”会成为新的产品竞争力。调用 Perplexity API 或其他 LLM API 的开发者想知道如何在请求参数层面对齐这种能力。做 Agent 应用的工程师希望把“努力程度”映射为 Agent 的搜索轮数、反思轮数和工具调用预算。核心结论先放在前面粒度选择器不是一次性 UI 实验而是 AI 产品从“答案输出”走向“推理资源配置”的必然一步。2. 什么是粒度和努力程度先统一概念在继续之前需要把两个概念区分清楚粒度和努力程度。粒度指的是回答被拆分成多细。低粒度的回答可能只有一句话或者只给出结论高粒度的回答会拆成背景、原因、步骤、案例、风险提示、参考来源等模块。粒度主要由输出结构和内容深度决定。努力程度指的是模型在生成回答之前投入多少计算资源。低努力程度可能是一次检索加一次生成高努力程度可能包括多轮检索、查询改写、交叉验证、候选答案生成、自检修正等多步推理过程。努力程度主要由推理时计算量决定。两者有关联但不完全等同。高努力程度通常会产生更高粒度的回答但也可能出现“思考太久但输出仍然很短”的情况反过来高粒度输出也可以在不追加额外搜索的情况下通过更长的生成文本来实现。一个合适的类比是“外卖配送选项”低努力相当于“快速配送”只保证送到高努力相当于“准时且完整包装”的服务增加更多检查环节。用户选择的不是“好吃程度”而是服务付出的过程成本。在 Perplexity 的语境里粒度与努力程度选择器大概率是一个组合控件。用户选择的不只是“回答多长”而是“AI 为这次回答投入多少推理与搜索资源”。这是一个比“输出长度”更本质的产品抽象。维度低粒度 / 低努力高粒度 / 高努力搜索轮数1 轮多轮可自动改写查询信息源数量少量多个且交叉验证推理过程直接生成分步推理、自我检查输出结构摘要、要点分节、对比、案例、总结适用场景事实查询、名词解释研究报告、方案评估、竞品分析成本与延迟低高当然这里要说明一下因为我看到的是功能预告与产品逻辑信息并非官方完整技术文档所以上面表格是基于常见模式做的归纳。具体档位怎么划分、参数名怎么定义以上线后官方说明为准。但从行业趋势看这个方向是清晰的。3. 为什么 Perplexity 要做这样的选择器任何一个产品功能背后通常有三个驱动力用户需求、成本约束、行业趋势。Perplexity 做粒度努力程度选择器刚好这三个驱动力都占全了。3.1 用户需求已经分化Perplexity 早期吸引用户的核心能力是“搜索 摘要”。大部分用户把它当成一个更好用的搜索引擎查资料、找答案、看新闻。但很快一部分用户开始把它当成研究工具写行业报告、比较产品参数、分析开源项目、整理文献综述。这两类用户对同一产品的诉求完全不同。前者希望“越快越好、越短越好”后者希望“越深越好、越全越好”。在没有选择器的情况下产品只能选择中间路线最后两边都不满意。更合理的方式是让用户显式选择需求类型而不是让模型猜。3.2 成本与体验的平衡如果默认所有请求都按照“深度研究”的标准执行先做 5 轮搜索、再来 3 分钟推理体验上不可接受成本上更不可控。反过来如果所有请求都按“快速回答”执行深度问题的回答质量会明显下滑。努力的档位本质上是一种资源配置策略。用户选择了高粒度意味着他愿意接受更长的等待时间也意味着产品可以向他展示更多检索过程和推理依据用户选择快速回答产品则可以在成本预算内完成响应。对 AI 搜索来说“把选择权交给用户”比“自动猜测”更容易控制成本预期与体验预期。3.3 推理时计算成为新的扩展维度过去两年大模型的能力提升主要靠参数规模、训练数据和训练技巧。但以推理模型为代表的新趋势表明给模型更多的推理时间也能带来显著的能力提升。这一现象在行业内被称为“推理时扩展”inference-time scaling或“思考时计算”。Perplexity 做“努力程度选择器”可以理解为把推理时计算从模型内部的一个隐藏过程变成用户可感知的产品参数。这不是 Perplexity 独有的想法但它可能是第一个把这种能力做到搜索产品前端交互里的主流玩家。4. 行业对标三个层级的产品差异把 Perplexity、传统搜索和 ChatGPT 放在一起对比能更清楚地看到粒度选择器的位置。传统搜索引擎的核心是关键词匹配和排序用户需要通过不断调整关键词来控制结果粒度。本质上它把“粒度控制”的成本全部转嫁给了用户。你搜“Java HashMap 原理”平铺出来的是一条条链接没有系统化组织。ChatGPT 这类对话助手虽然能生成结构化回答但用户对深度和粒度的控制是间接的只能通过提示词实现。想让回答更详细你得写“请展开说明并给出代码示例”。而且 ChatGPT 是单轮对话模型不会因为你一个问题自动去搜索多轮。Perplexity 的形态介于两者之间它自动做检索但用户对回答的详细程度一直缺少直接控制。粒度努力程度选择器一旦上线会让它比传统搜索更接近“研究助手”比通用对话助手更接近“可配置的搜索推理系统”。产品检索方式粒度控制推理预算控制适合任务传统搜索引擎关键词匹配用户手动改关键词无定位信息源ChatGPT无自动检索或插件检索提示词间接控制隐藏或部分露出文本生成、单轮问答Perplexity自动多源检索可设置粒度档位探索性支持研究型问答、快速查询还有一个值得参考的对象是各种 Deep Research 类功能。它们的思路很接近给 Agent 设定大量预算让它自动规划搜索步骤、汇总来源、输出研究报告。粒度选择器可能是这种深度研究能力的轻量版入口不是所有场景都需要 20 分钟的研究但用户应该有权选择需要多深。5. 产品逻辑与可能的技术实现路径虽然官方没有给出完整的技术细节但从 AI 搜索系统的常见架构可以推断粒度努力程度选择器影响的不是模型提示词里的一句话而是整条检索与推理链路中的多个参数。5.1 产品交互层最可能的产品形态是搜索框附近的一组档位比如“快速 / 标准 / 深度”三段式选择或者一个连续的粒度滑块。用户在发起搜索前先决定回答粒度而不是等搜索结果出来后再调整。更深一层系统也可以在用户输入问题后通过意图识别自动推荐档位但这需要非常强的问题复杂度判断能力。从产品风险控制的角度看初期先做显式选择更稳妥显式选择能让用户对等待时间和成本产生明确预期。5.2 技术链路层一次带粒度选择的 AI 搜索大致会经过以下环节查询理解判断问题类型、确定领域和检索关键词输出搜索计划。搜索规划根据努力程度决定搜索轮数上限。低档可能 1-2 轮高档可能 5-10 轮。检索与选择从网页、知识库或第三方 API 拉取结果按相关性过滤并在高档模式下交叉验证来源。推理与生成将检索结果作为上下文注入模型。高档模式会允许模型做更长的链式思考先形成中间结论再生成最终回答同时更严格地标注引用。输出渲染按粒度要求组织标题、表格、引用、小结等结构。这一链路中最直接的参数化方式是增加一组“推理努力”参数{ effort_level: high, search: { max_search_rounds: 8, max_sources: 12, enable_query_rewrite: true }, reasoning: { thinking_budget: high, enable_reflection: true, max_intermediate_answers: 3 }, output: { max_tokens: 4000, structure: detailed_report } }需要明确说明的是上面的 JSON 是结合行业习惯做的设想示例不代表 Perplexity 官方参数命名。用它来说明“努力程度如何参数化”是合适的但如果当成真实 API 文档使用就错了。等官方 API 更新后应以官方字段为准。5.3 成本控制层从工程角度多档位设计意味着一套成本控制策略需要落地。比如每个用户每天允许多少次“高努力”搜索。高努力档位是否只对订阅用户开放。实时监测每个档位的平均延迟和 token 消耗用于动态调度模型型号。如果某个时段请求压力大可将高风险用户的默认档位降为“标准”。这些能力在现有 Perplexity 产品上并不难实现但从“单一模式”到“多档位”的变化会让成本模型的复杂度上一个台阶。6. 对开发者与 API 使用者的启示即使你不直接用 Perplexity 的 Web 产品这个功能也有很强的借鉴意义。尤其是正在接 LLM API 的开发者应该认真思考一个问题你的产品是否把所有请求都当成同一类请求处理了大多数应用目前的做法是统一用 max_tokens 控制最大输出长度统一走同一个系统提示词统一不做前置路由。结果就是简单请求浪费 token复杂请求深度不足。Perplexity 的粒度努力程度选择器提示我们可以把“努力程度”做进 API 调用的参数体系里。下面用一个 Python 示例展示思路。这里基于 Perplexity 现有 API 的官方调用方式新增的 effort_level 字段属于假想设计用于演示。# 文件路径demo_perplexity_effort.py import requests API_URL https://api.perplexity.ai/chat/completions API_KEY your_api_key def ask_perplexity(query, effort_levelmedium): headers { Authorization: fBearer {API_KEY}, Content-Type: application/json, } payload { model: sonar, messages: [ { role: system, content: ( You are a search assistant. Return concise answer when effort is low. Return detailed structured answer with citations when effort is high. ), }, {role: user, content: query}, ], # 下面这个字段是演示用的假想字段真实 API 请以官方文档为准 effort_level: effort_level, } resp requests.post(API_URL, jsonpayload, headersheaders, timeout60) resp.raise_for_status() data resp.json() return data[choices][0][message][content] if __name__ __main__: print(ask_perplexity(Java 中 HashMap 的扩容机制, effort_levelhigh))这段代码本身可以直接跑但请把 API_KEY 替换成自己的密钥。重点不是这段代码能否真的对接到 Perplexity 新功能而是让我们看到“努力程度”已经成为 API 设计中一个值得显式化的参数。更接近生产环境的做法是不把 effort 写死在调用方而是做一个路由函数def resolve_effort(query: str, user_tier: str) - str: # 简单规则示例根据问题长度和用户等级决定 effort if user_tier premium: return high if len(query) 20: return low if 对比 in query or 分析 in query or 报告 in query: return high return medium这个函数虽然简单但体现了一个重要的工程思路将“生成策略”从业务代码中解耦出来用独立的规则或模型判断当前请求应该消耗多少推理资源。还可以用离线对比的方法验证不同 effort 对回答质量的影响。下面是一个提示词层面的示例任务评估同一问题在不同努力档位下的回答质量。 问题PostgreSQL 与 MySQL 在事务隔离级别上的主要差异是什么 低努力回答评价维度 1. 是否直接回答了核心差异 2. 是否出现了不准确表述 3. 是否满足 3 分钟快速阅读 高努力回答评价维度 1. 是否覆盖两种数据库的全部隔离级别 2. 是否给出具体命令示例 3. 是否说明默认隔离级别 4. 是否引出 MVCC 相关机制 5. 是否包含场景建议如果在不同档位之间高努力回答在上述维度上没有显著提升说明产品对这个参数的利用还不够充分。反过来如果高努力回答明显更好就要考虑把它作为付费高级功能提供。7. 这样设计可能遇到的坑与反思粒度努力程度选择器看起来直观真正实现时坑不少。把这些问题提前列出来比功能上线后再补救要有效。问题现象可能原因排查方式解决方案用户不点档位选择器全部用默认值设置入口不显眼用户不理解差异查看按钮点击率和热力图在搜索前用轻提示示例说明档位差异高努力回答反而更差检索轮数过多引入噪声来源对比不同档位的引用来源质量对新增来源增加相关性阈值减少来源冗余响应延迟过高导致用户流失高努力档位执行时间超出用户预期在等待页显示搜索轮数进度设置最大延迟上限超时时自动降档并提示成本超预算高档位请求占比过高按档位统计 token 消耗与请求次数对高档位设置每日配额或动态价格不同档位回答风格不一致提示词对档位定义不够明确同一问题多次测试为每个档位设计独立系统提示词模板这里最容易被忽视的坑是“高努力不等于高质量”。如果模型只是把答案写得更长但没有增加验证、对比和引用用户并不会觉得更好反而会觉得产品在浪费他的时间。努力程度的本质是把更多资源用在正确的地方也就是搜索计划、来源验证和推理反思上而不是单纯增加生成字数。另一个坑在评测层面。传统 RAG 系统评测标准答案是否命中但不同努力档位会生成风格和结构完全不同的答案。如果统一用一个评测集打分低努力可能因为“输出太短但信息完整”得到高分高努力却因为“输出太长导致精确匹配下降”被打低分。这需要分别设计评测维度。8. 最佳实践与工程建议结合上面的分析这里给出几条在自研产品中落地“努力程度”的工程建议。8.1 把 effort 设计为显式参数而不是隐藏在提示词里在实际项目中prompt 往往是可变的但工程上可以强制每个请求携带一个 effort 标签方便后续做成本分析、延迟分析和质量分析。// 文件路径src/main/java/com/example/search/EffortLevel.java public enum EffortLevel { LOW, MEDIUM, HIGH }这样在日志里可以很直观地看到今天有多少请求是 LOW多少是 HIGH。从这些数据能反推用户任务分布也能定位哪些业务场景成本异常。8.2 默认值要保守路由策略要渐进新功能上线时不要把所有用户默认设为 HIGH。正确的路径是先默认 MEDIUM观察线上请求延迟和用户反馈再逐步对特定问题类型启用 HIGH。判断是否启用 HIGH 的条件可以从“用户是否在结果页停留更久”“是否愿意点击展开全文”这类行为信号中回收。8.3 做好缓存与重复查询识别高努力档位的成本很高如果两个用户搜索同一个热门问题系统应该复用缓存结果而不是重新跑一遍完整检索和推理。缓存键不仅要包含 query还要包含 effort_level、来源范围、时间窗口等维度。8.4 监控关键指标建议重点关注四个指标各档位请求占比。各档位平均延迟和 P95 延迟。各档位 token 成本。高努力档位的回答采纳率、点赞率和引用点击率。如果发现 HIGH 档位的用户行为指标并没有显著优于 MEDIUM就需要回查技术链路而不是继续推高成本。8.5 对 Agent 架构的启发如果你在构建多步 Agent可以把“努力程度”映射为 Agent 的执行步数、最大迭代次数和反思次数。高努力 Agent 可以允许多次工具调用和结果重试低努力 Agent 则走默认流程。这比用一套固定 max_steps 更灵活也更贴近 Perplexity 这个功能的思路。9. 总结AI 搜索的下一个方向是可控推理深度Perplexity 的新粒度努力程度选择器看起来只是产品交互层的一个新增控件但它背后的产品逻辑很清晰AI 搜索正在从“统一答案输出”转向“可配置推理资源”。用户将成为推理成本的决策者而不仅是答案的接收者。对开发者来说这个功能最大的价值不是“Perplexity 有这个东西”而是一个可以复用的设计思路把搜索轮数、推理预算、输出粒度组合成一个用户可感知的档位让系统在不同任务复杂度下都能找到成本和质量的平衡点。在功能正式上线后建议做两件事第一实际体验不同档位在同一个问题上的差异并把结果记录下来这比看任何评测数据都真实第二检查自己的应用是否也存在“所有请求一刀切”的问题考虑是否值得加入类似的努力程度参数。交互层的设计可以等官方参考但工程层的参数化思路现在就可以开始准备。