企业官网建设流程全解析

1. 整体架构设计：企业版RAG的七个关键环节

先聊一个很现实的问题：为什么企业知识库问答做到最后，都要回到RAG这条路上来？

我在某跨平台系统项目里做知识库问答时，最早的想法很简单——把文档丢给大模型，让它“记住”所有内容，然后直接回答。结果实测下来问题一大堆：模型幻觉严重、新文档更新后回答还是旧的、上千页的合同没法一次性塞进上下文窗口、每次调用费用高得离谱。换了好几个底座模型，问题依旧。

RAG（检索增强生成）的核心思路其实不复杂：不让模型凭“记忆”回答，而是先从一个企业内部的知识库里检索出和问题最相关的片段，再把这些片段拼进提示词里，让模型基于这些材料来生成答案。你不需要微调模型，不需要重新训练，只需要把知识准备好、检索做好，就能让模型回答得又快又准。

把标题里的“企业落地版”拆开看，RAG在企业场景里和做Demo是两码事。Demo只要能用就行，企业落地必须考虑七个环节：非结构化数据的接入与解析、切分策略、向量化、索引存储、检索召回、重排序、生成与引用溯源。少一个环节，后面线上跑起来都要还债。

• 数据接入：企业内部文档格式五花八门，Word、PDF、Markdown、HTML、扫描件，甚至还有表格里的备注。每个格式的解析方式和坑都不一样。
• 切分策略：文档切多大、怎么切，直接决定检索的命中率。切太小，语义不完整；切太大，噪声多、还浪费上下文空间。
• 向量化：选什么向量化模型、维度多少、要不要针对领域做微调，这些都会影响检索质量。
• 索引存储：向量数据库选型，以及向量索引和元数据过滤怎么配合。
• 检索召回：Top-K取多少、相似度阈值设多少，都有讲究。
• 重排序：向量召回的结果顺序不一定符合真实相关性，需要用一个更强的模型把候选结果重新排一遍。
• 生成与溯源：回答里怎么让模型引用原文片段，方便用户核对，这是企业场景的刚需。

2. 向量化与切分策略：决定检索质量的地基

先说说整个RAG里最容易被低估、但影响最大的部分——文档切分和向量化。我调试过的项目中，至少有一半的“回答得不对”问题，根源不在模型，而在切分和向量化这一步。

2.1 切分策略：先按结构切，再按语义补

很多人上手RAG时会直接按字符数硬切，比如固定500个字符一块。这种方案在测试Demo时看着还行，放到企业文档里就露馅了。一份技术方案文档，一个小节讲的是“系统架构”，下一个小节讲的是“部署要求”，硬切会把逻辑完整的一段话拦腰截断。用户问“部署需要什么环境”，结果检索回来的片段里只有半句话，另一半是架构设计的干扰内容。

提示：我自己实践下来的经验是，一定要先利用文档本身的层级结构做切分，再对长段落做二次细分。比如PDF解析出来之后，先按标题层级（一级标题、二级标题）切块，保证每一块在逻辑上是“一个完整主题”；如果某个小节还是太长，再按段落、按句子边界做补充切分。

切分参数需要根据文档类型调整。合同类文档往往条款很长，一节几千字很正常，我会把块大小设在800到1200字左右；FAQ类文档本身就很短，一条问答直接作为一块，不用再切。千万不要一套参数走天下，同一个项目里不同类型的文档分开配置切分规则，是值得一开始就做好的设计。

2.2 分块重叠：防止边界截断的兜底手段

即使按结构切分，长文本仍然可能在块边界处丢失语义。比如一个段落里前半段在讲背景，后半段在讲结论，结论引用了背景里的某个术语定义，而那个术语定义恰好被切到了前一块。

解决这个问题的一个实用手段是分块重叠，也就是相邻两个块之间保留一部分重复内容。块大小1000字的话，可以设重叠100到200字，这样位于边界附近的语义信息不会完全丢失。代价是索引体积增加一些，但相对于检索质量的提升，这点开销非常划算。

2.3 向量化模型选型：通用模型起步，领域模型优化

向量化模型决定了“语义相近”这件事在你这个项目里到底准不准。通用中文向量化模型在常见业务问答上表现不错，但遇到专业术语密集的领域（比如法律条款、医疗术语、制造工艺参数），通用模型的语义空间往往映射得不够准。

实操中我的建议是：先拿一个成熟的通用向量化模型把整条链路跑通，用一批真实业务问题去测召回效果，如果发现同义表达检索不到、检索结果语义相关性差，再考虑用领域语料做向量化模型微调，或者换一个在垂直领域表现更好的模型。企业项目里，不建议一上来就在向量化模型微调上投入大量时间，先看通用模型能不能覆盖大部分场景，再决定是不是要做这一步。向量化之后，文档就变成了高维向量，存入向量数据库。这里有两个坑要留意：一是向量维度要统一，换模型之后必须重建索引；二是必须把元数据（文档ID、来源、章节路径、更新时间）一起存进去，没有元数据的向量索引在召回后没法做权限过滤，也没法生成引用溯源信息。

3. Spring AI里RAG前的基础设施准备

真正动手写代码之前，先把Spring AI里RAG相关的基础设施理清楚。Spring AI这个框架最大的价值在于，它把“接一个大模型”这件事标准化了，让Java生态和模型服务商之间的集成变得非常规整。你不需要关心每个模型服务商的SDK差异，只需要面向Spring AI的抽象接口编程，后续换模型服务商只需要改配置。

3.1 依赖引入与基础配置

用Maven的话，核心依赖是这样组织的：

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter</artifactId> <version>1.0.0</version> </dependency>

注意Spring AI的模块划分：ChatClient负责与大模型对话，EmbeddingModel负责文本向量化，VectorStore负责向量存取。不同模块可以独立配置、独立替换。举个例子，你可以用某一家的Chat模型做生成，同时用另一家的Embedding模型做向量化，这两者之间没有耦合。

配置文件里至少需要三块内容：

spring: ai: chat: base-url: http://your-model-service api-key: ${MODEL_API_KEY} model: your-chat-model-name temperature: 0.1 embedding: base-url: http://your-embedding-service api-key: ${EMBEDDING_API_KEY} model: your-embedding-model-name

这里有个小经验：对话模型和Embedding模型建议分开配置独立服务地址。企业环境里这两类模型往往部署在不同地方，有的是外部API，有的是内网自建服务，分开配置才能在切换部署环境时不动代码。

3.2 温度参数和Token限制：企业场景要“稳”不要“飘”

对话模型的temperature参数建议在0到0.3之间。知识问答场景要求答案忠实于检索到的材料，temperature太高会让模型自由发挥，出现“自己编一个答案”的情况。我看到不少踩坑案例，就是因为temperature默认值没改，模型回答得倒是很流畅，但关键数据对不上——这在企业内部是不可接受的。

另外要算清楚Token预算。一次完整的RAG调用，提示词大概包括：系统指令、用户问题、检索回来的若干个文档片段。假设检索回来5个片段，每个片段800字左右，那就是4000字左右的输入，留给输出的空间要提前规划好。maxTokens不要设太小，否则长答案会被截断；也不要盲目设大，成本会失控。一般企业问答场景，maxTokens设到512到1024是比较合理的区间。

4. Spring AI中RAG检索管线的完整实现

基础设施就绪之后，进入正题：把检索增强生成的完整链路用Spring AI实现出来。整个管线我用四层来组织：文档解析层、索引层、检索层、生成层。每一层各管一件事，职责清晰，排查问题时也容易定位。

4.1 文档解析与索引构建

文档进RAG之前，必须先被转换成纯文本。Spring AI提供的文档读取器对不同格式有不同实现方式。以PDF为例：

public List<Document> loadPdfDocuments(String path) { SqlSource sqlSource = new SqlSource(path); // 使用PDF解析器读取，保留标题层级信息 List<Document> docs = pdfDocumentReader.get(); return docs; }

解析之后的关键动作是切分。用Spring AI的TokenTextSplitter时，我的配置是这样的：

TokenTextSplitter splitter = TokenTextSplitter.builder() .withChunkSize(800) .withChunkOverlap(120) .build(); List<Document> chunks = splitter.apply(docs);

切分完成后，给每个切块补上元数据：

chunks.forEach(doc -> { doc.getMetadata().put("source", fileName); doc.getMetadata().put("chapter", chapterTitle); doc.getMetadata().put("updatedAt", LocalDate.now().toString()); });

这些元数据在后面做权限过滤和引用溯源时都会用到，建议在索引阶段就存好，不要等检索完再回头补。最后把切块交给VectorStore写入：

vectorStore.add(chunks);

这一步会调用配置好的EmbeddingModel，把每个切块向量化并存储。数据量大的时候可以选择批量写入，比如每批次50个文档，避免一次性加载太多导致内存溢出。

4.2 检索调用：查询向量化、相似度搜索、Top-K

检索阶段就是把用户的问题变成向量，去向量库里找最相似的文档片段。Spring AI里的实现非常直观：

SearchRequest request = SearchRequest.builder() .query(question) .topK(6) .similarityThreshold(0.5) .build(); List<Document> results = vectorStore.similaritySearch(request);

Top-K和相似度阈值这两个参数，是我调得最多的两个参数。Top-K太小，候选材料不够，模型可能回答不出来；Top-K太大，无关片段混进来，模型会被干扰。结合前面说的Token预算，我一般建议Top-K设在5到8之间。

similarityThreshold则要结合向量化模型的实际分数分布来定。不同模型的余弦相似度分布差异很大，有的模型相关文档得分普遍在0.6以上，有的模型0.45就已经很相关了。不要直接抄别人项目的阈值，要在自己的数据上跑一批测试问题，统计相关文档和不相关文档的分数分布，再定阈值。这个统计工作花不了多少时间，但对线上效果影响很大。

4.3 提示词模板：把检索结果变成可用的上下文

Spring AI提供了PromptTemplate来管理提示词。企业场景中，提示词模板不要写在代码里，要放在资源文件里，方便后续调整。我通常是这样组织的：

String template = """ 你是一名企业知识库助手。请严格基于下面提供的文档片段回答用户问题。 如果文档片段中没有足够信息，请明确回答“知识库中没有找到相关内容”，不要编造答案。 文档片段： {documents} 用户问题： {question} """; PromptTemplate promptTemplate = new PromptTemplate(template); Prompt prompt = promptTemplate.create(Map.of( "documents", joinedDocs, "question", question ));

这里有个细节，“不要编造答案”这句话看着简单，但实测下来对抑制幻觉非常有效。模型接收到明确的指令约束后，和没有任何约束相比，胡说八道的概率显著下降。另外，把检索片段拼接时需要标注来源编号，比如“文档片段1”、“文档片段2”，这样后面生成时可以要求模型在回答中标注引用了哪个片段，溯源功能就很容易实现。

4.4 完整调用链封装：从问题到答案

把以上环节串起来，一个Controller里的核心方法大概是这样的：

public String ask(String question) { // 检索 SearchRequest request = SearchRequest.builder() .query(question) .topK(6) .build(); List<Document> docs = vectorStore.similaritySearch(request); // 组装上下文 String context = docs.stream() .map(doc -> "片段" + (index.getAndIncrement()) + "：" + doc.getText()) .collect(Collectors.joining("\n\n")); // 构造提示词并调用模型 Prompt prompt = promptTemplate.create(Map.of("documents", context, "question", question)); ChatResponse response = chatModel.call(new ChatRequest(prompt)); return response.getResult().getOutput().getText(); }

这里我踩过的一个坑是：每次调用都要重新做一次检索，不要试图做缓存把检索结果存下来。因为知识库是持续更新的，今天的检索结果明天可能就过期了。如果确实想优化性能，应该考虑的是从索引层做增量更新，而不是缓存检索结果。增量更新方案可以这样设计：新增文档时只向量化新增部分并加入向量库；修改文档时先删除对应旧切块再写入新切块；删除文档时按元数据里的文档ID批量清理。Spring AI的VectorStore本身支持delete和add操作，用元数据来定位要删除的批次，整体实现成本不高。

注意：上述实现用到了框架中常规的抽象类与组件命名（如ChatModel、VectorStore等），不同版本的Spring AI API命名略有差异，但整体思路一致。企业项目升级版本时，重点看这几个类的包路径和构造方式有没有变化。

5. 检索增强的三个进阶手段：查询改写、重排序与混合检索

基础链路跑通只能算“能用”，想在企业场景里回答得更准，强烈建议把下面三个手段加上。它们的共同特点是：不改变整体架构，只是在检索环节增加一个处理步骤，但收益非常明显。

5.1 查询改写：先把用户的问题“翻译”成检索友好语句

用户提问和文档原文之间的措辞差异，是影响检索质量的一大因素。比如用户问“怎么部署这个系统？”，而文档里的措辞是“安装步骤”、“环境配置”，向量化之后的相似度不一定够高。

查询改写的思路是：先用大模型把用户问题改写成一个更利于检索的查询语句，再用改写后的语句去向量库检索。实现起来就是一个额外的大模型调用：

String rewritePrompt = """ 请将下面的用户问题改写为适合用于知识库检索的查询语句。 要求：简洁、包含关键词、不改变原意。 用户问题：{question} 改写结果： """;

这一步的模型调用成本很低（输入输出都很短），但对检索命的提升很有效。实测下来，一些原本检索不到对应文档的问题，经过改写后能正常命中。

5.2 重排序（Rerank）：让最相关的内容排到前面

向量检索的Top-K结果，排序依据是向量相似度，而向量相似度不等于“语义相关性”。举个例子，用户问“系统支持哪些权限角色？”，向量检索可能召回一篇提到“角色”但不是讲权限的文档，而且排在前面的位置。

重排序的做法是把Top-K的候选片段全部交给一个重排序模型（Rerank Model），让模型逐对判断每个片段和问题的相关性，重新排序后取前N个。Spring AI里可以通过额外调用一个重排序模型的API来实现：

public List<Document> rerank(String question, List<Document> candidates) { // 构造重排序请求，每个候选片段和问题组成一对 // 调用重排序模型接口，返回相关性分数 // 按分数降序，重新组织候选列表 }

重排序的价值在于：它用的模型能力比向量相似度计算强很多，但代价是对每个候选片段都要单独计算一次，所以它只能作用于Top-K的候选集合，不能作用于整个知识库。正确的顺序是：向量检索快速缩小范围，重排序精排Top-K，最后再交给生成模型。

5.3 混合检索：关键信息要用关键词兜底

向量检索对语义匹配友好，但也有明显的短板：对精确词、专有名词、编号类信息不敏感。比如用户问“合同编号HT-2024-0018”，向量检索很可能匹配不到完全一致的编号，因为语义上它并不知道“HT-2024-0018”这种Token意味着什么。

混合检索就是同时做向量检索和关键词检索（比如倒排索引），把两部分结果合并去重后再送重排序。关键词检索保证了专有名词不丢，向量检索保证了语义泛化能力，两者互补。Spring AI集成向量存储时，可以根据底层存储是否支持全文索引来决定要不要做混合召回；如果企业场景里含有大量编号、型号、术语类信息，混合检索不是可选项，而是必选项。

6. 生产环境常见问题与排查经验

最后这部分，把我在企业项目里实际踩过、也帮别人排查过的典型问题整理成一份速查表。这些问题在Demo阶段几乎不会出现，但一上生产就冒头，全部是真实经验。

6.1 权限过滤：企业落地绕不开的一道坎

上面表格里提到权限越界问题，我得单独多说几句。企业知识库里往往有不同密级的文档，不同部门、不同职级的人能看到的内容范围不一样。如果在检索阶段不做权限过滤，即使生成模型不直接输出敏感内容，检索到的上下文里也包含了不该出现的信息，存在泄露风险。

权限过滤的通用做法是：在文档元数据里打上权限标签（比如部门、密级、可见范围），检索时把当前用户的权限条件作为过滤条件传给向量库，只召回有权限看的那部分文档。Spring AI的SearchRequest支持设置过滤表达式，可以在向量检索时就做条件过滤。这样一个简单的设计，能在源头上避免越权信息进入上下文。

6.2 检索结果质量的日常监控

企业项目的RAG上线不是终点，模型会换、文档会更新、用户问题分布会变化，检索质量必然衰减。我建议至少做两件日常维护动作：

一是建立一个回归问题集。放30到50个覆盖典型业务场景的问题，每次改动切分策略、换向量化模型或者调整检索参数之后，跑一遍回归集，对比答案质量变化。这能够避免“改了个参数，结果一类问题变好、另一类问题变差”的情况被漏掉。

二是记录检索日志。每次问答把召回片段的ID、相似度分数、来源文档记录到日志里。当用户反馈“回答不对”时，第一件事就是去查日志，看召回的是不是相关文档。80%的答案质量问题，最终都能追溯到召回环节。

7. 结尾：一点个人的实操体会

把整个企业版RAG从零搭起来，我最大的感受是：Spring AI让整个工程链路变得非常规整，但框架只是把“连接”这件事做好了，真正决定问答质量的仍然在数据工程和检索策略上。切分、向量化、重排序、权限过滤，这些环节没有哪个特别“高深”，但每一个都值得用真实业务数据反复调试。

如果在项目初期只能选定三个优先级最高的事，我会选：把切分策略真正按文档结构调整好、建立回归问题集、把元数据和权限标签设计到位。这三件事搞定，RAG的底线就保住了；其余能力（查询改写、重排序、混合检索）都是在这个底线上做增益。踩着这些坑走过来之后，我对后续做企业级问答系统更有底气了，也希望这些经验能让你少走几步弯路。