企业官网建设流程全解析

先说我自己的结论：做了三个企业级RAG落地项目之后，我越来越觉得，市面上一大半的Demo级方案，拉去生产环境就是灾难。RAG本身不复杂，但“能跑通的RAG”和“能扛住生产环境的RAG”，中间隔着数据治理、检索质量、工程稳定性、效果度量这四座大山。这篇文章把我这几次落地过程中的判断、踩坑、架构取舍和度量方法都写出来，给正准备从Demo走向生产的团队做参考。

1. 先泼盆冷水：Demo能跑通，和生产能扛住是两码事

1.1 Demo阶段的“惊艳”大多是假象

我第一次做RAG POC的时候，效果惊艳到我怀疑人生。拿了几十篇内部制度文档，随便问几个问题，答案不仅准，还能给你标出引用来源。老板看完当场拍板：这个项目可以上。我当时也这么觉得。

但回头复盘那段Demo，其实充满了“幸存者偏差”。Demo知识库只有几十份文档，还都是我亲手挑过的、格式规整的Word和PDF。提问的人是我自己，问的问题我都大概知道答案在哪篇文档里。说白了，那是一次“开卷考试”——检索的任务难度极低，系统只要做到把相关段落排进前几名，LLM就能“照着抄”出正确答案。

等真正到了生产环境，我发现用户根本不会按照你预设的方式提问。同一台设备的故障，有人问“为什么机器报警”，有人问“设备异响怎么处理”，有人问“这个报警代码是啥意思”，指代、口语、错别字全都有。文档也从规整的Word变成了扫描件、Excel表格、PPT、甚至只有图片的说明书。检索难度直接翻了几倍，Demo阶段那些“灵光一现”的调参技巧全都不好使了。

1.2 从“跑通”到“扛住”，隔着的不是一点半点

我复盘这三个项目，发现Demo方案和可落地方案之间，差的不只是某个组件，而是整个设计理念。这里列个清单，大家可以对号入座：

这个表可能有些抽象，我举个具体的例子。Demo阶段我做的是向量相似度top-5召回，没有任何重排，准确率看起来还行。到了生产环境，知识库扩大到十万级文档，同样的检索策略，Hit Rate直接从Demo时的85%掉到了60%不到。不是向量检索本身不行，而是数据规模上来之后，相似的干扰片段成倍增加，top-5里全是“看起来有点像但根本不是答案”的内容。这时候你要是不改架构，光靠调prompt，天花板就在那儿摆着。

1.3 生产环境的“隐形需求”比你想的多

很多人做RAG只盯着“检索+生成”这一段，忽略了生产环境特有的隐形需求。我概括一下，大概有这么几类：

第一类是可观测性。生产环境里用户问了一个问题，系统给了错误答案，你得能复盘：到底是因为检索没召回，还是LLM生成时没参考检索结果？没有全链路日志，这种问题只能靠猜。第二类是权限与安全。企业知识库里大量文档是有密级的，不是所有人都有权限看到所有内容。不少Demo方案直接一个向量库全量灌进去，问谁都能查，这在企业环境里就是合规事故。第三类是容灾。向量数据库挂了怎么办？索引重建要多久？生产库没有备份的情况下误删了某个分区，怎么恢复？这些问题在Demo阶段没人考虑，到了生产环境都是事故级别的。

我把这三个项目里最核心的坑和对应的解法拆开写，下面每一节都会落到具体操作上。

2. 三个项目踩出来的坑：90%的Demo方案死在这些地方

2.1 文本切分：切得“太聪明”，反而把语义切碎了

文本切分是RAG里最不起眼、但影响最大的环节之一。Demo阶段大家最喜欢干的事，就是拿一个固定 chunk_size 比如500个字符，加一点overlap，完事。跑起来效果还行，因为文档少、主题集中。

第一次做生产项目时，我天真地以为要把切分做得“智能”一点，于是上了语义切分模型，想按语义边界把段落切出来。结果在制造业设备手册上翻了大车。设备手册里大量内容是分步骤的：第一步、第二步……很多步骤在语义上是衔接的，但被语义切分模型识别成不同的主题，硬生生拆开了。用户问“更换滤芯的完整流程”，检索回来的片段只有“第一步到第三步”，后续步骤根本不在上下文里，LLM给出的答案自然缺胳膊少腿。

后来我把切分策略改成了“结构感知切分 + 兜底固定窗口”。核心思路很简单：先用文档本身的层级结构（标题、章节、步骤列表）作为切分边界，优先保证一个完整的结构化单元不被切开。如果某个单元太大，超过模型上下文窗口，再用固定窗口二次切割，并保留足够的overlap。实际效果立竿见影，环境项目里的Hit Rate从62%提到了78%。

关于切分参数，我给一个参考值，但强调一下这真的需要按数据调：chunk_size在300到800字之间需要测试，overlap一般设为chunk_size的10%到20%。我当时用的配置是chunk_size=512，overlap=64，这两个值在我们数据上表现最好。你在自己项目里最好跑一组对比实验，别照抄。

还有一个容易被忽略的点：切分后的chunk必须保留元数据，至少包括来源文档ID、章节路径、页码。Debug的时候你就知道这有多重要了。

2.2 Embedding选型：通用模型在领域词汇面前基本靠蒙

第二个坑是Embedding模型选型。第一个项目我们图省事，直接用了一个通用中文Embedding模型，在标准测试集上表现不错。结果一上线就发现，设备型号、故障代码、工艺术语这些词，检索效果惨不忍睹。举个例子，用户输入“ALM-407”，这是特定设备的一个报警代码，通用模型给它算出来的向量，和真正描述这个报警的文档片段向量之间的距离，居然比和一堆无关文档的距离还大。原因也不难理解：模型训练时根本没见过这种稀有的、纯字母数字组合的领域词汇，自然学不出有区分度的表示。

这里有两个解法，按成本从低到高排列：

第一个解法是在不换模型的前提下做查询增强。具体做法是在检索前加一个“术语归一化”的步骤：维护一份领域词典，把用户提问里的口语表达、简称映射到标准术语，再把标准术语和原始问题拼接起来一起做向量检索。比如用户问“机器嘎嘎响”，词典里映射到“异响”，然后同时检索“机器嘎嘎响”和“异响”的向量。这个方法零训练成本，能解决一部分问题。

第二个解法是直接训练或微调领域Embedding模型。如果公司预算允许，收集领域相关的query-文档配对数据，在通用模型基础上做继续预训练或对比学习微调。我们在第二个项目里就是这么干的，用了几万条合规问答对做微调，新模型在领域测试集上的Recall@10提升了12个百分点。注意，微调的数据量不用特别大，关键是要“领域相关”，几万条高质量数据比几十万条低质量数据有用得多。

另外一个实战经验：不要把所有的Route都交给同一个向量。我们后来在生产环境采用混合检索，向量检索负责语义相似，BM25关键词检索负责精确匹配。像“ALM-407”这种报警代码，BM25直接按精确字符匹配就能找到，根本不依赖向量质量。多了一条路之后，系统整体检索效果稳了很多。

2.3 检索链路：只做top-k相似度，就是裸奔

第三个坑，也是我踩得最深的一个：以为向量召回top-5就算检索完成，直接丢给LLM生成答案。早期Demo这么做没问题，因为文档少、答案明显。生产环境文档一多，top-5里开始混入大量视觉上相似但语义偏离的片段，LLM看到这些错误上下文，生成出来的答案不仅不准，还特别“自信”，言之凿凿地错。

后来我全面改成“查询改写 → 混合检索 → Rerank → 上下文精排”四段式检索链路。这里不展开讲全部，重点说两个效果最明显的环节。

查询改写指的是在真正检索之前，先用一个小模型或LLM对用户问题做扩展：提取关键词、消除指代、补全口语缺省。比如用户问“它坏了怎么办”，系统先根据对话历史把“它”指代的设备识别出来，然后把“设备X故障处理”作为检索query，而不是直接用原始问句。这一步很土，但极其有效。

Rerank就是重排，这是整个链路里性价比最高的一环。向量召回阶段可以多召回一些，比如top-50，然后交给一个交叉编码器（cross-encoder）Rerank模型，把候选片段逐对和query计算相关度，重新排序，最后取top-5作为LLM上下文。实测下来，光加一个Rerank，生产环境Hit Rate提升了10到18个百分点不等。Rerank模型资源消耗大一些，但因为只对50个片段排序，延迟增加控制在100毫秒以内，完全值得。

2.4 知识库不是垃圾桶：入库管道的质量决定了检索的天花板

第四个坑是我最有感触的：大家把太多精力放在检索和生成上，却很少有人认真对待“入库”这一端。RAG这条链路上，检索效果的上限在知识库的质量。你往库里放垃圾，检索出来的也是垃圾，Rerank再强也只能从垃圾里选相对不垃圾的。

生产环境里最常遇到的数据类型有这么几种：扫描版PDF、Excel表格、PPT、图片型说明书。先说扫描版PDF，这种文档没有文本层，必须走OCR，而且OCR出来的文本还经常带错别字和乱码。我们当时的处理策略是：OCR之后建一个“清洗规则列表”，把常见的OCR误识别模式（比如把“0”识别成“O”）用正则批量修正。再说Excel表格，直接把整张表切碎往向量库里丢，效果很差。图表的正确做法是：把表格转成Markdown或JSON结构，再按行和列语义组织成若干描述性句子。比如“设备A的工作温度是-20℃到60℃”，而不是把原始表格贴进去。

关于“RAG知识库能不能存储图片”这个问题，被问过很多次。答案是能，但要想清楚存的是什么。图片本身存入向量库的意义不大，除非你做多模态检索，否则真正有用的是图片的理解结果。我们的做法是：把图片交给多模态模型（比如视觉语言模型）生成结构化描述，再把描述文本和图片路径一起存起来，检索命中的时候优先返回文本，必要时附上图片路径给前端展示。这样既避免了向量库被图片二进制撑爆，又保留了视觉信息。

最后一个入库层面的坑，就是知识割裂。企业内部知识通常是散落的：同一个设备，维修手册在A系统，故障案例在B系统，备件清单在C系统。把它们切碎后都灌进一个向量库，相互之间没有任何关联，用户问“这个故障该换什么备件”，检索系统要跨越多个知识源才能拼出完整答案。这个问题的解法我在后面的“本体与GraphRAG”小节再细说，这里先记住一个结论：入库阶段就要给不同来源的知识打上统一的实体标签，没有实体关联的知识孤岛，检索能力再强也白搭。

3. 企业级RAG的架构长什么样：从“能跑”进化到“能扛”

3.1 文档入库管道：解析、清洗、切分、向量化四步走

生产级的RAG系统，一定有一个完整、可追踪的入库管道。我们最终沉淀下来的管道分为四步：

第一步是解析。不同类型的文件走不同的解析器：Word和PDF走文本提取，扫描件走OCR，Excel走结构化读取，PPT取每页文字和备注。解析之后统一转成Markdown格式，方便下一步处理。手工清洗文档这件事，真的比你想象的重要。我当时给自己定了一个原则：入库管道里必须有至少一道“人工抽检”环节，每批次随机抽5%的解析结果人工检查，宁可入库慢一点，也别把烂数据灌进去。

第二步是清洗。解析出来的文本往往带着页眉页脚、导航目录、乱码字符。清洗阶段的核心目标是去掉这些噪声，识别文档结构的边界。这里我强烈推荐一个本地化的文本拆解工具思路：用正则+文档结构特征做一个轻量的清洗器，比一上来就用大模型清洗要可靠且便宜。大模型清洗适合做语义层面的合并和纠错，正则负责处理高频模式，两者配合效率最高。

第三步是切分。前面提过的结构感知切分，具体落地可以分这几步：先按标题层级把文档拆成“章节块”，再对超大章节按段落边界二次切分，最后给每个chunk打上元数据标签。切分的结果统一存两份，一份是原文chunk，一份是专门用于检索的“浓缩版”（比如用LLM把chunk压缩成包含关键实体的摘要），检索时用浓缩版向量，生成时引用原文。这个方法我们叫“双份索引”，效果不错。

第四步是向量化与入库。每个chunk经过Embedding模型产出向量，写入向量数据库，同时把原文、元数据和向量三者关联。向量数据库选型上，小规模项目用pgvector就够了，靠PostgreSQL自带能力，省去多维护一套中间件；数据量上了百万级，建议上Milvus或专门的向量服务，毕竟检索性能和运维成本摆在那里。

3.2 检索增强链路：查询改写、混合检索、Rerank、引用溯源

对应入库管道，检索侧也要有一条完整链路。我把它分为五个环节：

查询改写是第一步。前面提过，用户问题往往口语化、有指代。线上系统做的查询改写包括：实体识别（把问题里的关键实体提取出来）、指代消解（结合对话历史消除“它”“这个”）、关键词扩展（把同义词加入检索词）。这一步我们用了一个小参数模型配合规则模板，延迟在毫秒级。需要说明的是，query改写不是必须用大模型，小模型加规则在大多数场景下更稳定可控，成本也低很多。

混合检索是第二步。把改写后的query同时送进向量检索和BM25关键词检索，各取top-N，然后做结果合并。合并的策略我们用过简单拼接，也用过RRF（Reciprocal Rank Fusion）加权排序，后者效果好一些，因为能兼顾两个召回通道的排名信息。召回数量建议设置得大一点，向量和BM25各出50条，为后面的Rerank留下充足的候选空间。

Rerank是第三步。交叉编码器逐对计算query和候选片段的相关性，这一步精度远高于双塔式向量召回。我们用的开源Rerank模型，单条query处理50个候选片的耗时大约60到90毫秒，对于大多数企业内部场景可以接受。Rerank后取top-5作为最终上下文。

第四步是引用溯源。生产环境必须做到：每个生成答案里的关键句子，都能追溯到具体的知识库片段。实现上我们在prompt里要求LLM在生成时对关键句标注引用标记，同时在系统层面把检索片段的文档ID、标题、页码嵌入引用元数据。这一步有三个目的：对用户负责（他能自查）、对审计负责（出了问题能追责）、对调试负责（哪个环节错了能定位）。

最后一个环节是兜底策略。如果Rerank之后所有候选片段的相关度分数都低于某个阈值，就不要硬着头皮让LLM回答。系统应该返回“未找到相关信息”并给出建议提问方式。这一步在Demo阶段容易被忽略，但在生产环境非常重要——它决定了系统是“诚实的不知道”还是“一本正经地胡说八道”。我们最终设置的阈值是相关度分数低于0.45时触发兜底，这个值需要拿标注样本调，不能拍脑袋。

3.3 生成与校验：LLM不是复读机，也不是垃圾桶

检索质量上去了，生成环节也不能拖后腿。生产环境里LLM生成踩过的坑，大概有三类：

第一类是“复读机”问题。LLM面对检索回来的上下文，有时候会逐字逐句照抄原文，导致答案冗长、没有组织。解决方法是prompt里明确要求：“基于上下文信息，组织一段精炼的回答，不要直接复制原句，用自己的话概括关键信息。”如果发现复读问题仍然严重，可以检查是不是检索片段本身太长、噪声太多，这时候需要进一步压缩上下文。

第二类是“幻觉”问题。检索回来的片段明明没有某条信息，LLM却凭训练时的记忆脑补了出来。生产环境里解决幻觉不能只靠prompt，必须在系统层做校验。我们的做法是：对LLM生成的答案做“引用校验”——答案里的关键信息点（实体、数字、结论）要能在引用片段里找到支撑，找不到就标记为低置信度，要么重新生成，要么降级为兜底回答。

第三类是格式要求。企业场景经常要求结构化输出：JSON、Markdown表格、固定字段的摘要。这里有个经验：不要直接在总prompt里塞输出格式要求，最好做一个格式模板层，在用户query到达生成模块时，把格式模板显式地嵌入prompt。这比让LLM自己“领会”要稳定得多。

生成侧的选择上，如果公司有私有化部署要求，我们通常在70B级别以下的开源模型里选，兼顾中文能力和部署成本；如果允许调用云端API，直接用商业大模型，效果会好不少。关键是把“检索质量”作为重点投入方向，因为生成效果的天花板很大程度由检索上下文决定。

3.4 工程化落地：部署、监控、容灾与备份，一个都不能少

这部分是我强烈建议每个做RAG的团队都认真对待的，因为Demo方案死在工程化上的比例，远比死在算法调参上的比例高。

部署方面，我们最终是用Kubernetes跑的整套系统。这里有一些踩坑经验：检索服务和生成服务的资源画像完全不同，向量检索是CPU密集、内存敏感，LLM推理是GPU密集，要把它们拆成不同的Deployment，独立水平伸缩，而不是揉在一个Pod里。还有，向量数据库和LLM服务的Pod要配置独立的资源配额和反亲和性调度，避免同一节点资源争抢导致P95延迟飙高。K8s环境里最常见的生产故障，比如节点资源不足导致Pod被驱逐、网络策略误配导致服务间调用超时，我们基本都遇到过。提前做好资源监控和Pod调度策略，能省掉半夜被oncall叫醒的痛苦。

监控方面，至少要有五个核心指标：检索延迟、生成延迟、整体端到端延迟、召回命中率（用日志里的引用标记反推）、以及上下文命中率（用户对答案的反馈，比如点赞点踩）。我们当时用Prometheus+Grafana做监控面板，检索服务和生成服务各自上报trace，出现问题先从trace定位是检索链路还是生成链路，效率高很多。

容灾备份这块是被忽视的重灾区。生产库没有备份的情况下误删数据，是每个运维的噩梦。我们的做法是：向量数据库每日全量备份+增量备份，索引文件定期导出到对象存储；文档原始文件（知识库源头）做版本管理，任何一个chunk都能追溯回源文档和历史版本。这样即使向量索引坏了，重建管道通常只需要几十分钟。数据库恢复这件事，我强烈建议你在搭建RAG系统的第一天就把备份机制做了，而不是等出事了再想办法。等出事再想，大概率就是丢掉之前几周的全部知识库数据和标注记录。

高可用方面，检索服务至少两个副本，生成服务如果用的开源模型，可以部署多副本做负载均衡，并辅助一个简单的重试机制。需要保持一个原则：RAG系统里，数据库和LLM都是依赖项，任何一个环节挂掉，都应当让系统优雅降级——比如LLM挂了但检索正常，就返回检索到的原文摘要让用户自行阅读；向量库挂了但BM25可用，就退回纯关键词检索模式。生产环境不追求“永不故障”，追求的是“出了故障影响可控”。

4. 效果怎么度量：别再拿“感觉还行”糊弄自己

4.1 检索质量的核心指标：Hit Rate、Recall、MRR怎么算

做RAG最怕的就是“效果验收靠感觉”。Demo阶段你还可以拍着胸脯说“看起来不错”，生产环境你必须有数字支撑。检索侧我建议至少盯三个指标：

Hit Rate也叫命中率，含义是“在检索返回的top-k结果中，是否包含标准答案所在的片段”。它的计算方式是把测试集中的每个问题，检索top-5或top-10，然后看答案片段在不在里面。这是最直观的指标，我们要求生产环境对标达到75%以上才算达到可用线。

Recall@k衡量的是答案被召回的比例。如果一个问题对应标准答案有3个片段，top-10召回了2个，Recall就是2/3。这个指标反映了检索的全面性，对于多跳类问题尤为重要。

MRR（Mean Reciprocal Rank）衡量的是答案排名的质量。标准答案排在第一位得1分，第二位得0.5分，第三位得0.33分……取所有问题得分的均值。它比Hit Rate更严格，因为即使答案在结果里，排在第五位对整体效果意义也不大。加上Rerank之后MRR的提升通常非常显著，这也是我推荐Rerank的原因之一。

这里给一个我们项目里的实测对比：纯向量检索，Hit Rate@5大概在62%；加上BM25混合检索，提高到70%；再加上Rerank重排，Hit Rate@5到了84%。MRR从0.46一路涨到0.71。这些数字在不同项目里会有浮动，但提升趋势是稳定的。

4.2 评估集怎么建：从用户真实问题里挖，而不是自己编

构建评估集（Eval Set）是整个RAG项目中技术含量被低估的一环。很多人为了省事，让开发同学自己编几十个问题，再人工标注答案片段。这种评估集的问题在于：开发同学编的问题往往是自己心里有标准答案的“简单题”，跟生产环境真实用户的刁钻问题完全不是一回事。

正确的做法是把线上日志里的真实用户查询捞出来，按类型做分层采样，比如：单一事实类、多跳推理类、否定/排除类、口语化查询类、跨文档聚合类，每类至少取50条。然后找业务专家或知识库作者对每个问题标注标准答案片段，必须精确到具体chunk的ID。这里有个注意事项：标注答案片段的时候，最好让标注者“盲标”——只给定原始文档集，不要提前看检索结果，否则容易先入为主。

评估集不是一次性产物，要持续维护。每次知识库更新、检索策略调整、模型升级，都要跑一遍评估集做回归对比。我们当时定了一个规矩：任何改动如果让评估集上的Hit Rate或MRR下降超过2个百分点，就必须回滚或重新调参，不允许“感觉还行先上线”。

4.3 线上反馈闭环：不追踪Badcase，优化就是闭眼开车

评估集是离线验证，线上还需要一套反馈闭环。生产环境里最直接的质量信号是用户的点赞/点踩，但这个信号太稀疏，而且用户通常懒得点。我们实际依赖的是两类数据：第一类是答案引用率，即生成答案时实际使用了几个检索片段、分别是谁；第二类是追问率，用户在收到答案之后多久会再问一次，如果频繁追问，很可能说明答案没解决他的问题。

我们内部搭了一套简单的“Badcase日报”：每天从日志里随机抽200条用户提问，自动标注出那些触发了兜底回答、或答案置信度低的记录，然后统一人工复查。每周出一份Badcase分析报告，归类成“检索错位”“上下文缺失”“生成幻觉”“用户提问异常”等几个类型。Badcase收集的时间越长，你对系统的改进优先级就越清楚。比如我们发现一段时间里大量问题集中在“跨文档聚合”类型，就知道应该优先投入GraphRAG或知识关联的建设。

这套反馈闭环，配合离线评估集，才构成了一个“可度量、可回归、可持续优化”的完整循环。

5. 三个落地项目的复盘：同样的配方，不同的坑

5.1 项目一：制造业设备运维知识库

第一个项目是某制造企业的设备运维知识库，知识来源包括设备说明书、维修手册、历史故障工单、备件清单，一共大约8万份文档。这个项目踩的坑前面已经提了不少：语义切分切碎了步骤、通用Embedding对设备型号检索乏力、纯向量召回在十万级文档场景下命中率惨淡。

最终落地的架构是：OCR加清洗规则处理扫描件，结构感知切分加“原文+浓缩版”双份索引，检索链路用BM25+向量混合召回加交叉编码器Rerank。上线后Hit Rate@5从最初的62%提到84%，用户满意度调研从“能用”变成了“基本好用”。这个项目给我最大的教训是，制造业文档里大量的型号编码、故障代码本身就是强标识符，这类信息靠关键词匹配比靠语义向量靠谱得多，混合检索在这种场景是刚需而非锦上添花。

另外一个经验是领域词表的建设要前置。我们在项目中期才开始整理设备术语、故障代码、备件名称的映射词典，导致前期大量的评估标注工作重复做了一遍。如果重来一次，我会在项目启动第一周就拉着业务专家梳理领域词典。

5.2 项目二：金融合规文档问答

第二个项目是金融领域的合规文档问答系统。知识库规模不大，只有大约2万份合规制度、监管发文和内部流程文档，但有一个致命特点：知识的时效性极强，监管规则频繁更新，旧的文档和新的文档可能内容冲突。

这个项目的核心难点是版本管理和时效性。用户问“现在的开户流程是什么”，系统必须把旧流程文档屏蔽掉，只参考最新版本。我们最终引入了“文档有效期元数据+版本优先级”机制：每一份文档入库时标注生效日期和失效日期，检索阶段对快照做过滤，只保留当前有效的版本；如果同一主题存在多个版本，版本优先级高的文档在Rerank评分里加权。

金融场景对引用溯源的要求极高。我们在这一套系统里把“答案级引用标注”做到了极致：每个回答的每一句关键结论都对应一个可点击的引用，点进去能直接看到原文段落、发文机构和生效日期。这让合规团队愿意试用，因为他们可以自查答案的依据。生产环境里很多RAG项目推进不下去，就是卡在“没人敢为错误答案负责”这一关，引用溯源一旦做好，这个顾虑会大幅缓解。

5.3 项目三：企业内部流程与制度助手

第三个项目是企业内部通用流程与制度助手，面向全公司员工，知识库涵盖了HR制度、财务报销流程、差旅规定、IT服务目录等，数据量约3万份文档，同时接入了企业内部系统的一些结构化数据。这个项目是典型的Java技术栈环境，我们用了LangChain4j来编排RAG流程。这里顺带说一句，如果你所在的团队以Java为主，不要因为RAG生态里Python内容多就强行换技术栈，LangChain4j的RAG模块完整度已经足够支撑生产级项目，包括文档加载、切分、向量存储、检索器和提示模板。

这个项目的独特挑战是权限隔离。不同部门的员工，能看到的制度范围不同。我们最终用“权限标签过滤”来解决：每个chunk入库时打上部门权限标签，检索时先从用户身份解析出权限集合，然后在向量检索和BM25检索阶段都做权限过滤，再从候选集中做Rerank。注意权限过滤必须前置到召回阶段，如果等Rerank之后再做权限过滤，很可能出现top-N里没有一条用户有权查看的，系统只能兜底，体验很差。

项目里还有一个有意思的发现：员工提问的“口语化”程度比我预想的高得多。“报销发票丢了怎么办”“出差回来多久必须报账”这类问题，直接拿去做向量检索效果很差，但经过查询改写（识别意图、映射到“发票丢失处理流程”、“差旅报销时限规定”这类标准问法）之后，Hit Rate提升了十几个点。所以我愈发觉得，查询改写模块在面向大众用户的企业内部系统里，是性价比最高的优化点之一。

6. 下一步：从RAG走向Agentic RAG，以及GraphRAG和本体能补什么

6.1 RAG的瓶颈到底在哪

做了三个项目之后，我对RAG的瓶颈有了比较清楚的认识。简单的“检索-增强-生成”管线有三个天花板：

第一个是多跳推理能力弱。用户问“A设备的故障会导致B产线停多久”，这需要把“A设备与B产线的关系”和“A设备故障的平均修复时间”两段知识拼起来，中间还夹着推理。简单的单次检索只能拿到其中一段。第二个是知识割裂问题。知识分散在不同系统、不同文档里，如果没有实体层面的关联，向量检索很难把跨源知识聚合起来。第三个是工具使用能力缺失。企业环境里有大量结构化数据存在数据库、接口里，用户问“这个月报销总额是多少”这类问题，纯靠文档检索是答不出来的，必须调用API或查询数据库。

6.2 Agentic RAG：什么时候该上、工具怎么拆

Agentic RAG（智能体RAG）的核心思路是把“一次检索+一次生成”变成“多轮规划+多次检索+工具调用”的循环。模型不再是被动地接收上下文然后生成答案，而是扮演一个智能体，自己决定需要检索什么、调用什么工具、如何验证结果。

什么情况下值得上Agentic RAG？我的判断标准是：如果用户问题里超过20%需要多跳推理或需要查结构化数据，就值得投入。纯文档问答场景上Agentic RAG是过度设计，不仅延迟翻倍，还引入更多的不可控因素。

Agentic RAG的工具拆分，我建议按“最小可用”原则来做，先只拆三个工具：文档检索工具（封装混合检索+Rerank）、结构化查询工具（封装SQL查询或API调用）、计算/聚合工具（用于数据统计与推理）。每个工具要有清晰的参数说明和返回格式。当时我们在第三个项目里试点Agentic流程，处理“报销类”问题效果很好——模型先调用结构化查询工具拿到报销数据，再调文档检索工具拿制度条款，最后综合生成答案。但要注意，Agentic RAG需要更强的模型才能稳定规划，如果用的开源小模型，建议还是老老实实走标准RAG管线，别追求花活。

6.3 GraphRAG与本体：解决知识割裂的另一条路

最后聊聊GraphRAG和本体（Ontology）RAG。简单RAG把文档切碎后丢失了实体之间的关联，而GraphRAG通过构建知识图谱，让“实体-关系-属性”结构显式地参与检索，天然能解决跨文档聚合和知识割裂问题。

我个人的经验是：GraphRAG不适合在所有项目里硬上，它适合那些实体关系密集、知识高度关联的场景。比如制造业里“设备-故障-备件-工艺”的关系网络，就非常适合用图结构组织。而纯规章制度类知识，实体关系相对简单，GraphRAG带来的收益有限，投入产出的性价比不如先把Rerank和查询改写做好。

本体（Ontology）建设更是如此。我们第三个项目尝试过为内部制度体系建设一个轻量本体：组织、流程、制度、角色这几个实体类型，加上“隶属于”“适用于”“流程包含步骤”等关系，配合标签体系做检索增强。实际效果是帮助Rerank阶段更好地理解上下文之间的关系，但对整体指标的提升幅度较小，大约3到5个百分点。这个提升放到动辄百万级的知识库里，依然值得做，但如果你的项目还在从零搭建、连基础检索质量都没达标，我建议先把基础打牢，再考虑本体和GraphRAG这些进阶方案。

最后分享一点个人体会

三个企业级RAG项目做下来，我最想跟同行说的一句话是：不要迷信Demo，也不要把“先进架构”当成目标。RAG落地是个系统工程，文本切分、Embedding选型、混合检索、Rerank、数据治理、权限隔离、监控容灾、效果度量，每一环都有实打实的坑。与其花大量时间追逐最新架构，不如把自己手头数据的质量做扎实，把检索链路的基础打好，先把Hit Rate做到可用水平，再谈Agentic、GraphRAG这些进阶方向。工具和模型迭代很快，但数据治理和工程化的基本功，永远是这类项目最值得投入的部分。