数据不出域
私有化部署
数据与指标口径都留在企业自己的环境里，适合对数据不出域有要求的政企、金融客户。
数幄智数 · 产品
一个平台
把数据变成能问的答案
建设、沉淀、使用是同一件事的三段，不是三套要分别采购的工具。 数据接进来建成指标资产，文档沉淀成可引用的证据。 最后人和 AI 共用一个提问框，每个答案都带着口径与出处。
- 指标口径统一
- 答案带出处
- 私有化 / SaaS 双形态
one platform
三大能力，一件事
客户买的是「问数有答案」这一个结果。拆成三个产品来卖，只会让人误以为要分别采购、分别实施。
01 · 建设
接入数据，建成指标资产
把分散在各个业务系统里的数据接进来，建成一套全公司共用的指标、维度与模型关系。 AI 会辅助建模，但每一步改动都要人确认后才生效。
- 多源数据接入，为指标建模做准备
- 指标、维度、模型关系统一定义在语义层
- AI 辅助建模，人拍板：未确认的改动不影响任何现有口径
技术细节
- 数据接入按多源方向演进，已开放 MySQL / PostgreSQL，并持续扩展更多数据源类型
- 语义层以模型（Model）、视图（View）、指标立方（Cube）三层组织：模型描述一张业务表的字段与含义，视图把多张表按业务关系拼成可复用的分析对象，指标立方则固化「算什么、怎么算、按什么维度看」
- AI 建模产出的是一份改动清单，人工逐条确认后才写入语义层
02 · 沉淀
把文档变成可引用的证据
制度、流程、合同、说明文档沉淀为可检索、可引用的知识证据。 问知识时，回答会引用真实文档与原文段落，并注明来源。
- 文档与文本沉淀为可检索的知识证据
- 回答引用真实原文段落并注明来源
- 找不到依据时明确说没找到，不做推测性回答
技术细节
- 知识回答与数据回答走同一套追溯机制：数据回到指标口径，知识回到文档原文
- 业务术语与同义词统一登记，让「毛利」「毛利润」「GP」指向同一个口径
03 · 使用
人和 AI，共用一个入口
问数、问知识、出表格、出报告、看板与综合分析，都在同一个提问框里完成。 每个数字都能点开看口径和来源。
- 用大白话问业务数据，支持追问和按维度拆解
- 把多个问数结果组织成图表、报告与看板
- 复合分析拆成多个受控问题，分别取数再汇成结论
技术细节
- 自然语言先归一成受控的语义查询，在已定义的指标口径里取数，不生成任意 SQL
- 取数使用只读账号，并对语句做单语句校验，杜绝写操作与多语句拼接
- 每次取数留有审计记录，可回溯是谁、在什么时间、用哪个指标口径取了哪些数
where ai sits
AI 永远不是数据的主人
AI 只在两处出现：建设端作为助手，改动需人工确认；使用端受既定指标口径约束。数据和口径，始终归属企业。
AI 建议，人工确认
建指标资产时，AI 理解企业数据并给出指标与关系建议，产出一份改动清单——每一条均展示明细，人工逐条确认后生效。
- AI 产出的是改动清单，不是直接写进语义层的结果
- 未确认的改动，不影响任何现有口径
- 确认过程留痕，谁改了什么口径可回溯
安全边界：指标口径就是那条线
AI 在界线之上提问，数据库在界线之下受保护。只有受控的只读取数才能穿过这条线——所以它不可能误写、不可能跑错语句、也不可能编造数字。
AI 不接触企业数据库
取数账号只读，不存在误写误删，数据始终归企业掌控。
AI 不自己写 SQL
仅在已定义的指标口径内取数，不存在跑错语句算错数。
AI 不瞎编
口径不存在时明确提示，不编造数字。
deployment
灵活部署：私有化，或 SaaS
按企业合规与数据要求自选，两种形态共享同一套产品核心与同一套指标资产。
开箱即用
SaaS
无需自建环境，快速上手，适合希望轻量启动的团队。
同一套产品核心 · 同一套指标资产