企业官网建设流程全解析

这几年，很多 AI 应用都是从知识库问答开始的。

把公司文档、产品手册、制度说明、接口文档、FAQ、项目资料丢进系统里，再接上大模型，让用户直接提问，看起来就是一个很自然的 AI 应用场景。

从 Demo 角度看，RAG 也确实很容易让人产生信心：上传几份文档，切分成片段，做向量化，用户提问时检索相关内容，再把检索结果交给大模型生成答案。流程不长，效果也很直观。

但很多项目真正开始使用后，很快就会暴露问题。

用户明明问的是文档里有的内容，系统却说不知道；有时检索到了资料，但资料和问题并不相关；有时模型拿到资料后仍然开始自由发挥；有时答案看起来很完整，却没有引用来源；还有时系统回答得过于自信，用户反而不知道能不能相信。

这就是很多 RAG 知识库问答“不好用”的根源：它不是没有跑起来，而是没有真正变成一个稳定、准确、可信、可维护的系统。

RAG 想解决的不是“让模型什么都知道”

RAG 的全称是 Retrieval-Augmented Generation，也就是检索增强生成。

它的核心思路并不是让大模型记住所有知识，而是在模型回答之前，先从外部知识库中检索相关资料，再把这些资料作为上下文交给模型，让模型基于资料回答问题。

这件事看起来简单，但背后的目标很重要：

RAG 不是让模型变成一个万能数据库，而是让模型在回答时有依据。

普通大模型回答问题时，主要依赖训练阶段学到的知识和当前输入。如果问题涉及企业内部资料、私有文档、最新信息、项目规范或业务流程，模型本身通常并不知道。即使模型能编出一个流畅答案，也不代表答案可靠。

RAG 的价值就在于把“模型自由回答”变成“模型基于资料回答”。

一个好的 RAG 系统应该尽量做到：

• 用户问的问题能匹配到相关资料。
• 模型回答时能依赖这些资料。
• 资料不足时不要强行编答案。
• 答案最好能给出来源，方便用户追溯。
• 系统出现问题时，开发者能知道问题出在哪里。

所以，RAG 的关键不是“接了一个向量库”，而是能不能把用户问题、知识资料和模型回答稳定地连接起来。

为什么 Demo 阶段看起来不错？

很多 RAG Demo 的体验都不差，原因并不复杂。

Demo 通常有几个特点。

第一，文档数量少。

只有几份文档时，检索空间很小。哪怕切分粗糙、检索策略简单，也比较容易找到看起来相关的内容。

第二，问题比较标准。

演示时的问题通常是提前准备过的，问法也接近原文表达。比如文档里写着“报销流程包括提交申请、部门审批、财务复核”，用户就问“报销流程是什么”。这种问题很容易命中。

第三，场景边界很清楚。

Demo 往往只展示最理想的路径，不会故意问模糊问题、跨文档问题、权限问题、过期内容问题、引用冲突问题。

第四，用户容忍度更高。

演示阶段，大家更关注“它能不能回答”，而不是“它是否每次都稳定、是否能追溯、是否适合上线”。

但真实业务不是 Demo。

真实知识库里的文档会越来越多，格式会越来越复杂，问题会越来越口语化，用户会不断追问细节，还会提出文档中没有答案的问题。一旦系统进入真实使用环境，RAG 的很多隐藏问题就会被放大。

RAG 知识库问答常见的 6 类失败

一个 RAG 系统不好用，通常不是某一个点出了问题，而是多个环节共同影响结果。下面这 6 类失败最常见。

1. 文档在知识库里，但系统检索不到

这是最容易让用户失望的问题。

用户知道答案在文档里，甚至知道是哪份文档，但系统就是找不到。出现这种情况，通常不是模型生成的问题，而是检索链路的问题。

可能的原因包括：

• 文档解析时内容丢失。
• 文档切分破坏了原有语义。
• chunk 太小，关键信息被拆散。
• chunk 太大，相关内容被无关内容稀释。
• Embedding 模型对领域术语理解不好。
• 用户问题和文档表达方式差异太大。
• 检索 TopK 设置不合理。

比如用户问“试用期员工能不能申请年假”，但制度文档里写的是“入职未满一年员工休假规则”。如果系统只做简单语义匹配，又没有查询改写或关键词补充，就可能召回不到真正相关的片段。

这种失败会让用户觉得系统“不懂业务”。

2. 检索到了内容，但内容不相关

另一类常见问题是系统确实检索到了内容，但召回内容和问题关系很弱。

比如用户问“生产环境数据库备份策略是什么”，系统却召回了“开发环境数据库初始化说明”；用户问“合同审批流程”，系统却召回了“采购审批流程”。

这类问题通常来自检索质量不足。

向量检索擅长捕捉语义相似，但它并不总是理解业务边界。两个片段只要词汇相近、主题相似，就可能被召回。对于企业文档来说，这会带来很多干扰。

尤其是下面这些内容，很容易产生误召回：

• 相似流程文档。
• 相似产品模块。
• 相同部门下的不同制度。
• 多个版本的同一类文档。
• 包含大量重复术语的技术文档。

如果没有 Rerank、metadata filter、关键词检索、权限过滤和版本控制，系统很容易把“看起来相似”的内容当成“真正相关”的内容。

3. 检索结果正确，但模型回答时自由发挥

RAG 系统里，检索只是第一步。

即使检索内容是正确的，模型也可能在生成阶段出现问题。

比如资料里只说“标准审批时间为 3 个工作日”，模型却补充说“特殊情况可能延长到 7 个工作日”。如果这个补充不是资料里明确写的，就可能造成业务风险。

模型为什么会自由发挥？

通常有几个原因：

• Prompt 没有明确要求“只能基于资料回答”。
• 检索上下文太长，模型抓不住重点。
• 多段资料之间存在冲突，模型自行选择了一个版本。
• 问题中带有诱导性表达，模型顺着用户问题继续生成。
• 系统没有要求模型在资料不足时回答“不知道”。

RAG 并不会自动消除幻觉。它只是给模型提供了上下文。如果生成环节没有约束，模型仍然可能编出一个看似合理的答案。

4. 答案没有来源，用户不知道该不该信

知识库问答最重要的价值之一，是让答案可追溯。

如果系统只给出一段流畅回答，却不告诉用户依据来自哪里，用户仍然很难信任它。

尤其在企业场景里，很多问题不是闲聊，而是和流程、制度、合同、财务、权限、交付、合规有关。用户需要知道：

• 这个答案来自哪份文档？
• 是哪个章节？
• 文档是否最新？
• 有没有其他文档说法不同？
• 这个答案是否只是模型总结？

没有引用来源的 RAG，很容易退化成一个“看起来接了知识库的聊天机器人”。

用户真正需要的不是一句漂亮的回答，而是一个可以核查的答案。

5. 文档内容过期，但系统还在回答

知识库不是一次构建后就不变的。

企业制度会更新，产品文档会迭代，接口会变更，项目规范会调整，旧版本资料也可能仍然留在系统里。

如果 RAG 系统没有处理版本和时效性，就可能拿过期内容回答用户。

比如旧文档里写“接口调用频率限制为每分钟 100 次”，新文档已经改成“每分钟 500 次”，但系统检索到了旧文档并生成答案。这种错误比“回答不知道”更危险，因为它看起来很确定。

所以企业级 RAG 不能只关注“能不能检索到”，还要关注：

• 文档是否最新。
• 是否存在多个版本。
• 是否有废弃标记。
• 是否需要按时间排序。
• 是否需要在答案里展示文档更新时间。

知识库问答一旦进入真实业务，数据治理就会变成非常核心的问题。

6. 系统出错后，开发者不知道问题在哪里

很多 RAG 系统上线后，最痛苦的不是“有问题”，而是“不知道问题出在哪里”。

用户反馈“这个问题答错了”，开发者需要判断：

• 是文档里本来就没有答案？
• 是文档解析失败了？
• 是切分方式不合理？
• 是 Embedding 召回失败？
• 是 TopK 太小？
• 是 Rerank 排错了？
• 是 Prompt 没约束住模型？
• 是模型生成时产生了幻觉？

如果系统没有记录完整链路，排查就会变成猜。

一个可维护的 RAG 系统，至少应该记录：

• 用户原始问题。
• 改写后的查询。
• 召回的文档片段。
• 每个片段的相似度分数。
• Rerank 后的排序结果。
• 最终传给模型的上下文。
• 模型生成的答案。
• 引用来源。
• 调用耗时和 token 成本。

没有日志和可观测性，RAG 很难从 Demo 走向生产。

RAG 不只是向量数据库

很多人刚接触 RAG 时，会把重点放在向量数据库上。

向量数据库当然重要，但它只是 RAG 系统中的一环。

一个完整的 RAG 系统至少包括这些部分：

• 文档采集：文档从哪里来，如何更新。
• 文档解析：PDF、Word、Excel、网页如何提取内容。
• 数据清洗：重复、噪声、无效内容如何处理。
• 文档切分：如何保留语义结构。
• Embedding：如何把文本转成向量。
• 索引存储：如何存储向量和元数据。
• 检索策略：向量检索、关键词检索、混合检索如何组合。
• Rerank：如何对候选内容重新排序。
• Prompt 设计：如何约束模型基于资料回答。
• 答案生成：如何组织结构化输出。
• 引用追溯：如何展示来源。
• 权限控制：不同用户能看到哪些资料。
• 评测体系：如何判断效果是否变好。
• 日志观测：如何排查错误和优化系统。

只接一个向量库，只能说明系统有了检索能力，不能说明系统已经可用。

真正难的是把这些环节连成一个稳定链路。

什么样的 RAG 才算可用？

一个可用的 RAG 系统，不是每次都回答得很长，也不是看起来很聪明，而是要在真实使用中可靠。

我认为至少要满足几个标准。

1. 能找到相关资料

这是最基本的能力。

如果答案明明存在于知识库里，系统却经常检索不到，用户很快就会放弃使用。

要做到这一点，系统需要有合理的文档切分、Embedding 模型、检索策略和查询处理能力。

2. 能过滤无关资料

召回多不代表效果好。

如果系统把大量不相关内容塞给模型，模型就会被干扰，答案质量反而下降。

所以 RAG 不只需要 recall，也需要 precision。

3. 能基于资料回答

模型应该围绕检索内容生成答案，而不是把检索内容当作一个参考，然后继续凭感觉补充。

Prompt、上下文组织和生成约束都很重要。

4. 能在资料不足时说“不知道”

这点非常关键。

一个成熟的 RAG 系统，不应该为了显得有用而强行回答所有问题。

当知识库没有足够依据时，回答“不知道”比编一个答案更可靠。

5. 能提供引用来源

引用来源能显著提升用户信任，也方便后续排查问题。

尤其是企业内部知识库，答案最好能关联到文档名、章节、片段、更新时间等信息。

6. 能评测和持续优化

RAG 的效果不是一次调好就结束。

文档会增加，模型会变化，用户问题会变化，业务规则也会变化。系统必须有评测集和回归测试，才能知道一次优化到底是变好了还是变差了。

7. 能排查问题

当用户说“答错了”，系统需要能还原完整链路。

否则每一次问题都只能靠人工猜测，长期维护成本会非常高。

RAG 的难点在工程化，而不只是模型能力

很多 RAG 问题表面上看像是模型不够聪明，但实际往往是工程链路不完整。

比如：

• 检索不到，不一定是模型问题，可能是切分和索引问题。
• 回答不准，不一定是模型问题，可能是上下文质量问题。
• 答案胡编，不一定是模型问题，可能是 Prompt 约束问题。
• 用户不信任，不一定是模型问题，可能是没有引用来源。
• 上线后难维护，不一定是模型问题，可能是缺少日志、评测和数据治理。

这也是为什么 RAG 很适合作为 AI 应用工程化的核心场景。

它不是单点技术，而是一条完整链路。

如果只是为了演示，RAG 可以很简单；如果要真正上线，RAG 就必须被当成一个系统来设计。

后续应该怎么继续深入？

这篇文章只是整个 RAG 系列的入口。

如果我们要把一个知识库问答系统从 Demo 做到可用，后面至少要继续拆解这些问题：

• 文档应该怎么解析和切分？
• Embedding 模型应该怎么选？
• 向量数据库到底承担什么职责？
• 检索质量如何提升？
• 为什么需要 Hybrid Search 和 Rerank？
• RAG 的 Prompt 应该怎么设计？
• 复杂问题如何做查询改写和多步检索？
• GraphRAG 和 Agentic RAG 解决什么问题？
• RAG 系统怎么评测？
• 企业场景下如何处理权限、多租户、成本和可观测性？

这些问题看起来分散，但它们共同指向一个目标：

让 RAG 不只是一个能跑的 Demo，而是一个能在真实业务中长期工作的 AI 应用能力。

总结

很多 RAG 知识库问答不好用，并不是因为 RAG 这个方向不行，而是因为很多系统只完成了最表层的流程：文档入库、向量检索、模型回答。

真正可用的 RAG，需要处理文档质量、切分策略、检索召回、重排序、Prompt 约束、引用来源、权限控制、效果评测和问题排查。

RAG 的价值不在于让模型看起来更聪明，而在于让模型的回答有依据、可追溯、可验证。

如果把 RAG 当成一个简单插件，它很容易停留在 Demo；如果把 RAG 当成一个工程系统，它才有机会成为企业 AI 应用里真正可靠的基础能力。