1. 聊清楚需求再做技术选型很多人一上来就问“RAG 框架用哪个好”我通常都会反问他一句你的知识库到底要解决什么问题这个问题的答案直接决定了后续所有技术选型的方向比任何框架对比都重要。1.1 企业级 RAG 和“个人知识库”本质上是两码事我之前见过不少团队把个人知识库那套玩法直接搬进企业场景结果处处碰壁。个人知识库的核心诉求是“帮我自己找到我写过的东西”数据量撑死几万条检索错了也无所谓我自己能判断。企业级知识库完全不是这个逻辑它有几个个人场景根本不会遇到的硬约束权限体系必须嵌入检索链路一个普通员工不应该检索到 HR 的薪酬文档这种过滤不是“搜完再删”而是必须在检索阶段就按权限范围预过滤。RAG 项目里最容易翻车的就是这里——你辛辛苦苦把检索准确率做到 90%结果漏了一条用户本不该看到的记录信任直接归零。数据的召回质量直接影响业务决策知识库里的答案会被拿去写方案、做报价、判断合同风险答错了不只是“体验不好”而是实实在在的经济损失。知识库是动态的不是一次性导入就完事企业文档每天都在新增、修改、下线增量更新和版本管理是常态需求不是锦上添花。所以选型之前先把这些业务约束列清楚。技术选型本质上是业务约束的翻译业务上需要什么技术就选什么。1.2 我们当时的需求清单是怎么列出来的拿我之前做的一个真实项目举例客户是一家有几千员工的科技公司要做内部知识库覆盖的产品线有四条核心需求拆下来是这样一张清单需求项具体描述对选型的影响数据规模起步 50 万篇文档预计一年内翻两倍决定向量库和检索引擎的容量规划权限控制按部门、项目组、文档密级三级管控决定是否必须用带成熟 RBAC 的检索引擎检索精度高频问题 Top-5 命中率目标 85% 以上决定是否必须引入重排模型引用溯源每个回答必须带出处文档和段落决定分块策略和检索结果的元数据结构更新频率每天新增/修改约 3000~5000 篇文档决定增量索引管道的设计响应时间检索接口 P95 小于 2 秒决定混合检索的链路复杂度和重排候选数量部署环境私有化部署不能出内网决定所有模型必须用开源的或本地化的这张表列完基本就知道该选什么了私有化部署 开源模型 成熟检索引擎 重排层 增量管道这就是大方向。我们后面所有的技术选型都是拿这张表去对照而不是看哪个框架在 GitHub 上星多。2. 检索架构的核心决策从向量库到混合检索检索是整个 RAG 知识库的骨架。LLM 只是“嘴巴”检索才是“眼睛”。很多项目最后效果不好八成问题不在模型而在检索。2.1 为什么最后选了 Elasticsearch 而不是 Milvus聊这个之前先同步一下背景免得大家觉得我在瞎推荐。我们当时用半个工作日做了召回准确率的对比测试数据量是 68 万篇文档每篇平均 1800 字总 token 大约 1.1 亿。测试指标只盯两个Top-20 召回率和首条命中率。先说 Milvus 这一路。它本身的向量检索性能在千万级数据下确实猛这点我不否认。但在 68 万这个量级上它的优势完全发挥不出来反而暴露了三个问题向量检索结果和业务元数据是割裂的。用户问“2024 年 Q3 华南区的服务台故障率是多少”Milvus 只能给你“语义上相近的段落”至于这些段落满不满足“2024 年 Q3”“华南区”“服务台”这些条件它是不知道的只能靠召回后自己在业务层过滤。召回 200 条再过滤过滤完可能就剩 5 条准确率波动得非常厉害。元数据过滤条件很多是组合式的Milvus 的标量过滤性能和 ES 不在一个量级。增量更新的问题。我们内部文档更新频率不算极端但每天也有几千篇新增和修改Milvus 需要自己管理 embedding 的更新状态、删除状态这在工程上是一堆隐形工作。ES 的方案就顺很多。常规的keyword text dense_vector三字段映射配合filter参数做业务条件的预过滤再用script_score或者rrf把全文检索分值和向量分值融合。RFF 在 ES 8.8 之后就已经是稳定功能了不需要自己写复杂的分值归一化逻辑。有一说一在 68 万这个量级ES 的召回质量和 Milvus 的差距基本可以忽略但工程复杂度低了一大截。长期来看这个选择也撑得住。我们后来把知识库容量从 68 万扩到了 200 万篇ES 在单集群 18 个数据节点的配置下P95 检索延迟仍然能压在 1.5 秒以内。作为对比同规模下如果用 Milvus还得多维护一套元数据存储和一套数据同步管道光这个运维成本就够喝一壶的。2.2 分块策略从 512 到 1024再到按结构切分分块这事看着简单其实最体现工程的细活。我们一开始用的是固定窗口 512 token不带重叠。上线之后发现两个问题长段落被拦腰截断比如一个合同条款被切成了两半检索时只召回后半段模型根本回答不了前因后果。固定不重叠的分块导致语义边界漂移同一个意思的表达散落在两个块里召回结果经常是“半句话”。后来改成 1024 token、128 token 重叠情况好了不少但紧接着又踩了第二个坑纯粹按 token 切分还是会破坏文档结构。于是我们最终改成了结构感知切分根据 Markdown 标题层级、合同编号、条款序号做第一轮分段确保每个块内有完整的语义单元。第二层再按 token 限制做截断超长的块从段落边界处切开而不是硬切。对于表格类内容保留 Markdown 表格原样不拆成散落的行否则模型回答“对比一下这季度和上季度的毛利”这种问题时根本找不到对齐的数字。这里我特别想提醒一点重叠值不是越大越好。128 token 重叠意味着每 1024 token 的块里实际只有 768 token 是独立的存储膨胀接近 26%。我们实测过 256 重叠召回率提升不到 1%但存储和检索延迟都明显上去了。所以别盲从“重叠越多越准”的说法选 10%~15% 的重叠率性价比最高。2.3 召回策略的“三重门”这里说的“三重门”不是花活就是每次查询必须依次经过的三层召回每一层都要有数据落盘方便后面调优。第一层关键词检索BM25。把用户问题拆成 termES 的multi_match配合minimum_should_match控制宽松度。这一层专门兜底冷门实体、产品型号、内部缩写这类字面匹配的场景。第二层向量检索。用 query 的 embedding 走dense_vector的HNSW索引取 Top-50。第三层混合精排。BM25 的结果和向量结果通过 RRF 融合取 Top-20 进入重排阶段。重排模型我们选的BAAI/bge-reranker-base刚开始用的 v1 版本。v1 在下游任务上成绩不错但有一个很头疼的问题——对 512 token 以上的长文本效果衰减得非常快。后来换成了 bge-reranker-base-v2把 query 和 doc 拼接后送进模型长文本场景好了很多。这里注意一下重排阶段不是全量文档都跑模型只对 RRF 之后的 Top-20 跑所以 latency 是可控的。我们压测过在 CPU 上跑 bge-reranker-base-v220 条候选大概 80ms 左右完全可以接受。最后还有一层兜底的用户反馈采集。检索结果返回后我们会记录“用户最终是否采纳了这条结果”具体做法是前端在搜索结果下面埋点“点赞/点踩”点踩的结果会进入负样本池隔周用这批负样本重新评估重排模型的效果。这个小机制看着不起眼但对后期持续优化非常关键后面第 4 节会细说。3. 服务化与工程落地的几个关键选择3.1 为什么用 FastAPI 而不是 LangChain 的一体化封装很多人一上来就用 LangChain 的RetrievalQA链觉得方便。我也理解但真实项目里我强烈建议用 LangChain 做流程编排可以别让它直接持有业务逻辑。我们最终的服务形态是这样的KnowledgeBaseAPI (FastAPI) ├── /api/retrieval // 纯检索返回带 score 的候选 ├── /api/chat/stream // 问答接口支持 SSE 流式输出 ├── /api/feedback // 用户采纳/未采纳反馈 └── /v1/ingest // 文档写入异步任务化LangChain 只用在/api/chat/stream内部负责把“检索 → 拼 Prompt → 调用 LLM → 流式输出”这一段串起来。至于文档入库、索引重建、反馈数据落库全部自己写。为什么因为 LangChain 的抽象层太重你一旦想把自定义逻辑塞进它的 Chain 里调试成本直线上升。我们初期就用 LangChain 的RetrievalQA跑通了 demo但后来加“引用溯源”“拒答逻辑”“追问澄清”这些业务能力时发现它的抽象反而成了枷锁最后还是拆出来自己写。再说服务化的一些基础设施。我们用 FastAPI Uvicorn 提供 HTTP 服务SSE 走流式传输前端可以一个字一个字地蹦出来。文档入库接口设计成了异步任务文件先传到对象存储再发一条 MQ 消息Worker 进程负责解析、切分、embedding、写库。这样做的直接好处是大量文档并发写入时不会拖垮在线检索服务。3.2 向量化的生产注意点Embedding 这件事单看效果大家都差不多但生产环境真正要命的是稳定性和降级策略。我们用的是开源 embedding 模型BAAI/bge-large-zh-v1.5部署成独立的 embedding 服务通过 HTTP 调用。有几个点必须提前想清楚超时和重试批量写入文档时如果 embedding 服务偶发抖动会导致一批 1000 条数据只写了一半这种场景必须配套重试队列。批量大小我们实测 GPU 上 bge-large 一次 batch 32 是性价比拐点再大吞吐提升有限但显存占用直线增加。缓存策略同一个文本块重复 embed 是很浪费的我们对md5(文本块)做了一层缓存测试阶段跑重复数据时速度提升明显。降级方案如果 embedding 服务挂了检索接口不能跟着挂。我们在线上的降级策略是如果向量检索不可用自动退回 BM25multi_match检索保证用户还能搜到东西只是相关性差一些。混合检索还有个容易忽略的点query 的 embedding 和文档的 embedding 必须用同一个模型、同一个版本。我们曾经踩过坑因为升级了某个 embedding 模型版本导致线上老向量没法直接用最后不得不全量重出向量。所以 embedding 模型的版本管理一定要纳入发布流程不是改个配置就完事。3.3 流式输出的细节与“引用溯源”落地企业知识库问答最刚需的功能其实是引用溯源——用户要的不是一个“自信的答案”而是“凭什么这么答”。所以我们当时把引用溯源做成了硬性指标每条回答后面必须附上来源文档编号和引用段落。实现上不复杂关键在于两点检索阶段拿到的 Top-20 候选我们不会全塞给 LLM而是取重排后的 Top-5 进 prompt要求 LLM 在回答时标注这些候选的编号例如“根据[S3]和[S7]的条款……”。输出层做一层后处理把 LLM 标注的编号映射回真实的文档 ID 和段落链接拼到 SSE 流的末尾。这个功能上线后用户对系统的信任度提升非常明显。有个真实的反馈是“以前模型说啥我都不敢信现在能看到它读的是哪一段心里踏实多了。”所以如果你的 RAG 知识库还没做引用溯源我建议直接提上优先级。3.4 流式请求下的幻觉控制幻觉这事RAG 解决了一部分但解决不了全部。我们在企业场景里观察到即使检索结果完全正确LLM 依然可能根据自己的“知识”自由发挥。后来我们加了三道防线Prompt 硬约束在 system prompt 里写死“如果检索内容不足以回答问题直接回答‘基于现有资料无法回答’禁止推测”。拒答阈值重排模型最高分的分值如果低于阈值我们定的是 0.35直接走拒答分支不调用生成。引用完整性校验LLM 输出的引用编号必须在给它的 Top-5 候选中存在否则该句会被过滤换成“未找到直接依据”。第一版上线时我们只做了前两道结果发现很多用户反馈“回答太机械了明明一句话能说清的事非说不知道”。后来把第三道校验加上之后效果平衡了很多。幻觉控制不是越严格越好要在可用性和可信度之间找平衡点。4. 评测体系与“喂数据”的持续优化闭环4.1 从 0 到 1 建评测集的思路很多团队做 RAG 项目最大的问题不是模型不行而是没有评测集说不清楚哪里不行。我们一开始也掉进过这个坑——工程师凭感觉调参调了两周也不知道是变好了还是变坏了。后来我们用一个月时间建了一套评测集规模不大但足够覆盖业务场景类别数量示例流程制度类120“报销审批流程是什么”产品参数类90“A 系列设备的最大负载是多少”合同条款类80“逾期交付的违约金怎么计算”事故报告类60“2024年3月华南区服务台事故原因”拒答类不该答的50“这个项目负责人私人电话是多少”这 400 条评测集来自三个渠道真实用户日志里的高频问题、业务方提供的“必答清单”、以及我们主动构造的边界问题故意模糊、故意跨文档。每条评测都标注了预期答案的关键点不要求 LLM 一字不差但必须击中关键点才算过。评测跑起来之后我们每天都会跑一次全量回归。任何一次 embedding 模型升级、切分策略调整、prompt 修改都必须先过评测集再上线这个机制保证了后续所有优化都是可量化的。4.2 用户反馈的“负样本回灌”机制前面提到前端埋了点赞/点踩这个数据不能只是看看得真正反哺到系统里。我们的做法是两周一个迭代点踩样本拉出来先做聚类找出“高频踩”的主题大概率是某个文档没进库、或者某个类型的问题检索策略不对。针对高频踩的主题人工去补评测集把这个场景加进去变成一条新的评测用例。同时把点踩的 query 作为“隐式负反馈”加入 BM25 的词典权重调整或者作为 reranker 的微调负样本候选。这套闭环跑起来之后我们从第 3 个月开始就能很清楚地看到检索准确率的周维度改善曲线而不是一直靠拍脑袋调参。说实话这可能是整个项目里性价比最高的一块投入。4.3 常见评测指标的陷阱做 RAG 评测的坑也不少简单讲三个我们踩过的Hit Rate 的“虚高”Hit Rate 只代表“正确的 chunk 是否出现在 Top-k 里”不代表回答质量。我们见过 Hit Rate 95% 但用户满意度很低的案例原因是 Top-k 混了大量相似但不精确的片段生成阶段选错了上下文。只看召回不看重排Top-20 召回再好重排差也能毁掉整个体验。所以评测必须拆成两段召回阶段看 RecallK重排阶段看 MRR 和 NDCG。评测集过拟合评测集数量多了之后调参会开始“背题”。我们每个月都会从真实日志里抽取新问题加入评测集淘汰掉已经过时的旧问题保证评测集本身在“流动”。这几点做下来不敢说我们的 RAG 是行业标杆但至少在团队内部我们每次改动都能说出“变好了 3 个点”还是“变差了 2 个点”——这是以前做不到的。5. 最后想说的几句大实话RAG 不是模型竞赛。对于企业知识库这种场景基础模型能力只要够用就行比如 Qwen 系列效果和成本都很稳真正决定体验的是数据治理、分块策略、检索链路和评测闭环。我们后期甚至发现把 embedding 模型从 bge-large 换到别的更大的模型评测集得分提升不到 0.5%但推理成本涨了一倍多。知识库不是一个“搜索框 模型”就完事了。文档的生命周期管理权限、版本、下线、知识的维护机制谁负责更新、多久更新一次同样重要。我们上线半年后最大的瓶颈已经不是技术而是知识库里的内容开始陈旧这时候 RAG 再准也白搭。有条件就上 Agentic RAG但不是为了炫技。我们第二期引入了简单的 Agentic RAG 能力当检索不到答案时Agent 会主动改写查询、拆解问题、尝试多跳检索。实测下来在“跨文档对比”和“多条件组合查询”这两类问题上回答成功率提升了大概 15%。但注意这建立在评测闭环已经跑通的基础上——如果你连基础 RAG 的评测都还没建好直接上 Agentic RAG 很容易失控。最后分享一个小经验。做企业级 RAG 最忌讳的就是“一步到位”总想着一步跨到完美的架构。现实是从 BM25 起步到混合检索再到 Agentic RAG是一个渐进的过程每一步都踩在数据反馈上才走得稳。希望这篇思路对正在做选型的朋友们有帮助。