deepseek rag 教程

很多人看完 RAG 原理就动手，结果卡在「检索能跑、上线就崩」：向量库连不上没人知道、模型超时整条链一起挂、并发一上来就被限流、答案变差了也说不清是哪一步退的。这篇不重复讲原理，只给一条从零到能用的落地路线，以及实战项目该从哪个最小切口入手。

RAG 的原理文档到处都有，真正卡人的是另一回事：检索在本地跑得好好的，一上线就各种崩。向量库连不上没人收到告警、模型调用超时把整条链一起拖挂、并发稍微一上来就被限流、答案变差之后谁也说不清是哪一步退化的。这篇不重讲原理，只给一条从零到能用的落地路线，以及实战项目该从哪个最小切口进去。

先把心态摆正：RAG 不是一个模型能力问题，是一个工程链路问题。链路里的每一段都有自己独立的失败模式，混在一起调只能靠猜。下面按拆链路、做闭环、定运行参数、做日志评测、核对数字这五步展开，每一步都给可执行的动作。

先把链路拆成四段，别一上来写整体

很多人的第一版代码是一个大函数：读文档、切块、调接口、返回答案，全写在一起。结果是任何一处报错都定位不到。正确做法是先按数据流把链路切成四段，每段能单独跑、单独看中间结果，四段都稳了再串成一个应用。

进料段: 文档清洗、切块、向量化入库，产出可重复执行的脚本，而不是手工点一次的操作
检索段: 一次查询拿到候选片段，先不管生成质量，单独能调通、能把命中的片段打出来看
生成段: 把候选片段拼进提示词交给 DeepSeek，先验证「只依据片段回答、片段里没有就说不知道」这条约束是否真生效
串联段: 前三段各自稳了再拼成一个应用，这一段的主要工作是异常传递和超时控制

拆的时候有个判断标准：能不能在不调用大模型的情况下，把进料段和检索段单独跑一遍并打印结果。如果做不到，说明耦合还没解开，这时候调生成质量基本是浪费。什么情况下可以不拆？只有一次性验证概念、代码不会进入任何真实流程时才值得省这一步。

实战项目从哪切入：先做最小闭环再谈优化

实战项目入手最容易犯的错是场景选太大。一上来就想着把公司所有文档都灌进去，结果资料量一大，切块策略、召回质量、回答边界全都变模糊，出了问题根本不知道从哪查。第一步应该是选一个资料量小、答案边界清楚的场景，几十份文档就够。

选场景挑一个答案确定、范围封闭的问答场景，比如内部规范问答。判断标准是：你能提前写出标准答案，而且答案确实只来自这批资料
灌数据用脚本把这批文档清洗、切块、入库，记录切块参数。要验证的是重跑一次脚本结果一致，不是跑通一次就算
验检索单独调检索，看目标片段有没有进候选。如果正确答案所在的片段压根没被召回，后面调提示词再怎么改也没用
验生成把候选片段交给模型，问三个你已知答案的问题，再问一个资料里根本没有的问题。验收标准是前者答对、后者明确说不知道
加优化闭环跑通后才动优化，顺序是先看召回有没有漏、再看要不要加重排、最后才调提示词写法

反面情况也说清楚：如果你的场景本身就是开放域、答案需要跨多份资料推理，那最小闭环的验收标准要放宽，不能用「三个问题答对」这种标准硬套，得改成看召回覆盖率和人工抽样评估。

上线前必须定的三件事：超时、并发、降级

这三件事的共同点是：不提前定，线上就由别人替你定。超时只设一个总数，会让检索的慢和生成的慢混在一个桶里，排查时看不出是谁卡的。并发不设上限，你就是把上游的限流当成自己的限流在用。降级不写分支，出问题时只能靠临场拍脑袋。

项目	要定什么	常见坑
超时	检索连接、检索读取、生成首字、整体四个口径分开配	只设一个总超时，分不清卡在哪段
并发	先量单次延迟基线，再按上游额度往回推最大同时在途数	超出额度就硬打，被打回来还重试
降级	检索失败、生成超时各自走哪条分支，提前写死	临场判断，不同请求行为不一致
排队	超过并发上限时请求排队还是直接拒，要有明确策略	默默丢弃，用户看到的是无响应

并发怎么量：先固定一个请求规模，跑一轮拿到延迟基线，再推算同时在途多少不会把上游打爆。超出的请求走排队而不是直接丢，队列长度也要有上限。降级分支要写成配置而不是散在代码里，这样出问题时改配置就能切换行为。

日志与评测：让「变差」这件事可定位

RAG 最让人头疼的不是出错，而是「感觉答案越来越差但说不清哪里差」。解决办法只有一个：每次请求留够字段，改动之后能拿固定问题回归。这不是运维的事，是写第一版代码时就该埋的。

每次请求至少记：问题原文、命中的片段 ID 列表、拼进提示词的字符数、各段耗时、是否走了降级分支
留一组固定问题当回归集，改动切块方式、向量模型或提示词之后跑一遍，看答对率有没有掉
评测不只看「答得像不像」，更要看「依据的片段对不对」，检索错了再好的生成也救不回来
日志里不要记完整提示词原文，记字符数和片段 ID 就够定位，避免把敏感资料落到日志里

回归集怎么用：每次只改一个变量，跑完对比答对率。如果一次改了三处再跑，就算分数掉了也归因不到具体某一处。至于用哪套评测口径、分数怎么算，去站内评测页面看当时的说明，不同口径的分数没法横向比。

动手前先去站内把数字和目录对一遍

工程实现之外，选型和成本估算最容易踩的坑是拿记忆里的数字做判断。这类数字变化快，靠脑子记基本一定错。所以本文所有涉及具体数值的地方都写成「去某页核对」，而不是给你一个数。

你要确认的东西	去哪看	注意什么
模型规格与计费口径	官方来源页对照	别用旧记忆做成本估算，口径常变
向量库与嵌入模型选型	站内模型与工具目录	各家对维度、距离算法的默认值不同
接口延迟基线	站内测速工具	先量一次再定并发上限
陌生术语	站内词典页	概念上别耗时间，查完就继续动手
实时价格波动	站内价格追踪页	看趋势比看单点更有用

判断标准很简单：凡是你要写进代码注释、写进方案文档的数字，都必须有一个站内页面能对上，否则就写成「以页面当前值为准」。什么情况下可以不算得这么细？只有纯本地实验、不涉及任何真实计费和多人并发时才无所谓。

RAG 能不能上线，取决于你把失败路径设计得多清楚，而不取决于你把提示词写得多漂亮。

下一步先去站内工具目录挑向量库和嵌入模型，再去测速工具量一次接口延迟基线，两个数字拿到手再回头定你的超时和并发上限。

常见问题

没有 GPU，能不能先做 DeepSeek 的 RAG？

可以。检索和生成都走接口的话，本地只要能跑向量库和脚本就行，不需要显卡。真正的限制是并发的额度和单次延迟，先用小规模资料验证闭环，量出延迟基线再决定要不要本地化部署向量模型。

RAG 效果不好，应该先调切块还是先换模型？

先看检索结果对不对。把命中的片段单独打印出来人工看一遍，如果片段本身答不上问题，换生成模型没用；如果片段对但答得跑偏，再去调提示词和生成参数。切块方式属于最容易被高估的一步，通常排在检索召回之后。

这套链路上线后最常出的问题是什么？

多半不是模型答错，而是某一环超时或限流没被处理：检索库连不上、生成首字迟迟不来、并发一高就整批失败。提前把超时分档、并发排队和降级分支写清楚，比事后调提示词省事得多。