很多人照着教程把向量库跑起来了，可真接上 DeepSeek 之后发现答非所问、检索召回一堆无关片段、成本还控不住。这篇不重复讲 RAG 是什么，只讲从选模型、切片入库到生成调优这条链路上，具体先做什么、后做什么，以及哪些环节一旦偷懒后面会返工。
很多人照着教程把向量库跑起来了，向量检索也能返回结果，可真接上 DeepSeek 之后发现答非所问、召回一堆无关片段、账单还一路往上走。问题基本不在模型本身，而在整条链路上每一步都留了坑：切片没切好、召回条数没定、提示词没约束、上线后又没有评测手段来定位问题。
这篇不重复讲 RAG 是什么概念，只按落地顺序把该先做什么、后做什么讲清楚，每一步给出能自己验证的判断标准。适合打算自建知识库、手里已经有文档、但还没把生成效果调顺的开发者。
先把两个模型分工定死：生成用 DeepSeek，向量化另选
最容易犯的错是把 DeepSeek 当成万能模型，以为它既能生成又能算向量。实际上在 RAG 里它承担的是「拿到片段后组织答案」这一步，向量化必须另配嵌入模型。这两件事一旦混在一起想，后面选型就会一直拧巴。
- 嵌入模型替换成本很高：换一次，历史向量全部作废要重建，所以选之前先确认它中文效果可用、维度够用、调用稳定，别贪便宜选了个不维护的
- 生成侧要提前想清楚调用路径：走官方接口还是中转站，长文档场景下上下文窗口和并发限制会不会成为瓶颈，价格口径去 /official-api/providers/deepseek 核对当时的数字
- 把两边的超时和重试策略分开配，嵌入服务抖动不该拖垮整个问答链路
- 不适用情形：只做几十条 FAQ 的小库，硬上向量检索反而更慢，关键词匹配加一次大模型润色可能就够
进料与切片：脏数据放进向量库，后面调什么都救不回来
这一环节最不起眼，但返工率最高。扫描件、页眉页脚、目录页、重复水印，如果入库前不处理干净，检索回来的必然是垃圾片段，后面调提示词、加重排都只是给烂地基刷漆。
| 文档类型 | 切片方式 | 要保留的元数据 |
|---|---|---|
| 合同、条款、规章 | 按标题层级切，一节一片 | 文档名、章节号、生效版本 |
| 产品说明、操作手册 | 按自然段落切，段落过长再拆分 | 产品名、章节、更新时间 |
| 问答、客服话术 | 一问一答为一个整体，不拆开 | 问题分类、来源渠道 |
| 表格类数据 | 整表转成结构化文本再切 | 表名、字段说明 |
- 先清洗去掉页眉页脚、目录、水印和重复段，扫描件先做文字识别并人工抽查几页，确认识别没串行
- 再切片按上表选策略，每片保留来源路径和标题，方便回答时给出处；别一刀切固定字数
- 抽检片段随机抽十几条看语义是否完整，被拦腰截断的片段是最常见的召回失败原因，发现就改切片规则重来
- 入库带元数据文档名、章节、更新时间一起存，后面做过滤和增量更新都靠它
检索链路：召回数量、过滤条件与重排
召回条数和送进模型的条数不是一回事。召回少了漏答案，送多了挤占上下文还抬高成本。建议先固定召回数量，再用评测集看前几条里有没有正确片段，有则收窄，没有则放宽，别凭感觉拍数字。
- 有明确分类或时间范围的库，优先用元数据过滤把候选集缩小，再走向量检索，比直接调相似度阈值稳得多
- 切片数量上来之后，加一层重排通常比换嵌入模型更划算；重排模型和嵌入模型是两个东西，配置时别搞混
- 验证办法：准备一批真实问题逐条看检索结果，没召回对就回切片环节，别急着改提示词
- 调参顺序记牢：先切片、再召回、再重排、最后才动提示词，倒着调会浪费大量时间
生成环节：让 DeepSeek 只基于给定片段作答
提示词里必须明确三件事：只能依据片段回答、片段里没有就直说不知道、回答末尾标出引用来源。这三条比反复调温度更能压住胡编。上下文拼装时把最相关的片段放靠前，并给每段加编号，模型引用方便，你回溯也方便。
- 兜底分支
- 所有片段相似度都低于阈值时直接返回「未找到」，不要硬让模型编一个答案
- 引用编号
- 每个片段前加序号，要求回答里带上序号，事后能对回原文
- 流式输出
- 接前端前先处理超时和断流，否则用户看到半截答案体验更差
上线前后怎么判断这套系统能用
没有评测集，后面所有优化都是盲调。建一套二十到五十条真实问题的小集合就够用，每次改切片、改召回、改提示词都跑一遍，看命中率有没有退步。关键是分开记录两件事：检索有没有找对片段，模型有没有照着片段答，混在一起看永远定位不到问题出在哪。
- 上线后盯三个指标：单次请求延迟、单次消耗的 token、无答案请求占比，这几项比任何跑分都更能反映真实体验
- 文档要能增量更新，旧版本片段必须清掉，不然新旧内容互相打架
- 准备一个回滚开关，改了检索策略效果变差能马上切回去
- 定期拿线上真实问题补充进评测集，让它跟着知识库一起长
常见问题
DeepSeek 本身能做向量化吗，还是必须另找嵌入模型？
生成和向量化是两件事，DeepSeek 在 RAG 里通常只负责最后组织答案。向量化要单独配一个嵌入模型，选型时优先确认中文效果和稳定性，因为一旦更换，已有向量要全部重建。可先去站内的嵌入模型页面看当时可选项。
文档不多，也要上向量数据库吗？
不一定。几十到一两百条、结构规整的内容，用关键词或标签先筛再交给模型，往往更省事也更好排查。等文档量上去、问题变发散、关键词匹配开始漏召回，再引入向量检索更合适。
回答老是编内容，是模型不行还是我的流程有问题？
多数情况是流程问题：要么检索没召回正确片段，模型只能猜；要么提示词没约束只能依据片段回答。先按「召回对不对、提示词有没有约束、有没有无答案兜底」这个顺序查，换模型通常是最后一步。
