RAG 只能读静态网页快照：机票余票、酒店库存这类必须现场调用才会产生的信息，它从结构上就拿不到。 TURA 把网页检索也包装成一种 MCP Server，和各类 API 放在同一个池子里——先用意图分解 + 索引增强选出该用哪个，再用 DAG 把互不依赖的调用并行发出去，最后交给一个蒸馏过的 4B 小模型逐步执行工具。 代价是：整个离线评估建立在一个从生产日志构建的内部基准 MCP-Bench 上，而网页检索被放进了同一个检索池里。
arXiv v2 于 2026-03-12 提交，晚于笔记日期 2025-08-15；表号与结论以 v2 为准。
论文把 AI 搜索定义成一个带延迟上限的组合优化：选一组 MCP Server 调用策略 π，在 L(π) ≤ τmax 下最大化答案质量 Q(A)（Eq.1）。网页搜索本身也被当成一个 MCP Server，于是静态检索和动态 API 走同一套规划与执行。
三段各解决一个卡点：意图分解 + 为每个 Server 合成查询来扩充索引，把「用户口语 → 开发者文档」的词汇鸿沟垫平（Table 4/5）；DAG 规划器只在判定为复杂查询时被调用，简单查询走单任务方案（§4.3）；蒸馏执行器训练时学完整的 thought + action，上线时连 thought 一起生成以减少 token 与延迟（§4.4.2）。
最强的信号来自蒸馏：Qwen3-4B Distilled 工具调用准确率 88.3%，比它的基座 70.1% 高 18.2 个百分点，比教师 Deepseek-V3（671B-A37B）的 82.4% 高 5.9 个百分点；P80 延迟 750ms，是基座 2200ms 的 65.9% 降幅（Table 7）。但端到端 Table 1 的对比对象只是 LLM + RAG / Dynamic RAG / Tool-Agent，没有 "TURA 去掉蒸馏" 这一行，所以 Table 1 的差距里，蒸馏占多少、规划与检索占多少，论文没有拆分。
读完这节应能说清：为什么更强的检索模型救不了实时查询，以及论文把这类查询形式化成了什么。
网页检索读的是预先建好的静态快照。但有一类信息的产生方式就是「现场问一次系统」：某个日期的机票余票、电商数据库里的实时库存、铁路车次在指定日期的时刻表。这些内容在索引时还不存在，召回率再高也召不回来。
论文的做法不是给 RAG 打补丁，而是换一个形式化：把所有能力——包括网页搜索本身——都表示成 MCP Server M = {M₁, …, M_N}；一次具体的调用组合与顺序记作执行策略 π；目标是
这个改写把三类难点一次摆到台面：选哪些 Server（工具选择的语义鸿沟）、按什么顺序与并行度调用（多跳依赖）、用什么模型执行（生产环境的延迟）。后面三节依次对应。
评估基准 MCP-Bench 的规模（§5.1.1）：
多意图查询只占 4.98%（§5.1.1）。推断（依据：数据来自生产日志的自然分布，而 §5.3.2 又单独划出「复杂、多跳」子集才测 DAG——说明这部分是少数派，DAG 的收益只作用在少数查询上）。
读完这节应能说清：LLM+RAG、Dynamic RAG、Tool-Agent 各自卡在哪，以及它们在人工评测里分别落在什么水平。
Deepseek-V3 配百度的检索 API（跳过 rerank 只取原始文档），合成答案，不调用工具。
卡点：索引里没有实时数据，再强的 LLM 也只能复述旧网页。
生成过程中动态决定何时、检索什么，但仍然局限在静态索引。
卡点：检索时机变聪明了，仍然碰不到事务型 API。
ReAct 式与 DAG 式 agent，用同一批 MCP Server，但没有 TURA 的统一检索模块与蒸馏执行器。
卡点：能调工具了，但工具选择与执行延迟没做优化。
Table 1 的人工评测呈现出三级台阶（同一基准 MCP-Bench，指标为准确率 / 忠实度）：
| Method | Accuracy (Human) | Faithfulness (Human) |
|---|---|---|
| LLM + RAG | 65.3% | 72.4% |
| Dynamic RAG | 67.2% | 77.6% |
| Tool-Agent | 76.8% | 81.7% |
| TURA | 87.5% | 96.2% |
数据取自 Table 1 的 Human 列。同表的 LLM-as-judge 列：Accuracy 68.1% / 69.5% / 80.4% / 88.3%，Faithfulness 75.0% / 79.4% / 83.9% / 97.1%，顺序同表。
Tool-Agent 同时缺「统一 MCP 检索模块」和「蒸馏低延迟执行器」（§5.1.2 原话："do not incorporate our unified MCP server retrieval module or our distilled low-latency executor"）。所以 Table 1 中 Tool-Agent → TURA 的 +10.7 个百分点，是两个模块合起来的差，不能单独记在 DAG 或蒸馏任一头上。
读完这节应能动手算出：一个依赖图里有 k 条并行分支时会省下多少等待时间，以及论文里这条 DAG 具体长什么样。
论文 §4.3 完整走了一遍 Figure 2 的例子：查询 "Beijing trip June 10-15. Need hotel, 2-3 attractions and things to do."。规划器把子任务定义为 stk = (sq′k, Mk)——一个上下文相关的细化子查询，外加一个在 Mfinal 中选定的 MCP Server；当子任务 b 需要子任务 a 的输出作为输入时，连一条边 (va, vb)。
路由模型先判断复杂度：简单查询不走 DAG 规划器，直接构造单任务执行计划；只有被判为复杂的查询才调用由 Deepseek-V3 实现的 DAG 规划器（§4.3、§5.1.4）。执行时 orchestrator 沿图遍历，子任务一旦可执行就派给执行器。
Table 6 只在 MCP-Bench 中「复杂、多跳、存在并行可能」的子集上比较两种规划方式（成功率 88.9% → 89.1%，+0.2 个百分点）。
| Planning Method | Success Rate (%) | Avg. Latency (ms) ↓ |
|---|---|---|
| Sequential Plan | 88.9 | 1,650 |
| DAG Plan | 89.1 | 920 |
平均延迟降 730ms，相对 Sequential 降低 44.2%（730 / 1650 = 0.4424，与论文 §5.3.2 的 "reduces average latency by 44.2%" 一致）。论文原句是 "This substantial efficiency gain is achieved with no degradation in the execution success rate"——成功率的实际变化是 +0.2 个百分点（88.9 → 89.1）。
并行省的只是「等最慢那条分支」的时间：关键路径不变，其余分支重叠执行，总延迟由最长的那条路径决定。下图把 Figure 2 那张 DAG 搬到一个极简的耗时模型上（四个子任务等长、各为 t），切换规划模式、拖动子任务耗时，观察总延迟与节省比例。
在本模型里，降幅恒等于 1 − 步数 / 4：Figure 2 的 DAG 恒为 1 − 2/4 = 50.0%，全部无依赖恒为 1 − 1/4 = 75.0%，与 t 的取值无关。滑块只改绝对延迟（毫秒），比例的读数不随 t 变。
前两种对应 Figure 2：天气（Sub-task1）单独一条；景点（Sub-task2）、酒店（Sub-task3）各自先跑，然后共同汇入路径规划（Sub-task4）。第三种把 Sub-task4 的依赖人为拆掉，论文没有这个方案，只用来展示上界。
读数中比例与 t 无关，t 只改绝对延迟。
把 t = 450ms 代入：顺序 = 4 × 450 = 1800ms；Figure 2 的 DAG = 2 × 450 = 900ms，相对顺序执行降低 50.0%（少 900ms）；全部无依赖 = 450ms，相对顺序执行降低 75.0%。
规则（本页自定的示意模型，不是论文的算法）：
4t。[天气]、[景点 → 路径]、[酒店 → 路径]，各占 t、2t、2t，总延迟 = max(t, 2t, 2t) = 2t——不是 3t；本模型假定 Sub-task4 在两条分支上共用一个执行结果、只跑一次（论文 §4.3 未讨论 S4 被调用多次的情形，这是页面自定的假设）。max(t, t, t, t) = t。1 − total(模式) / total(Sequential)，百分比保留 1 位小数。第 1 组：t = 450ms，DAG（Figure 2）
顺序：4 × 450 = 1800 ms
Figure 2：max(450, 450 + 450, 450 + 450) = max(450, 900, 900) = 900 ms
降低比例：1 − 900 / 1800 = 0.5 → 50.0%，少 900ms。
第 2 组：t = 700ms，全部无依赖
顺序：4 × 700 = 2800 ms
无依赖：max(700, 700, 700, 700) = 700 ms
降低比例：1 − 700 / 2800 = 0.75 → 75.0%，少 2100ms。
为什么只有 2×、以及和 Table 6 的关系：关键路径是「景点 → 路径」两步，并行再彻底也要至少 2t，所以 4 个等长子任务的图最多降到顺序的一半。Table 6 的实际比值是 920 / 1650 ≈ 0.5576，高于本模型的 0.5。推断（依据：本模型假设四个子任务等长、除子任务外无其它开销；实际子任务长短不一，且规划、检索等环节有不能并行的固定开销，这两点都可能让实际比值高于关键路径下界）。
读完这节应能说清：教师轨迹怎么被筛成数据、学生为什么能超过教师，以及线上为什么最后选 4B 而不是最准的 30B。
用 Deepseek-V3 直接做细粒度执行在生产上不可行：每一步决策的上下文包括对话历史、Server 描述，以及论文所说的（未明确是每个 Server 之内还是整个上下文的）"dozens of tool APIs"（§4.4）。Table 7 的数字给出了量级：教师模型每步平均 P80 延迟 8,700ms。
教师模型按 ReAct 式三元组 ⟨ot, tht, at⟩ 生成轨迹（观察、思维、动作），然后过两道自动质检（§4.4.1）：
Jcorrect 检查是否遵守 API schema、参数值是否合法、思维是否逻辑成立，失败的整条丢弃。Jefficient 检查动作冗余、路径次优，这类轨迹 "either pruned or programmatically corrected"。训练用 Qwen3 系列，标准交叉熵损失覆盖 thought + action 的完整 token 序列（Eq.8）；上线时 prompt 明确要求直接产出 action、跳过 thought——这就是 "train-with-thought, infer-without-thought"。
学生超过教师，论文的解释是：数据管线 "effectively filters noise and crystallizes optimal reasoning paths into a targeted training dataset"（§5.3.3）。
| Agent Model | Model Size | Tool Calling Acc. (%) ↑ | Avg. Latency/Step P80 (ms) ↓ |
|---|---|---|---|
| GPT-4o | N/A | 81.7 | 6,800 |
| Teacher (Deepseek-V3) | 671B-A37B | 82.4 | 8,700 |
| Qwen3-1.7B | 1.7B | 43.5 | 1,500 |
| Qwen3-4B | 4B | 70.1 | 2,200 |
| Qwen3-30B-A3B | 30B-A3B | 76.3 | 2,600 |
| Qwen3-1.7B Distilled | 1.7B | 77.6 | 620 |
| Qwen3-4B Distilled | 4B | 88.3 | 750 |
| Qwen3-30B-A3B Distilled | 30B-A3B | 88.7 | 760 |
"…while concurrently achieving a 66% reduction in P80 latency (from 2,200ms to 750ms)."
(2200 − 750) / 2200 = 1450 / 2200 = 65.91% → 65.9%，与 66% 相差 0.1 个百分点。页面统一按原表数值计算。
读完这节应能说清：一个查询从进入系统到出答案，各段分别做了什么、在表上对应哪一列。
用户说的话和开发者写的工具文档用词不同。论文在离线阶段用生成模型 gLLM-gen 以高温 Thigh > 1.0 为每个 Server 合成一批可能的用户查询 Qisyn，与原始文档拼成 D′i = {Di} ∪ Qisyn，再逐段嵌入（ERNIE）。上线时把每个子查询与 Server 的全部向量做 max cos（Eq.4），跨子查询取最高分聚合（Eq.6），取 top-K。
| Retrieval Method | Recall@5 ↑ | Precision@5 ↑ |
|---|---|---|
| Dense Retrieval (ERNIE) | 0.4187 | 0.5505 |
| TURA (w/o Augment.) | 0.7500 | 0.8555 |
| TURA (w/o Decomp.) | 0.4530 | 0.5631 |
| TURA (Full) | 0.8289 | 0.9190 |
两个模块都撤掉哪个更致命，从 Table 4 能直接读出来：
合成查询放多少条也有拐点：Figure 3 显示 Recall@5 在 NQ = 20 时达到峰值，之后进入平台期，论文据此固定 NQ = 20。索引组织方式上，Table 5 比较了三种方案（NQ = 20）：Single-Vector 0.7721，Multi-Vector（Queries + Doc）0.8289，Multi-Vector（Queries Only）0.8299。Queries Only 略高 0.0010，论文仍选 Queries + Doc，给出的理由是保留原始文档作为 "safety net"。
Figure 3 的曲线未转录（只有峰值位置这条结论 + 表 5 的 NQ=20 截面）；Table 5 的 @5 指标列名在原文写作 P@5。
读完这节应能说清：线上 A/B 的三个指标各是什么口径、以及论文自身跨表引用时有一处对不上的地方。
| Online System | SSR | GSB |
|---|---|---|
| LLM + RAG (Legacy) | 55.1% | — |
| TURA (Ours) | 64.0% (+8.9%) | 13% / 86% / 4% |
数据取自 Table 2。SSR（Session Success Rate）的口径是「提供满意答案的会话占比」（§5.1.3，引 [7]）；GSB 是 TURA 相对线上 LLM + RAG 的人工对比评分，13% Good / 86% Same / 4% Bad，正文称 Same 为 "Satisfactory"。
TURA 的 SSR 单元格是 64.0% (+8.9%)，与 §5.2.2 正文 "It increased the Session Success Rate by 8.9%" 并列出现。
由 55.1% 与 64.0% 计算：绝对差 8.9 个百分点，相对提升 (64.0 − 55.1) / 55.1 = 8.9 / 55.1 = 16.15% → 16.2%。页面不替原文选口径。
| Online System | Total Issues | Advantage Rate | SSR |
|---|---|---|---|
| LLM + RAG (Legacy) | 66 | — | 55.1% |
| TURA (Ours) | 55 (−16.7%) | 8.7% | 64.0% (+8.9%) |
"Detailed performance analysis showing TURA's 8.7% performance advantage with significantly reduced error rates across all issue categories."（原文未给出 Advantage Rate 的计算口径，8.7% 无法与其他列互相核对。）
原文未给出 Advantage Rate 的计算口径（§5.1.3、§5.2.2 均未说明）。可查的邻近数字只有：Advantage Rate 8.7% vs SSR 差 64.0 − 55.1 = 8.9 个百分点；TURA 行的 (−16.7%) 与 (+8.9%) 分别对应问题数相对降幅 (66 − 55) / 66 = 16.67% 与 SSR 的绝对差。
正文还给出分类降幅：accuracy −7.1%、content richness −28.6%、content value −17.6%，以及关键失败从 9 降到 4（§5.2.2）。
读完这节应能判断：什么场景直接借鉴没问题，什么场景需要重新验证。
MCP-Bench 来自百度搜索的匿名化生产日志，人工标注（Cohens kappa 0.87），Server 与工具标识被匿名化后公开发布（§5.1.1 原句只承诺 "anonymizing server and tool identifiers"，页面不据此推断 service 侧域名或属性也已匿名化）。Table 1/4/5/6/7 的所有对比都在这个基准上，论文没有报告它与公开 benchmark 的交叉结果。
传统网页检索本身被当作一个 MCP Server（§3："traditional web retrieval is itself treated as an MCP server"）。推断（依据：§4.2 的召回在 top-K 处截断，"selecting the top-K servers"，且 Table 4 的 Recall@5 不满 1）：搜索引擎若没挤进 top-K，原本纯静态的查询也会失效——论文未单独报告纯静态查询子集上的效果，这个风险有多大无法从表中判断。
只有被判为复杂的查询才进 DAG 规划器，简单查询走单任务方案（§4.3）；MCP-Bench 中 95.02% 是单意图、平均 DAG 宽度 1.147，Table 6 的 44.2% 延迟降幅只在「复杂多跳、存在并行」的子集上测得，不能外推到全量。并行只压缩关键路径之外的等待，不减少总工具调用本地计算。
训练数据来自教师在「一组具有代表性的子任务」上生成的轨迹（§4.4.1："For a large set of representative sub-tasks"），再由两道裁判模型筛选。教师无法正确解决的子任务类型，学生也没有对应的正例。推断（依据：Eq.7 的 Ddistill 全部来源于 Dexpert；§5.3.3 把学生超教师解释为数据管线 "filters noise and crystallizes optimal reasoning paths"，未讨论管线之外的类型）。
论文的指标围绕答案质量、忠实度、SSR 与延迟；对 API 失败/超时后的重规划、工具调用的权限与安全，文中没有对应的实验或指标。推断（依据：§5.1.3 列出的评估指标全集不含失败恢复类指标）。
其中每一步的可复用性、以及在非百度搜索场景下能拿回多少收益，都要用自己的流量日志重新测——尤其第二块，它依赖教师模型和服务端 API 的具体分布。