在现代 RAG 系统的工程实践中，混合检索与多阶段排名一直是基础设施的痛点。传统方案要求团队维护向量数据库、搜索引擎、特征存储等多套系统，并通过数千行 Python 代码粘合业务逻辑、过滤规则和重排序逻辑。这种「弗兰肯斯坦式」的架构不仅迭代缓慢，更难以追溯某个 item 为何排在第一位的原因。ShapedQL 作为一种声明式 SQL 方言，其核心创新在于将整个检索与排名堆栈压缩为单一查询语句。本文将聚焦其实现机制，剖析 SQL 语法元素如何映射为底层的 RAG 排名操作，特别是 Reciprocal Rank Fusion（RRF）和 learned sparse scoring 的表达方式。
SQL 算子到排名管线的映射模型
ShapedQL 的查询语法遵循经典 SQL 结构，但每个子句都对应于多阶段排名管线的特定环节。从执行语义来看，一条 ShapedQL 查询会经历六个阶段的转换：并行检索、结果合并、过滤、评分、重排序和限流。这种映射关系的精妙之处在于，开发者只需编写熟悉的 SQL 表达式，而引擎会自动将其转换为底层的排名操作配置。
具体而言，FROM 子句中的每个 retriever 函数（如 similarity、text_search）会被翻译为独立的检索执行器，并在引擎内部并行触发。检索结果通过 union 操作合并，并进行去重处理。WHERE 子句使用 DataFusion SQL 语法定义的过滤表达式，会被下推至检索阶段执行，以减少后续处理的候选集规模。ORDER BY 子句中的 score 表达式是整个映射机制的核心，它定义了如何对候选 items 进行评分和排序。REORDER BY 子句则负责最终的 diversity 和 exploration 后处理，确保推荐结果的多样性和新鲜度。
以下是一个典型的混合检索查询示例，展示了这种映射关系：
SELECT *
FROM similarity(embedding_ref='als', limit=50),
text_search(query='$query', mode='lexical', limit=50)
WHERE category = 'electronics' AND price < 200
ORDER BY score(expression='rrf(similarity, text_search, k=60)', input_user_id='$user_id')
LIMIT 20
在这个查询中，FROM 子句定义了两个并行检索器：基于协同过滤的相似性检索和基于关键词的文本搜索。WHERE 子句应用了类目和价格过滤。ORDER BY 子句中的 rrf 表达式指定使用 Reciprocal Rank Fusion 算法融合两个检索器的结果，k 参数设为行业常用的 60 值。整个查询的长度不超过 30 行，而传统实现同等功能可能需要数百行 Python 代码和多个系统间的网络调用。
RRF 作为声明式评分表达式
Reciprocal Rank Fusion 是混合检索领域的标准基线算法，其核心思想是忽略各检索器的原始分数，仅依据排名位置进行融合。RRF 的公式为：对于文档 d，其 RRF 分数等于各检索系统排名倒数的加权和，常数 k（通常设为 60）用于平滑排名差异，防止单一检索器的第一名主导最终结果。在 ShapedQL 中，RRF 并不是作为独立的后处理步骤存在，而是被封装为 score () 函数内的表达式，与其他评分逻辑统一处理。
这种设计带来了几个重要的工程优势。首先，RRF 的超参数（如 k 值）可以在查询中直接调整，无需修改底层配置。其次，RRF 可以与其他评分信号（如 learned sparse scoring）进行线性组合或嵌套调用。再者，引擎会自动处理多个检索器结果的对齐和去重，开发者无需编写复杂的融合逻辑。从实现角度来看，ShapedQL 的查询解析器会将 score 表达式转换为内部的评分算子配置，包括检索器引用、融合权重和常数参数。这些配置在执行阶段被分发给相应的评分模块，最终生成每个候选 item 的综合分数。
值得注意的是，ShapedQL 的 RRF 实现支持动态参数化。例如，k 值可以根据查询类型或用户特征进行调整，以控制不同检索器之间的相对影响力。这种灵活性在传统实现中往往需要修改代码逻辑，而在 ShapedQL 中只需修改查询字符串即可。引擎还支持在 score 表达式中使用变量占位符，使得同一查询模板可以适应不同的运行时上下文。
Learned Sparse Scoring 的表达式化
Learned sparse embedding 是近年来信息检索领域的重要进展，它结合了传统词袋模型的可解释性和稠密向量的语义表达能力。典型实现如 SPLADE 或 E5，通过学习将查询和文档映射到高维稀疏空间，每个维度对应一个词汇表中的词项，激活强度反映该词项的重要程度。在混合检索场景中，learned sparse 检索可以补充稠密向量检索在精确匹配和术语覆盖方面的不足。
ShapedQL 将 learned sparse scoring 纳入统一的 score () 表达式框架中，允许开发者以声明式的方式定义稀疏信号的加权方式。一个典型的表达式可能形如：score (expression='sparse_weighted (sparse_retriever, weight=0.3)', input_user_id='$user_id')。这里，sparse_retriever 是 FROM 子句中定义的稀疏检索器名称，weight 参数控制其在融合评分中的相对重要性。与 RRF 不同，sparse_weighted 表达式会保留稀疏向量的原始分数，并按照指定权重进行线性组合。
更复杂的场景可能需要将 learned sparse 信号与其他评分信号进行深度融合。ShapedQL 支持在单个 score 表达式中嵌套多个操作符，例如：score (expression='linear_combination (rrf (dense_retriever, sparse_retriever), sparse_weighted (sparse_retriever, weight=0.2), weights=[0.7, 0.3])')。这种嵌套表达能力使得复杂的排名策略可以通过组合基本算子来实现，无需引入自定义代码。引擎内部的代价优化器会根据查询结构和数据分布，选择最优的算子求值顺序和并行策略。
从实际效果来看，将 learned sparse scoring 表达为 SQL 评分子句大大降低了实验成本。传统流程中，调整稀疏向量的权重或融合方式需要修改模型配置、重新部署推理服务，可能还涉及在线 AB 测试的流量切换。而在 ShapedQL 中，同一查询模板只需修改表达式参数，即可在数毫秒内生效。这种敏捷性对于快速迭代排名策略、验证业务假设具有重要意义。
与传统实现的对比分析
为了更直观地理解 ShapedQL 的价值，有必要将其与传统实现方案进行对比。假设我们需要构建一个支持混合检索（稠密向量 + 关键词 + learned sparse）和多阶段排名（Reranker + Diversity）的推荐系统。传统方案的技术栈可能包括 Pinecone（向量检索）、Elasticsearch（关键词检索）、Redis（特征缓存）和自研的 Python 排名服务。每个检索器需要独立的 API 调用，结果需要通过网络传输到排名服务进行融合。业务逻辑如过滤规则、重排序策略则嵌入在 Python 代码中，维护成本高昂。
使用 ShapedQL 实现的同等功能，查询代码可能如下：
SELECT video_id, creator_name
FROM similarity(embedding_ref='als', limit=100),
text_search(query='$query', mode='lexical', limit=100),
sparse_retriever(query='$query', limit=100)
WHERE category IN ('tech', 'gaming')
AND previously_watched(user_id='$user_id') = FALSE
ORDER BY score(expression='colbert_rerank(cross_encoder(rrf(similarity, text_search, sparse_retriever)))')
REORDER BY diversity(step_name='diversity_step', diversity_factor=0.3)
LIMIT 30
这条查询声明了三个并行检索器，应用了类目和已观看过滤，使用 cross-encoder 对 RRF 融合结果进行重排序，最后通过 diversity 因子保证结果多样性。所有这些逻辑都包含在单条 SQL 语句中，由 ShapedQL 引擎负责分布式执行和结果聚合。相比传统方案，这种方式的迭代速度提升了一个数量级，同时显著减少了系统间的状态同步开销。
从可观测性角度，ShapedQL 的声明式语法也带来了优势。查询本身就是一个完整的执行计划文档，任何工程师都可以阅读并理解数据的流动方向和排名策略。相比之下，传统实现的业务逻辑散落在多个代码仓库和服务配置中，追溯某个排名决策的来源可能需要跨越多个系统。这种透明性对于排查 ranking 相关问题、进行审计和合规检查都有重要价值。
工程落地的关键参数
在生产环境中使用 ShapedQL 的排名表达式时，有几个参数值得特别关注。首先是检索器的 limit 参数，它决定了每个检索阶段返回的候选数量。设置过低可能导致优质结果被过早过滤，设置过高则会增加后续评分阶段的计算开销。对于典型的召回 - 精排两阶段架构，建议将召回阶段的 limit 设在 50 到 200 之间，精排阶段使用 reranker 时 limit 应控制在 10 到 50 之间。
score () 表达式中的 weight 参数用于控制不同检索器或评分信号之间的相对重要性。这些权重通常需要通过离线实验（如 A/B 测试或回放）来确定初始值，再根据线上指标（如点击率、转化率）进行迭代调优。ShapedQL 支持在表达式中使用运行时参数（如 input_user_id），使得同一查询模板可以适应不同用户群体的个性化需求。需要注意的是，过度细粒度的参数化可能导致查询模板数量爆炸，影响缓存命中率。
REORDER BY 子句中的 diversity_factor 参数控制重排序阶段的多样性权重，值域通常在 0 到 1 之间。较高的值会强制结果在类目、作者或其他维度上更加分散，但可能牺牲部分相关性。在实际应用中，建议将该参数与业务指标联合优化，避免单纯的 diversity 追求导致用户体验下降。ShapedQL 还支持自定义 diversity 策略，通过指定分组字段（如 category_id 或 creator_id）和惩罚函数来实现领域特定的多样性目标。
对于 RRF 表达式，k 常数的选择对融合结果有显著影响。较小的 k 值会放大排名差异，使得排名靠前的结果更具优势；较大的 k 值则会平滑差异，鼓励跨检索器的共识。根据行业实践，k=60 是一个稳健的默认值，但在特定场景下（如检索器数量较多或排名分布差异较大时）可能需要调整。ShapedQL 的查询优化器会在执行计划生成阶段考虑 k 值对结果分布的影响，以优化后续算子的资源分配。
资料来源：ShapedQL 官方文档（docs.shaped.ai），Shaped.ai 官方博客（2026 年 1 月 27 日发布）。