1. 为什么我要把大模型搬到本地来处理文档先说结论如果你手头经常要处理几十上百页的PDF、Word、Excel又不想把合同、财报、内部资料往在线服务里传那本地部署大模型做文档处理是目前性价比最高的方案。我自己从去年开始陆续在几台机器上折腾这套东西踩过的坑比想象中多但跑通之后确实回不去了。所谓离线AI文档处理核心就三件事第一把大模型跑在你自己的机器上断网也能用第二把PDF、Word、Excel这些格式的内容准确提取出来喂给模型第三让模型完成校对、摘要、信息抽取、格式转换这些具体任务。听起来简单但每一环都有细节。这套方案适合谁我总结下来是三类人一是经常处理敏感文档的法务、财务、研究人员二是需要批量处理文档但又不想按量付费的开发者三是想学大模型落地、拿文档场景练手的技术爱好者。如果你只是想偶尔问几个问题在线服务更省事但一旦涉及批量、隐私、定制化本地部署的优势就出来了。我用的主力配置是一台带24G显存的机器跑7B到14B量级的模型很舒服再大就得量化或者上多卡。下面我把整套流程拆开讲包括模型选型、文档解析、任务编排、常见坑尽量给到能直接抄的参数和命令。2. 本地大模型部署方案怎么选2.1 三种主流部署方式的取舍本地跑大模型目前主流就三条路Ollama、vLLM、以及直接用transformers加载。我三个都用过场景不同选择不同。Ollama最大的好处是省心。一条命令拉模型自动处理量化、显存分配、API暴露适合快速验证和单机日常使用。缺点是并发能力弱批量处理时吞吐上不去。我平时做文档校对、单篇摘要就用它启动快改模型也快。vLLM是冲着吞吐去的。它做了PagedAttention显存利用率高并发请求下吞吐能比朴素加载高好几倍。如果你要批量处理几百个文档或者想搭个内部服务给团队用vLLM是正解。代价是配置麻烦一点对显卡和CUDA版本有要求。直接transformers加载最灵活能改模型结构、能自定义推理逻辑但显存管理和批处理都得自己写除非有特殊需求否则没必要。我的建议是先用Ollama跑通流程确认任务可行后如果量大了再迁到vLLM。别一上来就啃vLLM容易在环境上耗掉热情。2.2 模型选型不是越大越好热词里很多人问“ollama本地部署大模型哪个模型最佳”这问题没有标准答案得看你的任务和硬件。文档处理任务大致分几类校对纠错、摘要提炼、信息抽取、格式转换、问答检索。不同任务对模型能力要求不一样。校对和抽取更看重指令遵循和中文能力摘要看重长文本理解格式转换看重结构化输出能力。我实测下来7B量级的模型里Qwen系列中文表现稳指令遵循好适合校对和抽取14B量级能明显感觉到长文档理解更准摘要质量上一个台阶。如果你机器够14B是文档处理的甜点区。再往上32B、70B质量提升有但边际递减而且量化后速度掉得厉害。量化方面Q4_K_M是通用推荐质量和速度平衡好Q5_K_M质量更接近原版显存多花一点Q8_0基本无损但显存吃紧。我一般用Q4_K_M起步重要任务用Q5_K_M。提示模型选型别只看榜单分数一定要拿你自己的文档试。同一个模型在校对任务上可能很好在表格抽取上可能一塌糊涂任务匹配比参数重要。2.3 硬件与显存的实际账显存是硬约束。粗略估算7B模型Q4量化约需5-6G显存14B Q4约需9-10G32B Q4约需20G。这还没算上下文占用的KV Cache。上下文越长KV Cache越大。处理长PDF时上下文开到8K甚至16K显存会明显上涨。我的24G卡跑14B Q4加8K上下文很稳跑32B Q4就得把上下文压到4K长文档得分块。如果你只有8G显存7B Q4是上限长文档必须分块处理。CPU推理也能跑但速度慢到不适合批量。除非你只是偶尔用否则还是建议有张像样的显卡。内存方面模型加载和文档解析都吃内存16G是底线32G更从容。3. 文档解析PDF、Word、Excel各有各的坑3.1 PDF解析的三种路线PDF是最麻烦的格式因为它本质是排版文件不是结构化数据。解析路线有三条第一条是文本层直接提取用pdfplumber、PyMuPDF这类库。适合原生电子PDF速度快、保真度高。但遇到扫描件、图片型PDF就抓瞎。第二条是OCR识别用PaddleOCR、Tesseract这类工具。适合扫描件但识别有误差尤其是表格和公式。中文OCR里PaddleOCR表现不错表格结构还原也还行。第三条是版面分析加多模态用带视觉能力的大模型直接读图。这条路最贵但最省心适合复杂版面。不过本地跑多模态模型对显存要求高我一般只在关键文档上用。我的常规做法是先判断PDF有没有文本层有就直接提取没有就走OCR。判断方法很简单用PyMuPDF读第一页看能不能拿到文字。import fitz def has_text_layer(pdf_path, sample_pages3): doc fitz.open(pdf_path) for i in range(min(sample_pages, len(doc))): text doc[i].get_text().strip() if len(text) 50: return True return False这个判断很关键走错路线后面全白费。3.2 Word解析python-docx够用但不够好Word解析相对简单python-docx能拿到段落、表格、样式。但有几个坑一是批注和修订拿不到而校对场景恰恰需要这些二是复杂表格的合并单元格处理起来别扭三是公式基本拿不到OMML格式得单独解析。如果你要处理带公式的文档比如热词里提到的“公式图片转word”“mathtype嵌入word”那得用专门的方案。公式转文本目前没有完美方案我的做法是把公式区域截图交给多模态模型识别成LaTeX再转回Word。这条路准确率大概八成关键公式还得人工核对。批注和修订的话python-docx确实不行得直接解压docx看XML。docx本质是个zip里面word/comments.xml存批注word/document.xml里w:ins和w:del标记修订。解析XML能拿到但写起来费劲。我一般用python-docx处理正文批注单独解析XML。3.3 Excel解析openpyxl和pandas的分工Excel解析用openpyxl读结构和格式用pandas读数据。分工是这样的如果你要保留格式、公式、多sheet结构用openpyxl如果只是要数据做分析pandas更快。坑主要在合并单元格和公式。openpyxl读合并单元格时只有左上角有值其他是None得自己填充。公式的话openpyxl默认读公式字符串要读计算值得设data_onlyTrue但前提是文件被Excel打开保存过否则缓存值是None。import openpyxl wb openpyxl.load_workbook(data.xlsx, data_onlyTrue) ws wb.active # 处理合并单元格 for merged_range in ws.merged_cells.ranges: top_left ws.cell(merged_range.min_row, merged_range.min_col).value for row in range(merged_range.min_row, merged_range.max_row 1): for col in range(merged_range.min_col, merged_range.max_col 1): ws.cell(row, col).value top_left这段填充逻辑我用了很多次处理报表时特别有用。4. 把文档喂给模型的完整实操流程4.1 整体架构解析、分块、推理、回写整套流程我拆成四步解析把文档转成纯文本或结构化数据分块把长文本切成模型能处理的片段推理让模型完成具体任务回写把结果写回文档或输出成新格式。这四步里分块最容易被忽视但最影响效果。切得不好上下文断裂模型理解就错。我的分块策略是按语义切不按字数硬切。段落优先段落太长再按句子切句子还长才按字数切。块之间留10%到20%的重叠避免边界信息丢失。def semantic_chunk(text, max_len1500, overlap200): paragraphs text.split(\n\n) chunks [] current for para in paragraphs: if len(current) len(para) max_len: current para \n\n else: if current: chunks.append(current.strip()) current para \n\n if current: chunks.append(current.strip()) # 加重叠 overlapped [] for i, chunk in enumerate(chunks): if i 0: chunk chunks[i-1][-overlap:] chunk overlapped.append(chunk) return overlapped这个函数不完美但比硬切好很多。实际用的时候我会根据文档类型调max_len技术文档段落长max_len设大点对话记录段落短设小点。4.2 校对任务的提示词设计文档校对是本地AI最实用的场景之一。热词里“使用本地部署ai离线校对文档”就是这个需求。校对任务的提示词设计有几个要点第一明确任务边界。别只说“校对”要说清楚校什么错别字、语法、标点、术语一致性、格式规范。任务越具体模型表现越好。第二给示例。few-shot对校对任务提升明显。给两三个改前改后的例子模型就知道你要什么风格。第三要求结构化输出。让模型输出JSON包含原文、修改后、修改理由方便后续处理。我常用的校对提示词模板你是专业文档校对员。请检查以下文本的错别字、语法错误、标点误用和术语不一致。 对每处问题输出JSON格式{original: 原文, corrected: 修改后, reason: 理由} 只输出JSON数组不要其他内容。 示例 输入这个方案的实施需要多个部门协同配合缺一不可。 输出[] 输入我们因该在周五前完成报告。 输出[{original: 因该, corrected: 应该, reason: 错别字}] 待校对文本 {text}这个模板我用了几个月稳定性不错。注意示例里给一个空输出能减少模型强行找错的情况。4.3 信息抽取从合同和报表里捞数据信息抽取是另一个高频场景。比如从合同里抽甲方乙方、金额、期限从报表里抽关键指标。这类任务的关键是schema定义要清晰。我一般先定义好要抽的字段和类型写成JSON schema然后让模型按schema输出。这样输出可控后续能直接入库。extract_prompt 从以下合同文本中抽取信息按JSON输出 { party_a: 甲方名称, party_b: 乙方名称, amount: 合同金额数字, sign_date: 签订日期YYYY-MM-DD, duration: 合同期限 } 找不到的字段填null。 合同文本 {text} 实测下来7B模型在字段少、格式规整的抽取任务上准确率能到九成字段一多或者文本一乱就掉。14B明显稳。如果抽取字段特别多建议拆成多个任务一次抽三五个字段别贪多。4.4 格式转换Markdown转Word的工作流热词里“markdown转word工作流”是个真实需求。模型输出通常是Markdown要转成Word得走一道转换。我用的方案是pandoc加模板。pandoc input.md -o output.docx --reference-doctemplate.docxreference-doc指定样式模板这样转出来的Word字体、标题样式都符合要求。模板可以先用Word做好存成docxpandoc会读取里面的样式。如果模型输出的是带公式的Markdownpandoc对LaTeX公式支持还行转Word时公式会变成OMML能在Word里编辑。但复杂公式转换会出错关键公式还是得人工核对。表格转换是另一个坑。Markdown表格转Word后列宽经常不对热词里“word表格列宽无法拖动”可能就跟这有关。我的做法是转换后用python-docx再调一遍列宽。from docx import Document doc Document(output.docx) for table in doc.tables: for row in table.rows: for cell in row.cells: cell.width None # 清除固定宽度让Word自动调整 doc.save(output.docx)把cell.width设成NoneWord会按内容自动调整比硬设宽度灵活。5. 常见问题与排查技巧实录5.1 模型输出不稳定怎么办最常见的问题是模型输出格式飘一会儿JSON一会儿自然语言。解决办法有三个一是降低temperature校对和抽取任务设0.1到0.3别用默认的0.7二是加格式约束在提示词里明确“只输出JSON不要解释”三是后处理兜底用正则从输出里抠JSON抠不到就重试。我一般三个一起上。temperature设0.2提示词强调格式代码里加正则提取和重试。重试最多三次三次还不行就标记人工处理。5.2 长文档处理超上下文怎么办长PDF动辄几十页超上下文是常态。两条路分块处理再合并或者用RAG检索相关片段。分块处理适合校对、摘要这类可以分段做的任务。每块独立处理结果按顺序拼起来。注意块之间要有重叠避免边界问题被漏掉。RAG适合问答类任务。把文档切块存进向量库用户提问时检索最相关的几块喂给模型。本地向量库我用Chroma轻量好用。embedding模型用bge-small-zh中文效果好速度快。import chromadb from sentence_transformers import SentenceTransformer client chromadb.PersistentClient(path./db) collection client.get_or_create_collection(docs) model SentenceTransformer(BAAI/bge-small-zh-v1.5) def add_docs(chunks): embeddings model.encode(chunks).tolist() collection.add( embeddingsembeddings, documentschunks, ids[fid_{i} for i in range(len(chunks))] ) def search(query, top_k3): q_emb model.encode([query]).tolist() results collection.query(query_embeddingsq_emb, n_resultstop_k) return results[documents][0]这套组合我在几个项目里用过检索准确率够用搭建也快。5.3 显存不够的几种救急方案显存不够是本地部署的永恒话题。几个救急方案按优先级排第一换更小的量化。Q4换Q3或者换更小的模型。质量会掉但能跑起来。第二缩短上下文。上下文从8K压到4KKV Cache能省不少。代价是长文档得分更多块。第三CPU卸载部分层。Ollama和llama.cpp都支持把部分层放CPU显存不够时能救急但速度会明显下降。第四用vLLM的显存优化。vLLM的PagedAttention能提高显存利用率同样的卡能跑更大的模型或更长的上下文。我一般按这个顺序试实在不行才考虑升级硬件。5.4 常见问题速查表问题现象可能原因排查方向解决建议模型输出格式乱temperature过高检查推理参数降到0.1-0.3加格式约束长文档处理报错超上下文看报错信息分块或上RAG显存溢出模型太大或上下文太长看显存占用换小量化、缩上下文、CPU卸载PDF提取乱码编码或字体问题检查文本层换解析库或走OCR表格抽取错位合并单元格未处理检查表格结构先填充合并单元格公式转换失败格式不支持看转换日志截图走多模态识别推理速度慢模型大或硬件弱测token/s换小模型或量化批处理吞吐低单请求串行看并发配置迁到vLLM这张表是我踩坑踩出来的遇到问题先对一遍能省不少时间。注意排查时先确认是解析问题还是模型问题。很多人一上来就调模型结果发现是PDF根本没提取出文字。先验证输入再怀疑模型。6. 我踩过的几个真实坑和独家心得第一个坑是PDF文本层判断失误。有次处理一批扫描件我偷懒没判断直接走文本提取结果提取出一堆空白模型对着空白输出了一堆废话。后来我强制加判断没文本层直接走OCR问题解决。这个判断逻辑现在是我所有PDF处理流程的第一步。第二个坑是分块重叠给太多。一开始我怕丢信息重叠给了50%结果同一段内容被处理多次校对结果里重复修改。后来把重叠降到15%到20%效果好很多。重叠不是越多越好够用就行。第三个坑是提示词里的示例太完美。我一开始给的校对示例都是明显错别字模型就只找明显错误漏掉语法和标点问题。后来示例里混入语法错误和标点误用模型才全面起来。示例要覆盖你想要的各类问题别只给一种。第四个坑是忽略文档编码。处理一批老Word文档时中文全是乱码查了半天发现是GBK编码。python-docx默认按UTF-8读遇到GBK就崩。后来加了编码检测和转换问题解决。def read_text_safe(path): for enc in [utf-8, gbk, gb18030, latin-1]: try: with open(path, r, encodingenc) as f: return f.read() except UnicodeDecodeError: continue raise ValueError(无法识别编码)这个函数现在是我读文本文件的标准入口省心。第五个坑是模型选型只看中文能力。有次选了个中文榜单很高的模型做表格抽取结果它对结构化输出支持很差JSON老是格式错。后来换了个指令遵循更好的模型虽然中文榜单分数低一点但抽取任务准确率高很多。任务匹配比榜单重要这话我说多少遍都不嫌多。最后分享一个提效技巧把常用任务封装成脚本。校对、抽取、摘要这几个任务我各写了一个脚本输入文档路径和任务类型自动走完解析、分块、推理、回写全流程。日常用起来就是一条命令的事比每次手动调省太多时间。python doc_ai.py --input report.pdf --task proofread --model qwen2.5:14b --output result.docx这套脚本我迭代了十几版现在处理一份几十页的文档从解析到出结果大概几分钟比人工快太多而且断网也能跑敏感文档也不担心外传。如果你也经常跟文档打交道强烈建议把这套流程搭起来一次投入长期受益。 
长河君 · 2026/9/20 23:34:14 · 阅读 1.2k 本地部署大模型做离线AI文档处理：从选型到实操的完整指南
1. 为什么我要把大模型搬到本地来处理文档先说结论如果你手头经常要处理几十上百页的PDF、Word、Excel又不想把合同、财报、内部资料往在线服务里传那本地部署大模型做文档处理是目前性价比最高的方案。我自己从去年开始陆续在几台机器上折腾这套东西踩过的坑比想象中多但跑通之后确实回不去了。所谓离线AI文档处理核心就三件事第一把大模型跑在你自己的机器上断网也能用第二把PDF、Word、Excel这些格式的内容准确提取出来喂给模型第三让模型完成校对、摘要、信息抽取、格式转换这些具体任务。听起来简单但每一环都有细节。这套方案适合谁我总结下来是三类人一是经常处理敏感文档的法务、财务、研究人员二是需要批量处理文档但又不想按量付费的开发者三是想学大模型落地、拿文档场景练手的技术爱好者。如果你只是想偶尔问几个问题在线服务更省事但一旦涉及批量、隐私、定制化本地部署的优势就出来了。我用的主力配置是一台带24G显存的机器跑7B到14B量级的模型很舒服再大就得量化或者上多卡。下面我把整套流程拆开讲包括模型选型、文档解析、任务编排、常见坑尽量给到能直接抄的参数和命令。2. 本地大模型部署方案怎么选2.1 三种主流部署方式的取舍本地跑大模型目前主流就三条路Ollama、vLLM、以及直接用transformers加载。我三个都用过场景不同选择不同。Ollama最大的好处是省心。一条命令拉模型自动处理量化、显存分配、API暴露适合快速验证和单机日常使用。缺点是并发能力弱批量处理时吞吐上不去。我平时做文档校对、单篇摘要就用它启动快改模型也快。vLLM是冲着吞吐去的。它做了PagedAttention显存利用率高并发请求下吞吐能比朴素加载高好几倍。如果你要批量处理几百个文档或者想搭个内部服务给团队用vLLM是正解。代价是配置麻烦一点对显卡和CUDA版本有要求。直接transformers加载最灵活能改模型结构、能自定义推理逻辑但显存管理和批处理都得自己写除非有特殊需求否则没必要。我的建议是先用Ollama跑通流程确认任务可行后如果量大了再迁到vLLM。别一上来就啃vLLM容易在环境上耗掉热情。2.2 模型选型不是越大越好热词里很多人问“ollama本地部署大模型哪个模型最佳”这问题没有标准答案得看你的任务和硬件。文档处理任务大致分几类校对纠错、摘要提炼、信息抽取、格式转换、问答检索。不同任务对模型能力要求不一样。校对和抽取更看重指令遵循和中文能力摘要看重长文本理解格式转换看重结构化输出能力。我实测下来7B量级的模型里Qwen系列中文表现稳指令遵循好适合校对和抽取14B量级能明显感觉到长文档理解更准摘要质量上一个台阶。如果你机器够14B是文档处理的甜点区。再往上32B、70B质量提升有但边际递减而且量化后速度掉得厉害。量化方面Q4_K_M是通用推荐质量和速度平衡好Q5_K_M质量更接近原版显存多花一点Q8_0基本无损但显存吃紧。我一般用Q4_K_M起步重要任务用Q5_K_M。提示模型选型别只看榜单分数一定要拿你自己的文档试。同一个模型在校对任务上可能很好在表格抽取上可能一塌糊涂任务匹配比参数重要。2.3 硬件与显存的实际账显存是硬约束。粗略估算7B模型Q4量化约需5-6G显存14B Q4约需9-10G32B Q4约需20G。这还没算上下文占用的KV Cache。上下文越长KV Cache越大。处理长PDF时上下文开到8K甚至16K显存会明显上涨。我的24G卡跑14B Q4加8K上下文很稳跑32B Q4就得把上下文压到4K长文档得分块。如果你只有8G显存7B Q4是上限长文档必须分块处理。CPU推理也能跑但速度慢到不适合批量。除非你只是偶尔用否则还是建议有张像样的显卡。内存方面模型加载和文档解析都吃内存16G是底线32G更从容。3. 文档解析PDF、Word、Excel各有各的坑3.1 PDF解析的三种路线PDF是最麻烦的格式因为它本质是排版文件不是结构化数据。解析路线有三条第一条是文本层直接提取用pdfplumber、PyMuPDF这类库。适合原生电子PDF速度快、保真度高。但遇到扫描件、图片型PDF就抓瞎。第二条是OCR识别用PaddleOCR、Tesseract这类工具。适合扫描件但识别有误差尤其是表格和公式。中文OCR里PaddleOCR表现不错表格结构还原也还行。第三条是版面分析加多模态用带视觉能力的大模型直接读图。这条路最贵但最省心适合复杂版面。不过本地跑多模态模型对显存要求高我一般只在关键文档上用。我的常规做法是先判断PDF有没有文本层有就直接提取没有就走OCR。判断方法很简单用PyMuPDF读第一页看能不能拿到文字。import fitz def has_text_layer(pdf_path, sample_pages3): doc fitz.open(pdf_path) for i in range(min(sample_pages, len(doc))): text doc[i].get_text().strip() if len(text) 50: return True return False这个判断很关键走错路线后面全白费。3.2 Word解析python-docx够用但不够好Word解析相对简单python-docx能拿到段落、表格、样式。但有几个坑一是批注和修订拿不到而校对场景恰恰需要这些二是复杂表格的合并单元格处理起来别扭三是公式基本拿不到OMML格式得单独解析。如果你要处理带公式的文档比如热词里提到的“公式图片转word”“mathtype嵌入word”那得用专门的方案。公式转文本目前没有完美方案我的做法是把公式区域截图交给多模态模型识别成LaTeX再转回Word。这条路准确率大概八成关键公式还得人工核对。批注和修订的话python-docx确实不行得直接解压docx看XML。docx本质是个zip里面word/comments.xml存批注word/document.xml里w:ins和w:del标记修订。解析XML能拿到但写起来费劲。我一般用python-docx处理正文批注单独解析XML。3.3 Excel解析openpyxl和pandas的分工Excel解析用openpyxl读结构和格式用pandas读数据。分工是这样的如果你要保留格式、公式、多sheet结构用openpyxl如果只是要数据做分析pandas更快。坑主要在合并单元格和公式。openpyxl读合并单元格时只有左上角有值其他是None得自己填充。公式的话openpyxl默认读公式字符串要读计算值得设data_onlyTrue但前提是文件被Excel打开保存过否则缓存值是None。import openpyxl wb openpyxl.load_workbook(data.xlsx, data_onlyTrue) ws wb.active # 处理合并单元格 for merged_range in ws.merged_cells.ranges: top_left ws.cell(merged_range.min_row, merged_range.min_col).value for row in range(merged_range.min_row, merged_range.max_row 1): for col in range(merged_range.min_col, merged_range.max_col 1): ws.cell(row, col).value top_left这段填充逻辑我用了很多次处理报表时特别有用。4. 把文档喂给模型的完整实操流程4.1 整体架构解析、分块、推理、回写整套流程我拆成四步解析把文档转成纯文本或结构化数据分块把长文本切成模型能处理的片段推理让模型完成具体任务回写把结果写回文档或输出成新格式。这四步里分块最容易被忽视但最影响效果。切得不好上下文断裂模型理解就错。我的分块策略是按语义切不按字数硬切。段落优先段落太长再按句子切句子还长才按字数切。块之间留10%到20%的重叠避免边界信息丢失。def semantic_chunk(text, max_len1500, overlap200): paragraphs text.split(\n\n) chunks [] current for para in paragraphs: if len(current) len(para) max_len: current para \n\n else: if current: chunks.append(current.strip()) current para \n\n if current: chunks.append(current.strip()) # 加重叠 overlapped [] for i, chunk in enumerate(chunks): if i 0: chunk chunks[i-1][-overlap:] chunk overlapped.append(chunk) return overlapped这个函数不完美但比硬切好很多。实际用的时候我会根据文档类型调max_len技术文档段落长max_len设大点对话记录段落短设小点。4.2 校对任务的提示词设计文档校对是本地AI最实用的场景之一。热词里“使用本地部署ai离线校对文档”就是这个需求。校对任务的提示词设计有几个要点第一明确任务边界。别只说“校对”要说清楚校什么错别字、语法、标点、术语一致性、格式规范。任务越具体模型表现越好。第二给示例。few-shot对校对任务提升明显。给两三个改前改后的例子模型就知道你要什么风格。第三要求结构化输出。让模型输出JSON包含原文、修改后、修改理由方便后续处理。我常用的校对提示词模板你是专业文档校对员。请检查以下文本的错别字、语法错误、标点误用和术语不一致。 对每处问题输出JSON格式{original: 原文, corrected: 修改后, reason: 理由} 只输出JSON数组不要其他内容。 示例 输入这个方案的实施需要多个部门协同配合缺一不可。 输出[] 输入我们因该在周五前完成报告。 输出[{original: 因该, corrected: 应该, reason: 错别字}] 待校对文本 {text}这个模板我用了几个月稳定性不错。注意示例里给一个空输出能减少模型强行找错的情况。4.3 信息抽取从合同和报表里捞数据信息抽取是另一个高频场景。比如从合同里抽甲方乙方、金额、期限从报表里抽关键指标。这类任务的关键是schema定义要清晰。我一般先定义好要抽的字段和类型写成JSON schema然后让模型按schema输出。这样输出可控后续能直接入库。extract_prompt 从以下合同文本中抽取信息按JSON输出 { party_a: 甲方名称, party_b: 乙方名称, amount: 合同金额数字, sign_date: 签订日期YYYY-MM-DD, duration: 合同期限 } 找不到的字段填null。 合同文本 {text} 实测下来7B模型在字段少、格式规整的抽取任务上准确率能到九成字段一多或者文本一乱就掉。14B明显稳。如果抽取字段特别多建议拆成多个任务一次抽三五个字段别贪多。4.4 格式转换Markdown转Word的工作流热词里“markdown转word工作流”是个真实需求。模型输出通常是Markdown要转成Word得走一道转换。我用的方案是pandoc加模板。pandoc input.md -o output.docx --reference-doctemplate.docxreference-doc指定样式模板这样转出来的Word字体、标题样式都符合要求。模板可以先用Word做好存成docxpandoc会读取里面的样式。如果模型输出的是带公式的Markdownpandoc对LaTeX公式支持还行转Word时公式会变成OMML能在Word里编辑。但复杂公式转换会出错关键公式还是得人工核对。表格转换是另一个坑。Markdown表格转Word后列宽经常不对热词里“word表格列宽无法拖动”可能就跟这有关。我的做法是转换后用python-docx再调一遍列宽。from docx import Document doc Document(output.docx) for table in doc.tables: for row in table.rows: for cell in row.cells: cell.width None # 清除固定宽度让Word自动调整 doc.save(output.docx)把cell.width设成NoneWord会按内容自动调整比硬设宽度灵活。5. 常见问题与排查技巧实录5.1 模型输出不稳定怎么办最常见的问题是模型输出格式飘一会儿JSON一会儿自然语言。解决办法有三个一是降低temperature校对和抽取任务设0.1到0.3别用默认的0.7二是加格式约束在提示词里明确“只输出JSON不要解释”三是后处理兜底用正则从输出里抠JSON抠不到就重试。我一般三个一起上。temperature设0.2提示词强调格式代码里加正则提取和重试。重试最多三次三次还不行就标记人工处理。5.2 长文档处理超上下文怎么办长PDF动辄几十页超上下文是常态。两条路分块处理再合并或者用RAG检索相关片段。分块处理适合校对、摘要这类可以分段做的任务。每块独立处理结果按顺序拼起来。注意块之间要有重叠避免边界问题被漏掉。RAG适合问答类任务。把文档切块存进向量库用户提问时检索最相关的几块喂给模型。本地向量库我用Chroma轻量好用。embedding模型用bge-small-zh中文效果好速度快。import chromadb from sentence_transformers import SentenceTransformer client chromadb.PersistentClient(path./db) collection client.get_or_create_collection(docs) model SentenceTransformer(BAAI/bge-small-zh-v1.5) def add_docs(chunks): embeddings model.encode(chunks).tolist() collection.add( embeddingsembeddings, documentschunks, ids[fid_{i} for i in range(len(chunks))] ) def search(query, top_k3): q_emb model.encode([query]).tolist() results collection.query(query_embeddingsq_emb, n_resultstop_k) return results[documents][0]这套组合我在几个项目里用过检索准确率够用搭建也快。5.3 显存不够的几种救急方案显存不够是本地部署的永恒话题。几个救急方案按优先级排第一换更小的量化。Q4换Q3或者换更小的模型。质量会掉但能跑起来。第二缩短上下文。上下文从8K压到4KKV Cache能省不少。代价是长文档得分更多块。第三CPU卸载部分层。Ollama和llama.cpp都支持把部分层放CPU显存不够时能救急但速度会明显下降。第四用vLLM的显存优化。vLLM的PagedAttention能提高显存利用率同样的卡能跑更大的模型或更长的上下文。我一般按这个顺序试实在不行才考虑升级硬件。5.4 常见问题速查表问题现象可能原因排查方向解决建议模型输出格式乱temperature过高检查推理参数降到0.1-0.3加格式约束长文档处理报错超上下文看报错信息分块或上RAG显存溢出模型太大或上下文太长看显存占用换小量化、缩上下文、CPU卸载PDF提取乱码编码或字体问题检查文本层换解析库或走OCR表格抽取错位合并单元格未处理检查表格结构先填充合并单元格公式转换失败格式不支持看转换日志截图走多模态识别推理速度慢模型大或硬件弱测token/s换小模型或量化批处理吞吐低单请求串行看并发配置迁到vLLM这张表是我踩坑踩出来的遇到问题先对一遍能省不少时间。注意排查时先确认是解析问题还是模型问题。很多人一上来就调模型结果发现是PDF根本没提取出文字。先验证输入再怀疑模型。6. 我踩过的几个真实坑和独家心得第一个坑是PDF文本层判断失误。有次处理一批扫描件我偷懒没判断直接走文本提取结果提取出一堆空白模型对着空白输出了一堆废话。后来我强制加判断没文本层直接走OCR问题解决。这个判断逻辑现在是我所有PDF处理流程的第一步。第二个坑是分块重叠给太多。一开始我怕丢信息重叠给了50%结果同一段内容被处理多次校对结果里重复修改。后来把重叠降到15%到20%效果好很多。重叠不是越多越好够用就行。第三个坑是提示词里的示例太完美。我一开始给的校对示例都是明显错别字模型就只找明显错误漏掉语法和标点问题。后来示例里混入语法错误和标点误用模型才全面起来。示例要覆盖你想要的各类问题别只给一种。第四个坑是忽略文档编码。处理一批老Word文档时中文全是乱码查了半天发现是GBK编码。python-docx默认按UTF-8读遇到GBK就崩。后来加了编码检测和转换问题解决。def read_text_safe(path): for enc in [utf-8, gbk, gb18030, latin-1]: try: with open(path, r, encodingenc) as f: return f.read() except UnicodeDecodeError: continue raise ValueError(无法识别编码)这个函数现在是我读文本文件的标准入口省心。第五个坑是模型选型只看中文能力。有次选了个中文榜单很高的模型做表格抽取结果它对结构化输出支持很差JSON老是格式错。后来换了个指令遵循更好的模型虽然中文榜单分数低一点但抽取任务准确率高很多。任务匹配比榜单重要这话我说多少遍都不嫌多。最后分享一个提效技巧把常用任务封装成脚本。校对、抽取、摘要这几个任务我各写了一个脚本输入文档路径和任务类型自动走完解析、分块、推理、回写全流程。日常用起来就是一条命令的事比每次手动调省太多时间。python doc_ai.py --input report.pdf --task proofread --model qwen2.5:14b --output result.docx这套脚本我迭代了十几版现在处理一份几十页的文档从解析到出结果大概几分钟比人工快太多而且断网也能跑敏感文档也不担心外传。如果你也经常跟文档打交道强烈建议把这套流程搭起来一次投入长期受益。