2026年11月12日，Perplexity发布Decider v1.3及轻量版本Decider Flash v1.3。一个以搜索和问答起家的AI公司，专门推出一类用于判断、排序、路由和字段定位的模型，传递出一个十分清晰的信号：企业里的AI工作负载正在分化。过去我们习惯让通用大模型读一段文本、写一段推理、最后输出一个JSON；现在越来越多的工作本质上只需要做出一个可计算的判断，并把依据在原文中的位置准确返回。智能体一旦从演示环境进入真实的生产管理系统，这种毫秒级、结构化、高重复频次的判断任务就会大量出现，其总成本和工程重要性甚至可能超过少数复杂的长文本推理。
以一家装备制造企业的售后服务中心为例，每天进入系统的内容包括客户报修邮件、设备故障照片、MES导出的异常记录、检验单、产品手册片段和工程师的语音转写文本。运营管理者关心的是哪些工单属于安全相关事件、应该转给哪个专业岗位、是否涉及某个在保设备、有哪些字段值得进一步查阅。大多数问题需要的最终产物是标签、分数、原文定位、工作队列和处理优先级。对这些任务逐一调用长链条推理模型，相当于在一条自动化产线上，每一个简单传感器判断都要启动一台完整的研发工作站。系统可以这样运行，但大量真实业务并不需要这种计算结构。
从“回答问题”转向“完成一次判断”
Decider的设计是直接对给定问题返回候选标签的概率，而不是以逐Token生成长篇自然语言为核心。按照Perplexity披露的用途，它可以处理文本、结构化数据与图像输入，覆盖分类、相关性判断、偏好排序、模型路由及评测。这里的工程价值来自输出契约发生变化：业务应用调用模型时，可以预先定义候选类别、预期字段和处理阈值，并将模型响应直接纳入下游控制流。客服工单可被分派到机械、电气或软件三个专业队列；图纸变更申请可以被识别为尺寸修改、物料替代或工艺更改；质量投诉可以按是否包含批次编号、故障症状及现场照片分层处理。
如果把这些任务放在传统的生成式接口里，开发者通常要先写一大段系统提示词，规定输出格式，再去处理JSON不完整、字段名称漂移、模型解释与字段值混在一起等情况。为了提高可靠性，还可能追加一轮格式修复或二次校验。决策模型直接围绕标签概率训练，意味着输入输出可以做得更接近工业软件中熟悉的分类器、检索排序器或状态判定器。应用侧保存每次调用的输入摘要、模型版本、标签分布和阈值配置，就能建立一个可观测、可回放、可比较的判断流水线。
Perplexity此次公开的信息显示，较大版本以Qwen3.8-27B为基础，Flash版本使用Qwen3.5-4B并通过蒸馏构建。官方披露BF16权重规模约为49GiB和8.5GiB。两种规格对应着两类典型的基础设施取舍：大型模型可以承担语义复杂度较高、类别边界相互交叉的判断；小型模型更适合高频、低延迟、大吞吐的任务入口。对于具备本地GPU资源的企业，8.5GiB级别的原始权重规模还有明确的硬件规划意义，可以结合量化、并发批处理与显存分配设计具体服务节点。当然，实际运行显存和吞吐还涉及上下文、KV缓存以及所用推理框架，部署预算应由实测数据决定。
Locate：从抽取一个值到定位一段证据
v1.3引入的Locate能力尤其值得工业知识与业务系统团队研究。传统信息抽取倾向于要求模型直接给出“合同金额是多少”“订单号是什么”“设备序列号是什么”，而Locate进一步要求模型指出这些信息在输入中的字符区间，并提供相应分数。返回值与原文位置绑定，系统就能够在界面上高亮对应句子，也能够用确定性的规则读取、归一化和校验字段。对于合同条款、检验记录、物料属性和技术规范，位置往往与字段值同样重要，因为位置支持后续人工审核、版本对比以及跨系统的数据溯源。
想象一份一百多页的设备技术协议，采购系统需要判断交货周期、验收标准、质保范围和关键性能指标。仅把生成答案写入数据库，后续工程师核对还需要重新打开文档搜索；如果智能体同时记录原始文件哈希、页码映射、字符位置、字段类别和相关性分数，用户可以从采购审批页面直接回到合同中的对应条款。在PLM场景中也是一样：智能体从变更申请中定位零件号和更改原因，再沿BOM关系查找受影响对象。检索与决策组件共同承担的是把自然语言业务资料变成可追踪的结构化操作，而不是孤立地生成一段摘要。
这也解释了为什么“先检索、后按需处理”的工程思想越来越重要。企业知识最可靠的承载物，往往仍是文件、表格、项目目录以及PLM、MES、ERP中的实体记录。先用文件名、路径、元数据、全文索引和结构化查询缩小范围，再把相关片段交给Locate或者生成模型，常常比把全量资料重新向量化后再检索更直接。在这个过程中，决策模型承担“这段资料是否值得送往下一环”的轻量筛选，原始系统保留数据所有权和版本边界，模型只在必要时参与处理。
智能体编排为什么需要专门的决策层
过去谈多模型编排，大家容易把注意力放在模型排行榜和大模型之间的切换上。复杂之处藏在数百种业务状态和几千条工具调用路径里。一个设计智能体可能需要根据用户输入决定是打开现有CAD文件、查询标准件目录、调用参数化建模器，还是启动一次CAE计算。一个质量工程师智能体需要判断工单中的异常属于原材料、机加工、热处理还是装配。一个设备维护智能体需要先判断传感器告警是否有对应的维护规程，再选择知识查询、时序数据分析或诊断报告。编排的前几步本身就是一连串微决策。
把这一层抽象出来之后，架构可以分为业务输入、语义判断、任务计划、工具执行、结果验证和反馈记录几个部分。通用大模型仍然擅长理解模糊需求、综合多步证据与撰写复杂报告；专门的决策模型则适合承担分类、过滤、排序、路由、实体提取和低成本质量门禁。两者结合的关键不在于谁替代谁，而在于工作负载被合理拆开。企业还能够为每一个判断配置不同阈值：低风险的文件分类可以自动处理，涉及工艺参数的更改则要求更高置信度和岗位审批。模型能力因此与组织权限、流程规则一起成为完整的企业软件设计。
工业软件过去使用了大量人工维护的条件判断和规则引擎。规则擅长描述确定性逻辑，如设备温度超过上限、库存低于阈值、物料版本不一致；模型擅长识别语言和视觉输入中的复杂语义，例如“客户描述的症状是否属于已知泵阀振动故障”。两种能力结合，可以形成“统计语义入口加确定性业务约束”的工作方式。这样的组合容易部署在已有MES或质量管理系统的外围，通过MCP、API和命令行工具逐步接入，不必以一次巨大的系统替换项目作为前提。
模型路由的经济账：把高成本推理留给少数复杂任务
企业评估AI系统成本，不能只看一次聊天的平均Token价格。总费用取决于一个生产流程从输入到结果调用了多少次模型、每次携带多长上下文、多少任务可以通过轻量模型提前结束，以及失败重试产生了多少额外调用。假设一条售后工作流含有工单分类、产品识别、资料定位、故障知识匹配、处理建议和结果审核六步，其中前四步如果采用专用判断或检索组件，就可能减少多次大模型完整生成。更重要的是，批处理、缓存和阈值过滤能够让整个系统的响应时间更稳定，处理峰值请求时不必让高成本模型承担全部任务。
模型路由还有一个容易被忽视的维度，就是企业希望保持模型供应商的可替换性。若所有业务判定规则都封装在某个供应商专属的长提示词中，迁移模型会同时改变分类边界、输出字段和错误处理方式。使用明确的任务模式、标准化标签、评测样本与独立的决策服务，可以把业务定义与具体模型权重分离。今天使用某个开源小模型，明天换成另一个模型，只需要在相同的业务数据集上重新测量精度、延迟和资源成本，然后逐步切流。所谓企业AI资产，很大一部分其实是这些可以复用的任务定义、数据样本和工程评价体系。
在企业私有部署中，本地推理和云API也可以混合使用。低频但复杂的多模态需求可以发送至企业授权的云服务，高频工单路由与敏感文件抽取保留在厂内GPU上。企业不必让每个工位都持有完整的大模型会话，也不必让每个业务应用维护一套完全不同的模型调用代码。一个统一入口提供鉴权、租户隔离、限流、模型目录、调用日志和费用归集，内部再按任务特点选择Decider一类决策模型、语音模型、检索引擎或通用推理模型。模型路由成为工业智能算网的基础能力之一。
如何把一次分类变成可测量的工程能力
企业部署微决策组件，第一步是定义业务标签，而不是直接挑模型。例如质量异常可以按零件、设备、工艺、批次、供应商和现场条件建立多级标签；客服工单可以按产品线、故障现象、处理紧急度和所需专业团队划分。接下来收集一定数量的历史工单，保留原始资料、最终处理结果与工程师修正记录，组成可持续更新的测试集。在工业领域，标签体系本身就是企业知识的结构化表达。一个好的标签体系能兼容术语差异、产品更新和工艺更改，也能让不同型号模型在相同的评价标准下被比较。
评价时可把指标拆成分类准确率、关键类别召回、置信度校准、字段定位误差、平均延迟和单件处理成本。对于Locate类型任务，尤其要统计预测区间与人工标注区间的重合程度，以及字段映射到PLM或ERP对象时的匹配情况。质量工程师关心的可能是关键缺陷是否准确进入优先队列，采购部门则关心合同金额和交付日期是否对应正确的条款。相同模型在两个任务上可能呈现不同的业务价值，因此测量单位最终应回到具体流程，而非孤立的通用评测排名。
线上运行还可以形成主动学习的数据循环。模型把高置信度任务送入自动化流程，把边界样本交由专业人员处理，系统记录人工改正的类别、原因和新出现的术语。每次产品型号变更、材料替换或供应商切换，都有机会使历史样本库更丰富。算法团队根据这些记录开展定期评测、微调或阈值调整，业务人员则能够直接看到分类稳定性和工作量变化。久而久之，数字工匠平台中每一个岗位智能体都会积累属于本岗位的决策数据集，成为持续演进的工程资产。
从文件检索到CAD/CAE调用，微决策藏在每一步里
以研发工程师智能体为例，用户输入“给这套泵重新选择密封方案，考虑介质温度和维修周期”。系统首先需要识别产品型号、部件类型和工况条件，再确认现有产品模型、物料清单和密封件资料是否已在本地库中。下一步或许调用设计手册与历史故障记录，并对不同材料的温度适用范围进行筛选。当某项判断进入计算范围，才启动参数化设计、有限元分析或成本核算工具。每次调用背后都有明确条件和结构化结果，而不是让一个长上下文模型独自承担所有工程步骤。
仿真试验组也有类似需求。项目库可能同时存在CFD网格、计算日志、试验曲线、图片和报告，模型首先应判断文件类型、几何对象、工况和试验阶段，然后定位可以用于当前问题的数据。把这些判断变成专用组件，可以让检索、数据校验和模型拟合更容易自动编排。基于试验数据的研发数据集并非简单堆叠文件，而是在原始数据之上补齐来源、时间、设备、参数、版本以及适用工况等语义。一个准确的微决策层，可以显著降低工程师重新整理材料的重复劳动。
在生产线数字孪生场景里，自然语言查询也需要类似的入口。用户说“找出这周焊接质量波动最大的工位，并比较工艺参数”，系统应先判断用户说的是哪个车间、哪条线、哪个质量指标，再查询MES、QMS和设备时序库。检索到数据后，系统可以选择时间序列算法、统计控制图或已有的降阶代理模型进行分析，再组织可视化结果。业务交互在表面上是一句话，在后台则由多个低成本判断、数据查询和专业计算协同完成。只有把每一步清楚拆解，企业才能真正解释一次智能体决策调用了什么数据、采用了什么规则、产生了什么后续操作。
新一轮企业AI竞争会转向谁掌握任务定义
Perplexity推出Decider v1.3，反映出行业开始把生成式大模型之外的专用能力做成独立产品。它的意义不局限于Perplexity自己的模型生态，也为工业AI团队提供了技术分层的新参照：识别与抽取负责把非结构化信息整理成可处理对象，微决策负责将对象匹配到业务规则和执行路径，通用大模型负责综合分析和复杂计划，专业软件与物理计算模块负责完成真正的工程动作。对于大型组织，这种分层比“所有流程共用一个超级模型”更有利于长期维护和多部门协作。
从产业角度看，未来值得投资的不只是更大的模型，也包括针对装配、检验、设备诊断、文档治理、合规审批和研发知识查询构建的高质量任务数据。拥有真实工单和专业工程师反馈的制造企业，具备建立行业微决策基准的优势；熟悉PLM、MES和质量系统的软件团队，具备把这些模型嵌进现有业务流的条件。AI编排正在逐渐接近传统工业控制系统所熟悉的模块化思想：每个组件有输入、有输出、有适用范围、有测试依据，整个系统通过明确接口协同运行。
企业AI下一阶段的效率提升，很可能来自数百万次不起眼的小判断。一个工单分得更准确，一条技术条款定位得更快，一次模型路由省去多余的推理，一份仿真报告找到正确的版本，这些变化单独看不如发布一个巨型模型轰动，却能够在生产、研发和服务各个部门连续发生。Perplexity Decider让我们看到，围绕这种微决策构建专门的基础设施，已经开始成为AI产品设计的新方向。对于工业智能体而言，真正可持续的工程优势，往往就建立在这些高度专业化、可测量、可复用的小能力上。
参考文献
- Perplexity, Perplexity Decider v1.3: Training, eval, and use cases, 2026-11-12. https://www.perplexity.ai/hub/blog/perplexity-decider
- Hugging Face, Perplexity Decider series model repository and metadata. https://huggingface.co/Perplexity
- TSN Media, Perplexity Decider v1.3, 2026-11. https://tsnmedia.org/perplexity-decider-v1-3/