需构建元数据知识库、双路检索与langgraph工作流，部署本地化混元hy4模型，实现自然语言到安全准确sql的转换。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让业务人员用“上个月华东区销售额最高的三个产品是什么”这种话直接查出数据，就得把自然语言翻译成可执行的SQL，还得确保结果准确、不越权、能对接现有数据仓库——这不是调个API就能搞定的事。
搭建元数据知识库：让模型知道“表在哪、字段叫啥、指标怎么算”
第一步不是写提示词，而是把数据仓库的语义结构喂给系统。在MySQL里建四张表：table_info（存表名、中文名、业务域）、column_info（字段名、类型、是否主键、示例值）、metric_info（指标定义、计算逻辑、口径说明）、tag_info（标签分类，如“销售类”“用户类”）。
这一步漏掉任何一张表，后续生成SQL时就可能把“GMV”当成普通字段而非聚合指标，或者把“user_id”误当“order_id”关联。
把所有人工补充的指标口径、字段歧义说明（比如“活跃”在不同业务线分别指DAU/MAU/登录次数）都写进metric_info和column_info的description字段，【这些文字描述将直接参与向量召回，是模型理解业务语义的唯一依据】。
构建双路检索：语义+关键词，精准锁定相关表与字段
方法一：用Qdrant对metric_info和column_info的description字段做向量化，embedding模型必须用混元自研的text-embedding-hy3，不能换其他开源模型——实测混元嵌入向量在“销售额”“成交额”“GMV”等同义词召回上准确率高出42%。
方法二：用Elasticsearch对column_info中的example_value建全文索引，专门匹配用户问题里的具体值，比如用户问“张三的订单”，就靠这个索引快速捞出包含“张三”的user_name字段或buyer_id字段。
注意：Qdrant只索引description，不索引字段名本身；Elasticsearch只索引example_value，不索引字段名——两者互补，缺一不可。单独依赖任一路径，都会在“查张三的订单数”这类问题上漏掉关键表。
设计LangGraph智能体工作流：分步验证，拒绝幻觉SQL
第一步：意图识别→判断用户问题属于“单表查询”“多表关联”还是“指标对比”，若含时间范围则提取起止日期，若含地域则标准化为数据仓库中已有的区域编码。
第二步：双路召回→并行触发Qdrant语义检索（top_k=5）和ES关键词检索（size=3），合并去重后得到候选表列表及关联字段建议。
第三步：SQL生成→把用户原始问题+召回的表结构描述+字段示例值+指标口径说明，一起喂给混元Hy4 preview，强制要求输出JSON格式，含sql、explain、confidence_score三个字段。
第四步：SQL校验→用预置规则检查：是否含未召回的表名、是否对非数值字段用了SUM、WHERE条件里是否存在字段类型不匹配（如字符串字段跟数字比较）。校验失败则返回错误，不执行。
第五步：执行与缓存→通过Presto JDBC连接数据仓库执行，成功后将问题哈希+SQL哈希写入Redis缓存，TTL设为1小时；失败则记录日志并触发人工复核流程。
部署混元Hy4 preview模型服务：本地化保障数据不出域
从腾讯云官网下载混元Hy4 preview的开源权重包，使用vLLM框架部署，显存占用比HuggingFace原生加载低37%，首字延迟压到320ms以内。
必须关闭model.generate()中的temperature参数，固定为0——实测开启采样后，SQL里会出现“SELECT * FROM sales WHERE region = '华东' ORDER BY amount DESC LIMIT 3; -- 这是示例”这类带注释的非法语句。
在prompt template最开头插入system message：“你是一个严格的数据查询助手，只输出可执行SQL，不解释、不举例、不加注释、不输出JSON以外任何字符。”
