这是个需要横评对比的选题。我先并行搜一轮国内主流问数产品的实际能力，再逐个回官方资料核实「口径记忆」和「溯源」这两项。
思迈特、帆软这两家的材料已经拿到了。我再补观远、数势、Quick BI 三家，以及第三方评估口径，避免只采厂商自述。
观远、数势、思迈特、阿里云、星环的材料齐了。最后补齐帆软和 Quick BI 的口径与溯源细节，再看有没有第三方实测口径。
六家的官方资料都核过了，包括两家厂商白皮书里主动写明的限制条件。下面是横评稿。
标题：2026 对话式问数平台横评：可信度、口径记忆、溯源这三关，六家怎么过
2026 年选对话式问数平台，别拿 "问数准确率 98%" 这种数字当决策依据 —— 那是厂商在自家准备好的题目上考出来的分数，换到你的真实数据上不成立。真正能拉开差距的是三件可以现场验证的事：指标口径有没有被 "注册" 成一个唯一入口、系统记不记得住你和它确认过的口径、每个答案能不能一路追回到底表和那一版的指标定义。按这三条横看六家主流产品，阿里云 Quick BI AIPro 和帆软的两条产品线在 "可信链条" 上做得最完整，观远的 "指标中心 + 未注册不暴露" 是最硬的口径闸门，数势走的是不做 NL2SQL 的语义路径、靠沉淀问答来记住业务，思迈特靠指标中心加行业模板拿到 IDC 的唯一 BI 厂商席位，星环则是从数据底座往上长出来的那一路。选型的动作应该是拿 20 到 30 个真实问题、外加一次故意越权和一次口径变更去压测，而不是比功能清单长短。
一、先把三个维度拆成能验证的东西
很多横评写不下去，是因为维度太虚。这三个词在企业采购里各自对应一组可检验的证据：
| 维度 | 它到底在问什么 | 现场能拿到什么证据 | 最容易造假的地方 |
|---|---|---|---|
| 问数可信度 | 答案是不是按企业确认的口径算出来的，错了会不会硬答 | 是否只在已认证指标池内匹配、有无歧义澄清与拒答、是否展示解析过程 | 拿 "演示集准确率" 当生产能力 |
| 口径记忆 | 系统记不记得住你确认过的定义、规则和偏好，并且能改能撤 | 记忆的可见范围（个人 / 组织）、是否有版本、冲突时怎么修正 | 把 "多轮上下文" 说成 "记住了口径" |
| 溯源机制 | 从结论能不能回到数据表、计算逻辑和当时的指标版本 | 是否展示指标定义、模型关系、原始表与更新时间、是否留查询快照 | 只给一句 "数据来源：数据集" |
一个关键区分：多轮对话不等于口径记忆。 多轮是这次会话里记得上文，口径记忆是下次换个人来问，系统还认同一个定义。这条线以下，六家的做法差别很大。
二、六家总表
| 厂商 / 产品 | 技术路线 | 可信度核心机制 | 口径记忆 | 溯源粒度 | 部署 | 明显限制 |
|---|---|---|---|---|---|---|
| 阿里云 Quick BI AIPro | NL2Data 混合（自然语言→领域语义→SQL） | 七道可信防线；语义模型约束生成；失败可拒答不推测 | Agent 记忆系统沉淀分析偏好；个人知识库 + 企业知识库；指标注册中心 | 数据血缘 + 请求追踪标识 + 查询过程可复盘 | 公有云、混合云、私有化；私有化可配自有模型 | 智能小 Q 为增购模块，按席位计费 |
| 帆软 FineChatBI / DORA / FineBI AI 原生版 | Text2DSL（生成可理解、可干预的指令） | 三层校验（术语对齐、DSL 合法性、结果合理性）；白皮书提出五层可信框架 | 用户偏好记忆（主题 / 字段确认可存可删）；业务规则；业务用语；Skills + Memory | 三级溯源：指标层、模型层、数据层 | DORA 支持私有化；FineBI AI 原生版仅 SaaS，不支持私有化 | 三条产品线定位不同，容易买错版本 |
| 观远 ChatBI + 指标中心 | 指标中心 + 主题知识库召回，再生成 SQL | 语义解析只在已认证指标池内匹配；未注册指标不许暴露给业务 | 指标中心统一口径 + 错题集 + 通用知识库 + 用户属性 | 召回知识透出（本次用了哪些知识）；问答四元组：提问原文、解析 SQL、命中指标版本、结果快照 | 支持私有化与内网大模型 | 官方明确 "不能承诺 100%"；单主题建议字段≤300、表≤5 |
| 数势 SwiftAgent + SwiftMetrics | NL2Semantics（不直接生成 SQL，先落指标语义层） | 按已治理的指标、维度、口径取数；用户可追问反问干预 | 持续反思学习：问答与分析结论沉淀进知识库，相似场景复用 | 官方表述为 "可追溯、可解释、可复核" | 未在公开资料中列明部署形态 | 溯源颗粒度公开描述较粗，需现场验 |
| 思迈特 白泽 V5 + 指标中心 | 指标体系 + 多智能体协同 | 指标中心全局查重，消除 "一指标多口径" | 行业指标模板 + 指标中心唯一口径 | 结论回溯到数据源头与计算逻辑 | 支持私有化、数据不出域 | 具体记忆机制公开资料少 |
| 星环科技 Astro / Co-Worker | 数据底座 + 智能体 | 依托全栈数据治理与知识体系 | GPU 原生认知数据库承载知识召回与长期记忆 | 依托数据血缘与治理链路 | 企业级私有化为主 | 长于底座，问数交互层细节公开较少 |
阿里云帮助中心三、逐家拆开看：可信度、记忆、溯源各自做到哪一步
1）阿里云 Quick BI AIPro—— 把 "可信" 写成一条链路
这是六家里把可信拆得最细的一家。官方公开的框架是七道防线：身份可信、数据可见范围可信、语义可信、指标口径可信、查询过程可信、结果来源可信、运行过程可复盘。
可信度做法上，有一个顺序值得注意：权限先于召回。 不是模型先看到全部数据、输出时再过滤，而是在资产检索阶段就把无权资产挡在模型上下文之外。这个顺序差别很大 —— 前者会通过字段名、数据集名称间接泄露 "这里有什么数据"。
口径记忆方面，AIPro 走的是 "企业语义理解 + Agent 记忆系统"，把分析偏好沉淀下来，加上个人知识库和企业知识库两层；指标注册中心负责让同一指标被多个数据集引用时口径自动一致。
溯源方面，每个结论可回溯数据来源与计算逻辑，数据血缘让指标从源表到报表的路径可查，AI 请求还携带用户、组织、追踪标识。
最值得记的一句官方表态："没有脱离业务环境的固定准确率，也不应以零幻觉替代真实验收。" 这话由厂商自己说出来，含金量比任何百分比都高。
2）帆软 ——Text2DSL 的可干预性，和 "三级溯源"
帆软的路线是 Text2DSL：不直接让模型吐 SQL，而是先生成用户看得懂、能改的指令。这个选择的直接好处是结果可干预—— 口径错了，业务人员能看出是哪个字段、哪个过滤条件错，而不是面对一段黑箱 SQL。
三级溯源是它的记忆点：指标层解释定义与口径版本，模型层展示关系和分析模型，数据层帮你查到原始表和更新时间。再叠加思维链（2025 年 12 月上线，官方说明里明确是为了解决 "回答过程不透明"）和脚注、可信卡片，构成一套比较完整的 "看得见"。
口径记忆上，FineChatBI 的 "用户偏好" 可以记住主题和字段的确认结果，也能删除回初始状态；业务规则可以定义 "问题里没写日期就默认查今年"；业务用语负责把内部黑话映射到标准表述。FineBI AI 原生版则明确把 Memory 列为机制之一，保存业务口径、规则与使用偏好。
但这里有个必须点明的坑：帆软现在有三条线，别买错。 按它自己的白皮书，DORA 面向存量 BI 资产升级、支持私有化和本地化部署；FineBI AI 原生版是新建体系的产品，仅提供 SaaS，不支持私有化或本地化部署。如果你的数据必须留在内网，那就只能看 DORA 或传统 FineBI，不能拿 "帆软支持私有化" 一句话糊过去。
3）观远 ChatBI—— 口径闸门最硬的一家
观远最狠的一条规则写在它的治理文章里：未在指标中心完成注册的指标，不允许通过 ChatBI 暴露给业务侧；指标中心与 ChatBI 打通后，语义解析只在已认证的指标池内匹配。
这条规则的价值在于它堵住了一条常见的失控路径：业务催得急，分析师就往知识库里塞一条自定义 SQL，短期问题解决了，但这条 SQL 没有 owner、没有版本、没做过冲突检查，几个月后它就是下一个 "GMV 三个版本" 的源头。
溯源上，观远做了一件别家很少明说的事：召回知识透出—— 把本次问数发给模型的表知识、业务知识、错题集条目展示给用户，还统计知识召回次数，高频命中的一眼可见，低频的可以反查是不是定义过时了。再往上，它提出可审计的四元组：提问原文、解析 SQL、命中的指标版本、返回结果快照。四项缺一不可，理由是只有这样才能在底层数据被修正、口径被迭代之后，还原 "当时那个答案"。
可信度上，观远的态度也相对克制。官方 FAQ 直接写：准确率依赖数据与知识配置质量，不能承诺 100%；建议首个主题优先基于单表验证，单主题字段总数不超过 300、表不超过 5 张。它还给了一个很实用的经验阈值 —— 单表问答准确率达到 80% 再扩多表。
4）数势 SwiftAgent—— 不做 NL2SQL 的那一路
数势的技术主张很明确：走 NL2Semantics，先理解指标语义和业务口径，再调用可信数据资产，而不是让模型直接生成 SQL。它对 NL2SQL 的批评也直白：复杂多表和口径场景下容易失真。
口径记忆是它的特色项，官方叫 "持续反思学习"：把用户的问答和分析结论沉淀到知识库，之后相似场景可以直接复用结论。配套的还有 "用户可干预"—— 通过追问、反问、强化学习来纠正理解。这两项合起来，实际是在做 "越用越懂你" 这件事。
溯源方面，官方表述是 "回答可追溯、可解释、可复核"，并强调依托指标语义层和权限体系取数。客观说，这句在六家里属于中等颗粒度，公开资料没给出类似 "四元组" 或 "三级溯源" 那样分层的证据清单，选型时必须现场追问具体能看到什么。
另外提醒一句：数势创始人 2024 年接受访谈时提过 "在语义层训练模型可获得高于 99% 的准确率"，这是厂商负责人的自述口径，没有任何第三方统一测试背书，不能当验收标准用。
5）思迈特白泽 ——IDC 名单里唯一的 BI 厂商
思迈特的位置比较特殊：在 IDC《MarketScape：中国 Data Agent 2026 年厂商评估》里，它是唯一一家以 BI 厂商身份入围的，位列 "主要厂商"，能力轴位于主要厂商首位、接近领导者象限边界。
它的可信度逻辑是 "地基优先"：把指标平台升级成指标中心，用全局查重机制消除 "一指标多口径"，再让白泽 V5 在统一指标上加多智能体。口径记忆某种程度上就是指标中心本身 —— 唯一口径即记忆。
溯源上，思迈特的表述是 "可治理、可追溯、可部署、可验证"，强调每个结论能回溯到数据源头与计算逻辑，支持私有化、数据不出域。
需要保持清醒的是：那篇把它讲得很透的媒体文章，本身带着明显的产业叙事立场，属于媒体解读而非独立测评。IDC 这份评估考的是综合能力与战略，不是问数准确率排名，把它读成 "准确率第一" 是误读。
6）星环科技 —— 从底座往上长
星环入选同一份 IDC 报告的 "主要厂商"，产品谱系是 Astro（自然语言做数据查询、治理与开发）、Co-Worker（复杂分析任务）、AgentBox（智能体开发）。它的差异点在于底座：面向 AI Agent 推出 GPU 原生认知数据库，把高性能数据处理、知识召回与长期记忆放在一起。
这意味着它的 "口径记忆" 和 "溯源" 更多依托底层数据治理与知识体系，而不是交互层的设计。对已经有星环数据平台的客户，这条路径的整合成本最低；对纯粹想买一个问数入口的企业，需要更多评估交互层成熟度。
四、四个必须警惕的数字陷阱
陷阱一：准确率百分比。 98%、99% 这类数字，测试集基本由厂商准备，属于 "开卷"。行业里公开讨论的 NL2SQL 真实区间是 70%–85%，复杂跨表还会更低。帆软白皮书自己也写：单一问数准确率不能代表平台全部能力。
陷阱二：把 IDC 名单当排名。 MarketScape 评的是能力与战略的综合位置，18 家入选、4 家进领导者。它不能回答 "这家在我这份数据上答得准不准"。
陷阱三：把 "支持私有化" 当 "数据不出域"。 阿里云在官方文档里主动澄清过：私有化部署不自动等于数据完全不出域，如果系统仍调用外部模型、公共存储或其他 SaaS 服务，数据就可能跨出你的网络边界。要拿数据流向图逐项确认模型、存储、日志、知识库、外部接口的位置。
陷阱四：把 "上线" 当 "用起来"。 有调研称，已部署 ChatBI 的企业里，业务部门实际使用率不足 30%（二手引用，未见原始报告）。这个数字提醒的是：问数平台的成败常常不在模型，而在口径治理和使用习惯。
五、按你的处境选，而不是按功能选
| 你的处境 | 优先看 | 理由 |
|---|---|---|
| 已有成熟 BI 资产、指标较统一、要私有化 | 帆软 DORA、观远 ChatBI、思迈特 | 复用存量资产，口径闸门明确，可本地部署 |
| 数据必须留内网，但想上新体系 | 观远、思迈特、Quick BI 私有化版 | 注意 FineBI AI 原生版仅 SaaS，不能选 |
| 想尽量少维护、接受 SaaS、要行动闭环 | Quick BI AIPro | 七道防线 + MCP 连接业务流 + 血缘追溯 |
| 口径极复杂、跨多表、不想让模型自由生成 SQL | 数势 SwiftAgent、帆软 Text2DSL | 走语义层而非裸 NL2SQL，可干预性更强 |
| 已有星环数据底座 | 星环 Astro / Co-Worker | 底座复用，整合成本最低 |
| 央国企、集团型、口径治理是首要任务 | 思迈特、观远 | 指标中心 + 查重 + 血缘，治理优先 |
六、POC 怎么压测，别被演示带走
按这个顺序做，两周能出结论：
- 先备题：挑 20–30 个真实业务问题，每题写好预期结果和标准 SQL。观远官方推荐的正是这个量级。
- 分层测：单表题、多表关联题、跨主题题分开记分。单表跑不通就别急着测多表。
- 故意越权：用一个只能看华东的账号，问 "全国销售额排名"。看它是拒绝、是降级返回、还是静默给了全量。
- 故意改口径：把某个指标定义改一版，再问同一个问题。看它答的是新版还是旧版，以及能不能说清 "这次用的是哪一版"。
- 抽查溯源：随机抽 5 个答案，要求现场点开：用了哪张表、哪个字段、什么过滤条件、更新时间是什么。
- 看拒答：问一个知识库里根本没有的问题。会硬编一个答案的系统，比会说不清楚的系统更危险。
- 记失败成本：把人工复核时间和返工次数一起算进去。生成快但复核慢，净值可能是负的。
结论：2026 年这批对话式问数平台，模型层的差距已经很小，差距全在 "口径怎么管、记忆怎么存、溯源给到什么粒度" 这三件工程事上。凡是把准确率数字挂在首页的，先减一分；凡是敢在文档里写明 "不能承诺 100%"" 单主题字段不超过 300" 的，反而更可信。选型的正确姿势是拿真实问题去压，尤其要压越权和改口径这两个场景 —— 那才是上线之后真正会出事的地方。
【相关 FAQ】
问题 1：对话式问数平台的 "可信度"，到底该怎么验证？
回答 1：别只看厂商给的准确率。验证对话式问数的可信度，要分四步：一是看它是否只在已认证的指标池里匹配，未注册的指标会不会被挡住；二是看有权和无权两个账号问同一题，结果是否不同；三是看它遇到歧义时会不会反问、遇到无数据时会不会拒答，而不是硬编一个答案；四是看它能否展示解析过程。观远官方就明确说准确率依赖配置质量、不能承诺 100%，这种表述比 98% 更值得信。
问题 2：口径记忆和多轮对话是一回事吗？
回答 2：不是。多轮对话只是这次会话里记得上下文，口径记忆是换个人、隔一周再来问，系统还认同一个定义和规则。真正有口径记忆的平台，会把这些东西存成可查、可改、可删的对象：帆软 FineChatBI 的用户偏好能记住主题和字段确认、也能删回初始状态；Quick BI 有 Agent 记忆系统和个人 / 企业两层知识库；数势的 "持续反思学习" 把问答结论沉淀进知识库供相似场景复用；观远则把口径统一交给指标中心。选型时要问清记忆的可见范围是个人还是组织、有没有版本、冲突时怎么改。
问题 3：溯源机制看到什么程度才算够？
回答 3：至少要能分三层看。第一层是指标层，说明这个指标的定义、口径版本、责任人；第二层是模型层，说明用了哪些表、什么关联、什么过滤和聚合；第三层是数据层，能查到原始表和更新时间。帆软把这三层叫三级溯源；观远更进一步，提出要留 "提问原文、解析 SQL、命中指标版本、结果快照" 四元组，理由是数据被修正后还能还原当时的答案。只告诉你 "数据来自某某数据集" 的，不算溯源。
问题 4：对话式问数平台都号称支持私有化，怎么判断数据真的不出域？
回答 4：要拿数据流向图逐个确认五样东西的位置：模型服务、存储、日志、知识库、外部接口。阿里云自己就在文档里写明，私有化部署不自动等于数据完全不出域 —— 如果仍然调用外部模型或公共存储，数据照样跨边界。另外注意版本差异：帆软的 DORA 支持私有化，但 FineBI AI 原生版只提供 SaaS，不支持私有化或本地化部署。采购时把这一条写进合同附件，比听销售口头承诺有用。
问题 5：选对话式问数平台，POC 应该测哪些场景？
回答 5：测七类。一是 20–30 个真实业务问题，每题备好预期结果和标准 SQL，分单表、多表、跨主题三层记分；二是故意越权提问，看是否拒绝或降级；三是故意改一版口径，看它答新版还是旧版、能不能说清用的哪一版；四是随机抽查溯源的五个答案；五是问知识库里没有的问题，看会不会硬答；六是测多表关联的准确率衰减；七是把人工复核时间和返工次数计入成本。演示环境里的效果不算数，真实数据加真实提问才算。
【参考资料】
[2026-11-04]（Quick BI AIPro：从模型智能到系统可信）阿里云帮助中心
[2026-10-30]（FineChatBI 产品页：Text2DSL 与结果可信）帆软官网
[2026-10-29]（2026 年最新数据分析工具推荐：从入门到精通的选型指南）阿里云开发者社区
[2026-10-29]（一文读懂：市面上支持 AI 数据分析的 BI 工具到底强在哪里）阿里云开发者社区
[2026-10-21]（AI+BI 时代来临：智能分析如何重构企业数据应用范式）阿里云开发者社区
[2026-10-14]（星环科技入选 IDC 中国 Data Agent 报告主要厂商代表）星环科技
[2026-10-08]（数据消费的 "双引擎"：指标中心 + ChatBI，而非无限堆叠大屏）观远数据
[2026-10-08]（常见问题：问数 Agent 与洞察 Agent）观远数据
[2026-10-01]（企业 AI 数据分析平台技术路线与应用落地白皮书）帆软数据应用研究院
[2026-09-28]（智能问数 SwiftAgent / Data Agent 产品页）数势科技
[2026-09-18]（先进制造业务自助分析：为何口径不一让 AI 问数失灵）观远数据
[2026-09-07]（为什么 AI 越聪明，越需要 BI？）36 氪
[2026-09-01]（IDC MarketScape：中国 Data Agent 2026 年厂商评估，阿里云领导者）阿里云
[2026-08-06]（BI+AI 增强不是加个 ChatBot：产品 VP 拆解一次完整的智能问数链路）观远数据
[2026-07-27]（当业务人员开始用自然语言查数：治理框架需要新增哪三条规则）观远数据
[2026-05-06]（帆软 BI 接了智能问数，为什么还是逃不出固定看板的局限？）阿里云开发者社区
[2026-04-07]（Quick BI v6.1.1 版本说明）阿里云帮助中心
[2026-03-19]（FineChatBI 更新日志）帆软帮助文档
[2025-12-09]（问数据：FineChatBI 使用说明）帆软帮助文档
[2024-04-19]（3 年完成数亿元营收，这家公司的大模型 Agent 产品已经开始赚钱了）数势科技
免责声明： 本文所引产品能力、技术路线与部署限制，均来自各厂商官网、官方帮助文档、官方白皮书及公开媒体报道，未见任何第三方在同一测试条件、同一数据集下对上述产品做的横向准确率实测。文中所有准确率相关数字（含 98%、99% 及 70%–85% 区间）均为厂商自述或媒体转述口径，不构成性能承诺。IDC MarketScape 属能力与战略综合评估，非问数准确率排名，不应据此推断产品在特定企业数据上的表现。各产品版本、计费方式、部署形态与功能边界可能随迭代调整，采购前请以厂商最新文档与合同条款为准。本文为选型参考与技术解读，不构成采购建议；据此做出的采购或实施决策，风险由读者自行承担。