能落地的 ChatBI，才是真ChatBI！

随着 ChatGPT、DeepSeek、Manus 这些大模型技术的集中爆发，企业级应用的落地进程明显加速了。但一个尴尬的现实是：真正落到实际场景时，总是逃不开成本高、响应慢、幻觉无法消除这几个坎。尤其在智能分析 ChatBI 领域，不少大模型厂商都试过水，可企业用户对数据准确度的要求实在太高——大量分析最终还是回到查数据库这条老路上。怎么把数据分析的门槛降下来、去掉麻烦的语义层、把模型幻觉管住，成了绕不开的核心议题。基于此，这篇文章就来拆解一下 DataFocus 是怎么凭十年的 Text2SQL 技术积累，拿出了一套能打的创新方案，给智能数据分析探条新路出来。

主要内容分三块：先说 ChatBI 落地碰到的那些硬骨头；再介绍 DataFocus 的产品到底怎么干的；最后是问答环节，把大家最关心的问题挨个说清楚。

01 ChatBI 落地挑战

1. 幻觉之困，ChatBI 变 CheatBI

大模型往企业场景里扎得越深，“幻觉”就越像一堵墙堵在落地前面。这个问题搞不定，看着挺智能的 ChatBI，一不小心就可能变成了“CheatBI”——拿假数据、错误的结论去糊弄决策，技术可信度一下子就垮了，企业价值也无从谈起。

Text2SQL 技术搞了好几十年，真正爆发是从 2020 年 Transformer 架构出来之后。SPIDER 基准测试的数据摆在那：准确率从 BERT 模型的 62.3%，跳到了 T5 模型的 78.6%；等 GPT 系列上了指令微调，2023 年最优模型已经冲到了 89.1%，增长快得跟指数似的。不过说到底，Text2SQL 当前的准确率还是卡在 90% 左右，再往上突破挺难。

右图列了当前 Top25 大模型的幻觉率，表现最好的那款，幻觉率也还维持在 0.7% 到 1.2% 之间。所以说，大模型的幻觉问题始终如影随形。

2. 响应太慢，ChatBI 变 WaitBI

第二个让人头疼的问题是响应速度。年初不少公司开始部署 DeepSeek 的一体化系统，结果并发数一上来——说白了就是用户一多——查询速度就直线往下掉，慢得让人受不了，根本没法满足那种即问即答的对话需求。

3. 方案偏差，ChatBI 变 CostlyBI

为了摆平上面那两个麻烦，企业不得不额外搞一堆活。比如，得提前把语义层定义得特别细，用来填补自然语言和结构化数据之间的沟；还得部署性能拉满的满血版 DeepSeek，指望靠算力把响应效率撑上去；再把 2000 多个指标从头到尾梳一遍，确保数据不打架、口径统一。

但这些折腾下来，负担可不轻。企业既要多花一倍的功夫——从方案规划到部署调试，每个环节都绕不开；还得掏双倍的钱——硬件、软件授权、人员培训，样样都要堆钱。最要命的是，这么大投入换来的效率提升却有限，性价比低得让人心塞，解决关键问题的路看起来越走越窄。

02 DataFocus 产品介绍

1. 对话式 BI 技术路线

在聊 DataFocus AI 算法之前，先把大模型时代 ChatBI 的几条技术路线捋一捋。

第一条，用得最多的是 Chat-to-DB 模式。这条路子全靠大模型的代码生成能力，直接把用户说的自然语言转成 SQL。但效果怎么样，取决于用户的使用场景和数据本身干不干净。因为这层关系，Chat-to-DB 更适合那些本来就懂 SQL 的数据库工程师——他们能靠自己的专业知识审查模型输出的结果，按需改改，效率能提上来。可要是拿它去做面向业务的 ChatBI，各种问题就冒出来了，业务场景那多样化的需求根本招呼不住。

第二条，Copilot 方式。它得提前把指标体系梳理得妥妥当当，或者先把大量问题定义好。用户一问，大模型就能迅速匹配到对应的指标，给业务员交出准确的结果。但局限性也很明显：太依赖前期准备，指标的事前工作量巨大。系统灵活性不足，业务一变就难跟上，运维成本也蹭蹭往上涨。

第三条，就是 DataFocus 在走的大模型加小模型的路子。不同企业实际用的具体模型可能有差别，但基本原理相通。业内普遍预测这会是未来的主流方向。不过，真要让这条路落地并发挥出优势，还得把一个小模型普适性的关键问题给解决了——也就是说，小模型的解析能力必须足够完备，要能覆盖拖拽式 BI、自己写 SQL 开发、做报表等各种场景能实现的功能，这样才接得住企业那些五花八门的需求。

2. DataFocus 探索历程

DataFocus 从 2016 年就开始捣鼓 Text2SQL 技术了，目标就是搭一座不用代码的自然语言交互桥梁，让业务人员和管理者能直接跟数据库对话，把数据使用的门槛狠狠降下来，提升企业决策效率。

2018 年，DataFocus 推出了探索式 BI 产品，用创新交互和智能分析碘伏了传统模式，重新定义了 BI 的新玩法。

搜索式 BI 的原理其实不复杂：通过自然语言做数据搜索。用户把问题输进去，系统先做语义解析，然后把查询指令送到解析层，翻译成对应的 SQL，再下发到内存里计算，最后把结果返回给前端。

搜索式 BI 的核心瓶颈，在于语义层太复杂、局限性太强。所以目标很明确：干掉语义层。

用了九年时间深耕，全新的 ChatBI 产品终于实现了即用即搜——不用提前搞复杂的细粒度建模，用自然语言就能快速发起搜索分析，数据交互流程简单得多。

目前，DataFocus 的自然语言搜索功能支持中、英文双语解析，但不建议混着用。用户不需要提前定义语义层，也不用搭完善的指标体系。提问方式很自由，有需求直接提，系统会自动算好基本指标，体验高效又便捷。同时，系统也照顾到不同用户的习惯——同义词功能可以根据自己的数据表达习惯自定义用语，用起来更顺手。还支持公式搜索，逻辑判断、数学计算、值转换这些复杂操作都能轻松搞定，搜索的灵活性和实用性一下就上来了。

3. DataFocus AI 算法优势

DataFocus 从设计之初就打定了主意，要降低大数据分析的门槛。研发团队精心做了个 Focus Search 小模型。用户只需要输关键词，系统就自动转成 SQL 并出结果。这设计让数据分析的入门门槛降得很低，更多人能轻松上手。不过，它的运行原理是用户得按预设模板输入问题，模型然后才输出对应的 SQL。

因为 Focus Search 不完全依赖深度神经网络，解析速度很快，还能做到零幻觉输出，结果很靠谱。但缺点也有：用户需要学对应的关键词体系，学习成本上去了。所以它更适合有一定基础的数据分析师用，帮他们更高效地完成工作。

为了补上短板、提升体验，DataFocus 推出了 AI 助手——小慧。小慧靠深度神经网络技术，能准准地接收用户输入的自然语言，然后转成关键词输出。小模型 Focus Search 再针对小慧解析出来的关键词语句，做进一步的深度解析，最后转成 SQL 输出。这两级模型协同工作，灵活性和准确性都兼顾到了，给用户带来更高效、更优质的分析体验。

4. DataFocus AI 算法价值

• 更可控
  ：对业务人员来说，不用懂复杂的 SQL，也能轻松判断小慧解析的结果对不对。幻觉最让人头疼的地方，就是不知道它什么时候冒出来。但要是使用者能把结果审查住，幻觉问题就捏在手心里了，不会对使用过程造成实质影响，真真正正做到可控。

• 更准确
  ：只要保证小慧生成的关键词没错，后面输出的 SQL 就不会出幻觉问题。把关键词这个关键环节卡住，整个数据分析流程的准确性就有保障了，给企业决策提供的数据支撑也够硬。

• 更高效
  ：Focus Search 的响应速度惊人，毫秒级就能出结果。从用户用纯自然语言提问题，到系统输出对应的 SQL，整个流程也只消几秒。同时还能轻松支持万人并发访问，效率比传统大模型高出 3 个数量级，企业数据处理的效率大大提升，大规模业务场景下的快速响应也接得住。

• 更透明
  ：从小慧收到用户输入，到解析成关键词，再到生成 SQL，整个过程每一步都清楚明了，用户随时能查看。Focus Search 的解析全程可追溯、可复现。这既增强了用户对系统的信任，也为系统优化和问题排查提供了有力支持。

• 更安全
  ：DataFocus 默认通过线上 API 实现推理功能，只把用户的问题和问题涉及的原数据传输给模型。这种严格的处理方式，最大程度地守住了企业的商业秘密，防止敏感信息外泄，用起来不用提心吊胆。

• 更灵活
  ：企业可以把整个模型部署在本地，不用绑定特定的大模型，还支持模型灵活切换。DataFocus 掌握了模型微调训练的全流程技术和数据，企业能根据自己的需求对模型做个性化调整。小慧的模型还支持基于开源模型训练，给企业提供了更多选择和自主性，满足不同业务场景的多样化需求。

5. 产品发展里程碑

从 2014 年创立 DataFocus 品牌，到 DataFocus Cloud 智能搜索式 BI 平台、Focus Search 数据库搜索引擎这些产品不断升级，再到 2024 年发布 FocusGPT 实现数据分析零门槛——DataFocus 创新的步子一直没停过。

DataFocus 的产品定位是“协助企业构建大模型时代认知智能基座”，让企业能高效驾驭海量数据，走可持续发展的路。

6. FocusGPT

用 FocusGPT，用户可以轻松开启跟数据库的多轮深度对话。同时，在自然语言理解上也跨了一大步，能更精准地抓住用户意图，支持多轮对话和分析引导，让人跟数据库的交互变得自然顺畅。

上图展示了 FocusGPT 跟其他开源框架比起来的核心优势。

FocusGPT 采用了经典的 Agent 架构。用户问题一进来，大模型就启动“智慧引擎”，对提问做意图识别，精准提取用户的目标。然后像一个经验丰富的策略家，把目标拆成多个子任务，定出一份详细的执行计划。评估觉得计划可行后，就借助 DataFocus 的小慧做关键词的深度解析，生成 SQL，最终输出查询结果。

FocusGPT 还会记住用户的上下文关联和所在领域的背景知识。为了实现这个目标，系统特别加了一些小组件，能显著提高模型处理任务时的精细程度，让每次对话和分析都更贴合用户需求，带来优质高效的使用体验。

7. DataFocus AI 赋能平台

DataFocus 不只是一个功能完备的数据平台，更是一个成熟的 AI 赋能平台。它能为企业大模型应用提供最重要的基础组件——Text2SQL，并以标准 API 的形式呈现，方便企业按需随时调用。为了更灵活方便，还依据 MCP 协议，把 Text2SQL 的能力封装成 MCP Server，同样支持直接调用，大幅降低了企业的技术门槛和开发成本。前端组件也是开放的，开发者可以自由装载；在 dify 和 Coze 里也提供了专门的插件，能更好地融入各类 AI 生态。

基于这些开放组件，还提供了一套 ChatBI demo，用户可以下载套件快速搭出一套 ChatBI 系统，感受 FocusGPT 的强大功能。

整套系统既能在云端直接用，也能做私有化部署。

这些开放组件和插件都有详细的视频介绍，可以去 DataFocus 的开源仓库或对应地址下载使用。

以上就是 DataFocus 产品的全貌。未来，DataFocus 会在认知智能领域继续深耕，用创新技术和专业服务，跟企业一起探索数据价值的新边界，共赴智能商业的新时代。

03 问答环节

幻觉问题

A1：DataFocus 通过分层解析架构和规则约束机制来抗幻觉：

• 小慧大模型
  ：小慧是专门做关键词解析的垂直大模型，把用户自然语言转成结构化的关键词（比如时间范围、指标、维度），避免直接生成 SQL 的语法风险。这一步可能有幻觉，但用户根据返回的关键词能发现幻觉并避开它。

• FocusSearch 引擎
  ：这个模型是 DataFocus 团队花了 9 年打磨出来的、专用于关系型数据库的搜索引擎，能把用户的关键词输入转成标准 SQL 输出，保证语法正确——这一步是零幻觉的。

关键词层相当于一个“安全网”，约束模型输出范围。就算 LLM 部分出了错，后续的规则引擎也能基于正确的关键词生成有效的 SQL。

前面提过，幻觉没法完全消灭，除非不用大模型。但在 DataFocus 里，幻觉是可管控的。具体来说，先借助小慧这类工具，把用户口语化的提问转化成简洁的中文关键词语句。这样哪怕业务人员或老板完全不懂 SQL，也能靠判断这些关键词来把控有没有“幻觉”问题，确保信息准确。

A2：可以的。DataFocus 的 Text2SQL 生成，通过第二阶段的 FocusSearch 模型去实现。这个模型不是纯粹基于深度神经网络搞出来的，里面还包含一些传统的 NLP 技术和工程技巧，所以没有 Transformer 模型固有的幻觉问题。确定的输入，一定会得到确定的输出。

意图识别与容错处理

A3：对用户问题的意图识别，像输入字符错误、语义含糊这些基本问题，对大模型来说基本不成问题，都在它能力范围内。用户表述稍微有点偏差——比如说错几个字，或者表达含混不清（像说了很多销售数据却没点明相关要点）——模型能自主处理，主动跟用户交互、澄清问题，准确抓住用户意图，保证后续回应贴合需求。

A4：因为涉及数据查询，所以对错误的容忍度通常很低。企业应用场景里这一点尤其突出——数据准确性直接关系到业务决策。同时，在速度和精度的权衡上，不应该做非此即彼的选择。对话交互的场景里，响应速度一慢用户体验就大幅下滑，所以不能为了速度牺牲精度，也不用为了精度牺牲速度，而要找到两者之间的平衡，确保系统既高效又准确。

模型与算法

A5：可以切换大模型。目前 DataFocus 对 DeepSeek 和 Qwen 系列模型都支持。

A6：大模型需要预先学关键词的用法。小慧大模型就是在通用开源大模型基础上，训练出关键词输出能力得到的微调模型。它的训练要求是把用户自然语言提问转成规范的关键词格式，这个输出可以直接喂给小模型做 SQL 解析。

A7：没有。小模型需要关键词输入，只要关键词输入正确，SQL 就是确定的，所以不适合用 Bird 数据集去测试。

A8：大模型把用户自然语言问题转成关键词输出，相当于一个简单的翻译任务——中文到中文、英文到英文。只是语言表达符合关键词的规范，更加简练。这样的结果，不需要任何技术基础，不懂 SQL 的用户也能看懂。正因为用户能审查结果的对错，就有效地控制了幻觉。

如果用大模型直接生成 SQL，就避免不了因幻觉特性产生的错误输出。这时候终端用户至少得能读懂、能判断 SQL 的正确性，才能审查结果的对错。所以说，幻觉并不可怕，可怕的是没法判断由幻觉产生的错误结果可能带来的危害。

数据建模与优化

A9：功能上支持几百列的大宽表。系统默认有一定字段数量限制，本地部署时配置可以灵活调整。只用 FocusSearch 小模型时，千列大宽表也没问题。不过，不建议在宽表里设过多字段，特别是用小慧大模型或 FocusGPT 智能体时，字段太多可能导致上下文信息量过大、增加处理难度和复杂度，影响模型性能和效果；token 消耗量大了使用成本也会提高。建议宽表适度，一般控制在 100 个字段以内比较合适。

A10：系统对物理表有一定要求，通常是数据结构清晰、字段名称显示合理的数据，使用效果会更好。DataFocus 的数据模型不管是星形还是雪花都支持。表名和列名如果没有清晰的中（英）文注释，Focus Search 小模型也能直接处理这类字段查询，但用起来不太直观，还是处理一下更好。DataFocus 在数据导入时，系统能自动检测数据表的字段，有详细注释和中文翻译的话会同步过来。把字段处理清晰了，像日期、数值用对格式、避免文本格式求和出错，系统处理起来会更高效准确。

A11：面对重复或相似字段（比如“销售额”“净销售额”“总销售额”同时存在），DataFocus 用三级处理机制来保障查询准确性：

• 字段优先级匹配
  ：系统内置业务语义权重库，对高频字段（如“销售额”）赋予更高优先级。例如，用户问“显示销售额”时，就算同时存在“净销售额”“毛销售额”这些相似字段，系统也会优先选权重最高的字段。权重规则可配置，企业可以根据业务需求调整（比如零售行业优先“GMV”，制造业优先“产量”）。

• 交互式澄清
  ：用 FocusGPT 智能体时，如果相似字段权重相近，系统一般会主动追问。比如问“您需要的是‘销售额（含税）’还是‘销售额（不含税）’？”用户选择后，生成对应的 SQL。

• 历史行为学习
  ：对同一用户的重复查询，系统会记录偏好选择（比如某用户常选“净销售额”），后续自动优先匹配。

影响控制：如果重复字段没得到有效治理，可能导致查询结果偏差。建议通过数据治理合并冗余字段，或在系统中配置字段别名（比如把“销售额”“总销售额”映射到同一个物理字段）。

A12：不是。关键词是计算逻辑。指标没法穷举，但计算逻辑可以穷举。关键词的用法可以参考官方关键词手册来学习。

A13：DataFocus 的 Text2SQL 支持有限度的复杂查询，能力边界取决于用户能不能用自然语言把需求说清楚。通常一句话能表达清楚的查询问题，都能满足。

A14：支持。如果表之间有关联关系，导入系统时系统会自动探测。探测完了，数据管理员去确认一下就会自动保存。不确认不保存的话，查询时就不会用关联关系。

A15：首要任务是做数据治理。一方面要保证企业内部有统一的主数据，保障数据的基础规范；另一方面要统一数据口径定义，避免标准不一引发问题。数据治理完成后，可以先选试点——比如让财务、采购这些高频用数据的部门先试试。通过他们的使用反馈做优化，再逐步往其他部门推，这样推广起来更稳妥有效。

A16：数仓适配小模型的实施周期通常是 1 到 3 个月，具体时长取决于企业数据治理的成熟度和技术基础：

• 数据评估阶段（2-4 周）
  ：梳理元数据——盘点现有数仓的表结构、字段注释、关联关系，找出缺注释或命名不规范的字段。做逻辑映射验证——测试小模型对核心业务查询（比如“月度销售额趋势”）的解析准确率，定位适配瓶颈。

• 治理改造阶段（3-6 周）
  ：优化结构——拆分宽表、补全外键关系，按需把雪花模型简化成星型模型。建设语义层——在数仓里构建业务语义层，把物理字段映射为业务术语（比如把 total_amount 映射成“订单总额”）。

• 模型训练与部署（1-2 周）
  ：领域微调——基于企业专属术语库（比如行业黑话、内部缩写）对小模型做微调。灰度上线——选一部分用户试运行，监控响应速度和准确性，优化参数后全量发布。

如果企业已经有完善的数仓文档和语义层，周期可以缩短到 1 个月以内。

A17：DataFocus 集成了数据治理能力，但强调的是“治理先行，分析驱动”的协同模式。

• 数据标准与质量
  ：支持定义统一数据标准，检测数据缺失、重复、异常等问题，并提供清洗工具来提升质量。

• 安全与权限
  ：细粒度权限管理，保障数据安全合规。

• 元数据与血缘
  ：自动采集元数据，追踪数据血缘，形成资产目录，提升数据发现效率。

• 生命周期管理
  ：支持数据归档、迁移等策略配置，避免冗余。

系统架构与部署

A18：DataFocus 的离线运行能力通过本地化部署架构来实现，分三个层级：模型与计算本地化——FocusSearch 小模型和整个数据平台（含数仓、查询引擎）完全部署在企业内网服务器上，不依赖外部网络。用户自然语言解析、关键词生成、SQL 执行这些核心流程都在本地闭环完成。云端协同限制——只有启用大模型功能时才需调用云端 API，但这个模块是可选的，企业可以完全关掉来实现纯离线模式。

A19：支持两种方式——存入 DataFocus 数仓，或者直连本地数据库。

A20：默认的私有化部署方式是把 DataFocus 数据平台和 FocusSearch 小模型部署在本地，云端通过调用小慧大模型的 API 实现智能解析。这种情况下，通常 8 核 CPU、32GB 内存的普通 X86 服务器就能跑起来。用户也可以根据数据量大小和使用规模做集群扩展。

A21：云端和私有化部署的差异，主要在于有的企业想把数据存在本地，有的觉得放云上不太合适。功能上没什么差异，基本上都一样。

性能与扩展性

A22：单纯说几个 T 或几个 PB 的容量不是关键，核心在于处理单表极限或多表 join 之后的数据量——是十亿级、百亿级，还是千万级、百万级。系统采用集群部署方式，数据量小可以用单个节点运行，数据量大就构建大集群，能弹性扩展，多大数据量都没问题。因为最终靠计算引擎处理，AI 只是辅助解析意图。

A23：DataFocus 支持大多数主流的开源 OLAP 引擎，比如 Doris/SelectDB、ClickHouse、Impala、Presto、Trino 等。如果有千万级数据需要实时分析，可以把数据导入 DataFocus 中分析，也可以通过直连 ClickHouse 等引擎来分析。

A24：从响应速度来看，随便一个查询，DataFocus 的响应都很快。就算大量用户同时使用，也能保持高效。特别是万人并发这种高负载场景，完全基于大模型的方案基本顶不住——不仅成本极高，还很难达到可用状态。当然，不惜成本往里砸或许能实现，但性价比太低了。DataFocus 凭自身技术，能在控制成本的同时，实现高并发下的快速响应。

A25：一般情况下，DataFocus 的查询响应速度都是亚秒级，具体取决于问题的复杂度和数据量大小。常用查询请求的响应速度很快，大量用户同时用也能保持高效。万人并发这种高负载场景，特别适合 DataFocus。完全靠大模型的方案基本顶不住，成本极高，还很难达到可用状态。

安全与权限体系

A26：因为大模型处理过程中不涉及具体数据，最终 SQL 生成是 FocusSearch 小模型做的，所以不存在大模型使用过程中的权限问题。取数这一步由小模型完成，FocusSearch 会根据系统权限配置，生成带权限控制的 SQL。

A27：系统里会定义角色，里面有各种资源——数据表、数据源、数据集等。以数据集为例，可以对角色配置：比如规定某些字段不展示给该角色，或者品牌等于或不等于特定内容的数据。配置好后，该角色下的用户访问表或数据集时，就会受到权限限制。每次查询，系统会把对应权限信息融进查询过程。

A28：FocusGPT 智能体支持智能选表。当不指定某张表做问答数据源、需要从一定范围的库表里找答案时，FocusGPT 会自动在用户有权限的数据表列表中，根据用户问题的意图去匹配数据。

• 语义映射
  ：解析用户问题中的业务实体（比如“销售额”“客户”），在元数据里检索包含相关字段的表。例如，问“统计客户复购率”，系统自动匹配包含“客户 ID”“订单日期”字段的表（比如订单表、客户行为表）。

• 表优先级排序
  ：根据历史查询频率、数据新鲜度（最近更新时间）、字段匹配度为表打分，优先选高分表。

为了保障准确率，一方面数据表描述信息要写得更具体，方便模型精准定位；另一方面别一次性给模型太多表，可以通过权限设定来划分，不同角色分配几十张表，从少量表里找，准确率就比从海量表里找高得多。

企业应用与集成

A29：最多支持多少轮对话？理论上可以支持无限轮，但对话轮数太多会丢失早期信息。DataFocus 的多轮对话能力由上下文窗口管理机制决定，支持轮数受限于大模型的上下文支持长度，也取决于环境配置。系统配置会管理一个滑动的上下文窗口，超限后自动丢弃最早记录。

A30：这可以理解成两个问题。第一个，跟企业内部部署的 AI 大模型集成——如果企业内部的大模型服务提供标准接口（比如兼容 openai 的接口规范），可以在 DataFocus 系统配置里直接配好接进来。第二个，跟企业微信、钉钉、飞书这些 IM 软件集成——DataFocus 的系统配置页面里，可以通过全局设置配置企微、钉钉和飞书。

A31：知识库分个人记忆库和系统知识库两部分。系统知识库一般由管理员统一配置，全体用户使用时都共用这部分知识；个人知识库只存个人的记忆，用户可以手工配置，也可以直接告诉大模型去记住相关知识。

A32：目前不建议直接用 Dify 做 Chat BI。更常见的做法是把相关能力作为工具来调用。比如在智能客服场景里，需要从数据库查数据来回答客户问题（像查退货信息），可以调用 DataFocus 的 Dify 插件做数据库查询，拿到结果后返回给模型回复用户。纯粹用 Dify 做 Chat BI，成本高、速度慢，而且 Dify 不是专为这个场景设计的。不过，可以借助 Dify 简单搭个 Chat BI 演示来做早期测试，初步评估效果、发现问题。

A33：目前系统已经支持贡献度归因分析和夏普利归因分析。在数据查询过程中，只要符合归因模型的数据要求，就会自动做归因。预测分析已经在计划里了，请期待。

A34：这两个功能目前已经是 DataFocus 系统里有的功能了，可以直接用。

A35：不需要。实时问数过程中就可以做归因分析。

A36：差异很明显。传统 BI 授权模式通常是预先付费买授权，不管实际用多少，费用相对固定。API 调用计费模式按需付费，用户根据实际调用 API 的次数或数据量来支付。这种模式下，成本跟实际使用紧密挂钩，避免了资源浪费，相比传统模式成本更低、也更公平合理。

A37：跟 Excel 表比，两者适用场景不同。Excel 极度灵活，适合个人在小规模数据场景下用，用户可以对每个单元格随便操作。DataFocus 系统主要面向企业级场景，处理的是几百上千万甚至几十亿级别的大规模数据，能迅速给出统计分析结果。Excel 不适合处理大数据，也不能做权限控制，适合小团队或个体用户。

A38：从公开资料看，Tableau 的 AI 功能基于 Einstein Trust Layer，确保数据隐私和安全。具体怎么实现的不得而知。对比来看，DataFocus 和 Tableau 功能定位大致相同，最大的差异可能是 DataFocus 是 Made in China，Tableau 是 Made in USA。

Tableau 能实现的功能，DataFocus 都能覆盖。而 DataFocus 的 FocusSearch 功能是 Tableau 不具备的。具体使用体验，有条件的用户可以分别试试，看看哪个产品在性能上更占优势。

以上就是本次分享的内容。