InfiniSynapse vs. Databricks Genie：语义抽取还不够，真正关键是 Agentic 分析

Databricks 最近给 Genie 的宣传语很锋利：

Genie 正在成为 Databricks 里最重要的数据分析方式，因为它可以从整个 Lakehouse 里抽取语义。

这个问题抓得很准。

大多数 AI 数据产品失败，并不是因为模型不会写 SQL，而是因为 Agent 对数据的理解不够深。它不知道哪个指标是官方口径，哪张表可信，哪个 dashboard 经过认证，哪个 notebook 里藏着真正的逻辑，哪份业务文档解释了字段含义。

Databricks Genie 是从 Databricks 世界里回答这个问题：从 Lakehouse、dashboards、notebooks、Genie Spaces、Apps 和外部知识源里抽取并路由语义，然后让业务用户通过一个 AI 入口提问。

InfiniSynapse 回答的是一个更通用、也更难的问题：

如果数据、语义、执行步骤和业务知识本来就没有统一在一个 Lakehouse 里，该怎么办？

这才是真正的差异。

Genie 正在成为 Databricks 的语义前门。

InfiniSynapse 则在构建一个 Agentic Analytics Workbench：连接实时数据源，把数据源绑定到高准确率知识库，让 Agent 使用一门 Agentic 友好的 SQL 语言，展示关键执行过程，并交付图表、SQL、文件和可审查报告。

这不是简单的“和数据聊天”。这是另一种让 AI 做数据分析的方式。

1. Genie 的关键思路：从 Lakehouse 里抽取语义

新一代 Genie 的方向并不浅。

Databricks 不是在说“我们加了一个聊天框”。它真正想说的是，AI 体验应该理解整个 Lakehouse 的语义表面：

• certified Genie Spaces；
• governed dashboards；
• Databricks Apps；
• notebooks；
• Google Drive、SharePoint 等外部知识源；
• 元数据和描述；
• 业务定义和经过验证的指标逻辑；
• 面向业务用户的移动端访问。

这个判断很清楚：如果企业信任的资产已经存在于 Lakehouse 里，Genie 就可以成为这些资产之上的自然语言入口。

这很强，因为企业分析里到处都是语义陷阱：

• 表名可能误导人；
• 两个 dashboard 对“活跃用户”的计算方式可能不同；
• notebook 里可能才有真正的转换逻辑；
• 某个指标可能只有在特定过滤条件下才成立；
• 同一个业务词在不同部门里可能完全不是一个意思。

Genie 的答案，是把 Databricks 资产体系当作语义底座。它试图为问题找到、路由并使用正确的可信资产。

这已经远远超过基础 Text-to-SQL。

但它仍然留下了一个更大的问题：

仅仅从现有平台资产中抽取语义，是否足以支撑真正的 Agentic 数据分析？

对很多企业来说，答案是否定的。

2. InfiniSynapse 的关键思路：把语义绑定到数据源上

InfiniSynapse 从另一个观察出发：

业务语义不应该只在事后被搜索出来，它应该明确绑定到 Agent 正在分析的数据源上。

这就是为什么数据库 + 知识库绑定，是 InfiniSynapse 最重要的设计之一。

数据库告诉 Agent 发生了什么。

知识库告诉 Agent 这件事意味着什么。

这句话看起来简单，但它会改变整个分析过程。

在当前 InfiniSynapse 控制台里，winclaw_cn 不只是一个 PostgreSQL 背后的业务数据库。它还是一个已经绑定知识库的数据源，对应的知识库是 winclaw_cn_telemetry_knowledge。

在 InfiniSynapse 里，数据源可以被启用、查询，也可以绑定解释其业务语义的知识库。

知识库页面展示了绑定关系的另一侧：

知识库不是一个泛泛的文档桶，而是和它所解释的数据库明确关联。

这解决的是元数据无法解决的问题。

比如一个 telemetry key：

download:tool:windows:x64:agent_excel

数据库可以统计它。schema 可以告诉你字段名叫 metric_key。dashboard 可以把它展示成一行。但这些都不足以回答：

• 这是下载意图，还是确认安装？
• agent_excel 是否属于 Office 自动化？
• 它是否应该归入文档工作流需求？
• 它是否适合出现在公开案例分析里？
• 它属于漏斗上游、激活阶段，还是工作量指标？

Agent 需要的是业务含义，而不只是列元数据。

InfiniSynapse 让这种含义变成 Agent 可调用的工具。在真实任务里，Agent 可以在运行 SQL 前先询问绑定知识库。

Agent 先查询绑定知识库，再用 SQL 验证可计算事实。

这就是“语义搜索层”和“语义操作层”的差别。

搜索可以召回文本。

绑定会告诉 Agent：当你分析这个数据库时，应该使用这套业务知识。

当然，这件事只有在知识库足够准确时才成立。低准确率 RAG 会误导 Agent。InfiniSynapse 的第四代知识库之所以重要，是因为数据库绑定知识不是装饰性上下文，而是分析工具链的一部分。

3. Genie 是强消费入口，InfiniSynapse 是分析工作台

Genie 正在成为 Databricks 业务用户消费可信资产的更好方式。

这是很有价值的产品方向。业务用户不应该知道哪个 workspace、dashboard、Genie Space 或 notebook 里有答案。AI 层应该能帮他们找到正确的可信资产。

InfiniSynapse 做的是另一件事：

让 Agent 像分析师一样，一步一步完成分析工作，同时留下人可以检查的轨迹。

所以 InfiniSynapse 首页更像 Agent 工作空间，而不是 dashboard 目录。

起点是一个业务任务，以及可选择的上下文：模型、Agent 模式、数据源、文件、浏览器和数据市场。

一个严肃分析任务很少是“一问一答”。它通常长这样：

1. 理解业务问题；
2. 找到相关数据源；
3. 检查 schema；
4. 补齐缺失的指标定义；
5. 做第一轮聚合；
6. 发现异常；
7. 生成中间表；
8. 接入另一个数据源；
9. 生成图表；
10. 写报告；
11. 保留 SQL 和文件供复核。

这是分析师的工作，而不只是聊天界面的工作。

InfiniSynapse 把任务当成一个工作对象。它可以在同一个任务里展示 SQL、结果表、图表和文件。

Task View 会展示 Agent 分析背后的 SQL 和结果表。

它也可以把中间分析状态转成可视化结果：

Agent 可以从查询到表，再到图表，同时保留可检查路径。

这一点很重要，因为企业不只需要答案，还需要可信、可检查、可复用、能进入决策的答案。

4. 很多 Data Agent 缺失的一层：Agentic 友好的 SQL 语言

这一点必须讲重。

InfiniSynapse 不只是连接数据库。它还定义了一门 Agentic 友好的 SQL 语言：InfiniSQL。

这是一个非常重要的产品选择。

大多数 AI 数据工具会选择两条路之一：

1. 让模型生成普通 SQL；
2. 让模型写 Python / pandas 代码。

这两条路在 demo 里都能跑。但一旦进入长链路 Agentic 工作流，就会变脆。

普通 SQL 适合单次查询，但真正做分析的 Agent 需要持续积累的工作空间。它要命名中间结果、复用中间结果、继续下钻，并从上一步继续做。

Python / pandas 很灵活，但给 Agent 的动作空间太大：变量、包 API、内存限制、对象生命周期、隐式副作用、环境错误和调试负担。Agent 会变成一个脆弱的程序员，而不是稳定的数据分析师。

InfiniSQL 是围绕 Agentic loop 设计的：

• connect：注册数据源；
• load：把数据源加载进分析 session；
• select ... as tableName：每次查询结果都变成一张具名表；
• session 表空间：前面的结果可以被后续步骤继续引用；
• train、predict、register：建模也留在同一个表式工作流里；
• 分布式执行和计算下推：分析不需要默认把所有数据拉到本地内存。

最关键的设计是 select ... as tableName。

这个小小的语法约束，比它看起来重要得多。

它强制每一步分析都留下一个有名字的产物。

于是一次 Agentic 分析会变成一条不断增长、可以检查的表链：

select ... as daily_metrics;
select ... from daily_metrics ... as funnel_summary;
select ... from funnel_summary ... as business_readout;

Agent 不需要每次追问都回去改一大段 Python notebook。它可以追加下一步。

旧结果不会消失。

人可以检查旧结果。

后续步骤可以复用旧结果。

所以 InfiniSQL 不是“又一个 SQL 方言”。它更像 Agentic 数据分析的工作协议。

Genie 强调在 Lakehouse 内部做深度数据理解。

InfiniSynapse 再往前加了一层：一门为长链路、多步 Agent 工作设计的语言和执行模型。

这可能是最容易被低估的差异。

5. 语义抽取 vs. 语义绑定 + Agentic 执行

Databricks 的信息可以概括成：

Genie 从 Lakehouse 中抽取语义，让业务用户能够提出复杂数据问题。

InfiniSynapse 的信息应该是：

InfiniSynapse 把语义绑定到数据源上，让 Agent 使用 Agentic 友好的 SQL 语言执行分析，并留下可审查的工作轨迹。

这不是同一种产品哲学。

语义抽取，是从现有资产里发现含义。

语义绑定，是把含义附着到数据源上，并在分析过程中使用它。

Agentic 执行，是把这些含义转成一系列工具调用、SQL 步骤、表、图表和报告。

这组组合才是 InfiniSynapse 的差异：

1. 数据库 + 知识库绑定 给 Agent 业务语义；
2. InfiniSQL 给 Agent 一个稳定的多步数据工作语言；
3. Task View 给人类可审计轨迹；
4. 图表和文件 把工作转成交付物；
5. 多源连接 让分析可以从数据本来所在的地方开始。

下面这个最终报告就是一个小例子。Agent 会把数据库事实和知识库解释分开。这正是严肃 Data Agent 应该做到的。

结果不是一段生成式回答，而是把可计算事实和绑定知识库提供的业务定义分开呈现。

6. 更深入的对比

这比“谁有聊天框”更有价值。

真正的问题是：一个产品如何给 Agent 足够的理解能力和足够稳定的执行纪律。

Genie 强调来自 Lakehouse 的语义理解。

InfiniSynapse 强调语义绑定、Agentic SQL 和可检查执行。

7. 为什么这件事重要

Data Agent 这个类别正在经历三个阶段。

第一阶段是 Text-to-SQL：

AI 能不能写查询？

第二阶段是语义 grounding：

AI 能不能理解应该信任哪些数据和定义？

第三阶段是 Agentic 执行：

AI 能不能完成多步分析，保留状态，询问知识，安全执行，展示过程，并交付产物？

Databricks Genie 正在从第一阶段强力进入第二阶段，并把这种能力包装成围绕 Databricks 资产的业务用户体验。

InfiniSynapse 想直接进入第三阶段。

这就是为什么 InfiniSQL 重要。

这就是为什么数据库绑定知识重要。

这就是为什么 Task View 重要。

也正因为如此，“和你的数据聊天”已经不是足够好的产品描述。

真正的产品，是围绕 Agent 的整套分析系统：

• 它如何理解业务含义；
• 它如何决定下一步；
• 它如何执行；
• 它如何记住中间结果；
• 它如何避免凭空发明语义；
• 它如何展示证据；
• 它如何交付有用结果。

8. 结语

Databricks Genie 是一个重要信号：Lakehouse 内部的 BI 和数据分析会越来越 AI-native、语义化、面向业务用户。

InfiniSynapse 则是另一个方向的重要信号：未来的 Data Agent 不只需要语义抽取，还需要语义绑定、Agentic 友好的 SQL 语言、可检查执行过程和可交付产物。

如果你的公司已经深度运行在 Databricks 上，Genie 是可信 Lakehouse 资产上的自然 AI 层。

如果你的公司需要一个 Agent 连接实时数据源，把业务知识绑定到数据源上，完成多步分析，生成具名中间表，展示 SQL 和图表，并产出可审查报告，那么 InfiniSynapse 正在解决更完整的 Agentic analytics 问题。

下一代数据分析的胜负，不会由谁的聊天框更漂亮决定。

真正决定胜负的是：谁能给 Agent 足够深的语义、足够稳定的工作语言，以及足够可信的执行轨迹。

这正是 InfiniSynapse 正在构建的方向。