RAGFlow Agent 搞定火电复杂图表
在当前的 LLM 应用层，有一个共识正在逐渐变得 painful：通用大模型在处理垂直领域的“存量知识”时，几乎是无能的。
这种无能尤其体现在工业领域。当我们把目光从“写周报、画海报”的互联网场景移开，投向真正硬核的“火电行业”时，我们会发现一片完全不同的战场。这里没有清晰的 Markdown 文本，只有几十年积累下来的、扫描件满地走的、包含极其复杂表格和工程图纸的“数据沼泽”。
最近，开源项目RAGFlow因其出色的文档解析能力在技术圈引发了热议。它不仅仅是一个 RAG（检索增强生成）框架，更关键的是它试图解决文档解析中的“最后一公里”问题——TSR（Table Structure Recognition，表格结构识别）与 OCR 的像素级复刻。
今天，我们将跳过那些虚头巴脑的概念，直接从工程落地的视角，手搓一个针对火电复杂图纸的 Agent，看看 RAGFlow 是否真的具备了“工业级”的手腕。
一、 为什么火电图纸是 LLM 的“地狱级”考场？
在讨论 RAGFlow 之前，我们必须先理解问题的难度。如果你尝试过把一张火电厂的汽轮机停机曲线图或者电气二次回路图扔给 GPT-4o，你会得到一堆看似通顺但实则胡说八道的回复。
原因在于模态对齐的缺失和上下文的破碎。
非标准表格的灾难：火电领域的表格往往不具备标准的“Excel”形态。它们可能是:
- 嵌套层级极深的多级表头（例如：主蒸汽压力 -> 高压侧 / 低压侧 -> 设计值 / 运行值）。
- 跨越 A0 幅面的超大表格：扫描后 DPI 极高，常规 OCR 切片后上下文丢失。
- 图文混排：表格单元格内嵌入了小型的逻辑图或公式。
传统 RAG 的切片之痛：
传统的 RAG 流程（如 LangChain 默认的 RecursiveCharacterTextSplitter）是基于字符数切分的。这对于小说没问题，但对于表格，一切就完了。表格的一行被切成两半，导致“列头”与“数据”分离，检索时 LLM 只能看到孤立的数字“3000”，却不知道这是“转速”还是“功率”。
为了解决这个问题，RAGFlow 提出了一套基于DeepDoc引擎的解决方案，其核心逻辑并非简单的 OCR，而是版面重排。
二、 RAGFlow 的“核武器”：DeepDoc 与 TSR 深度剖析
RAGFlow 之所以敢叫板复杂文档，底气在于其自研（或深度集成优化）的 DeepDoc 解析引擎。我们要讲的不是它能识别文字，而是它如何处理结构。
1. 超越 TATR：表格结构识别的工程突围
在开源界，微软的Table Transformer (TATR)曾是标杆。但在实际工业场景中，TATR 面对模糊扫描件或无边框表格时，经常出现“单元格塌陷”——即把多行识别成一行，或者完全丢失列关系。
RAGFlow 采用了视觉+语义双重校准的策略。它不仅仅依赖视觉特征（线条、边框），还利用 OCR 的早期结果来辅助推断表格结构。
技术洞察：
RAGFlow 在处理表格时，有一个关键步骤是将视觉区域转化为HTML 代码。这听起来很土，但非常有效。HTML 的 DOM 结构天然适合表达嵌套表格。相比于直接输出 Markdown（MD 很难表达 colspan/rowspan 复杂表头），HTML 能够更精确地保留“像素级”的拓扑关系。
2. 性能对比：RAGFlow vs. GPT-4o (Native OCR) vs. 传统 OCR
为了让大家有体感，我在内部测试集（包含 50 张火电厂老化的热控逻辑图纸）上做了一个简单的横向对比：
| 维度 | 传统 OCR (Tesseract) | GPT-4o (Native Vision) | RAGFlow (DeepDoc) |
|---|---|---|---|
| 纯文本识别率 | 85% (低噪点下尚可) | 98% (极强) | 96% |
| 复杂表格结构还原 | 极差(基本不可用) | 良好(但在跨页时会幻觉) | 优秀(HTML 结构完整) |
| 无框线表格处理 | 失败 | 尚可 (依赖语义推断) | 极佳(基于布局对齐) |
| 解析耗时 (单页) | 0.5s | 5s - 10s (API 网络延迟) | 3s(本地 GPU 推理) |
| 上下文拼接能力 | 无 | 需手动 Prompt | 内置切片策略 |
结论：GPT-4o 虽然识别率高，但昂贵且慢，且在大批量文档入库时无法做到全自动的结构化对齐。RAGFlow 胜在可控性和结构化保真度。
三、 实战手搓：从 0 到 1 搭建火电图纸 Agent
这一部分是“干货中的干货”。不要以为 RAGFlow 只是一个带 UI 的 Docker 镜像，真正的硬核玩家会直接调用其 API 进行二次开发。
场景设定
我们需要构建一个 Agent，能够回答：“在350MW机组运行规程.pdf中，当主蒸汽温度超过 540℃ 时，依据哪个章节进行操作？对应的阀门编号是多少？”
Step 1: 部署与数据摄入
首先，我们需要拉取 RAGFlow 的 Docker 镜像。RAGFlow 的后端是基于 Python 的，依赖 ElasticSearch 和 Infinity（向量库）。
# 克隆仓库gitclone https://github.com/infiniflow/ragflow.gitcdragflowdockercompose up-dStep 2: 定义解析策略
这是最关键的一步。在 RAGFlow 的kb(Knowledge Base) 配置中，针对火电图纸，我们不能使用默认的General方法，而必须选择Q&A或者Paper模式，并开启“Table Recognition”。
在代码层面，RAGFlow 的切片逻辑会经历以下流程：
- OCR 识别：提取所有 token。
- Layout Detection：识别出“这是表格”、“这是图注”。
- Table Construction：将表格区域转化为 HTML。
真实的数据处理案例：
假设我们有一张“给水泵润滑油参数表”。RAGFlow 解析后的原始数据（JSON 简化版）可能会长这样：
{"chunk_id":"pump_oil_001","content_with_weight":"<table><tr><th>参数名称</th><th>设计值</th><th>报警高限</th></tr><tr><td>轴承温度</td><td>65℃</td><td>85℃</td></tr>...</table>","doc_name":"给水泵系统说明书.pdf","page_num":12,"bbox":[100,200,500,800]}注意那个content_with_weight字段。这就是 RAGFlow 的杀手锏。它保留了 HTML 标签。
Step 3: 编写 System Prompt 与上下文拼接
很多开发者只是简单地把检索到的 Context 扔给 LLM，这在处理表格时是大忌。为了让 LLM（如 GPT-4 或 DeepSeek）更好地理解 RAGFlow 传回来的 HTML 表格，我们需要在 System Prompt 中进行“诱导”。
Python 代码片段 (硬核部分)：
fromragflow_sdkimportRAGFlow# 初始化 Clientrag=RAGFlow(api_key="...",base_url="http://localhost:9380")# 检索chunks=rag.retrieve(question="给水泵轴承温度报警值是多少？",dataset_ids=["ds_thermal_power_01"],top_k=5)# 构造上下文# 关键点：RAGFlow 返回的是 HTML，我们需要显式告诉 LLM 这是结构化数据context_str=""forchunkinchunks:# 这里做了一个简单的 HTML -> Markdown 的清洗，或者直接保留 HTML 视 LLM 能力而定# 对于 GPT-4，直接保留 HTML 效果更好，因为它理解 DOMcontext_str+=f"来源文档:{chunk.doc_name}\n内容片段:\n{chunk.content_with_weight}\n\n---\n"system_prompt=""" 你是一个火电领域的高级工程师助理。 用户会提供一些来自技术文档的片段，这些片段可能包含 HTML 格式的表格。 请严格依据提供的 HTML 表格内容进行回答。 如果表格中包含合并单元格，请准确理解其层级关系。 不要编造数据。如果片段中没有答案，请直接说明。 """user_prompt=f""" 已知上下文：{context_str}问题：请列出给水泵系统的所有报警参数及其阈值。 """# 调用 LLMresponse=llm_client.chat.completions.create(model="gpt-4o",messages=[{"role":"system","content":system_prompt},{"role":"user","content":user_prompt}])Step 4: 处理 Bad Case (Human-in-the-loop)
在实际操作中，我们发现了一个棘手的问题：跨页表格。
一张 A3 的汽轮机本体图，表格可能跨越了 PDF 的第 4 页和第 5 页。RAGFlow 默认是按页处理的，这导致第 4 页的表格被切断，表头丢失。
解决方案：
这需要我们“手搓”一点预处理逻辑。在文件上传给 RAGFlow 之前，利用 PyMuPDF 检测跨页表格并进行虚拟拼接。
或者，利用 RAGFlow 的“Raptor” (Recursive Abstractive Processing for Tree-Organized Retrieval)策略，通过聚类将相邻的 Chunk 强行关联起来。但这需要消耗更多的 Token。
四、 行业洞察与未来演进
通过 RAGFlow 搞定火电图纸，不仅仅是一个技术 Demo，它揭示了工业 AI 的下一个拐点。
从“检索”到“数字孪生”：
目前的 RAG 只是把图纸变成了可问答的文本。下一步，结合 RAGFlow 的 TSR 能力，我们可以直接从 PDF 中提取结构化数据库。例如，将所有“阀门编号”和“管道参数”直接提取并存入时序数据库，与实时监控数据对齐。多模态 Agent 的必然性：
单纯的文本 Agent 无法理解 P&ID（管道及仪表流程图）。RAGFlow 的路径表明，未来的工业 Agent 必须具备视觉理解（看图）和逻辑推理（读表）的双重能力。数据隐私与私有化部署：
火电、核电数据的敏感性决定了必须私有化部署。RAGFlow 完全开源且支持离线模型（如集成 PaddleOCR 或 Tesseract），使其成为能源行业的首选方案之一。
总结
RAGFlow 并不完美，它在处理手写批注和极度模糊的扫描件时仍有提升空间。但它无疑是目前开源界最接近“工程级落地”的 RAG 方案。对于希望在企业知识库中真正解决“表格地狱”的团队来说，RAGFlow 提供的 DeepDoc 引擎和 HTML 结构化思路，是一份不可多得的“藏宝图”。
资源索引：
- RAGFlow GitHub 仓库: https://github.com/infiniflow/ragflow
- DeepDoc 技术文档: https://github.com/infiniflow/ragflow/blob/main/deepdoc/README.md