对比背景
在构建电力运维知识库等垂直领域RAG（检索增强生成）系统时，常常需要处理海量的PDF文档，其中包含大量设备参数表、检修周期表等。这类表格的特征是：列名多为短文本标签，单元格内容多为纯数值（如“15ms”、“1250A”）。如果直接采用常规的RAG流程（文档解析→分块→向量化→检索），会面临一个致命问题：主流的Embedding模型擅长捕捉自然语言语义，但对数值的编码能力极弱，“15ms”与“20ms”在向量空间中的距离几乎为零，导致检索准确率极低。为了解决这一痛点，技术团队通常需要在“纯向量检索方案”与“基于半结构化技术的混合检索方案”之间做出技术选型与架构演进。
对比对象定义
- 纯向量检索方案：将PDF文档解析后统一转换为文本，按固定长度或段落切分为Chunk，直接使用Embedding模型将所有文本和数值编码为高维稠密向量，检索时完全依赖向量相似度（如余弦相似度）召回相关内容。
- 基于半结构化技术的混合方案：在文档解析阶段，专门针对表格区域进行结构化识别，保留表格的行列二维关系；在存储阶段，将表格内容转化为键值对（KV）或Markdown/HTML等半结构化格式，结合关系型数据库或全文索引进行存储；检索时，采用“向量检索（处理语义描述）+ 结构化/精确检索（处理数值与标签）”的混合策略。
相同点分析
尽管两种方案在底层处理逻辑上差异巨大，但它们在RAG系统中的核心目标是一致的：
- 输入输出一致：均接受PDF等非结构化文档作为输入，最终为大语言模型（LLM）提供上下文，以生成准确的问答回答。
- 依赖基础组件类似：都需要文档解析器、文本分块器、Embedding模型以及向量数据库作为基础支撑组件。
- 应用场景重合：均致力于解决企业内部知识库的智能化查询问题，降低人工查阅文档的成本。
核心差异分析
这两种方案在处理PDF表格，特别是大量数值数据时，表现出截然不同的特性。差异主要来源于对“非结构化数据结构化”的理解深度不同。
技术架构差异
- 纯向量方案：架构简单，属于单向流水线。PDF解析器将表格平铺为一行行文本，随后按普通文本逻辑进行切分并送入向量库。系统边界清晰，但忽略了表格的二维拓扑结构。
- 半结构化方案：架构更为复杂，属于多路召回融合架构。需要引入具备表格识别能力的解析器（甚至视觉模型），将表格抽取为结构化数据对象（如JSON），并分流处理：文本部分走向量化，表格部分走结构化存储（如SQL或Elasticsearch），最后通过统一网关进行混合检索。
功能能力与数值处理
- 纯向量方案：数值处理能力弱。由于高维向量需要压缩整段文本信息，大量数值在压缩后失去了精确度。当用户查询“110kV某型号断路器合闸弹簧储能时间”时，系统无法区分“合闸时间”与“储能时间”的数值差异。
- 半结构化方案：保留了精确的数值与映射关系。通过将表格转换为“设备型号-参数名-参数值”的三元组，系统能够通过精确的字段过滤（如WHERE voltage=’110kV’ AND param_name=’储能时间’）直接命中目标数值，检索准确率大幅提升。
接入方式与改造复杂度
- 纯向量方案：接入成本低，通过标准化的API即可完成“输入文本-输出向量”的闭环，适合快速验证原型。
- 半结构化方案：开发改造量大。需要编写额外的表格解析适配器，处理跨行跨列的合并单元格，并设计结构化数据的存储Schema。同时，混合检索的融合排序（如RRF算法）也需要额外的开发工作。
性能表现
- 纯向量方案：对于长文本语义检索延迟较低，但在面对长表格时，如果整表作为一个Chunk，向量压缩会导致信息丢失；如果切碎，则行列关系断裂。
- 半结构化方案：结构化查询的延迟极低且稳定，不受数据量波动影响。但由于引入了多路检索，整体Pipeline的编排延迟会有所增加，需要权衡并发处理能力。
运维成本与使用边界
- 纯向量方案：运维简单，只需维护向量库的可用性。但不适合包含大量参数表、财务报表、工业控制指令等强数值依赖的场景。
- 半结构化方案：运维复杂，需要同时维护向量数据库与结构化存储（或搜索引擎），并关注两者之间的数据一致性。其使用边界在于，当文档中表格占比超过30%，且查询多涉及具体数值、阈值、型号匹配时，该方案是必选项。
对比表格
| 对比维度 |
纯向量检索方案 |
半结构化混合检索方案 |
| 解析策略 |
纯文本提取，忽略二维结构 |
表格区域专有识别，保留行列拓扑 |
| 数值处理能力 |
极弱（向量压缩导致数值精度丢失） |
极强（精确匹配，保留原始数值） |
| 检索准确率(数值类) |
低（约30%左右） |
高（可达85%以上） |
| 系统架构 |
单路召回，架构简单 |
多路召回+融合排序，架构复杂 |
| 开发与迁移成本 |
低，标准化API直接接入 |
高，需定制解析规则与存储Schema |
| 适用数据类型 |
纯文本、长段落、叙事性文档 |
设备手册、参数表、财务报表等 |
| 运维复杂度 |
低，单数据源维护 |
高，需保障异构数据源一致性 |
典型场景选择
- 场景A：规章制度与纯文本知识库
如企业内部的人力资源制度、休假政策查询。这类文档以连续的自然语言为主，用户提问多为“年假怎么折算”、“报销流程是什么”。此时纯向量方案完全胜任，且开发效率最高。 - 场景B：电力运维与设备参数查询
如本文开头提到的电力行业知识库，文档中充斥着“故障代码表”、“检修周期表”。用户查询多为“某型号断路器的合闸时间标准”。此时必须采用半结构化方案，否则系统将无法准确回答任何涉及具体参数的问题。 - 场景C：混合型研报与财务分析
文档既有大段的市场分析文字，又有嵌入的财务数据表。此时建议采用半结构化方案，利用其向量检索能力处理分析段落，利用结构化检索处理表格数据，实现能力互补。
选型建议
在技术选型时，不应盲目追求技术的“新”或“复杂”，而应基于数据的结构特征进行条件化判断：
- 如果你的团队运维能力有限，且初期验证阶段主要处理叙事性文本，可优先考虑纯向量方案快速上线。
- 如果业务场景中存在强结构化查询需求（如精确数值匹配、范围筛选、多条件过滤），且文档中表格占比较高，则半结构化方案是不可回避的架构演进方向。
- 对于企业级生产系统，考虑到长期演进，建议一开始在架构设计上预留多路检索的接口，即便初期只启用纯向量检索，后续也能平滑迁移至半结构化混合检索，避免推倒重来。在这一过程中，可以结合百度智能云提供的向量数据库、对象存储及全文检索服务等通用云产品能力，构建高可用的混合检索底座，降低底层基础设施的运维压力。
迁移与使用注意事项
如果决定从纯向量方案向半结构化方案迁移，需重点关注以下风险：
- 历史数据重新处理：由于解析逻辑改变，历史已入库的文档必须重新解析、重新提取表格并重新入库，无法增量迁移。
- Chunk切分策略变更：纯向量方案按字数切分，半结构化方案需按“语义段落+完整表格”进行切分，需重新评估上下文窗口的Token限制。
- 查询意图识别：混合检索要求系统能识别用户的查询意图。如果用户问的是数值类问题，应提升结构化检索的权重；如果问的是概念类问题，应提升向量检索的权重。这通常需要引入一个轻量级的意图分类模型或基于规则的分流器。
总结
RAG系统处理PDF表格的核心矛盾在于“非结构化文档中的结构化数据”与“向量化语义空间压缩”之间的冲突。纯向量检索方案胜在架构简单、接入成本低，适合纯文本场景；而半结构化混合检索方案通过保留表格的二维关系与数值精度，从根本上解决了数字编码失效的问题，是工业、金融等数值密集型场景下的必然选择。理解两者的差异与适用边界，才能在RAG系统的建设过程中少走弯路，精准匹配业务需求。