摘要

本文从大模型和RAG系统的视角，系统梳理文档的多维分类体系，分析不同文档类型对模型能力的挑战，结合半导体显示领域的典型场景（论文、技术白皮书、企业内PPT/Word/Excel等）探讨文档解析工具选型和结构化抽取的工程实践，并对VLM（视觉语言模型）端到端文档理解范式的可行性与陷阱进行深入分析。

1. 引言

多模态大模型（GPT-4o、Qwen3-VL、Gemini等）的视觉能力已达到实用水平，多模态RAG系统也逐步成为企业知识库、技术情报系统的标准架构。但在实际工程落地中，一个普遍被忽视的基础性问题是：文档本身的异质性（Heterogeneity）对系统整体性能的影响远大于模型选择。

半导体显示行业（包括LCD、OLED、Mini/Micro LED等技术路线）的知识资产具有典型的多模态特征：SID/IDW学术论文包含大量公式、图表和器件结构示意图；企业内部的技术白皮书、工艺规范书（SOP）以图文混排为主；良率报表、工艺参数表高度依赖Excel中的结构化数据；产品技术路线图、客户规格书评审材料则以PPTX为载体，信息呈现高度视觉化。这些文档对模型的感知、理解、推理能力提出了截然不同的要求。

本文的核心观点是：构建高效多模态RAG系统的前提，是对文档建立多维度的分类认知，并据此设计差异化的处理管线，而非期望单一模型或单一工具"通吃"所有文档类型。

2. 文档的多维分类体系

仅按文件后缀（.pdf/.pptx/.docx/.xlsx）对文档分类是远远不够的。本节从四个核心维度对文档进行系统分类，并结合半导体显示场景给出具体示例。

2.1 维度一：内容元素类型

这是决定模型理解难度的最核心维度，也是RAG系统分块（Chunking）策略设计的首要依据。

• 特征：连续的文字流，不含表格、图片、公式等非文本元素
• 行业示例：专利交底书的背景技术部分、工艺规范书中的操作步骤描述、技术白皮书的行业概述章节
• 模型能力：★★★★★ — LLM的原生能力域，现有文本分块+Embedding+检索的技术栈已非常成熟
• RAG处理建议：采用语义分块（Semantic Chunking），块大小512~1024 tokens，中文场景推荐BGE-large-zh-v1.5或GTE-Qwen2作为Embedding模型

表格是文档理解中最具挑战性的元素之一。在半导体显示领域，表格承载了大量核心技术数据：Array段各站点（CVD、Sputter、Photo、Etch）的工艺参数对照表、OLED器件寿命测试数据（LT95/LT90在不同温度/电流密度下的数值）、发光材料特性对比表（CIE坐标、EQE、寿命T95）、BOM成本拆解表等。

表格需进一步细分为：

RAG处理的关键原则：表格不应被简单线性化为文本流。应保留为结构化格式（HTML Table或Markdown Table），并将表头、表标题、脚注作为元数据（Metadata）与表格内容绑定存储。对于数据密集型表格，建议同时存储一份面向检索的文本摘要（如"表3展示了A、B、C三种绿色磷光材料在1000nit下的LT95寿命分别为18000h、23000h、21000h"），以提升检索召回率。

半导体显示技术文献中的图表类型非常丰富：

• IVL曲线（电流密度-电压-亮度关系）：折线图，多曲线对比不同器件结构
• EQE曲线（外量子效率-亮度关系）：折线图，关注效率滚降（Efficiency Roll-off）
• TFT转移特性曲线：Id-Vg曲线，对数坐标，提取阈值电压Vth和迁移率μ
• 良率趋势图：按周/月的Paret图或折线图，标注Top defect类型
• 色域对比图：CIE 1931色度图上的三角形覆盖区域对比
• 工艺窗口图（Process Window）：散点图或等高线图，展示参数可行域

模型对图表的理解呈现明显的"描述强、量化弱"特征：能识别图表类型和大致趋势，但在精确数值读取、多曲线交叉点识别、对数坐标刻度判读等方面准确率显著下降。复合图表（如一个Figure中包含a/b/c/d四个子图分别展示IVL、EQE、寿命、光谱）的跨图关联分析几乎是当前模型的能力盲区。

RAG处理建议：图表应作为多模态Chunk处理，保留原始图片，同时用VLM生成结构化的Caption（图表类型、坐标轴含义、关键数据点、核心结论）。对于关键数值（如峰值EQE、Vth数值），应显式抽取为结构化字段，避免完全依赖模型对图片的"目测"。

半导体显示论文中的公式密度较高：

• 载流子迁移率公式（Mott-Gurney定律、Poole-Frenkel效应）
• OLED发光效率计算公式（EQE = η_out × η_e/h × η_pl × γ）
• 寿命衰减模型（拉伸指数分布、Weibull分布）
• 色彩学计算公式（RGB到CIEXYZ的转换矩阵、JND计算）

主流多模态模型对常见简单公式的识别和LaTeX还原可达实用水平，但对复杂嵌套公式（多层积分、矩阵运算、上下标密集的器件物理公式）的准确率显著下降。

RAG处理建议：公式必须转换为LaTeX代码存储，绝不能以图片形式直接入库。对于公式中的物理量符号（如μ_FE、Vth、LT95），应建立术语映射表，统一Embedding前的表述，避免因符号写法差异导致检索遗漏。

这是半导体显示文档中极具领域特色的一类内容元素：

• 器件结构示意图：OLED堆叠层结构（HIL/HTL/EML/ETL/EIL）的截面示意图，标注每层材料和厚度
• 工艺流程图：Array→CF→Cell→Module四阶段的全流程图，标注关键站点
• 电路原理图：像素驱动电路（2T1C、7T1C等）、GOA电路原理图
• 截面TEM/SEM图：膜层结构的电镜照片，标注各层厚度和界面
• 面板设计图：Pixel排列图（RGB Delta、Pentile、WRGB等）

这类图的理解高度依赖领域知识：一个通用VLM能识别"这是一个多层堆叠结构"，但无法准确指出"这层是CGL（电荷生成层）用于串联OLED结构"。

RAG处理建议：技术示意图必须保留原图，Caption生成需要领域知识注入（可通过Fine-tuning或在Prompt中提供领域术语表实现）。关键标注信息（如材料名称、厚度数值）应显式抽取为结构化文本存入Metadata。

这是技术文档最常见的形态，按复杂度递增：

• 图-文并列：图片旁边有对应的描述段落（如论文中Figure X旁边的结果分析）
• 交叉引用：正文中出现"如图3所示"、"见表5"等跨元素引用
• 多栏混排：学术论文标准的双栏排版，图文在两栏间分布

半导体显示领域的SID论文采用典型的双栏排版，图文混排密度高，且图注、表注中包含大量关键信息。

2.2 维度二：文件格式与解析管线

不同文件格式决定了文档解析的入口和预处理管线。

对RAG架构的直接启示：

• PPTX不应作为整文件处理，应拆解为逐页视觉单元，页面是最小的处理粒度
• XLSX不应走OCR路线，应直接通过pandas/openpyxl读取结构化数据，保留行列语义
• PDF需要根据其生成来源（LaTeX论文 vs Word导出 vs PPT导出）选择不同的解析参数
• 不应仅按文件后缀路由处理逻辑，解析后应按内容元素类型重新归类

2.3 维度三：视觉布局复杂度与"视觉文档"概念

文档AI领域将文档分为文本主导型（Text-dominant）和视觉富文档（Visually-rich Document, VrD，简称"视觉文档"）两类。其核心区分标准是：视觉布局本身是否承载语义信息——如果去掉排版只保留文字，信息是否大量丢失。

视觉文档的复杂度光谱：

单栏纯文本 → 单栏+少量图 → 双栏论文 → 多栏+跨栏 → PPT页面 → 信息图/海报(SOP正文)    (白皮书)      (SID论文)  (技术期刊)  (路线图)   (产品宣传)

2.4 维度四：知识类型与信息密度特征

3. 多模态模型的文档理解能力边界

3.1 三层认知模型

我们用三层模型来刻画多模态大模型对文档的理解过程，每一层对应不同的能力成熟度：

第一层：感知提取层（Perception）

• 能力内涵：OCR文字识别、元素区域检测（哪里有文字、表格、图片）、区域定位
• 当前成熟度：★★★★☆
• 现状：主流VLM和专用OCR工具（PaddleOCR等）在清晰数字文档上的表现已达到实用水平，手写体和艺术字体仍有挑战，但在企业内部文档场景中问题不大

第二层：结构理解层（Structural Understanding）

• 能力内涵：元素类型识别（这是表格还是流程图）、布局结构理解（阅读顺序、层级关系）、跨元素关联建立（"如图3所示"中3指的是哪张图）
• 当前成熟度：★★★☆☆
• 现状：LayoutLM系列等专用Document AI模型在标准文档类型上表现良好，但在PPT自由排版、复杂SmartArt等场景仍有较多错误；通用VLM的版面理解能力正在快速追赶

第三层：语义推理层（Semantic Reasoning）

• 能力内涵：跨元素信息整合、数值计算与比较、逻辑推理、领域知识调用
• 当前成熟度：★★☆☆☆（最大瓶颈）
• 现状举例：
• "从表2的三个材料数据中，找出1000nit下LT95寿命最长的材料，并计算其比第二名长百分之多少"——这类跨表格数值比较+计算仍不可靠
• "结合IVL曲线图中器件A的驱动电压和表3中的EQE数据，计算器件A的功率效率"——跨元素多步推理失败率高
• "根据这份工艺参数表，判断该站点的工艺窗口是否覆盖当前量产条件"——领域规则+数值推理，通用模型基本无法完成

3.2 对RAG系统设计的指导意义

清醒认识这三层能力边界有直接的工程意义：

1. 不要把推理工作完全交给生成阶段的LLM：在索引阶段（Indexing）就应尽可能完成结构化抽取和关键信息显式化，减少生成阶段的推理负担
2. 跨元素关联应在预处理阶段建立："如图3所示"这类引用关系，应在文档解析阶段就解析为结构化的引用链接，而非留给LLM在生成时"猜"
3. 数值计算应外移到代码执行：表格中的数值汇总、对比、计算，应在检索后通过代码（Python/SQL）执行，而非期望LLM心算

4. 文档解析工具选型与工程实践

4.1 主流工具对比

2025-2026年，文档解析领域的工具链已相对成熟：

4.2 面向半导体显示场景的选型建议

基于前述文档类型分析，针对半导体显示企业的典型文档栈，推荐分层选型策略：

5. 结构化抽取：从解析内容到可检索数据

文档解析的输出（Markdown/JSON/图片）只是原料，RAG系统真正需要的是按业务Schema结构化的数据。本节讨论如何将解析后的文档内容，通过LLM/VLM抽取为结构化字段，支撑精确检索和混合查询。

5.1 为什么需要结构化抽取

直接将解析后的原文Chunk入库，有三个本质缺陷：

1. 只能语义相似度检索：无法支持"查找2024年Q3所有应用于OLED蓝色磷光主体材料、且EQE大于20%的测试数据"这类精确条件查询
2. 关键字段遗漏：LLM生成答案时容易忽略散落在上下文中的关键字段值
3. 无法聚合分析：无法支持"过去一年HTL材料的迁移率变化趋势如何"这类聚合类问题

5.2 分阶段结构化抽取架构

结构化抽取应按文档层级分阶段执行：

Level 1：文档级抽取（Document-level）

• 抽取目标：文档标题、作者/发布部门、文档日期、文档类型（论文/SOP/报告/PPT）、产品/技术领域（OLED HTL材料/Array Photo工艺/Module组装等）
• 执行时机：文档解析完成后立即执行一次
• Schema示例：

{  ”doc_id”: ”DOC-2024-001”,  ”title”: ”新型绿色磷光主体材料G-X1性能评估报告”,  ”doc_type”: ”技术报告”,  ”department”: ”材料研发部”,  ”date”: ”2024-03-15”,  ”tech_domain”: [”OLED”, ”磷光材料”, ”主体材料”],  ”product_line”: ”AMOLED手机面板”}

Level 2：页面/章节级抽取（Page/Section-level）

• 抽取目标：章节标题、页码、核心结论、本页涉及的关键实体（材料名、设备名、站点名、参数名）
• 执行时机：按页或按章节分批执行
• 对于PPTX，页面是天然的处理边界；对于Word/PDF，按章节划分

Level 3：元素级抽取（Element-level）

• 抽取目标：表格中的字段和数值、图表中的关键数据点、公式中的物理量和结论
• 执行时机：对检测到的每个结构化元素单独执行
• 示例（IVL曲线图表）：

{  ”element_type”: ”chart”,  ”chart_type”: ”line”,  ”title”: ”器件A/B/C的亮度-电压特性曲线”,  ”x_axis”: {”label”: ”Voltage (V)”, ”range”: [0, 10]},  ”y_axis”: {”label”: ”Luminance (cd/m²)”, ”scale”: ”log”},  ”key_data_points”: [    {”device”: ”A”, ”von”: 2.8, ”luminance_at_5v”: 3500},    {”device”: ”B”, ”von”: 3.2, ”luminance_at_5v”: 4200}  ],  ”conclusion”: ”器件B的驱动电压略高但5V下亮度更高”}

5.3 Prompt设计的工程要点

结构化抽取的Prompt设计直接决定输出质量：

1. 提供明确的JSON Schema：每个字段给出类型、含义、取值范围约束，字段命名与业务术语一致（如用"LT95"而非"寿命数值"）
2. 给出Few-shot示例：针对本领域的典型文档（如一张OLED寿命表、一张IVL曲线图）提供1-2个输入输出示例，可使格式稳定性和字段准确率提升20%以上
3. 严格约束输出边界：明确告知模型"仅基于提供的内容抽取，未提及的字段填null，禁止推测和编造"——这在技术数据场景中至关重要
4. 利用VLM的视觉能力：对于PPT页面和图表，在Prompt中明确要求"利用视觉空间感知能力，识别流程图箭头方向、层级关系、图表坐标轴刻度"
5. 输出校验与自动重试：使用Pydantic定义Schema模型，LLM输出后立即做校验，不合格的（类型错误、字段缺失、JSON格式错误）自动重试，最多重试3次

5.4 VLM端到端抽取的可行性与陷阱

Qwen3-VL-72B、GPT-4o等新一代VLM支持超长上下文（Qwen3-VL原生256K，可扩展至1M），一个自然的技术选择是：跳过传统解析工具，直接将文档逐页转图片后送入VLM，端到端完成结构化抽取。

这种范式相比"解析工具+纯文本LLM"的两阶段架构，在以下场景具有明确优势：

• PPTX中的SmartArt、流程图、逻辑架构图：传统解析工具只能提取零散文本框，逻辑关系完全丢失；VLM能直接看懂箭头指向和层级结构
• 图文强耦合的技术示意图（如OLED器件结构+材料标注）：传统方案图文分离后丢失了空间关联；VLM能精准定位"某个标注箭头指向哪一层"
• 复杂表格（带合并单元格、颜色编码语义如红色=超规、绿色=合格）：VLM能理解颜色、边框粗细等视觉语义

但是，"将整份50页PPT直接一次性喂给VLM"的做法在工程上有四个致命陷阱：

陷阱1：视觉分辨率衰减与Token爆炸VLM将图片切分为Patch（典型28×28像素），一张1920×1080的PPT页面约消耗1200个视觉Token。50页PPT仅图片就消耗约60000 Token。为了塞进上下文窗口，API服务端会自动压缩图片分辨率，导致小字号文本（如PPT中密密麻麻的参数脚注）模糊，引发幻觉和漏读。工程经验上，单张图片的视觉Token消耗控制在1500以内才能保证小字识别准确率。

陷阱2：长上下文的"Lost in the Middle"效应无论LLM还是VLM，在超长上下文下对中间部分内容的注意力显著下降。实测表明，一次性喂入30页以上PPT时，第10-20页的字段抽取准确率会从90%以上跌至50-60%。

陷阱3：超大JSON输出的格式不稳定让模型一次性输出包含50个页面、每页10个字段的大JSON（可能数万Token），括号不匹配、Key丢失、字段截断等格式错误率急剧上升，重试成本极高。

陷阱4：延迟与成本不可控VLM处理图片的首Token延迟（TTFT）显著高于纯文本。一次性处理50页PPT，TTFT可能达20-40秒，API成本约为纯文本的8-15倍。

正确的工程做法：分而治之的并发管线

原始文档（如50页PPTX）    │    ├─[1] 物理拆分为逐页高清图片（python-pptx + pdf2image/ LibreOffice）    │     同时提取每页的原生文本作为辅助输入    │    ├─[2] 批量并发调用VLM（建议每批1-3页）    │     每批独立提取当前页的结构化字段，输出小JSON    │     并发度根据API限流设置（通常5-10并发）    │    ├─[3] 逐批Pydantic校验，不合格自动重试    │    ├─[4] 代码层合并为完整的文档级JSON    │     （跨页关联在此处通过代码逻辑处理，不依赖模型记忆）    │    └─[5] 文本化与Embedding后存入向量库          同时保留原图URL/路径作为多模态检索的原始素材

5.5 混合架构：文档类型感知的路由策略

最成熟的工程实践不是"二选一"，而是根据页面特征动态路由处理管线：

def route_page_processing(page):    ”””根据页面视觉复杂度选择处理管线”””# 快速规则预判（轻量级）    text_ratio = calculate_text_area_ratio(page)    has_complex_visuals = detect_smartart_or_charts(page)    has_dense_table = detect_dense_table(page)    if text_ratio > 0.85 and not has_complex_visuals:# 纯文本页（如SOP正文段落）# 走：传统文本提取 + 纯文本LLM抽取# 优点：速度快、成本低、长文本处理稳定        return TextPipeline()    elif has_complex_visuals or text_ratio < 0.3:# 复杂视觉页（流程图、架构图、全图表页）# 走：高清渲染 + VLM视觉抽取# 优点：保留视觉信息，逻辑关系不丢失        return VLMPipeline(vlm_model=”qwen3-vl-72b”, image_dpi=200)    elif has_dense_table:# 数据密集表格页# 走：单独裁剪表格区域 + 高分辨率送入VLM# 避免全页图片中表格分辨率不足        return TableSpecificPipeline()    else:# 一般图文混排页        return MixedPipeline()

对于PPTX这类整体视觉化程度高的文档，可以直接全量走VLM管线（每页单独处理）；对于Word为主的SOP文档，大部分页面走文本管线，少数含图页面路由到VLM。

6. 向量数据库存储与混合检索

结构化抽取后的最终目的是入库检索。本节以Milvus为例讨论面向半导体显示场景的Collection设计。

6.1 Collection Schema设计

from pymilvus import CollectionSchema, FieldSchema, DataTypefields = [# === 主键与向量字段 ===    FieldSchema(name=”chunk_id”, dtype=DataType.VARCHAR, is_primary=True, max_length=64),    FieldSchema(name=”text_embedding”, dtype=DataType.FLOAT_VECTOR, dim=1024),# BGE-large-zh-v1.5: 1024维    FieldSchema(name=”image_embedding”, dtype=DataType.FLOAT_VECTOR, dim=768),# SigLIP/CLIP: 768维# === 文档基础元数据（来自Level 1抽取）===    FieldSchema(name=”doc_id”, dtype=DataType.VARCHAR, max_length=64),    FieldSchema(name=”doc_title”, dtype=DataType.VARCHAR, max_length=512),    FieldSchema(name=”doc_type”, dtype=DataType.VARCHAR, max_length=32),# paper/sop/pptx_report/whitepaper    FieldSchema(name=”tech_domain”, dtype=DataType.ARRAY, element_type=DataType.VARCHAR, max_capacity=20, max_length=64),    FieldSchema(name=”date”, dtype=DataType.VARCHAR, max_length=16),    FieldSchema(name=”department”, dtype=DataType.VARCHAR, max_length=128),# === Chunk定位信息 ===    FieldSchema(name=”page_num”, dtype=DataType.INT64),    FieldSchema(name=”element_type”, dtype=DataType.VARCHAR, max_length=32),# text/table/chart/formula/diagram    FieldSchema(name=”bbox”, dtype=DataType.ARRAY, element_type=DataType.FLOAT, max_capacity=4),# [x1,y1,x2,y2]# === 业务结构化字段（按领域定义）===    FieldSchema(name=”material_name”, dtype=DataType.VARCHAR, max_length=128),# 如 ”G-X1”, ”HTL-A03”    FieldSchema(name=”material_type”, dtype=DataType.VARCHAR, max_length=64),# 如 ”磷光主体”, ”HTL”, ”ETL”    FieldSchema(name=”parameter_name”, dtype=DataType.VARCHAR, max_length=64),# 如 ”EQE”, ”LT95”, ”Vth”, ”μ_FE”    FieldSchema(name=”parameter_value”, dtype=DataType.FLOAT),    FieldSchema(name=”parameter_unit”, dtype=DataType.VARCHAR, max_length=16),# === 原文与图片 ===    FieldSchema(name=”text_content”, dtype=DataType.VARCHAR, max_length=65535),    FieldSchema(name=”structured_json”, dtype=DataType.VARCHAR, max_length=65535),    FieldSchema(name=”image_url”, dtype=DataType.VARCHAR, max_length=512),# 原图OSS/本地路径]schema = CollectionSchema(fields=fields, description=”半导体显示领域多模态RAG知识库”)

6.2 混合检索策略

Milvus支持向量检索与标量过滤的组合查询，这正是结构化抽取价值的集中体现。

典型查询场景："查找所有蓝色磷光掺杂材料在1000nit下的EQE测试数据"

纯向量检索：将Query直接Embedding后做ANN搜索，可能混入其他颜色材料、其他亮度条件、甚至不相关的寿命数据，准确率约60-70%。

标量过滤+向量检索：

results = collection.search(    data=[query_embedding],    anns_field=”text_embedding”,    param={”metric_type”: ”COSINE”, ”params”: {”nprobe”: 10}},    limit=20,# 先用结构化字段精确过滤，再在结果集中做语义检索    expr='material_type == ”磷光掺杂” and parameter_name == ”EQE”',    output_fields=[”text_content”, ”structured_json”, ”material_name”, ”parameter_value”, ”image_url”])

准确率可提升至90%以上。

生产环境推荐三路混合检索：

1. 语义向量检索（dense retrieval）：捕捉语义相似性
2. BM25全文检索（sparse retrieval，Milvus 2.5+原生支持）：保证精确关键词命中（如具体材料代号"G-X1"）
3. 结构化标量过滤：按业务字段精确缩小范围三路结果通过RRF（Reciprocal Rank Fusion）融合排序。

7. 工程落地的建议与常见陷阱

基于在多模态RAG系统建设中的实际经验，给出以下工程建议：

1. 先做文档画像（Document Profiling），再动手写代码

在搭建系统之前，随机抽取50-100份典型文档，人工标注：

• 各文件类型占比（PPTX/DOCX/XLSX/PDF各占多少）
• 内容元素分布（纯文本/表格/图表/公式/示意图的比例）
• 视觉复杂度分布（单栏/双栏/自由排版的比例）
• 主要业务实体类型（材料/工艺站点/设备/产品型号等）

这一步的投入产出比极高，直接决定后续工具选型、Schema设计、Chunk策略的方向。

2. 建立Golden Set评测集

在正式开发前，人工标注10-20份典型文档的期望抽取结果（含文档级、页面级、元素级字段），形成Golden Set。每次Prompt调整、模型更换、工具升级后，用Golden Set跑回归测试，量化准确率变化。这比"凭感觉调参"效率高10倍以上。

3. 不要迷信"大模型一次搞定"

当前VLM能力虽然强大，但工程上仍应坚持"分而治之"：

• 物理拆页，每批1-3页
• 按元素类型差异化处理
• 结构化校验在代码层完成，不依赖模型自检
• 跨页/跨Chunk的关联用代码逻辑拼接，不依赖模型的长上下文记忆

4. Excel文档一定要走原生读取

很多团队为了统一管线，把Excel转成PDF再走文档解析，这是典型的"为架构牺牲性能"。Excel的DataFrame原生包含完整的行列语义、单元格类型、公式关系，pandas直接读取后可生成结构化摘要（如"本表为2024年Q1 HTL材料迁移率测试数据，共测试15个批次，平均迁移率为2.3E-5 cm²/Vs，最高3.1E-5，最低1.8E-5"），再结合字段化抽取入库，效果远好于OCR。

5. 原图永远保留

无论解析工具多么强大，入库时务必保留原始图片路径或URL。当检索命中某个Chunk时，将原图（而非仅文本）送给生成阶段的大模型，作为"视觉证据"。这在回答涉及图表、示意图、复杂表格的问题时，质量差异是质变级别的。

6. 领域术语的Embedding一致性

半导体显示领域有大量专业术语和缩写（如"LTPS"、"Oxide TFT"、"CGL"、"Tandem"、"EQE"、"LT95"、"GOA"）。通用Embedding模型对这些术语的编码可能不一致，建议：

• 维护一份领域术语同义词表（如"T95"="LT95"="寿命95%保持时间"）
• 在Embedding前对Query和文档做术语归一化
• 有条件的话，用领域语料对Embedding模型做Fine-tune或Adapter训练

8. 总结

本文系统阐述了RAG系统中文档理解的关键问题，核心结论如下：

1. 文档是异质的：必须从内容元素、文件格式、视觉布局、知识类型四个维度建立分类认知，不同类型文档需要差异化处理管线
2. 模型能力有边界：感知层已成熟，结构层在进步，推理层仍是瓶颈；在索引阶段完成更多显式结构化，减少生成阶段的推理负担
3. 工具选型要场景化：MinerU、PaddleOCR-VL、VLM各有最佳适用场景，应按文档类型分流而非"一刀切"
4. VLM端到端可行但不可"整份喂"：逐页/分块并发、输出校验、代码合并才是工程正解；"视觉复杂度路由"是兼顾成本和质量的关键
5. 结构化抽取是检索精度的核心驱动力：混合检索（向量+BM25+标量过滤）显著优于纯向量检索
6. 半导体显示场景有鲜明的领域特征：高度视觉化的PPT、密集数值表格、专业图表和公式、领域术语体系，都需要在工程实现中针对性处理

文档理解是多模态RAG系统的"第一公里"。这一步的质量决定了整个系统的上限——垃圾进，垃圾出（Garbage In, Garbage Out）。在模型能力快速迭代的今天，扎实做好文档分类、解析、结构化的基础工作，比盲目追逐最新模型能带来更实在的系统性能提升。