一、背景与痛点为什么“纯文本 RAG”在企业文档面前会崩过去两年绝大多数企业级“文档问答”系统都建立在同一条脆弱的流水线上PDF → OCR/解析库 → 纯文本 → 切分 → 向量化 → LLM 回答这条链路在纯文字 PDF 上表现尚可但一旦面对真实业务文档——财务报表、招股书、医疗检验单、工程图纸、带批注的合同扫描件——它会在三个环节同时失效版面信息丢失。双栏排版被拉平成一行行乱序文本表格变成一堆用空格拼接的数字页眉页脚混入正文。你不光丢掉了“哪一列是 2023 年营收”还丢掉了“这是一个三线表”这个事实。2.OCR 误差累积。OCR 的字符错误率哪怕只有 2%在识别率最差的那 2% 里往往恰好是金额、编号、单位——也就是最不能错的部分。而误差一旦进入向量库就永久固化了。3.不可回答的问题类型。用户问“这份合同里第三页的签字盖章是否完整”“这张图表的趋势是上升还是下降”纯文本链路从设计上就答不了。这三类失败不是彼此独立的工程 bug而是同一个根因的不同表现传统 RAG 把文档当成“一维字符流”而真实文档的信息是“二维甚至三维”的。一个数字是“本期”还是“上期”取决于它所在的表头行一个条款是否生效取决于签署页有没有那枚红章一个金额属于哪一列取决于它在页面上的横向位置。切分器把二维语义压成一维字符串的那一刻这些关联就被永久切断了而且切分之后无法恢复——下游再强的 LLM 也猜不回它没看到的东西。更隐蔽的问题是嵌入模型对数字几乎“免疫”。12,345,678.90和12,345,679.80在向量空间里的余弦相似度通常在 0.99 以上检索时会被当成同一段内容。但在财务、医疗、法务场景里这 0.9 元的差异恰恰是全部意义所在。下面这张表可以更直观地说明问题边界文档类型纯文本 RAG 表现主要失效点多模态方案收益单栏纯文字 PDF良好几乎无明显问题低不值得走视觉双栏论文 / 财报中等阅读顺序错乱、跨栏串行高含合并单元格的表格差单元格错位、表头丢失极高扫描件 / 影印合同差OCR 误差叠加、无版面极高图表、流程图、工程图纸基本不可用信息本身非文本唯一可行方案发票、票据、表单差键值对关系断裂极高多模态大模型LMM改变了这条链路的根本假设不再需要把文档“翻译”成文本模型可以直接看页面。这不是精度上的小改进而是架构上的范式切换。二、核心原理多模态模型是怎么“看懂”一页 PDF 的2.1 三种融合范式范式代表特点双塔对比学习CLIP、SigLIP图文对齐强但无法做生成适合检索交叉注意力融合Flamingo、Qwen-VL 早期视觉特征以 cross-attention 注入 LLM参数效率高视觉 Token 化Early FusionGPT-4o、Qwen2-VL、InternVL图像 patch 直接投影成 token与文本 token 拼接进同一序列三种范式的差别值得展开一点因为它直接决定了你的技术选型双塔对比学习用 InfoNCE 损失把匹配的图文对拉近、不匹配的推远产物本质上是一个“相似度函数”。你可以拿 CLIP 做以图搜图、做页面级召回但它无法回答“这张发票的金额是多少”——它没有生成能力也没有细粒度理解能力。交叉注意力融合以 Flamingo 为代表冻结 LLM在层与层之间插入 gated cross-attention并用 Perceiver Resampler 把变长的视觉特征压成固定数量的 latent 向量通常 64 个。优点是视觉 token 数量恒定可控、训练成本低缺点是视觉信息经过多轮压缩后细节损失明显——对“读清 6 号字的一行数字”这种任务并不友好。视觉 Token 化是今天的绝对主流。图像 patch 过完 ViT 之后直接接一个 MLP或 Q-Former投影到词嵌入空间像文本 token 一样进入同一个 Transformer。它的最大好处是不确定性的来源变少了没有 OCR 中间层没有版面重建规则模型端到端地学“看到什么、答什么”。目前主流方案是第三种。它的核心组件只有两个视觉编码器通常是 ViT把图像切成固定大小的 patch如 14×14 或 16×16 像素每个 patch 编码成一个向量。投影层MLP 或 Q-Former把视觉向量映射到 LLM 的词嵌入空间使其与文本 token “同构”。于是模型看到的输入实际上是[img v1 v2 ... vN /img] 请提取这张发票的金额和税额这里有一个容易被忽略的认知要点img与/img之间的视觉 token 并不是“一张图的文本摘要”它们就是图像本身。不存在一层可读的中间表示作为退路一旦某个 patch 的投影出错信息就真丢了。这也解释了为什么分辨率与压缩策略会如此关键。补充一点工程上很关键的细节今天的 Qwen2-VL / Qwen2.5-VL 还引入了M-RoPE多模态旋转位置编码把一维位置编码拆成时间t、高度h、宽度w三个分量。这样模型才能天然理解“这个 token 在第 3 行第 5 列”而不是像早期方案那样把二维 patch 拉平成一维序列后彻底丢失空间关系。对表格、票据这类强结构化文档M-RoPE 带来的提升是决定性的。2.2 Token 成本多模态开发的第一性约束这里有个必须刻进肌肉记忆的公式视觉 Token 数≈H×Wpatch_size2\text{视觉 Token 数} \approx \frac{H \times W}{\text{patch\_size}^2}视觉Token数≈patch_size2H×W一张 1024×1024 的图用 14×14 的 patch就是5352 个 token。一页 200 DPI 渲染的 A4 扫描件约 1654×2339 像素不做任何处理就是约 20000 个 token。一本 100 页的年报光图像 token 就是 200 万——远超任何模型的上下文窗口账单也会非常难看。把不同渲染规格摊开看量级差异一目了然渲染规格分辨率约无压缩 token 数2×2 merging 后成本量级150 DPI A41240 × 1754≈ 11,100≈ 2,780中200 DPI A41654 × 2339≈ 19,700≈ 4,930高300 DPI A42480 × 3508≈ 44,400≈ 11,100极高1280×28×28 预算上限≈ 1,003,520 px——≈ 1,280低比计费更早出现问题的是显存。KV Cache 的大小与序列长度线性相关以 Qwen2-VL-7B28 层、4 个 KV head、head_dim 128、FP16为例每个 token 的 KV Cache 约 56 KB1000 个视觉 token 就是约 56 MB一页 200 DPI 扫描件约 2 万 token单项就要吃掉 1.1 GB 显存。8 路并发一上来显存直接爆掉——这不是调优问题是物理问题。所以现代模型都引入了动态分辨率 视觉 token 压缩Qwen2-VL 的 Naive Dynamic Resolution 允许任意分辨率输入并通过 2×2 patch merging 把 token 数降到 1/4实践中通常用max_pixels/min_pixels直接约束 token 预算例如max_pixels 1280 * 28 * 28 ≈ 1,003,520像素约对应 1280 个视觉 token。核心工程原则一页文档的视觉 token 预算应当控制在 1000~2000 之间超过这个量级的收益递减成本却线性上涨。反过来说如果你的抽取任务需要看清 6 号字正确做法不是把整页提到 300 DPI而是先定位、再裁剪、只对目标区域提分辨率。2.3 一个关键判断文本层可用就不要走视觉这是我见过最多团队踩的坑——盲目全量转视觉。实际上原生电子版 PDF的文本层是矢量信息100% 准确、零 token 成本对视觉而言扫描件才必须走视觉路径。还有一个常被忽略的中间态混排 PDF前几页是电子版封面后面是扫描的附件以及**“伪文本层”PDF**——某些 OCR 软件处理后会往 PDF 里塞一层哈希乱码文本字符数看着很足实际完全不可读直接喂给 LLM 只会污染上下文。正确做法是混合路由先探测文本层质量质量好的走文本通道成本低、精度高差的才降级到视觉通道。而且判断粒度必须是“页”而不是“文件”否则一份 200 页的年报里夹了 3 页扫描表格整本都会被拖进昂贵的视觉通道。三、实战构建智能文档分析助手3.1 整体架构┌─────────────┐ PDF/图片 ───────► │ 文档路由器 │ └──────┬──────┘ 文本层可用 │ 文本层缺失/低质 ┌──────┴──────┐ ▼ ▼ ┌─────────┐ ┌───────────┐ │ 文本通道 │ │ 视觉通道 │ │ 版面还原 │ │ 页面渲染 │ └────┬────┘ └─────┬─────┘ └──────┬───────┘ ▼ ┌───────────────┐ │ 多模态 LLM │ │ 结构化抽取 │ └───────┬───────┘ ▼ ┌───────────────┐ │ 向量库 BM25 │ │ 混合检索 │ └───────────────┘这条流水线里有三个必须明确的工程约定路由发生在页面级路由结果要落库页号 → 通道 → 哈希后续增量更新只重跑变化的页。抽取阶段与检索阶段解耦。抽取输出的是结构化字段带页码、bbox、置信度检索面向的是“字段 原文片段”两者共用同一套 ID 体系回答时才能精确回链。每一页都保留一份“原始视觉副本”缩放后的 PNG因为当抽取结果被人工质疑时唯一可信的证据永远是那页图而不是任何中间文本。3.2 代码示例一文档预处理与混合路由# pip install pymupdf pillow openaiimportbase64importiofromdataclassesimportdataclassimportfitz# PyMuPDFfromPILimportImage MAX_PIXELS1280*28*28# 约 1000 视觉 token 的像素预算RENDER_DPI200dataclassclassPagePayload:page_no:intkind:str# text | imagecontent:str# 文本内容 或 base64 图片def_downscale(img:Image.Image)-Image.Image:按 max_pixels 约束等比缩放避免视觉 token 爆炸。w,himg.sizeifw*hMAX_PIXELS:returnimg scale(MAX_PIXELS/(w*h))**0.5returnimg.resize((int(w*scale),int(h*scale)),Image.LANCZOS)def_text_layer_ok(page:fitz.Page,min_chars:int120)-bool:判断文本层是否可用字符够多且不是乱码。textpage.get_text(text).strip()iflen(text)min_chars:returnFalse# 粗略检测乱码可打印字符占比过低则视为扫描件printablesum(c.isprintable()andnotc.isspace()forcintext)returnprintable/max(len(text),1)0.85defparse_pdf(path:str,dpi:intRENDER_DPI)-list[PagePayload]:docfitz.open(path)payloads:list[PagePayload][]foridx,pageinenumerate(doc,start1):if_text_layer_ok(page):payloads.append(PagePayload(idx,text,page.get_text(text)))continue# 降级到视觉通道渲染成位图pixpage.get_pixmap(dpidpi,colorspacefitz.csRGB)imgImage.open(io.BytesIO(pix.tobytes(png)))img_downscale(img)bufio.BytesIO()img.save(buf,formatPNG,optimizeTrue)b64base64.b64encode(buf.getvalue()).decode()payloads.append(PagePayload(idx,image,b64))doc.close()returnpayloads这段代码有两个设计要点值得说明_text_layer_ok不仅判断字符数量还用可打印字符占比来识别“伪文本层”——不少扫描件经过某些 OCR 软件处理后会在 PDF 里留下一层哈希乱码文本字符数很足但完全不可读。_downscale是成本闸门。先缩放再编码而不是先编码再让模型端缩放可以省下大量上传带宽与预处理延迟。还有一处可以立刻改进的地方当前page.get_text(text)拿到的是阅读顺序未知的一维文本。在双栏文档上这个顺序经常是错的。更稳的写法是取带坐标的块自己按阅读顺序重排def_text_layer_ordered(page:fitz.Page)-str:按 (行, 列) 重排文本块缓解双栏文档的顺序错乱。blockspage.get_text(blocks)# (x0, y0, x1, y1, text, block_no, block_type)blocks[bforbinblocksifb[6]0andb[4].strip()]# 先按 y 粗聚类成行容差取字高的量级再按 x 排序blocks.sort(keylambdab:(round(b[1]/12),b[0]))return\n.join(b[4].strip()forbinblocks)对要求更高的场景可以先用垂直投影做列切分再把每一列当成独立文档排序效果比任何“智能重排提示词”都稳。3.3 代码示例二结构化抽取 引用溯源多模态抽取最怕模型“看着图编数字”。解决办法是强制 JSON Schema 输出并要求模型回填坐标把每一处结论锚定到页面区域。importjsonfromopenaiimportOpenAI clientOpenAI(base_urlhttps://api.your-gateway.com/v1)SCHEMA{type:object,properties:{doc_type:{type:string,enum:[invoice,contract,report,other]},fields:{type:array,items:{type:object,properties:{name:{type:string},value:{type:string},page:{type:integer},# 归一化坐标 [0,1]用于前端高亮溯源bbox:{type:array,items:{type:number},minItems:4,maxItems:4,},confidence:{type:number},},required:[name,value,page,bbox,confidence],additionalProperties:False,},},},required:[doc_type,fields],additionalProperties:False,}SYSTEM_PROMPT你是文档信息抽取专家。规则 1. 只抽取你能在页面中直接看到的字段禁止推断、补全或计算。 2. 每个字段必须给出其所在页面的归一化 bbox左上x, 左上y, 右下x, 右下y取值 0~1。 3. 无法定位坐标的字段一律不要输出。 4. confidence 表示你对该字段的把握低于 0.6 的请一并给出并在 value 中保留原始拼写。defbuild_messages(payloads):content[]forpinpayloads:ifp.kindtext:content.append({type:text,text:f【第{p.page_no}页 文本层】\n{p.content}})else:content.append({type:text,text:f【第{p.page_no}页 图像】})content.append({type:image_url,image_url:{url:fdata:image/png;base64,{p.content},detail:high},})content.append({type:text,text:请按 Schema 抽取全部关键字段。})return[{role:system,content:SYSTEM_PROMPT},{role:user,content:content},]defextract(payloads,model:strqwen2-vl-72b-instruct):respclient.**更多硬核网安与AI工具包请扫码获取完整源码**chat.completions.create(modelmodel,messagesbuild_messages(payloads),temperature0.0,response 一、背景与痛点为什么“纯文本 RAG”在企业文档面前会崩过去两年绝大多数企业级“文档问答”系统都建立在同一条脆弱的流水线上PDF → OCR/解析库 → 纯文本 → 切分 → 向量化 → LLM 回答这条链路在纯文字 PDF 上表现尚可但一旦面对真实业务文档——财务报表、招股书、医疗检验单、工程图纸、带批注的合同扫描件——它会在三个环节同时失效版面信息丢失。双栏排版被拉平成一行行乱序文本表格变成一堆用空格拼接的数字页眉页脚混入正文。你不光丢掉了“哪一列是 2023 年营收”还丢掉了“这是一个三线表”这个事实。2.OCR 误差累积。OCR 的字符错误率哪怕只有 2%在识别率最差的那 2% 里往往恰好是金额、编号、单位——也就是最不能错的部分。而误差一旦进入向量库就永久固化了。3.不可回答的问题类型。用户问“这份合同里第三页的签字盖章是否完整”“这张图表的趋势是上升还是下降”纯文本链路从设计上就答不了。这三类失败不是彼此独立的工程 bug而是同一个根因的不同表现传统 RAG 把文档当成“一维字符流”而真实文档的信息是“二维甚至三维”的。一个数字是“本期”还是“上期”取决于它所在的表头行一个条款是否生效取决于签署页有没有那枚红章一个金额属于哪一列取决于它在页面上的横向位置。切分器把二维语义压成一维字符串的那一刻这些关联就被永久切断了而且切分之后无法恢复——下游再强的 LLM 也猜不回它没看到的东西。更隐蔽的问题是嵌入模型对数字几乎“免疫”。12,345,678.90和12,345,679.80在向量空间里的余弦相似度通常在 0.99 以上检索时会被当成同一段内容。但在财务、医疗、法务场景里这 0.9 元的差异恰恰是全部意义所在。下面这张表可以更直观地说明问题边界文档类型纯文本 RAG 表现主要失效点多模态方案收益单栏纯文字 PDF良好几乎无明显问题低不值得走视觉双栏论文 / 财报中等阅读顺序错乱、跨栏串行高含合并单元格的表格差单元格错位、表头丢失极高扫描件 / 影印合同差OCR 误差叠加、无版面极高图表、流程图、工程图纸基本不可用信息本身非文本唯一可行方案发票、票据、表单差键值对关系断裂极高多模态大模型LMM改变了这条链路的根本假设不再需要把文档“翻译”成文本模型可以直接看页面。这不是精度上的小改进而是架构上的范式切换。二、核心原理多模态模型是怎么“看懂”一页 PDF 的2.1 三种融合范式范式代表特点双塔对比学习CLIP、SigLIP图文对齐强但无法做生成适合检索交叉注意力融合Flamingo、Qwen-VL 早期视觉特征以 cross-attention 注入 LLM参数效率高视觉 Token 化Early FusionGPT-4o、Qwen2-VL、InternVL图像 patch 直接投影成 token与文本 token 拼接进同一序列三种范式的差别值得展开一点因为它直接决定了你的技术选型双塔对比学习用 InfoNCE 损失把匹配的图文对拉近、不匹配的推远产物本质上是一个“相似度函数”。你可以拿 CLIP 做以图搜图、做页面级召回但它无法回答“这张发票的金额是多少”——它没有生成能力也没有细粒度理解能力。交叉注意力融合以 Flamingo 为代表冻结 LLM在层与层之间插入 gated cross-attention并用 Perceiver Resampler 把变长的视觉特征压成固定数量的 latent 向量通常 64 个。优点是视觉 token 数量恒定可控、训练成本低缺点是视觉信息经过多轮压缩后细节损失明显——对“读清 6 号字的一行数字”这种任务并不友好。视觉 Token 化是今天的绝对主流。图像 patch 过完 ViT 之后直接接一个 MLP或 Q-Former投影到词嵌入空间像文本 token 一样进入同一个 Transformer。它的最大好处是不确定性的来源变少了没有 OCR 中间层没有版面重建规则模型端到端地学“看到什么、答什么”。目前主流方案是第三种。它的核心组件只有两个视觉编码器通常是 ViT把图像切成固定大小的 patch如 14×14 或 16×16 像素每个 patch 编码成一个向量。投影层MLP 或 Q-Former把视觉向量映射到 LLM 的词嵌入空间使其与文本 token “同构”。于是模型看到的输入实际上是[img v1 v2 ... vN /img] 请提取这张发票的金额和税额这里有一个容易被忽略的认知要点img与/img之间的视觉 token 并不是“一张图的文本摘要”它们就是图像本身。不存在一层可读的中间表示作为退路一旦某个 patch 的投影出错信息就真丢了。这也解释了为什么分辨率与压缩策略会如此关键。补充一点工程上很关键的细节今天的 Qwen2-VL / Qwen2.5-VL 还引入了M-RoPE多模态旋转位置编码把一维位置编码拆成时间t、高度h、宽度w三个分量。这样模型才能天然理解“这个 token 在第 3 行第 5 列”而不是像早期方案那样把二维 patch 拉平成一维序列后彻底丢失空间关系。对表格、票据这类强结构化文档M-RoPE 带来的提升是决定性的。2.2 Token 成本多模态开发的第一性约束这里有个必须刻进肌肉记忆的公式视觉 Token 数≈H×Wpatch_size2\text{视觉 Token 数} \approx \frac{H \times W}{\text{patch\_size}^2}视觉Token数≈patch_size2H×W一张 1024×1024 的图用 14×14 的 patch就是5352 个 token。一页 200 DPI 渲染的 A4 扫描件约 1654×2339 像素不做任何处理就是约 20000 个 token。一本 100 页的年报光图像 token 就是 200 万——远超任何模型的上下文窗口账单也会非常难看。把不同渲染规格摊开看量级差异一目了然渲染规格分辨率约无压缩 token 数2×2 merging 后成本量级150 DPI A41240 × 1754≈ 11,100≈ 2,780中200 DPI A41654 × 2339≈ 19,700≈ 4,930高300 DPI A42480 × 3508≈ 44,400≈ 11,100极高1280×28×28 预算上限≈ 1,003,520 px——≈ 1,280低比计费更早出现问题的是显存。KV Cache 的大小与序列长度线性相关以 Qwen2-VL-7B28 层、4 个 KV head、head_dim 128、FP16为例每个 token 的 KV Cache 约 56 KB1000 个视觉 token 就是约 56 MB一页 200 DPI 扫描件约 2 万 token单项就要吃掉 1.1 GB 显存。8 路并发一上来显存直接爆掉——这不是调优问题是物理问题。所以现代模型都引入了动态分辨率 视觉 token 压缩Qwen2-VL 的 Naive Dynamic Resolution 允许任意分辨率输入并通过 2×2 patch merging 把 token 数降到 1/4实践中通常用max_pixels/min_pixels直接约束 token 预算例如max_pixels 1280 * 28 * 28 ≈ 1,003,520像素约对应 1280 个视觉 token。核心工程原则一页文档的视觉 token 预算应当控制在 1000~2000 之间超过这个量级的收益递减成本却线性上涨。反过来说如果你的抽取任务需要看清 6 号字正确做法不是把整页提到 300 DPI而是先定位、再裁剪、只对目标区域提分辨率。2.3 一个关键判断文本层可用就不要走视觉这是我见过最多团队踩的坑——盲目全量转视觉。实际上原生电子版 PDF的文本层是矢量信息100% 准确、零 token 成本对视觉而言扫描件才必须走视觉路径。还有一个常被忽略的中间态混排 PDF前几页是电子版封面后面是扫描的附件以及**“伪文本层”PDF**——某些 OCR 软件处理后会往 PDF 里塞一层哈希乱码文本字符数看着很足实际完全不可读直接喂给 LLM 只会污染上下文。正确做法是混合路由先探测文本层质量质量好的走文本通道成本低、精度高差的才降级到视觉通道。而且判断粒度必须是“页”而不是“文件”否则一份 200 页的年报里夹了 3 页扫描表格整本都会被拖进昂贵的视觉通道。三、实战构建智能文档分析助手3.1 整体架构┌─────────────┐ PDF/图片 ───────► │ 文档路由器 │ └──────┬──────┘ 文本层可用 │ 文本层缺失/低质 ┌──────┴──────┐ ▼ ▼ ┌─────────┐ ┌───────────┐ │ 文本通道 │ │ 视觉通道 │ │ 版面还原 │ │ 页面渲染 │ └────┬────┘ └─────┬─────┘ └──────┬───────┘ ▼ ┌───────────────┐ │ 多模态 LLM │ │ 结构化抽取 │ └───────┬───────┘ ▼ ┌───────────────┐ │ 向量库 BM25 │ │ 混合检索 │ └───────────────┘这条流水线里有三个必须明确的工程约定路由发生在页面级路由结果要落库页号 → 通道 → 哈希后续增量更新只重跑变化的页。抽取阶段与检索阶段解耦。抽取输出的是结构化字段带页码、bbox、置信度检索面向的是“字段 原文片段”两者共用同一套 ID 体系回答时才能精确回链。每一页都保留一份“原始视觉副本”缩放后的 PNG因为当抽取结果被人工质疑时唯一可信的证据永远是那页图而不是任何中间文本。3.2 代码示例一文档预处理与混合路由# pip install pymupdf pillow openaiimportbase64importiofromdataclassesimportdataclassimportfitz# PyMuPDFfromPILimportImage MAX_PIXELS1280*28*28# 约 1000 视觉 token 的像素预算RENDER_DPI200dataclassclassPagePayload:page_no:intkind:str# text | imagecontent:str# 文本内容 或 base64 图片def_downscale(img:Image.Image)-Image.Image:按 max_pixels 约束等比缩放避免视觉 token 爆炸。w,himg.sizeifw*hMAX_PIXELS:returnimg scale(MAX_PIXELS/(w*h))**0.5returnimg.resize((int(w*scale),int(h*scale)),Image.LANCZOS)def_text_layer_ok(page:fitz.Page,min_chars:int120)-bool:判断文本层是否可用字符够多且不是乱码。textpage.get_text(text).strip()iflen(text)min_chars:returnFalse# 粗略检测乱码可打印字符占比过低则视为扫描件printablesum(c.isprintable()andnotc.isspace()forcintext)returnprintable/max(len(text),1)0.85defparse_pdf(path:str,dpi:intRENDER_DPI)-list[PagePayload]:docfitz.open(path)payloads:list[PagePayload][]foridx,pageinenumerate(doc,start1):if_text_layer_ok(page):payloads.append(PagePayload(idx,text,page.get_text(text)))continue# 降级到视觉通道渲染成位图pixpage.get_pixmap(dpidpi,colorspacefitz.csRGB)imgImage.open(io.BytesIO(pix.tobytes(png)))img_downscale(img)bufio.BytesIO()img.save(buf,formatPNG,optimizeTrue)b64base64.b64encode(buf.getvalue()).decode()payloads.append(PagePayload(idx,image,b64))doc.close()returnpayloads这段代码有两个设计要点值得说明_text_layer_ok不仅判断字符数量还用可打印字符占比来识别“伪文本层”——不少扫描件经过某些 OCR 软件处理后会在 PDF 里留下一层哈希乱码文本字符数很足但完全不可读。_downscale是成本闸门。先缩放再编码而不是先编码再让模型端缩放可以省下大量上传带宽与预处理延迟。还有一处可以立刻改进的地方当前page.get_text(text)拿到的是阅读顺序未知的一维文本。在双栏文档上这个顺序经常是错的。更稳的写法是取带坐标的块自己按阅读顺序重排def_text_layer_ordered(page:fitz.Page)-str:按 (行, 列) 重排文本块缓解双栏文档的顺序错乱。blockspage.get_text(blocks)# (x0, y0, x1, y1, text, block_no, block_type)blocks[bforbinblocksifb[6]0andb[4].strip()]# 先按 y 粗聚类成行容差取字高的量级再按 x 排序blocks.sort(keylambdab:(round(b[1]/12),b[0]))return\n.join(b[4].strip()forbinblocks)对要求更高的场景可以先用垂直投影做列切分再把每一列当成独立文档排序效果比任何“智能重排提示词”都稳。3.3 代码示例二结构化抽取 引用溯源多模态抽取最怕模型“看着图编数字”。解决办法是强制 JSON Schema 输出并要求模型回填坐标把每一处结论锚定到页面区域。importjsonfromopenaiimportOpenAI clientOpenAI(base_urlhttps://api.your-gateway.com/v1)SCHEMA{type:object,properties:{doc_type:{type:string,enum:[invoice,contract,report,other]},fields:{type:array,items:{type:object,properties:{name:{type:string},value:{type:string},page:{type:integer},# 归一化坐标 [0,1]用于前端高亮溯源bbox:{type:array,items:{type:number},minItems:4,maxItems:4,},confidence:{type:number},},required:[name,value,page,bbox,confidence],additionalProperties:False,},},},required:[doc_type,fields],additionalProperties:False,}SYSTEM_PROMPT你是文档信息抽取专家。规则 1. 只抽取你能在页面中直接看到的字段禁止推断、补全或计算。 2. 每个字段必须给出其所在页面的归一化 bbox左上x, 左上y, 右下x, 右下y取值 0~1。 3. 无法定位坐标的字段一律不要输出。 4. confidence 表示你对该字段的把握低于 0.6 的请一并给出并在 value 中保留原始拼写。defbuild_messages(payloads):content[]forpinpayloads:ifp.kindtext:content.append({type:text,text:f【第{p.page_no}页 文本层】\n{p.content}})else:content.append({type:text,text:f【第{p.page_no}页 图像】})content.append({type:image_url,image_url:{url:fdata:image/png;base64,{p.content},detail:high},})content.append({type:text,text:请按 Schema 抽取全部关键字段。})return[{role:system,content:SYSTEM_PROMPT},{role:user,content:content},]defextract(payloads,model:strqwen2-vl-72b-instruct):respclient.**更多硬核网安与AI工具包请扫码获取完整源码**chat.completions.create(modelmodel,messagesbuild_messages(payloads),temperature0.0,response