示例报告

我挑「智能文档助手」。因为它是从解析、切分、召回、重排到合成和接口的完整链路，成本那块本质上是它的下游产物，脱离主干讲成本不好讲清楚。可迁移的结论有三条：一是路由思想，把任务按难度分流到不同模型，这个在检索、抽取、摘要上都能用；二是分段处理，长文档两段式摘要和表格按行列展开，都是把「一次处理不完的东西」拆成可控颗粒；三是口径意识，成本这类数字必须先说清怎么统计的，否则优化无从验证。

是我主动加的。原因很直接：这种提升幅度的数字如果不写口径，面试官第一反应一定会追问，而且很容易被默认成自动指标拿去和别家对比，那对我反而不利。写清楚「人工盲评、是否可直接采用」，等于提前把边界划出来，讨论就能直接进入方法和样本量，而不是先花五分钟澄清数字含义。另外我确实有个习惯，写周报和文档时会把口径和边界写清楚，不做看起来很准的指标，这句话算是这个习惯的延伸。

我分一下。算法侧是我的主责，包括解析后的切分策略、召回重排的选型、合成答案的约束，这些改动是我提的、我做的；后端接口也是我写，三个接口和 Celery 那条异步链路。前端那一块，管理端主体是前端同学写的，我负责对话界面和引用定位这部分，以及和接口的联调。K8s 是运维主导，我配合写了健康检查和限流规则。那次雪崩是我参与定位和善后，重启也是我做的，但加 maxLifetime 和熔断是运维和我一起定的。原则是配合的活我不说成主导，但联调和线上问题我愿意认。

来源是客服的工单附件和合同，这两类版式差别挺大：工单附件格式杂、扫描件不少，合同相对规整但有大量表格和跨页。判断解析质量我一般不看好不好看，只看两件事：关键内容有没有丢，以及切出来的块是不是语义完整。做法是维护一个抽样文档集，每次改解析器就跑一遍，人工对照原始 PDF 看条款、金额这类关键位置有没有被吃掉。如果表格解析完行列错位，后面检索再好也救不回来，所以这一环我是按「召回条款是否完整」来验收，而不是按字符抽取率。

这里我得先坦白，我当时没有做严格对照。我的观察方式是：先把「表格条款答不上来」的 bad case 挑出来做成一个小集合，改动前后跑同一批问题看命中变化，同时不碰其他环节。这种方式能排除掉一部分干扰，但不能算严格的因果证明，因为 reranker 和切分粒度那段时间也有微调。如果现在重做，我会固定其他变量、留一个不改的对照组，并且把命中率拆成表格类和正文类分开看，这样收益归属才站得住。

上传接口本身很轻，只做落盘、算幂等键、投递任务，然后立刻返回一个 task 标识，真正的解析不在这条路径上。解析走 Celery 异步，任务进 Redis 队列，用独立的 worker 消费，并且限制并发数，避免解析把 CPU 和内存吃干、影响在线问答。在线问答是另一条路径，只读向量库和缓存，不依赖解析 worker。所以这两件事在资源上是要分开的，容量和并发也得分开压。这也是当时选 Celery 而不是在 FastAPI 里直接解析的原因。

这个口径我得如实说，当时的统计是偏粗的，主要是问题文本层面的重复统计，加人工看了一批近似问法，没有做严格的语义聚类。所以我只能说 40% 是个量级参考，不能当成精确的重复率。这也解释了为什么语义缓存的命中率是 37%，和 40% 比较接近属于合理，但我不能因此说缓存把重复问题捞干净了。如果重做，我会先对问题做一次聚类，分出「字面重复」「同义改写」「只是同一个文档的不同问题」三类，再看缓存能覆盖哪几类——因为第三类其实不该命中缓存，答案很可能不同。

采纳在我看来只是弱标签，它代表用户这次懒得改或者够用了，不代表答案正确。所以我的做法是把它当成复核队列的优先级信号，不是直接当正样本入集。真正进评测集之前要人工过一遍，判断是答案错、出处贴错、还是用户就是没用上。不采纳的同样要分类，有的确实是答错，有的只是用户想换个问法。标签如果不分类，评测集会越跑越偏，最后优化的方向也会跟着偏。

关键是切分的时候就别丢位置。每个 chunk 入库时我带着 doc_id、页码和块序号一起存，检索命中后这些来源信息要一路带到合成阶段。合成时我不让模型自己编出处，而是把这些候选块编号给它，要求它按给定的 cite 标识引用，模型只能选我给的编号。前端拿到的就是这些编号对应的位置，直接定位到原文段落并高亮。跨 chunk 的答案就带多个编号，前端就依次跳。这样做的核心是——出处是检索层给的，不是模型说的，模型说的出处不可信。

这两件事不是因果关系。重排确实增加延迟，它是在召回之后对候选做一次交叉编码打分，属于纯加法。P95 从 4.1s 降到 2.3s 是成本优化那一版的整体口径，主要来自两个地方：一是语义缓存命中后直接返回，压根不走后面的重排和生成；二是两段式摘要把输入 token 从 11k 压到 3.2k，生成阶段的时间显著下降。所以是缓存和 token 省下来的时间，盖过了重排加的那部分。我不会拿这两个数字说重排变快了，那是两回事。

这道题考的是结构化文本对两路召回的不同影响。对 BM25 来说，重复表头会让这些词的文档频率虚高，IDF 被拉低，结果是表头词变得没有区分度，甚至任何带这张表的 chunk 都能被召回。缓解办法是控制重复：只在块首或每若干行保留一次表名加列名，或者把表名单独作为一个字段参与召回。对 embedding 来说问题相反，展开后的文本是一堆「字段名：值」的短句堆叠，语义很稀薄，直接编码出来区分度差。更稳的做法是把表名、列名拼成一句自然语言描述再编码，让它落到语义空间里。

检索和生成我分开评。检索侧看 recall@k、MRR 这类，便宜、可复现，适合回归；生成侧看答案是否忠实于给定的上下文、出处对不对。如果只留一个指标，我会留「答案可采信率」，因为它最贴近用户价值，能同时反映检索和生成两端的问题。但它贵，必须抽样且要人判。所以我的实际建议是：日常回归用检索指标卡门禁，发布前用可采信率抽样兜底。一个便宜但只能测一半，一个贵但能测全链路，两个位置不同，不能互相替代。

判断逻辑是先分清「谁在等」。看池的活跃连接数、等待获取连接的时长，同时看下游自身耗时和错误率。如果下游耗时正常、错误率也正常，而本服务这边请求全卡在拿连接上，那问题就在池，不在下游。maxLifetime 是兜底——它让连接到期强制回收，把泄漏或异常路径没归还的连接捞回来，但它不修复泄漏本身，真正修的是把所有分支包括异常分支的归还都补齐。熔断处理的是另一件事，它防的是下游真的挂了之后请求继续堆积，把本服务也拖垮。两者一个是治存量一个是防扩散，性质不同。

我会分三层。第一层是优先用模型服务商提供的结构化输出或 function calling，由它在解码层面约束，这比纯 prompt 靠谱得多。第二层是 prompt 侧配合，把 schema 写清楚、字段尽量浅、少用嵌套和自由文本长字段，再给一两个例子。第三层是兜底：收到结果先用 JSON Schema 校验器校验，不合法就把错误信息拼回去让它修一次，重试一次还不行就降级到规则抽取或转人工。要注意的是，校验不能只看能不能解析，字段类型、枚举值、必填都得校，否则会出现「能解析但字段是错的」这种更隐蔽的问题。

常见实现是先把文本切成句子，再算相邻句子的向量相似度，在相似度明显掉下来的地方断开；另一种是直接按结构切，比如条款编号、标题层级。合同这类文本结构非常强，有明确的条、款、项，我个人会优先按结构切，语义相似度只用来兜底——比如一段正文特别长又没编号，再用它切。好处是块和条款对齐，召回出来就是完整一条，引用定位也准。风险有两个：块长度方差大，超长的还得再切、太短的还得合并，否则会影响召回；另外语义切分对流水线依赖重，多一步模型推理，慢了也更容易出错。

TTL 我倾向于按内容的时效性分档，不能一刀切，但这里的主要作用是控制错误的暴露窗口，所以宁短勿长。纠错的处理要分两步：第一步是立刻失效，把这条 key 删掉或者标记成不可用；第二步是防止它再被命中，因为命中判断是走相似度的，删了 key 之后同义问法还是可能匹配上来，所以要把这条问题加进一个「禁止命中」的集合，命中的时候先过这个集合。同时这条要进 bad case 集，用来回头看阈值是不是定松了。只删缓存不做第二步，等于没修。

幂等键放在文件内容上，不是文件名，也不是请求 ID。上传时先算内容 hash，查这个 hash 有没有解析过，有就直接复用原来的文档标识，不再投递任务。任务侧再做一层，用文档标识加分布式锁防止重复投递和并发消费。最后是写入侧，向量库里用文档标识加块序号做主键，走 upsert 而不是 insert，这样即使任务重复跑，结果也是覆盖而不是翻倍。三层里最后一层最重要，因为前两层都可能因为异常重试被绕过，写入幂等才是最终防线。

Redis 作为 broker 本质上是拿 list 或 zset 模拟队列，没有原生的确认、重投、死信和优先级机制，投递语义偏 at-most-once，实例挂了或者 worker 拿到消息就崩，消息就可能丢。缓解方式是配合 visibility timeout 加定期重推，但代价是会出现重复投递，所以消费侧必须自己幂等。什么情况该换？当任务不能丢、需要严格的 ack 和死信队列、需要优先级和延迟队列、或者需要按路由分发的时候，我会选 RabbitMQ 这类专业 broker。反过来，任务可重跑、量不大、团队又已经在用 Redis，就先用 Redis，别为了可靠性提前复杂化。

风险主要有三个。第一是淘汰策略打架：缓存希望内存满了按 LRU 淘汰，但队列里的消息被淘汰就是丢任务，所以同一个实例上没法用一套策略满足两边。第二是互相拖累，大 key 或者热 key 的慢操作会顶住整个实例，队列的延迟和缓存的延迟互相影响。第三是内存打满时两边一起出问题，故障域没有隔离。做法是拆成两个实例，队列那个设 noeviction，缓存那个设 allkeys-lru，并且分开监控。只分 DB 号是不够的，因为内存和淘汰是实例级共享的，DB 隔离不了这个。

这里我不追求强一致，走的是「元数据为准、向量可重建」。删除时先在 PostgreSQL 标记为已删，再按文档标识去删 Milvus 里的向量。如果 Milvus 删除失败，就落到一个补偿任务里按软删列表重试。更关键的是读路径兜底：检索出来的候选，在返回前按 PostgreSQL 里的有效文档集合再过一遍，删漏的也召不回来。这样即使两边短时间不一致，用户也看不到已删文档。为什么不做强一致？因为跨存储的分布式事务代价太高，而这个场景对一致性的要求其实是「最终一致且读路径不能漏」，用软删加补偿加过滤就够了。

我先按重排分数排序，按顺序取，同时卡一个总 token 预算，预算里要给系统提示和输出留出余量，不能把窗口占满。超预算的时候我不倾向直接截断尾部，因为对条款类问题来说，把一个条款从中间截断比少召几篇更危险——模型会拿着半句话编出完整结论。更稳的做法是少取几篇但保证每篇完整，或者对候选做一次预处理压缩，但压缩会丢细节，只适合摘要类任务，不适合抽取类。所以按任务类型分开定策略，而不是一套规则走到底。

核心原则是过滤条件必须下推到检索入口，而不是召回之后再筛。每个块入库时打上部门、密级这些标签，向量检索和 BM25 两路都在查询时带上这些过滤条件，Milvus 用标量字段过滤，关系库用条件过滤。如果先召回全部再过滤，中间结果已经进过 rerank、进过日志，那就是泄漏。第二个要点是缓存 key 一定要带权限维度，否则同一个问题法务命中过、销售就直接拿到答案，这是很容易被忽略的一条。再往外是审计和脱敏：谁在什么时候问了什么、答案引用了哪些文档都要留痕，敏感字段在返回前做掩码，生成阶段也不引入无权限的片段。

前两天先不碰代码，拿 50 到 100 个真实问题和期望答案做一个小评测集，把现有链路直接跑上去拿基线，这一步的目的不是做好，是看清失败长什么样。第三天开始分桶：是检索根本召不回、是切分把关键信息切碎了、还是术语对不上、还是文档里压根没有答案。然后针对最大的那一桶试一到两个改动，比如加领域词表、换或补一个领域 embedding、调整切分粒度。第二周做消融，确认这个收益稳定、不是运气。判断标准很清楚：如果失败集中在检索层，架构能复用，调检索就行；如果大量问题需要跨文档多跳推理、或者答案本身不存在，那就不是调优能解决的，得换方案。

不管是涨价还是私有化，第一件事都是把模型调用抽象成一层网关，业务侧只调这层接口，后面换什么模型对上层透明，这是前提。在这个基础上走三条路：一是路由，把对生成质量要求低的任务——摘要、分类、重排——先切到本地小模型或便宜模型，只留复杂抽取和追问走大模型；二是省 token，靠更准的召回把上下文压到最小，把离线摘要改成批处理跑；三是预热，把高频问题的答案提前算好。私有化部署的坑主要在本地模型的中文长文能力和并发吞吐，这两个必须压测过再切量，不能看着 demo 能跑就上。

我最缺的是可复现、可归因的实验能力。成本那个 37% 我没把语义缓存和小模型分流拆开看，只做过一周的分项观察，这就是典型症状——做得出来，但说不清是哪一步起的作用。这样往上走会很吃亏，因为你没法判断下一个改动值不值得做。打算分两步补：第一步是流程上的，任何优化先写口径、留对照组，评测集和回归跑当成习惯而不是额外工作；第二步是补模型侧的动手能力，做一次完整的数据构造和微调，因为现在遇到检索解决不了的问题，我手里只有调检索这一张牌。

我的依据是文档来源的分布和维护成本，不是技术难度。如果绝大部分文档来自几家固定模板的合同，那自研或者用开源底座加模板规则成本很低、也可控，继续自研是划算的。如果来源很散、版式五花八门，自研就会变成长期人力黑洞——每来一个新模板就要修一次，这类活我不建议团队自己扛，应该换成成熟的版面分析加表格结构识别方案，把人放在检索和合成上。所以我会先统计一份文档来源和版式的分布，再决定，而且这个统计要定期重跑，因为业务模板是会变的，一次判断不能管三年。

我希望是「把 RAG 这类系统从 demo 做到线上，并且能说清它为什么好、为什么不好的那个人」。后半句比前半句更难，也是我现在最缺的。接下来 12 个月我想做三件事，都尽量可衡量：第一是把评测做扎实，口径、对照组、回归集这一套跑顺，争取每季度产出一份带口径的评测结论；第二是补一次完整的领域模型适配，哪怕是个小模型，把数据构造到评估走通一遍；第三是在系统侧再完整吃一次故障，压测、容量规划、成本模型都自己做一遍，而不是等运维给结论。