deepseek rag 搭建，一次讲清做法、成本和注意点的实操细节和替代方案

看完 RAG 原理文章，真正动手时还是会卡：文档怎么切、向量模型选谁、检索回来答不对怎么调、账单怎么估算。这篇按搭建顺序把动作列出来，每一步说清做什么、怎么判断做对了，以及哪几种情况根本不该走这条路。

看完 RAG 原理文章，真动手还是会卡：文档怎么切、向量模型选谁、检索回来答不对怎么调、账单怎么估。这篇按搭建顺序把动作列出来，每一步说清做什么、怎么判断做对了，以及哪几种情况根本不该走这条路。

前提是有基础：会写脚本、能调 HTTP 接口、懂向量检索在做什么。按下面五节顺序做，先跑通一段纯文本再谈优化。每一步都给了「怎么算做对了」，做不对就退回去，别往下堆功能。

先搭骨架：一条请求走完的最小链路

链路拆成五个函数：文档入库、问题向量化、召回 top-k、拼 prompt 调 DeepSeek、带引用返回。先只塞一份短文档，端到端跑通一次，再往里加语料。骨架不通就调切片，出了问题分不清是检索错还是拼装错。

1. 写五个函数并串起来入库函数输入文件、输出切片列表；查询函数输入问题、输出带引用的答案。验证标准：问一个文档里明写的短问题，答案能对上且引用片段编号正确。
2. 先按结构切片，不调参按标题或段落切，长度控制在能完整表达一个意思的范围。切完人工抽 10 条看有没有被腰斩的句子、有没有把表格拆散。
3. prompt 里写清约束明确「只依据资料回答、找不到就说找不到」，并要求输出引用片段编号，方便回溯到原文核对。

向量模型和存储怎么选，别绕远路

嵌入模型和生成模型要分开选：嵌入负责召回质量，DeepSeek 只负责组织答案。检索不出来的内容，换生成模型也救不回来。先定嵌入模型和存储，再调生成端。

• 数据量小先上本地文件加内存向量索引，够用就别急着部署数据库
• 要上数据库时，到 /tools 里的数据库与工具目录挑候选，比完再选
• 换嵌入模型等于重建全部索引，选型时先想清楚后面会不会换
• 检索质量先用手工构造的问题集验证，别等上线才发现召回不对

成本怎么估，哪些地方在偷偷花钱

成本分三块：文档入库的一次性嵌入开销、每次提问的嵌入加召回、送给 DeepSeek 的上下文 token。第三块最容易被低估，因为召回条数直接放大输入 token，很多人上线后才发现账单大头在上下文。

• 先定一个偏小的 top-k，答不准再加，不要反过来
• 把每条召回片段的长度打日志，算清一次问答平均送进去多少上下文
• 文档入库成本只在首次和更新时发生，别用它做日常成本估算
• 单价随厂商和时段会变，到 /official-api/providers/deepseek 看当时的数字
• 用 /tools/model-cost-calculator 按自己的日问答量换算成月口径

估算时按峰值问答量算，不要按平均值算，否则流量上来会超预算。到上面两个页面核对当时单价和换算结果，再决定索引规模和 top-k。

答不准时的排查顺序

答不对别急着改 prompt，按召回、拼装、生成三段倒着查，每段只看一个问题。顺序错了会越调越乱，因为改动互相覆盖。

回归用固定问题集，别凭单次观察下结论。每次改动后同一批问题结果对比，变好才保留。这条不适用于问题本身含糊的场景，那种情况要先让用户澄清。

什么情况下这套方案不适用

RAG 不是所有问答的默认解。下面几种情况，硬上索引的维护成本可能超过收益，换路线更划算。

资料高频变动、要求秒级一致

索引和原文容易脱节，先评估用实时查询接口代替索引

问题以精确查数、算账为主

直接查数据库或调 API 比语义检索可靠得多

资料本身不含答案、靠推理得出结论

先整理资料或换更长上下文的推理路线，而不是堆检索

替代路线没有绝对好坏：实时数据多就走查询接口，推理类问题就走更长上下文，纯结构化统计就走 SQL。等需求稳定下来再决定要不要补一层语义检索。