企业官网建设流程全解析

1. 聊清楚需求，再做技术选型

很多人一上来就问“RAG 框架用哪个好”，我通常都会反问他一句：你的知识库到底要解决什么问题？这个问题的答案，直接决定了后续所有技术选型的方向，比任何框架对比都重要。

1.1 企业级 RAG 和“个人知识库”本质上是两码事

我之前见过不少团队，把个人知识库那套玩法直接搬进企业场景，结果处处碰壁。个人知识库的核心诉求是“帮我自己找到我写过的东西”，数据量撑死几万条，检索错了也无所谓，我自己能判断。企业级知识库完全不是这个逻辑，它有几个个人场景根本不会遇到的硬约束：

• 权限体系必须嵌入检索链路：一个普通员工不应该检索到 HR 的薪酬文档，这种过滤不是“搜完再删”，而是必须在检索阶段就按权限范围预过滤。RAG 项目里最容易翻车的就是这里——你辛辛苦苦把检索准确率做到 90%，结果漏了一条用户本不该看到的记录，信任直接归零。
• 数据的召回质量直接影响业务决策：知识库里的答案会被拿去写方案、做报价、判断合同风险，答错了不只是“体验不好”，而是实实在在的经济损失。
• 知识库是动态的，不是一次性导入就完事：企业文档每天都在新增、修改、下线，增量更新和版本管理是常态需求，不是锦上添花。

所以选型之前，先把这些业务约束列清楚。技术选型本质上是业务约束的翻译，业务上需要什么，技术就选什么。

1.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）。把用户问题拆成 term，ES 的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-v2，20 条候选大概 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 项目，最大的问题不是模型不行，而是没有评测集，说不清楚哪里不行。我们一开始也掉进过这个坑——工程师凭感觉调参，调了两周也不知道是变好了还是变坏了。

后来我们用一个月时间建了一套评测集，规模不大，但足够覆盖业务场景：

这 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 召回再好，重排差也能毁掉整个体验。所以评测必须拆成两段：召回阶段看 Recall@K，重排阶段看 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，是一个渐进的过程，每一步都踩在数据反馈上，才走得稳。希望这篇思路对正在做选型的朋友们有帮助。