很多人把 DeepSeek API 调通、检索也接上了，一放到真实使用就出问题：检索慢把整条请求拖超时、并发一高就限流、召回不准没人发现、出了错翻不出日志。这篇不重讲 RAG 原理，只讲从「能跑」到「敢用」之间要补的工程动作，每个环节给一份可照做的清单。
很多人把 DeepSeek API 调通、向量库也接上了，本地跑几条问题看着挺像样，一放到真实使用就开始出状况：检索那一下慢几秒，整条请求直接撞超时；并发一上来就吃限流；召回不准几天都没人发现；真出了错，翻日志发现什么都没记。这套东西从「能跑」到「敢用」，中间隔着的全是工程动作，不是算法。
这篇不讲 RAG 原理，只讲五个环节的落地做法：延迟预算、并发与批处理、降级策略、日志与成本、评测闭环。每个环节给一份能照着做的清单，最后附一条排查顺序。已经跑通 DeepSeek API 的人可以直接对号入座。
先把检索延迟算进预算，再谈超时
一次 RAG 请求的耗时大致分成三段：向量化加检索、Prompt 拼装、模型生成。多数人只给整条请求设一个超时，结果检索慢一点就把生成的时间也吃掉了，用户等到的是超时而不是一个稍慢的答案。正确做法是先量基线，再分配预算。
- 量你自己的延迟基线到 /tools/speed-test 跑一次，得到你所在网络到接口的响应基线。这个数是你做预算的地板，不是别人的平均值。
- 给每段单独设超时检索段设短一些（比如只够一次正常查询），拼装段可以忽略，生成段设长一些。三段各自超时，互不拖累。
- 超时就降级，不是报错检索段超时，就少召回几条或者退回纯模型作答；生成段超时，返回已有内容并标注未完成，别让整条请求失败。
并发、批量和失败重投怎么排
RAG 场景里有两个并发要分开看，混在一起谈就会互相甩锅。一个是外部打到你服务的请求并发，一个是你对 DeepSeek API 发起的调用并发。前者要靠队列削峰，后者要设硬上限。两者之间没有自动关系，得你手动接上。
| 环节 | 做法 | 判断标准 |
|---|---|---|
| 外部请求并发 | 入口挂队列，超出的排队而不是直接打接口 | 队列长度和等待时长要能观测，不能黑盒 |
| 调用接口并发 | 设一个硬上限，超了就等，不要放开 | 上限调到限流边缘就停，留一点余量 |
| 批量建索引 | 分批发送，每批之间留间隔 | 失败项单独收集，不跟成功项混在一起 |
| 失败重投 | 先判断是限流还是内容问题，再决定重投 | 限流就等，内容问题重投多少次都一样 |
重投必须幂等，这点最容易被忽略。同一份资料重复入库要去重，同一个问题重复回答要能识别出来。否则跑一段时间，知识库里全是重复片段，检索分数被稀释，召回质量掉得莫名其妙。限流恢复节奏和退避策略的通用做法可对照 /guides 里并发与限流相关篇目，但 RAG 场景要多做一步：检索失败和生成失败分开计数，因为它们的原因和修法完全不同。
检索拿不到东西时，回答怎么退
这是最容易做错的一节。很多人一看到召回了片段就全塞给模型，哪怕分数很低。低置信度时硬塞片段，比不检索更容易让模型编，因为它有素材可依，顺着就写下去了。宁可少答，也不要假答。
- 命中且分数够高：正常带引用回答，引用要能点回到原文片段
- 命中但分数低：明确告知「资料里没有确定答案」，不硬编
- 完全无命中：先问用户要不要转纯模型作答，把选择权交出去
- 兜底话术做成配置项而不是硬编码，客服类场景更保守，内部工具类可以更放开
- 低分片段的处理要和切片策略联调，分数低有时是切片切坏了，不全是召回问题
日志只记该记的，让慢和贵都能复盘
日志的目的不是全量存档，而是出事时能复盘。整段存向量和全文既贵又难查，真正有用的是一组结构化字段。每次请求至少留下问题、召回的文档 ID 与分数、最终给模型的上下文长度、生成耗时、是否走了降级。有这几项，慢和不准都能定位。
Token 消耗要按检索段和生成段分开统计。检索段的消耗来自嵌入和拼装，生成段来自模型输出。不分段，你永远不知道钱花在拼接上还是生成上。具体口径和换算到 /tools/token-price-calculator 与 /official-api/providers/deepseek 核对当时的数字。
- 上下文长度设硬上限，召回条数多了会顶到窗口
- 裁剪时先删低分片段，不要截断高分片段的中间
- 降级请求单独打标记，方便事后统计降级率
- 日志里只存文档 ID，不存文档全文，全文去库里查
怎么知道它到底变好还是变差
改了切片、改了召回条数、改了提示词，感觉好像好了一点，但到底是真好还是这次问的问题简单，光凭单次输出看不出来。得有一组固定的问题，每次改动都跑一遍，才有对比。
- 攒一组固定问题二十条左右就够，覆盖四类：能答的、答不了的、需要多段拼的、问法模糊的。这组问题不要随改动一起换。
- 只看两个量化指标命中率，该召回的有没有召回；引用正确率，引用的片段是不是真支撑答案。别只看输出好不好看。
- 换切片或换向量模型时一起更新评测集旧评测集不一定还适用，拿旧标尺量新方案等于白跑。评测集和方案要同步迭代。
排查顺序按这个走：先看是不是检索慢导致超时，再看是不是并发或限流，然后看降级有没有按预期触发，接着翻日志确认召回分数，最后拿评测集验证改动。这个顺序的好处是每一步都能排除掉一层原因，不用同时怀疑五件事。
下一步把你现在的检索段和生成段超时拆开，再去站内看看并发与上下文预算相关篇目，然后跑一遍当前方案的速度基线，心里就有数了。→常见问题
DeepSeek API 做 RAG，向量化和生成要用同一个模型吗？
不用。向量化是嵌入模型的活，生成是对话模型的活，两者分开选。选择嵌入模型时主要看中文效果、维度、能不能本地跑，可到站内嵌入模型目录对照当时的可选清单，再看官方接口页确认调用口径。
检索明明召回了，模型还是不用资料回答怎么办？
先确认召回的片段是不是真的相关，分数阈值是不是设太低导致塞了一堆噪音。其次看 Prompt 里有没有明确要求「只依据给定资料回答」以及引用格式。最后检查上下文是不是已经顶到窗口，靠前的片段会被挤掉。
测试环境好好的，一上线就超时，从哪查起？
按顺序排：先用测速工具比对线上和本地到接口的延迟差异；再看检索段耗时是不是被知识库规模拖慢；然后确认你对 API 的并发上限有没有和线上流量匹配。多半是最后一环，请求堆在队列里等而不是单次变慢。
