大模型 + rag + pdf问答

你已经能调通大模型接口，也想做「把一堆 PDF 丢进去、然后用自然语言问它」这个功能，但一上手就卡在几个地方：PDF 抽出来的文字是乱的、问一句要等很久、回答里找不到出处、跑一段时间账单超了也不知道哪一步慢。这篇不重讲 RAG 原理，只给一套能照着搭的工程顺序和排查动作，帮你把 demo 变成一个敢给别人用的 PDF 问答服务。

你已经能调通大模型接口，也想做「把一堆 PDF 丢进去、然后用自然语言问它」这个功能。但一上手就卡在几个很具体的地方：PDF 抽出来的文字是乱的，两栏排版串成一行；问一句要等很久，用户以为卡死了；回答看起来挺顺，但找不到出处；跑一段时间调用量上去了，却说不清到底哪一步慢、哪一步贵。这篇不重讲 RAG 的原理，只给一套能照着搭的工程顺序和排查动作。

思路很简单：把 PDF 问答当成一条流水线，进料、检索、生成、兜底、记录，每一段都有可验证的动作。先把流水线跑通，再谈调优。中间涉及模型和费用的具体数字，别信口头说法，到站内页面核对当时的数字更靠谱。

进料这一步先做对：PDF 怎么切、切完怎么验

PDF 问答翻车，一大半原因是进料没做好。第一步不是写检索，而是先分拣文档：原生带文本层的 PDF 和扫描件走两条不同管线。前者直接抽文本，后者先做 OCR 再抽。别指望一个库吃下所有 PDF，排版复杂的表格、公式、双栏，抽出来大概率是乱的。

1. 分拣文档按能否直接抽到文本，把 PDF 分成两条管线，分别记录成功和失败数量。
2. 按结构切片不要只按字数切，优先按标题层级或语义段落切，每片带上文档 ID、页码、章节名这些元数据。
3. 入库前抽查随机挑十条切片，人工看一遍文字是否连续、表格是否被切碎、页码是否对得上。
4. 记基线数字把切片总数、平均长度、抽取失败条数记下来，后面调检索全靠这个基线。

检索与回答：召回几条、怎么拼进提示词、答案带不带出处

检索这一段有两个容易搞反的参数：召回条数和相似度阈值。别先设阈值，先定召回几条。召回太多会把提示词塞满、拉高延迟，还容易把无关内容带进去；太少则答案缺信息。两个参数要一起调，并且用同一组固定问题来对比，不然就是凭感觉改。

• 召回结果按相关度排序后再拼进上下文，每段前面标上文档名和页码，方便模型引用。
• 明确要求模型在信息不足时说「文档里没有」，不要硬编，否则用户分不清是资料没有还是模型在猜。
• 回答结构里固定留一个来源字段，把用到的切片 ID 回传，前端才能做点击跳转。
• 同一个问题问两次，如果引用的切片都不同，说明切片或检索不稳定，先回头查进料那一步。

还有个常被忽略的点：提示词里给模型的上下文要限长。不是你召回多少就塞多少，超过一定长度后，后面的片段对答案几乎没帮助，却实打实增加延迟。到站内页面核对当时各模型的上下文上限，再决定召回上限，比拍脑袋强。

超时、并发与降级：PDF 问答最容易崩的环节在这

PDF 问答上线后最常见的投诉是「怎么这么慢」。慢在哪一段，光看总耗时看不出来。把整条链路拆成抽取、向量化、检索、生成四段分别计时，接口层面的基础延迟可以先用站内测速工具量一量，再对比应用层慢在哪。

1. 给每段设超时检索和生成各设一档超时，超时不要静默失败，返回明确状态。
2. 准备降级结果超时后降级成「只给相关片段、不做总结」，这也是一种可用结果，比转圈强。
3. 控制并发并发上来先排队，别一次把请求全推给向量库和模型，批量入库按批提交。
4. 返回明确错误向量库或模型任一环节不可用时，返回错误码和提示，别让前端一直等。

日志与评测：怎么知道这次改动是变好还是变坏

很多人改完切片策略或提示词，只凭感觉说「好像好点了」。要判断好坏，得先有可对比的东西。每次问答至少记几个字段：原始问题、召回切片 ID、分段耗时、token 用量、是否命中降级。出问题时，这些字段是你唯一的复盘依据。

• 准备一组固定问题集，覆盖能答、模糊、文档里没有这三类。
• 改切片或提示词后重跑一遍固定问题集，对比召回命中和胡编比例，而不是只看答得像不像。
• 上线后抽真实问题回看，把高频问不对的补进固定问题集。
• 评测集要跟着业务长，别一份问题集用一年。

评测重点看两件事就够了：该引用的片段有没有召回，没依据的时候有没有胡说。这两条比任何主观打分都实在。涉及具体模型表现和价格对比，别用记忆里的数字，到站内页面核对当时的数字，再决定要不要换模型。