企业官网建设流程全解析

做这套图文兼容的 PDF RAG 方案，起因是我最近在整理一批混合型文档——里面有扫描件、有带文本层的页面、有大量图表和复杂表格。用常规的 PDF 解析 + 向量化管线跑了几天，检索效果一言难尽：文字段落能召回，但问到“这个趋势图的转折点在哪”或者“这张表格里第三季度的环比”就彻底断电。后来我把 PyMuPDF 的版面解析和 Qwen-VL 的视觉理解接进来，走了双通道的思路，才把这类问题压下去。这篇文章就把这套方案的完整设计、落地代码、参数选择和踩坑复盘一次讲透。

先说清楚这套方案适合谁：手头有 PDF 需要做知识库问答、文档检索增强生成，且文档里图表和扫描页占比不低的工程师；或者你已经在跑 RAG，但被 PDF 解析质量卡住，想找一个低成本升级路径的同学。它不依赖昂贵标注数据，核心就两件事——用 PyMuPDF 把页面拆成带坐标的语义块，再用 Qwen-VL 对非文本区域做结构化描述，最后把“文本通道”和“视觉通道”统一进向量库。下面我按决策过程、架构设计、具体实现、问题排查的顺序来写。

1. 为什么纯文本思路做不好 PDF RAG

1.1 传统 PDF 解析的三个致命盲区

做 RAG 的人最容易被“PDF 里明明有文字，为什么检索不到”这句话逼疯。我归纳下来，纯文本解析通常死于三种情况。

第一是分栏和阅读顺序错乱。PDF 的文本层是按块存储的，双栏论文页在三栏排版的杂志上经常被切得七零八落。PyMuPDF 提取出来的 block 顺序如果直接用，你会发现一句话的主题在第一栏，它的下文跑到第二栏，向量化之后两段内容被拆成了互不相关的碎片。第二是图表内容在文本层里根本不存在。折线图、柱状图、UML 图、架构图，在 PyMuPDF 的 get_text() 眼里就是一页空白，最多抓到几个图例文字。你问“这个方案的平均延迟是多少”，答案在图表里，但文本层检索不到，召回率为零。第三是扫描件完全没有文本层。这类 PDF 本质是图片集合，你需要 OCR，而传统 OCR 对公式、密集表格、水印干扰的鲁棒性很一般，识别完还会引入错别字噪声。

1.2 PyMuPDF 能解决什么，解决不了什么

PyMuPDF（fitz）是我在 PDF 解析层面用得最顺手的一个库，不因为别的，就是它能把“文本内容”和“空间位置”绑定到一起。page.get_text("dict") 返回的 block 结构里，每个块都带 bbox，也就是矩形坐标。有了坐标，你就可以做版面切割：把页面切成左栏、右栏、标题区、图表区；你可以判断两个 block 是否属于同一个语义段落；你还可以把某一小块区域渲染成高清图片。这个“坐标到区域”的能力，是后面视觉通道能够精准裁剪的前提。

但 PyMuPDF 自己不理解图像语义。它知道这张图在哪个位置，不知道图里画的是什么趋势；它知道这有个表格框线，但提取出来的文本顺序和单元格对应关系经常是乱的。所以我的结论是：PyMuPDF 负责“把页面拆得清楚”，Qwen-VL 负责“把看不懂的区域说清楚”，两者是互补关系，不是替代关系。

1.3 Qwen-VL 在这个场景里的定位

选择 Qwen-VL 而不是传统 OCR 或者单纯用文本解析，核心原因是语义密度。OCR 只能把像素变成文字，但复杂图表里最重要的不是每个字，而是“图表的结论”。比如一张销售趋势图，OCR 能识别出横纵轴标签和几个数值，但回答不了“整体趋势在哪个阶段加速”。Qwen-VL 这类多模态模型能做到的是，把整张图作为一个整体理解，输出：“该图展示 2020 至 2024 年营收变化，整体呈上升趋势，2022 年增速明显放缓，2023 年起恢复增长。”这种描述放进向量库里，检索质量完全不一样。

但我必须提醒：视觉模型不是免费的午餐。它推理慢、token 贵，而且会编造细节。你不能把每一页都整页丢给 Qwen-VL，否则成本爆炸，幻觉也爆炸。方案里要做“精准裁剪、按需启用”，只让视觉模型看它该看的图。

2. 双通道架构的整体设计

2.1 核心设计理念：文本和图像分开处理，统一索引

我把整个链路定义成两个并行通道。

文本通道：用 PyMuPDF 提取文本块，按空间位置合并分栏，过滤页眉页脚噪声，切分成块，然后向量化。

视觉通道：用 PyMuPDF 检测非文本区域（图片、表格、复杂版面），按 bbox 裁剪成子图，送入 Qwen-VL 生成结构化描述，再把“描述文本”作为该区域的文本表示，向量化。

两条通道产出的节点最后都写入同一个向量集合，但节点元数据里标记source_type: text或source_type: vision。检索的时候同时命中两条通道，混合召回后再交给生成模型。用一句话概括：文本通道保底，视觉通道补全。

为什么这样做？因为排版分层。以常见的技术文档为例，一个页面的信息密度往往是这样的：段落文字大概占 60% 面积，但信息量占比很高；图表和表格占 40% 面积，传统管线的信息占比接近零。双通道的目的不是把两张结果简单叠加，而是让每一平方厘米的版面信息都能被“翻译”成一个可检索的文本节点。

2.2 技术选型的备选考量

可能有人问：这套方案的每一步都有替代品，为什么偏偏选这两件？

PDF 解析这一步，可选的还有 pdfplumber、pdfminer.six、camelot、PyMuPDF。pdfplumber 对表格提取做得精细，但在坐标体系、图像渲染上绕很多弯；camelot 依赖 OpenCV，安装重，而且只在规整表格上表现好。PyMuPDF 的优势是：同时提供文本提取、布局坐标、页面渲染、区域裁剪，API 统一，一个大文件全部搞定。这是它作为“底座”的最大理由。

视觉理解这一环，可选的也有 GPT-4o、InternVL、MiniCPM-V。选 Qwen-VL 是因为它在中文文档上的理解能力和可控的本地部署成本，同时在函数调用和结构化输出上有比较成熟的 prompt 兼容性。2B 和 7B 的模型如果只是用来做图表描述，显存压力比部署一个满血大模型小很多。如果你要用在线 API，流程一样，只是把本地推理换成 HTTP 调用。

2.3 从 PDF 页面到可检索节点：全流程总览

我把流程拆成五个阶段，每个阶段有明确的输入输出。

1. 页面解析阶段：输入 PDF 路径，输出页面对象列表，以及每个页面的文本块列表和图像块列表。
2. 区域切分阶段：根据文本块的 bbox 和图像块的 bbox，判断重叠关系，决定哪些区域要送去视觉模型。
3. 视觉描述阶段：对选中区域进行高清渲染，构造提示词，调 Qwen-VL，得到 JSON 格式的描述。
4. 节点组装阶段：把纯文本块和视觉描述各自封装成 Node，附加元数据（页码、坐标、来源类型、标题层级）。
5. 索引与检索阶段：向量化全部 Node，建立索引，查询时混合召回。

这张总览图式的框架，后面每一章都是其中一环的具体展开。值得强调的是，阶段 2 的“区域切分”是最容易做砸的，因为 bbox 是否重叠、裁多大的边距、以什么规则判定“这属于一个表格”，都需要针对文档实际情况微调。我在下一节给出一个比较稳的默认策略。

3. 核心细节解析与实操要点

3.1 PyMuPDF 文本块提取：用 dict 模式而不是 get_text()

先看最基础的代码，提取文本块并保留坐标。

import fitz def extract_text_blocks(page): blocks = page.get_text("dict", flags=fitz.TEXTFLAGS_TEXT)["blocks"] results = [] for block in blocks: if block["type"] != 0: continue bbox = block["bbox"] lines = block["lines"] block_text = "" for line in lines: for span in line["spans"]: span_text = span["text"].strip() if span_text: block_text += span_text block_text += "\n" if block_text.strip(): results.append({ "bbox": bbox, "text": block_text.strip(), "block_no": block["number"] }) return results

注意几个点。TEXTFLAGS_TEXT会过滤掉一些隐藏文字，避免把 PDF 里不可见的注释文本带进来。按 span 拼 text 时，不要只拼 line 的"text"字段，因为某些字体编码可能导致该字段为空，而 span 层是最可靠的最小单位。另外，一个页面上可能有几十个 block，但有些 block 是页眉页脚，后面需要用规则剔除。

这里“为什么”要说清楚：get_text("dict")返回的是完整结构化的 block-line-span 三级结构，而get_text("text")只给你纯字符串。纯字符串看起来简单，但你丢掉了坐标，后面想做分栏合并、区域裁剪就完全没抓手。坐标是这套方案的元数据命脉。

3.2 分栏合并策略：按 x 坐标做阅读顺序重排

双栏页面的 block 顺序是乱的，直接拼会有问题。我的策略是：先按 bbox 的水平中心 x 坐标做一次聚类，把页面分成若干栏，然后按“从上到下”的顺序输出，再对每个栏内部按 y 坐标排。代码思路如下：

def sort_blocks_for_reading(blocks, page_width): # 先粗分类：左栏(x0 < 页宽的一半)，右栏(x0 >= 页宽的一半) left = [b for b in blocks if (b["bbox"][0] + b["bbox"][2]) / 2 < page_width / 2] right = [b for b in blocks if (b["bbox"][0] + b["bbox"][2]) / 2 >= page_width / 2] left.sort(key=lambda b: b["bbox"][1]) right.sort(key=lambda b: b["bbox"][1]) return left + right

这只是一个基础方案，遇到三栏或者更复杂的浮动布局，可以用 KMeans 对 block 中心点 x 坐标聚类，栏数设为 2 或者 3，然后按聚类中心排序。实际效果上，双栏学术论文这个策略足够用。这个步骤的价值在于：顺序对了，分块才是连续的；分块连续了，向量语义才有上下文。

3.3 图像区域识别：如何找到“该给视觉模型看的东西”

判断一块区域是否需要走视觉通道，我总结了三条规则，按优先级判断。

1. 该区域是嵌入图片：PyMuPDF 的 dict 输出中 type 为 1 的 block 是图片块，直接提取 bbox。
2. 该区域是表格或其他复杂对象：当前版本 PyMuPDF 有page.find_tables()可以直接返回表格位置，尤其适合线框明显的表格。
3. 该区域内文字块之间间隔稀疏、且包含大量空白：这种情况通常是只有几个图注文字的图表区域，文本通道信息量极低。

实际代码里，我把规则 1 和规则 2 的 bbox 汇总，再去重，再与文本块 bbox 做交集判断。如果某个文本块几乎完全落在图片块的 bbox 内部，那这个文本块大概率是图内嵌文字，没必要重复进文本通道。合并之后的区域列表，就作为视觉通道的原始输入。

3.4 区域裁剪与高清渲染：一个必须仔细处理的坐标换算

PyMuPDF 的 bbox 坐标系和渲染出的图片像素坐标系不是一回事，这是新手最容易掉进去的坑。PDF 默认坐标系原点在页面左上角，单位是点（point），1 点 = 1/72 英寸。当你用get_pixmap(matrix=fitz.Matrix(zoom, zoom))渲染图片时，缩放因子 zoom 决定像素尺寸：zoom 为 2 表示 144 DPI，3 表示 216 DPI。裁剪图片时，pdf_bbox 的四个值都要乘以 zoom 才是像素坐标。

from PIL import Image import io def crop_region(page, bbox, zoom=2.0): mat = fitz.Matrix(zoom, zoom) pix = page.get_pixmap(matrix=mat, alpha=False) img = Image.open(io.BytesIO(pix.tobytes("png"))) x0, y0, x1, y1 = bbox # 注意：裁剪坐标必须取整 crop_img = img.crop((int(x0 * zoom), int(y0 * zoom), int(x1 * zoom), int(y1 * zoom))) return crop_img

这里给个实操经验：缩放因子不要低于 2.0。我做过一组对比，zoom=1.0 时 Qwen-VL 对图内小字体的识别明显变差，zoom=2.0（对应 144 DPI 渲染）是一个质变拐点；再往上提高到 3.0，对识别小字号数字有帮助，但耗时上升明显。如果你的文档里有很多数据密集型表格，建议对表格区域单独用 zoom=3.0 渲染，而不是整页 3.0。

3.5 Qwen-VL 提示词与结构化输出

视觉模型最忌讳的提示词是“描述这张图片”。你要给出格式、给出角色、给出约束，最好让它输出 JSON。我的默认模板这样写：

VLM_PROMPT = """ 你是一个专业文档理解助手。请分析这张来自技术文档的截图，完成以下任务： 1. 判断内容类型：figure(图表/示意图)、table(表格)、code(代码块)、other 2. 用中文概括这段内容的主题和关键信息，要求逻辑完整，覆盖所有可见的数值、结论、变化趋势。 3. 如果其中有数字，必须保留原数字；如果内容不清晰，请说明不确定，不要猜测。 严格输出 JSON 格式，不要包含额外说明： {"type": "...", "summary": "...", "key_points": ["...", "..."]} """

调用 Qwen2.5-VL 系列模型时，注意构建 messages 的方式。当前 transformer 版本推荐用 processor 直接处理图像和文本：

from transformers import Qwen2VLForConditionalGeneration, AutoProcessor model = Qwen2VLForConditionalGeneration.from_pretrained( "Qwen/Qwen2.5-VL-3B-Instruct", torch_dtype="auto", device_map="auto", ) processor = AutoProcessor.from_pretrained("Qwen/Qwen2.5-VL-3B-Instruct") def describe_region(crop_img, prompt=VLM_PROMPT): messages = [ {"role": "user", "content": [ {"type": "image"}, {"type": "text", "text": prompt} ]} ] text = processor.apply_chat_template(messages, tokenize=False, add_generation_prompt=True) inputs = processor(text=[text], images=[crop_img], return_tensors="pt") inputs = inputs.to(model.device) generated_ids = model.generate(**inputs, max_new_tokens=512) output = processor.batch_decode( generated_ids[:, inputs.input_ids.shape[1]:], skip_special_tokens=True )[0] return output

生成结果用json.loads解析，解析失败时加一层容错：把输出里被 ``` 包裹的 JSON 部分提取出来再解析。这个容错必须做，因为模型偶尔会多输出几句废话。

关于模型尺寸的选择，我用 3B 部署在一张 16G 显存的卡上，单图推理大概 1.5 到 2 秒；如果你有 7B 或更大型号，质量会更好，但成本线性上升。我的建议是先跑通 3B，确认整条链路没问题，再按需升级。

4. 实操过程与完整代码实现

4.1 环境准备与依赖清单

我的运行环境是 Python 3.10 + CUDA 12.1，显存 16G。依赖如下：

pip install pymupdf pillow transformers sentence-transformers faiss-cpu accelerate

说明一下每个库的位置：pymupdf 负责解析和渲染；pillow 负责图像裁剪和转换；transformers 负责加载 Qwen-VL；sentence-transformers 负责文本和描述向量化；faiss 负责索引检索。向量模型的选型，我用的 BAAI/bge-large-zh-v1.5 ，它对中文长文本效果稳定，而且带查询指令前缀的用法能提升匹配精度。如果你处理的文档主要是英文，可以用 bge-large-en-v1.5；混合语料建议分开建索引。

4.2 文档解析模块：把 PDF 变成区域节点列表

整个解析模块的入口函数，抽象成下面这样：

import fitz import re PAGE_HEADER_FOOTER_KEYWORDS = ["第", "页", "共", "版权所有", "目录"] def parse_pdf_to_nodes(pdf_path, dpi=144): doc = fitz.open(pdf_path) nodes = [] for page_idx, page in enumerate(doc): text_blocks = extract_text_blocks(page) # 过滤页眉页脚：要么高度太靠边，要么包含关键词 filtered_blocks = [] for block in text_blocks: bbox = block["bbox"] if bbox[1] < 40 or bbox[3] > page.rect.height - 40: continue if any(kw in block["text"] for kw in PAGE_HEADER_FOOTER_KEYWORDS): continue filtered_blocks.append(block) # 重排阅读顺序 ordered_blocks = sort_blocks_for_reading(filtered_blocks, page.rect.width) # 段落合并：当两个块之间的垂直间距小于某个阈值时合并 merged_blocks = merge_close_blocks(ordered_blocks, page_height=page.rect.height) for block in merged_blocks: if is_likely_figure_area(block, page): crop_img = crop_region(page, block["bbox"], zoom=2.0) desc = describe_region(crop_img) nodes.append({ "text": desc, "page": page_idx, "bbox": block["bbox"], "source_type": "vision", }) else: nodes.append({ "text": block["text"], "page": page_idx, "bbox": block["bbox"], "source_type": "text", }) return nodes

merge_close_blocks 是这个模块里最需要调参的部分。我把它定义成“如果当前块和前一个块，在同一栏内，且两者 y 方向间距小于当前块行高的 0.6 倍，就合并”，这可以避免把一个自然段切成两半。阈值设置需要观察你的文档排版，不同文档差异会很大，建议处理一批后打印合并结果人工抽查。

4.3 向量化与索引构建：混合节点的统一处理

拿到节点列表后，统一走向量化。这里有一个小技巧：文本通道的节点和视觉通道的描述，在向量化时可以用不同的 query instruction。

具体来说，bge 模型在检索时习惯给 query 加指令，给 document 不加指令。如果你把视觉描述也当作 document 处理，直接用 encode 就行。但如果你的检索 query 往往是对图表的自然语言提问，比如“2023 年营收是多少”，它和视觉描述文本的语义空间可能存在一点偏移。为了尽量对齐，我在索引时对视觉描述文本做一次轻量改写，让它更接近于“查询答案”的形态。这不算标准做法，是我在实测中发现比较好用的小技巧。

from sentence_transformers import SentenceTransformer model = SentenceTransformer("BAAI/bge-large-zh-v1.5") def embed_nodes(nodes): texts = [] metadatas = [] for node in nodes: texts.append(node["text"]) metadatas.append(node) embeddings = model.encode(texts, normalize_embeddings=True) return embeddings, metadatas

索引文件我直接用 faiss。IndexFlatIP 足够支撑十万级别节点，不需要上 IVF。构建索引：

import numpy as np import faiss embeddings, metadatas = embed_nodes(nodes) embedding_dim = embeddings.shape[1] index = faiss.IndexFlatIP(embedding_dim) index.add(embeddings.astype("float32")) faiss.write_index(index, "doc_index.faiss") # 元数据存 jsonl，方便检索时回溯 import json with open("doc_meta.jsonl", "w", encoding="utf-8") as f: for meta in metadatas: f.write(json.dumps(meta, ensure_ascii=False) + "\n")

注意：IndexFlatIP 要求向量已经做过归一化，所以 encode 时要加normalize_embeddings=True，否则内积分数没有意义。这一步很多人漏，导致排序结果不可解释。

4.4 检索与生成：混合召回和上下文构造

检索的逻辑分三步：query 向量化、top-k 召回、按类型加权重排。加权重排是我针对图文混合场景强加的一步。因为视觉通道的节点数量天然少于文本节点，如果不加权，最终 top-k 里几乎全是文本节点，图表的描述很难被选中。我给视觉节点一个 1.2 倍的得分加成，这个数字是经验值，你可以通过验证集调优。

def search(query, k=8, vision_weight=1.2): q_emb = model.encode(query, normalize_embeddings=True) scores, indices = index.search(q_emb.reshape(1, -1).astype("float32"), k * 2) results = [] for i, score in zip(indices[0], scores[0]): meta = metas[i] final_score = score * vision_weight if meta["source_type"] == "vision" else score results.append({"meta": meta, "score": final_score}) results.sort(key=lambda x: x["score"], reverse=True) return results[:k]

如果这一步之后你发现检索结果里同一页重复内容太多，可以做一轮 MMR（最大边际相关性）去重。MMR 的实现不复杂，但能明显提升生成质量，核心逻辑是每次选择与 query 相关分数高、且与已选结果相似度低的节点。我在演示里没有放完整代码，但建议线上系统加上。

最终生成部分，用 Qwen2.5-7B-Instruct 或者任何你本地部署的开源模型都可以。模板如下：

def build_prompt(query, retrieved_nodes): context_parts = [] for i, node in enumerate(retrieved_nodes): src = "图片描述" if node["meta"]["source_type"] == "vision" else "正文段落" context_parts.append( f"[{i+1}](来源:{src}, 页:{node['meta']['page']})\n{node['meta']['text']}" ) context = "\n\n".join(context_parts) prompt = f"""请根据以下参考资料回答问题。如果参考资料中没有相关信息，请明确回答“资料中未找到”。回答时请标注引用的参考编号。 参考资料： {context} 问题：{query} 回答：""" return prompt

这步要提醒：视觉描述是 Qwen-VL 二次生成的文本，存在幻觉风险，所以生成阶段必须让主模型区分哪些是“图片描述”，并对其保持一定的怀疑。我在提示词里加了“资料中未找到”的允许项，就是为了降低主模型强行从噪声上下文里编答案的概率。

5. 常见问题与排查技巧实录

5.1 文本块坐标偏移：渲染图与 bbox 对不上怎么办

这是第一个最容易遇到的现象：裁剪出来的图片区域整体偏移，内容被截断。原因基本就一个——没有乘以渲染缩放因子。PDF 的 bbox 以点为绝对值，渲染之后图像坐标系按像素走，中间差多少倍全看你当时的 zoom。排查办法很简单：把裁剪框的坐标打出来，和原始 bbox 对照一下，看看是否满足pixel = point * zoom。如果整体偏移几个像素，可以给裁剪框加向外扩的边距：

crop_box = (max(0, int(x0 * zoom) - 10), max(0, int(y0 * zoom) - 10), int(x1 * zoom) + 10, int(y1 * zoom) + 10)

这个 10 像素的边距能兜住大部分奇怪的字形边缘和轻微定位偏差。

5.2 Qwen-VL 输出解析失败：JSON 不稳定

多模态模型输出 JSON 偶尔会夹杂空行、markdown 代码围栏或者模型用自然语言加的前置说明。我写了一个extract_json函数：先尝试直接 json.loads，失败就用正则把{...}部分抓出来再试，再失败就把整个输出交给一个规则清洗函数，把换行和引号转义问题修正。实测下来，这个三级容错基本能覆盖 99% 的输出情况。

但更值得做的其实是把提示词里 JSON 格式示例直接给出完整的值示例，而不是只给字段名。模型看到示例值之后，模仿输出的稳定性会好很多。有一次我把"type": "table"这种具体值写进提示词里，失败率从 12% 降到 3%，这属于纯 prompt 工程经验。

5.3 视觉通道节点过少或过多：区域识别阈值调整

如果视觉节点太多，说明你把大量普通文本段落也裁成了图片，浪费了推理时间；太少，说明你漏掉了真正的图表。我的调优经验是：先看page.get_text("dict")里type为 1 的图片块数量和面积占比。如果页面图片面积超过 20% 但视觉节点几乎为零，那多半是图片块被文本块覆盖，需要把“文本块完全重叠于图片块”的判断逻辑放宽到“80% 面积重叠”。反过来，如果你的文档是 PPT 转的 PDF，每一页可能整页都是一个图形对象，这时候必须把视觉通道限制在 max_images_per_page=2，否则推理成本失控。

5.4 检索结果被页眉页脚污染

页眉页脚文本的 vector 很短，有时会出现语义漂浮，检索时反而被错误命中。我建议在过滤阶段就用硬规则：bbox 距离页面顶部或底部小于 50 point 的块直接丢弃；同时把包含“第 X 页”这种强模式的内容用正则排除。还有一个更稳的做法，是建一个停用词表，对长度小于 8 个字符的块直接不进索引，因为它们携带的信息量太低，只会拉低检索精度。

5.5 GPU 显存不足：流水线串行仍然爆显存

如果你的显卡只够跑 3B 模型，不要同时做向量化和 Qwen-VL 推理。建议处理流程里先全量跑完 Qwen-VL 生成视觉描述，释放显存，再加载向量模型做索引。我在实测中踩过一次：试图把两个模型同时放显存，结果 OOM 了三次才意识到该串行。串行多花十几秒钟，但稳定很多。如果文档量大到串行不可接受，那也不是本地单卡能解决的规模，该考虑部署成两个服务，或者用在线 API。

5.6 实测效果：文本通道与视觉通道的增益对比

我用一份 80 页的技术白皮书做了对照测试。文档结构大概一半正文、一半图表和分栏展示页。测试问题集 20 个，人工标注正确答案所在信息类型。

可以看到，双通道方案最大的收益来自图表类问题的召回率从 5% 拉到了 89%。损失主要是处理耗时变长了，但这对于离线建索引来说完全可接受。表格数值类问题还有提升空间，因为复杂表格的渲染质量受限于原始 PDF 的清晰度，低清晰度扫描件即使喂给 Qwen-VL 也会损失精度。

6. 一些沉淀下来的经验建议

这套方案我从搭建到调优花了大概两周，最深的体会有两点。

第一，解析阶段花钱花时间，永远比检索阶段调参更值得。我一开始把精力都放在向量模型和检索策略上，结果发现不管怎么调，召回上限被文本解析质量死死压着。后来把版面切分、区域识别做细致了，检索效果自然就上来了。RAG 系统很像水管工的工作：源头过滤干净了，水龙头拧开才不会有杂质。

第二，视觉描述需要留“不确定”的出口。我让 Qwen-VL 输出时，如果看不清就写“图像不清晰，无法准确判断”，这句话在检索时可能召回率不高，但在生成阶段能防止模型一本正经地编造答案。多模态模型的幻觉问题不是靠提示词彻底解决的，而是在系统设计上给它一个“认怂”的路径。

如果后续要扩展，我的计划是把表格区域单独抽出来做结构化抽取，配合 PyMuPDF 的find_tables()能力，把表格转成 Markdown 或行级 JSON 再进索引。这套路线的上限更高，也值得花时间探索。你先跑通双通道版，再往结构化方向走，路径比我这样一步步踩过来要平滑得多。