如何停止搜索数据，开始将其喂给 AI 代理
想象你以高级数据工程师的身份加入一家新公司。你获得了云访问权限，看到 BigQuery 中有数百张表、Cloud Storage 中有数千个文件，以及零散的日志。当前的客户档案在哪里？这张表中哪一列负责计算不含增值税的收入？通常，找到答案会变成一场侦探调查，在 Slack 上没完没了地提问。
Google 决定是时候采取行动了，推出了 Knowledge Catalog。之前这项服务叫 Dataplex，但这次品牌重塑不仅仅是换个名称。这是一个将枯燥的表格列表转变为活的"知识图谱"的尝试，不仅人类能理解，LLM 代理也能理解。
来自 Google Cloud Platform 的 knowledge-catalog 仓库是一套实用工具和示例集合，展示了如何充分利用这个平台。
为什么我们还需要另一个数据目录
大多数数据目录的问题在于它们是静态的。你描述一次数据，一周后描述就过时了。Knowledge Catalog 试图通过 AI 工具解决这个问题。它构建一个动态图谱，将结构化表格和非结构化文档与共享的业务上下文链接起来。
对于开发者来说，这意味着你现在可以向 AI 代理传递的不仅是"这是数据库 API"，而是"这是一个语义层，数据的相互关系在这里很清楚"。
仓库包含帮助自动化日常任务的工具：
- 自动填充目录元数据，无需手动输入。
- 为 RAG 系统（检索增强生成）创建上下文。
- 构建用自然语言"对话"数据的代理示例。
仓库里有什么有趣的内容
这个项目本身不是一个"盒装"产品。它更像是一套构建块，面向在 GCP 上构建复杂数据基础设施的人。
我将其内容分为三个逻辑部分。
元数据富化工具
处理数据最枯燥的部分是描述列。在仓库中，有使用 AI 进行自动标注的示例。系统查看表内容，理解第 0 列包含客户 ID，然后自动写入标签和描述。这在大规模项目上可以节省数周时间。
AI 代理的上下文
这可能是最相关的部分。如果你尝试过为内部公司数据编写聊天机器人，你就会知道：机器人经常出错，因为它不理解业务逻辑。例如，它可能会把"注册日期"和"最后活动日期"搞混。
Google 的开发者建议使用 Knowledge Catalog 作为链接机制。仓库展示了如何提取语义上下文并将其提供给 LLM。结果是，代理不仅按关键词搜索，还能理解知识图谱中的关系。
与 Cloud Shell 的集成
在 README 中有一个快速启动按钮：
如果你想探索示例但不想设置本地环境和 SDK，这很方便。整个仓库可以在几分钟内在 Google 的云环境中部署。
如何在实践中使用
假设你有一个任务：构建一个回答分析师关于大量文档和表格问题的机器人。
通常，你会从编写一个简单的 RAG 开始。但如果没有数据目录，你的 RAG 将是"盲目的"。使用这个仓库的开发成果，你可以：
- 通过 Knowledge Catalog 为所有源建立索引。
- 使用现成的脚本进行元数据提取。
- 通过提供的代码示例将代理连接到动态知识图谱。
结果是，机器人不仅知道文档的文本，还知道表的结构、所有者以及该数据的可信度级别。
技术细节
该项目采用 Apache 2.0 许可证分发。重要的是要理解这不是官方 Google 产品，正如免责声明中诚实说明的那样。这意味着支持取决于社区，示例的 API 可能会发生变化。
示例的主要语言是 HTML 和 Python（尽管由于文档结构，HTML 经常在 GitHub 元数据中高亮显示）。大多数解决方案都绑定在 Google Cloud 服务上，所以如果你在另一个云或本地部署，这个项目可能只能作为概念示例对你有用。
谁应该查看这个仓库
如果你是一个厌倦了在数据目录中手动填写描述的数据工程师，或者是一个正在寻找为代理提供更多关于公司数据上下文的 AI 开发者，这个项目适合你。
它有近 7,000 颗星，对于一个专业工具包来说已经很多了。这是一个好信号：里面的解决方案正在工作，并且实际上已在生产中使用。
最好从 1 文件夹开始。这是将分散的文件转换为逻辑连接系统的最易理解的实现所在。仓库本身的文档有时比较简洁，所以准备好查阅 Knowledge Catalog 和 Dataplex 的官方 Google Cloud 文档。
这个项目看起来是那些从简单聊天机器人转向严肃的企业 AI 系统的人的绝佳起点，在这些系统中，数据质量和上下文理解是第一位的。
相关项目