导语“统计华南地区零食销量 TOP3”不懂 SQL、不记表名字段输入大白话就能自动出报表这就是当下火爆的AI 智能问数。很多人好奇机器怎么读懂 “华南”“零食”“销量”自动匹配数据库里region_name、product_name、order_quantity核心答案只有四个字多路召回。今天抛开晦涩算法用业务场景讲透两套检索引擎分工、完整召回全流程。一、先搞懂为什么需要两套检索工具企业数据仓库动辄几十上百张表几百个字段、几十类指标字段叫order_quantity但业务只会说 “销量、件数、购买量”数据库存 “华东 / 华南 / 奥利奥”用户只会口语化描述 “南方区域、饼干零食”直接把全量表结构丢给大模型会超长超限、极易生成错误 SQL幻觉。于是系统设计双引擎并行召回各司其职、互补短板Qdrant 向量数据库语义召回找「字段 / 指标」Elasticsearch (ES) 全文检索关键词召回找「真实筛选值」1. Qdrant听懂你的 “大白话”匹配系统字段语义检索核心能力看意思匹配不卡死文字一模一样先做离线准备把所有字段名、字段描述、别名、指标名称、指标说明通过 Embedding 模型转换成 1024 维数字向量存入 Qdrant。比如region_name描述订单所属大区别名【地区、区域、片区】→ 生成向量order_quantity描述商品购买数量别名【销量、件数】→ 生成向量AOV指标平均订单金额别名【客单价、平均每单收入】→ 生成向量用户提问后流程抽取关键词 “华南、零食、销量”转为向量Qdrant 计算向量相似度找出语义最贴近的字段 / 指标输出结果region_name地区字段、product_name商品字段、order_quantity销量指标。举个通俗例子业务说 “客单价”数据库没有这个字段只有指标 AOV。普通关键词搜索完全匹配不到但向量能识别二者语义一致自动召回 AOV解决 “叫法不一样” 的痛点。2. Elasticsearch (ES)精准锁定数据库真实数据值分词检索核心能力分词匹配实体值防止 AI 瞎编筛选条件Qdrant 只知道 “有地区这个字段”但不知道字段里存了哪些真实数据ES 专门存维度枚举值。离线同步规则只同步维度字段真实取值大区、商品、品类、会员等级每条记录绑定所属字段 ID。ES 存储样例{id:dim_region.region_name.华南,value:华南,column_id:dim_region.region_name}{id:dim_product.product_name.奥利奥巧克力夹心饼干,value:奥利奥巧克力夹心饼干,column_id:dim_product.product_name}用户提问后流程关键词 “华南、零食” 送入 ES 做中文分词检索命中真实维度值华南归属 region_name、奥利奥归属 product_name属于零食品类限制大模型只能使用库里存在的值杜绝WHERE region西部这种不存在的错误过滤条件。两张表分清 Qdrant 和 ES 核心区别维度Qdrant 向量数据库Elasticsearch 全文检索存储内容字段、指标名称 / 描述 / 别名元数据维度真实枚举值华东、奥利奥、VIP匹配逻辑语义相似度同义词、口语都能匹配中文分词关键词匹配精确实体检索解决痛点用户说法≠系统字段名找不到对应表字段用户口语筛选值避免 AI 编造不存在数据产出内容告诉大模型「用哪张表、哪个字段、哪个指标」告诉大模型「这个字段可以填哪些过滤值」二、完整实战演示一句话看懂整条召回链路用户问题统计华南地区零食销量 TOP3 商品步骤 1关键词抽取预处理Jieba 分词过滤虚词提取核心关键词华南、零食、销量步骤 2双引擎并行召回核心多路流程通路 AQdrant 语义召回拿到字段 指标关键词向量入库检索匹配语义相近元数据“华南 / 地区” → 字段dim_region.region_name大区名称“零食 / 商品” → 字段dim_product.product_name、category品类“销量” → 指标order_quantity下单数量输出系统有哪些表、哪些字段可以用来回答这个问题。通路 BES 全文召回拿到真实筛选值关键词分词检索维度取值库“华南” → 命中值华南绑定字段region_name“零食” → 命中奥利奥巧克力夹心饼干、乐事薯片等食品类商品绑定product_name/category输出这些字段里真实存在的筛选内容限制 SQL 过滤条件。步骤 3合并召回信息字段与取值绑定合并服务做关联匹配用column_id把两路结果一一对应字段region_name→ 可用筛选值华南字段product_name→ 可用筛选值奥利奥、乐事薯片指标order_quantity→ 聚合方式SUM 求和同时自动补齐表关联关系fact_order订单表关联地区、商品维度表。步骤 4过滤冗余信息投喂大模型生成 SQL合并后还有多余无关字段LLM 二次精简表和字段最终把「表结构 字段 指标 合法筛选值」全部送入 Prompt大模型生成准确 SQLSELECTr.region_name,p.product_name,SUM(f.order_quantity)AStotal_quantityFROMfact_order fJOINdim_region rONf.region_idr.region_idJOINdim_product pONf.product_idp.categoryWHEREr.region_name华南ANDp.category食品饮料GROUPBYr.region_name,p.product_nameORDERBYtotal_quantityDESCLIMIT3;三、如果只单路召回会出现什么问题场景 1只用 Qdrant不用 ES只知道有region_name字段但不知道字段里有哪些地区。大模型容易凭空生成WHERE region南方片区数据库无匹配数据查询为空。场景 2只用 ES不用 Qdrant只能匹配 “华南” 这个文字但用户说 “大区销量”ES 识别不到 “大区” 对应region_name完全找不到对应字段直接查询失败。场景 3两路分开不合并召回字段和取值脱节模型不知道 “华南” 属于region_name写出错误过滤条件WHERE product_name华南完全逻辑错乱。四、业务价值多路召回为什么是 AI 问数底座大幅降低大模型幻觉只把和问题强相关的表、字段、合法值喂给 LLM上下文精简大幅减少不存在表 / 字段 / 数值的错误 SQL。兼容业务口语化表达业务不用死记字段英文“客单价、片区、拿货量” 这类口语都能通过向量匹配到标准指标。检索性能可控向量、全文检索均为毫秒级响应几百张表也不会出现查询卡顿。扩展性极强新增商品、地区、指标仅同步元数据到 Qdrant、ES无需改动代码自动支持新维度查询。五、写在最后AI 自然问数的核心不是大模型有多聪明而是先靠多路召回精准缩小数据范围再交给模型生成查询语句。Qdrant 负责 “听懂人话找字段”ES 负责 “锁定真实数据防编造”两者配合才能实现普通人一句话自动出数据分析报表。未来不管是零售掌柜、企业 BI、运营数据平台这套「向量 全文混合召回」架构都是自然语言数查的标准底层方案。