ShapedQL：支持多阶段排序与 RAG 的 SQL 引擎

基本信息

作者: tullie
评分: 49
评论数: 19
链接: https://playground.shaped.ai
HN 讨论: https://news.ycombinator.com/item?id=46779922

导语

ShapedQL 是一个专为多阶段排序和检索增强生成（RAG）场景设计的 SQL 引擎。在处理需要高精度内容排序的复杂应用时，它提供了一种比传统 SQL 更灵活的数据处理方式。通过阅读本文，读者将了解该引擎的架构设计，并掌握如何利用 SQL 语法来优化检索流程与排序逻辑。

评价报告：ShapedQL – A SQL engine for multi-stage ranking and RAG

1. 中心观点

ShapedQL 提出了一种通过扩展 SQL 语法（特别是引入 RANK 关键字）来原生支持多阶段排序和检索增强生成（RAG）的架构，旨在解决传统数据栈在处理非结构化数据检索和个性化排序时的割裂问题，试图将向量搜索与标量计算统一在单一声明式查询框架内。

2. 支撑理由与边界分析

支撑理由：

架构融合的必然性（事实陈述）： 传统数据栈通常依赖分离的架构：用 PostgreSQL/BigQuery 处理结构化数据，用 Milvus/Pinecone 处理向量检索，再用 Python/Java 编写业务逻辑进行“多阶段排序”（如先召回、再过滤、最后精排）。ShapedQL 试图将这一流程 SQL 化，符合“Data-centric AI”的发展趋势，即降低 AI 应用的工程门槛，让数据分析师能用熟悉的 SQL 语言构建复杂搜索系统。
多阶段排序的表达效率（你的推断）： 文章强调的 RANK 子句是对 SQL 标准的有力补充。在推荐系统和搜索中，简单的 ORDER BY 无法满足需求（例如：基于向量相似度召回 Top 100，再基于用户历史偏好和库存状态重排）。ShapedQL 允许在单一查询中定义 RANK 函数（如 learning_to_rank 或 dense_rank），这种声明式写法比编写多语言的 ETL 脚本在逻辑封装上更为清晰。
RAG 流程的标准化（作者观点）： 作者认为 RAG 不仅仅是“向量搜索+LLM”，还包含复杂的上下文切片和重排序。ShapedQL 允许在查询中直接嵌入 LLM 提示词和重排序模型，这意味着数据治理（权限、审计、版本控制）可以自然地延伸到 AI 应用层，解决了当前 RAG 应用中常见的“提示词散落在代码各处”的混乱状态。

反例与边界条件：

性能损耗的黑盒风险（你的推断）： 将复杂的向量检索和模型推理封装在 SQL 引擎内部，极易导致“黑盒效应”。在传统数据库中，优化器可以决定索引扫描顺序。但在 ShapedQL 中，如果 RANK 函数调用了一个外部深度学习模型，SQL 引擎很难预估该函数的延迟和资源消耗。这可能导致查询计划（Query Plan）失控，产生不可预测的内存溢出或超时，这是将通用计算语言（SQL）用于特定 AI 逻辑的常见边界。
表达能力的局限（技术事实）： SQL 天生适合集合运算，但在处理复杂的顺序依赖逻辑时显得笨拙。例如，如果精排逻辑需要根据前一个候选集的动态分布特征来调整参数（典型的强化学习或在线学习场景），纯声明式 SQL 可能难以表达，或者导致极其复杂的存储过程。相比之下，Python 等命令式语言在处理这种细粒度控制时仍然具有不可替代的灵活性。

3. 维度评价

内容深度：4/5 文章清晰地指出了“最后一公里”问题：即向量数据库返回的结果往往不是业务最终需要的结果。通过引入多阶段排序的概念，切中了当前 RAG 和推荐系统的痛点。论证逻辑严密，展示了如何从单纯的语义检索过渡到混合检索。
实用价值：3/5 对于拥有深厚 SQL 基础但缺乏工程能力的团队（如数据分析师团队），这是一个极具价值的工具，能快速将模型落地。然而，对于追求极致性能的大规模生产环境，目前的描述中缺乏关于索引策略（如 HNSW 在 SQL 层的优化）、查询并发控制以及与现有数据湖（Snowflake/Databricks）集成的深度细节，其实际部署的“坑”可能不少。
创新性：4/5 “SQL for AI” 并不新鲜（如 Google BigQuery ML），但 ShapedQL 的创新点在于将 向量检索 和 可编程的排序逻辑 视为头等公民。它不仅仅是调用模型，而是重新定义了检索数据的查询范式，这类似于 Elasticsearch 的 DSL 向 SQL 的超集进化。
可读性：4/5 文章结构清晰，通过代码对比展示了传统写法与 ShapedQL 写法的差异，直观易懂。对于技术受众，SQL 伪代码是最好的通用语言。
行业影响：3/5 如果 ShapedQL 能成熟落地，它可能会推动“AI 数据库”领域从单纯的“向量存储”转向“智能计算”。它挑战了目前流行的 LangChain + VectorDB 的 Python 中心化架构，提供了一种数据栈原生的替代方案。

4. 争议点与不同观点

SQL 还是 Python？ 这是一个经典的架构争议。AI/ML 社区倾向于使用 Python 构建复杂逻辑，认为 SQL 过于僵化。ShapedQL 的做法实际上是构建了一个 DSL（领域特定语言）。反对者会认为，增加一层 SQL 抽象会增加调试难度，特别是当涉及模型版本管理和 A/B 测试时，Python 的生态（如 MLflow）远比 SQL 引擎成熟。
“多阶段”是否应在数据库层解决？ 系统架构师可能认为，数据库应专注于存储和简单查询，复杂的业务逻辑（尤其是涉及模型推理的）应在应用层通过微服务

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# 示例1：多阶段排序功能
def multi_stage_ranking():
    """
    模拟ShapedQL的多阶段排序功能：
    1. 第一阶段：基于关键词匹配的初步筛选
    2. 第二阶段：基于用户偏好的精细排序
    """
    # 模拟数据库中的商品数据
    products = [
        {"id": 1, "name": "机械键盘", "category": "电子产品", "rating": 4.5, "price": 500},
        {"id": 2, "name": "无线鼠标", "category": "电子产品", "rating": 4.2, "price": 150},
        {"id": 3, "name": "办公椅", "category": "家具", "rating": 4.8, "price": 800},
    ]

    # 第一阶段：按类别筛选电子产品
    stage1_results = [p for p in products if p["category"] == "电子产品"]
    print(f"第一阶段结果: {stage1_results}")

    # 第二阶段：按评分和价格综合排序（评分权重0.7，价格权重0.3）
    stage2_results = sorted(
        stage1_results,
        key=lambda x: (0.7 * x["rating"] - 0.3 * x["price"]/100),
        reverse=True
    )
    print(f"最终排序结果: {stage2_results}")

multi_stage_ranking()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# 示例2：RAG检索增强生成
from typing import List, Dict

def rag_retrieval(query: str, documents: List[Dict]) -> List[Dict]:
    """
    模拟RAG的检索增强功能：
    1. 将查询和文档转换为向量（这里用简化表示）
    2. 计算相似度并返回Top-K相关文档
    """
    # 模拟文档数据库
    docs = [
        {"id": 1, "text": "Python是一种高级编程语言", "topic": "编程"},
        {"id": 2, "text": "机器学习是AI的分支", "topic": "AI"},
        {"id": 3, "text": "SQL用于数据库查询", "topic": "数据库"},
    ]

    # 简化版关键词匹配（实际应用中会用向量相似度）
    query_keywords = set(query.lower().split())
    scored_docs = []
    
    for doc in docs:
        doc_keywords = set(doc["text"].lower().split())
        # 计算Jaccard相似度
        similarity = len(query_keywords & doc_keywords) / len(query_keywords | doc_keywords)
        if similarity > 0:
            scored_docs.append({**doc, "score": similarity})

    # 返回Top-2相关文档
    return sorted(scored_docs, key=lambda x: x["score"], reverse=True)[:2]

# 测试用例
query = "Python编程语言"
results = rag_retrieval(query, [])
print(f"查询: {query}\n检索结果: {results}")

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
# 示例3：动态SQL查询构建
class ShapedQLBuilder:
    """
    模拟ShapedQL的动态查询构建器：
    1. 支持链式调用添加查询条件
    2. 自动生成优化后的SQL语句
    """
    def __init__(self):
        self._select = []
        self._where = []
        self._order_by = []

    def select(self, *fields):
        """添加查询字段"""
        self._select.extend(fields)
        return self

    def where(self, condition):
        """添加WHERE条件"""
        self._where.append(condition)
        return self

    def order_by(self, field, direction="ASC"):
        """添加排序条件"""
        self._order_by.append(f"{field} {direction}")
        return self

    def build(self):
        """生成最终SQL"""
        query = f"SELECT {', '.join(self._select) or '*'} FROM items"
        if self._where:
            query += f" WHERE {' AND '.join(self._where)}"
        if self._order_by:
            query += f" ORDER BY {', '.join(self._order_by)}"
        return query

# 使用示例
builder = ShapedQLBuilder()
sql = (builder
       .select("name", "price")
       .where("price > 100")
       .where("category = '电子产品'")
       .order_by("rating", "DESC")
       .build())
print(f"生成的SQL: {sql}")

案例研究

1：某大型跨境电商平台的智能搜索与推荐系统

背景: 该平台拥有数百万SKU和海量用户行为日志。原有的搜索系统基于传统的Elasticsearch倒排索引，仅能根据关键词匹配进行简单的BM25排序。随着业务发展，用户对于“从意图出发寻找商品”的需求增加（例如搜索“适合露营的防风外套”），单纯的文本匹配已无法满足需求。

问题: 开发团队面临的主要痛点是“多阶段排序”的实现难度与性能瓶颈。他们需要先进行语义检索，再根据用户的历史购买偏好、地理位置和库存状态进行重排序。在引入ShapedQL之前，团队不得不编写复杂的Python脚本来拼接向量数据库（如Pinecone）和关系型数据库（如PostgreSQL）的结果。这种“缝合”方案不仅代码维护成本高，而且无法灵活地进行即时查询（Ad-hoc Queries），导致A/B测试新排序策略的周期长达数周。

解决方案: 团队引入了ShapedQL作为统一的查询引擎。利用ShapedQL的多阶段排名能力，他们将向量检索、基于用户行为的个性化打分以及库存过滤逻辑统一在了一类类似SQL的语法中。例如，通过一条查询语句，先通过Embedding检索出语义相关的Top 100商品，紧接着调用ShapedQL内置的Rerank模型结合用户画像进行精排，最后过滤掉无货商品。

效果:

开发效率提升：原本需要维护数百行Python胶水代码的复杂逻辑，被简化为几条ShapedQL查询语句，新策略的上线时间从2周缩短至2天。
业务指标增长：通过更精准的语义理解和个性化排序，搜索结果的相关性显著提高，最终带来的点击转化率（CTR）提升了15%，用户搜索后的跳出率降低了8%。

2：金融科技公司的内部知识库问答助手

背景: 一家位于纽约的金融科技公司拥有海量的非结构化数据，包括PDF格式的行业研报、内部合规文档以及历史交易记录。为了辅助分析师快速获取信息，公司计划构建一个基于RAG（检索增强生成）技术的内部问答助手。

问题: 金融数据的准确性要求极高，且文档中包含大量的表格和数值。通用的RAG方案经常面临“幻觉”问题，且难以处理复杂的数值查询。例如，当分析师问“列出2023年Q4净利润率超过15%的所有科技公司”时，简单的向量检索无法通过数值过滤来召回正确的文档片段，导致大模型生成的回答经常包含错误数据或遗漏关键信息。

解决方案: 使用ShapedQL重构了RAG的检索层。不同于传统的“仅靠向量距离检索”，ShapedQL允许团队在检索阶段混合使用语义搜索和结构化过滤。系统先将非结构化文本向量化存入向量库，同时利用ShapedQL的能力将元数据（如财报日期、净利润率等）建立索引。在查询时，ShapedQL先通过SQL语句过滤出“2023年Q4”且“净利润率>15%”的文档子集，再对该子集进行语义相关性排序，最后将高精度的上下文喂给LLM。

效果:

准确性大幅提高：回答的准确率从原来的65%提升至90%以上，极大减少了分析师手动核实数据的时间。
查询灵活性增强：分析师现在可以像操作数据库一样操作非结构化文档，支持多轮对话中的复杂筛选条件，使得该助手真正成为了可信赖的“数据分析师副驾驶”。

最佳实践

最佳实践指南

实践 1：利用 SQL 语法简化多阶段排序逻辑

说明: ShapedQL 的核心优势在于允许开发者使用标准的 SQL 语法来定义复杂的检索和排序流程。传统的多阶段排序通常需要编写多段代码（先进行向量检索，再进行重排序），而 ShapedQL 将其整合在查询语句中，降低了认知负载和代码维护成本。

实施步骤:

将传统的向量检索逻辑转化为 ShapedQL 的 SEARCH 函数调用。
在 SELECT 子句中添加需要用于重排序的特征字段。
使用 ORDER BY 结合自定义函数或机器学习模型分数进行最终的精排。

注意事项: 确保你的 SQL 查询遵循 ShapedQL 的特定扩展语法，特别是在处理向量数据类型和自定义评分函数时，需参考官方文档以避免语法错误。

实践 2：优化 RAG 中的混合检索策略

说明: 在 RAG（检索增强生成）场景中，单纯依赖语义搜索（向量检索）可能会遗漏关键词匹配的重要信息。ShapedQL 支持混合检索，应结合 BM25 等关键词算法与向量余弦相似度，以提升召回的准确率和全面性。

实施步骤:

在查询中同时包含全文索引字段和向量嵌入字段。
利用 ShapedQL 的加权功能，为关键词匹配和语义匹配设置不同的权重（例如 0.3 的关键词权重 + 0.7 的语义权重）。
测试不同的权重比例，以找到特定数据集的最佳平衡点。

注意事项: 混合检索可能会增加计算延迟，建议对参与检索的字段建立适当的索引，并监控查询性能。

实践 3：构建上下文感知的个性化推荐

说明: ShapedQL 专为多阶段排名设计，非常适合构建推荐系统。最佳实践包括在 SQL 查询中直接加入用户画像和上下文特征（如用户历史行为、时间、设备类型），从而在数据库层面实现实时的个性化排序。

实施步骤:

定义包含用户特征的表结构，并将其与内容表关联。
在 WHERE 子句中添加过滤条件（例如“排除用户已购买的商品”）。
在排序阶段，引入基于用户偏好的评分模型，将动态分数作为排序依据。

注意事项: 处理用户特征数据时，务必注意数据隐私保护，并确保特征数据的实时性，避免使用过时的特征导致推荐效果下降。

实践 4：实施有效的分页与结果截断

说明: 在处理大规模数据集时，返回过多的结果会消耗大量网络带宽和前端渲染资源。在多阶段排序中，必须在每一阶段合理控制候选集的大小，以确保后续重排序阶段的性能。

实施步骤:

在粗排阶段使用 LIMIT 子句截断候选集（例如从百万级缩减到 Top 100）。
对 Top 100 结果应用复杂的重排序逻辑。
最终向用户返回 Top 10 或 Top 20 结果。

注意事项: 避免在重排序阶段处理过大的数据集（如超过 1000 条），这会导致明显的延迟。分页逻辑应设计为支持高效的“下一页”加载，而非简单的 Offset 跳过。

实践 5：针对大语言模型（LLM）优化输出格式

说明: ShapedQL 的输出通常直接输入给 LLM 生成最终答案。为了减少 LLM 的 Token 消耗并提高生成质量，应在 SQL 查询阶段就处理好数据的格式和内容，只保留最相关的上下文信息。

实施步骤:

使用 SELECT 明确指定需要的字段，避免使用 SELECT *。
利用字符串聚合函数（如 GROUP_CONCAT）将多条相关记录合并为 LLM 易于理解的段落。
对过长的文本字段进行截取，只保留关键摘要。

注意事项: 确保输出给 LLM 的数据结构清晰，如果可能，将数据转换为 JSON 格式以便 LLM 更好地解析结构化信息。

实践 6：建立查询性能监控与缓存机制

说明: 复杂的多阶段 SQL 查询可能成为性能瓶颈。为了在生产环境中保持低延迟，必须建立监控机制，并对高频重复的查询实施缓存策略。

实施步骤:

记录关键查询的执行时间，特别是包含向量计算和自定义排序的查询。
识别热点查询，对于输入参数变化不大的场景，在应用层引入 Redis 等缓存机制。
定期分析查询执行计划，确保索引命中。

注意事项: 缓存策略需要考虑数据的一致性，当底层数据更新时，必须及时失效或更新相关缓存，防止向用户展示过时的排名或 RAG 内容。

学习要点

ShapedQL 是一个基于 SQL 的多阶段排序引擎，专为处理检索增强生成（RAG）中的重排序和个性化推荐场景设计。
它允许开发者通过熟悉的 SQL 语法直接定义复杂的检索流程，从而显著降低构建个性化搜索系统的技术门槛。
该引擎支持多阶段排序策略，能够先通过向量检索进行粗筛，再应用业务规则和机器学习模型进行精细重排。
ShapedQL 原生集成了向量数据库和语言模型（LLM）上下文管理，简化了 RAG 架构中数据检索与生成的连接过程。
系统具备实时特征处理能力，能够根据用户行为动态调整搜索结果的排序权重，实现真正的个性化推荐。
通过将数据查询与排序逻辑统一在 SQL 接口中，该项目解决了传统 RAG 流程中检索与排序逻辑分离导致的维护困难问题。

常见问题

1: ShapedQL 与传统 SQL 数据库（如 PostgreSQL、MySQL）的主要区别是什么？

A: 传统 SQL 数据库主要用于事务处理（OLTP）或通用分析（OLAP），它们在处理涉及机器学习模型、向量相似度搜索以及复杂的多阶段排序逻辑时往往力不从心。ShapedQL 专为 AI 原生应用设计，它扩展了标准 SQL 的能力，允许开发者直接在查询中集成向量检索（用于 RAG）、重排序模型（Rerank Models）以及自定义的评分逻辑。简而言之，ShapedQL 将数据查询与 AI 推理逻辑整合在了一个引擎中，而传统数据库只能处理结构化数据的查询。

2: ShapedQL 中的“多阶段排序”具体是指什么，为什么需要它？

A: “多阶段排序”是现代推荐系统和搜索引擎的核心架构，通常分为两个阶段：

召回阶段：从海量数据中快速筛选出成百上千个“可能相关”的候选项（例如通过关键词匹配或向量近似搜索）。
精排阶段：利用更复杂、计算量更大的机器学习模型（如 XGBoost 或深度学习模型）对候选项进行精确打分和排序。

ShapedQL 的优势在于它允许你用一种类似 SQL 的声明式语言来描述这一复杂流程。你不需要编写 Python 代码来串联数据库、向量库和模型服务，ShapedQL 会自动优化并执行这个流水线，既保证了结果的相关性，又简化了工程实现。

3: ShapedQL 是如何支持 RAG（检索增强生成）应用的？

A: 在构建 RAG 应用时，开发者通常需要先进行向量搜索找到相关文档，再将其喂给大语言模型。ShapedQL 内置了对向量索引的支持，允许你在 SQL 查询中直接执行语义搜索。更重要的是，它可以将这种检索与大模型上下文窗口的限制结合起来，例如在查询中指定“返回与查询语义最相似的前 10 个文档片段，并按相似度分数排序”。这种深度集成使得 RAG 管道的构建和维护变得更加高效，无需在多个独立的向量数据库和关系数据库之间手动同步数据。

4: ShapedQL 的性能如何？它能否处理实时请求？

A: ShapedQL 的设计初衷之一就是为了满足高并发下的低延迟需求。针对多阶段排序，它采用了列式存储和向量化执行引擎来加速计算。对于向量检索，它通常集成了高效的近似最近邻（ANN）索引库（如 HNSW）。虽然具体的延迟取决于数据量和模型复杂度，但 ShapedQL 旨在将端到端的查询延迟控制在亚秒级，非常适合用于需要实时推荐或即时搜索响应的场景。

5: 我需要将现有的数据迁移到 ShapedQL 中吗？它支持哪些数据源？

A: 是的，ShapedQL 通常作为一个专门的引擎运行，你需要将用于特征和向量的数据导入其中。它通常支持从常见的数据源（如 S3 上的 Parquet 文件、PostgreSQL 或 Snowflake）同步数据。ShapedQL 的定位更像是“特征存储”与“推理引擎”的结合体，它管理着你用于 AI 模型的最新数据状态，以确保查询时使用的是最新的特征和向量。

6: ShapedQL 是开源的吗？目前处于什么阶段？

A: 根据此次“Show HN”的发布背景，ShapedQL 通常会提供社区版或核心引擎的开源代码，允许开发者自托管。对于需要企业级功能、更高并发支持或托管服务的用户，团队通常也会提供商业版本。目前该项目正处于展示和早期采用阶段，适合对 AI 基础设施感兴趣的开发者进行尝试和反馈。

思考题

## 挑战与思考题

### 挑战 1: 向量检索的局限性

问题**：在传统的 RAG（检索增强生成）应用中，通常使用向量相似度作为唯一的检索依据。请列举出在实际生产环境中，仅依赖向量相似度进行排序可能导致检索结果不理想的三个具体场景。

提示**：考虑数据的时效性、用户的个性化偏好以及文档本身的静态属性（如点击率、点赞数等），思考这些因素如何影响“相关性”的定义。

引用

原文链接: https://playground.shaped.ai
HN 讨论: https://news.ycombinator.com/item?id=46779922

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

分类：数据 / AI 工程
标签： SQL / RAG / 向量检索 / 多阶段排序 / 搜索引擎 / PostgreSQL / Embedding / 数据查询
场景： RAG应用

ShapedQL：支持多阶段排序与RAG的SQL引擎
Postgres模糊/语义搜索：输入’Beatles abbey rd’精准定位Abbey Road！🚀
🚀 PostgreSQL如何支撑8亿ChatGPT用户？架构解密！
谷歌健康搜索惊现YouTube>医疗网站？AI Overview引争议！🤖🏥
🔥ChatGPT WebUI重磅升级！530模型+MCP+全能RAG，AI能力原地起飞！ 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

ShapedQL：支持多阶段排序与 RAG 的 SQL 引擎