知识库的检索方式不是由技术决定的，而是由场景决定的。本文深入拆解精确检索、语义检索与混合检索的适用场景，结合Claude Code与Cursor的实战对比，给出从飞书多维表格到云RDBMS再到自建全栈的三条选型路径，为产品经理提供一套可落地的知识库构建决策框架。

这是系列第三篇。第一篇定义了 AI 内容生产的三层架构（感知→知识库→生产），指出知识库是天花板；第二篇解决了数据怎么结构化进知识库（ASR→抽帧→标注→可检索存储）。这篇解决知识库怎么存、怎么查的问题。

一、场景决定检索方式：精确、语义、还是混合

知识库的检索方式不是由技术决定的，而是由场景决定的。三种典型场景对应三种不同的检索策略：

场景一：人在界面查

用户自己输入筛选条件，系统返回匹配的记录列表。精确查询，不需要 NL 解析。

场景二：Agent对话查

Agent 收到自然语言指令后解析意图，决定用什么方式检索：

• 字段关键词匹配（类似 grep / contains）——目标有明确的关键词特征
• 向量匹配（embedding）——需要深度语义理解

场景三：混合查

NL 解析后拆解为精确条件 + 语义意图，分别走结构化检索和语义检索，再合并排序。关键在系统要判断每个子任务该走哪种检索，不是一律 RAG。

场景决定了”系统需要怎么回答”——返回精确记录（结构化过滤）、匹配关键词（字段检索）、还是理解含义（embedding）。

理解了场景差异，才能选对存储和检索方案。

Agent 的两种检索实现：Claude Code vs Cursor

两者代表了精确检索（grep）vs 语义检索（embedding）。Cursor 官方博客 Semantic Search at Cursor 的评估数据：

1. 在需要搜索才能回答的问题上，语义搜索提升准确率 12.5%（6.5%–23.5%）；
2. 但在覆盖所有请求的 A/B 测试中，真实收益较小（代码保留率 +0.3%，追问 -2.2%）。
3. 说明大部分查询 grep 已经够用。Claude Code 选择纯 grep 而不用 RAG，也印证了这一点。

二、评估指标与透明设计

2.1. 评估指标

场景不同，评估重点不同。精确检索看准确率和响应时间；语义检索看能否找对内容。混合检索既要有召回又要可控。

以下指标按检索类型分类：

2.2 NL（自然语言） 数据分析的透明设计

自然语言（NL）→查询翻译是概率性的，用户无法直接判断对错。产品设计的核心是让用户感受到系统理解了什么、有多确定、错了怎么办。

参考：三家主流平台的共同模式

Snowflake Cortex Analyst（Verified Query Repository）、Databricks Genie（Trusted Assets + Ontology）、BigQuery Conversational Analytics（Verified Queries）——三家共同做法是数据团队预先治理查询资产，系统优先复用经过验证的查询，结果标注来源标签，最终由用户凭业务知识判断。

Google BigQuery产品设计参考示例

信任不来自 LLM 的”自信程度”，而来自curation 基础设施。数据团队预先治理查询资产后，系统按四阶段运作：

三、选型路径

根据团队规模和研发能力，知识库选型分为三条路径。选对路径比选对技术更重要。

路径一：Code Agent + 飞书（个人/小团队）

适用：个人开发者、小团队（1-5人）、数据量 <1000条、无研发资源。

核心思路：Code Agent（Claude Code / Cursor）通过 CLI 或 API 直接操作飞书多维表格，精确查询走结构化过滤，不需要自建任何基础设施。

查询方式：Agent 通过 API 对多维表格执行结构化过滤（按字段筛选、排序、聚合），用户不感知底层协议；运营在飞书多维表格界面用筛选器做同样的事——同一张表、同一份数据，不需要额外的权限配置或数据同步。

Claude Code&飞书skill 测试示例

路径二：云 RDBMS + NL2SQL（中型项目 · 托管服务路线）

适用：有预算、需要 NL2SQL 能力、数据量 1000-10万条、希望免运维。

核心思路：用云关系型数据库（AWS RDS + Bedrock、Azure SQL + Copilot、Google Cloud SQL + Gemini）自带的 NL2SQL 能力，平台已内建自然语言→SQL 翻译。你只需做数据加工和 curation，不需要自建 Agent 实现层。

数据加工与 curation：原始数据 → ETL 清洗 → 语义模型配置（字段含义、业务口径）→ Verified Queries（10-20条起步）→ benchmark 评测 → 补充映射 → 迭代覆盖核心场景。

多入口访问：Code Agent 通过 API/NL2SQL 查询，业务人员通过 WebUI 查询，运营通过 BI 工具查询。同一数据源，不需要为每个入口单独开发。

⚠️ curation 是关键瓶颈：NL2SQL 准确率取决于语义模型和 Verified Queries 的质量。建议从 10-20 条高频问题起步，跑 benchmark 迭代。

路径三：自建全栈（大型项目 · 自建路线）

适用：有研发团队、对数据安全要求高、数据量 10万+条、需要完全可控。

核心思路：自建完整的 Agent 实现层（意图解析、路由、检索编排）+ 自建存储层（MySQL/PG + ES + 向量DB）+ 自建 curation pipeline。完全可控，但工程量大。

自建 curation：原始数据 → ETL 清洗 → 自建语义模型（字段映射、业务口径）→ 自建验证查询库 → benchmark 评测 → 自动化回归测试 → 迭代。

多入口访问：自建 API Gateway 统一认证，Code Agent 通过 API 查询，业务人员通过自建 WebUI 查询，BI 工具通过 JDBC/ODBC 直连。所有入口共享同一套权限和审计日志。

怎么选：一张决策表

三条路径不是互斥的，是递进的。飞书多维表格验证了知识库的价值后，可以平滑迁移到云 RDBMS；云 RDBMS 跑通后，再根据需要决定是否自建。先跑通，再优化。