小红书数据平台部 ICDE 2026 新成果：RedParrot 以语义缓存加速企业级自然语言数据分析

近日，小红书数据平台部联合浙江大学在 ICDE 2026 发表论文《RedParrot: Accelerating NL-to-DSL for Business Analytics via Query Semantic Caching》，提出了一种面向企业级商业分析场景的自然语言到 DSL（NL-to-DSL）加速框架。该框架围绕真实业务查询中高重复度、强结构化模式的特点，构建查询语义缓存，并通过查询骨架匹配、实体无关向量表示和多源异构 RAG，将传统多阶段 LLM 工作流压缩为更短链路的生成流程。

在小红书真实业务数据集上，RedParrot 平均实现 3.6x 推理加速，并带来 8.26% 的执行准确率提升；在由 Spider 和 BIRD 改造而来的开放 NL-to-DSL 基准上，整体准确率提升 34.8%，显著优于标准 In-Context Learning 基线。相关研究成果发布于 ICDE 2026 会议上，ICDE（International Conference on Data Engineering）是数据库与数据工程领域的顶级会议，与 VLDB、SIGMOD 并称数据库三大顶会，聚焦数据库系统、数据管理、大规模数据处理等方向。

论文链接：https://arxiv.org/abs/2604.22758

1.1 背景与挑战

随着电商、广告、社区内容与商业化业务的快速增长，业务同学对实时数据分析的需求正在从“固定报表查询”转向“自然语言交互式分析”。用户希望直接用自然语言描述问题，例如“过去 7 天 iPhone 17 的出货量”或“2025 年 Apple 的销售额”，系统则需要自动理解意图、定位数据、生成可执行查询，并返回文本或可视化结果。

在企业场景中，为了保证指标语义一致、权限可控和执行稳定，系统通常不会直接让大模型生成 SQL，而是先将自然语言转换为受控的领域专用语言 DSL。DSL 统一表达维度、指标、过滤条件和聚合逻辑，再由底层系统编译到 SQL、可视化配置或其他执行后端。这样的语义层设计提升了可靠性，但也让 NL-to-DSL 成为业务智能分析链路中的关键步骤。

在小红书的实践中，早期 NL-to-DSL 方案采用长链路 LLM 工作流：先做问题解析与意图澄清，再做数据检索，随后分别生成维度、指标、过滤条件等 DSL 组件，最后进行校验。该方案具备较好的可解释性和工程可控性，但也带来显著问题：多次 LLM 调用导致 P90 延迟超过 30 秒，单次请求消耗超过 26000 tokens，且前置阶段的错误会逐步传递到后续 DSL 生成中，最终影响线上体验和结果稳定性。

进一步观察真实业务查询可以发现，用户的问题虽然表达多样，但结构模式高度重复。例如“Apple 25 sales”和“Huawei 23 到 25 年销售额”在实体和时间范围上不同，但背后的查询结构、目标表和 DSL 形态高度相似。这意味着，历史查询中的结构化经验可以被复用，而不是每次都从零开始走完整长链路。

1.2 核心贡献

本文的核心贡献包括以下三个方面：

其一，提出了面向企业级商业分析的查询语义缓存框架 RedParrot。框架不再完全依赖多阶段 LLM 推理，而是将历史查询抽象为可复用的“查询骨架”，并通过匹配相似骨架复用历史 DSL 模板，从而显著降低推理延迟和 token 成本。

其二，提出了混合式查询骨架构建与实体无关表示学习方法。离线阶段，系统通过 LLM、命名实体识别、规则过滤、聚类与连通图筛选构建高质量骨架缓存；在线阶段，系统使用对比学习训练得到的实体无关编码器，直接从原始用户查询中捕捉结构相似性，减少额外骨架抽取步骤带来的误差传播。

其三，提出了多源异构 RAG 增强的 DSL 生成机制。RedParrot 同时引入 DSL 配置知识、列值知识和企业领域知识，用于补足历史模板无法覆盖的新实体、新字段、业务缩写和专有语义，使短链路方案在保持低延迟的同时具备较强泛化能力。

2.1 企业级 NL-to-DSL 的长链路瓶颈

自然语言数据分析看似是“问一句、查一次”的简单过程，但在企业系统中，模型必须同时解决多个问题：理解用户真实意图，选择正确宽表，识别业务指标，映射字段和枚举值，配置维度、指标、过滤条件，并生成满足系统约束的 DSL。任何一个环节出错，都可能导致最终结果不可执行或语义偏差。

因此，传统方案通常将任务拆成多个阶段，以换取更高的可控性：问题解析负责意图澄清，数据检索负责定位表和字段，DSL 生成负责逐项填充配置，校验模块负责发现结构错误。这种方式适合冷启动和复杂查询，但在高频在线分析场景下代价过高。

论文对长链路流程的成本进行了统计：在社区业务数据集上，问题分析、数据检索、维度生成、指标生成和过滤条件生成合计 P90 延迟达到 30.25 秒，token 消耗达到 26271，最终执行准确率仅为 35.00%。这说明问题不只是“模型不够强”，而是链路本身过长，导致延迟、成本和误差传播同时累积。

2.2 查询骨架重复带来的加速机会

真实业务查询具有显著的结构复用特征。不同用户可能询问不同品牌、时间范围或业务对象，但问题背后的 DSL 结构常常一致：它们访问同一类宽表，使用相近的维度和指标，只在实体值、时间窗口或过滤条件上发生变化。

RedParrot 将这种稳定结构抽象为查询骨架。查询骨架会去除实体、时间等易变信息，保留决定 DSL 形态的核心语义。例如“Apple 25 sales”可以抽象为“? sales ?”，与其他品牌或时间范围的销售查询共享相似结构。只要新查询能匹配到历史骨架，系统就可以复用对应 DSL，再结合当前实体和领域知识进行改写。这一观察使 NL-to-DSL 从“每次完整推理”变成“先检索可复用结构，再少量生成改写”。对于大量重复模式的企业查询，这种短链路方案能够天然降低 LLM 调用次数和上下文长度。

2.3 新实体与业务知识带来的泛化挑战

单纯依赖历史模板并不足够。企业查询会持续出现新商品、新账号、新业务字段、新缩写和新指标口径，而这些内容往往不在历史缓存中。如果系统只根据相似骨架复用 DSL，可能会在字段映射、枚举值归一化或业务术语理解上出错。例如，用户在电商场景中询问 “DGMV” 时，系统需要知道它代表 Direct Gross Merchandise Volume，并进一步映射到真实表中的指标字段；当用户使用“竞价广告”“auction ads”等别名时，系统还需要将自然语言表达归一到数据库中的标准枚举值。缺少这些知识，短链路即使命中了模板，也难以生成正确 DSL。因此，RedParrot 的设计并不是简单缓存历史 DSL，而是将语义缓存与企业知识检索结合：缓存解决结构复用，RAG 解决动态知识补全，两者共同支撑在线生成。

2.4 查询结构相似性难以直接匹配

查询相似并不等于结构相似。两个查询可能因为共享实体或词汇而在普通向量空间中非常接近，但实际访问的表和 DSL 结构完全不同；反过来，两个查询可能表述不同，却拥有相同骨架和 DSL 形态。例如“Apple 25 sales”和“Apple 2025 product catalog”都包含 Apple 和 2025，但前者关注销售额，后者关注商品目录，最终可能落到不同宽表和不同 DSL。传统通用 embedding 更容易被实体词影响，而 RedParrot 需要模型关注“查询骨架”本身。

为解决这一问题，RedParrot 训练实体无关的结构表示模型，通过对比学习让相同骨架的查询在向量空间中更接近，让不同结构的查询拉开距离，从而提升缓存命中的准确性。针对上述挑战，小红书数据平台部联合浙江大学提出了 RedParrot（Query Semantic Caching for NL-to-DSL）框架。该框架围绕“历史结构复用 + 领域知识补全 + 单次 DSL 改写”的思路，将原本需要多阶段 LLM 调用的链路压缩为查询编码、模板检索、知识检索和 DSL 改写四个核心步骤。

3.1 查询骨架缓存构建

RedParrot 的离线阶段首先从历史查询和对应 DSL 中构建骨架缓存。系统会通过 LLM 生成初始查询骨架，并使用命名实体识别与规则过滤去除残留实体、时间表达等干扰信息，得到更稳定的结构表达。

随后，系统使用向量模型将骨架映射到表示空间，并通过 K-means 聚类完成初步分组。在每个聚类内部，RedParrot 进一步构建基于相似度的连通图，将同一聚类中的骨架划分为更细粒度的连通分量，并选取代表性强、连接度高的骨架加入缓存。

这种设计使缓存既不会无限膨胀，也不会只保留少量粗糙模板。最终得到的骨架缓存具备三个特点：体量可控、结构代表性强，并且能够通过后续增量更新持续演进。

3.2 实体无关表示模型

在线推理时，如果先让大模型抽取查询骨架，再拿骨架去检索缓存，链路会重新变长，也会引入新的抽取误差。RedParrot 因此选择训练一个实体无关 embedding 模型，使其能够直接从原始查询中捕捉结构相似性。

模型训练采用自监督对比学习。系统基于离线阶段得到的骨架聚类和连通分量自动构造三元组：同一连通分量中的查询作为正样本，同一聚类但不同连通分量的查询作为 hard negative，不同聚类中的查询作为普通负样本。训练目标是拉近结构相同的查询，拉远结构不同的查询，同时保留必要上下文。

实验显示，该实体无关模型相比同等规模的 Qwen3-embedding-0.6B，在三个企业数据集上 HR@5 平均提升 4.23 个百分点，FHR@5 平均提升 12.47 个百分点。也就是说，它不仅更容易找回相关模板，也更擅长在多意图查询中找全所有关键结构。

3.3 多源异构知识检索

为了处理历史缓存无法覆盖的新信息，RedParrot 引入三类知识源：

• DSL 配置知识：定义目标 DSL 的语法、参数、字段类型和操作符约束。例如字符串字段中，“等于”应映射为精确匹配，“包含”应映射为模糊匹配。

• 列值知识：负责将自然语言中的实体值映射到数据库中的标准枚举值。例如将“竞价广告”“auction ads”等表达统一归一到标准业务枚举。

• 企业领域知识：维护业务专有术语、缩写和指标解释。例如识别 DGMV、GMV、SOV 等业务词，并映射到真实表字段或指标口径。

对于紧凑的 DSL 配置知识，系统可以直接注入 prompt；对于规模较大的列值知识和领域知识，RedParrot 使用 BM25 与向量检索结合的混合检索，并通过 RRF 融合排序结果，从词面匹配和语义匹配两个维度召回最相关知识。

3.4 DSL 改写与双链路兜底

在线阶段，RedParrot 会先用实体无关编码器检索相似的查询骨架和历史 DSL，再结合多源知识构造结构化 prompt，由 LLM 完成最终 DSL 改写。由于相似 DSL 已经提供了表、维度、指标和过滤条件的参考，模型不需要从零推理完整结构，只需围绕当前查询做少量差异化修改。

在生产环境中，RedParrot 采用短链路和长链路并存的双路径架构。当缓存命中置信度足够高时，系统走短链路快速生成；当遇到新型查询或相似度低于阈值时，系统自动回退到长链路，以保证复杂场景下的结果质量。回退后的高质量查询-DSL 对还可以反哺缓存，持续提升后续命中率。

4.1 实验设置

论文在小红书真实业务数据和开放基准上进行了系统评估。企业数据集覆盖 RED-commerce、RED-community 和 RED-trading 三个核心业务域，并构造了 095 与 0916 两个版本，共六组实验设置，用于验证框架在真实业务分布下的效果。

同时，为了验证方法的泛化能力，论文将 Text-to-SQL 领域的 Spider 和 BIRD 数据集改造为 Spider-DSL 与 BIRD-DSL。该过程将原始 query-SQL 对转换为 query-DSL 对，并进一步生成 Simple、Moderate、Challenging 三类相似查询，用于模拟历史模板与新查询之间的结构复用关系。

评估指标包括执行准确率 ACC、表选择准确率 TB、维度准确率 DM、指标准确率 MS、过滤条件准确率 FT，以及衡量在线体验的 P90 延迟。

4.2 低延迟与高准确率同时提升

在企业数据集上，RedParrot 相比长链路方案显著降低延迟。长链路方法的 P90 延迟普遍超过 20 秒，在 RED-community-0916 上平均 P90 达到 29.5 秒；而 RedParrot 通过短链路生成，将 -095 和 -0916 两类数据集上的平均 P90 分别降低 16.4 秒和 21.3 秒。

更关键的是，延迟下降并没有牺牲准确率。相比主长链路基线，RedParrot 在执行准确率上平均提升 8.26 个百分点；在表选择准确率上平均达到 85.99%，比基线高出 21.59 个百分点。这说明历史 DSL 模板不仅能减少推理步骤，也能帮助系统更稳定地定位正确宽表和配置 DSL 结构。

从组件维度看，RedParrot 在维度、指标和过滤条件生成上的平均准确率分别提升 15.48、11.65 和 5.14 个百分点。通过复用历史结构，模型可以在一次生成中整体配置 DSL，而不必像长链路那样逐步生成并承担误差传递。

4.3 开放基准上的泛化能力

在 Spider-DSL 和 BIRD-DSL 上，RedParrot 同样展现出较强泛化能力。Spider-DSL 整体准确率从 ICL 基线的 47.9% 提升到 77.8%，提升 29.9 个百分点；BIRD-DSL 整体准确率从 25.8% 提升到 65.5%，提升 39.7 个百分点。

BIRD-DSL 难度更高，涉及更复杂的 schema 和查询结构，RedParrot 在该数据集上的收益更明显，说明查询骨架缓存不仅适用于小红书内部数据，也可以迁移到更通用的 NL-to-DSL 场景。

4.4 消融实验与缓存更新

消融实验表明，RedParrot 的三个核心模块各自承担了关键作用。移除实体无关编码器后，RED-commerce-0916 和 RED-community-0916 的执行准确率分别下降 5.90 和 8.20 个百分点；移除知识检索后，在较大数据集上准确率同样明显下降，说明领域知识对处理新实体和新字段至关重要；移除缓存短链路后，运行时间至少增长 3 倍。

在缓存更新方面，论文比较了全量重建和增量更新两种策略。全量重建可以保证一致性，但随着历史数据增长，成本会迅速上升。RedParrot 的增量更新策略只将高置信重复模式或结构新颖的查询纳入缓存，在保持覆盖能力的同时显著降低计算开销。实验显示，增量更新平均带来 3.7x 加速，在 RED-commerce 场景中最高达到 5.13x。

4.5 工程部署价值

从工程架构看，RED PARROT 采用离线到在线的完整闭环。离线侧负责构建高质量查询模板，进行聚类、连通图筛选和实体无关模型训练，并将代表性骨架存入 Milvus 向量库；在线侧通过工作流引擎编排短链路与长链路，支持异步监控、自动回退和缓存持续演进。这种设计让平台可以在不放弃长链路可靠性的前提下，将大量高频查询交给短链路处理。对于业务用户而言，直接收益是等待时间显著缩短；对于平台系统而言，收益是 token 成本降低、LLM 调用次数减少、错误传播链路缩短，并且历史成功经验可以沉淀为可复用资产。

本文面向企业级自然语言商业分析场景，提出了基于查询语义缓存的 NL-to-DSL 加速框架 RED PARROT。框架通过查询骨架缓存、实体无关表示学习和多源异构 RAG，将传统长链路 LLM 工作流压缩为更高效的短链路生成，在小红书真实业务数据上实现平均 3.6x 加速和 8.26% 准确率提升，并在开放基准上取得显著泛化收益。

我们是小红书企业智能部，正在建设面向全公司的 Enterprise Agentic Cowork Workspace，目标是让 AI Agent 成为每个员工日常工作的协作者，推动小红书从软件协作组织升级为 AI Native 组织。

Agent Harness 工程师

岗位职责

1. 建设企业级 Agent Harness / Agent Runtime

2. 建设 Agent Serverless 基础设施

3. 建设 Multi-Agent 通信与协作机制

4. 参与开源 Agent 框架研究与改造

岗位要求

1. 计算机相关专业，本科及以上学历，具备扎实的计算机系统基础。

2. 熟悉至少一种主流后端语言，如 TypeScript / Node.js、Python、Go、Java、Rust 等。

3. 具备较强的系统工程能力，理解服务治理、任务调度、权限系统、可观测性、分布式系统等基础能力。

4. 对 LLM Agent、Tool Calling、MCP、Agent Runtime、Coding Agent、Multi-Agent 等方向有深入兴趣或实践经验。

5. 具备优秀的问题抽象能力，能够把复杂业务问题沉淀为平台化、框架化、基础设施化能力。

6. 有较强的 ownership，愿意面对新问题、定义新边界，而不是只实现明确需求。

投递链接：小红书招聘

Context Engineering 工程师

岗位职责

1. 解决 Single Source of Truth 问题

2. 建设统一 Context 表征体系

3. 优化 Context 检索效率、成本和准确性

4. 建设 Context 安全和权限治理能力

岗位要求

1. 计算机相关专业，本科及以上学历，具备扎实的数据结构、数据库、搜索、分布式系统或机器学习基础。

2. 熟悉至少一种主流工程语言，如 Python、Go、Java、TypeScript、Scala 等。

3. 理解 LLM、RAG、Embedding、向量检索、重排序、知识图谱、语义搜索等基本原理。

4. 对企业知识管理、指标治理、数据治理、Ontology、Semantic Layer、AI Knowledge Infrastructure 有浓厚兴趣。

5. 具备复杂系统抽象能力，能够把碎片化业务知识建模成可维护、可扩展的系统。

6. 重视正确性、安全性和可解释性，不满足于“看起来能回答”，而是追求“答得对、说得清、可追溯”。

投递链接：小红书招聘