利用Databao加速数据分析工作流
Guja 目前在嘉年华海事（Carnival Maritime）担任分析工程师，该公司是全球最大的休闲旅游和邮轮公司之一。作为我们最早期的 Alpha 用户之一，Guja 试用了 Databao 的上下文引擎（Context Engine）。这是一个命令行工具（CLI），能够从数据源中提取模式（schema）和元数据，从而让 AI 智能体能够可靠地对数据进行推理。
我们与他进行了交流，探讨了他为何被 Databao 所吸引，以及它是如何帮助他加快在复杂数据环境下的即席分析工作的。
当你发现 Databao 时，你试图解决什么问题？
我当时在寻找数据发现方面的帮助——本质上，我需要一种方法来封装我们的数据集市，以便我能与数据进行“对话”。
你如何描述在嘉年华海事工作时所接触的数据？
邮轮上存在的一切最终都会转化为某种数据，从引擎温度到天气预报，应有尽有。正因如此，数据环境非常复杂。它分布在众多的数据库、领域、模式和团队中，要理解数据背后的完整上下文非常困难。
在使用 Databao 之前，你是如何尝试与数据“对话”的？
除非你只处理单个数据库中的单个表，否则必须要有上下文。大约 95% 的工作量都在向智能体解释上下文，只有 5% 是实际的提问。
我们研究过现有的解决方案，但没有一个是真正合适的。大多数方案只能解决工作流的一部分，或者存在供应商锁定（vendor lock-in）的问题，而我希望能避免这种情况。
因此，我尝试自己构建一个数据聊天机器人，通过拼凑模式提取引擎、上下文生成器和 Text-to-SQL 模型来实现。但最终，它们之间的兼容性并不好。
向智能体提供上下文到底难在哪里？
当你对数据库进行即席分析并开始使用大模型（LLM）或智能体时，你必须解释这些表代表什么、它们之间如何关联、连接（join）应该如何执行，以及业务或技术背景是什么。
如果大模型或智能体无法真正理解这些背景，你很快就会陷入一种心理状态：仅仅因为大模型无法生成正确的 SQL 或答案，你就会开始怀疑自己的模式或表结构设计得不好。
实际上，问题往往出在缺乏上下文，而不是数据建模不行。
这就是为什么能够从数据库中提取模式和上下文并将其提供给大模型或智能体的工具非常有用——它们有助于填补这一空白，减少这种心理和技术上的摩擦。
Databao 是如何改变你的工作方式的？
我可以花更多时间在分析上，而不是数据管道的搭建上。
如今，分析工程师将大部分时间花在数据清洗和管理上，而不是进行分析，这几乎已成为常态。在即席分析工作中尤其如此。
假设你有一天的时间来回答一个问题。你可能直到最后 20 分钟才有时间去构建仪表盘，因为你花了一整天的时间仅仅是为了整合数据。
数据工程师负责将数据从 A 搬运到 B，而分析工程师则负责将 KPI 从 A 转化到 B。你在努力平衡工程工作与分析结果。问题在于，目前的这种平衡被打破了：工程工作占比过重，只有在一切其他事项都处理得当时，分析工作才能得以开展。
我们为何构建 Databao
Guja 在向 AI 提供上下文方面遇到的挑战，正是我们构建 Databao 上下文引擎的原因。它是一个 Python 库，可以从数据库和 dbt 项目等数据源中自动生成受控的语义上下文。它在你的本地环境中运行，并可与任何大模型集成，从而提供准确、具备上下文意识的回答。
上下文引擎是 Databao 实现自助式分析平台的一部分。如果你所在的团队希望让业务用户能更方便地访问数据，我们很乐意与你交流。请联系我们以启动概念验证（POC）、讨论你的需求并分享反馈。