Transforming solar and wind maintenance reports with Genie and AI agents
TL;DR · AI 摘要
Databricks Genie与AI代理结合,将太阳能和风能维护报告的PDF转换为可查询数据层,实现自然语言分析。
核心要点
- Plenitude使用Databricks Genie和Agent Bricks将PDF转换为统一的可查询数据模型。
- 用户可通过自然语言提问,分析跨电站的趋势并生成可视化图表。
- 该方案支持行级安全访问和预测性维护,提升维护效率。
结构提纲
按章节快速跳转。
- §引言
Plenitude利用Databricks Genie和Agent Bricks将非结构化PDF转换为可查询数据模型。
当前太阳能和风能维护报告以PDF形式存在,但难以进行跨电站分析。
解决方案通过事件驱动方式解析PDF,并使用LLM提取结构化数据。
提取的元素以JSON格式存储在Delta Lake中,并保留版本历史。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- 基于AI代理的PDF到数据分析架构
- 数据处理流程
- PDF解析与LLM提取
- Delta Lake存储与版本控制
- 核心功能
- 自然语言查询
- 跨电站趋势分析
- 行级安全访问
金句 / Highlights
值得收藏与分享的关键句。
Plenitude使用Databricks Document Intelligence AI Functions,如ai_parse_document,从PDF中提取文本块、表格、图表和元数据。
该架构支持按时间、类别和地理位置过滤数据,并能追踪每个洞察回原始PDF。
维护报告不再是静态文件,而是可进行高级分析和代理推理的持久数据层。
通过 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"