【AI问数·技术】四维RAG体系深度拆解：Schema/Knowledge/Few-shot/Context

hotdefans2026-08-20 20:45

RAG（检索增强生成）是NL2SQL准确率从60%跃升到95%的核心技术。但"RAG"不是一个单一技术，而是一个多维度的知识注入体系。本文深度拆解鲲溟智能的四维RAG架构------Schema RAG、Knowledge RAG、Few-shot RAG、Context RAG，从原理、数据结构、检索策略到工程实现，逐一讲透每个维度的技术内核。

📖 导读

为什么通用大模型直接生成SQL的准确率只有60-70%，而加入RAG后能提升到95%+？

答案在于：大模型懂"语法"，但不懂"你的数据"。 它不知道你的数据库里"销售额"存在哪个字段、"华东区"对应什么编码、"客单价"的计算口径是含不含税。RAG的本质，就是在生成SQL之前，把"你的数据知识"精准注入给大模型。

但"注入什么知识"大有讲究------注入太多会干扰生成，注入太少又不够用，注入不精准反而误导。鲲溟智能的四维RAG体系，正是解决"注入什么、注入多少、何时注入"的系统性方案。

关键词：RAG、NL2SQL、Schema Linking、知识图谱、Few-shot、上下文管理、鲲溟智能

一、RAG在NL2SQL中的角色

1.1 为什么NL2SQL需要RAG？

1.2 四维RAG总览

二、Dimension 1：Schema RAG

2.1 解决什么问题？

核心问题：在几百张表、几千个字段中，精准找到与用户问题相关的表和字段。

一个中型企业的数据仓库可能有200+张表、3000+个字段。如果把完整Schema全部塞给大模型：①超出上下文窗口；②大量无关信息干扰生成。Schema RAG的目标是只注入相关的5-15张表和20-50个字段。

2.2 数据结构

python 复制代码 
# Schema元数据结构（简化示意）
class TableSchema:
    table_name: str          # "sales_order"
    description: str         # "销售订单主表，记录所有客户订单"
    columns: List[Column]    # 字段列表
    primary_key: str         # "order_id"
    foreign_keys: List[FK]   # 外键关系
    tags: List[str]          # ["销售", "订单", "收入"]
    sample_values: Dict      # 各字段的示例值

class Column:
    name: str                # "net_amount"
    type: str                # "DECIMAL(12,2)"
    description: str         # "净销售额（含税，未剔除退货）"
    business_name: str       # "净销售额"
    synonyms: List[str]      # ["销售额", "营收", "收入"]
    is_metric: bool          # True（是度量字段）
    is_dimension: bool       # False
    formula: str             # "SUM(net_amount) WHERE is_return=0"

2.3 检索策略

2.4 工程要点

要点 实现方式 效果
字段描述质量 人工+AI辅助生成，定期审核 召回准确率+15%
同义词维护 从用户查询日志自动挖掘 覆盖口语化表达
向量索引更新 Schema变更时增量更新 保持时效性
多表关联推理 图数据库存储表关系 支持3+表JOIN
示例值注入 每个字段附带3-5个示例值 帮助理解字段含义

三、Dimension 2：Knowledge RAG

3.1 解决什么问题？

核心问题：理解业务术语、指标口径和默认规则。

"销售额"在不同企业含义不同：是GMV还是净收入？含不含税？含不含退货？"华东区"包含哪些省份？"大客户"的标准是什么？这些业务知识不在数据库Schema里，需要额外的知识库来承载。

3.2 知识分类

3.3 检索与注入

python 复制代码 
# Knowledge RAG检索流程（简化示意）
class KnowledgeRetriever:
    def retrieve(self, question, entities):
        knowledge_items = []

        # 1. 术语匹配：识别问题中的业务术语
        for term in self.extract_terms(question):
            matched = self.term_index.search(term)
            knowledge_items.extend(matched)

        # 2. 口径匹配：识别涉及的指标
        for metric in entities['metrics']:
            caliber = self.caliber_db.get(metric)
            knowledge_items.append(caliber)

        # 3. 规则匹配：加载适用的默认规则
        rules = self.rule_engine.match(
            metrics=entities['metrics'],
            dimensions=entities['dimensions']
        )
        knowledge_items.extend(rules)

        # 4. 编码映射：维度值→SQL条件
        for dim_value in entities['dim_values']:
            mapping = self.dim_mapping.get(dim_value)
            knowledge_items.append(mapping)

        # 5. 去重+排序+截断（避免注入过多）
        return self.rank_and_truncate(knowledge_items, max_items=10)

3.4 知识库运营

运营动作 频率 负责人 来源
新术语录入 按需 数据分析师 业务部门反馈
口径变更更新 按需 数据治理团队 财务/业务变更
规则审核 月度 数据治理团队 错误case分析
行业知识补充 季度 产品团队 行业研究
自动挖掘 每日 AI系统 用户查询日志

四、Dimension 3：Few-shot RAG

4.1 解决什么问题？

核心问题：给大模型"参考答案"，让它学会"你的SQL写法"。

同一个查询意图，SQL可以有多种写法。Few-shot示例让大模型学习：①企业偏好的写法；②复杂查询的正确模式；③特殊业务的处理逻辑。

4.2 示例库结构

python 复制代码 
# Few-shot示例结构
class SQLExample:
    question: str        # "上个月各区域销售额排名"
    sql: str            # "SELECT r.name, SUM(s.amount) ..."
    explanation: str    # "按区域分组，汇总销售额，降序排列"
    difficulty: str     # "medium"
    tags: List[str]     # ["销售", "区域", "排名", "聚合"]
    embedding: Vector   # 问题的向量表示（用于相似度检索）
    verified: bool      # 是否经过人工验证
    usage_count: int    # 被引用次数
    success_rate: float # 引用后SQL正确率

4.3 检索策略

4.4 示例库建设

五、Dimension 4：Context RAG

5.1 解决什么问题？

核心问题：理解多轮对话中的指代、省略和修改。

复制代码 
第1轮："上个月华东区销售额多少？" → 正常查询
第2轮："华南呢？" → 省略了"销售额"和"上个月"
第3轮："按产品线拆分看看" → 省略了所有条件，只要改GROUP BY
第4轮："去掉华南，加上西南" → 修改WHERE条件
第5轮："改成按季度看" → 修改时间粒度

没有Context RAG，每轮都是"全新问题"，无法理解"华南呢？"是什么意思。

5.2 上下文管理

python 复制代码 
# Context RAG数据结构
class ConversationContext:
    session_id: str
    turns: List[Turn]
    current_state: QueryState  # 当前查询的完整语义状态

class QueryState:
    metrics: List[str]        # 当前指标 ["销售额"]
    dimensions: List[str]     # 当前维度 ["区域"]
    filters: List[Filter]     # 当前过滤条件
    time_range: TimeRange     # 当前时间范围
    order_by: str             # 当前排序
    limit: int                # 当前限制
    last_sql: str             # 上一轮生成的SQL
    last_result: DataFrame    # 上一轮的结果（用于追问）

# 上下文解析逻辑
class ContextResolver:
    def resolve(self, new_question, context):
        # 1. 指代消解
        # "华南呢？" → 理解为"上个月华南区销售额多少？"

        # 2. 省略补全
        # "按产品线拆分" → 补全为"上个月华东区各产品线销售额"

        # 3. 修改应用
        # "去掉华南" → 修改filters，移除华南条件

        # 4. 状态更新
        # 更新QueryState，传递给下一轮

        return resolved_full_question, updated_state

5.3 上下文窗口策略

策略 说明 适用场景
完整保留 保留所有历史轮次 短对话（<5轮）
滑动窗口 只保留最近3轮 长对话（>5轮）
状态压缩 只保留QueryState，不保留原始对话 超长对话
话题切换检测 检测到新话题时重置上下文 话题跳转

六、四维协同：Prompt工程

6.1 最终Prompt结构

6.2 Token预算管理

维度 预算占比 Token数（约） 说明
System Prompt 10% 400 角色定义+输出格式
Schema RAG 35% 1,400 5-15张表的精简Schema
Knowledge RAG 25% 1,000 5-10条知识项
Few-shot RAG 20% 800 2-3个示例
Context RAG 5% 200 最近1-3轮上下文
用户问题+输出 5% 200 问题+生成空间
总计 100% ~4,000 控制在4K Token内

七、效果验证

7.1 消融实验

配置 综合准确率 说明
无RAG（纯LLM） 62% 基线
+Schema RAG 72% +10%
+Knowledge RAG 84% +12%
+Few-shot RAG 92% +8%
+Context RAG（多轮） 95.6% +3.6%（多轮场景+5%）
四维全开 95.6% +33.6%

7.2 各维度对不同查询类型的影响

查询类型 无RAG +Schema +Knowledge +Few-shot +Context
简单查询 78% 92% 94% 96% 96%
业务术语 45% 55% 90% 93% 93%
复杂多表 52% 72% 78% 92% 92%
模糊表达 48% 58% 72% 85% 88%
多轮追问 35% 45% 55% 65% 92%

关键发现：Knowledge RAG对业务术语查询贡献最大（+35pp），Context RAG对多轮追问贡献最大（+27pp）。

📌 本文要点回顾

  1. RAG是NL2SQL准确率从60%→95%的核心技术，本质是"在正确时间注入正确知识"
  2. Schema RAG（+10%）：在几百张表中精准定位相关表和字段，多路召回+关联扩展
  3. Knowledge RAG（+12%）：业务术语、指标口径、默认规则、维度编码------让AI"懂业务"
  4. Few-shot RAG（+8%）：相似问题的正确SQL示例，让AI学会"你的写法"
  5. Context RAG（+5%，多轮+27%）：指代消解、省略补全、修改应用------让多轮对话自然流畅
  6. 四维协同的关键是Token预算管理：4K Token内精准注入，不多不少

❓ FAQ

Q1：RAG的知识库需要人工维护吗？成本高不高？

A：初始建设需要人工投入（Schema描述、术语定义、口径规范），但后续运营主要靠AI自动化：①从用户查询日志自动挖掘新术语；②从错误case自动补充知识；③Schema变更时自动更新索引。鲲溟智能提供知识库管理工具，数据分析师即可完成日常维护，无需专业AI工程师。

Q2：不同行业/企业的RAG知识库差异大吗？

A：Schema RAG完全不同（每家企业数据库不同），Knowledge RAG部分通用（行业术语可复用）+部分定制（企业口径需定制），Few-shot RAG完全定制（每家SQL风格不同）。鲲溟智能预置了行业通用知识（汽车56条/金融48条/零售38条），企业只需补充自身特有的口径和规则。

Q3：RAG检索的延迟会影响用户体验吗？

A：不会。四维RAG检索总耗时控制在200ms以内（Schema 50ms + Knowledge 60ms + Few-shot 50ms + Context 40ms），加上LLM生成时间（1-3秒），用户感知总响应时间<5秒。检索使用向量数据库（Milvus/Qdrant）+缓存机制，高频查询直接命中缓存（<10ms）。

💬 互动话题：你在做NL2SQL或Text-to-SQL相关的工作吗？你在实践中遇到的最大挑战是什么------是Schema匹配、业务理解还是多轮对话？

欢迎在评论区分享你的NL2SQL技术实践！

本文作者：鲲溟智能 · 产品与解决方案部

鲲溟智能官网：www.trionesagent.com

下一篇预告：【AI问数·技术】多Agent协同架构：查询规划/SQL生成/洞察分析/报告生成

热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点03微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新042026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？05历年考研数学一、数学二、数学三真题试卷及答案PDF06Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费07AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路08VSCode+CodeX扩展，无法启动092026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片10如何新建文件夹？ 电脑新建文件夹的4种方法