拆解PDF文档问答：解析、切片与混合检索的工程实践

把一份 300 多页的设备验收规范丢进工具问“第 4 章里那台机组的振动阈值是多少”结果返回了另一份标准里的数值——这个场景我在过去一年里见过不下五次提问的人有做工程的、有做法务的也有写技术文档的。他们第一反应都是“这模型不行”但把同一份 PDF 换一种方式喂进去答案立刻就对了。ChatPDF 这类 PDF 文档问答工具真正决定成败的地方从来不在模型那一层而在模型看到的那几百个字是怎么被抽出来、怎么被切碎、怎么被找回来的。这个系列写到第三篇前两篇聊的是写作辅助和表格处理这篇专门拆“让文档开口说话”这件事它背后是什么原理、解析层有多少暗坑、切片和检索该怎么设计、扫描件和表格这类硬骨头怎么啃、以及自己动手搭一个能用的版本需要哪些零件。无论你是想把工具用明白的普通办公用户还是打算在内部系统里嵌一套文档问答能力的开发者下面的内容都能直接拿去对照。1. 从“翻页找答案”到“开口问答案”中间隔着四道工序很多人对这类工具的心理模型是“把 PDF 上传AI 读完了然后我问它答”。这个模型错得很彻底也是后面所有失望的根源。真实的链路是四段式的先把 PDF 拆成机器能读的字符流再把字符流切成一块块语义相对完整的片段然后把这些片段变成向量存进索引最后在你提问时召回若干片段、连同问题一起交给大模型生成回答。大模型从头到尾没有“读过”你的文档它只是在回答的那一刻看到了被检索出来的几段文字。1.1 为什么不能直接把整份 PDF 塞给大模型最朴素的方案是把全文拼成一个超长字符串一次性提交。这条路在 20 页以内的短文档上勉强能跑超过这个量级就会撞上三堵墙。第一堵是上下文窗口一份 300 页的技术规范中文大约 40 万字符就算模型宣称支持百万级上下文实际有效注意力也会在长文中后段明显衰减你问第 4 章的内容它可能被第 9 章的相似表述带偏。第二堵是成本每次提问都重传全文输入侧的计费会随页数线性膨胀一天问二十次就是二十倍开销。第三堵是延迟几十万 token 的预填充等上十几秒是常态。检索增强这套做法本质上是用“一次便宜的相似度计算”换掉“一次昂贵的全量阅读”。它把“读全文”这件事提前到入库阶段做一次之后每次提问只支付几千 token 的代价。代价是引入了新的误差源解析错了、切错了、没召回都会直接变成错误答案。所以讨论这类工具好不好用八成时间应该花在前三道上而不是纠结用哪个模型。1.2 四道工序各自会丢什么信息工序输入输出典型信息损失解析PDF 二进制纯文本 版面坐标阅读顺序错乱、表格结构塌陷、公式变乱码、页眉页脚混入正文切分长文本若干 chunk跨段语义被截断、标题与正文分离、指代对象丢失索引chunk 文本向量 元数据数字与专有名词的精确匹配能力被稀释检索生成问题 召回片段自然语言回答多片段冲突时取舍错误、超出片段范围时编造这张表值得贴在显示器边上。每次遇到“答得不对”先按这四行从上往下排查基本能在十分钟内定位到是哪一道出的问题。我自己的经验是解析层的问题占六成切分层占两成半检索和生成加起来的责任不到一成半。也就是说绝大多数“AI 不聪明”的抱怨其实是文字抽取阶段就已经把内容搞坏了。1.3 什么场景它靠得住什么场景别指望用久了会发现这类工具有很清晰的适用边界。判断标准不是文档长短而是“答案是否以一段相对独立的文字形式存在于原文中”。制度条款、产品手册、论文方法节、合同特定条款、培训材料这些都属于它的舒适区因为答案本身就是一段可以被完整摘出来的话。反过来需要跨几十页做汇总统计、需要对全表做数值计算、需要理解图纸里的空间关系、需要根据隐含逻辑做推理的它就容易翻车。有个很实用的自测方法拿三个你已知答案的问题去问它一个问题答案在单段内、一个问题答案分散在两个相邻小节、一个问题需要通读全文才能回答。前两个答对了说明解析和切分基本健康第三个答错很正常别因此否定工具而要意识到这属于“需要汇总”的任务应该改成分步提问或者干脆导出数据自己算。2. PDF 解析层决定成败的不是模型是你把文字抽成了什么样PDF 这个格式的设计初衷是“在任何设备上打印出来长得一样”它描述的是一堆字符画在页面哪个坐标位置而不是“这是一段话、那是一个标题”。这个本质决定了从 PDF 里还原出正确的阅读顺序本身就是一个需要判断的问题而不是一个可以直接读取的字段。搞不清楚这一点后面所有的优化都是在流沙上盖楼。2.1 先探测再决定用哪条解析路线同样是.pdf后缀内部结构可能天差地别。我习惯在上传后先做一次探测抽取前几页的文字层统计每页的字符数量。如果某页字符数接近于零但页面有图像那它是扫描件如果字符数正常但顺序明显错乱那是排版复杂但含文字层的电子版两者混杂的就是混合型。这个判断决定了后面走哪条流水线。def probe_pdf(path, sample_pages5): 粗略探测 PDF 类型决定后续解析路线 doc open_pdf(path) # 换成你手头的解析库 stats [] for i in range(min(sample_pages, len(doc))): page doc[i] chars len(page.extract_text() or ) has_img len(page.images) 0 stats.append({page: i, chars: chars, image: has_img}) avg_chars sum(s[chars] for s in stats) / max(len(stats), 1) if avg_chars 30: return scanned # 走 OCR 路线 if avg_chars 200: return digital_text # 走文字层 版面还原 return mixed # 逐页判断这个函数没什么技术含量但它能帮你避开最常见的一种浪费拿电子版 PDF 去跑 OCR既慢又引入识别错误或者拿扫描件去抽文字层得到一堆空白然后怀疑工具坏了。我见过有团队把整批扫描件喂进普通解析器索引里全是空字符串检索自然一无所获最后归因于“向量模型不适合中文”方向完全跑偏。2.2 抽取出来的是“字符”不是“文字”即使文字层完好直接抽出来的东西也常常没法用。中文排版里有几类高频污染我按出现频率排一下。第一类是页眉页脚和页码。它们会在每一页重复出现如果你不做剔除一份 200 页的文档里“XX公司内部资料 第 N 页”这种串会出现 200 次向量检索时它们会污染大量片段的语义让相似度打分失真。处理方法很直接统计所有页面中出现次数超过总页数 30% 的短行认定为页眉页脚模式批量删除。第二类是断行与连字符。PDF 里一个完整句子经常被硬换行切碎英文还会出现行尾连字符。如果不合并切出来的片段会变成“该参数的最”“大值为 12.5”语义虽然勉强能猜但关键词匹配会失效用户搜“最大值”搜不到。中文的情况更微妙段内换行和段间换行在字符层面看起来一样需要靠行尾是否有标点、下一行是否缩进来判断。第三类是字符编码层面的坑。有些文档用了特殊字体子集抽出来是乱码或者私用区字符有些公式用数学字体渲染抽出来是一串没有意义的符号还有全角半角混用、不间断空格、零宽字符。这些在肉眼阅读时完全无感但对检索是致命的。import re def clean_text(raw, page_no): t raw t t.replace(\u00a0, ).replace(\u200b, ) # 不间断空格、零宽字符 t re.sub(r(\w)-\n(\w), r\1\2, t) # 英文行尾连字符合并 t re.sub(r(?[\u4e00-\u9fa5])\n(?[\u4e00-\u9fa5。]), , t) # 中文段内换行 t re.sub(r[ \t]{2,}, , t) # 压缩多余空白 return t注意中文换行合并这条正则要慎用。如果你的文档是列表式排版每条一行、行尾没有标点这条规则会把整个列表压成一坨。更稳的做法是先判断该页是否属于列表版式再决定是否合并。2.3 版面还原双栏文档的阅读顺序陷阱这是解析层最容易被低估的问题。学术论文、产品规格书大量使用双栏排版而多数解析器按“从上到下、从左到右”的坐标顺序输出结果就是左栏第一行接右栏第一行再回到左栏第二行。人眼一看就知道错机器不知道。后果是切出来的片段全是两个不相干句子的拼接语义混乱检索命中率断崖式下跌。判断方法不难抽取每行文本的横坐标如果明显聚成两簇左半页、右半页就是双栏。修复思路是按栏分组先输出完左栏所有内容再输出右栏。带版面分析能力的解析器会自动做这件事但它们对三栏、图文混排、侧边批注的处理并不稳定重要文档我建议人工抽查前五页的抽取结果看一眼阅读顺序对不对。表格是另一个重灾区。绝大多数解析器会把表格拍平成按行的文本流单元格之间的对应关系彻底丢失。一张三列五行的参数表转成文本后变成一串数字和名词交替出现大模型看到这段文字几乎不可能正确回答“第三列第二行是什么”。这块的处理方案我在第 5 章单独讲。2.4 给每个片段装上“户口本”解析完成后我强烈建议保留位置信息这段文字来自第几页、属于哪一级标题之下、在原文档中的字符起止位置。这些元数据在下游至少有三个用处回答时可以标注“依据第 17 页第 3 节”让用户自己去核对检索时可以按章节做范围过滤比如用户明确问“附录里写了什么”就只在附录对应的片段里召回切分时可以借助标题层级做语义边界判断避免把一个完整小节从中间劈开。很多现成工具不给你这些信息回答只有一段话、没有出处。这种工具用来快速浏览还行一旦涉及需要核对原文的严肃场景没有出处的答案基本不可用。如果你要自己搭这一块的成本极低、收益极高属于必做项。3. 切片与检索为什么你的追问总是答非所问切片是整条链路里最需要经验的一环也是最容易被“默认参数”毁掉的一环。绝大多数教程给的建议是“每 500 字切一块重叠 50 字”这个参数在英文博客文章上勉强能用套到中文技术文档上经常出问题。原因很简单中文的信息密度比英文高500 个汉字的信息量大约相当于 900 到 1000 个英文单词切片太长会让一个片段里混入多个主题向量被平均掉检索时哪个主题都不像切得太短又会把因果链、条件句拆散模型拿到半截话只能靠猜。3.1 按结构切而不是按字数切我现在的默认做法是“结构优先、字数兜底”。具体说先用正则或解析器识别出标题行一级、二级、三级把文档切分成若干节如果某一节长度超过阈值中文我一般设 800 字再在节内按段落边界二次切分如果某一节短于 150 字就与相邻节合并。这样切出来的每个片段天然带着一个完整的论述单元语义完整度远高于机械按字数切。切分策略中文建议值适用文档主要风险定长切分400–600 字无结构的连续叙述跨段语义截断段落聚合300–800 字按段落边界制度、手册长段落被硬切标题层级切分按节节内再切规范、论文、说明书依赖标题格式规范语义切分动态混杂型长文计算开销高、不稳定重叠窗口我一般设 10%–15%也就是 500 字的片段重叠 50–75 字。重叠的作用是兜住“答案横跨两个片段边界”的情况设太多会让索引里出现大量重复内容检索时同一段话占据多个召回位挤掉真正有用的其它片段。3.2 元数据注入让片段自带上下文一个孤立的片段经常缺少指代对象。比如切出来一句“该值不得超过 12.5”这个“该值”指什么切片之前它是“第七节 振动限值。该值不得超过 12.5”切开之后指代就丢了。解决办法是在切片时把所属的标题路径拼到片段开头形成“文档名 第 4 章 验收标准 4.2 振动限值 | 该值不得超过 12.5”这样的结构。这段前缀会一起参与向量化效果提升非常明显尤其在多份文档混合索引时能有效区分同名章节。同理页码、文档版本、生效日期这些也建议拼进去或者存进元数据字段。我在一个多版本文档的场景里吃过亏新旧两版规范同时入库检索时把旧版条款召回给了用户答案虽然“有出处”但出处是过期文件。后来加了版本过滤问题才解决。3.3 混合检索向量救语义关键词救数字纯向量检索有个天然的短板它对数字、型号、编号、专有名词的区分能力很弱。“GB-7231”和“GB-7232”在向量空间里几乎重合但它们是两份完全不同的文件。用户在文档问答里最爱问的恰恰是“XX 型号的参数是多少”“第 3.2.1 条规定了什么”这类问题里最关键的 token 全是精确匹配型。所以我基本都会配一套混合检索向量召回取 Top 20关键词召回BM25 之类取 Top 20两路结果按排名融合取 Top 8 交给下游。融合算法可以用简单的加权分数归一化也可以用倒数排名融合后者的好处是不依赖两路分数的量纲一致性实现起来也就十几行。def hybrid_search(query, vec_index, kw_index, top_k8, pool20): q_vec embed_texts([query])[0] vec_hits vec_index.search(q_vec, pool) # [(chunk_id, score), ...] kw_hits kw_index.search(query, pool) # 倒数排名融合 scores {} for rank, (cid, _) in enumerate(vec_hits): scores[cid] scores.get(cid, 0) 1.0 / (60 rank) for rank, (cid, _) in enumerate(kw_hits): scores[cid] scores.get(cid, 0) 1.0 / (60 rank) ranked sorted(scores.items(), keylambda x: -x[1]) return [cid for cid, _ in ranked[:top_k]]那个 60 是经验常数作用是压低头部排名的绝对优势避免某一路的 Top1 直接锁定结果。这个数字不必纠结50 到 70 之间效果差异很小。3.4 多轮追问的上下文怎么管“它说的那个限值适用于哪个工况”——这种追问里出现了一个指代“那个限值”如果只把当前这句话拿去检索什么也搜不到。处理办法有两种一是把最近两轮的问答拼进检索 query 里让指代被历史文本补全二是先用一轮轻量的模型调用把追问改写成独立完整的问题再拿改写后的问题去检索。前者便宜但容易引入噪声后者多一次调用但准确率高。我一般默认用后者因为改写这一步顺带能纠正错别字和口语化表述对检索帮助很大。生成阶段还有个小技巧召回 8 个片段全塞进去并不总是好事。如果片段之间内容重复度高或者明显有冲突模型容易摇摆。我通常会在生成前做一次简单去重按片段首句的相似度并在提示词里明确要求“若多个片段给出不同数值请分别列出并标注出处不要自行取舍”。这句话能显著减少“模型自作主张挑一个”的情况。4. 搭一个能用的最小版本选型逻辑与可复现代码骨架聊完原理落到动手。我要先说清楚一个判断自己搭这套东西的门槛比想象中低但要搭到“敢在正式场合用”门槛比想象中高。中间差的是解析质量的打磨、自测集的建立、边界的处理。如果你只是想验证可行性一个下午够了如果要做成团队可用的工具两周到一个月是常态。4.1 三个关键选型的判断依据向量模型选本地还是远程。判断依据是文档的敏感程度和查询频率。涉及内部资料、客户信息、未公开方案的本地部署开源权重模型更稳妥代价是需要一定的显存和一笔一次性的部署成本。文档完全不敏感、查询量又不大的走远程接口更省事。要注意的是入库阶段的计算量和查询阶段完全不是一个量级10 万页文档的入库向量化可能需要几小时甚至更久而单次查询只在毫秒级。因此入库成本和查询成本要分开核算别被“单次调用很便宜”迷惑。向量库选文件型还是服务型。数据量在十万个片段以内、单机使用、追求部署简单文件型或嵌入式向量库完全够用启动零依赖。超过百万片段、需要多用户并发、需要增量更新和删除就得上服务型方案。中间还有一类“单机但带服务接口”的选项适合小团队内网共享。我的经验是先按最简方案做等到检索延迟超过 500 毫秒再考虑升级过早引入复杂组件只会增加运维负担。生成模型选大还是选小。文档问答这个任务的难点不在语言能力而在“严格遵守给定材料、不越界编造”。这个能力跟模型参数量不是严格正相关。有些小模型在“只根据材料回答”这条指令上表现反而更老实大模型则更容易“热心”地补充背景知识而补充的内容恰恰是你不需要的。建议拿同一套自测题跑两三个候选重点看“材料里没有时它是否老实说没有”这比看回答流畅度重要得多。4.2 一条能跑通的流水线下面这段是核心骨架去掉业务细节后的样子。为了让代码可移植我把解析和向量化抽象成接口你换成手头可用的实现就行。import hashlib def build_index(pdf_paths, store): for path in pdf_paths: doc_id hashlib.md5(path.encode()).hexdigest()[:12] pages parse_pdf(path) # 返回 [{page: n, text: str, blocks: [...]}] pages [{page: p[page], text: clean_text(p[text], p[page])} for p in pages] sections split_by_heading(pages) # 按标题层级切节保留 page 区间 chunks [] for sec in sections: for piece in chunk_section(sec, max_len600, overlap60): chunks.append({ id: f{doc_id}-{len(chunks):04d}, text: f{sec[path]} | {piece[text]}, # 元数据注入 doc_id: doc_id, page: piece[page], section: sec[path], }) vectors embed_texts([c[text] for c in chunks], batch16) store.add(chunks, vectors) store.commit()几个实现细节值得单独说。批处理大小设为 16 是个折中太小会导致调用次数多、往返开销大太大会撞上接口的 token 上限建议按片段的平均长度算一下确保单批不超过模型上限的 70%。split_by_heading这个函数是整个流程里最脏的一块因为 PDF 里的标题没有标签只能靠字号、加粗、行首编号“4.2”“第三章”去猜。我通常做两层判断先看行首是否匹配编号模式再看这行的字号是否大于正文中位数。两个条件都满足才算标题宁可漏判也别误判误判会把正文劈碎。4.3 提示词里必须写死的三条约束生成阶段的提示词决定了模型会不会“自由发挥”。我固定会写进去的三条是只使用下方提供的材料回答材料中没有的信息直接回复“材料中未提及”不要推测。回答末尾用「出处第 X 页」的形式标注依据若引用多个片段各自标注。如果不同片段对同一问题给出了不一致的信息把差异原样列出不要自行选择。第一条是防编造第二条是给用户核对路径第三条是防悄悄取舍。这三条加起来大约 100 字但对输出质量的影响比换模型还大。写完提示词后一定要用一个“材料里明确没有答案”的问题去测它看它会不会编。这一测能筛掉相当一部分“看起来很好用、实际不敢用”的方案。4.4 自测集二十道题定生死不用等别人来挑毛病自己先造一套题。我的做法是拿目标文档手工写出 20 个问题分四类各 5 个——单段内可直接找到答案的、跨两个小节需要拼接的、需要精确匹配型号或编号的、文档里没有答案的。然后逐题标注期望答案和期望出处页。跑一遍按类统计正确率。经验值是第一类应该接近 100%第二类 80% 以上第三类看解析质量如果编号识别不了会系统性偏低第四类必须是 100% 老老实实说不知道。哪一类不达标就回到对应环节去改别整体调参数。这套自测集的价值在于它是唯一能让你在“换了个模型之后到底变好还是变坏”这个问题上有客观答案的东西。我见过太多团队凭感觉调优改了三周回头一测还不如初版。5. 扫描件、双栏、表格与公式四类硬骨头前面讲的是“正常文档”的处理。真实世界里能让你卡住半天的往往是这四类扫描件、复杂版面、表格、公式。它们各自需要不同的策略混在一起谈没有意义。5.1 扫描件OCR 只是第一步扫描件的处理链路是“图像预处理 → 文字识别 → 版面分析 → 文本重建”。多数人只关注第二步实际上第一步的收益更大。倾斜校正、去噪、二值化、分辨率归一一般 300 dpi 足够再高只是增加计算量这几步做好识别准确率能提升一大截。特别是拍照生成的 PDF透视畸变和光照不均会显著拉低识别率直接做透视校正比换识别引擎有效。识别结果的置信度要利用起来。每个识别出来的文本块通常带一个置信度分数低于阈值的部分建议标记为“低置信”在最终回答里提示用户“该处原文识别质量较差请核对原件”。这个提示看似多余但在合同、检测报告这类场景里非常必要——一个数字识别错了可能引发完全不同的结论。我踩过一次坑一份扫描版检测报告里“≤”被识别成“”恰好提问问的就是边界值答案错了但看起来很自信。后来所有扫描件入库都加了低置信标记并在提示词里要求模型遇到低置信片段时主动说明。还有一种情况是扫描件里混着电子文字层比如扫描封面 电子正文。这类混合文档如果整体走 OCR会把原本完好的文字层也重新识别一遍白白引入错误。正确做法是逐页判断有文字层的直接用没有的才走识别。5.2 双栏与公式顺序错乱的两种表现双栏的问题第 2 章提过这里补一个实操判断方法抽取每页所有文本行的边界框计算横坐标中位数如果存在一个明显的分界点让左右两簇各自占比接近 50%就是双栏。修复时按簇分组、组内按纵坐标排序、组间先左后右。三栏的文档同理只是簇数变成三个误判率会上升建议这类文档直接上带版面模型的解析器。公式的麻烦在于它常常是图片或者特殊字体。抽出来是乱码人看不懂模型更看不懂。处理策略分两种如果公式只是辅助说明、答案不依赖它直接在清洗阶段丢掉别让它污染索引如果公式本身是核心内容比如技术方案里的计算式就得走公式识别把图像转成结构化表达式再入索引。判断依据很实际拿三个涉及公式的问题去测如果模型完全答不上来说明公式确实是关键信息值得投入如果答案主要靠周边文字就能推出来那就不必折腾。5.3 表格别指望它变成一段话这是我最想强调的一点。表格转文本几乎必然失败因为表格的价值在二维结构一旦拍平成一维字符流行列对应关系就没了。你可能会想“让模型自己从文字里还原结构”但模型看到的是“压力 温度 流量 12.5 380 2.3”这样一串东西它没办法知道哪个数字属于哪一列。正确的做法是把表格单独提取成结构化数据比如二维数组或表格对象存进一个独立的表格库和文本片段索引分开。用户提问时先判断问题是否涉及表格内容可以通过关键词或者一次轻量的意图分类如果是就把对应的表格结构连同表头一起喂给模型或者直接交给代码执行环境去做筛选和计算。后者更可靠因为涉及数值比较、求最大最小值、按条件筛选的问题模型算错的概率不低而代码不会算错。表格处理方式适用场景可靠性实现成本拍平成文本只有两三列、结构极简低极低转 Markdown 表格行列规整、无合并单元格中低结构化存储 代码计算数值查询、多列筛选高中视觉模型直接读图复杂版式、合并单元格多中高高跨页表格是另一个坑。一份长表格被分页切开第二页往往没有表头。如果你按页切分第二页的片段就变成一堆没有列名的数字。处理办法是在解析阶段检测“该页首行是否为表格续行”通常表现为没有表头、列数和上一页末尾一致如果命中就把上一页的表头拼过来。这个逻辑不难写但没写的话跨页表格的后半部分基本等于废数据。6. 实测中踩到的坑与那笔容易被忽略的成本账写到这里原理和方案都齐了最后聊点实战里真正会卡住人的东西。这些内容在任何官方说明里都找不到全是踩出来的。6.1 五个高频故障的定位链路症状一上传成功提问全部回答“材料中未提及”。排查顺序是先看索引里的片段数量和总字符数如果字符数接近零是解析失败大概率是扫描件走了文字层路线如果字符数正常但检索召回为空是向量维度和查询不匹配或者索引没提交如果召回有内容但模型仍说没有是提示词约束过强或者片段被截断。这个链路我走过很多次八成问题出在第一步。症状二答案对但出处页码全错。这是切片时页码映射没做对。常见原因是先合并全文再切片页边界信息在这个过程中丢了。正确做法是切片时逐块携带来源页一块跨页就拆成两块。症状三问具体型号永远搜不到。纯向量检索的固有问题加关键词混合检索就能解决。如果加了还不行检查分词器是否把型号拆碎了——“AB-1234”被拆成“AB”和“1234”匹配自然失效需要在分词阶段加白名单保护。症状四同一份文档上午答对下午答错。检查是否有重复入库。增量更新时如果没做去重同一份文档会被索引多次检索时同一段话占满召回位把其它有用片段挤掉答案就飘了。用文档指纹做唯一键能避免。症状五追问几轮之后开始胡说。上下文越堆越长历史里的错误答案被当成事实反复引用。解决办法是限制历史轮数三轮以内并且在每轮生成时都重新检索不要复用上一轮的召回结果。6.2 成本结构入库是一次性的查询是长期的很多人只算查询成本忽略了入库。一笔粗略的账一万页中文文档按每页 800 字算总量约 800 万字切成 600 字一块大约 1.5 万个片段。向量化这 1.5 万个片段是一次性开销但如果你改了切片策略、换了向量模型、或者给片段加了新的元数据前缀就得全部重算。这就是为什么切片策略要在动手前想清楚——它不是“调一下参数”而是“重跑一遍全量”。查询侧的成本主要在生成。每次提问召回 8 个片段每片段 600 字加上问题和提示词单次输入大约 5000 字输出几百字。按每天 200 次查询算一个月的开销对个人用户是可以接受的量级对团队则需要做额度控制。省钱的几个方向缓存高频问题的答案很多团队的提问重复率超过 30%对简单问题走小模型把召回的片段数从 8 降到 5前提是自测集正确率不掉。6.3 权限和隐私这两条线不能事后补如果这套东西要给多人用权限模型必须在索引设计阶段就定下来。最基本的要求是片段级别的权限标签检索时按用户身份过滤而不是在生成之后再做脱敏。原因很直接——如果无权限的内容进了模型上下文即使最终回答里没出现它也可能以“根据相关规定”这种模糊表述泄露信息。这个坑很深事后补的代价是重建整个索引。隐私方面我的建议是把“文档会不会离开本地”这个问题在上线前明确回答清楚并让使用者知道。内部资料、个人信息、客户数据这几种内容在多数场景下都不适合送到外部接口做向量化。本地部署方案在这类场景里不是“更安全的选择”而是“唯一的选择”。6.4 什么时候该推倒重来最后说个反直觉的判断如果你发现自己在不停地调提示词、换模型、加规则而自测集正确率始终在 60% 附近徘徊那问题几乎肯定不在生成层而在解析层。这时候正确的动作是停下来把前五页的抽取结果打印出来一行一行读一遍。我做过这个练习第一次看到自己以为“解析成功”的文档里段落顺序是乱的、表格是一坨数字、页眉混在正文中间那种冲击感比任何调参都管用。反过来如果解析结果干净、切分合理、自测集第一类问题接近满分只是复杂问题答不好那就别折腾了接受它的能力边界把复杂问题拆成几个简单问题分步问效果比继续优化链路好得多。我个人在实际操作中的体会是这类工具的价值不在于“替代阅读”而在于“把定位成本从几分钟压到几秒”。它帮你快速找到那一段话在哪剩下的判断还是得自己做。把它当成一个反应极快、但偶尔会指错页码的助手用起来会舒服很多指望它替你读完并给出结论失望是迟早的事。真正值得投入时间去打磨的永远是那份二十道题的自测集和那份干净的解析结果其余都是锦上添花。