构建一个基于 LLM 的 Chat-BI 分析助手，要实现 SQL 准确率和自助分析效率，不能仅靠简单的 Prompt 工程，必须构建一套包含语义理解、知识检索、安全管控、反馈迭代的完整工程化闭环。
以下是详细的实现流程架构，分为五个核心阶段：
一、总体架构设计
在进入流程前，需明确核心模块的交互关系：
- 用户层：自然语言提问。
- 大脑层 (LLM + RAG)：意图识别、语义解析、SQL 生成。
- 知识层 (语义层 + 向量库)：存储指标定义、表结构、历史优质 SQL。
- 执行层 (安全沙箱)：SQL 校验、权限控制、查询执行。
- 反馈层：点赞/点踩、修正记录、模型微调。
二、详细实现流程 (5 个阶段)
阶段 1：数据资产与语义层构建 (基础建设)
目标：解决“业务术语”与“物理字段”的映射问题，这是提升准确率的关键。
元数据同步：
自动同步数仓（Hive/MaxCompute/Doris 等）的表结构、字段注释、主外键关系。
提取字段统计信息（如：status 字段的枚举值分布），帮助 LLM 理解数据内容。
语义层建模 (Semantic Layer)：
- 指标定义：将业务术语（如“毛利率”、“活跃用户”）注册为逻辑指标，绑定计算逻辑（如 sum(profit)/sum(revenue)）。
- 维度注册：明确时间、地区、品类等维度的物理映射。
- 同义词库：为关键字段配置业务别名（例如：gmt_create 别名包含“下单时间”、“创建日期”）。
-
知识向量化 (RAG 准备)：
将表结构、指标定义、历史高频 SQL、业务文档切片。
存入向量数据库（如 Milvus/ES），建立索引，用于后续检索增强。
阶段 2：意图识别与上下文增强 (理解用户)
目标：精准理解用户想要什么，减少歧义。
问题预处理：
拼写纠错、指代消解（如将“上个月”转换为具体日期范围 2023-10-01 to 2023-10-31）。
意图分类：
- 判断用户是查数（Text-to-SQL）、问知（RAG 检索文档）还是诊断（归因分析）。
如果是查数，识别涉及的业务域（如：是查“销售域”还是“用户域”）。 -
动态上下文检索 (RAG Core)：
Schema Linking：根据问题，从向量库中检索最相关的 3-5 张表及其字段（避免将所有表结构塞入 Prompt，超出 Token 限制且干扰模型）。
Few-Shot 检索：检索历史库中相似问题的优质 SQL 作为示例（Example），放入 Prompt 中引导模型。
语义知识注入：检索相关的指标计算逻辑，防止模型瞎编公式。
阶段 3：Text-to-SQL 引擎生成 (核心大脑)
目标：生成可执行且逻辑正确的 SQL。
Prompt 工程构建：
采用 CoT (Chain of Thought) 策略：要求模型先输出思考过程（“用户想查... 涉及表... 关联条件是..."），再输出 SQL。
注入约束：强制要求使用语义层定义的指标，禁止 SELECT *，限制 LIMIT 条数。
SQL 生成：
调用 LLM 生成初步 SQL。
自我修正 (Self-Correction)：
- 语法检查：使用 SQL Parser 校验语法错误，若有错，将错误信息回传给 LLM 重试。
- 执行反馈：在沙箱中 EXPLAIN 或试运行，若报错（如字段不存在），将错误日志反馈给 LLM 进行修正（通常迭代 1-2 次可大幅提升准确率）。
- 逻辑校验：检查是否包含敏感操作（如 DROP, UPDATE, DELETE），检查是否涉及全表扫描。
阶段 4：安全沙箱与执行 (风险控制)
目标：确保数据不泄露、数据库不崩溃。
权限隔离 (RBAC)：
Chat-BI 使用只读账号连接数据库。
根据提问用户的身份，动态注入行级权限过滤（例如：上海区的经理只能查 region='Shanghai' 的数据）。
资源熔断：
设置查询超时时间（如 30 秒）。
设置扫描行数上限（如 100 万行），防止大表拖垮集群。
数据脱敏：
对手机号、身份证等敏感字段在结果返回前进行掩码处理。
结果执行：
在沙箱环境中执行最终 SQL，获取结果集。
阶段 5：可视化与反馈迭代 (体验与优化)
目标：提升效率，形成闭环优化。
智能可视化：
根据数据结果类型（趋势、占比、对比），自动推荐图表（折线图、饼图、柱状图）。
生成分析结论：LLM 根据查询结果，用自然语言总结核心洞察（如“本月销售额环比增长 15%"）。
人机协同反馈 (Human-in-the-Loop)：
点赞/点踩：用户对结果反馈。
SQL 修正：允许高级用户在界面上直接修改生成的 SQL，修改后的“问题 -SQL"对存入黄金数据集。
模型持续优化：
- SFT 微调：定期使用积累的黄金数据集对基座模型进行微调，提升特定业务场景的准确率。
- Bad Case 分析：定期分析准确率未达标的案例，补充语义层定义或优化 Prompt。
