引言
大家好，感谢大家一直以来对数睿通产品的关注与支持。目前我们主要维护两条产品线：数睿通 2.0 数据中台和数睿通智库，两者都在持续迭代和完善。
这次想和大家介绍的，是数睿通智库平台中的一个新能力：智能问数。它要解决的，是一个很多企业都很熟悉、但真正落地并不简单的问题：能不能让业务人员直接用自然语言提问，让系统自己理解数据、生成查询，并给出可信的分析结果？
如果企业已经在数睿通 2.0 数据中台里完成了数仓建设和主题数据沉淀，也可以把这些数仓数据维护到数睿通智库的数据源中。这样，智能问数就能基于已经治理过的表、字段和业务口径工作，帮助业务人员更直接地理解数仓数据，而不是每次都依赖技术同事手写 SQL 或解释表结构。
很多系统都说自己支持“用一句话查数据”。
但真正把这件事放到企业环境里，会发现它远比演示视频复杂：用户问的是业务语言，数据库里存的是表、字段、类型、方言和历史包袱；用户要的是一个结论，系统却必须先判断数据范围、生成 SQL、选择执行器、控制返回行数、解释结果，还要在出错时把问题讲清楚。
更难的是，企业数据不是一个玩具库。它可能分布在 MySQL、PostgreSQL、Oracle、SQL Server、达梦、人大金仓、ClickHouse、StarRocks 等不同系统里；有的表有清晰注释，有的字段只有内部缩写。正常情况下，业务问数更多还是围绕一个已经治理好的数仓或业务库展开，跨库分析并不是最高频的日常动作；但平台仍然需要保留跨源能力，用来处理少数确实需要联动多个系统的数据问题。一个看起来很自然的问题，背后往往是一条复杂的数据理解链路。
数睿通智库的智能问数，就是为这个场景设计的。
它不是把大模型简单接到数据库上，也不是让用户自己写提示词、自己猜表名、自己复制 SQL。它更像一个具备数据边界意识的分析工作台：先把可用数据范围固定下来，再让模型在可控上下文中理解问题、生成 SQL、执行查询、解释结果，并在需要时自动把结果转成图表。
从一个问题开始：业务人员真正想要的不是 SQL
假设运营同事问：
最近 30 天每天的订单数量和成交金额趋势怎么样？有没有异常波动？
这句话在人听来很简单，但系统要回答它，至少要完成几件事：
- 明确“订单”相关的数据表在哪里。
- 知道哪些字段表示下单时间、订单状态、成交金额。
- 判断“最近 30 天”应该如何写成对应数据库方言。
- 生成 SQL，并避免扫出过大的结果集。
- 按会话配置决定：只展示 SQL、等待用户确认执行，还是自动执行。
- 执行后把结果转成表格、摘要，必要时生成趋势图。
- 如果用户继续追问“那华东区域呢”，还要知道这不是一个孤立问题，而是上一轮分析的延伸。
这就是智能问数的核心价值：它把“自然语言 -> 数据上下文 -> SQL -> 执行 -> 解释 -> 可视化 -> 追问”的链路串成一个产品能力，而不是只做其中某一个环节。
它首先是 Text-to-SQL，但不止于 Text-to-SQL
智能问数最直观的能力，是 Text-to-SQL。
用户用自然语言提出问题，系统自动理解分析意图，结合当前会话的数据表、字段、注释、数据库类型和执行器约束，生成对应数据库可执行的 SQL。它不是简单把一句话翻译成查询语句，而是在生成 SQL 时同步考虑数据源范围、字段语义、SQL 方言、查询模式、返回行数、是否跨源、是否需要使用 Trino 去限定表名等上下文。
这意味着，用户不需要知道订单表到底叫 order_info 还是 biz_order，也不需要记住金额字段是 amount、pay_amount 还是 total_fee。只要数据源元数据足够清晰，模型就能在系统整理过的上下文里完成语义对齐。
但如果只做到 Text-to-SQL，企业问数仍然是不完整的。
因为用户真正要的通常不是“一段 SQL”，而是：
- SQL 为什么这么写。
- 这条 SQL 是否可以执行。
- 执行前是否需要人工确认。
- 执行结果是否正常。
- 查询结果能不能被解释、被追问、被可视化。
- 出错时能不能知道是字段、方言、权限、执行器还是数据源配置的问题。
所以智能问数把 Text-to-SQL 放进了一条更完整的链路中：先生成可解释的 SQL 候选，再按会话策略确认或自动执行，随后返回结果预览、执行耗时、结果摘要，并支持继续生成图表和追问分析。
从这个角度看，它不是一个“SQL 生成器”，而是一个面向业务分析的自然语言数据执行系统。
使用方式：先圈定数据，再开始问
智能问数采用“会话制”的使用方式。每一次分析不是直接对全库开放，而是先创建一个问数会话。
在创建会话时，用户可以配置：
- 会话名称：例如“订单经营分析”“客户增长看板”“财务收入核对”。
- 对话模型：选择当前要使用的大语言模型。
- 执行器：支持 JDBC 单数据源执行，也支持 TRINO 跨数据源查询。
- 查询模式：只生成 SQL、确认后执行、自动执行。
- 最大返回行数：限制结果规模，避免一次查询拖垮数据库或把无意义的大表直接返回给前端。
- 数据源与数据表：选择本次分析允许使用的数据范围，可按表精确选择，也可以对筛选后的表批量全选、反选。
- 会话说明：补充业务背景，让后续使用更清晰。
这个设计很关键。
很多自然语言查数系统的问题，不是模型不会生成 SQL，而是“它不知道自己不该查什么”。智能问数把权限、范围、上下文和执行策略前置到会话中，让模型只在用户明确选择的数据边界内工作。
当然，“明确选择”不等于只能选几张表。系统支持用户按数据源、表名、表注释进行检索，也支持对当前筛选结果一键全选或反选。对于一个结构清晰的业务库，用户可以选择少量核心表做精确分析；对于需要探索的整库场景，也可以把几百张表纳入会话范围，让系统在更大的元数据空间里完成表识别、字段匹配和 SQL 生成。
这里的关键在于上下文控制。系统不会把混乱的数据库连接信息直接丢给模型，而是基于已同步的元数据、用户选择的范围、表字段注释、执行器要求和 token 预算进行组织。创建会话时，前端会提示上下文 token 规模；后端也会围绕会话上下文构造更适合模型理解的结构化提示。这样即使面对整库级分析、几百张表的元数据，也能保持可控、可解释、可继续优化。
用户进入会话后，右侧会展示当前会话上下文，包括已选择的数据源、表、字段和注释。中间是对话区，左侧是会话列表。整个体验更接近数据分析工作台，而不是一个孤立的聊天框。
数据源不是“连上就完了”：先建立可理解的元数据层
智能问数真正工作的起点，不是用户输入问题，而是数据源元数据同步。
系统支持对数据源进行连接测试、元数据同步、表字段浏览，并把数据库里的表、字段、类型、注释、schema、catalog 等信息沉淀下来。对模型来说，这些内容就是“可理解的数据地图”。
对于已经使用数睿通 2.0 数据中台的团队来说，一个很自然的路径是：先在数据中台完成数据接入、清洗、建模和数仓分层，再把面向业务分析的主题库、宽表或指标结果表维护到智库数据源中。这样智能问数面对的不是一堆原始业务表，而是一批经过治理、口径更稳定、注释更清晰的数据资产，业务人员也更容易把自然语言问题和数仓中的指标、维度、主题域对应起来。
这里有一个容易被低估的难点：不同数据库的元数据行为差异很大。
同样是“列出表和字段”，MySQL、PostgreSQL、Oracle、SQL Server、达梦、人大金仓、ClickHouse、StarRocks 的 catalog、schema、大小写、注释读取方式、驱动能力都有差别。如果只用一套粗糙的 JDBC 逻辑，很快就会在真实环境里遇到兼容问题。
智能问数在设计上把元数据扫描抽象成数据库适配层：统一入口负责选择 Provider、建立连接和包装异常；具体数据库差异由各自的元数据 Provider 处理。这样既保留了统一体验，也能针对国产数据库、数仓数据库、传统关系库做细粒度适配。
最终用户看到的只是“选择数据源、同步元数据、选择表字段”，但背后其实是在把异构数据库整理成一份模型可消费、执行器可验证、前端可展示的结构化上下文。
这也是为什么智能问数可以支持更大范围的数据分析。它不是临时从数据库里猜表，而是先把整库元数据变成可筛选、可选择、可压缩、可注入的分析上下文。无论是几张核心业务表，还是几百张表组成的完整业务库，都可以通过“元数据治理 + 会话范围选择 + 上下文预算控制”的方式进入问数流程。
三种查询模式：从谨慎验证到自动分析
智能问数提供三种查询模式，适合不同的数据安全与效率要求。
只生成 SQL
适合早期验证、敏感库、生产库谨慎使用等场景。系统只根据问题生成 SQL，并说明它的用途，不直接执行。
这类模式适合数据管理员、开发人员、数仓工程师使用：他们可以快速获得一个高质量 SQL 草稿，再结合实际情况调整。
确认后执行
这是更平衡的模式。
模型先生成 SQL，用户确认无误后点击执行。执行成功后，系统展示返回行数、耗时、结果预览和结果摘要。对于大多数企业场景，这是一个比较安全的默认选择：既减少手写 SQL 成本，又保留人对执行动作的控制。
自动执行
当会话范围清晰、数据源稳定、问题相对规范时，可以开启自动执行。系统会在生成 SQL 后自动进入执行流程，并把结果直接返回。
自动执行不是“放任模型随便跑”。它仍然受会话数据范围、最大返回行数、执行器选择、SQL 解析和执行策略约束。对高频运营分析、指标查询、临时报表类场景来说，这能显著缩短从问题到答案的路径。
JDBC 与 TRINO：单库效率和跨源能力同时保留
企业问数的一个典型矛盾是：大多数问题其实只查一个数据源，但少数关键问题又必须跨库。
这也是智能问数在设计上刻意区分执行路径的原因。正常业务分析里，尤其是基于数仓、主题库、指标宽表的问数，大多数查询都应该尽量保持在单一数据源内完成。这样路径更短，性能更稳定，SQL 方言也更清晰。跨库不是常态化依赖，而是当数据确实分散在多个系统、又暂时没有在数仓侧完成汇聚时的一种补充能力。
如果所有查询都走跨源引擎，简单问题会变重；如果只支持单库直连，跨系统分析又做不了。智能问数同时支持 JDBC 和 TRINO 两类执行器，就是为了平衡这个矛盾。
JDBC 更适合单数据源查询。它直接使用目标数据库的原生方言，路径短、成本低、语义也更贴近数据库自身能力。比如只查数据中台沉淀出来的订单主题库、客户宽表或财务指标表，优先走 JDBC 会更自然。
TRINO 更适合跨数据源分析。当问题需要把多个数据库的数据放在一起关联，系统会要求使用 catalog.schema.table 这样的全限定表名，确保跨源查询可以被正确路由。
更进一步，系统允许在一个会话中同时启用 JDBC 和 TRINO。这样模型在生成 SQL 时会根据问题意图选择更合适的执行路径：单数据源问题优先保持轻量，跨数据源问题再切到 TRINO。
这听起来只是一个选项，实际却涉及一整套判断逻辑：会话选择了哪些数据源、SQL 命中了哪些表、这些表是否配置了 Trino catalog、当前查询是否跨库、JDBC 能不能明确定位到单一数据源。只有把这些边界判断清楚，才能让“自然语言查数”不变成“自然语言撞库”。
会话记忆：让追问真的像追问
智能问数不是一次性问答。
在真实分析过程中，用户经常会连续追问：
- “按区域再拆一下。”
- “只看已支付订单。”
- “把昨天的数据也加上。”
- “这个异常是哪个渠道导致的？”
如果每一轮都当成新问题，模型很容易丢失上下文。智能问数引入会话记忆，让模型能结合历史问题、历史答案和当前数据范围理解追问。
同时，系统也提供了“清除记忆”和“清空会话”两个动作。前者保留历史消息，但后续追问不再引用旧记忆；后者清空消息并重置会话分析过程。
这里还有一个细节：当会话上下文变长时，系统会进行记忆压缩。用户在界面上能看到压缩提示，知道系统正在处理长上下文，而不是卡住或无响应。
这类设计看似不起眼，但对长期使用非常重要。因为问数不是做一次漂亮演示，而是要在真实业务里反复问、连续问、带着上下文问。
流式响应：让分析过程不再像“黑盒等待”
智能问数的问答和 SQL 执行都支持流式输出。
用户发送问题后，不需要盯着空白页面等待完整结果返回。系统会随着模型分析逐步输出内容；执行 SQL 后，分析解释也可以继续流式生成。前端对流式内容做了批量刷新与缓存优化，避免长会话、大历史、多 SQL 候选时页面变得卡顿。
这背后体现的是一个产品判断：企业 AI 系统不应该只追求“最后给答案”，还要让用户感受到过程是活的、可等待的、可理解的。
尤其是数据分析场景，等待时间很难完全消失。连接数据库、生成 SQL、执行查询、总结结果都需要时间。流式体验至少让用户知道系统正在推进，而不是让人怀疑请求已经失败。
SQL 候选、执行结果与错误反馈：把模型输出变成可操作对象
智能问数不会只把 SQL 混在一段文本里返回。
系统会把 SQL 作为结构化候选展示：标题、用途、方言、SQL 内容、执行状态、执行信息、结果预览、错误提示都会被分块呈现。用户可以清楚地看到：
- 这条 SQL 是做什么的。
- 当前使用的 SQL 方言是什么。
- 是否已经执行。
- 执行成功返回多少行、耗时多久。
- 执行失败时错误是什么。
这也是“难复刻”的地方之一。
很多问数原型只做到“让模型吐一段 SQL”。但真正可用的产品，需要把 SQL 从文本变成对象，变成一个可以确认、执行、重试、修复、展示、可视化、持久化的业务实体。只有这样，前端才能给出清晰交互，后端才能追踪状态，用户也才能建立信任。
从表格到图表：让结果更接近分析，而不是查询日志
执行成功后，系统不仅展示结果表格，还支持基于当前结果生成图表。
目前图表能力覆盖常见分析表达：
- 指标卡：适合单个或少量核心指标。
- 折线图：适合趋势变化。
- 柱状图：适合分类对比。
- 饼图：适合占比结构。
图表不是固定模板，而是根据查询结果和模型生成的图表规格进行渲染。系统会判断当前结果是否适合可视化，并给出可视化标题、字段映射和图表类型。前端再基于 ECharts 渲染成图形。
这让智能问数从“查出一张表”向“给出一个分析视图”迈了一步。
对业务用户来说，他们并不总是想看原始行数据。很多时候，他们真正想要的是趋势、对比、异常、占比和结论。图表能力让问数结果更接近业务分析的终态。
设计思路：把不可控的大模型放进可控的数据工程框架
智能问数的设计核心，可以概括成一句话：
不让大模型直接“碰数据库”，而是让它在被治理过的数据上下文中完成分析任务。
具体来说，它把整个链路拆成几层。
第一层：数据接入与元数据治理
数据源先经过连接测试、元数据同步和表字段沉淀。不同数据库通过适配层处理差异，最终形成统一的表字段上下文。
这一步决定了模型“看见什么”。
第二层：会话级数据边界
用户创建会话时选择数据源和表，系统把可分析范围固定下来。模型不会面对全库，而是面对一个经过业务选择的上下文集合。
这一步决定了模型“允许使用什么”。
这里既可以做小范围精确分析，也可以做整库级分析。用户可以手动勾选关键表，也可以检索后全选，把一个业务域内的大量表统一纳入会话。系统通过上下文 token 估算、表字段结构化组织、执行器约束和长会话记忆压缩，让大范围元数据不至于变成无序噪声。
第三层：提示词与执行器协同
系统根据会话执行器、数据库类型、表字段、Trino 映射、查询模式等信息构造分析约束，引导模型生成可执行、可解释、符合当前场景的 SQL。
这一步决定了模型“应该怎么生成”。
第四层：SQL 结构化与执行规划
模型输出不会直接结束，而是被整理成 SQL 候选。系统再根据 SQL 命中的表、当前执行器配置和数据源范围选择执行路径。
这一步决定了 SQL “能不能执行、由谁执行”。
第五层：结果解释与可视化
SQL 执行后，系统把结果摘要、预览数据、执行状态和可视化规格统一回写到消息中，让一次问数具备完整闭环。
这一步决定了用户“能不能看懂并继续追问”。
为什么它不是一个简单 Prompt 就能复刻
如果只看最终交互，智能问数像是“问一句话，出一个答案”。但真正难的部分藏在交互背后。
第一，数据库方言差异很难靠提示词完全解决。日期函数、分页语法、schema 规则、大小写、字段类型、关键字转义，不同数据库都有差别。没有元数据层和执行层兜底，模型生成得再漂亮，也可能无法运行。
第二，跨源分析不是把多个表名放进提示词就行。跨源查询需要 catalog、schema、执行器、路由、连接配置协同；单库查询和跨库查询还要能自动区分，否则简单问题也会被复杂化。
第三，大规模上下文不是“越多越好”。几百张表放进同一个分析范围时，真正难的是让模型既看得到全局，又不会被无关表干扰。智能问数通过表选择、批量全选、上下文 token 估算、元数据结构化和会话级约束，把整库分析变成可控能力，而不是把所有表名粗暴塞进提示词。
第四，企业场景必须有边界。哪些表能查、最多返回多少行、是否允许自动执行、历史上下文是否继续引用，这些都不是模型自己决定的，而是产品和工程共同定义的控制面。
第五，结果必须可验证。用户要看到 SQL、执行状态、耗时、行数、结果预览、错误信息，才能判断系统是不是可信。只给一个自然语言结论，在数据场景里是不够的。
第六，长会话体验需要工程优化。消息分页、流式刷新、SQL 候选缓存、图表渲染、记忆压缩，这些都不是演示时最显眼的能力，却决定了系统能不能长期使用。
所以，智能问数真正做的是一件复合型工程：大模型能力、数据库工程、数据治理、执行安全、前端交互和企业级权限边界必须同时成立。
一个推荐的落地路径
如果你准备在自己的团队里试用智能问数，可以按这个路径推进：
- 先选择一个边界清晰的业务域，例如订单、客户、财务收入、项目进度。
- 如果已经通过数睿通 2.0 数据中台建设了数仓，优先选择面向业务分析的主题库、宽表或指标结果表。
- 在数据源管理中配置数据库连接，并完成连接测试。
- 同步元数据，检查表注释和字段注释是否足够清晰。
- 创建一个问数会话，只选择与该业务域相关的数据表。
- 初期使用“只生成 SQL”或“确认后执行”，验证 SQL 质量。
- 稳定后，对高频问题开启自动执行。
- 对常见指标类问题，结合图表能力形成轻量分析看板。
这个路径的好处是：先让系统在一个可信范围内跑通，再逐步扩大数据范围和自动化程度。
智能问数不是要求企业一次性把所有数据库都开放给 AI。相反，它更建议从已经治理好的数仓数据开始，让业务人员先围绕稳定口径提问、理解和验证。后续如果确实存在跨系统联查需求，再按场景引入 TRINO 跨源能力。小范围分析追求精准，整库分析追求探索，跨库分析解决补充问题，三者都能通过表选择、全选和上下文控制进入同一套问数链路。
写在最后：让每一次提问都沉淀成数据理解能力
智能问数的意义，不只是“少写几句 SQL”。
它更像是在企业内部建立一层新的数据交互方式：业务人员用自然语言表达意图，系统把意图转成可执行的数据动作；技术人员不再被大量临时取数打断，而是把数据结构、口径和边界沉淀进平台；管理者获得的不只是结果，还有一条可追踪、可解释、可复用的分析链路。
当自然语言、数据上下文、执行引擎和可视化结果被真正串起来，企业的数据资产才开始从“存得住”走向“问得出、看得懂、用得上”。
这也是数睿通智库智能问数想解决的问题：不是让 AI 看起来会查数，而是让它在真实的数据系统里，稳定地完成一次又一次的可信分析。
想要获取数睿通智库平台源码，Docker部署包，部署文档等资料的朋友可以关注公众号 螺旋编程极客 付费加入 极客AI 知识星球获取，加入星球通过填写商用授权表可获取商用授权资格，对于目前实现的功能来说，价格可以说是非常便宜了，平台会一直更新迭代，再次感谢大家的关注与支持。
