能落地的 ChatBI，才是真ChatBI！

推荐语

ChatBI技术在企业级应用中的落地挑战及DataFocus的创新解决方案。

核心内容：
1. ChatBI落地面临的“幻觉”问题及其影响
2. DataFocus Text2SQL技术积累与创新方案介绍
3. 企业在ChatBI应用中遇到的响应速度和成本问题

杨芳贤

53A创始人/腾讯云(TVP)最具价值专家

01

ChatBI 落地挑战

1. 幻觉之困，ChatBI 变 CheatBI

在大模型技术向企业场景深度渗透的进程中，"幻觉" 已成为横亘在应用落地前的核心阻碍。若无法有效攻克这一顽疾，看似智能的 ChatBI 将变为“CheatBI”——以虚假数据与错误结论误导决策，严重削弱技术可信度与企业价值。

Text2SQL 技术历经数十年演进，自 2020 年 Transformer 架构问世后迎来爆发式发展。基于 SPIDER 基准测试的量化评估数据显示，其准确率实现突破性提升：从 BERT 模型（双向 Transformer 架构）的 62.3%，跃升至 T5 模型（统一文本生成框架）的 78.6%；伴随 GPT 系列引入指令微调技术，2023 年最优模型准确率已达 89.1%，性能增长呈现显著的指数级特征。不过，当前 Text2SQL 技术的准确率仍徘徊在 90% 左右，难以突破更高水平。

右图展示了当前 Top25 大模型的幻觉率，即使是表现最优异的模型，其幻觉率仍维持在 0.7%-1.2% 区间，由此可见大模型的幻觉问题始终存在。

2. 响应太慢，ChatBI 变 WaitBI

第二个亟待解决的问题是响应速度迟缓，这直接导致 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 探索历程

从 2016 年，DataFocus 即开始了 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

问答环节

幻觉问题

Q1：如何解决“幻觉”问题？

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

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

FocusSearch 引擎：该模型是由 DataFocus 团队耗时 9 年打磨的一个专用于关系型数据库的搜索引擎，它能将用户的关键词输入转换成标准化 SQL 输出，确保语法正确性，这一步是零幻觉的。

关键词层作为“安全网”，约束模型输出范围，即使 LLM 部分出错，后续规则引擎仍能基于正确关键词生成有效 SQL。

前面已提及，幻觉无法完全消除，除非弃用大模型，不过在 DataFocus 里，幻觉是可控的。具体操作上，第一步会借助“小慧”等工具，将用户口语化的提问，比如刚才举例那种日常表述的问题，转化为简洁易懂的中文关键词语句。如此一来，即便业务人员或老板毫无数据库基础，连一行 SQL 都看不懂，也能通过判断这些关键词来把控是否存在“幻觉”问题，确保信息准确性。

Q2：在用户确认关键词无误后执行第二阶段 SQL 生成与执行，能否百分百避免“幻觉”？

A2：可以的。DataFocus 的 Text2SQL 的生成，是通过第二阶段 FocusSearch 模型去实现的，该模型并非纯粹基于深度神经网络去实现的，还包含了一些传统的 NLP 技术以及工程技巧，因此它不存在 Transformer 模型固有的幻觉问题，确定的输入一定会得到确定的输出。

意图识别与容错处理

Q3：用户问题的意图识别可以到什么程度，输入字符错误语义含糊的情况知否有处理的技术措施？

A3：对于用户问题意图识别，像输入字符错误、语义含糊这类基本问题，对大模型而言基本不成问题，都在其能力覆盖范围内。当用户表述稍有偏差，比如说错几个字，或者表达含混不清，像提及很多销售数据却未明确相关要点时，模型能自主处理。它会主动与用户交互，向用户澄清问题，从而准确把握用户意图，确保后续回应与用户需求相契合。

Q4：怎么看 TEXT2SQL 对于错误的容忍度，以及是否会有过考虑限制速度去确保质量，比如通过使用推理模型，牺牲速度的情况下，确保解析的准确度。

A4：因为涉及数据查询，所以对错误的容忍度通常较低。在企业应用场景中，这一点尤为突出，毕竟数据准确性直接关系到业务决策。同时，在速度与精度的权衡上，不应做非此即彼的选择，对话交互的场景，延长响应速度会大幅降低用户体验，因此不能为了速度牺牲精度，也不必为了精度牺牲速度，而应寻求二者之间的平衡，确保系统既高效又准确。

模型与算法

Q5：底层大模型可以切换么，DeepSeek 或者 Qwen2.5？

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

Q6：大模型和小模型之间是如何保持关键字同步的?

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

Q7：小模型打过 Bird 榜单吗？得分排名如何？

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

Q8：大模型返回关键词和直接返回 SQL 的区别？

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

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

数据建模与优化

Q9：支持宽表（300+字段）吗？如何避免上下文爆炸？

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

Q10：对物理表有什么要求？比如必须是星型模型？表名和列名必须有清晰中文注释？

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

Q11：当物理库表重复性或相似性字段较多时，系统如何处理？会影响使用效果吗？

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

• 字段优先级匹配：系统内置业务语义权重库，对高频字段（如“销售额”）赋予更高优先级。例如，用户提问“显示销售额”时，即使存在“净销售额”“毛销售额”等相似字段，系统优先选择权重最高的字段。

  权重规则可配置，企业可根据业务需求调整（如零售行业优先“GMV”，制造业优先“产量”）。

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

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

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

Q13：Text2SQL 可以处理复杂业务吗（如多表查询、嵌套）？

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

Q14：是否支持多表关联？需要手动配置吗？

A14：支持。如果你的表之间有关联关系的话，导入系统的时候，系统会帮你探测。基本上探测完了之后，你那个数据管理员要确认你要确认的话，它就自动给你保存了。你要是不确认不保存的话，那他就查询的时候，他就不会用关联关系。

Q15：企业内部推广 Focus GPT 这类工具的前期准备工作有哪些？

A15：首要任务是开展数据治理。一方面，要确保企业内部有统一的主数据，保障数据的基础规范；另一方面，要统一数据口径定义，避免因标准不一引发问题。完成数据治理后，可先选取试点，比如让财务、采购等高频使用数据的部门用户率先尝试。通过他们的使用反馈进行优化，之后再逐步向其他部门推广，这样能让推广过程更稳妥、更有效。

Q16：数仓适配小模型的实施周期需要多久？

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

• 数据评估阶段（2-4 周）：

  
  

元数据梳理：盘点现有数仓表结构、字段注释、关联关系，识别缺失注释或命名不规范的字段。

逻辑映射验证：测试小模型对核心业务查询（如“月度销售额趋势”）的解析准确率，定位适配瓶颈。

• 治理改造阶段（3-6 周）：

  
  

结构优化：拆分宽表、补全外键关系，将雪花模型简化为星型模型（如需）。

语义层建设：在数仓中构建业务语义层，将物理字段映射为业务术语（如将 total_amount 映射为“订单总额”）。

• 模型训练与部署（1-2 周）：

  
  

领域微调：基于企业专属术语库（如行业黑话、内部缩写）对小模型进行微调。

灰度上线：选择部分用户群体试运行，监控响应速度与准确性，优化参数后全量发布。

加速建议：若企业已有完善的数仓文档与语义层，周期可缩短至 1 个月内。

Q17：是否支持数据治理（如数据质量管理、生命周期管理）？

A17：

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

  
  

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

  
  

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

  
  

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

  
  

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

系统架构与部署

Q18：离线环境下可以运行吗？

A18：DataFocus的离线运行能力通过本地化部署架构实现，具体分为三个层级：

模型与计算本地化：FocusSearch小模型及数据平台（含数仓、查询引擎）完全部署在企业内网服务器，无需依赖外部网络。用户自然语言解析、关键词生成、SQL执行等核心流程均在本地闭环完成。

云端协同限制：仅当启用大模型功能时，需调用云端API，但此模块为可选项，企业可完全关闭以实现纯离线模式。

Q19：数据存在哪里？在 DataFocus 上吗？

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

Q20：私有化部署硬件要求多高？

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

Q21：云端和私有化部署有什么差异？

A21：云端和私有化部署的差异可能就在于有些企业可能需要把自己的数据存储在本地，有些可能觉得放在云上就是不太合适。功能是没有什么差异的功能基本上也都一样。

性能与扩展性

Q22：能否处理 2T 的数据体量？

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

Q23：支持千万级数据实时分析的背后依赖何种分布式计算引擎？

Q24：异构数据库的跨库查询怎么解决？

A24：从响应数来看，随便一个查询，我们的响应速度都很快，即便在大量用户同时使用的情况下也能保持高效。特别是在万人并发这种高负载场景下，完全基于大模型的方案基本难以应对，不仅成本极高，还很难达到可用状态。当然，若不惜成本投入或许能实现，但性价比极低。而我们凭借自身技术，能够在控制成本的同时，实现高并发下的快速响应。

Q25：高并发场景下的响应速度问题及压力测试数据？

A25：通常情况下DataFocus的查询响应速度都是亚秒级，具体取决于问题的复杂度以及数据量的大小，常用查询请求的响应速度都很快，即便在大量用户同时使用的情况下也能保持高效。特别是在万人并发这种高负载场景下，特别适合DataFocus。这种场景完全基于大模型的方案基本难以应对，不仅成本极高，还很难达到可用状态。当然，若不惜成本投入或许能实现，但性价比低。而我们凭借自身技术，能够在控制成本的同时，实现高并发下的快速响应。

安全与权限体系

Q26：权限问题是如何解决的？

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

Q27：权限控制具体能举个例子吗？

A27：在系统中会定义角色，系统内有众多资源，像数据表、数据源、数据集等。以数据集为例，可针对角色进行配置，比如规定某些字段不展示给该角色，像品牌等于或不等于特定内容的数据。配置完成后，该角色下的用户访问表或数据集时，就会受到权限限制。每次查询时，系统会将对应权限信息融入查询过程。

Q28：不指定某张表作为数据源，如何保障准确性？

A28：FocusGPT 智能体支持智能选表的功能，当不指定某张表作问答数据源，需从一定范围库表作答时， FocusGPT 会自动在用户有权限的数据表列表中，依据用户问题理解意图，寻找匹配数据。

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

  
  

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

  
  

为保障准确率，一是数据表描述信息要写得更具体，便于模型精准定位；二是别一次性给模型过多表，可通过权限设定划分，不同角色用户分配几十张表，从少量表中查找，准确率会比从海量表中找高。

企业应用与集成

Q29：多轮问答最大支持轮数是多少？

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

Q30：与企业内部 AI 助手（钉钉、企业微信）集成能否实现？

A30：这可以理解成两个问题。第一个问题是，能否与企业内部部署的 AI 大模型集成？如果企业内部的大模型服务提供标准的接口的话，比如兼容 openai 的接口规范，可以在 DataFocus 系统配置中直接配置接入。第二个问题是，能否与企业微信，钉钉，飞书等 IM 软件集成？DataFocus 的系统配置页面中可以通过全局设置配置企微，钉钉和飞书。

Q31：知识库要怎么整理？

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

Q32：用 Dify 做 Chat BI 合适吗，难点是什么？

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

Q33：现在还停留在数据可视化吗？数据 BI 不是应该往趋势预测，归因分析这些高维度能力发展吗?

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

Q34：请问归因分析和数据洞察有落地的思路吗？

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

Q35：归因分析是否需要基于已有的问答过程？

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

Q36：从成本控制方面考虑，API 调用计费模式和传统的 BI 授权模式有什么差异？

A36：从成本控制角度看，API 调用计费模式和传统 BI 授权模式差异明显。传统BI授权模式通常是预先付费购买授权，无论实际使用量如何，费用相对固定。而API调用计费模式采用按需付费方式，用户根据实际调用 API 的次数或数据量来支付费用。这种模式下，成本与实际使用紧密挂钩，避免了资源浪费，相比传统模式成本更低且更为公平合理。

Q37：相比 Excel 的优点和不足是什么？

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

Q38：与 Tableau AI 有什么区别？

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

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

以上就是本次分享的内容，谢谢大家。