企业官网建设流程全解析

做了三个企业级的RAG落地项目之后，我对网上那些光鲜亮丽的RAG Demo越来越警惕。不是Demo本身没价值，而是绝大多数Demo方案在设计时只回答了一个问题——“这样能不能跑通”，却完全没回答生产环境真正在乎的问题：数据量涨100倍还能不能扛？并发上来会不会雪崩？知识库每天更新时召回会不会劣化？业务方拿错误答案来投诉时你有没有日志可以甩锅？这篇文章不聊怎么快速搭一个漂亮的知识库Demo，而是基于我这三个项目的实际经历，拆解RAG系统从Demo到生产环境之间那道真正的鸿沟，希望能让准备上生产的团队少走弯路。

1. 三个项目做完，我总结的「死因」清单

先说说背景。这三个项目分别是：某企业的内部制度问答系统，文档量大概十几万份；一个面向客户的智能客服助手，对接的是商品手册和售后政策，内容持续在更新；还有一个偏平台性质的文档问答服务，需要支持多个业务线各自上传私有资料。三个项目走的是同一条路——先做Demo给业务看效果，效果不错，然后开始推生产，结果在推的过程中暴露出完全不同的一堆问题。

1.1 Demo与生产环境的差距到底在哪

我用一个表格总结过这两者的本质区别，现在分享出来：

Demo能跑，是因为所有风险都被环境掩盖了。数据量小的时候，召回乱一点也能靠大模型兜底；没有并发，也就不存在超时和资源争抢；没有权限控制，自然也不需要过滤逻辑。一旦上生产，这些被掩盖的问题会集中爆发。

1.2 三个项目暴露的共性问题

三段项目过后，我整理出几个高频率“死因”，基本所有失败都能归到这几类：

第一，检索质量的隐性崩塌。用Demo那套固定切分、单一向量检索的方式，在数据量变大、文档类型变杂之后，召回结果会肉眼可见地变差。而且这个问题不是突发的，是慢慢劣化的，等到业务反馈“最近怎么老答错”的时候，已经影响用户体验很久了。

第二，持久化与向量库运维经验缺失。很多人用chromadb或者faiss本地文件跑Demo，到了生产要面对向量副本、索引构建、容量规划、备份恢复这些问题，完全措手不及。

第三，大模型生成层的失控。生产环境下用户问的问题千奇百怪，Prompt写得再严谨，模型该胡说还是胡说。如果没有引用溯源和拒答机制，错误的回答造成的信任损伤是很难修复的。

第四，没有量化评估体系。Demo阶段“人工看一眼觉得还行”，生产阶段行不通——你怎么证明这周比上周好？你怎么回答业务方“准确率到底多少”？没有评估集、没有指标基线，优化就变成玄学。

1.3 哪些方案能留，哪些方案必须推翻

做完这些项目，我的心得是：Demo阶段的代码架构可以保留，但方案设计基本要重做。不是说Demo没用，而是要把Demo当成“交互验证工具”，而不是“架构蓝本”。你验证的是产品体验和用户需求，但生产链路需要用完全不同的工程标准重新搭建。所以接下来这篇文章的每一部分，都是我重新搭生产链路时亲身验证过的方案和踩过的坑。

2. 检索链路的生产化改造：切分、召回、重排不是跑通就行

RAG的核心在检索，检索的核心在数据组织和召回策略。这一部分我要重点讲从Demo到生产，检索链路必须做的三件大事。

2.1 文档切分：没有万能参数，只有组合策略

Demo阶段最常见的做法是拿LangChain的RecursiveCharacterTextSplitter，chunk_size=500，overlap=50，然后就完事了。这个参数在小规模数据上没啥毛病，因为文档少，噪声少，就算切得烂，embedding也能大致召回。但生产环境文档类型五花八门，有PDF合同、有Excel表格、有Markdown文档、有扫描件OCR结果，固定参数切分会带来两个问题。

第一个问题是语义单元被割裂。比如一个合同条款，从“甲方责任”到“违约责任”可能横跨几百字，如果被500字一刀切开，条款的上下文就断了。第二个问题是召回冗余。一个chunk如果同时包含多个不相关主题，embedding向量可能被稀释，导致检索时既不精准，还占向量库空间。

我的生产实践是组合策略：

• Markdown和HTML类文档，先用标题结构做第一层切分：按#、##、###拆成章节块，再把过大的章节块按段落二次切分。
• PDF和Docx类文档，先抽取段落结构，不要直接用纯文本切。很多业务文档的“条款”、“附件”是强结构化信息，保留这些层级对召回很有帮助。
• 表格类数据单独处理，最好把表头信息拼进每一行再做chunk，这样检索“2024年Q3营收”时能命中准确的行。
• chunk_size建议512到1024之间，overlap建议80到150，具体要靠你自己的评估集去调，没有放之四海皆准的参数。

另外，chunk的“父子结构”非常值得做。我常用的设计是：大chunk（比如一个二级标题下的全文）用于检索，小chunk（比如其中一个段落）用于喂给LLM生成。这样既能保证召回时看到全文语义，又能保证生成时上下文精简，避免token浪费。

2.2 Embedding与索引选型：单向量检索在大多数场景不够用

用Demo跑的时候，用户问个“报销流程”，你用文本embedding也能召回到相关文档。但生产环境里用户的真实问法千奇百怪：“我们部门采购服务器怎么走流程”“上个月说的那个报销新规现在还能用吗”“发票丢了怎么办”。这些query和文档之间的词汇差异极大，纯向量检索对这种词汇鸿沟非常吃力。

我现在的做法是混合检索：BM25稀疏检索 + 向量密集检索，然后做结果融合（RRF或者加权）。BM25擅长精确关键词匹配，向量擅长语义匹配，两者互补，效果提升非常明显，尤其在售后、客服、制度文档这类专业术语多的场景。

再说Embedding模型选型。我在生产里用的是中文场景下效果稳定且开源的方案（比如bge系列），以及各家大模型厂商提供的商用embedding接口。需要注意的是：

• 模型发布之后不要频繁切换。embedding模型版本一变，整个向量库的坐标空间就变了，你就必须全量重建索引。我踩过一次，发布新embedding模型后忘记重建，线上检索质量骤降，排查好久才发现是索引和模型不一致。
• 向量维度越高的模型，召回能力不一定越强，但存储和计算成本一定更高。如果是几十万级文档，768维和1024维的差别在Milvus里查询延迟可能差一倍。在满足效果的前提下，优先选低维度版本。
• 向量库选型要从运维视角看。我三个项目分别用了Milvus、Qdrant和pgvector，各有各的适用场景。小团队、数据量不大、想省事的，pgvector配合PostgreSQL现成的备份体系最省心；数据量上了百万、追求查询性能和动态schema，Milvus或Qdrant更合适。别为了“技术时髦”引入一套还得专门养人的中间件。

2.3 重排（Rerank）是生产环境标配，不是可选项

很多人觉得加了重排会让链路变复杂，事实是，在召回阶段追求“高召回”然后用重排模型做“精排序”，才是生产环境正确处理精确性和性能矛盾的方式。我通常的管道是这样的：

1. 第一轮召回：混合检索，从全量向量库召回top 100（这个阶段可以宽松一点，宁可多召回）。
2. 第二轮精排：把top 100的候选块交给Rerank模型（比如bge-reranker或商用的rerank接口），输出top 5到top 10给LLM生成。

第一轮保证不漏，第二轮保证精度，两轮分工明确。Rerank模型的强项是query和文档之间的深度交互，这一点是纯双向量编码做不到的。代价是延迟增加，但实测中，好的Rerank模型能把答案准确率提升10到20个百分点，这一两百毫秒的代价完全值得。

2.4 资料新鲜度与权限过滤：很多人忘了检索还要带条件

生产环境的检索不是“全库相似度排序”这么简单。用户只能看自己权限范围内的资料，而且用户昨天的提问和今天的提问，检索范围都可能不一样。Demo阶段那个“一个库里全是自建文档，随便搜”的模式完全不可用。

我的做法是给每篇文档打上结构化的元数据，包括：所属业务线、文档分类、更新时间、可见范围（部门/角色/个人）、密级等。检索时先通过元数据过滤缩小候选集，再做向量检索。这个过滤一定要放在检索之前，别等top 100出来了再过滤，否则效率极低，还可能因为过滤掉了真阳性导致召回不足。

时间衰减也值得做。制度类文档通常是“新版本替代旧版本”，如果旧版本没有被覆盖掉而是被归档，检索时就要对旧文档做时效降权。我在生产链路里加了一个时间衰减系数，新文档权重更高，老文档除非用户明确提及否则不进入top结果。

3. 生成层改造：流式、缓存、幻觉控制，每一项都是硬指标

检索负责找料，生成负责炒菜。但生产环境对“炒菜”这个环节的要求，远不是Demo里“把检索结果拼接进Prompt，调一下模型API”那么简单。

3.1 流式输出与超时控制：用户等不了10秒

内部Demo阶段，点击提问后转个圈等5秒，用户不会说什么。生产环境你试试，5秒不出字，用户就开始刷新页面了，再刷新一下你的后端就又多一次请求。

所以生成接口必须做SSE（Server-Sent Events）流式输出。设计和Demo最大的不同在于，你要对首包延迟和整体时长分别做控制。我给自己定的标准是：检索全程控制在500毫秒以内，模型首token控制在1秒以内，完整回答控制在10秒以内。任何一个环节超预算，都需要告警和排查。

具体操作上，我把“检索完成”和“生成开始”的逻辑解耦。检索一完成就先向客户端推一个“signal”，告诉前端可以渲染引用的资料了；模型开始输出后，用SSE持续推流。这样用户感知到的延迟被大幅降低，哪怕生成要5秒，用户已经在看到内容逐步出现。

3.2 幻觉控制三板斧：Prompt、引用、拒答

RAG系统即使检索完全正确，LLM也可能在生成时产生幻觉。生产环境下我靠三道防线来控制：

第一道防线是Prompt约束。系统提示词里明确写：只能基于提供的参考资料回答，禁止编造，如果参考资料不足以回答就明说不知道。这个约束不是写一遍就完事，还要配合few-shot示例来强化。

第二道防线是引用溯源。生成时要求模型在回答中标注引用来源编号（比如[1]、[2]对应检索到的chunk），前端把引用渲染成可点击的链接。好处是双重的：用户可以点开核对原文，增强信任感；出现错误回答时也能追溯到是哪份资料或哪段上下文导致模型判断失误。

第三道防线是置信度阈值与拒答。我给每个query计算一个检索置信度，比如用top结果的得分和相对于第二名的差值做判断。置信度低于阈值时，不要硬答，而是返回“当前知识库中没有找到足够相关的资料”。虽然这个回答看起来“没用”，但比起一本正经地胡说八道，它不伤人。

这道防线尤其适合面对C端的客服场景——用户宁愿听到“查不到”，也不愿意被错误回答误导，然后回头投诉你。

3.3 缓存设计：别让相同的问题反复花钱

生产环境下你会发现，用户问的问题高度重复。首页点击率高的那十几个问题，每天能占所有提问的30%以上。如果每个重复问题都完整走一遍“检索+重排+大模型生成”，钱包和延迟都受不了。

我的方案是两层缓存：

• 精确命中缓存：完全相同或规范化后的query（去掉标点、统一大小写）直接在Redis里命中答案，TTL根据知识库更新频率来定。
• 语义缓存：对新query先计算embedding，和缓存里的历史query做相似度比较，如果相似度超过某个阈值（比如0.92），直接复用缓存答案。这个方案能覆盖改写、错别字的场景，但要注意阈值别设太低，否则两个不同问题容易串答案。

缓存之外还有一层降级策略。生产上最大的风险是大模型API限流或超时。我把整个RAG链路拆成三个fallback级别：正常链路是“检索+重排+大模型生成”；大模型接口失败时降级为“检索top结果直接展示原文摘要”；检索链路失败时提示用户稍后重试。降级方案宁可简单，也不能让服务白屏报错。

3.4 结构化输出与Agentic RAG：是什么时候值得升级

很多人看到“Agentic RAG”这个词很兴奋，觉得智能体加持后RAG就无所不能了。我的建议是：先把非Agent的RAG做得足够好，再谈升级。

Agentic RAG的本质是让LLM自己决定“下一步查什么”，适合跨多个数据源、需要多轮追问、需要写代码查数据库的复杂场景。但它带来的是不可控的延迟和成本——一个query可能要调用十几次模型，单次响应超过30秒都是常事，而且排障复杂度指数级上升。

所以我的判断标准是：

• 如果是知识库问答，别上Agent，普通RAG链路足够。
• 如果是业务报表分析，需要根据用户意图决定调哪个接口、拼什么条件，才值得考虑Agent。
• 如果上Agent，一定要做规划步骤的可观测，把每步的思考、工具调用、结果都记录下来，否则线上出了错根本无从排查。

4. 底座工程：可观测性、权限隔离、评估集，缺一个都别上线

一个RAG系统能不能上生产，很多时候看的不是算法多好，而是工程底座结不结实。我三个项目推进过程中最痛的一个体会是：效果优化是慢功夫，但工程底座的欠缺会直接导致上线失败。

4.1 评估集：从“你觉得好”到“量化可比”

没有评估集的RAG优化就是打地鼠。这周调了切分参数觉得“好像好了”，下周改了Prompt又觉得“好像差了”，但你根本说不清差在哪。

所以第二个项目开始，我第一件事就是拉着业务方一起建评估集。做法很简单：从真实用户日志里抽200条典型问题，覆盖高频问题、长尾问题、拒答场景、多轮追问场景；然后给每一条标注标准答案和对应引用的文档范围。这200条问题就是后续所有优化的标尺。

评估指标我用到这几个：

每个版本上线前，跑一遍评估集，输出对比报告。这个习惯救了我很多次——它能让你在改坏一个参数时立刻发现，而不是等用户抱怨。

4.2 日志与监控：每个错误都要能定位到链路环节

RAG链路长，节点多：query解析、文档切分、向量检索、重排、Prompt组装、模型生成、流式输出。任何一个环节出错，如果日志不完整，排查就是大海捞针。

我给每个请求生成一个唯一的trace_id，贯穿全部环节；每个环节记录耗时、输入输出摘要、命中的chunk列表。监控指标上，我重点盯这几个：

• 检索平均耗时和P99耗时，指标突增通常是向量库或重排服务出了问题。
• 检索无结果率（top结果得分为0的比例），这个指标如果持续偏高，说明资料覆盖有问题或切分策略不当。
• 生成token消耗和成本预估，防止某个用户或某个时段异常刷量导致账单超支。
• 用户端“无答案”率，即触发了拒答策略的比例。太高说明知识库覆盖不足，太低说明模型答了不该答的。

4.3 权限与合规：RAG系统的隐形红线

企业级RAG逃不过权限问题。我第三个项目因为对接多个业务线，一开始用最简单的“管理员维护权限白名单”方案，结果业务方根本不愿意把资料传上来——因为别人也能检索到。后来我把权限拆成两层：

第一层是文档级权限，在索引阶段就给每个文档打上可见范围标签，检索阶段用标签过滤。第二层是内容级审计，记录谁在什么时候检索了什么文档、看到了哪些chunk，万一出现违规访问或泄密，可以追溯。

这里提醒一句：如果业务方要求“根据用户角色动态决定可见内容”，千万别在检索后才做内容过滤，一定要把权限条件下推到向量查询里。否则先检索全库再逐条判断权限，性能和安全性都过不了关。

4.4 K8s部署的几个坑：OOM、优雅退出与HPA

我的三个项目最终都跑在K8s集群里，这块的坑比想象中多。最典型的是并发上来之后服务OOM。RAG服务的内存大头不在模型推理，而在检索结果和Prompt组装——一个top 100候选的chunk列表动辄几十KB，并发一高，积压起来就把内存打爆了。

我的调整经验是：

• 给业务服务和模型服务分开部署。业务服务无状态，可以随便扩；模型服务（尤其本地推理）有显存和内存上限，不能跟着业务流量盲目扩。
• 配置优雅退出。K8s滚动更新时，如果旧Pod被直接杀掉，正在处理的SSE流会中断，用户端表现为回答到一半没了。我在业务服务里加了PreStop钩子，等待正在处理的请求完成后再退出，并且加了terminationGracePeriodSeconds的合理配置。
• HPA指标用自定义的“在途请求数”而不是CPU。因为RAG服务CPU波动极大，纯靠CPU触发扩容往往慢半拍。
• 本地模型推理要预留显存余量。如果用的开源模型跑在GPU上，并发推理时显存可能暴涨。我的经验是，推理服务开启连续批处理（continuous batching），并且给并发上限加信号量控制，超出直接排队而不是全部打进去。

5. 两个最有代表性的生产故障复盘（从表象到根因）

这一部分我不打算讲理论，直接复盘两个真实故障。这两个故障都属于“Demo阶段根本不会发生、生产阶段一旦发生就很致命”的类型。

5.1 故障一：知识库更新后，第二天全线指标骤降

现象：某个业务线的制度文档每周五更新，周一早上一看监控，检索命中率从0.75掉到0.51，用户侧“答非所问”的反馈开始增加。

排查链路：

1. 先查了重排和生成环节的日志，发现输入输出的质量都在正常范围，问题锚定在检索召回。
2. 查了向量库的索引状态，没有重建任务在跑，索引健康。
3. 拉出更新的文档列表，对比更新前后的chunk内容，发现问题出在切分策略上：新上传的文档是PDF版本，格式解析出了问题，表格内容全被打散成一个一个独立的小块。
4. 原来的文档走的是“标题结构+段落切分”策略，新版PDF走的是纯文本递归切分，结果一个完整条款被拆成几十个碎片，检索时根本找不全上下文。

根因是：数据管道对新增文档的格式没有做统一预处理，不同格式走了不同路径。修复方案是统一解析管线，所有文档先转成标准结构化格式再做切分，并且在上线前对本周新增文档跑一遍捞回抽检。

这个故障给我的教训极深：RAG的数据管道和代码管道一样需要做CI/CD，新增文档必须经过质量检查才能入索引。

5.2 故障二：上线半小时，搜索服务的P99延迟从800ms飙到12秒

现象：新版本上线后，30分钟后监控显示检索模块P99延迟从800ms飙升到12秒，紧接着生成模块也跟着超时，前端大量请求失败。

排查链路：

1. 先看负载均衡和Pod数量，发现Pod CPU并不高，K8s也没有触发扩容，排除资源不足。
2. 看数据库连接池，发现连接数打满，大量请求阻塞在获取连接上。
3. 进一步定位，原来是向量库客户端连接数配置是固定值，上线后的流量比预估计翻倍，连接池不够用，线程全部阻塞。
4. 更严重的是，阻塞导致调用方重试，重试又加剧连接池压力，形成雪崩。

修复方案分两步：短期扩容连接池并限制调用方超时和重试次数；长期做连接池的动态伸缩，并加了舱壁隔离——检索服务和生成服务使用独立线程池，一方慢不能把另一边拖死。

这个故障让我意识到，生产环境你要考虑的永远不是“正常情况多快”，而是“峰值情况多稳定”。任何“瓶颈前不加限制”的做法都是定时炸弹。

6. 我对RAG项目从Demo到生产的几点反思

最后一个部分，不列技术清单，纯粹分享我做完整整三个项目后的一些个人体会。

第一，别迷信技术概念的时髦度。很多人一上来就问“你要不要上Agentic RAG”“要不要上GraphRAG”，我现在的回答一律是：先把最基础的“检索+重排+生成”做到位，把评估集建起来，把日志监控铺好。基础链路的数据质量、召回精度都还不够扎实的时候，上什么高级架构都是空中楼阁。

第二，RAG项目成功的关键不在AI，而在数据治理。尤其是企业场景，文档的格式统一、权限标记、版本管理、更新节奏，这些工作占了我一半以上的精力。AI模型只是把整理好的数据变成答案，数据本身一塌糊涂，模型再强也救不回来。

第三，业务方的预期管理比技术实现更早要做。Demo阶段业务方看到的都是“这也能答出来”的神奇时刻，上了生产面对的是“为什么这个答不对”“为什么这么慢”的日常拷问。我在做第三个项目时，上线前专门给业务方做了一次“能力边界”的沟通，明确告诉他们在什么场景下系统会很靠谱、哪些问题它天生回答不了，并且把拒答机制也透了个底。事实证明，这次沟通大大减少了上线后的投诉量。

第四，预算和成本要提前量化。RAG的生产成本大头在大模型API调用和向量库资源上。我在第二个项目里做了按月成本预估：假设日均5000个query，每个query检索加生成消耗约3000 token，再加上语义缓存命中率按30%算，一个月的大模型费用大概率在五位数以上。这笔账必须提前和财务说清楚，而不是等账单出来再甩锅给技术。

做RAG落地这件事，越往后越会意识到它是一门“工程大于算法”的活儿。Demo让你看到可能性，生产让你面对现实。能在这两者之间找到平衡、稳扎稳打把基础链路做扎实的团队，才能真正让RAG从演示走向创造价值。希望这篇基于真实项目经历的总结，能帮你少走几段我走过的弯路。