AI搜索评测背后：Octen Search 77分与速度第一的工程逻辑

AI 搜索这几年的竞争烈度算是把整个赛道卷到了一个新高度。各家评测机构也跟着冒出来不少但论方法论的透明度和评测维度的贴近度Artificial Analysis 的专项评测一直是我自己参考最多的榜单之一。最近这轮搜索评测结果公布后我第一时间盯上了 Octen Search 的成绩——77 分综合排名第三同时在所有参测产品里拿到了响应速度最快的单项表现。这个组合确实有点意思。在 AI 搜索这个场景里单纯分数高不稀奇单纯速度快也不稀奇但能在质量分站上第一梯队的同时把延迟做到全场最低说明这个产品在工程侧是有真东西的。这篇文章我不打算做成新闻复述而是从评测到底测了什么77 分是什么水平速度为什么能这么快我们自己怎么验证这几个角度把这次评测结果拆开揉碎聊一遍。无论你是普通用户、产品经理还是正在做 AI 搜索相关开发的工程师都能从中拿到点可用的参考。1. Artificial Analysis 搜索评测到底在测什么1.1 评测机构的背景与可信度Artificial Analysis 是一家专注大语言模型和 AI 应用横向评测的独立机构早期以模型能力基准测试出名后来逐步扩展到聊天机器人、Agent、AI 搜索等具体产品形态。它跟很多厂商自己的宣传数据有一个本质区别所有测试任务、提示词、评分标准都是公开的评测过程也尽量做到标准化和盲测化避免拿自己出的卷子考自己这种作弊行为。这个点很重要。因为 AI 搜索产品的官方宣传稿里准确率提升多少响应速度多快这些数字往往是在理想环境下跑出来的。而第三方评测会把产品放在统一的任务集里用相同的问题、相同的判定标准去横向比较这时候水分就被挤得差不多了。Octen Search 能在这样的评测里拿到前排位置含金量比厂商自报的指标高得多。1.2 评测指标体系的拆解从 Artificial Analysis 过往的搜索评测方法论来看它考察的维度大致可以分成两块一块是回答质量另一块是响应效率。回答质量层面通常包含事实准确性、信息相关性、引用可溯源性和指令遵循度响应效率层面则主要看端到端延迟用户发出请求到收到完整回答的时间和吞吐能力。具体到 Octen Search 拿到的 77 分这个分数大概率是回答质量维度的综合得分。它不是一个及格线的概念而是经过多轮、多类型任务加权汇总后的量化结果。要理解 77 分的含金量不能只看绝对数字得看它在整个榜单里的位置——在 Artificial Analysis 的评测体系里头部梯队本身分数咬得很紧前几名之间往往只有几分甚至更小的差距。能在这样的密度里站到第三说明它的核心能力已经进入了第一方阵。1.3 为什么第三方评测值得作为选型依据我自己做技术选型的时候有个习惯厂商文档看架构官方博客看愿景但真要决定用哪个产品一定先看第三方评测和实测数据。原因很简单AI 搜索这类产品的体验由太多环节决定——检索的质量、重排的精准度、生成模型的推理能力、流式输出的稳定性任何一个环节拉胯整体体验都会崩。这些细节厂商不会在发布稿里告诉你但评测和实测会。Artificial Analysis 这类评测的价值还有一个隐形加成它把所有产品拉到同一批真实任务上做对比等于帮你省掉了自己造测试集的时间。你只需要关注它测的场景是否覆盖你的使用场景就可以把评测结论迁移到自己的选型决策里。2. 77 分的含金量Octen Search 的能力拆解2.1 排位背后的分数密度看榜单不能只看名次要看分数分布。Artificial Analysis 搜索评测的头部区域通常会出现一个很有意思的现象第一名和第二名可能就差 1 到 2 分第二和第三差 3 到 4 分再往下就开始出现明显的断层。Octen Search 以 77 分排第三说明它跟身前产品的差距是可追赶的而不是代差级的。这意味着什么意味着在绝大多数日常查询场景里Octen Search 的体验跟前排产品已经很难拉开肉眼可见的差距。差距主要集中在长尾任务——那些数据稀薄、语境复杂、需要多步推理的极端案例上。对普通用户来说这种差距的影响远小于评测分数给人的直觉印象。2.2 从分数结构反推核心优势77 分这个综合得分如果拆开看通常意味着产品在多个单点能力上没有明显短板。结合它速度最快的评级可以反推出几个技术侧的特征。第一检索与重排环节一定做得非常干净。AI 搜索绝大部分的笨都笨在检索环节——要么召回了一堆无关内容让模型产生误导要么该召回的高价值信息源被漏掉了。能在质量分上拿到这个位置说明其检索管道的召回率和重排模型的精准度都经过了认真打磨。第二生成环节的指令遵循能力在线。评测任务里有大量请给出带引用的回答请分步骤解释这类指令性要求模型如果遵循指令的能力弱这部分分就丢了。能拿到 77 分说明模型在结构化输出、引用格式遵循这些细节上表现稳定。第三流式输出和整体链路的工程优化做得好。速度评级不是单看某一个节点的耗时而是端到端的综合延迟。从查询解析、检索、重排、生成到输出整条链路的耗时都被压缩了这背后是大量的工程细节积累。2.3 与头部产品的差距在哪老实说第三名的位置也意味着 Octen Search 还有被拉开差距的地方。从评测经验来看这种差距通常集中在两类任务上。一类是高密度信息检索任务。比如用户问一个涉及多份文档交叉验证的问题回答需要同时整合多个信息源并且准确标注每句话的出处。这类任务对重排模型的要求极高头部产品可能专门针对这种场景做了强化普通产品在这里会露怯。另一类是复杂指令的稳定执行。普通查询大家都做得好但面对忽略前文中过时的信息只基于最新数据回答这类带约束条件的指令模型的执行稳定度就会分出高下。77 分说明主流场景表现优秀但这两类极端场景仍然值得继续观望。注意评测分数反映的是特定时间点、特定任务集上的表现。产品迭代很快榜单也会随之波动看评测要看趋势而不是看一次定生死。3. 速度最快的背后架构与优化思路3.1 AI 搜索的标准链路长什么样要理解 Octen Search 为什么快得先理解 AI 搜索的一次请求要经历什么。简单来说一次完整的 AI 搜索请求会经过五个环节查询理解把用户口语化的问题转成适合检索的形式、信息检索从索引里召回候选文档、重排对召回结果按相关度重新排序、上下文拼装把高相关度内容塞进模型上下文、生成回答LLM 逐 token 输出结果。这五个环节里任何一个环节耗时过多都会直接推高端到端延迟。很多 AI 搜索产品慢不是慢在生成而是慢在检索和重排——尤其当需要实时抓取网页时网络 I/O 的时间会非常不可控。Octen Search 能在综合速度评级里拿到第一说明它大概率在链路设计上做了并行化和分层缓存。3.2 延迟优化的几个关键手段从工程角度反推能把端到端延迟压到榜单最低通常离不开这几板斧。并行化检索是第一步。搜索请求细看往往不是单一查询而是多个子查询的组合。比如用户问对比 A 和 B 两款手机的续航和拍照系统可以拆成手机 A 续航手机 A 拍照手机 B 续航手机 B 拍照四个子查询并发执行。串行跑要四次网络往返并行跑只需要一次耗时最长的往返。这个优化做不做延迟差异是倍数级的。重排阶段的模型轻量化也很关键。重排模型如果直接用大参数量模型延迟会非常难看。常见的做法是用小模型做初排再用大模型或精排模型对前 N 条结果做二次排序既保证效果又控制耗时。这个策略在业界已经很成熟Octen Search 大概率也采用了类似的分级重排思路。生成环节的加速手段就更多了流式输出让用户第一时间看到字在蹦而不是干等投机采样和 KV Cache 优化能显著减少生成耗时简单任务走小模型、复杂任务走大模型的路由策略cascade routing也能在保证质量的前提下压低平均延迟。3.3 速度与质量如何兼得很多人有个误区觉得提速一定会牺牲质量。实际上在 AI 搜索里速度和质量的矛盾远没有想象中那么大关键在于算力花在哪里。一个聪明的系统会把 80% 的算力花在 20% 的复杂查询上而不是让所有查询都走一遍最重的链路。简单查询用轻量模型快速回答检索两次就出结果复杂查询才启动多路召回、长上下文、深度推理。这种分级路由的设计既保住了平均延迟又不牺牲复杂任务的上限质量。Octen Search 能同时拿到质量分第三和速度第一从技术逻辑上完全讲得通——它不是靠牺牲质量换速度而是靠聪明的资源调度让每一毫秒的算力都花在了刀刃上。4. 实操体验如何验证又稳又快4.1 上手路径想验证 Octen Search 的表现第一步自然是先找到入口。这类产品通常会提供 Web 端和 API 两种使用方式。Web 端适合普通用户快速体验API 适合做批量测试和性能压测。如果你只是想感受一下它的搜索质量直接打开网页版准备一批测试问题就行如果你是想评估它能不能接入自己的产品那就申请 API 密钥写几行脚本做自动化测试。我个人的建议是先用 Web 端手动测 20 到 30 个问题感受一下整体体验如果感觉不错再申请 API 做量化测试。不要一上来就写脚本因为搜索质量的体感差异很多时候是看文字比看分数更直观。4.2 设计一套你自己的测试集评测机构有评测机构的测试集你自己测也得有一份自己的测试集。我的经验是测试集至少要覆盖四类问题。事实型问题要测比如某本经典小说的作者是谁某款手机发布的时间是哪天重点是看回答是否准确、是否有引用来源。时效型问题也要测比如最近一周科技圈有什么大新闻这类问题考验实时检索能力很多搜索产品在这里翻车。对比型问题可以测比如A 和 B 两套方案各自的优缺点考验信息整合能力。还可以加几道指令约束型问题比如不要提及 2020 年之前的内容用三句话概括并给出依据看它能不能严格照做。每类问题准备五到十个测完之后记录三个指标回答准确率、引用可验证性、端到端耗时。三分记录法能让你在多个产品之间做横向对比时有据可依而不是凭感觉。4.3 用脚本量化延迟表现如果你想更严谨地测试速度可以写一段简单的脚本请求它的 API以 OpenAI 兼容接口为例记录请求发出到完整响应返回的耗时。import time import requests def test_search_latency(api_url, api_key, query): headers { Authorization: fBearer {api_key}, Content-Type: application/json, } payload { model: octen-search, messages: [ {role: user, content: query} ], stream: False, } start time.time() resp requests.post(api_url, jsonpayload, headersheaders, timeout30) elapsed time.time() - start return elapsed, resp.status_code, resp.json() for q in [为什么天空是蓝色的, 2024 年诺贝尔物理学奖得主是谁, 对比 REST 和 GraphQL 的使用场景]: cost, code, data test_search_latency(API_URL, API_KEY, q) print(fquery: {q} | status: {code} | latency: {cost:.2f}s)实测的时候有几个细节要注意网络环境要尽量稳定最好在同一网络下对比测试多个产品要分别记录首个 token 时间和完整响应时间因为流式输出下用户感知到的等待时间其实是首 token 时间每个问题至少跑三遍取平均值避免网络抖动带来的误差。技巧速度测试一定要在业务低峰期做。晚高峰时 API 可能因为负载高导致延迟显著上升这反映的是服务容量问题不是产品能力问题。5. 从评测看 AI 搜索的发展方向5.1 质量与速度的双 KPI 时代Artificial Analysis 把回答质量和响应速度放在同一张榜单里本身就是一个行业信号AI 搜索产品正在进入质量和速度双 KPI 的时代。前几年大家卷的是谁的回答更聪明现在多了一维——谁的体验更像搜索引擎。毕竟对用户来说等十秒出一个完美答案和等两秒出一个良好答案后者的实际体验更好。这个趋势对产品团队的启示很直接模型能力只是一半工程优化是另一半。同样的模型检索管道设计得好不好、缓存策略到不到位、路由逻辑聪不聪明最终体验可能差出一大截。Octen Search 能在速度维度拿第一说明这个团队在工程侧投入了足够多的精力。5.2 不同场景下的产品选型建议评测成绩怎么落到自己的使用决策里我给你几个粗略的判断框架。如果你是普通用户日常查资料、看新闻、找攻略Octen Search 这个级别的产品完全够用而且速度快的优势会让你用得舒服。如果你是重度研究者每天要做大量交叉验证和信息溯源那前排几个产品在复杂检索任务上的细微差距可能值得你在意建议针对自己的高频任务类型再做一轮实测。如果你是开发者打算把 AI 搜索能力集成到自己的应用里那除了质量和速度还要关注 API 的稳定性、价格成本和文档完善度——这些维度评测榜单不会告诉你得自己去看去测。5.3 对开发者的启发测什么决定你优化什么这次评测还有一个隐藏价值它给所有做 AI 搜索的开发者提供了一份能力体检清单。评测机构关注的维度往往就是用户真正在意的维度。如果你的产品也想在类似榜单上拿高分可以对照这套指标体系看看自己的检索召回率够不够、重排精准度行不行、端到端延迟还有多少压缩空间。我见过不少团队优化的重点放在模型 Prompt 上反复调提示词却忽略了链路里真正的瓶颈——比如检索阶段可能已经丢掉了关键信息重排阶段可能把正确答案排到了后面。评测的意义就在于帮你把视角从模型拉回系统关注整条链路的综合表现。6. 常见问题与排查实录6.1 分数理解的几个误区关于 77 分我在各个平台看到不少误读这里统一澄清一下。77 分不是及格线上的平庸分数而是评测体系里第一梯队的表现——尤其在 Artificial Analysis 这类扣分严格的评测里越往高分走每提高一分需要解决的技术问题就越复杂。第三名意味着产品已经跨过了可用的门槛进入了好用的区间。另一个常见误区是把综合分当成单一能力分。77 分是一个加权汇总的结果不同产品可能有不同的长板和短板。有的产品综合分略高但速度慢有的产品综合分略低但速度快得惊人。选型时应该结合自己的核心诉求看单项表现而不是只盯着一个综合分。6.2 实际使用中遇到的现象与应对我在测 Octen Search 的过程中也碰到过一些值得记录的现象。最典型的问题是部分查询响应变慢。同一个产品简单问题秒回复杂问题要等很久这其实是分级路由策略的正常表现不是故障。简单查询走了轻量链路复杂查询激活了深度推理链路耗时自然不同。应对方式是如果你对响应速度有硬性要求尽量避免一次抛出过于复杂的多跳问题拆成几个子问题逐个问体验会流畅很多。另一个现象是某些时效性查询的回答不够新。这通常不是模型的问题而是信息源的抓取频率和覆盖范围有限。应对方式是在提问时带上时间范围比如过去一周内帮助系统更精准地判断需要检索的时间窗口。6.3 避坑技巧速查表坑点现象对策高峰期测速延迟飙升错峰测试取多次平均值复杂问题一锅端响应慢且易出错拆解为多个子问题逐个提问不看引用直接信回答看着合理但出处存疑养成点开引用来源核实的习惯只测事实题低估/高估产品能力覆盖事实、时效、对比、指令四类问题忽略流式输出误判首字等待时间区分首 token 延迟和完整响应时间用同一 Prompt 套所有产品无法体现各自真实能力按产品特点分别设计匹配的测试集这张表里的经验不只是针对 Octen Search而是所有 AI 搜索产品实测时都可能踩的通用坑。6.4 值得留意的延伸能力最后说一个在榜单上看不到、但实测中给我留下印象的点Octen Search 对引用格式的处理。它给出的引用通常能对应到具体的来源句而不是泛泛地在结尾堆一串链接。这个细节在信息溯源场景里价值很高——你可以直接跳到原文核对而不是被引导到一篇完全不相关的网页。对我个人来说AI 搜索评测最大的意义不是帮你选一个永远最强的产品而是帮你建立一套判断产品好坏的方法。再好的评测榜单也只是某个时间点的快照产品在迭代榜单在变动只有掌握了自己验证、自己判断的能力才不会被任何一次评测结果牵着鼻子走。下次看到类似某产品在某评测中排第几的新闻建议你先去翻原始评测报告看看它的任务集覆盖了什么、没覆盖什么再决定这条新闻对你的参考价值有多大。这个习惯比记住任何一个具体分数都管用。