去年下半年我接手了一个企业知识库 AI 私有化部署项目。老板的需求很直接把我们所有文档喂给大模型员工想问什么就问什么。这个需求听起来简单但真正进入 RAG 落地阶段从模型选型、向量库到框架取舍几乎每一步都是坑。当时团队内部甚至为“到底该不该用 Llama”“要不要上 GraphRAG”吵了好几轮最后沉淀下来六个工程决策。这篇文章就把这六个决策背后的取舍逻辑和实际效果写出来给正在做同类私有化知识库项目的同学一些参考。1. 场景边界先定义“什么不问”再定义“怎么答”1.1 RAG 解决的是“知识新鲜可追溯”不是“会推理”RAG 的核心逻辑是检索增强生成把用户问题转成向量或关键词先从知识库里捞相关片段再把这些片段交给大模型生成答案。企业私有化场景选 RAG最大的动力不是模型变聪明了而是三件事知识库可以随时更新、答案可以溯源到原文、敏感数据不用出内网。单凭这三点RAG 就比微调更适合大多数企业知识库场景。但 RAG 有个天然边界——它不负责复杂推理也不负责“没检索到内容时的自我发挥”。比如员工问“我今年休了 5 天年假还能休几天”如果知识库里只有公司年假制度RAG 搜到制度片段后模型要自己算结果这其实是“检索计算”的组合不是传统 RAG 能一步搞定的。所以我做项目时第一件事不是选技术而是列清楚哪些问题必须答对、哪些问题可以答得模糊、哪些问题直接说“不知道”比硬答更好。这个边界没划清楚后面所有技术选型都是空中楼阁。1.2 什么场景该选 Agentic RAG今年很多团队在聊 Agentic RAG。传统 RAG 是“一次检索 → 直接生成”Agentic RAG 则是让模型自己决定要不要再查一次、要不要调用工具、需不需要追问。比如“帮我对比 Q1 和 Q2 的报销数据”传统 RAG 只能把两段相关文本拼出来Agentic RAG 可以先检索 Q1、Q2 的文档再调用计算工具算出差异。私有化部署选不选 Agentic RAG取决于知识库的复杂度和交互深度。如果只是规章制度问答传统 RAG 足够稳定如果要做跨文档对比、多步分析、甚至带操作动作那就必须把 Agent 能力考虑进架构。注意Agentic RAG 会显著增加延迟和失败率因为多轮检索的每一步都可能出错。我的建议是 POC 阶段先不上 Agent把基础 RAG 跑通再挑几个高频复杂场景做 Agent 化不要一上来就整个复杂体。1.3 三类典型场景的边界划分以我们的企业知识库为例场景分了三类技术路线完全不同场景典型问题技术路线关键指标制度问答报销流程是什么传统 RAG命中率、溯源准确率跨文档分析对比三份合同里的付款条款Agentic RAG多步任务完成率专业建议专利权利要求怎么写RAG 微调 专家规则专业评审通过率这里有个很深的体会很多项目失败不是模型不行而是把三类场景揉在一起期望一套 RAG 解决所有问题。我在第一个决策上花了两周时间访谈业务方把能明确拒绝的、模糊的问题都列出来后面所有选型才有了依据。所以第一个工程决策准确说是“确定不做什么”。2. 模型选型与推理部署别一上来就追 Llama2.1 中文知识库场景的模型选择“Llama 适合国内企业拿来搞知识库问答和私有化 Agent 部署吗”这个问题我们项目里也认真讨论过。结论是能用但未必是最优解。Llama 系列在国际通用任务上很强可国内企业知识库里有大量中文专有名词、政策条文、行业缩写中文效果往往不如国内厂家的开源模型比如 Qwen、GLM 系列。另一个现实问题是 Llama 的社区轮子和企业内部安全策略不一定匹配许可证和商用条款也得仔细确认。我们选模型时定了三条硬指标中文基准测试得分、上下文长度、显存占用与吞吐。对大多数企业知识库问答7B-14B 参数量的模型在主流服务器上就能跑效果基本够用非要追求推理能力72B 级别要四卡 A100 起步成本直接翻好几倍。最后我们选了 14B 级别通义千问配合一套好的检索链路效果比盲目上一个超大模型更稳成本也更可控。2.2 Ollama 能用来做生产吗什么时候该换 vLLMOllama 这几年火得不行零基础教程一搜一大把确实适合本地快速验证。我在 POC 阶段就用 Ollama 拉了一个 Qwen 模型配合 LangChain 跑通了一个简易本地 RAG 知识库整个搭建过程不到半天。但到了生产环境Ollama 的并发吞吐和监控能力跟不上尤其是企业私有化部署常常要对接统一鉴权和日志系统。后来我们换了 vLLM支持 PagedAttention高并发推理稳定多了。具体参数可以参考7B 量化模型在单张 24G 显存的卡上vLLM 并发 32 时延迟还能控制在 2 秒内不量化则建议 32G 以上显存。Ollama 胜在零配置适合开发机vLLM 胜在可控性和吞吐适合线上。如果团队有容器基础我建议生产环境直接上 vLLM不要因为图省事把 Ollama 拿来扛线上流量。2.3 上下文长度与知识库切片的辩证关系现在模型动不动就 128K 上下文很多人会想那我干脆把整个文档塞进去。这是私有化知识库的常见误区。上下文长不代表检索质量高塞进大量无关内容模型反而容易被干扰还会拉高推理成本和时间。我们的实际经验是即便用 128K 上下文的模型检索阶段仍然要把最相关的片段控制在 2-4 个 chunk 内保证生成阶段输入不超过 4000-6000 字。上下文长度是兜底能力不是检索策略的替代品。3. 知识库底座向量库只是起点不是终点3.1 向量库选型从 pgvector 到 Milvus向量库的选型几乎决定了检索链路的底子。我上手时对比了 pgvector、Milvus、Elasticsearch 和 Chroma各有各的适用场景。简单整理如下方案适用规模并发运维复杂度典型场景pgvector百万级中低复用 PG中小知识库、已有 PG 团队Milvus千万级高高大规模文档、高并发检索Elasticsearch百万-千万级高中高已有 ES、需要全文/混合搜索我们最终选了 pgvector 起步因为文档量在百万级以内团队又熟 PostgreSQL。后来并发上来才引入独立的向量检索服务。这里最关键的不是“哪个向量库最强”而是“和现有技术栈契不契合”。企业私有化部署最怕的就是一个系统一个数据库最后运维直接崩溃。从一个团队熟悉的组件起步永远比追新工具稳妥。3.2 关系密集的知识域单靠向量检索会漏我们后来做了一个专利和合同库文本里全是实体关系比如甲方、乙方、关联公司、授权范围。向量检索在这个场景经常会漏召回因为它把一整段文字压成一个稠密向量关系信息是隐性的。GraphRAG、Ontology RAG 这类方案就是把实体和关系显式抽取出来建图检索时不仅能找相似文本还能沿着关系跳转比如“查某公司作为甲方的所有合同”。这对法务、研发、专利场景特别有用。但 GraphRAG 也不是银弹。知识图谱的构建和维护成本很高需要抽准确率和人工校验。我们实际做的是“本体 RAG”的轻量落地只对合同、专利这类结构化程度高的文档建本体和关系日常制度文档仍然走向量检索。这样能把成本控制住又能覆盖关系密集型场景。如果你一开始就全量上 GraphRAG大概率会在标注和抽取上被拖死。3.3 落地姿势向量的粗召回 图的精确跳转最终我们的 RAG 服务里同时保留了向量索引和轻量图谱索引。流程大概是先用向量召回 Top 20 候选片段再通过图谱关系把候选片段扩展成 Top 50最后经过规则和 Rerank 把最相关的 Top 5 交给大模型。这个混合架构不算复杂但对专利对比、条款溯源的效果提升非常明显。对大多数团队我建议别急着上 GraphRAG先把“向量检索关键词重排序”做到位再根据漏召回的具体 case 评估要不要上图谱。4. 检索链路切分、Embedding、Rerank 一个都不能少4.1 切分不是按字数切而是按“语义块”切很多人起步时就是按固定字数切chunk_size500、overlap50我也是这么过来的。这种切法实现最快但效果不稳定经常把一个完整的条款或表格拦腰切断。后来我改用按文档结构切分效果明显提升先按标题、段落、列表识别语义块再对超大块做二次分割。这样每个 chunk 基本是一个完整主题检索命中后给到模型的内容也更连贯。具体参数上我的默认值是 chunk_size 控制在 300-500 字overlap 在 50-100 字。表格数据最好单独切不要拆碎大段 Markdown 表格。如果文档有层级标题把标题拼到 chunk 内容里比如“第 3 章 请假制度 3.2 年假”检索时携带上下文命中率提升很直观。这些细节看起来不起眼但对 RAG 效果的影响比换模型还大。4.2 Embedding 模型与检索策略Embedding 模型的选择直接决定召回质量。中文场景我测试过 bge-m3、m3e、text-embedding 系列最终线上用 bge-m3。它对中文长文本和多语言支持好还支持稠密稀疏混合编码。这里有个坑Embedding 模型一定要和检索链路一起评测不能只看公开榜单分数。我们试过一个榜单很高的模型在专利术语上反而把同义词分得很散生成答案的质量明显下降最后换回 bge 才稳住。检索策略上只做向量检索是不够的。企业知识库里有大量编号、型号、人名这些精确词用关键词检索更准。所以我的方案是向量检索 BM25 并行召回再合并结果。这个策略在 RAG 里很经典实现成本不高但对 hit_rate 的提升非常明显。如果你发现某个问题偶尔答不上来先去看看是不是关键词没进去。4.3 Rerank 的意义从 hit_rate 到实际答案质量衡量 RAG 检索质量最常用的是 hit_rate 和 MRR。hit_rate 表示正确答案是否在召回结果里但即使答案在里面排序不对也会影响生成效果因为大模型会被靠前但不相关的片段带偏。Rerank 的作用就是把召回结果重新排序让最相关的片段排到最前面。我们用的 Rerank 模型不大单卡甚至 CPU 都能跑但效果立竿见影。我的标准实践是三步走召回用向量BM25 拿 Top 50Rerank 从 Top 50 里选 Top 5再拼接给模型。召回阶段尽量宽保证 hit_rate精排阶段尽量准保证生成质量。对私有化部署来说这个链路可以拆成两个独立服务后续单独替换哪一层都不影响其他部分。Rerank 是整套 RAG 链路里性价比最高的投资没有之一。5. 工程框架与 API 设计选型比写代码更重要5.1 LangChain、Spring AI、LlamaIndex 怎么选我们团队以 Java 为主也有 Python 服务所以当时在 LangChain、LangChain4j、Spring AI 之间纠结了很久。LangChain 生态丰富但版本迭代快Python 团队用起来顺手Java 团队用 LangChain4j 或 Spring AI 更合适。后来我的结论是框架没那么重要抽取的抽象层才重要。我们自建了一个 RAG 服务把检索、重排、生成、追踪封装成标准接口底层具体用 LangChain 还是自研代码随时可以换。很多人喜欢跟着框架走但框架迭代频繁经常破坏 API线上项目一旦用了某个版本升级成本很高。我的建议是POC 阶段随便用框架生产环境尽量让核心逻辑自己掌控框架只做胶水层。如果团队全是 JavaSpring AI LangChain4j 组合可以快速起步但一定要留好替换点不要把所有逻辑绑死在框架 API 上。5.2 私有化部署的接口约定与权限透传私有化部署和公有云最大的区别是必须跟企业的统一身份认证打通比如 SSO、LDAP。RAG 服务的接口设计至少要考虑三点聊天接口要带用户上下文、检索接口要按用户权限过滤、知识库文件接口要记录操作日志。比如普通员工不能搜到 HR 内部的薪酬文档这个权限判断必须在检索之前做不能等大模型生成后再过滤否则可能把敏感信息拼到答案里。我们定义了一套最小接口集/chat支持流式、/search调试用、/documents上传和更新、/feedback收集反馈。每个接口都透传 user_id 和 dept_code权限策略统一在一个拦截器里处理。这个设计后来被好几个系统复用算是私有化知识库最有价值的抽象之一。接口层多花一天设计后面能省掉很多返工。5.3 生产环境的三件事流式、超时、遥测企业用户对对话体验的耐心很低接口不支持流式输出等 5 秒没反馈就觉得系统崩了。所以/chat必须支持 SSE 流式。另外 RAG 链路涉及多个服务必须设置超时和重试。我们早期没做超时控制向量库一慢大模型请求全部排队最后所有聊天都卡死加了熔断和超时才解决。我的经验值检索服务 300ms 超时模型服务 5s 超时重试最多一次避免级联雪崩。遥测方面至少要把每个请求的耗时、命中的文档 ID、生成的 tokens、用户反馈记录下来。这些数据既能排查问题又是后续优化检索链路最宝贵的素材。用 OpenTelemetry 做链路追踪成本低收益大私有化部署也建议标配。别等到线上出问题才去想日志怎么查。6. 效果评估与持续治理没有度量就没有优化6.1 建立评测集把 hit_rate 和答案准确率分开看RAG 上线前一定要先建评测集。我们从真实用户提问里挑了 200 条分成三类简单事实题、多文档对比题、无标准答案的主观题。每条问题都标注了正确答案所在的文档 ID。然后离线跑检索链路统计 hit_rate 和 MRR再让大模型生成答案请业务方打分。很多团队只看 hit_rate但其实 hit_rate 只代表“有没有找到”不代表“答得对不对”。两套指标分开看才能定位问题到底出在检索层还是生成层。我的经验是初期先把 hit_rate 做到 85% 以上再优化答案质量。如果命中率低Rerank 做得再好也没意义如果命中率还行但答案依然差问题多半在提示词或者 chunk 里上下文不足。评测集不是做一次就完了每次调整模型或参数都要跑一遍这应该成为 RAG 项目的固定流程。6.2 知识库更新的三种机制企业知识库不是静态的制度、合同、产品资料都在持续变化。我们在私有化部署里梳理了三种更新机制全量重建、增量 upsert、定时同步。全量重建最简单适合低频更新增量 upsert 需要处理内容变更和删除复杂度高但资源消耗小定时同步则是数据源侧通过消息队列推送变更。大部分企业一开始不需要做实时增量每天凌晨全量重建一次足够稳定。有个很容易踩的坑增量更新时旧的 embedding 向量如果没删干净检索会一直命中过期内容。我们后来在文档元数据里加了 version 和 updated_at检索前先过滤掉过期版本问题才解决。如果你选增量更新一定要把“内容删除”这个操作纳入设计不能只做新增和修改。6.3 上线后的迭代节奏灰度、反馈闭环、知识库治理上线不是结束而是优化的开始。我建议先用 10% 的流量灰度观察日志和反馈一周再逐步放量。每次调整切分参数、Embedding 模型、Rerank 阈值时都跑一遍评测集做对比不要凭感觉上线。聊天界面里可以加“点赞/点踩”按钮把用户反馈自动回流到评测集。这个闭环一旦跑起来知识库质量会持续提升。另外一定要设一个“知识库管理员”角色专门负责文档入库、标注和答案质量抽检。技术能解决检索问题但知识本身的对错必须靠业务方维护。很多企业把 RAG 项目当成纯技术项目上线后没人管知识库三个月后效果断崖式下跌这就是治理缺位的代价。如果让我重来一次我会在启动时把第一个场景边界决策做得更细因为它决定了后面五个决策的走向。第 4 节的检索链路优化是性价比最高的投入切分和 Rerank 一改效果就能上一个台阶。说到底RAG 私有化部署真正的护城河不是某一个模型而是评测集和知识治理机制这两样东西越积累越值钱。