现在再看，用 Dify 加知识库做一个问数助手，好像已经不是什么新鲜事了。但在我们刚开始接触 Agent、Embedding 和向量检索时，整个团队都在摸索。
2024 年下半年，公司开始做这方面的技术储备。当时主要还是自己写代码验证，开发难度比较大，效果也一般。到 2025 年 4 月左右，我们调研和试用了 Dify、RAGFlow、MaxKB、n8n 等产品，最后选择了 Dify，智能问数才慢慢从技术验证变成一个真正上线的功能。
这次经历对我最大的影响，不是学会了怎么配置一个 Dify 应用，而是让我更确定了一件事：AI 看起来很新，真正决定它能不能落地的，还是原来那套系统做得怎么样。
为什么要做智能问数
原来的平台并不是查不到数据。我们已经有基于 Solr、Elasticsearch 一类全文检索的查询能力，可以做关键词匹配，再通过分面逐步筛选。
问题是，这套方式更适合熟悉统计业务和系统操作的人。领导临时想看一个数，通常不会愿意先进入数据治理平台，再一层层选择指标、地区和报告期。以前遇到这种情况，往往还是找熟悉数据的科室人员，让他们查完再整理出来。
实际场景可能很突然。比如上级临时问到某项数据进度，领导马上要准备汇报。相比提前打印一叠材料，如果能直接在手机或电脑上问一句，系统把数据和基本说明整理好，显然方便得多。
科室人员也有类似需求。他们写统计分析文章时，经常要找以前的数据。统计业务中的数据不会因为年份早就失去价值，一项已经核定的数据，多年后仍然可能被拿来做趋势分析和同期比较。所以我们的系统并没有把所谓“历史数据”简单放到一个很少使用的历史库里，而是希望它们一直可以被查到。
AI 接进来之前，数据已经有了底子
智能问数能做起来，并不是大模型把原来杂乱的数据自动整理好了。ISMP 本身就为统计指标、统计分组和宏观数据设计过一套颗粒化的数据模型。
2026 年一季度，广东省地区生产总值为 34950.34 亿元。
这里不只有一个数值。2026 年、一季度、广东省、地区生产总值、亿元，分别描述了报告期、地区、统计指标和计量单位。实际数据还会带上统计分组、来源和报表引用等信息。
我习惯把它理解成“一颗数据”：数值是核心，周围的元数据负责把它完整地描述出来。不同数据可以根据自己的业务含义组合不同的描述维度，不必为每一种情况都预先做一套固定维度的表。
有了这层基础，我们就可以把一颗数据的元数据和值组织成一句相对完整的文本，再交给 Embedding 模型生成向量。用户不需要知道系统中的标准指标名称，也有机会通过自然语言找到接近的数据。
当时接入智能问数的数据主要有三类。第一类是宏观数据，也就是经过汇总、计算后形成的统计数据；第二类是企业和项目等微观明细数据，主要来自直报平台的数据回流；第三类是指标和统计分组的解释信息，可以做成一个统计百科。
实际使用中，宏观数据是问数的重点。统计百科更多是能力展示，内部人员本来就比较熟悉这些概念。如果以后把能力开放给社会公众，这部分知识可能会更有用。微观数据则完全不同，它数据量大，还有严格的保密要求，不可能简单地全部放进知识库。
一次问数是怎么完成的
以宏观数据查询为例，用户的问题先由 Agent 判断和路由，再从问题中拆出接近统计业务元数据的关键词，到宏观知识库检索。
如果没有命中，模型会继续追问，让用户补充更准确的指标、口径或时间；命中后，再通过 Rerank 对召回结果重新排序，交给大模型组织回答。数据少时直接用一句话说明，数据多时整理成表格，并调用工具生成柱状图、折线图或饼图。
知识库里还保留了数据对应的报表信息，所以回答不只是给出一个数，还能继续生成报表查看和下载入口。用户可以先通过自然语言找到数据，再回到原来的业务报表核对或继续分析。
有些词需要额外处理。例如用户问“广东省最新 GDP”，“最新”不是一个固定报告期。我们给 Agent 配置了时间工具，让它先知道当前时间，再结合已经发布的数据判断应该返回哪个报告期。系统还接了图表工具、报表下载和浏览器打开报表等少量内部能力。
由于项目部署在内网，不能访问互联网，我们没有为了展示效果接入大量外部工具。能开放给 Agent 的能力比较有限，边界也比较清楚。
真正费时间的是调效果
整个过程中最麻烦的并不是把模型接进来，而是怎么让它找对数据。
统计数据对口径很敏感。有时两条数据只差一个字段，Embedding 看起来非常相似，但在统计业务中已经是完全不同的两个数。实际调试时，最常见的问题要么是没有命中，要么是一下召回太多相似结果。
Rerank 也不是万能的。它只能把已经召回的数据重新排序。如果第一轮检索根本没有找到正确数据，后面再怎么重排也没有用。
我们试过很多调整办法：改变元数据的组合顺序，强化统计指标和口径这些关键字段；把“元数据 + 值”拼成一句话存进知识库；也试过更接近传统库表的组织方式。相似度阈值、Top K、Rerank、提示词、温度等参数都反复调过。
模型也是一个现实限制。我们测试过 Qwen、GLM、MiniMax 等多种国内模型，最后主要选择 Qwen3 系列的小模型和 Embedding、Rerank 模型。除了提示词，还要配合算力平台人员调整显存使用和推理配置。单看任何一项都不复杂，但它们叠在一起时，就只能一点点试。
不同组织方式也各有问题。把一颗数据写成完整句子，更接近用户的自然语言；按结构化字段保存，又更容易保留口径边界。召回数量少了容易漏，召回多了又会把一堆相似口径交给模型。
所以我们没有要求 Agent 在任何情况下都必须给出答案。问题不够明确时，让它继续追问用户，通常比从几个相似结果里猜一个更可靠。
RAG 适合什么，不适合什么
做完这个功能后，我仍然认为宏观数据适合 RAG。领导或业务人员通常知道自己关心什么，但未必知道系统里的标准指标名称。向量检索正好可以在自然语言和统计元数据之间搭一座桥。
但 RAG 更适合帮助用户“找到可能相关的数据”，不能代替统计口径本身。
如果现在重新设计，我会保留宏观数据的语义检索，同时增加更明确的维度权重。比如统计指标最重要，口径其次，地区和报告期也必须参与约束。Dify 当时提供的通用检索配置，很难把这种统计业务中的字段优先级完全表达出来，这部分可能需要换一条更可控的技术路线。
微观数据则应该分开处理。企业和项目明细量大，而且不能出错，也不能越权访问。查询这类真实明细、聚合或汇总数据，更适合通过权限控制后的固定接口，或者受到严格约束的 Text-to-SQL 来完成，不适合把所有明细都放进向量库。
这并不是说 RAG 和 Text-to-SQL 谁更先进，而是它们解决的问题不同。一个擅长从不够标准的问题里发现相关内容，另一个负责返回不能出错的精确结果。
上线前，我们是人工一条条核对的
为了避免模型“看起来回答得很好，实际在胡说”，团队在上线前单独搭了一套 Dify 问数测试环境。同事手工整理一批测试数据导入知识库，再准备固定问题逐条测试。
返回结果需要和原始数据或报表人工核对，看看指标、口径、报告期和单位有没有选错，也要检查模型有没有在数据之外自行发挥。测试环境确认没有明显问题后，才把 Agent 工作流和提示词迁移到现场。
系统中也保留了“有用/无用”的反馈入口。目前它主要负责记录，还没有形成自动学习。原来的规划是先由人工查看这些反馈，再回来调整数据描述和检索参数；如果以后积累了足够多的标注，也可以把一部分稳定问题沉淀成可以复用的结果。
这一点现在回头看也应该说清楚：记录用户反馈不等于系统已经会自我学习。只有这些记录真正进入人工调优、训练或检索策略更新，反馈闭环才算完成。
现在回头看
这个功能后来正式上线使用，也得到了领导的认可。它确实让管理人员和科室人员多了一个更直接的查数入口，不必先学会怎么使用整套数据治理平台。
现在站在 2026 年回头看，它并不复杂，也有不少不完善的地方。统计口径的权重还可以做得更细，模型受到现场算力限制，用户反馈还没有形成真正的优化闭环，微观数据的精确查询也需要继续完善。
但对我来说，这次经历仍然很宝贵。一开始大家都不懂，只能找资料、请教有经验的人、了解行业里的新做法，再一起试模型、调参数、对接算力平台，最后把功能做出来并上线。很多东西今天看起来很简单，是因为已经有人把路走过了；亲自经历一次从技术储备到现场落地，得到的认识还是不一样。
我最后留下的结论也很简单：
AI 的高大上场景，背后还是取决于系统做得好不好。架构能力和数据治理是基本功，AI 可以锦上添花，但不能雪中送炭。
如果前面没有把统计指标、分组、地区、报告期和报表引用这些信息整理好，大模型面对的仍然只是一堆说不清楚的数据。正因为底层系统先把数据组织好了，智能问数才有机会成为一个真正能用的入口。