在构建检索增强生成（RAG）系统时，工程师常常面临一个棘手的架构选择：是将检索、排序、重排序拆分为多个独立服务，还是在一个单体引擎中硬编码所有逻辑。前者带来了服务间通信的延迟与数据格式转换的复杂性，后者则牺牲了迭代效率与业务可配置性。ShapedQL 的出现提供了一条中间路径 —— 它将多阶段排序流水线抽象为声明式 SQL 语句，使开发者能够以查询关系型数据库的熟悉方式编排 RAG 检索与排序逻辑。
从分离式架构到统一查询层
传统 RAG 系统的检索链路通常由三到四个独立组件构成。第一层是向量检索引擎，负责从 embedding 空间中召回候选文档；第二层是粗排模型，基于简单的相关性特征过滤低质量结果；第三层是精排模型，融合用户行为特征与语义相似度进行深度打分；最后一层是重排序模块，依据多样性、新鲜度或商业规则调整最终输出。每个组件都有独立的配置接口、模型版本管理与监控指标，跨层优化需要协调多个团队的工程资源。
ShapedQL 的核心设计理念是将这四层逻辑统一纳入一个查询编译层。开发者不再需要编写多个 API 调用并手动处理结果合并，而是用一条 SQL 语句声明期望的检索与排序行为。引擎在接收到查询后，会将其编译为优化后的多阶段执行计划，在后台自动完成向量检索、特征交叉、打分与重排序。这种设计将原来需要数周迭代的排序策略调整压缩到分钟级别 —— 只需修改 SQL 中的 ORDER BY 子句或新增一个 REORDER BY 块，引擎即可部署新的排序逻辑。
四阶段流水线引擎架构
ShapedQL 的执行模型由四个核心阶段组成，每个阶段对应 SQL 语句中的一个语义块。在检索阶段，系统支持混合检索模式，允许同时从语义索引与关键词索引中拉取候选集。语义检索使用预训练的 embedding 模型将查询文本映射到高维向量空间，通过近似最近邻搜索返回向量相似度最高的结果；关键词检索则基于倒排索引匹配查询词在文档中的出现频率。两种检索结果在合并时会依据配置的权重进行线性叠加，形成初始候选列表。
过滤阶段负责应用业务规则与硬约束。这一阶段对应 SQL 的 WHERE 子句，可以排除特定类别的内容、过滤未通过审核的文档、或基于用户画像实现千人千面的内容筛选。与传统过滤逻辑不同的是，ShapedQL 的过滤条件支持动态参数注入 —— 用户的历史行为、会话状态或实时信号都可以作为过滤表达式的变量传入。这种设计使得同一查询模板能够适配不同的业务场景而无需重复部署。
评分阶段是排序效果的核心所在。ShapedQL 在这一阶段集成了多种机器学习模型，包括基于 BERT 的语义匹配模型、用户行为预测模型（如点击率、转化率预估）以及自定义的价值函数。评分表达式写在 ORDER BY 子句中，支持多模型分数的加权求和或更复杂的特征交叉运算。引擎会在查询编译时将表达式展开为计算图，针对每个候选文档并行执行模型推理，确保在保持评分深度的同时不显著增加端到端延迟。
重排序阶段对应 SQL 的 REORDER BY 子句，专门用于后处理优化。常见的应用场景包括：基于类别多样性的结果去重、基于时间衰减的新鲜度加权、基于探索 - 利用策略的随机扰动，以及基于业务优先级的强制置顶规则。这一阶段的输出即为最终返回给上层应用的检索结果，整个流水线的端到端延迟被控制在 50 毫秒以内。
用户上下文作为一等公民
传统检索系统通常将用户信息视为查询的附属参数，在检索阶段仅用于简单的画像过滤。ShapedQL 的架构则将用户上下文提升为第一类输入，与查询文本、文档内容并列为核心检索维度。在 Intelligence Layer 中，引擎维护了用户 - 物品关系图谱，实时聚合用户的历史交互行为、偏好标签与当前会话状态。这些信号在评分阶段与文档特征进行交叉计算，使得排序结果能够反映用户个性化的兴趣分布。
以「为你推荐」信息流场景为例，一个典型的 ShapedQL 查询会同时调用 trending ()、personalize () 与 previously_watched () 三个函数。前者拉取全局热门内容，后者基于当前用户 ID 注入个性化信号，第三个函数则用于排除用户已消费的内容。三者的输出在 FILTER 阶段合并后，进入 SCORE 阶段由 watch_rate_model 与 share_rate_model 两个行为预测模型打分，最后通过 REORDER BY 中的 diversity () 与 exploration () 函数确保推荐结果的丰富度与新颖度。整个查询逻辑不到二十行 SQL，却完成了传统架构中需要多个服务协同才能实现的复杂排序策略。
工程实践参数与监控要点
在生产环境中部署 ShapedQL 时，有几个关键参数需要根据实际流量规模与延迟要求进行调优。检索阶段的候选集大小（通常称为 recall size）决定了后续排序阶段的计算开销 —— 过大会导致评分延迟上升，过小则可能遗漏高质量候选。对于一般规模的 RAG 应用，建议初始设置为 200 到 500 之间，通过 A/B 测试观察命中率曲线后逐步收敛到最优值。过滤阶段的条件表达式应当尽可能简化，避免在单次查询中引入过多嵌套判断，否则会增加查询编译时间并降低缓存命中率。
评分模型的批处理大小是影响吞吐量的关键变量。ShapedQL 支持将多个候选文档批量送入模型推理，批大小的选择需要在延迟与吞吐量之间取得平衡。在 50 毫秒的延迟约束下，建议使用动态批处理策略：当候选数量较少时单件推理以保证低延迟，候选数量较多时自动切换为批处理模式以提升吞吐。重排序阶段的 diversity strength 与 exploration strength 参数控制了排序结果的随机性程度，对于新用户或新内容占比较高的场景，建议将 diversity 参数设置在 0.15 到 0.25 之间，以避免过滤气泡效应。
监控层面需要关注的核心指标包括：各阶段的平均处理时间（检索、过滤、评分、重排序的分解延迟）、端到端 P99 延迟、候选文档在阶段间的流失率、模型打分的分布稳定性，以及 SQL 查询的编译缓存命中率。当发现某一阶段的延迟异常升高时，通常可以通过检查该阶段的计算密集度或 I/O 等待来定位瓶颈。
与现有 RAG 基础设施的集成
ShapedQL 并非要从零构建一套全新的检索栈，而是设计为与现有数据基础设施协同工作。在 Data Layer，引擎提供了超过 30 种原生连接器，覆盖主流数据仓库（Snowflake、BigQuery、Redshift）、流媒体平台（Kafka、Kinesis）以及业务数据库（PostgreSQL、MongoDB）。数据可以通过批量同步或实时流式两种方式接入，引擎会在内部将其转换为统一的 schema 视图供上层查询使用。这种设计使得企业无需迁移现有数据资产，即可在现有数据之上叠加 ShapedQL 的排序能力。
对于已经部署 Elasticsearch 或 Algolia 的团队，ShapedQL 提供了渐进式迁移路径。可以将 ShapedQL 作为现有检索引擎的排序增强层，原有的索引与查询逻辑保持不变，仅在 ShapedQL 侧增加重排序与个性化调优逻辑。这种混合部署模式降低了迁移风险，使得团队可以在小流量场景中验证 ShapedQL 的效果后再决定是否完全切换。
资料来源：Shaped 官方网站（https://shaped.ai/）