SemBench：一个用于语义查询处理引擎的基准测试

论文信息

• 标题 (Title)：SemBench: A Benchmark for Semantic Query Processing Engines

• 标题 (中文)：SemBench：一个用于语义查询处理引擎的基准测试

• 作者 (Authors)：Jiale Lao, Andreas Zimmerer, Olga Ovcharenko, Tianji Cong, Matthew Russo, Gerardo Vitagliano, Michael Cochez, Fatma Özcan, Gautam Gupta, Thibaud Hottelier, H. V. Jagadish, Kris Kissel, Sebastian Schelter, Andreas Kipf, and Immanuel Trummer

• 期刊/会议 (Journal/Conference)：arXiv Preprint (cs.DB)

• 发表年份 (Year)：2025

• DOI (Digital Object Identifier)：N/A (arXiv preprint)

• 原文链接 (URL)：https://arxiv.org/abs/2511.01716v1

结构化摘要 (Structured Abstract)

• 背景/目标 (Background/Objective)：随着大型语言模型 (LLM) 的兴起，一类新型的“语义查询处理引擎” (Semantic Query Processing Engines, SQPEs) 应运而生。这些系统将 SQL 与由自然语言指令配置的“语义算子”相结合，用于处理文本、图像、音频等多模态数据。然而，传统的数据库基准测试（如 TPC-H）无法评估这些系统的性能，因为其核心瓶颈已从传统的关系运算转向成本高昂且结果不确定的 LLM 调用。本研究的目标是提出一个名为 SemBench 的全新基准测试，旨在全面、严谨地评估和比较不同 SQPEs 在成本、延迟和准确性上的表现。

• 方法 (Methods)：研究者设计并构建了 SemBench，它涵盖了三个关键维度：1) 5个多样化的场景（电影评论分析、野生动物监测、电子商务、医疗记录、多模态问答）；2) 3种数据模态（文本、图像、音频）；3) 一系列核心语义算子（语义筛选、连接、映射、排序和分类）。研究团队使用 SemBench 对三个学术原型系统（LOTUS, Palimpzest, ThalamusDB）和一个工业级系统（Google BigQuery）进行了全面的实验评估。

• 结果 (Results)：实验结果表明，不同 SQPEs 在处理语义查询时表现出巨大的性能差异。某些查询的成本在不同系统间相差超过100倍。性能差异主要源于各系统对关键语义算子（尤其是语义连接和 LIMIT 子句）的实现方式以及提示（Prompt）设计的不同。没有任何一个系统在所有指标上都表现最佳，它们在成本、质量和延迟之间进行了不同的权衡。

• 结论 (Conclusion)：SemBench 成功地揭示了当前语义查询处理引擎的优势与不足，证明了其作为评估工具的有效性。研究结论强调，算子实现、查询优化和提示工程是提升 SQPEs 性能的关键。该基准为未来在这一新兴领域的研究和开发提供了明确的方向和坚实的评估基础。

1. 引言 (Introduction)

1.1. 研究背景与核心问题 (Research Background & Problem Statement)

本研究处于数据库系统与人工智能交叉的前沿领域。大型语言模型 (LLM) 的发展催生了一类新的数据处理系统——语义查询处理引擎 (SQPEs)。这类系统通过引入“语义算子”（如 AI.IF），允许用户使用自然语言指令对存储在数据库表中的多模态数据（文本、图像、音频）进行复杂的分析。例如，用户可以直接用 SQL 查询“计算所有包含‘红色汽车’的图片数量”。

然而，这种新的查询模式带来了根本性的性能挑战。传统的数据库系统优化目标是最小化 I/O 和 CPU 消耗，而 SQPEs 的性能瓶颈则转变为对 LLM 的调用。LLM 调用不仅成本极高（比传统数据处理高出数个数量级），而且其返回结果具有随机性，导致准确率并非100%。因此，SQPEs 的核心优化问题变成了：如何在最小化 LLM 调用的成本和延迟的同时，最大化查询结果的准确性？

现有的数据库基准测试（如 TPC-H, TPC-DS）完全专注于关系型数据和操作，无法衡量 SQPEs 的性能。因此，学术界和工业界迫切需要一个标准的评估框架。本文提出的核心研究问题是：

• RQ1: 如何设计一个能够全面评估现代 SQPEs 在多模态数据上性能（成本、延迟、质量）的基准测试？

• RQ2: 当前最先进的 SQPEs 在处理各类语义查询时的表现如何？它们的优势和弱点分别是什么？

• RQ3: 哪些技术因素（如算子实现、优化策略）是导致 SQPEs 性能差异的关键？

这是一个全新的问题，因为 SQPEs 本身就是近两年才出现的新事物。

1.2. 文献综述与研究缺口 (Literature Review & Research Gap)

作者主要从以下三个领域回顾了现有研究：

1. 众包数据库系统 (Crowdsourced Database Systems)：如 CrowdDB，这类系统在2010年代初就提出了将自然语言任务嵌入 SQL 的构想，但它们依赖人类工作者来执行这些任务，成本高、延迟大、可扩展性差。SQPEs 可以看作是这一理念在 LLM 时代的“技术继承者”。

2. 传统数据库基准测试 (Related Benchmarks)：如 TPC-H 和 TPC-DS，它们是评估分析型数据库性能的黄金标准，但其设计完全围绕关系代数，不包含语义算子，也未考虑 LLM 带来的成本和准确性维度。

3. 多模态问答基准 (Multimodal QA Benchmarks)：这类基准主要用于评估 AI 模型本身在理解和回答多模态问题上的准确性，但它们不关注承载这些模型的“系统”层面的性能，如查询处理的端到端延迟、货币成本和查询优化策略。

研究缺口 (Gap)：当前学术界和工业界缺乏一个专门为语义查询处理引擎设计的、能够系统性地衡量其在成本、延迟和准确性之间权衡的综合性基准测试。

1.3. 研究目标与核心假设/命题 (Objectives & Hypotheses/Propositions)

研究目标：

1. 设计并发布 SemBench：一个全新的、涵盖多种场景、数据模态和语义算子的公开基准测试，为 SQPEs 的评估提供统一标准。

2. 进行首次基准评估：利用 SemBench 对当前主流的学术和工业 SQPEs 进行深入的实验评估，提供一个性能快照。

3. 洞察与未来方向：分析实验结果，揭示影响 SQPEs 性能的关键因素，并为未来的研究指明方向。

本文没有提出明确的定量假设，而是基于一个核心命题 (Proposition)：不同的 SQPEs 在架构、算子实现和优化策略上存在显著差异，这将导致它们在 SemBench 的各项指标（成本、质量、延迟）上表现出不同的权衡和优劣势。

2. 研究设计与方法 (Methodology)

2.1. 研究范式与方法论 (Research Paradigm & Methodology)

本研究采用定量 (Quantitative) 的基准测试 (Benchmarking) 方法论。研究的核心是构建一个标准化的测试环境（数据集、查询集、评估指标），以客观、可复现的方式测量和比较不同系统（SQPEs）的性能。

论文中提到的解决方案之关键是什么？
SemBench 的关键在于其多维度和综合性的设计，它超越了传统的性能测试，专门针对 SQPEs 的核心挑战：

1. 关注 LLM 核心成本：所有查询都设计为让语义算子（即 LLM 调用）的开销在总计算成本中占主导地位。

2. 多模态数据整合：基准测试的数据表不仅包含传统 SQL 类型，还直接处理图像和音频数据，模拟真实应用场景。

3. 三位一体的评估指标：同时评估货币成本、执行延迟和结果质量，全面反映系统的综合表现。

4. 算子覆盖的广度：涵盖了从简单的语义筛选到复杂的语义连接等一系列当前 SQPEs 支持或应该支持的核心算子。

跟之前的方法相比有什么特点和优势?
与 TPC 等传统基准相比，SemBench 的优势在于其相关性和针对性。它不衡量已经成熟的关系运算性能，而是专注于评估新兴的、由 LLM 驱动的语义查询处理能力。与 AI 模型基准相比，它的优势在于其系统级视角，评估的是端到端的查询处理系统，而不仅仅是底层模型的质量。

2.2. 数据来源与样本 (Data Source & Sample)

• 数据来源：SemBench 的数据主要通过整合来自 Kaggle 等平台的、带有高质量人工标注的公开数据集构建而成。利用这些已有的人工标注，研究者可以生成查询的“标准答案”（Ground Truth），从而精确地评估查询结果的质量。

• 样本：基准测试包含5个独立的场景，每个场景都有自己的数据库。

  • Movies: 电影评论情感分析（仅文本）。

  • Wildlife: 基于图像和音频识别动物及其共现关系。

  • E-Commerce: 基于商品描述和图片进行时尚零售分析。

  • Medical: 模拟多模态电子健康记录系统，包含文本、X光图像、皮肤镜图像和肺音音频。

  • MMQA: 多模态问答，涉及表格、文本和图像。

• 由于 LLM 调用成本高昂，实验中使用了规模因子 (Scale Factor) 来控制每个场景使用的数据行数，从几百到几千不等，以确保实验可以在合理的时间和预算内完成。

2.3. 操作化与测量 (Operationalization & Measurement)

• 核心概念操作化：论文将“语义查询能力”具体化为五种核心的语义算子 (Semantic Operators)：

  • sem_filter: 根据自然语言条件筛选数据。

  • sem_join: 根据自然语言描述的匹配条件连接两个表。

  • sem_map: 根据自然语言指令转换数据。

  • sem_rank: 根据自然语言标准对结果进行排序。

  • sem_classify: 根据预定义类别对数据进行分类。

• 关键变量测量：

  1. 处理开销 (Processing Overheads)：

     • 货币成本 (Monetary Cost)：最重要的指标，直接反映调用 LLM API 的费用。

     • 延迟 (Latency)：查询执行的总时间。

     • 其他：LLM 调用次数、Token 消耗量。

  2. 结果质量 (Result Quality)：通过与“标准答案”比较来衡量。

     • 聚合查询 (如 COUNT)：使用相对误差。

     • 检索查询 (返回行)：使用 F1 分数。

     • 排序查询：使用斯皮尔曼等级相关系数 (Spearman's rank correlation)。

     • 分类/分组查询：使用调整兰德指数 (Adjusted Rand Index, ARI)。

3. 结果与发现 (Results & Findings)

3.1. 主要发现概述 (Overview of Key Findings)

• 性能差异巨大：不同系统在处理相同查询时，成本和延迟差异悬殊。在“Movies”场景中，对于涉及 LIMIT 子句的查询，系统间的成本差异超过 100倍。

• 算子实现是关键：性能差异主要源于对语义算子的不同实现策略。

  • LIMIT 优化：能够提前终止计算（一旦满足 LIMIT 的行数）的系统，其成本和延迟远低于那些必须处理完所有数据后再应用 LIMIT 的系统。

  • 语义连接优化：简单的逐对比较（每对元组调用一次 LLM）成本极高。采用近似方法（如先用 embedding 筛选候选对）或批处理（将多个元组打包进一个 prompt）的系统，成本显著降低，但可能会牺牲一定的准确性。

• 系统间的权衡：

  • Google BigQuery：作为唯一的商业系统，在功能支持和延迟方面表现稳健，但在处理图像等高成本模态时，其费用显著高于其他系统。

  • ThalamusDB：在支持的查询上通常能实现最低的成本，这得益于其积极的批处理策略，但其算子支持范围有限。

  • LOTUS & Palimpzest：作为功能较全的学术系统，它们在成本和质量之间展现了不同的设计哲学。例如，Palimpzest 的 prompt 更详尽，质量稍高但成本也更高。

• 没有“银弹”：没有任何一个系统在所有场景和指标上都取得胜利，这表明 SQPEs 领域仍处于早期发展阶段，优化空间巨大。

3.2. 关键数据与图表解读 (Interpretation of Key Data & Figures)

图/表 1：Table 4 - Movies 场景的实验结果

• 展示内容：该表详细列出了在 Movies 场景下，四个系统（LOTUS, Palimpzest, ThalamusDB, BigQuery）针对10个不同查询在成本、质量和延迟上的具体表现。

• 揭示关系：

  • Q1, Q5, Q6 (带 LIMIT 子句的查询)：ThalamusDB 和 Palimpzest 的成本极低（约

    $0.01\text{），而}LOTUS\text{和}BigQuery\text{成本高出很多（}$

    0.09 - $2.38）。这直观地展示了 LIMIT 优化策略带来的巨大影响。

  • Q7 (语义连接查询)：所有系统的成本和延迟都非常高，Palimpzest 耗时最长（1056.1s），成本最高（

    $7.72\text{）。这表明语义连接是当前}SQPEs\text{面临的最具挑战性的操作。}ThalamusDB\text{在此表现出显著的成本优势（}$

    0.15），但质量也最低（0.57）。

• 关键数据支撑：该表用精确的数据证实了“算子实现是性能关键”的核心发现。

图/表 2：Figure 1 - Movies 场景的相对成本

• 展示内容：该柱状图将每个查询在各个系统上的执行成本，除以该查询的最低成本（在所有系统中），从而进行归一化，直观地展示了“成本超支”的倍数。

• 揭示关系：图表清晰地显示，在 Q1, Q5, Q6, Q7 这几个查询上，某些系统的成本柱（如 LOTUS）达到了 10^2 的级别，意味着比最高效的系统贵了100倍以上。这极具视觉冲击力地强调了系统间性能的巨大鸿沟。

4. 讨论 (Discussion)

4.1. 结果的深度解读 (In-depth Interpretation of Results)

这些研究发现意味着语义查询处理引擎的性能远未达到成熟和标准化的阶段。开发者和用户不能将其视为一个黑盒，因为系统内部的实现细节（如是否进行近似计算、如何设计 prompt、是否支持批处理）会对最终的成本和结果产生决定性影响。

研究结果清晰地回答了引言中的研究问题：

• 不同的 SQPEs 在性能上表现出巨大的差异。

• 这种差异主要由语义连接、LIMIT 子句等关键算子的实现策略以及 prompt 设计哲学所驱动。

• 目前的系统在功能完备性、成本控制和结果质量之间进行了不同的、有时是痛苦的权衡。

4.2. 理论贡献 (Theoretical Contributions)

• 首个评估框架：本文最重要的贡献是提供了第一个用于评估和比较 SQPEs 的标准化基准和方法论 (SemBench)。它填补了该领域的评估空白，为后续研究建立了一个共同的对话基础和竞争平台。

• 重新定义优化问题：研究将 SQPEs 的优化问题明确定义为一个多目标优化问题（成本、延迟、质量），推动了数据库领域从传统的基于成本的优化向更复杂的多维权衡转变。

• 对业界的潜在影响：SemBench 为 Google (BigQuery), Snowflake 等云数据仓库厂商开发和优化其 AI 功能提供了清晰的路线图和竞争压力。它指明了哪些算子是核心，哪些优化技术是有效的，从而加速技术的成熟和商业化。

4.3. 实践启示 (Practical Implications)

• 对系统开发者：应优先优化成本高昂的算子，如语义连接。提供灵活的选项，让用户可以在成本和质量之间进行权衡（例如，选择快速但可能不准的近似算法，或选择慢但精确的算法）。

• 对数据分析师/用户：在使用 SQPEs 时必须“成本意识”。简单的查询重写或选择不同的系统都可能导致账单的巨大差异。在关键业务上，需要仔细验证语义查询返回结果的准确性。

4.4. 局限性与未来研究 (Limitations & Future Research)

• 局限性：

  • 时间快照：所有被评估的系统都在快速迭代中，本文结果只是一个时间点上的快照。

  • 有限的调优：研究没有对每个系统进行深度参数调优，仅使用默认或推荐配置。

  • 数据规模：受限于成本，实验使用的数据规模远小于传统的大数据基准。

• 未来研究：

  • 新的优化技术：研究如何将多个语义算子融合 (fuse) 到一个 LLM 调用中，以及如何利用缓存 (caching) 来重用相似查询的结果。

  • 自动化 Prompt 工程：开发能够根据查询需求自动调整 prompt 以平衡成本和质量的策略。

  • 扩展 SemBench：在未来版本中加入更多算子（如语义聚合）和更多场景。

  • 评估不同 LLM 的影响：系统性地研究更换后端 LLM（如从 GPT-4 到 Llama 3）对 SQPEs 性能的影响。

5. 结论 (Conclusion)

本文成功地设计并实现了一个名为 SemBench 的综合性基准测试，专门用于评估新兴的语义查询处理引擎。通过对四个代表性系统的严格实验，研究揭示了当前 SQPEs 性能上存在的巨大差异，并准确定位了差异的关键来源——语义算子的实现策略和 prompt 设计。SemBench 不仅为研究者和开发者提供了一个急需的评估工具，也为这个充满潜力的新领域的未来发展指明了清晰的优化方向。

6. 核心参考文献 (Core References)

1. ** Liu, C., Russo, M., Cafarella, M., et al. (2025). Palimpzest: Optimizing ai-powered analytics with declarative query processing.**

   • 被评估的核心学术系统之一，代表了通过多层优化来平衡成本和质量的研究方向。

2. ** Patel, L., Jha, S., Guestrin, C., & Zaharia, M. (2024). LOTUS: Enabling Semantic Queries with LLMs Over Tables of Unstructured and Structured Data.**

   • 被评估的另一个核心学术系统，展示了如何通过近似计算（如 embedding）来优化语义算子。

3. ** Franklin, M. J., & Kossmann, D. (2011). CrowdDB: answering queries with crowdsourcing.**

   • SQPEs 的思想前身，展示了将人类智能（自然语言任务）集成到数据库查询中的早期尝试。

4. ** Fernandes, S., & Bernardino, J. (2015). What is BigQuery?.**

   • 被评估的工业级系统的代表，其对 AI 功能的支持反映了这一技术的商业化趋势。

5. ** Brown, T. B., Mann, B., Ryder, N., et al. (2020). Language models are few-shot learners.**

   • 奠基性的 LLM 论文，其揭示的零样本/少样本学习能力是所有 SQPEs 存在的技术基础。

–EOF–
转载须以超链接形式标明文章原始出处和作者信息及版权声明.