CIDR 2026 · Deep Research · Semantic Operators · Analytics Runtime

Deep Research 要变成真正的数据分析系统，需要一个 Runtime

这篇论文的核心观点是：数据分析 Agent 不能只靠自由写 Python，也不能只靠固定 semantic operators。理想的 AI-driven analytics runtime 要同时具备 Agent 的灵活规划能力和数据库系统的优化执行能力。

论文：Russo et al. · CIDR 2026 官方标题：Deep Research is the New Analytics System 本地 PDF 已保存 关键词：Runtime / semantic operators / CodeAgent / Context

核心结论

做了什么

作者扩展 Palimpzest，加入 Context 抽象，以及两个由 CodeAgent 实现的新语义算子：search 和 compute。

解决什么问题

Deep Research Agent 会写代码、会探索数据，但执行计划经常很粗糙；semantic operators 可优化，但太静态。论文试图把二者合在一个 runtime 中。

和智能问数关系

它把“问数 Agent”从 prompt/SQL 生成问题提升到 runtime 问题：任务计划、算子选择、上下文复用、物化中间结果、成本优化。

为什么现有两类方法都不够

Runtime comparison
图 1：左边说明手写 semantic operator program 难处理交互式复杂分析；右边说明普通 Deep Research Agent 会走捷径，导致召回低。原型通过让 Agent 写优化后的 Palimpzest 程序来改进。

Semantic Operators 的问题

像 AI filter、AI map、AI join 这样的算子能被优化，但程序一旦写死，面对需要探索、多文件推理、动态修正的分析任务就不够灵活。

Deep Research 的问题

Agent 能动态写代码、读文件、调工具，但常见问题是执行不彻底：只读少量文件、用简单关键词过滤、提前停止，导致 recall 和 F1 低。

论文主张：AI analytics runtime 应该像数据库一样优化执行计划，同时像 Deep Research 一样允许动态探索和修正。

Runtime 设计

1

Context

把数据集、描述、工具、访问方法和中间结果包装成一个可传递对象，供 Agent 和算子使用。

2

Search Operator

让 Agent 在数据集中搜索、探索、收集信息，并产出更新后的 Context。

3

Compute Operator

让 Agent 根据 Context 写 Palimpzest 程序或代码，计算最终结果。

4

Optimization

复用数据库优化思想：query rewrite、cost-based optimization、physical operator optimization、materialized Context。

Context and physical plan
图 2：Palimpzest 程序和物理计划。search operator 先扩充 Context，compute operator 再使用中间 Context 执行计算。
ds = pz.Context(
    path="legal/",
    desc="FTC data on fraud and identity theft reports"
)

ds = ds.search("thefts info")
ds = ds.compute("2024 thefts")

# Runtime 可以优化 search/compute 的执行方式：
# - 选择便宜模型还是强模型
# - 是否复用 materialized Context
# - 是否拆分复杂 compute
# - 是否插入额外 search 辅助 compute

Context 为什么关键

论文中的 Context 类似数据分析过程里的“可物化中间状态”。它不只是数据引用，还包括自然语言描述、访问方法、工具、Agent 生成的中间发现。

Context 内容作用智能问数映射
数据路径/数据集引用告诉算子在哪里读数据数仓表、文件、向量库、文档库
自然语言描述帮助 Agent 理解数据含义表描述、字段口径、业务语义
访问方法支持迭代、索引、top-k、工具调用SQL、MCP tool、检索接口、指标服务
中间结果作为后续算子的输入schema linking 结果、候选 SQL、临时表、结果摘要
Materialized Context复用之前执行结果智能问数缓存、上下文缓存、查询计划缓存

实验结果

Kramabench table
表 1：在 Kramabench 查询上，PZ compute 的错误率最低，但耗时较高。它验证了动态 compute 能解决手写 semantic program 难处理的任务。
Enron table
表 2：在 Enron 邮件查询上，PZ compute 达到和 CodeAgent+ 同样的 F1，但成本和时间大幅降低。
1.95x

F1 提升

摘要中报告，相比标准 open Deep Research agent，原型最高达到 1.95x F1-score。

76.8%

成本节省

相比把 semantic operators 当工具交给 CodeAgent+ 手动调用，compute 节省 76.8% 成本。

72.7%

运行时间节省

同一设置下，compute 节省 72.7% runtime，原因是 Palimpzest 的执行引擎避免了冗余算子调用。

限制：实验只有两个示例查询，且原型紧耦合 Palimpzest。它是 vision/prototype，不是完整产品级 runtime。

对智能问数/数仓 Agent 的落地启发

如果你的项目已有 skill + MCP + SQL 生成链路，这篇论文的价值在于提醒：需要把 Agent 的每一步变成 runtime 可管理对象，而不是让 LLM 自由串 prompt。

论文概念智能问数落地建议
Context一次问数任务的执行状态保存用户问题、意图、schema linking、候选 SQL、执行结果、错误反馈
search探索/补充信息查字段目录、样例值、文档、历史问法、数据血缘
compute生成并执行查询计划生成 SQL、调用 MCP、聚合结果、生成图表数据
materialized Context缓存中间状态缓存 schema linking、查询计划、临时结果，供后续问题复用
optimizer调度策略决定何时用强模型、何时只查缓存、何时拆分问题、何时插入补充检索
工程建议：把智能问数链路设计成 runtime：每一步有输入、输出、成本、耗时、错误、缓存键。这样才能做回放、调优、降本和可靠性评估。

评价

创新点

它不是再做一个数据分析 Agent，而是提出 Agentic analytics 应该有 runtime 和 optimizer，方向更接近数据库系统研究。

局限

当前实现范围小，实验少，主要验证方向。生产系统还要补权限、数据版本、失败恢复、并发、观测、成本预算和安全边界。

结论：这篇适合指导“智能问数 harness/runtime”的架构设计。核心不是让 Agent 更会写代码，而是让 Agent 的代码、工具调用和语义算子进入一个可优化的执行框架。

资料来源

官方 PDF：https://www.vldb.org/cidrdb/papers/2026/p30-russo.pdf

本页面根据 CIDR 官方 PDF 本地抽取正文与图表生成。当前环境未暴露 paper2html skill，因此使用等价本地流程完成。