ChatBI 实体标准查询名优化实战：如何将准确率从 80% 提升到 90%

聊聊ChatBI查询准确率从80%拉到90%以上这事儿——我们是怎么靠一套三层混合架构搞定的。

先说几个核心判断：这绝不是堆数据、穷举别名就能解决的问题。恰恰相反，真正有效的思路是放弃穷举，用分层的方式去化解那些看似无解的维护成本和准确率难题。

一、痛点：维护成本高、准确率低

先聊聊系统上线后遇到的那些坑。ChatBI 智能问答系统跑起来之后，有三个问题不解决，根本没法用。

1.1 数据化的痛点

举个例子就明白了。汽车行业里，集团名称就有70多个，车型200多个，品牌50多个。每个实体平均要维护3到5个别名，加起来就是1000多个映射关系。更要命的是，之前把这些映射全部硬塞进 LLM 的 Prompt 里——结果 Prompt 长度直接飙到5000字以上，Token 消耗巨大，而且每次新增一个车型，改 Prompt、重新测试、部署，没有30分钟下不来。

初始准确率只有80%。也就是说，每查5次就有1次失败。失败的案例特别典型：用户输入"byd"，系统不认识，因为 Prompt 里没穷举到这个写法；输入"传祺向往 S7"，系统只识别了"S7"，别名组合没覆盖全；还有更夸张的，有人说"迪子"，系统完全蒙圈——俚语别名根本没在词库里。

新车型上市，改代码或改 Prompt；新别名出现，重新部署；跨表查询时，同一个别名在不同表中还可能对应不同的标准名。这架构基本是"一碰就倒"的状态。

1.2 量化的业务影响

对用户体验来说，每天大约有15%到20%的查询请求，都以失败告终。运维那边，每周得花2到3小时去维护别名映射。业务方看到这种数据，脸色当然不好看。

二、效果：准确率提升至95%，维护成本降低90%

整个优化过程大概用了1个月时间。参考了不少行业里 N2SQL 产品的解题思路，最后在 Dify 系统上，通过别名配置知识库优化配合代码提取，把查询准确性、维护难度和响应时间三个指标全部拉了上去。

2.1 核心指标对比

指标	优化前	优化后	提升
准确率	80%	90%+	+10%
Prompt 长度	~5000 字	~2500 字	-50%
Token 消耗	高	中	-30%
新增车型耗时	30 分钟	<1 分钟	-90%
维护成本	2-3 小时/周	<30 分钟/周	-80%
响应时间	~2000ms	~1000ms	-1000ms

2.2 实际测试结果

测试了100多个用例，效果很明显：

• ✅ "迪子2025年8月销量" → 正确识别为"比亚迪汽车25年8月的销量"
• ✅ "changan 25年8月销量" → 正确识别为"长安汽车25年8月的产量"
• ✅ "广汽S7 25年7月销量" → 正确识别为"广汽集团向往S7的批发量"

三、解决方案思路总览

3.1 核心理念：三层混合架构

核心设计理念是"不穷举、分层处理、智能匹配"。看这张流程其实就很清楚：

**用户问题**
    ↓
【第一层】Prompt 约定（10-20 个核心高频词）
    ↓ 100% 准确，零延迟
【第二层】RAG 知识库检索（中低频+长尾情况解决）
    ↓ 语义理解，自动召回
    ↓ 无需穷举，自动处理
标准化问题 → SQL 生成

3.2 技术架构

四、分步解决方案

步骤 1：构建实体别名知识库

1.1 按表分文件策略

每个数据表单独建一个别名知识库文件。按表分文件的好处显而易见：RAG 检索精度更高、噪音更少、易维护易扩展。

文件结构大概是这样：

### 集团：比亚迪汽车
**标准查询名**：比亚迪汽车 
**常见别名**：比亚迪、BYD、byd、迪子 
**所属表**：行业表 
**字段名**：group_name

1.2 知识库配置

在 Dify 里创建知识库时，做了这些配置：

名称：实体别名库_全部
文件：5 个 md 文件（行业表、批发表、终端表、产量表、库存表）
配置：
  检索模式：混合检索
  权重设置：语义 0.7，关键词 0.3
  Top K：3

关键配置说明：Top K 设为3，保证召回精度；混合检索兼顾语义和关键词。

步骤 2：构建实体链接处理器（30 分钟）

2.1 知识检索节点设计

在 Dify 工作流里加上知识检索节点。

2.2 RAG 实体解析（代码节点）

输入变量 arg1 选上一个节点输出的检索结果。代码写得很简洁：

def main(arg1: dict) -> dict:
    return {
        "result": [item["content"] for item in arg1]
    }

输出变量 result，类型选 Array [String]。

步骤 3：修改 AI 生成 SQL 节点（15 分钟）

3.1 简化 Prompt

删除的内容是原来硬编码的别名定义——足足2500字。保留的是核心 SQL 生成规则、指标说明和各报表字段说明（DDL）。

3.2 修改知识检索

直接用变量替换原来 Prompt 里的内容：{{#提取标准查询信息.result#}}。效果立竿见影：Prompt 从5000字减到2500字，Token 消耗降了30%，LLM 理解起来也更清晰。

五、意义和价值

技术价值

——三层混合架构（代码字典+RAG+智能匹配）不需要穷举所有别名，维护成本直接降了90%。

——新增实体只需要加 Markdown 段落，批量导入和更新都支持，跨团队协作也不折腾。

——这套方案能直接迁移到其他 Text-to-SQL 场景，代码节点和知识库管理模式都可以复用。

六、后续优化方向

6.1 短期优化（1-3 个月）

——目标是自动发现并补充新别名，通过分析未匹配词生成补充建议，预期维护成本再降50%。

——智能识别跨表查询，自动选最优表组合，提升复杂查询性能。

——支持语音输入、图表识别，以及自然语言加图表混合查询。

——基于历史查询推荐相关问题，智能补全用户输入，提供优化建议。

——构建实体关系图谱，支持更复杂的语义理解，目标是把准确率拉到99%以上。

七、总结

核心经验

1. 不要试图穷举
   ——只维护高频实体，长尾问题交给 RAG 处理。

2. 分层处理
   ——代码字典 + RAG + 智能匹配，各司其职。

3. 持续优化
   ——监控数据，及时补充知识库。

4. 量化评估
   ——用数据说话，持续改进。