从文档解析到检索增强生成，拆解用DeepSeek搭建RAG应用的完整链路，给出可复用的工程配置与评估方法。 RAG的价值不在于把大模型换掉，而在于让模型在回答前先拿到可靠的外部知识。DeepSeek在中文理解、长上下文和推理成本上具备实用优势，适合作为生成端接入企业文档、课程资料与业务知识库。下面按工程落地顺序拆解一套可复用的搭建方案，重点说明每个环节的配置选择、常见坑和可验证的产出。
1. 厘清RAG链路与DeepSeek的接入位置
搭建RAG应用前需要先把链路拆清楚：离线侧完成文档采集、解析、切分、向量化和入库，在线侧完成查询改写、向量检索、重排、上下文组装和答案生成。DeepSeek主要承担在线侧的生成任务，也可以辅助查询改写和答案校验，但不建议把文档切分、向量化这些确定性工作交给生成模型。DeepSeek API兼容OpenAI风格的调用，base_url可配置为，常用模型是deepseek-chat，温度建议设在0.2到0.4之间，既能保持答案稳定，又保留一定表达灵活性。工程上应把模型调用封装成独立服务，避免检索逻辑与生成逻辑耦合，后续更换嵌入模型或向量库时不必重写生成层。 接入位置确定后，需要为RAG准备一套最小可运行配置。文档侧至少支持PDF、DOCX和Markdown，PDF解析可用PyMuPDF提取文本与页码，DOCX用python-docx保留段落结构，表格内容单独抽成结构化文本，避免直接转成纯文本后丢失行列关系。向量库可先用Chroma做本地验证，数据量超过百万级再迁移到Milvus或Qdrant。嵌入模型可以选择BAAI/bge-m3本地部署，也可以使用兼容的嵌入API，但要注意嵌入维度与向量库索引配置一致。生成端通过DeepSeek的chat接口接收系统提示词、检索上下文和用户问题，返回答案与引用编号。这个阶段的目标不是追求最高精度，而是让一条完整链路先跑通，并能通过日志定位问题发生在解析、检索还是生成环节。 还需要明确DeepSeek在链路中的边界。对于“制度第几条如何规定”这类事实型问题，生成模型应严格基于检索上下文回答，上下文不足时明确说明未找到依据，而不是凭参数记忆补全。对于“对比两份方案差异”这类分析型问题，可以让DeepSeek在检索到的多个片段之间做归纳，但仍要求输出引用来源。工程上建议在系统提示词中固定回答格式，例如先给结论，再列依据，最后标注引用编号，便于前端渲染和人工复核。把接入位置、模型参数和边界规则先定下来，后续的切分策略与检索参数才有稳定的调优基准。
2. 文档解析、切分与向量化入库
文档解析质量直接决定RAG的上限。很多项目一上来就调检索参数，结果发现PDF里的页眉页脚、双栏排版和表格跨页导致文本顺序混乱，再怎么调top-k也救不回来。实际处理时应先做清洗：去除重复页眉页脚、合并断行、识别标题层级，并把表格转成“表名+列名+行数据”的文本形式。对于扫描版PDF，需要先走OCR，再进入文本清洗流程。解析完成后保留元数据，包括文件名、页码、标题路径和更新时间，这些信息在后续引用和权限过滤中都会用到。元数据不要只存在内存里，应随切片一起写入向量库的metadata字段。 切分策略建议采用“结构优先、长度兜底”的。先按标题层级切成语义块，再对超过800 token的块做二次切分，块大小控制在400到600 token，重叠100到150 token，避免答案被切断。重叠不宜过大，否则检索结果重复度高，浪费上下文窗口。每个切片应保留所属标题路径，例如“第三章 数据安全/第三节 访问控制”，这样即使切片脱离原文，嵌入向量仍带有上下文语义。向量化时批量提交，单批不超过64条，记录失败重试。写入向量库时同时建立全文索引字段，后续可采用向量检索与关键词检索混合召回，降低专有名词和编号类查询的漏召率。 入库后要做一次可观测性检查。随机抽取20个切片，人工确认文本是否完整、标题路径是否正确、页码是否可追溯；再用几个典型问题做冒烟检索，观察返回片段是否落在正确文档和章节。如果发现大量切片以“如下所示”“续表”开头，说明解析阶段没有处理好跨页内容，应回到清洗环节修正。向量库的集合命名要带版本号，例如kb_v1，每次调整切分参数后新建集合，避免旧向量污染新索引。对于课程资料或企业制度这类更新频繁的知识库，还要设计增量更新机制，通过文件哈希判断是否重新解析，删除旧切片时按doc_id批量清理，保证检索结果与最新文档一致。
3. 检索、重排与上下文组装
在线检索的第一步是查询处理。用户问题往往口语化或缺少关键实体，直接拿原句做向量检索容易偏离主题。可以用DeepSeek对查询做轻量改写，把“这个报销标准是多少”补全为“差旅费报销标准 住宿费 交通费”，但改写要保留原意，不能引入未出现的时间或部门限定。工程上建议先走规则改写，例如补充同义词和业务缩写，再视情况调用模型改写。检索阶段采用混合召回：向量检索取top 20，关键词检索取top 20，按去重后的候选集进入重排。top-k不宜一开始设得很大，候选过多会稀释重排效果，也会增加延迟。 重排环节建议引入交叉编码器，例如bge-reranker-v2-m3，对候选片段与查询做相关性打分，保留top 5到top 8进入上下文。重排模型对“问题是否真的能被该片段回答”判断更细，能明显压掉关键词命中但语义无关的片段。上下文组装时不要简单拼接，应按重排分数排序，给每个片段加上来源标识和页码，并控制总token不超过模型上下文窗口的60%，为系统提示词和回答留出空间。如果多个片段内容重复，做去重或合并；如果片段来自不同版本文档，优先保留更新时间较新的版本，并在提示词中说明版本冲突。上下文里还可以加入“若依据不足请说明”的约束，减少模型过度推断。 上下文组装完成后要做一次轻量校验。检查候选片段是否覆盖问题中的关键实体，例如问“2024年差旅住宿标准”时，上下文中必须出现年份和住宿费相关表述；如果缺失，应触发二次检索或直接返回“未检索到足够依据”。对于多跳问题，例如“某项目验收需要哪些材料，分别由谁审批”，单次检索可能只覆盖一部分，可以把问题拆成子查询分别检索，再合并上下文。检索日志要记录查询改写结果、召回片段ID、重排分数和最终入选片段，便于后续分析bad case。很多RAG效果问题不是生成模型造成的，而是重排后上下文里根本没有答案，或者答案被无关片段挤掉，因此这一步的可观测性比盲目换模型更重要。
4. 调用DeepSeek生成答案与闭环评估
生成阶段的关键是把提示词写成可执行的约束，而不是一句“请根据资料回答”。系统提示词应明确角色、任务、依据范围和输出格式，例如要求“仅使用提供的上下文回答，每个结论后标注引用编号，上下文不足时说明缺少哪类信息，不要编造条款编号”。用户消息中按“上下文—问题—输出要求”组织，上下文片段带编号和来源，方便模型引用。调用DeepSeek时温度设为0.2到0.3，最大输出token根据场景设置，事实问答可短一些，分析类问题适当放宽。返回结果后做后处理：校验引用编号是否落在实际片段范围内，检查答案是否包含上下文中不存在的数字或条款号，发现异常时降级为抽取式回答或提示人工复核。 评估不能只看“回答像不像”。建议建立三层指标：检索层看召回率和上下文精确率，生成层看忠实度和答案相关性，业务层看人工采纳率和一次解决率。可以用RAGAS做自动化评估，准备50到100条带标准答案和标准依据的问题集，覆盖事实查询、对比分析、条件判断和无法回答四类场景。忠实度重点检查答案中的每个事实是否能在上下文中找到依据，答案相关性检查是否正面回应用户问题，上下文精确率检查入选片段中有多少真正有用。评估结果按问题类型拆分，避免总体分数掩盖短板，例如制度条款类问题召回差，往往需要补关键词索引或调整切分粒度。 闭环优化要从bad case归因开始，而不是频繁换模型。把失败样本分成解析错误、切分断裂、召回缺失、重排误判、上下文超限、生成幻觉和提示词约束不足七类，分别记录修复动作。解析错误回到文档清洗，切分断裂调整块大小与重叠，召回缺失补混合检索或同义词，重排误判换重排模型或调整top-n，生成幻觉加强引用校验和拒答规则。每次调整只改一个变量，用同一套评估集对比前后指标，避免多变量同时变化导致无法判断收益来源。上线后保留用户反馈入口，把“答案有用”“依据不准”“没有回答”三类反馈写回样本池，按月补充评估集。这样RAG应用才能从能跑通走向可维护，DeepSeek的生成能力也才能在可靠上下文之上稳定发挥。
