手把手：用开源大模型搭一套数据不出内网的本地知识库问答

这两年我被问得最多的一个问题，不是“哪个模型最聪明”，而是“我们公司这些文档，能不能在本地自己搭一个问答系统，数据不出去？”。答案当然是能。今年开源模型的能力和推理框架都成熟到了一个甜点区间：一台带几张显卡的服务器，甚至一台高配工作站，就能跑起一套完整的检索增强生成系统。这篇就把我自己反复搭过、也给客户落地过的这套流程，从选型到调优，完整拆解一遍。文章面向有一定工程基础、但还没亲手做过检索增强的同学。

一、先想清楚：我们到底在解决什么问题

大模型直接问文档，有两个绕不开的毛病：一是它记不住你内网那几百上千页的私有资料，二是它会一本正经地编造。检索增强生成的思路很朴素：别让模型“凭记忆答题”，先把相关资料从你的文档库里捞出来，塞进提示词里，再让模型基于这些材料作答。模型负责组织语言，知识库负责提供事实，这样答案既贴你的业务，又可溯源。

所以一套系统拆成五块：文档解析与切块、向量化、向量存储、检索、生成。前四块都是为最后一步“把对的材料喂给对的模型”服务。很多人一上来就纠结用哪个大模型，其实对这类私有问答，检索的质量往往比模型大小更决定成败——材料捞错了，再强的模型也答不对。

二、模型与组件怎么选

本地大模型这一步，今年的选择已经很舒服。如果你只是做企业内部问答、对中文要求高，可以选开源的通义千问、DeepSeek 这类在中文语料上表现好的模型；想极致省资源，就用量化后的小参数模型。推理框架上，追求简单快速上手用 Ollama，一条命令就能把模型跑起来；要上生产、要高并发，就上 vLLM，吞吐和延迟都好得多。

向量化用的嵌入模型别用太大的，专门的中文嵌入模型效果就够，关键是和你的语种、领域匹配。向量库选型上，小规模演示用 Chroma 或者 FAISS 就够了，零依赖、纯本地；一旦文档量到百万级、要支持多租户和权限，再迁移到专业的向量数据库也不迟。我的经验是：先把链路跑通，性能问题等真遇到再优化，别在第一天就过度设计。嵌入模型和生成模型最好分开选，别图省事用同一个模型包办一切——一个擅长理解检索、一个擅长组织表达，各司其职效果才稳。

三、最容易被忽视的环节：切块

真正拉开差距的，是文档怎么切。很多人图省事，按固定字数硬切，结果一段合同条款或者一段代码被拦腰截断，检索出来的全是半句话。我的做法是：先按文档的天然结构切——章节、标题、表格边界，再在这个基础上控制每块的长度，并让相邻块保留少量重叠，避免一句话的上下文被切断。

举个真实的例子：我曾把一份几十页的产品手册直接按五百字硬切，上线后用户问“某型号的保修期限是多久”，系统每次都答得含糊。翻日志才发现，保修期那一行正好被切在两块的接缝上，单独捞出哪一半都不完整。后来改成按条款切、并把同一条款强制放在同一块里，问题立刻消失。这种坑不会报错，只会悄悄拉低答案质量，所以一定要拿真实业务问题去测，而不是跑通一个“你好”就以为万事大吉。

表格和图片是另一个坑。PDF 里的价格表、参数表，直接抽文本往往糊成一团。正经做法是先把表格单独识别、还原成结构化文本再入库；实在没条件，至少要把表格所在的段落标注清楚。我见过太多“系统答非所问”，追根溯源都是入库时文档就已经被解析坏了。这一步多花的功夫，后面能省十倍的调试时间。

四、检索与生成：让答案更靠谱

检索环节，建议同时保留关键词检索和向量检索两路，结果融合后再排序。纯向量检索在精确术语、编号、人名上经常漏召回，纯关键词检索又理解不了语义，两路并走是最省心的折中。再给召回的结果按相似度打个分、设个阈值：分数太低的问题，宁可老实回答“知识库中没有相关信息”，也别让模型硬编。

生成阶段，提示词要写得足够约束：告诉模型“只能依据下面提供的材料回答，材料里没有就明说不知道”，并要求它在答案后附上引用了哪几段。这样用户一眼就能判断答案靠不靠谱。我一般还会在前端把引用的原文片段高亮出来——可溯源，是企业内部系统能不能被信任的底线。

给一个可直接套用的最小闭环，方便你照着跑通：先用解析库把 PDF、Word、网页抓成干净的纯文本；按章节和长度切成带重叠的块；用嵌入模型把每块转成向量存进 Chroma；用户提问时，把问题也转成向量，取相似度最高的三五块，再拼进提示词模板里交给本地模型。整个链路跑通其实只要几百行代码，真正花时间的是后面把它从“能跑”磨到“好用”。

五、上线之后：别以为搭完就结束了

真实使用里，你会发现总有那么几类问题答得不好。这时候别着急换模型，先去看日志：是材料没捞到，还是捞到了却没被用上？把这些 bad case 攒起来，针对性地调整切块策略、补充缺失文档，比盲目换一个更大的模型有效得多。检索增强系统是个需要持续喂养的系统，上线只是开始。

成本上也要有个数。本地部署的好处是数据不出内网、长期边际成本低，但前期的硬件、运维投入是实打实的。如果你的文档量不大、查询频次不高，其实把开源模型跑在一张消费级显卡上就够用，不必一上来就堆服务器。把钱花在刀刃上，先服务好最痛的那几个场景。

最后提醒一个容易踩的坑：权限。公司文档是分级的，不是每个员工都该看到所有内容。理想的做法是在检索环节就按用户身份做过滤，而不是先全量捞出来再让模型挑——那样等于把敏感材料已经送进了提示词。做企业内部系统，权限这件事必须从第一天就设计进去，事后补代价极大。把解析、切块、检索、生成、权限这五件事都做扎实，你的本地知识库问答，才算真正能交给同事日常使用，而不是一个演示完就吃灰的玩具。

检索增强生成的精髓，不是堆一个最强的模型，而是把对的资料、在对的时间、以对的形式送到模型面前。工程做扎实了，普通开源模型也能交出让人信任的答卷。