长文本塞不进本地模型把预处理和任务调度当成工程问题来解最近一直在折腾本地智能体的落地其中一个让我翻了多次车的问题就是长文本超限。本地部署的大模型上下文窗口固定摆在那里而办公文档动不动就几十页、上百万字直接塞进去必然爆掉。即使硬塞进去模型的表现也会急剧退化回答得前言不搭后语。折腾一段时候之后我总结出一条经验长文本超限不是靠换更大模型解决的而是靠文档预处理和任务调度把它当作一条流水线来治理。所谓本地智能体本质上是把大模型部署在自己可控的环境中配合一套自动化流程让它能处理实际办公场景里的任务。而“实际办公场景”这个词翻译过来就是格式乱七八糟的 Word、扫描版 PDF、多级目录的 Excel、还有动不动几十页的合同和报告。如果不管这些文档的原始状态直接丢给模型那模型输出的质量就没法看。这篇文章不聊概念直接把我的完整链路拆开讲讲每一步为什么这么做以及踩过的那些坑。整套方案的核心思路只有一句话在一开始就把文档处理干净、切成合适的块再用调度机制把“预处理”和“大模型调用”串成一条自动流转的流水线。至于适合谁来看——如果你正在搭本地智能体或者在做 RAG 检索增强生成被“文本太长”“模型总答错”“流程串不起来”这些问题困扰那这篇内容应该能帮你省下不少试错的时间。1. 长文本超限的根源在哪本地模型的上下文瓶颈先说一个比较反直觉的结论上下文窗口只是长文本问题的表象真正的瓶颈在于你把所有内容都堆进了同一个对话里。哪怕你用的是 128K 上下文窗口的模型一份 200 页的技术文档塞进去之后模型照样会“迷失在中间地带”——开头和结尾的内容它记得准靠中间的部分就被稀释掉了。这不是模型不够聪明而是注意力机制天然对超长输入存在性能衰减。1.1 本地部署为什么更受限制云端的商业模型可以把单次请求的上下文拉得很长但这背后是巨量的显存和计算资源支撑。本地智能体面对的硬件约束是实打实的一张消费级显卡的显存就那么大加载模型之后剩余空间严重制约了能处理的文本长度。我的实测数据如下模型规模显存占用推理时常规可用上下文适合处理的单文档大小7B 量化版6-8 GB8K-16K不超过 1 万字14B 量化版12-16 GB16K-32K不超过 2 万字32B 量化版24-32 GB32K-64K不超过 4 万字表格里的数据是个大前提一旦超过这个范围轻则提示超限重则输出乱码。有人会说那我干脆把模型跑在云端不就行了这就失去了本地智能体的意义——本地部署要的就是数据不出内网、可控、可定制。代价就是你必须在文档进入模型之前把它压缩、切割、提炼到模型处理能力的舒适区里。1.2 长文本超限的三个典型表现在办公场景里长文本超限往往不是一次报错就能看出来的它通常有三种表现形态直接报错调用接口时提示“输入长度超过最大限制”这是最仁慈的失败方式因为至少你知道出了问题。后台截断模型只处理了你传入内容的前半部分后面的直接丢了。你问的问题恰好要依赖后半段的内容它就开始一本正经地胡说八道。这种失败特别坑因为返回结果看起来完全正常你很难意识到是截断导致的错误回答。性能崩塌文本长度没有超过硬限制但已经超过了模型的有效处理区间回答开始答非所问。比如你问“合同第三条说了什么”它能给你扯到合同第五条去。这三种表现说明同一个道理预处理不是可选项而是一道必需工序。你把多少内容交给模型模型就背负多大的认知负担而我们的目标就是让交给模型的每一段内容都精准、独立、信息密度足够高。2. 文档预处理三层拆解格式解析、清洗与分块策略预处理这个词听起来很笼统实际拆开就是三个动作把各种格式的文档解析成纯文本把文本里的噪音清理干净把干净的文本切成模型能处理、检索能命中、语义能连贯的块。这三步环环相扣少了任何一环后面的 RAG 或者任务执行效果都会大打折扣。2.1 第一层格式解析把 PDF、Word、Excel 变成干净文本这一层的目标很明确把电脑里的文档变成模型认识的语言。办公文档的格式五花八门但常见的无非 PDF、Word、Excel、PPT 这几类。以 Python 生态为例我现在的技术栈是这样的# 文档解析核心依赖 # - pdfplumber / pymupdf处理 PDF前者擅长表格提取后者速度快 # - python-docx处理 Word # - openpyxl / pandas处理 Excel # - python-pptx处理 PPT import fitz # PyMuPDF实测解析速度比 pdfplumber 快不少 def parse_pdf(file_path: str) - str: doc fitz.open(file_path) pages_text [] for page in doc: pages_text.append(page.get_text(text)) return \n.join(pages_text)这里有一个关键的教训不要只盯着文本提取还要保留文档的结构信息。一开始我做解析只保留了纯文本后来发现检索阶段根本没办法区分“这是标题”还是“这是正文”。后来我在预处理阶段额外记录了每个块对应的页码、章节标题、文档来源等信息这些结构信息在后面做检索、回答引用来源时作用非常巨大。模型看的是文本但调度系统需要知道这些文本“从哪里来”。2.2 第二层噪音清洗文档里那些“不能说”的话解析出来的文字远比你想象的要脏。我梳理一下常见的污染源污染类型典型示例处理方案页眉页脚公司名称、页码、日期重复出现按位置过滤删除每页首尾固定内容水印与扫描噪声“内部资料”、OCR 产生的乱码字正则匹配删除或按出现频率过滤目录与索引文档开头的“第一章…第二章…”导航根据“目录”关键词识别区间整体删除表格混乱字符单元格数据被拼接到一起没有分隔符重新按行格式化表格文本字符异常全角半角混用、多余空格、断行符统一做归一化处理清洗这一步有个原则宁可多删不可留错。你留一段没用的页眉在文本里检索阶段它就可能被当成有效内容捞出来导致答案里都是无关信息。举个例子一份 50 页的技术合同每页顶部都有公司名称和合同编号清洗前解析出来这些字段会重复出现 50 次。不做清洗的话用向量检索问题时这些重复字段对应的文本块会被高频命中直接污染检索结果。2.3 第三层分块策略不是简单按字数切分块是长文本预处理中最核心、也最需要花心思考虑细节的一步。很多资料只会告诉你“按固定 token 数切”这个说法实际应用起来远不够。文本不是铁板一块按固定长度硬切会把语义完整的一句话、一个代码块、一个表格劈成两半检索时两头都不像回答自然就废了。我的实践建议是分层处理按文档结构分优先按章节标题来切块。Word 或 PDF 自带标题层级时用标题作为切分边界是最稳的。每个章节的内容天然有主题一致性。按段落和语义分对于没有明确标题的文档按段落切块段落太长时再根据句号、问号、感叹号等句子边界做二次切分保证每个块里的内容在语义上是连贯的。按固定 token 数兜底当文本完全没有语义边界可依时才回退到固定长度切分并设置重叠区间避免切断关键语义。分块策略直接决定了后续任务调度的效率和 RAG 检索的准确率。我见过有人搞了几十万字的知识库分块参数随手一填最后模型回答的引用来源非常混乱指向完全不相关的文档章节。这种问题往往不是模型的问题而是预处理这一层的分块逻辑没做好。3. 分块参数调优的真实经验块大小、重叠率和元数据管理这块内容我会写细一点因为这是整个链路里被讨论得最少、但实际影响最大的部分。你以为分块就是把一个长文本切成几段但实际操作时块大小的选择、重叠区间的设置、以及每个块的元数据管理都需要根据模型的用途反复调整。3.1 块大小怎么定锚定模型上下文和检索精度第一个要决定的参数是块大小。块太小语义信息不完整检索时命中的内容过于零散块太大一个块里塞了好几个主题检索时虽然命中了但不精准。我的经验公式是这样块大小设定为模型上下文窗口的三分之一到五分之一。如果模型上下文是 8K token单块控制在 1500-2000 token 左右。如果模型上下文是 32K token单块可以放到 4000-5000 token。这个比例的底层逻辑很简单一个块被检索出来之后还要拼接上用户的问题和系统提示词如果单块占的比例太大留给问题和其他上下文的余地就小了。另外如果单块超长模型处理时中间部分的内容也容易被稀释。块越小单次检索时加入的内容越精准但也要注意别切得太碎否则语义断裂问题会更严重。3.2 重叠率被切成两半的那块内容靠它兜底紧挨着的两个块之间设置一个重叠区域确保跨边界的重要信息不会遗漏。常用的设置是 10%-15% 的重叠。举个例子如果块大小是 1500 token重叠区间可以设成 150-200 token。这样前一个块的后半部分内容和后一个块的前半部分内容有交叉检索时无论关键信息落在哪个位置都能至少完整地落到某一个块里。我调试一个检索召回率的问题时发现把重叠率从 0 改成 10% 之后回答的准确率提升很明显。当时的问题背景是同一段技术规格被硬生生从中间切到两个块里检索时分别匹配到两块的部分内容但没有一个块能提供完整上下文模型拼凑出的答案就出错了。加了重叠区间之后同样的文档段落至少能以一个相对完整的形态进入检索范围。3.3 元数据管理给每个块一张“身份证”每个块不光要有内容还要附带元数据文档编号、章节路径、页码、块序号、创建时间。这些信息的作用有两个检索溯源模型回答时能正确引用“依据某文档第几章第几页”避免凭空编造来源。精细化过滤比如用户只关心某个章节的内容调度系统可以通过元数据预过滤掉其他所有块提高检索速度并降低干扰。元数据管理这块我的一个补充做法是给每个块打上“文档类型”标签比如“合同条款”“技术规格”“会议纪要”。后续调度系统在分配任务时可以按标签优先选择数据源。比如模型被要求“总结一下会议待办事项”那检索时就重点去捞“会议纪要”类型的块。这个优先级的灵活度只有在预处理阶段做好了元数据后面才施展得开。4. 任务调度编排如何把预处理和大模型调用串成流水线预处理做完相当于把食材切好洗净了接下来就要解决“怎么把菜一道道端出去”的问题。这一步我称之为任务调度。4.1 为什么要引入调度层如果只是处理一份文档那直接调一次预处理函数、再调一次大模型接口就够了。但真实的办公场景往往是一个批量任务一堆文档需要同步处理、多个问题需要交叉查询、单个问题还可能涉及多个知识板块。这时候任务与任务之间存在依赖关系你不可能用一段简单代码平铺直叙地写完你需要一个任务队列来控制顺序、分发任务、处理失败和重试。调度层的本质是把“做什么”和“怎么做”解耦。上层只需要描述任务目标——比如“完成合同审查”下层根据这个目标拆解出具体步骤——读取文档、切片、检索、组装 prompt、调用模型、输出报告。每一小步都是一个可独立执行、可监控、可重试的任务单元。# 一个简化版的调度流程用队列串起预处理与大模型调用 from crewai import Crew, Process # 或其他任务编排框架 from celery import group as celery_group def build_pipeline(doc_paths: list[str], query: str): # 第一步并行预处理所有文档 preprocess_tasks [preprocess_task.s(path) for path in doc_paths] preprocess_results celery_group(preprocess_tasks)() # 第二步汇总预处理结果执行分块和索引 chunks chunk_and_index(preprocess_results) # 第三步针对用户问题执行检索 retrieved retrieve_relevant_chunks(chunks, query) # 第四步组装上下文并调用大模型 final_answer llm_call_with_context(query, retrieved) return final_answer看每一步都是独立的、可观测的。哪个环节慢了、哪个环节失败了、哪个文档解析出来是空内容你都能在日志里定位到具体位置。这就是调度层的意义。4.2 拆解与聚合文档复杂时的任务编排策略当一份文档特别长、或者一个任务涉及多份文档时光靠“读一遍再回答”是行不通的。这里可以用 Map-Reduce 的思想来做任务编排Map 阶段把大任务拆成小任务。比如一份 100 页的合同先按章节拆解每一章单独提取关键条款。这种并行任务可以同时跑互不依赖。Reduce 阶段把各章节的结果汇总再由大模型做一次综合提炼输出最终结论。我用这个策略处理过一个实际场景一个项目要做投标文件合规性审查标书拆成了十几个章节的 PDF共 800 多页。如果直接把 800 页塞给模型任何本地模型都扛不住。用 Map-Reduce 的思路先把每个章节并行抽取合规要点再汇总成一份结构化的审查报告最终效果远好于一次性传几百页文档给模型。单轮任务的处理时间也从不可接受的十几分钟缩短到两三分钟。4.3 任务状态管理与失败重试现实世界不是线性的。解析某个文档时进程崩了、磁盘满了、某个依赖服务暂时不可用这些问题在本地智能体落地时都会遇到。任务调度层做好这两件事能省很多事任务状态持久化把每个任务的状态等待中、执行中、成功、失败记录到本地文件或数据库中。重启之后调度器可以从中断的地方继续不用从头再来。失败重试 降级策略解析 PDF 失败时自动尝试备用解析器调用模型超时时自动退回更小规模的模型回答而不是让整个流程直接中断。我这套链路最早就是用简单的脚本顺序执行遇到一个文档解析失败整串任务就挂了。后来加了调度层和失败重试之后跑一批 20 份文档哪怕中间有 2 份解析失败也能自动跳过并生成失败报告不会让整个批处理任务卡死在那里。5. 落地效果与复盘测试数据、性能对比和踩坑清单工具讲完最后必须看疗效。我把这套“文档预处理 任务调度”的流水线用在一个实际的办公场景里本地知识库问答系统需要处理不同格式的合同、技术文档和会议纪要并回答员工提问。下面是我整个落地过程中的关键数据。5.1 改造前后对比还是那个模型效果差很多指标改造前直接塞长文本改造后预处理 调度单文档最大处理量勉强 1 万字左右不限按块处理回答准确率抽样评测约 55%约 88%平均响应时间30 秒以上3-8 秒文档解析失败率直接报错中断单文档失败自动跳过并记录需要人工介入的批次几乎每批都要极端情况才需要回答准确率的提升尤其吸引人。同样的模型、同样的硬件只把输入从“一坨长文本”换成“结构化分块 精准检索 调度组装”输出质量天差地别。这再次证明长文本问题的解决方案不在模型侧而在工程侧。5.2 踩过的坑清单按出现频率排序解析 PDF 时没有处理扫描件。有些 PDF 是纯扫描图片没有文字层直接解析出来是空内容。解决办法接入 OCR 环节再走清洗和分块。这块我在第一版完全漏了导致整批文档解析结果为空。分块时硬切表格。Excel 或 PDF 里的表格被按固定长度切块时表头和数据被拆散了模型解读出来的数据完全错位。后来的做法是识别表格区域整个表格作为一个块处理不参与固定长度切分。清洗过头。一开始做噪音清洗时正则表达式把一些正文里的有效标点也删了导致分块时失去句子边界切出来的块语义混乱。清洗逻辑要保守不够可靠的正则宁可不用。调度任务没有设置超时。某个模型的推理时间过长时整个队列都被阻塞后续任务全部积压。后来给每个任务加了执行超时和并发限制问题才解决。元数据没管好。我把来源信息写在块的正文里导致检索时经常把“来源”也当成正文内容命中。后来把元数据和正文分开存储只把正文内容纳入向量化范围这个问题就消失了。5.3 一个小工具推荐用任务状态看板做可视化监控调度链路跑起来之后可视化的任务状态看板会是一个非常得力的工具。我用的是轻量级方案任务状态写到一个 JSONL 文件里再用一个简单的 Web 页面实时渲染。每一条任务记录都包含任务 ID、类型解析/清洗/分块/检索/回答、状态、耗时、错误信息。这样当某个批次的任务效果不佳时你能直接根据状态日志倒推到具体环节而不是对着一个黑盒盲目调参。不过可视化只是辅助手段真正重要的还是上文那套流水线每个环节可独立观测、可独立重试。如果你在搭的本地智能体还没引入调度层我建议从最简单的队列开始哪怕就是一个 Python 列表加死循环轮询也比散落的脚本顺序执行要可控得多。最后再分享一点我的体会在做这套链路的过程中一个让我印象很深的感受是技术选型不是最耗时间的最耗时间的是定义输入和输出之间的边界。文档预处理做多做少、分块切到什么粒度、调度任务拆到什么程度这些都没有绝对正确的标准答案只能根据你的模型能力、文档类型和回答场景反复调优。我现在的个人习惯是每换一批文档类型第一件事不急着调大模型参数而是先抓几份代表性文档跑一遍预处理流水线看看解析出来的文本干不干净、分块的边界合不合理。文档侧的问题解决了 80%模型侧的幻觉和超限问题自然就缓解了 80%。至于任务调度它保证的是整个流程的可靠性和可维护性让你在改动任何一环时都不至于牵一发动全身。如果你正在处理一个“长文本 本地模型”的场景先把预处理和调度这两层地基打牢再去纠结模型大小的问题。我实测下来的结论是很多时候不是模型不行是我们喂给模型的东西不行。