趋势解读:Perplexity's "Search as Code" lets AI models write,评估 LLM Agent 表现
Perplexity推出"Search as Code"新架构,让AI模型编写Python脚本来执行搜索,而非调用固定API,在复杂研究任务中可降低85%的token使用量,并显著提升准确率。
原贴
查看原文原文
中文翻译
在Perplexity的新"Search as Code"架构中,模型不调用现成的搜索API,而是编写自己的搜索工作流程作为Python代码。该公司承诺更精确的结果和更低的token使用量。
任何看过AI智能体处理复杂研究任务的人都会看到同样的模式。模型编写一个查询,搜索API返回结果列表,模型读取它们,然后编写下一个查询。这个循环重复,往往连续多次。
Perplexity在一份新技术报告中称此为瓶颈。今天的搜索引擎是为想要整齐蓝色链接列表的人类构建的,但对于试图在几分钟内运行数百次搜索的AI智能体来说,这种设置过于僵化。智能体只能调整搜索词;其他一切都是黑箱。
"Search as Code"(SaC)改变了这一动态。不是调用API,而是模型编写一个自定义Python脚本来运行搜索。该脚本在安全沙箱中运行,从Perplexity的搜索后端拉取数据。检索、过滤、去重和重排序等基本操作被封装为简单的SDK函数。
该架构分为三层。顶层是模型,它理解任务并决定搜索策略。中间是运行代码的沙箱。底层是"Agentic Search SDK",它将Perplexity的搜索引擎拆分为独立的、可混合匹配的函数。
标准搜索API仍然存在,用于快速问题。但对于困难的研究,模型可以深入得多。它可以同时发起并行查询,以编程方式过滤掉噪音,并将相关结果拉入上下文窗口。据Perplexity称,这就是胜利所在。
标准搜索管道会因过滤逻辑被锁定而用垃圾填满智能体的上下文窗口。当智能体编写自己的过滤器时,上下文保持精简,模型在长时间的研究过程中保持方向感。
为了展示这在现实世界中的效果,Perplexity在一个混乱的网络安全任务上进行了测试。一个智能体必须追踪200个2023年至2025年间发布的严重软件漏洞(CVE)。对于每个漏洞,它需要找到官方供应商公告、受影响的软件以及修补该漏洞的确切版本。新闻报道或博客文章不算数。
使用SaC,模型编写了一个三阶段脚本。它针对Mozilla或Google等特定供应商的安全公告格式运行了定制化的并行搜索。接下来,它扫描自己的发现,发现缺口,并运行针对性的后续查询。最后,它使用一个模式验证CVE、产品和修复版本是否全部对齐。
它成功了。Perplexity称智能体完成了任务,同时比其标准管道少用了85%的token。竞争系统获得不到四分之一的数据正确。Perplexity声称SaC在五个基准测试中的四个上击败了OpenAI的Responses API和Anthropic的Managed Agents等竞争对手。最大的差距在"WANDR"上,这是Perplexity自己为广泛研究任务设置的基准,计划很快发布。
当然,对于自我报告的基准要持保留态度,但与Perplexity自己旧架构的比较显示出了清晰、巨大的性能飞跃。Perplexity将SaC视为更大趋势的一部分。传统软件依赖于确定性指令。前沿模型在token空间中添加推理。最强大的系统结合两者:模型负责策略,确定性运行时负责批处理和过滤,搜索基础设施作为I/O层。
核心信息
Perplexity推出"Search as Code"新架构,让AI模型编写Python脚本来执行搜索,而非调用固定API,在复杂研究任务中可降低85%的token使用量,并显著提升准确率。
- Perplexity推出Search as Code架构,模型自写搜索脚本
- 相比传统API,SaC降低85% token消耗
- 在CVE追踪任务中准确率远超竞品
- 代表推理+确定性代码结合的趋势
- 沙箱运行代码,平衡灵活性与安全性
详细解读
这是什么信号? Perplexity推出的"Search as Code"架构标志着AI搜索范式的重大转变:从调用固定API到让模型自主编写搜索脚本。这代表了将大模型的推理能力与确定性代码执行相结合的趋势,旨在解决传统搜索管道中上下文污染和效率低下的问题。
为什么重要? 在Agent工作流中,搜索往往是瓶颈。传统API返回过多无关内容,浪费token和上下文窗口。SaC通过模型自行编写过滤逻辑,大幅降低噪音,已在CVE追踪任务中展示85%的token节省和远超竞品的准确性。这提示未来Agent可能不再依赖封装好的API,而是直接编写底层操作代码,实现更精细的控制。
对谁有价值? 对AI开发者:可借鉴此架构优化自己的Agent系统,尤其在需要大量实时搜索的业务场景(如安全情报、金融研究)。对企业:若使用Perplexity的服务,可获得更高效的搜索能力。对研究LLM Agent的团队:SaC提供了可复现的基准提升案例。
可以怎么行动? 试用Perplexity的SaC接口(若已开放),对比传统API在自身任务上的效果。在自己的Agent设计中引入可编程搜索层,允许模型动态编写过滤规则。关注Perplexity即将发布的WANDR基准,用于评估广泛研究任务。
风险或限制 SaC依赖模型生成正确代码,存在安全风险(虽然Perplexity使用沙箱)。自报告基准可能高估效果,实际收益因任务而异。当前仅适用于Perplexity生态,通用性待验证。另外,编写代码增加了计算开销,部分场景可能得不偿失。
信息差价值
信息差价值: Perplexity的技术报告揭示了当前Agent搜索效率低下的核心原因——传统搜索API为人类设计,而非AI。SaC通过让模型自主编写过滤逻辑,打破了封闭API的黑箱。这一信息对正在构建Agent工作流的团队至关重要:不要局限于现有API,尝试赋予模型更多底层控制权。
业务启发: 如果你的业务涉及大量信息检索(如法律条文、医疗文献、技术文档),SaC架构可显著提升搜索精度和上下文利用效率。考虑在内部工具中引入类似思路:允许模型动态构建查询语句、并行抓取、结构化验证。例如,在客户支持场景中,让Agent自行编写脚本从多个数据库获取信息并交叉验证。
可沉淀动作: 1) 使用Perplexity的SaC API进行原型测试,对比现有搜索流程的token消耗和准确率;2) 在自己的Agent框架中实现可编程搜索层,提供安全沙箱和基础SDK函数;3) 收集不同领域任务(如研究、分析、监控)的收益数据,判断SaC模式的适用边界。
参考来源
TOPIC HUBS
延伸专题
AI SUMMARY
这篇文章回答了什么
趋势解读:Perplexity's "Search as Code" lets AI models write,评估 LLM Agent 表现主要讲什么?
Perplexity推出"Search as Code"新架构,让AI模型编写Python脚本来执行搜索,而非调用固定API,在复杂研究任务中可降低85%的token使用量,并显著提升准确率。
这篇文章最值得关注的要点是什么?
Perplexity推出"Search as Code"新架构,让AI模型编写Python脚本来执行搜索,而非调用固定API,在复杂研究任务中可降低85%的token使用量,并显著提升准确率。;Perplexity推出Search as Code架构,模型自写搜索脚本;相比传统API,SaC降低85% token消耗;在CVE追踪任务中准确率远超竞品
这篇文章和哪些AI专题相关?
它适合放在Agent工作流、AI工具、AI超级个体专题里阅读。 关联原因:这篇内容命中「Agent、工作流」等主题信号。;这篇内容命中「自动化、模型」等主题信号。;这篇内容命中「技能」等主题信号。
阅读这篇文章建议先理解哪些关键词?
建议先理解AI工具、工具、自动化、模型、Cursor这些关键词,再结合正文判断工具、机会或风险是否值得进入自己的工作流。