Databricks AI 产品深度体验心得

在中文互联网上少见 Databricks 的产品体验，恰逢公司数据库、数据处理计算正在迁移到 Databricks 上，也算是深度体验了一下 Databricks 当前的 AI 产品线，有一些自己的感想，不吐不快。

Genie Space

Genie Space 是一个通过自然语言交互、使用 SQL 从数据库获取对应数据，并做简单可视化展示的 Data Agent。这个概念本身看起来很好，很吸引人，但是 AI 获取数据的准确性和稳定性堪忧。尤其是在复杂要求和多数据库联合时有待加强。

Genie Space 提供客制化修改指令和范式的功能。这是在一个底层的技术黑盒上搭建范式，不透明的底层指令和构建的客制化指令相冲突，让本应该加强能力的设置反而成为了阻碍。

例如：当询问「过去一个月的销售额」，语义可以有很多种解释，是上个月，还是过去 30 天，抑或是月初到今天。尽管在客制化的指令中定义了「过去一个月」是指上个月，但是如果和底层黑盒中的设置指令相冲突，模型会随机根据一种定义选择回答。

当然这种情况可以通过测试发现并调整。但是对于指令的不完全掌控使得后续的测试和调整十分困难。尤其是当多个有歧义的条件结合在一起再加上跨表格查询，这在工程学上简直是灾难。

这也引出了其他两个问题。

一，Databricks 对于 Git 的支持很有限，只能通过 Web UI 交互，Genie Space 的客制化甚至不支持 Git 同步。用户只能通过 script 将整个客制化保存成 JSON，再通过 Git 同步，再手动加载覆盖。这简直是团队协作的灾难，CI/CD 基本没有。

二，Genie Space 无法选择基座模型，也无法修改交互方式。当自然语言输入的指令存在歧义的时候，最简单的是反问用户明晰需求，最不济也要指出问题。然而这些都因为底层黑盒被限制了，很难做到。

Genie Code

Databricks AI 的另一个产品是 Genie Code，这是一个专注于数据治理的 AI Coding Agent。你无法选择模型，看不到上下文窗口。这就像在高速上没有时速表，也不知道油门对应车子的马力。

举一个我本人的案例：Genie Code 花了 5 分钟，经过多轮修改和测试，最终才解决了一个十分简单的 error：! pip install XXX 的 cell 被设置在了 SQL 环境而非 Python 环境中。

严肃一点来说，Genie Code 在复杂工程环境中艰难达到及格线。在我参加的一场 Databricks 活动上，我看到 Databricks 工作人员使用 Claude Code 搭建 MVP，并让它运行在自家平台上。这个细节在我看来，反而凸显了 Genie Code 和成熟 AI coding 工具之间的差距。

毋庸置疑 Genie Code 在做一些 MVP 时十分有用，对于 Databricks 内部的知识库调用也十分顺畅。但是其设定的目标是数据治理和数据分析场景里的 coding agent，从基础功能上就比 Claude Code、Codex 这类目前最好用的 AI 工具要弱，更不用说复杂情况下的 harness engineering 以及工具调用了。

展望

Databricks 的 Genie Space、Genie Code，对于没有接触 AI 原生的人来说十分有吸引力。但是用在真正深度 AI 原生的工作流中有点玩具性质。

如果 Oracle + Codex/Claude Code 可以完全替代 Databricks 当前的 AI 产品，甚至更好用，那 Databricks 这个平台在 AI 方向的护城河到底在哪里？

以我个人的愚见，大力加强 Genie Code，使其达到和 GitHub Copilot 同样的水准，结合 Databricks 的数据库，成为一款为超级个体提供放大能力的 AI 工具，缩小和现阶段 T0 级别 AI 工具的差距。保持 Genie Code 的云端优势，同时给用户一定的自由度来修改工具本身。

在平台上，为组织专门设计 Genie Code 和 Genie Code 之间的通信协调架构。发挥云端优势，对于 session 历史进行管理和同步，以及项目进度信息的同步，重新设计一个 AI agent 协调协作同步的超级团队架构，减少沟通协调的阻力。这可能成为工具的亮点。