T
traeai
登录
返回首页
Databricks

Transforming solar and wind maintenance reports with Genie and AI agents

8.5Score

TL;DR · AI 摘要

Databricks Genie与AI代理结合,将太阳能和风能维护报告的PDF转换为可查询数据层,实现自然语言分析。

核心要点

  • Plenitude使用Databricks Genie和Agent Bricks将PDF转换为统一的可查询数据模型。
  • 用户可通过自然语言提问,分析跨电站的趋势并生成可视化图表。
  • 该方案支持行级安全访问和预测性维护,提升维护效率。

结构提纲

按章节快速跳转。

  1. Plenitude利用Databricks GenieAgent Bricks将非结构化PDF转换为可查询数据模型。

  2. 当前太阳能和风能维护报告以PDF形式存在,但难以进行跨电站分析。

  3. 解决方案通过事件驱动方式解析PDF,并使用LLM提取结构化数据。

  4. 提取的元素以JSON格式存储在Delta Lake中,并保留版本历史。

思维导图

用一张图看清主题之间的关系。

查看大纲文本(无障碍 / 无 JS 友好)
  • 基于AI代理的PDF到数据分析架构
    • 数据处理流程
      • PDF解析与LLM提取
      • Delta Lake存储与版本控制
    • 核心功能
      • 自然语言查询
      • 跨电站趋势分析
      • 行级安全访问

金句 / Highlights

值得收藏与分享的关键句。

  • Plenitude使用Databricks Document Intelligence AI Functions,如ai_parse_document,从PDF中提取文本块、表格、图表和元数据。

    第3段

    ⬇︎ 下载 PNG𝕏 分享到 X
  • 该架构支持按时间、类别和地理位置过滤数据,并能追踪每个洞察回原始PDF。

    第4段

    ⬇︎ 下载 PNG𝕏 分享到 X
  • 维护报告不再是静态文件,而是可进行高级分析和代理推理的持久数据层。

    第4段

    ⬇︎ 下载 PNG𝕏 分享到 X
#Databricks#AI代理#数据处理#自然语言分析#能源维护
打开原文

通过 Genie 和 AI 代理转变太阳能和风能维护报告 | Databricks 博客

跳至主要内容

客户

2026年6月8日

通过 Genie 和 AI 代理转变太阳能和风能维护报告

Plenitude 如何使用 Databricks Genie 和 Agent Bricks 将非结构化的维护 PDF 转换为可搜索的数据层,并在太阳能和风能电厂中实现自然语言分析。

作者:Maria Vallarelli

摘要

  • Plenitude 在 Databricks Genie 上构建了一个基于代理的系统,将太阳能和风能维护的非结构化 PDF 转换为统一的、可查询的数据模型。
  • 该解决方案结合使用 Genie、Unity Catalog 语义元数据和 AI 函数,使用户能够通过自然语言提问,并在电厂和时间维度上创建可视化。
  • 早期成果包括更快的多电厂分析、具有行级安全性的受控自助访问,以及对关键资产(如逆变器)进行预测性维护的基础。

通过 AI 代理从维护 PDF 转变为可操作的洞察

太阳能和风能电厂的操作和维护供应商通常以 PDF 的形式交付报告,关键信息分散在自由文本、表格和图像中。这种格式易于访问但难以扩展:随着资产数量的增加,团队必须手动阅读每份文档以了解故障、趋势或重复问题,这使得跨电厂的比较变得缓慢且不一致。

Plenitude 和 Databricks 构建了一个基于代理的系统,将这些 PDF 维护报告转换为结构化数据。核心思想很简单:将文档转换为数据,然后使用 AI 代理从这些数据中提取可操作的见解。现在用户可以通过自然语言提问,分析时间趋势,比较电厂并导出结构化输出,而无需逐个浏览报告。

从 PDF 到数据分析的基于代理的架构

该解决方案从事件驱动的电厂级 PDF 报告摄入开始。每份新报告都会触发一个 Databricks 作业,该作业解析文档并应用基于 LLM 的提取。提取的元素以 JSON 格式序列化并存储在 Delta Lake 中,Delta Lake 保留完整的版本历史,以便审计和重放。

图1:用于多电厂分析的自动化文档智能架构

为了解决维护信息几乎完全存在于非结构化 PDF 中的根本问题,Plenitude 使用了 Databricks 文档智能 AI 函数——特别是 ai_parse_document,从每一页中提取多种类型的元素,包括文本块、表格、图表和元数据。每个元素都通过诸如电厂、报告周期、页码和内容类型等属性进行丰富,并且每条记录都保留直接链接回原始报告,以实现可追溯性。

这种结构解锁了强大的功能:

  • 按时间、类别和地理位置进行过滤。
  • 识别内容类型并使用空间坐标。
  • 将每个见解追溯回原始 PDF。
  • 与 BI 工具和数字代理集成,而无需更改底层文档。

维护报告不再是静态文件,而是成为准备进行高级分析和代理推理的持久数据层。

在 Databricks 上的数据处理:从 PDF 到 Delta Lake

架构分为三个主要层次:摄入和解析、数据结构化和基于代理的交互。

图2:提取 - 查询 – 推理

步骤1:解析

使用 ai_parse_document,该流程从每一页中提取文本、表格和元数据,并将其序列化为结构化的 JSON 对象。即使是最复杂的表格也能完整地被捕捉,包括其在页面上的位置和 HTML 表示。

步骤 2:标准化和存储

对于每一页(page_id)和每一个对象(id),系统会在 Delta Lake 表中创建一行。每一行包含以下内容:

  • 提取的 JSON 内容。
  • 页面和对象标识符。
  • 表示页面上边界框的坐标(coords)。
  • 内容类型(例如文本或表格)。
  • 高价值的元数据,如月份、年份、文件名、类别和国家。

这种标准化模型将 PDF 转换为统一的、可查询的数据集,便于与其他数据源进行连接,同时保留了与原始文档的完整可追溯性。

步骤 3:Genie 空间和 Agent 模式

在这一精心构建的数据层之上,Plenitude 创建了一个专用的 Genie 空间,然后利用 Genie 的 Agent 模式对数据进行深度研究。Genie 使用结构化的 Delta Lake 表作为其主要上下文,并允许用户使用自然语言与维护数据进行交互。

当用户提出一个问题时,Genie 会:

  • 使用 Unity Catalog 中的语义元数据来识别可用的表和列。
  • 借助详细的列描述、精选的知识库和 SQL 示例来指导查询生成。
  • 生成并执行针对结构化层的 SQL 查询。
  • 返回答案、可视化结果,并可选择导出结果。

图 3:Genie:从问题到可视化

这种设计使 Genie 能够理解维护数据的业务语义及其底层结构,从而产生准确且具有上下文感知的答案。

图 4:Genie 工具流和执行管道

元数据和指令对 Genie 的重要性

为了从复杂的 PDF 派生数据集中获得可靠的结果,仅有上下文是不够的。Plenitude 发现,两个设计模式至关重要:丰富的元数据和对 Genie 空间的明确指令。

元数据作为与 Agent 的契约

明确的表和列描述告诉 Genie 每个字段的含义以及如何使用。例如,page_id 识别原始报告中的源页面,type 表示元素是文本还是表格,coords 编码了空间位置,content 包含提取的文本或表格表示。这些元数据将原始 JSON 转换为 Genie 可推理的可理解知识。

通用指令作为操作基础

当数据碎片化或跨越多个页面时,添加到 Genie 空间本地知识库中的领域特定指令变得至关重要。Plenitude 对处理跨页表格、忽略 HTML 艺术品、排除标题行和应用特定于工厂的过滤器进行了编码。

一个实际的例子:即使拥有完整的元数据,如果 Genie 对 YTD 列求和或忽略了缺失的月份,它可能会计算出错误的季度总计。通过添加明确的指令,如“仅使用月级列,从不使用 YTD 字段”和“在求和之前验证所有必需的月份都已存在”,团队为 Genie 提供了确保结果一致的操作保障。

这些特定于 Genie 空间的指令,结合来自 Unity Catalog 的元数据,有助于 Genie 正确地应用逻辑来解释数据。

使用 Genie 和 Agent Bricks 实现可扩展的 Agent 工作流

虽然 Genie 在结构化维护层之上提供了强大的研究代理体验,但 Plenitude 也需要可重复的工作流程和编排,以支持日益增长的一系列使用场景。Agent Bricks 是这一演进的下一步。

借助 Agent Bricks,Plenitude 可以从“LLM 加提示”模式转向代理式工作流程,这些工作流程可以代表维护分析师和工程师执行一系列操作。由 Delta Lake 表、元数据和指令支持的 Genie 所使用的相同精选数据,可以被使用 Agent Bricks 构建的 Supervisor 风格代理重复使用,以实现以下目标:

  • 将复杂问题分解为更小的分析任务。
  • 调用 Genie 工具流程生成并执行 SQL。
  • 触发下游操作,如报告生成或警报创建。

过去需要手动连接提示、工具和验证逻辑的工作,现在可以集中到 Agent Bricks 中,与管理数据的同一 Databricks 平台进行统一管理。

通过自动液态聚类优化性能

由于代理驱动的查询是探索性和动态的,传统的基于 Z-ORDER 的调优并不总是最佳选择。Plenitude 发现,随着新报告、用户和问题的出现,访问模式会不断演变,这使得手动聚类难以持续维护。

相比之下,自动液态聚类通过学习表的实际使用方式,并据此调整布局,从而减少了对前期索引设计和持续调优的需求。这一点在概念验证和早期上线阶段尤为重要。在这一背景下,自动聚类是 Delta 表上代理和 LLM 驱动工作负载的首选方案。

为 Genie Rooms 提供数据访问安全

维护数据通常有特定于国家或地区的访问要求。为了统一执行这些规则,Plenitude 使用行级安全性,结合 Unity Catalog 和表进行管理。

一个 Unity Catalog 函数会确定当前用户可以访问哪些国家,并返回一个列表或关键字 ALL(如果用户有完全的访问权限)。然后,表会根据该函数过滤行,因此每个用户只能看到其被授权访问的国家的数据。

当用户通过 Genie Room 进行交互时,所有查询都运行在过滤后的表上,因此行级安全性会自动应用。这意味着用户可以用自然语言提问,但只能看到他们被允许查看的数据。同一数据集同时支持 Genie、代理和 BI 工具,而可见性则根据用户进行调整。

未来改进:迈向预测性维护

由于维护报告包含开放事件和故障详情,结构化数据模型是预测性维护的坚实基础。逆变器就是一个很好的例子:故障可能导致每个单位损失数兆瓦时的电量,而重复问题通常首先出现在维护笔记中。

通过分析随时间推移的故障模式,Plenitude 可以:

  • 识别潜在的记录问题。
  • 检测早期预警信号。
  • 优先考虑需要进一步调查的工厂。
  • 将更高质量的事件历史数据输入预测模型。

基于代理的系统将这些信号转化为可访问的分析、趋势和可视化,使团队能够提前预知问题,而不仅仅是被动应对。

在之前的方法中,分析仅限于单独阅读报告,这使得难以建立历史趋势、比较工厂或生成结构化输出。创建图表、导出结果或结合多个报告中的见解最多只能手动完成,而且通常不可行。

通过使用 Databricks 上的 Genie Agent 模式和一个适合代理的数据模型,Plenitude 可以:

  • 跨时间、跨工厂探索维护数据。
  • 生成可视化图表并导出结果,包括 PDF 输出。
  • 检测早期信号和重复模式。
  • 扩展分析,而无需增加手动工作量。

通过结合结构化数据、业务元数据和人工智能推理,系统生成的分析、趋势和可视化支持问题的早期检测和预测,而不仅仅是回顾性报告。

了解更多关于 Databricks Genie 和 Agent Bricks 的信息。

在您的邮箱中获取最新文章

订阅我们的博客,即可将最新文章发送到您的邮箱。

注册

查看所有博客

slice-start id="_gatsby-scripts-1"

slice-end id="_gatsby-scripts-1"

AI 可能会生成不准确的信息,请核实重要内容