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

基本信息

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

导语

在构建基于大语言模型的应用时，如何高效地从海量数据中检索并精准排序结果，是提升系统质量的关键环节。ShapedQL 是一款专为多阶段排序和 RAG 场景设计的 SQL 引擎，旨在解决传统检索方案在语义匹配与上下文重排方面的局限性。通过阅读本文，读者将了解该工具如何利用熟悉的 SQL 语法来优化检索流程，从而在实际项目中实现更智能、更可控的信息检索体验。

中心观点

该文章提出了一种通过在SQL引擎中内嵌多阶段排序和检索增强生成（RAG）能力的技术路线，旨在解决传统数据库在处理非结构化数据检索与AI应用集成时的“语义鸿沟”问题，试图将AI应用的数据层从“脚本拼凑”推向“声明式查询”的新范式。

支撑理由与边界条件分析

1. 技术架构的收敛性

事实陈述：文章展示了ShapedQL如何将向量搜索、重排序和LLM上下文构建封装为标准的SQL接口。
你的推断：这反映了数据基础设施领域的一种趋势——即“AI工作负载的数据库化”。随着向量数据库的火热，行业正在从“专用数据库”向“具备AI能力的通用数据库”演进。
支撑理由：通过SQL（一种声明式语言）来控制RAG流程，极大地降低了后端工程师构建AI应用的门槛，使得复杂的检索逻辑（如混合检索、倒排融合）可以通过熟悉的查询语法实现，无需编写大量的Python胶水代码。

2. 性能与优化的权衡

事实陈述：ShapedQL强调“多阶段排序”，这通常涉及稠密检索、稀疏检索以及基于Cross-Encoder的重排序。
支撑理由：在SQL引擎内部进行这些操作，相比于在应用层（如Python服务）进行多次数据库往返，理论上减少了网络IO序列化的开销，且更容易利用数据库的查询优化器进行算子下推和并行处理。

3. 边界条件与反例

反例1（灵活性陷阱）：SQL擅长处理集合运算，但在处理高度非结构化、需要复杂逻辑控制的RAG流程时（例如：根据检索结果动态决定下一步Prompt策略，或者涉及多Agent协作），SQL的声明式特性可能会变成一种束缚。强行将所有逻辑塞入SQL可能导致“存储过程”式的维护噩梦。
反例2（实时性挑战）：虽然文章未详述底层实现，但若该引擎依赖传统的批处理架构或无法有效利用GPU加速向量计算，其在高并发、低延迟的实时搜索场景下，可能不如专门优化的向量搜索引擎（如Milvus或Pinecone）表现优异。

维度评价

1. 内容深度：严谨但存在黑盒 文章在技术选型上表现出一定的深度，特别是对“多阶段排序”的重视，表明作者理解检索质量仅仅靠向量相似度是不够的。然而，文章作为一篇Show HN（通常用于展示Demo），在索引结构的细节、查询优化器的具体实现以及向量检索算法（如HNSW参数）的调优方面论证不够严谨，更多停留在接口层面的展示。

2. 实用价值：中高 对于已经拥有成熟SQL技术栈的团队，ShapedQL提供了一种低摩擦的AI应用接入方式。它允许复用现有的数据库权限管理、连接池和监控体系。其实用价值取决于“迁移成本”，如果它能直接连接PostgreSQL或MySQL作为插件，价值将倍增；如果是一个全新的独立数据库，则迁移成本会抵消部分便利性。

3. 创新性：集成创新大于底层突破 这并非底层算法的突破（如提出新的向量索引方式），而是工程架构的创新。它类似于MongoDB近期推出的向量搜索功能，或者是TimescaleDB的AI功能。核心创新点在于**“RAG的标准化”**，试图将RAG从一种“编程模式”变成一种“查询能力”。

4. 可读性：清晰 技术文章通常容易陷入实现细节，但该文通过SQL示例直观地展示了功能，逻辑清晰。对于开发者而言，看到SELECT ... WITH RAG这样的语法比阅读长篇大论的架构图更容易理解核心价值。

5. 行业影响：推动“Data-Centric AI”落地 如果此类工具成熟，将推动AI开发从“模型中心”（Model-Centric，关注调参）转向“数据中心”（Data-Centric，关注检索质量和数据管道）。它可能会催生一类新的职位：AI数据工程师，他们不需要精通PyTorch，但需要精通SQL和检索策略。

争议点与不同观点

争议点：SQL是否是AI的终极接口？

作者观点：SQL是处理RAG的理想接口，因为它标准化了数据流。
不同观点：部分AI研究者认为，RAG本质上是一个概率性和非确定性的过程，而SQL的设计初衷是处理确定性的集合运算。用确定性语言描述概率性流程，可能会导致语义混淆。例如，如何用SQL表达“如果置信度低于0.8，则调用备用的LLM模型”这种逻辑？虽然可以通过Case When实现，但这会让SQL变得极其臃肿，违背了其简洁性。

实际应用建议

场景匹配：如果你的应用主要是“检索+生成”，且数据源主要来自结构化数据库或半结构化文档，ShapedQL这类工具非常适合。如果你的应用涉及复杂的推理链或多轮对话状态管理，建议将其作为检索层，而非全栈解决方案。
性能基准测试：在引入此类引擎前，务必对比“应用层Python实现”与“SQL引擎内实现”的端到端延迟。不要假设数据库内部的实现就一定更快。
可观测性：RAG系统的调试非常困难。建议检查该工具是否提供了Trace功能，能够输出每一阶段的检索得分和中间结果，否则排查“为什么没搜到”将成为噩梦。

可验证的检查方式

代码示例

 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
46
47
48
49
50
51
52
# 示例1：多阶段排序（结合语义相似度和元数据过滤）
from typing import List, Dict
import sqlite3

def multi_stage_ranking():
    """模拟ShapedQL的多阶段排序功能"""
    # 初始化SQLite数据库并创建示例表
    conn = sqlite3.connect(":memory:")
    conn.execute("""
        CREATE TABLE products (
            id INTEGER PRIMARY KEY,
            name TEXT,
            price REAL,
            description TEXT,
            popularity_score REAL
        )
    """)
    
    # 插入示例数据
    products = [
        (1, "智能手表", 299.99, "健康监测防水运动手表", 8.5),
        (2, "无线耳机", 149.99, "降噪蓝牙耳机长续航", 9.2),
        (3, "智能音箱", 79.99, "语音控制智能家居", 7.8)
    ]
    conn.executemany("INSERT INTO products VALUES (?, ?, ?, ?, ?)", products)
    
    # 模拟语义相似度分数（实际应用中会来自向量数据库）
    semantic_scores = {1: 0.85, 2: 0.92, 3: 0.78}
    
    # 执行多阶段查询：先过滤再排序
    query = """
        SELECT p.*, 
               (p.popularity_score * 0.3 + ? * 0.7) as final_score
        FROM products p
        WHERE p.price < 200
        ORDER BY final_score DESC
    """
    
    # 为每个产品计算最终分数
    results = []
    for row in conn.execute(query, (semantic_scores[2],)):
        results.append({
            "name": row[1],
            "price": row[2],
            "final_score": row[5]
        })
    
    conn.close()
    return results

# 运行示例
print(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
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
# 示例2：RAG增强的文档检索
import sqlite3
from typing import List, Tuple

def rag_document_retrieval():
    """模拟ShapedQL的RAG增强检索功能"""
    # 创建内存数据库和文档表
    conn = sqlite3.connect(":memory:")
    conn.execute("""
        CREATE TABLE documents (
            id INTEGER PRIMARY KEY,
            title TEXT,
            content TEXT,
            embedding_id INTEGER
        )
    """)
    
    # 插入示例文档
    docs = [
        (1, "Python教程", "Python是一种高级编程语言...", 101),
        (2, "机器学习基础", "机器学习是AI的一个分支...", 102),
        (3, "数据库设计", "关系型数据库使用SQL...", 103)
    ]
    conn.executemany("INSERT INTO documents VALUES (?, ?, ?, ?)", docs)
    
    # 模拟向量相似度搜索结果（实际会来自向量数据库）
    vector_results = [(102, 0.89), (101, 0.75), (103, 0.62)]
    
    # 执行RAG查询：结合向量搜索和SQL过滤
    query = """
        SELECT d.title, d.content, v.similarity
        FROM documents d
        JOIN (VALUES (?, ?), (?, ?), (?, ?)) AS v(id, similarity)
        ON d.embedding_id = v.id
        WHERE d.title LIKE '%教程%'
        ORDER BY v.similarity DESC
    """
    
    # 展平向量结果为查询参数
    params = [item for sublist in vector_results for item in sublist]
    
    # 执行查询并返回结果
    results = []
    for row in conn.execute(query, params):
        results.append({
            "title": row[0],
            "content": row[1][:50] + "...",  # 截断内容
            "similarity": row[2]
        })
    
    conn.close()
    return results

# 运行示例
print(rag_document_retrieval())

  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
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
# 示例3：混合查询（结构化数据+非结构化数据）
def hybrid_query():
    """模拟ShapedQL的混合查询能力"""
    # 初始化数据库
    conn = sqlite3.connect(":memory:")
    
    # 创建用户表和订单表
    conn.execute("""
        CREATE TABLE users (
            id INTEGER PRIMARY KEY,
            name TEXT,
            email TEXT,
            preferences TEXT  -- JSON格式的偏好设置
        )
    """)
    
    conn.execute("""
        CREATE TABLE orders (
            id INTEGER PRIMARY KEY,
            user_id INTEGER,
            product TEXT,
            amount REAL,
            FOREIGN KEY(user_id) REFERENCES users(id)
        )
    """)
    
    # 插入示例数据
    users = [
        (1, "张三", "zhang@example.com", '{"category": "电子产品", "price_range": "100-500"}'),
        (2, "李四", "li@example.com", '{"category": "书籍", "price_range": "50-100"}')
    ]
    conn.executemany("INSERT INTO users VALUES (?, ?, ?, ?)", users)
    
    orders = [
        (1, 1, "智能手表", 299.99),


---
## 案例研究


### 1：某大型跨境电商平台的智能搜索优化

 1：某大型跨境电商平台的智能搜索优化

**背景**:
该平台拥有数亿商品和数千万日活用户。其核心业务依赖于站内搜索引擎，用户通过关键词搜索商品。传统的搜索系统基于倒排索引（如 Elasticsearch），能够处理基本的文本匹配，但在面对长尾查询或需要理解用户深层意图时表现不佳。

**问题**:
原有的搜索架构在引入语义检索（RAG）后遇到了严重的工程瓶颈。
1.  **多阶段排序难以编排**：系统需要先进行语义召回，再基于用户历史行为进行重排序。传统的代码实现方式导致各个阶段（召回、粗排、精排、业务规则过滤）逻辑分散，维护成本极高。
2.  **数据割裂**：用于语义向量的向量库与存储用户行为和商品属性的 SQL 数据库是分离的。开发人员不得不编写复杂的 Python 脚本来搬运数据并在不同系统间进行 Join 操作，导致端到端延迟很高。
3.  **灵活性差**：产品经理经常要求调整排序权重（例如：在特定节日优先推荐高利润库存商品），每次调整都需要研发团队修改代码并重新部署，无法快速响应市场变化。

**解决方案**:
引入 ShapedQL 作为统一的查询引擎。
1.  **统一接口**：将向量检索逻辑和传统的 SQL 业务逻辑（价格、库存、过往购买记录）整合。
2.  **多阶段编排**：利用 ShapedQL 的多阶段排序能力，在一个查询语句中完成“语义相似度召回 -> 基于历史点击率的粗排 -> 基于业务规则的精排”。
3.  **RAG 集成**：将商品的长文本描述作为上下文，通过 RAG 技术增强对用户模糊查询的理解，直接在查询层完成检索与生成。

**效果**:
1.  **研发效率提升**：原本需要维护多套微服务的搜索逻辑，现在通过数行 ShapedQL 即可表达，新功能上线周期从 2 周缩短至 2 天。
2.  **转化率提高**：通过更精准的多阶段排序，实现了搜索结果与用户意图的高度匹配，长尾词搜索的点击转化率提升了 15%。
3.  **系统简化**：移除了中间的数据搬运层，查询延迟降低了 30%，极大提升了用户体验。

---



### 2：金融科技公司的内部知识库问答系统

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

**背景**:
一家服务于机构投资者的金融科技公司，拥有海量的研报、财经新闻和内部合规文档。为了提升分析师的工作效率，公司计划构建一个基于 RAG 的内部知识库问答系统，允许分析师用自然语言查询数据。

**问题**:
在实施过程中，单纯依靠向量检索的 RAG 方案存在严重的缺陷。
1.  **检索精度不足**：金融领域对数字极其敏感。当分析师询问“某公司在 2023 年 Q4 的净利润”时，传统的向量检索往往返回的是语义相似但数字过时或不准确的段落，导致大模型产生“幻觉”。
2.  **权限控制复杂**：金融文档具有严格的权限等级（如：仅核心团队可见）。简单的向量数据库无法在检索层面直接结合用户权限表（SQL）进行过滤，必须在检索后进行二次过滤，增加了安全风险和计算开销。
3.  **多模态数据融合困难**：最佳答案往往结合了文本描述和结构化数据（如股价走势表），两者难以在一个查询中高效结合。

**解决方案**:
采用 ShapedQL 构建混合检索引擎。
1.  **混合排序**：结合语义检索（RAG）和关键词检索（BM25），并利用 ShapedQL 的排序能力，将包含精确数字的结构化数据权重调高，确保数值类问答的准确性。
2.  **行级安全过滤**：在查询阶段直接将用户权限表与文档索引进行 Join 操作，确保分析师只能检索到其有权访问的文档，从底层杜绝数据泄露。
3.  **结构化与非结构化结合**：在一个查询中同时关联 SQL 数据库中的最新财务指标和文档库中的分析文本，为 LLM 提供高质量的上下文。

**效果**:
1.  **答案准确率大幅提升**：通过引入结构化数据的精确匹配和重排序，复杂金融问题的回答准确率从 65% 提升至 90% 以上，显著减少了人工核查的工作量。
2.  **合规性保障**：实现了查询层面的权限隔离，顺利通过了内部合规团队的审计。
3.  **响应速度快**：相比先检索再过滤的方案，ShapedQL 的原生过滤机制将查询响应时间控制在 500ms 以内，满足了交互式问答的需求。

---
## 最佳实践

## 最佳实践指南

### 实践 1：构建语义与关键词混合检索策略

**说明**: 在 RAG（检索增强生成）场景中，单纯的向量检索或关键词检索往往存在局限性。ShapedQL 支持多阶段排序，最佳实践是结合向量数据库的语义检索与传统数据库的关键词检索（如 BM25），利用 ShapedQL 的 SQL 能力将两者结合，既保证语义的相关性，又弥补关键词匹配的精确度。

**实施步骤**:
1. 在数据源中同时存储文本的 Embedding 向量和原始文本。
2. 编写 SQL 查询，首先通过向量相似度搜索获取候选集，再通过全文检索进行过滤或加权。
3. 使用 ShapedQL 的排序函数对两组结果进行融合（如 RRF 算法）。

**注意事项**: 确保向量索引和全文索引已正确构建，以避免全表扫描导致的性能问题。

---

### 实践 2：利用多阶段排序优化结果相关性

**说明**: ShapedQL 的核心优势在于“多阶段排名”。不要试图在一个复杂的 SQL 查询中完成所有逻辑，而应将其拆解。第一阶段可以快速过滤（如基于时间、类别），第二阶段进行粗排（如基于向量相似度），第三阶段进行精排（如基于复杂的业务规则或重排序模型）。

**实施步骤**:
1. 定义漏斗模型：明确每一阶段的数据筛选目标。
2. 编写多层级 SQL 查询，利用 `WITH` 子句或嵌套查询来分阶段处理数据。
3. 在最终阶段引入业务特征（如用户点击率、商品热度）进行加权打分。

**注意事项**: 每一阶段的数据量级应呈递减趋势，防止在精排阶段处理过多数据导致延迟。

---

### 实践 3：实现上下文感知的个性化 RAG

**说明**: 通用的 RAG 往往忽略用户差异。利用 ShapedQL 连接用户特征库和文档库，可以在检索阶段就加入个性化过滤。例如，根据用户的历史偏好调整检索权重，或根据用户权限过滤文档。

**实施步骤**:
1. 准备用户画像表，包含用户 ID、偏好标签或历史行为向量。
2. 在 SQL 查询的 `WHERE` 子句中加入用户相关的过滤条件。
3. 在 `ORDER BY` 子句中计算文档内容与用户画像的匹配度作为排序依据。

**注意事项**: 处理好用户隐私数据的访问权限，避免在日志中泄露敏感用户信息。

---

### 实践 4：优化向量检索的性能与召回率

**说明**: 向量检索通常是 RAG 中最耗时的部分。在 ShapedQL 中，应合理设置检索的 `top_k` 值。过小的 `k` 值可能导致丢失关键信息（低召回率），过大的 `k` 值则会增加计算负担和噪声。

**实施步骤**:
1. 在开发阶段测试不同的 `top_k` 值（如 20, 50, 100），观察最终生成质量。
2. 在 SQL 中使用近似最近邻（ANN）索引函数，并设定可接受的精度阈值。
3. 对检索返回的文档片段进行截断，控制输入给 LLM 的总 Token 长度。

**注意事项**: 监控查询延迟，如果向量检索耗时过长，考虑调整索引参数（如 HNSW 的 `ef_construction`）。

---

### 实践 5：建立数据验证与过滤机制

**说明**: 垃圾进，垃圾出。在将检索结果传递给 LLM 之前，必须在 SQL 层面建立严格的数据验证。这包括过滤掉低质量内容、去重以及处理空值。

**实施步骤**:
1. 在 SQL 查询中添加 `DISTINCT` 或去重逻辑，防止重复内容干扰 LLM。
2. 使用 `CASE WHEN` 语句或过滤函数排除质量分低于阈值的文档。
3. 检查必要字段是否为 `NULL`，确保上下文完整性。

**注意事项**: 过于严格的过滤可能导致返回结果为空，建议在代码层增加“降级策略”，当无结果时返回默认通用回复。

---

### 实践 6：模块化 SQL 逻辑以便于 A/B 测试

**说明**: RAG 系统的调优需要频繁实验。将 ShapedQL 的查询逻辑模块化（例如使用视图 View 或存储过程），可以方便地在线上切换不同的排序策略或检索范围，进行 A/B 测试。

**实施步骤**:
1. 将核心检索逻辑封装在数据库视图中。
2. 通过传入不同的参数（如不同的权重系数 `alpha`）来控制语义检索与关键词检索的比例。
3. 记录每次查询的元数据（如使用的排序版本），以便后续分析效果。

**注意事项**: 确保模块化后的查询计划不会导致性能下降，避免视图嵌套过深。

---
## 学习要点

- ShapedQL 是一个基于 SQL 的引擎，专为多阶段排序和检索增强生成（RAG）设计，允许开发者用熟悉的 SQL 语法定义复杂的检索逻辑。
- 该引擎通过将向量检索、重排序和业务逻辑结合在一个 SQL 查询中，解决了传统 RAG 管道中碎片化的问题，简化了开发流程。
- ShapedQL 支持在查询中直接调用机器学习模型进行特征提取和评分，实现了数据检索与模型推理的无缝集成。
- 它提供了灵活的排序机制，允许用户根据自定义权重和业务规则对检索结果进行多阶段精细化的重新排序。
- 该工具旨在降低 AI 应用开发的门槛，使不具备深厚机器学习背景的开发者也能构建高性能的个性化推荐和搜索系统。
- ShapedQL 能够连接多种数据源，通过统一的数据访问层消除了在向量数据库和关系数据库之间同步数据的复杂性。

---
## 常见问题


### 1: ShapedQL 主要解决什么技术痛点，它与标准 SQL 有何区别？

1: ShapedQL 主要解决什么技术痛点，它与标准 SQL 有何区别？

**A**: ShapedQL 主要旨在解决传统 SQL 在处理“多阶段排序”和“检索增强生成（RAG）”工作流时的局限性。标准 SQL 非常适合聚合和简单的过滤操作，但在构建复杂的推荐系统（例如：先筛选候选集、再进行语义相似度排序、最后应用业务规则重排）时，编写起来会非常繁琐且效率低下。

ShapedQL 将这些高级功能（如向量搜索、机器学习模型推理、列表操作）原生集成到了 SQL 语法中。它允许开发者在一个查询中完成从数据提取到 AI 模型推理再到结果排序的全过程，而不需要在应用层编写复杂的 Python 代码来拼接数据库查询和模型调用。

---



### 2: ShapedQL 中的“多阶段排序”具体是指什么？

2: ShapedQL 中的“多阶段排序”具体是指什么？

**A**: 在构建推荐系统或搜索引擎时，通常不会一次性对所有数据进行排序，因为这既昂贵又不准确。多阶段排序是一种分而治之的策略，通常包含以下步骤：

1.  **召回/候选集生成**: 快速从海量数据中筛选出几百或几千个可能相关的项目（例如基于简单的过滤规则或关键词匹配）。
2.  **精排**: 对候选集进行更细致的计算，利用复杂的机器学习模型或向量相似度对每个项目打分。
3.  **重排**: 根据业务逻辑（如多样性、新鲜度、用户指定的规则）对最终结果进行调整。

ShapedQL 提供了特定的语法和函数来支持这种流水线式的操作，使得在一个查询语句中描述整个流程成为可能。

---



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

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

**A**: RAG 应用通常需要先从数据库中检索相关文档，然后将其作为上下文传递给大语言模型（LLM）。ShapedQL 通过内置的向量搜索能力和对 LLM 的原生支持来简化这一过程。

开发者可以直接在 SQL 查询中计算文本的向量嵌入，并立即执行向量相似度搜索（例如寻找与用户问题最相似的文档段落）。此外，它可能还支持直接在查询中调用 LLM 端点，将检索到的结果格式化并生成最终答案，从而减少了在数据库和 AI 服务之间来回传输数据的开销。

---



### 4: ShapedQL 是一个独立的数据库还是一个连接器？

4: ShapedQL 是一个独立的数据库还是一个连接器？

**A**: 根据名称和“SQL engine”的描述，ShapedQL 通常被设计为一个中间层引擎或代理，而不是一个从零开始存储数据的独立数据库。它通常连接到用户现有的数据存储（如 PostgreSQL, MySQL, Snowflake 或向量数据库）。

它的工作原理是接收用户的 ShapedQL 查询，将其拆解，下推部分计算到源数据库，在内部或外部计算引擎中执行 AI/ML 相关的计算（如向量距离或模型推理），然后将结果组合返回。这使得用户可以在不迁移现有数据资产的情况下获得高级 AI 功能。

---



### 5: 相比于在 Python 代码中编写逻辑，使用 ShapedQL 有什么优势？

5: 相比于在 Python 代码中编写逻辑，使用 ShapedQL 有什么优势？

**A**: 虽然在 Python 中使用 Pandas 或专门的库可以实现相同的功能，但使用 ShapedQL 有以下显著优势：

1.  **数据局部性**: 如果逻辑在数据库层（或靠近数据库的引擎层）执行，可以避免将大量数据集拉取到应用服务器内存中，从而显著减少网络延迟和内存占用。
2.  **声明式编程**: SQL 是声明式的，你只需要描述“想要什么”，而不需要详细描述“怎么做”。这使得代码更易于阅读、维护和优化。
3.  **性能优化**: 引擎可以自动优化查询执行计划，例如并行化处理或智能索引使用，这比手写的 Python 循环通常更高效。

---



### 6: ShapedQL 的性能如何？它能处理实时请求吗？

6: ShapedQL 的性能如何？它能处理实时请求吗？

**A**: ShapedQL 的设计目标通常包括能够处理实时的交互式查询。由于它针对多阶段排序进行了优化，它可以通过在第一阶段快速缩小数据范围来保证低延迟。

具体的性能表现取决于底层数据库的延迟以及调用的外部模型（如嵌入模型或 LLM）的响应速度。如果配置得当（例如利用向量索引缓存），它完全可以被用于构建亚秒级的推荐 API 或搜索服务。对于超大规模的数据集，通常需要配合其向量索引功能或连接的 OLAP 数据库来实现高性能。

---



### 7: 学习 ShapedQL 是否困难？

7: 学习 ShapedQL 是否困难？

**A**: 如果你已经熟悉 SQL，学习 ShapedQL 的门槛会很低。它的核心设计理念是扩展现有的 SQL 标准，而不是创造一种全新的语言。

你需要学习的主要是新增的函数，例如用于向量搜索的运算符（如 `NEAREST`）、用于调用机器学习模型的函数，以及用于定义排序阶段的特定语法。对于数据分析师和后端工程师来说，这通常比学习全新的编程范式或复杂的 Python 框架要快得多。

---
## 思考题


### ## 挑战与思考题

### ### 挑战 1: [简单]

### 问题**: 在传统的 SQL 查询中，`WHERE` 子句通常用于基于布尔逻辑（如 `age > 18`）进行硬性过滤。假设你正在使用 ShapedQL 构建一个推荐系统，你需要根据用户的“兴趣度”对商品进行排序，但同时也希望过滤掉库存为 0 的商品。请设计一个查询逻辑，说明如何结合传统的布尔过滤与基于向量相似度的软排序。

### 提示**: 思考 SQL 执行的顺序，以及 ShapedQL 如何处理结构化数据（库存）与非结构化数据（向量嵌入）的混合查询。过滤操作应该在计算相似度之前还是之后进行？

### 

---
## 引用

- **原文链接**: [https://playground.shaped.ai](https://playground.shaped.ai)
- **HN 讨论**: [https://news.ycombinator.com/item?id=46779922](https://news.ycombinator.com/item?id=46779922)

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

---


---
## 站内链接

- 分类： [AI 工程](/categories/ai-%E5%B7%A5%E7%A8%8B/) / [数据](/categories/%E6%95%B0%E6%8D%AE/)
- 标签： [ShapedQL](/tags/shapedql/) / [SQL引擎](/tags/sql%E5%BC%95%E6%93%8E/) / [RAG](/tags/rag/) / [多阶段排序](/tags/%E5%A4%9A%E9%98%B6%E6%AE%B5%E6%8E%92%E5%BA%8F/) / [向量检索](/tags/%E5%90%91%E9%87%8F%E6%A3%80%E7%B4%A2/) / [数据查询](/tags/%E6%95%B0%E6%8D%AE%E6%9F%A5%E8%AF%A2/) / [AI基础设施](/tags/ai%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD/) / [搜索优化](/tags/%E6%90%9C%E7%B4%A2%E4%BC%98%E5%8C%96/)
- 场景： [RAG应用](/scenarios/rag%E5%BA%94%E7%94%A8/) / [AI/ML项目](/scenarios/ai-ml%E9%A1%B9%E7%9B%AE/)

### 相关文章

- [基于嵌入的Top-k检索：R^{2k}维度理论上已足够](/posts/20260129-arxiv_ai-mathbbr2k-is-theoretically-large-enough-for-embedd-8/)
- [Postgres模糊/语义搜索：输入'Beatles abbey rd'精准定位Abbey Road！🚀](/posts/20260126-hacker_news-find-abbey-road-when-type-beatles-abbey-rd-fuzzyse-6/)
- [谷歌健康搜索惊现YouTube>医疗网站？AI Overview引争议！🤖🏥](/posts/20260126-hacker_news-google-ai-overviews-cite-youtube-more-than-any-med-9/)
- [🔥ChatGPT WebUI重磅升级！530模型+MCP+全能RAG，AI能力原地起飞！](/posts/20260126-hacker_news-oss-chatgpt-webui-530-models-mcp-tools-gemini-rag--11/)
- [💥文本为王！揭秘AI时代最被低估的核心价值！](/posts/20260126-hacker_news-text-is-king-11/)
*本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。*

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