企业官网建设流程全解析

搞个人知识库这几年，我最大的体会是：真正卡住 RAG 项目的往往不是模型选型，也不是向量库调参，而是数据导入这一步。尤其当你的资料库里出现 PDF 和图片的时候，问题一下子变得特别现实——同样是 PDF，有的是出版社直接排版导出的文字版，有的是扫描成图像的影印版，还有的是图文混排的教材和产品手册。这三种情况完全不是同一种解析方案能搞定的。这篇是 RAG 数据导入系列的第二章，我专门把图文与 PDF 解析这件事掰开揉碎讲清楚，围绕 OCR、多模态大模型，以及九种主流 PDF 处理工具逐一过一遍，把边界条件、选型逻辑和实际踩坑点都说透。

PDF 这个东西最大的迷惑性在于：它看起来是一种格式，实际上是一篮子格式的统称。同样是 .pdf 后缀，文件内部可能是一个带文字层的文档流，可能是一堆 JPEG 图像的打包容器，也可能是文字层破损、只有残存乱码的半扫描件。如果你把解析结果直接丢给 RAG，后面检索效果差，十有八九问题出在这一步。本文不会只罗列工具，我会把“什么时候必须上 OCR、什么时候上多模态模型、什么时候普通文本提取就够了”的判断逻辑讲清楚，再给出一个可以直接照抄的混合解析管道。无论你用的是 LangChain 系框架，还是自己手写的简单 RAG，这套思路都能落地。

1. 图文与 PDF 为什么是 RAG 数据导入中最难啃的骨头

1.1 PDF 不是一种格式，而是一篮子格式的统称

很多人第一次做 RAG 数据导入时，默认把“解析 PDF”当作一件简单的事，无非就是调个库把文本抽出来。但实际操作几次就会明白，PDF 内部结构差异极大，不同来源的 PDF 在解析难度上是天壤之别。

• 文字版 PDF：由 Word、LaTeX、排版软件直接导出，内部包含字体信息和文本流，可以用文本提取工具直接读出完整内容。这类 PDF 最好处理，但问题往往出在阅读顺序和版面复杂结构上。
• 扫描版 PDF：本质是若干张图片合订成的容器，每一页就是一张大图，内部压根没有文字层。用普通文本提取工具读出来只会得到空字符串。这种文件必须走 OCR。
• 混合版 PDF：部分页面有文字层，部分页面是图片；或者文字层存在但字体映射损坏，提取出来的全是乱码和空格。这类情况最坑，因为你无法简单地“有文字层就提、没文字层就 OCR”。
• 图文混排型 PDF：常见于教材、技术手册，文字、表格、公式、流程图混排。解析出的文本虽然在，但图表信息全部丢失。

还有一个非常实际的问题：大量民间流通的 PDF 其实是劣质扫描件的二次压缩产物，页面上还有水印、书脊阴影、手指遮挡，OCR 识别准确率会大幅下降。这类数据如果不做预处理，后面无论用什么模型，召回质量都会受影响。

1.2 一个反直觉的认知盲区：嵌入图片中的表格和信息

说到图片型内容，很多人第一反应是“图片里的文字用 OCR 提出来不就行了”，但这里有个认知盲区。图片里不仅有文字，还有表格关系、层级结构、流程图逻辑。比如一张设备拓扑图，文字节点之间的关系靠连线表达；一张柱状对比图，数值的高低关系靠图形表达。这些关系信息，传统 OCR 完全无能为力。

这也是为什么我在标题里把“图文与 PDF 解析”放在一起：图像型信息的入库问题，本质上不是一个“识别文字”的问题，而是一个“结构还原”的问题。你需要的不是把图片翻成文字，而是让后续的检索单元能理解这段内容表达的是什么关系。这里就牵扯到多模态模型介入的必要性，后文会展开讲。

1.3 本篇文章要解决的三个问题边界

为了避免文章变成无意义的工具罗列，我先明确这一篇要围绕哪几个核心问题展开：

1. 什么时候必须上 OCR，什么时候普通文本提取就够了。判断标准是什么，不依赖人工逐个翻页的办法有没有。
2. 传统 OCR 和“多模态大模型读图”各自擅长什么、不擅长什么。两者的成本、速度、准确率差距到底有多大。
3. 面对多种类型的 PDF 和图片，一个工程上可落地的混合管道怎么搭。工具选型怎么定，预处理怎么设计，切块怎么规避乱序。

搞清楚这三个问题，你自己的知识库数据导入就不再是个玄学问题，而是变成一条条可以测试、可以量化的工程流程。

2. OCR 路线：从 Tesseract 到 PaddleOCR 的边界判断与落地细节

2.1 先判断要不要 OCR：文字层检测的简单方法

很多教程一上来就推荐 OCR，实际上是不负责任的。文字版 PDF 去跑 OCR，不仅耗时翻倍，还可能因为识别误差引入原本不存在的错字。正确做法是先判断目标 PDF 有没有可用的文字层。

我常用 PyMuPDF 做快速检测，逻辑很简单：

import fitz # PyMuPDF def check_text_layer(path, sample_pages=10): doc = fitz.open(path) total_chars = 0 total_pages = min(len(doc), sample_pages) for page_num in range(total_pages): page = doc[page_num] text = page.get_text("text") total_chars += len(text.strip()) doc.close() return total_chars, total_chars / total_pages if total_pages else 0

如果平均每页提取字符数极低（比如低于 50），基本可以断定这个 PDF 没有有效文字层，直接进入静默降级，把该文件标记为“需要 OCR / 渲染成图后多模态识别”。如果字符数正常，但肉眼抽检发现乱码、断字严重，则说明字体映射损坏，也需要先做修复，或者干脆当扫描件处理。

注意这里有个容易犯的错：文件有文字层不代表文字层可靠。有些 PDF 的“文字层”是 OCR 软件自动生成的，文本本身错漏百出，直接当正常文本提取入库，等于把错误知识喂给模型。我的习惯是抽几页渲染成图片，肉眼对比提取文本和原页面的差异，再决定走哪条路。别嫌麻烦，这一步省下的是后面一排排的脏数据。

2.2 Tesseract、PaddleOCR 与腾讯开源 OCR 的横向取舍

一旦确定走 OCR，接下来就是选引擎。这几年的开源 OCR 生态已经很成熟，主要选手有这几个：

我自己在中文知识库场景下，长期主力是 PaddleOCR 这一挂。原因是它的 PP-StructureV2 不只是 OCR，还能做版面分析、表格还原和阅读顺序恢复。单纯把字识别出来，和把一页的语义结构还原出来，是两码事。后面工具选型章节我会专门讲它。

如果在低配机器上部署，或者只是给一个轻量工具脚本用，RapidOCR 会更舒服，因为它是 ONNX 模型，不需要装 Paddle 全家桶。如果你处理的是韩文、日文等多语种材料，腾讯那套针对语种优化的模型值得一试。我也遇到过 PaddleOCR 默认模型识别韩文失败的情况，后来查了才知道是语言模型没指定，对应语种包要额外下载，并不是引擎不行。

2.3 OCR 之后真正的坑：版面恢复与阅读顺序

很多人以为 OCR 识别完文字就完事了，实际上这只是开始。OCR 引擎输出的通常是一堆带坐标的文本块，如果不做版面恢复，后面的切块会出大问题。

举个真实的例子：一页 PDF 有三栏排版，OCR 直接按坐标输出的话，顺序可能是“左边栏第一行”“中间栏第一行”“右边栏第一行”……割裂了段落语义。传统 RAG 对 chunk 的切分基于文本流，顺序错乱直接导致语义错位。就算检索到了相关内容，完整段落也是碎的。

解决办法有两个层级：

• 如果你用的工具自带版面分析（如 PaddleOCR 的 PP-Structure），把“版面分析 + 阅读顺序”选项打开，它会根据标题、段落、表格、图片区域重新组织文本流。这是首选方案。
• 如果没有版面分析能力，退而求其次：把 OCR 输出保存为带坐标的 JSON 或 DataFrame，按“自上而下、自左而右”的阅读规则自行排序。多栏页面尤其要用 y 坐标先分栏，再按 x 坐标排序，而不是直接按 y 坐标线性排。

还要提一个细节：页眉页脚和页码必须在 OCR 后的清洗阶段删掉，否则每次切块都会带进大量噪声。账单、教材这类文档，页眉页脚的重复信息会显著污染向量检索的相似度计算。我的做法是：在文本流中识别连续出现超过三页且高度相似的短行，直接丢进黑名单过滤掉。

3. 多模态大模型解析 PDF：从“看图识字”到理解图表关系的升级

3.1 为什么纯 OCR 解决不了信息损耗问题

如果你只是想提取大段文字的扫描件，OCR 是够用的。但 RAG 知识库里常见的资料，往往夹杂着大量图表。图的语义不是文字能闭环的：对比柱状图、环形占比、拓扑线、泳道图、时序图，它们的信息主体是空间关系和数值映射。

一个很实际的例子：产品规格书里的参数对比表，用 OCR 提出来虽然能保留文字内容，但表头结构、单元格归属一旦丢失，后续检索“支持 Wi-Fi 6 的型号有哪些”这类问题时，模型从散落文本里找不到明确的对应关系。这时候，多模态大模型的价值就体现出来了——它能把一整张图或一整页版面作为输入，观察空间布局，直接输出结构化的描述。

3.2 把 PDF 页面渲染成图，交给多模态模型

主流的做法并不复杂：用 PyMuPDF 将 PDF 页面渲染成 PNG，然后送给支持视觉输入的多模态大模型，让它生成结构化的输出。整体链路是：

1. 用 PyMuPDF 以较高分辨率（建议 150-200 DPI）渲染页面；
2. 将渲染后的图片交给多模态模型，提示词中要求“完整还原页面信息，输出结构化 Markdown，表格用表格语法，公式用 LaTeX，不要遗漏页面中任何文字”；
3. 设定 temperature=0，避免模型自由发挥；
4. 对输出做文本清洗和校验，再进入切块阶段。

本地方案我实测过，用 Ollama 加载 MiniCPM-V 或 Qwen2-VL 系列模型，一台普通 8GB 显存的显卡就能对中文扫描件跑出可用的结果。速度上每页大概 2 到 5 秒，跟 PaddleOCR 差不多，但输出结构要好得多。如果你是零基础搭建本地知识库，参照“ollama + 简易本地 RAG 知识库”那类流程就能跑通，只是要把输入端换成我刚才说的渲染步骤。

3.3 多模态模型也有明显短板：大表格、复杂公式、密集版式

多模态模型并非万能，我用下来有三类情况必须人工介入或退回传统 OCR：

• 超大表格：几十列、上百行的密集表格，直接给模型读图很容易出现列错位、数值张冠李戴。这时候反而建议用 PP-Structure 的表格识别模块单独处理，再回填上下文。
• 复杂数学公式：模型对稀疏公式的识别不错，但遇到多行推导、复杂符号堆叠时，经常给出结构正确但系数错误的 LaTeX。涉及公式类资料，最好人工抽检，OCR 加后规则校验也是办法。
• 页面内多个独立语义块：比如报纸式排版，一页包含七八个互不相关的新闻条目，多模态模型容易只输出视觉上占据主要篇幅的内容，边角料被漏掉。应对策略是先把页面按区域切图，再分块送入模型。

为了减少漏项，我习惯在提示词里强制要求它“逐区域扫描”，并且在解析后用一个简单的字符数校验：拿渲染图的提取文本字符数与多模态输出的字符数对比，如果后者明显偏少，就标记为疑似漏页，进入人工抽检队列。这个自动化校验非常管用。

3.4 OCR 和多模态大模型的组合策略

实际项目里，OCR 与多模态模型不是二选一，而是各用所长：

• 纯文字扫描件：PaddleOCR/PP-Structure 够了，速度快、成本低。
• 图文混排、PPT 截图、产品手册：多模态模型直接读整页，还原关系结构。
• 包含复杂表格的财务或合同材料：先 PP-Structure 表格识别，再用多模态模型补足版面上下文。
• 需要字段抽取的场景：比如合同里抽收入、单位、时间等关键字段，多模态模型配合结构化输出比 OCR 加正则稳定很多。这也是很多用百度 OCR 做合同识别的人最终转向大模型的原因——字段级的正则规则属实维护不动。

这种组合策略也决定了后面管道设计：文件先分流，再按类型走不同处理路径，而不是一个工具打天下。

4. 九种 PDF 解析工具选型对照表与实测体会

4.1 快速选型对照表

这一节直接上核心对比。九种工具，我按实际用途、适合场景、限制条件列了一张表。每个我都实际跑过，不是只看过文档。

4.2 不同应用场景下的选型原则

场景一：文字版 PDF 转文本入库

首选 pdfplumber 或 PyMuPDF。pdfplumber 的优势是能拿到字符的精确坐标，方便做阅读顺序的二次处理。PyMuPDF 优势是速度快，整本 500 页的书几秒钟就能抽完文本。我通常的组合是：用 PyMuPDF 快速抽取 + pdfplumber 对可疑页面做细查。

场景二：扫描版中文 PDF 完整入库

直接上 PP-StructureV2，这是目前中文环境下我的首选。它内部整合了版面分析、文本检测、文本识别、表格识别四个模块，输出是结构化 JSON。你要做的只是把 JSON 按阅读顺序组装成 Markdown 或纯文本。唯一要花点心思的是环境部署——Paddle 全家桶装起来比较占空间，但收益是值得的。如果你的环境装不了 Paddle，那就用 RapidOCR 加自写的版面排序逻辑，也能达到八成效果。

场景三：需要 Markdown 格式直接喂给 LLM / RAG

用 markitdown 或者 unstructured。markitdown 的开箱体验更好，直接把 PDF 转成干净的 Markdown，特别适合“PDF 转文档语料”的场景。unstructured 的好处是可以按元素类型（Title、NarrativeText、Table、Image）分区输出，这对 RAG 切块非常友好——你可以把表格和正文分开处理，再决定是否合并。但它的中文版面分析质量不如 PP-Structure，而且依赖树比较深，换一台机器环境就崩的情况我遇到过好几次。

场景四：只抽表格

Camelot 和 tabula-py 是专门干这个的。tabula-py 接入简单，但表格结构复杂时识别不准。Camelot 的 Lattice 模式对有线表格还原度很高。需要注意：这两个工具都只处理文字版 PDF，如果 PDF 是扫描件，必须先走 OCR 生成文字层或直接改走 PP-Structure 的表格识别模块。

4.3 一个容易忽略的决策逻辑：先从 PDF 类型判断工具，而不是先选工具

很多初学者容易犯一个错误：先选一个喜欢的库，然后所有 PDF 都往里面丢，解析失败就换下一个库。正确的决策顺序应该是：

1. 先判类型：文字版 / 扫描版 / 混合版。
2. 再判目标：只要正文文本，还是要表格结构，还是要版面关系。
3. 最后选工具：按上述场景匹配表格里的工具体系。

这个判断顺序能帮你省下大量无效尝试的时间。我自己最初踩过的坑就是迷信 “unstructured 能搞定一切”，结果在扫描版教材上浪费时间，最后才发现该上 OCR 的时候不要绕路。

5. 一套混合解析管道的落地配置：检测、分流、排序、切块

5.1 管道整体设计

前面几章讲的都是工具和思路，这一章给可以照着抄的管道设计。整体流程分四段：

1. 输入检测段：抽取 PDF 元数据、页面数、文字层有效字符数，判定文件类型。
2. 分流段：按类型把文件分派给不同的解析器。
3. 结构化段：把解析结果统一转成 Markdown 或带元数据的文本块。
4. 清洗与切块段：过滤页眉页脚、合并段落、控制切块尺寸，再进入 embedding。

5.2 用 Python 快速实现一个分流器

下面这个代码是我实际在用的精简版，包含文件类型自动判断和解析器分派逻辑：

import fitz import pdfplumber from pathlib import Path import json def detect_pdf_type(pdf_path: str, char_threshold: int = 50) -> dict: """判断 PDF 是否有可用文字层""" doc = fitz.open(pdf_path) result = { "path": pdf_path, "pages": len(doc), "text_chars": 0, "type": "unknown", } sample_pages = min(len(doc), 10) total_chars = 0 for i in range(sample_pages): text = doc[i].get_text("text").strip() total_chars += len(text) result["text_chars"] = total_chars result["avg_chars_per_page"] = round(total_chars / sample_pages, 2) doc.close() if result["avg_chars_per_page"] < char_threshold: result["type"] = "scanned" # 扫描版，走 OCR / 多模态 else: result["type"] = "text" # 文字版，走文本提取 return result def parse_pdf(pdf_path: str): info = detect_pdf_type(pdf_path) if info["type"] == "scanned": return parse_scanned_pdf(pdf_path) # 走 PP-Structure 或多模态 else: return parse_text_pdf(pdf_path) # 走 pdfplumber / PyMuPDF def parse_text_pdf(pdf_path: str) -> str: # 优先用 pdfplumber 提取文本，保留坐标信息供后续排序 full_text = [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: text = page.extract_text(x_tolerance=2, y_tolerance=2) if text and text.strip(): full_text.append(text) return "\n\n".join(full_text)

这里有个细节我特别提醒：pdfplumber 的extract_text有两个宽容度参数x_tolerance和y_tolerance。默认值在遇到多栏文本时经常把同一栏的文字拆散，或者把两栏内容交叉混排。我实测下来，x_tolerance=2能有效缓解文字忽左忽右导致的断行问题。如果你解析的 PDF 是专业排版、字符间距特别大，还需要调大这个值。直接使用默认参数处理复杂版面，效果很难看。

5.3 扫描版 PDF 解析：OCR 与多模态模型的接口封装

扫描版方面，我封装过两条路径，按机器配置切换：

• 轻量路径：RapidOCR 提取文本，返回带坐标的块列表，再按阅读顺序组装。
• 完整路径：PP-StructureV2 做版面分析，直接输出带结构标签的 JSON。
• 多模态路径：PyMuPDF 渲染页面为 PNG，提交本地 Qwen2-VL，输出 Markdown。

实际生产环境你是想全部用“完整路径 + 多模态抽检”的组合。PP-StructureV2 负责批量处理，速度相对可控；多模态模型只对 PP-Structure 输出可疑、文本量偏低、或版面特别复杂的页面出手。这个组合既保证质量又控制成本，不会让 GPU 打满却没产出。

5.4 清洗与切块的三个关键控制点

解析出文本之后还有三道工序，我分别踩过不同程度的坑，写在这里当备忘：

第一，页眉页脚过滤。规则可以是“跨页重复出现且字符长度小于 30 的行，直接剔除”。但要注意别误伤正常的短标题。我的过滤器会结合页面位置判断：出现在页面顶部 10% 区域或底部 10% 区域的行才进入候选黑名单。

第二，段落合并。OCR 输出常常把同一段落切成多行，如果直接按行切块，向量化噪音很大。简单有效的方法是：以空行作为段落分隔符，如果两行之间只有一个换行没有空行，就合并成同一段落。这一步做完，chunk 的质量会有肉眼可见的提升。

第三，切块边界的避免。RAG 切块时如果只按固定字符数硬切，很可能把表格的一行、段落的一半从中断开。我固定在切块前对 Markdown 输出做格式感知：优先在标题、空行、列表项边界处切；表格单独成块，不跟正文混切。这个规矩看起来基础，但能救回大量检索时的上下文完整性。

def split_into_chunks(markdown_text: str, max_chars: int = 1000) -> list[str]: # 简单示例：优先在空行处切，超长再强制切 blocks = markdown_text.split("\n\n") chunks = [] current = "" for block in blocks: if not block.strip(): continue if len(current) + len(block) > max_chars: if current.strip(): chunks.append(current.strip()) current = block else: current += "\n\n" + block if current.strip(): chunks.append(current.strip()) return chunks

5.5 用质检指标给整条管道兜底

管道搭完后要有一个自动质检环节，不然你永远不知道解析精度会不会在线性恶化。我常用的指标有三个：

1. 页面级提取率：提取字符数 / 渲染页面估算字符数（可以用图像面积按经验估算），低于阈值则标记重试。
2. 表格结构校验：表格解析后行列数和原始页面对齐情况，抽查自动比对。
3. 多模态复查率：对随机抽样的 5% 页面做多模态模型二次解析，对比主要差异。

这个质检不需要很精确，它的目标是兜住明显异常：比如某页因为渲染分辨率太低导致 OCR 一片空白，或者工具版本升级后解析逻辑出现兼容性问题。没有这道质检，数据管道跑一夜后你只会收获一堆默默污染知识库的坏数据。

6. 图片型内容进 RAG 的三种姿势：文本化、描述化、多模态检索

6.1 直接回答“RAG 知识库到底能不能存图片”

这个问题问的人太多了，因为很多人的知识库里确实需要管图片：产品图、聊天截图、流程图、拍摄的试卷照片、问卷拍照内容。答案是可以，但要知道存的方式和存文本完全不同。

• 向量库本质上存的是向量，不是图片文件本身。图片要么被转成一段文本后嵌入，要么通过专门的视觉编码器变成一个向量。
• 如果直接把图片二进制文件丢给常规文本 embedding 模型，得到的向量没有包含图片语义，检索基本作废。
• 所以“图片进 RAG”实际要决定的是：图片的语义用哪种方式表达。

6.2 姿势一：OCR 文本化，简单但丢信息

把图片 OCR 成一段文字，然后当普通文本向量化入库。这个方案最省事，但有两个天然缺陷：

• 图表中的关系性信息会丢失，比如流程图的分支逻辑、拓扑图的连接关系。
• 检索命中后返回的是文本，如果用户希望看到原图，你还需要额外维护“文本块-原图路径”的索引关系。

它的适用场景是：纯文字的截图、合同拍照件、问卷答案照片。这类图片的信息主体本来就是文字，OCR 化几乎没有损失。文本化足够解决大部分实际需求。

一个实际例子：问卷系统里的拍照上传功能，用户拍一张纸质问卷，后台 OCR 识别出答案文本，再进知识库。这种场景只用 OCR 文本化就够了，没必要动用多模态模型。

6.3 姿势二：描述化（Image Captioning），保留原图，增强语义

第二种做法是：先用多模态模型给图片生成一段结构化描述，比如“这张图是网络拓扑图，中间是核心交换机，向下连接三个接入交换机……”然后把这段描述向量化入库，同时保存原图路径。检索时命中描述文本，再将对应的原图展示给用户或交给下游模型。

这个方案最适合“图片本身就是核心资产”的场景：产品手册中的结构爆炸图、UML 类图、系统架构图、流程截图。它比 OCR 文本化的优势在于：描述的语义是显式的，模型能看懂各元素的布局关系，检索时以“拓扑”“链路”“分支”“上下级”这类关系词命中，而不是靠零散的文字词汇碰运气。

实际项目中我会把原图的缩略图 URL、原始文件路径、描述文本三样东西都存进元数据，保证下游无论走 LLM 还是走人肉查看都能回溯到真实图片。

6.4 姿势三：多模态联合检索（图文向量直查）

如果知识库本质是“图多文少”的图片库，比如相册、设计素材库、图纸库，那么 OCR 和描述文本都很绕路。更直接的做法是：用视觉 embedding 模型把图片本身编码成向量，与文本向量一起放进同一个向量索引，查询时用户输入文字，命中图文混合的向量。

常用的视觉编码器包括 CLIP 系、SigLIP、Jina CLIP v2 等。查询过程是：用户自然语言 → 文本编码器转成向量 → 在混合索引里按余弦相似度找最相关的图片和文本块。这样既可以用文字搜图，也能用图搜图。

这个方法的问题是部署成本和硬件需求相对高，视觉编码器和文本编码器要保持对齐，建议在中小规模图片库上先用，别一上来就想管理上百万张图。对大多数个人知识库和中小公司来说，描述化方案已经够用了。

6.5 三种姿势的混合使用建议

现实中我不会只用一种姿势。常见的混合策略是：

这个混合策略在数据导入时只多花一点额外算力，在检索端的体验会提升很多。每类图片的解析结果都会带上 type 标签，检索时可以在元数据里做类型过滤，需要图文证据链的时候按图索骥，不需要时直接返回文本答案。

支撑这种混合策略的工程前提，就是前几章讲的那条混合解析管道：文字层检测、OCR 分流、多模态补充。链路统一了，图片处理就不再是知识库项目中的第二个方案，而是和文本处理平级的一条完整通路。

我在搭这条管道时最深的体会是：数据导入流程里每一步看似都在处理“格式”，实际上处理的都是“保持语义完整性”这件事。PDF 解析选型也好，OCR 兜底也好，多模态读图也好，全都是在尽量还原原始文档的信息结构，而不是把文字榨出来那么简单。刚起步的时候，不用追求一次性搭出完美的管道，最可行的路径是：先用文字版 PDF 跑通全文链路，再逐步加入扫描版和多模态，最后再把图片描述化补进来。每加一层，用二三十个真实样本对比一下召回质量，你会很清楚地看到哪一层的投入产出比最高。