在数据不出内网的前提下，使用DeepSeek模型配合检索增强生成与向量数据库，完整搭建可溯源、可评测的本地知识库。 本地知识库的核心不是把文档直接塞给大模型，而是让模型在回答前先检索到可信片段，再基于片段组织答案。对教育机构、企业培训部门和咨询团队来说，课程讲义、制度文件、项目复盘往往分散在网盘、邮件和共享目录中，直接问答容易出现答非所问或编造内容。搭建一套可落地的DeepSeek本地知识库，需要把模型运行、文档治理、检索链路和评测运维连成闭环，下面按实施顺序展开。
1. 运行环境与模型选型。
搭建前先确认硬件边界和模型版本。若以部门级知识库为目标，单张24GB显存显卡可运行DeepSeek-R1-Distill-Qwen-7B的4bit量化版本，适合二三十人以内并发；14B或32B蒸馏模型更适合复杂问答，但32B通常需要48GB以上显存，DeepSeek-V3满血版则涉及多机多卡，不适合普通团队起步。推理框架可选Ollama做快速验证，也可用vLLM提升吞吐，配套的嵌入模型建议选bge-m3或bge-large-zh-v1.5，重排模型可用bge-reranker-v2-m3，向量库在Qdrant、Milvus和Chroma之间按数据规模取舍。 环境准备要围绕“模型服务与知识库服务分离”来做。把DeepSeek推理服务部署在内网GPU服务器，通过OpenAI兼容接口暴露给编排层；编排层可选择Dify、RAGFlow或LlamaIndex，负责文档解析、切分、索引和问答流程。这样后续更换模型或调整切分策略时不必重做全部工程，也便于把嵌入模型和重排模型放到独立服务中做压力隔离。 模型选型不要只看参数规模，还要看回答风格与业务匹配度。制度问答强调引用准确和拒答边界，7B模型配合高质量检索往往比大模型裸答更稳；课程内容生成则需要更强语言组织能力，可把14B或32B模型用于复杂问题，再设置路由把简单问题交给小模型。上线前应记录每个模型的显存占用、首字延迟和每分钟请求数，形成可复用的容量基线。
2. 文档治理与向量索引。
知识库效果的上限由文档质量决定。先把PDF、Word、PPT、Markdown和网页归档按业务域分类，扫描件用PaddleOCR或MinerU做版面识别，表格尽量保留为Markdown结构，标题层级、页码、生效日期和所属部门要写入元数据。对制度文件还要保留版本号和废止状态，避免旧版内容被检索出来；对课程讲义则要标记章节、讲师和适用人群，为后续权限过滤和引用展示打基础。 切分策略要兼顾语义完整和检索粒度。中文文档可按512至800个token切分，重叠80至120个token，标题和表格说明尽量与正文绑定，避免把一条制度拆成失去主语的碎片。索引阶段用bge-m3生成向量并写入Qdrant的HNSW索引，数据量达到千万级时再评估Milvus的分布式方案；同时建立BM25关键词索引，形成向量检索与关键词检索的混合召回，解决专有名词、编号和缩略语召回不稳的问题。 元数据不是装饰，而是权限和溯源的基础。每个切片应携带文档ID、部门、密级、版本、生效日期和原文位置，检索时先按用户权限过滤候选集，再把候选片段送入重排模型。实践中常见错误是只做向量相似度而忽略元数据过滤，导致低权限用户通过语义相近的问题命中受限内容；正确做法是在检索入口完成ACL过滤，提示词只负责组织答案，不能承担权限控制职责。
3. 检索增强问答链路。
问答链路按“改写问题、混合召回、重排、生成、引用”的顺序落地。用户问题先做指代消解和关键词扩展，例如把“这个政策还能用吗”补全为具体制度名称和当前日期；召回阶段同时取向量Top20和BM25 Top20，合并去重后交给重排模型选出Top5至Top8片段。重排阈值要结合业务校准，低分片段宁可触发拒答，也不要让模型在无关内容上硬答。 生成提示词要明确约束回答范围和引用格式。系统提示中要求模型只依据给定片段作答，每个结论后标注文档名称、版本和页码，片段不足时说明“现有资料未覆盖”，并给出可转人工的方向。DeepSeek模型对中文指令跟随较好，但仍需在提示词中限定输出结构和拒答条件；对数值、日期、责任部门等关键字段，可在生成后做规则校验，发现引用片段与答案不一致时降级为摘要式回答。 链路搭建还要考虑并发和缓存。常见做法是把高频问题的检索结果做短时缓存，文档更新时按文档ID失效；对长文档问答可先做章节级摘要索引，再进入片段级检索，减少上下文长度。教育场景中，学员问题往往围绕同一课程反复出现，缓存命中率较高，配合流式输出能明显改善体验。整个链路应保留检索日志、重排分数和最终引用，便于后续定位是召回问题还是生成问题。
4. 评测、权限与持续运维。
上线前要建立小规模但稳定的评测集。从真实业务中抽取100至300条问题，覆盖直接事实、跨文档对比、时间版本和无法回答四类，记录召回命中率、引用准确率、拒答率和平均响应时间。每次调整切分、嵌入模型或提示词后跑同一套评测，避免凭主观感受判断效果；对错误样本要归因到文档缺失、切分不当、召回失败或生成越界，形成可追踪的改进清单。 权限和审计要贯穿运行期。文档入库时写入部门、密级和可见角色，检索服务按用户身份过滤；管理后台保留文档上传、索引重建、模型切换和问答日志，敏感问题可追溯到具体片段和操作人。文档更新采用增量索引，旧版本标记失效但保留审计记录，防止历史答案与现行制度冲突；对高频访问和低评分答案设置人工复核入口，让业务老师参与知识校准。 运维重点在容量、版本和反馈闭环。监控GPU显存、检索延迟、重排耗时和错误率，按并发增长提前扩容；模型或嵌入模型升级时先在影子环境跑评测集，再灰度切换。业务侧每周汇总未命中问题和低分回答，补充文档或调整切分规则，使知识库从“能问答”逐步过渡到“答得准、可追溯、能维护”的稳定状态。
