企业官网建设流程全解析

在实际的大模型应用开发中，直接让模型回答用户问题往往会遇到知识过时、幻觉和缺乏专业领域知识的问题。检索增强生成（RAG）技术通过将外部知识库与大型语言模型结合，成为了解决这些问题的核心方案。然而，从概念到落地，一个高效的RAG系统远不止是“向量检索+生成”这么简单，它涉及文档处理、检索、召回、重排、生成等多个环节的精细调优，任何一个环节的短板都会导致最终效果大打折扣。

本文面向希望构建或优化RAG应用的开发者，将系统性地拆解RAG的全链路，从文档接入、切片策略、向量化索引，到混合检索、重排序，再到工程化落地中的常见陷阱与调优策略。我们将结合一个基于 Spring Boot 和 Milvus 的实战项目，展示如何将理论转化为可运行的代码，并重点分析如何通过策略组合提升检索质量，让你在构建企业级知识库或智能问答系统时，能够清晰地定位问题、实施优化，避免在工程实践中走弯路。

1. 理解RAG：不只是检索，而是增强生成的全链路

RAG（Retrieval-Augmented Generation）的核心思想是在大模型生成答案之前，先从外部知识库中检索出与问题相关的文档片段，然后将这些片段作为上下文与问题一同提交给大模型，从而生成更准确、更具事实依据的答案。

1.1 RAG的基本工作流程

一个典型的RAG流程可以分解为以下几个阶段：

1. 索引构建（Indexing）：这是离线准备阶段。将原始文档（如PDF、Word、网页）进行清洗、解析，分割成更小的文本块（Chunk），然后将这些文本块转化为向量（Embedding），并存入向量数据库构建索引。
2. 检索与召回（Retrieval）：这是在线服务阶段。当用户提问时，先将问题转化为向量，然后在向量数据库中进行相似度搜索（如余弦相似度），找出最相关的K个文本块。这个过程称为“召回”。
3. 后处理与重排（Reranking）：初步召回的结果可能包含相关性不高或冗余的信息。重排阶段使用一个更精细的模型（通常比生成模型小，但比向量模型更懂语义）对召回的文档进行重新排序，筛选出最相关的几个片段。
4. 提示工程与生成（Generation）：将重排后的顶级相关文档作为上下文，与用户问题一起构造成提示（Prompt），提交给大语言模型（LLM），由LLM生成最终答案。

1.2 为什么需要全链路调优？

很多初建的RAG系统效果不佳，往往是因为只关注了其中一两个环节。例如：

• 文档切片不合理：切片过大，包含无关信息，干扰模型；切片过小，丢失关键上下文，导致信息碎片化。
• 检索策略单一：仅依赖向量检索，对关键词匹配、业务规则等考虑不足，可能漏掉关键文档。
• 缺乏重排环节：向量检索返回的“最相似”片段，在语义上未必是“最相关”的，直接交给LLM可能导致答案偏离。
• 工程化细节缺失：没有处理文档更新、版本管理、多知识库路由、检索结果冲突等问题。

因此，构建一个健壮的RAG系统，必须对全链路有清晰的认识和针对性的设计。

2. 环境准备与核心组件选型

在开始实战之前，我们需要搭建开发环境并选择合适的技术组件。本实战项目将构建一个基于Java技术栈的本地化RAG问答系统。

2.1 开发环境与依赖

• JDK: 17 或以上版本。
• 构建工具: Maven 或 Gradle。
• IDE: IntelliJ IDEA 或 Eclipse。
• 向量数据库: Milvus（单机版），用于存储和检索向量。
• 嵌入模型: 选用一个开源的、支持本地部署的文本嵌入模型，例如BAAI/bge-small-zh-v1.5，它针对中文进行了优化。
• 大语言模型（LLM）: 为了演示完整流程，我们使用 OpenAI 的 GPT 系列（需API Key）或本地部署的Ollama（如qwen:7b）。生产环境可根据实际情况选择。
• 重排模型: 可以使用BAAI/bge-reranker-base等专门的重排模型。

2.2 项目依赖配置 (Maven)

创建一个Spring Boot项目，并在pom.xml中添加以下核心依赖：

<dependencies> <!-- Spring Boot Web --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- LangChain4j - 核心RAG框架 --> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j</artifactId> <version>0.31.0</version> <!-- 请使用最新稳定版 --> </dependency> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-embeddings-all-minilm-l6-v2</artifactId> <!-- 本地嵌入模型 --> <version>0.31.0</version> </dependency> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-milvus</artifactId> <!-- Milvus集成 --> <version>0.31.0</version> </dependency> <!-- 用于文档解析（如PDF） --> <dependency> <groupId>org.apache.tika</groupId> <artifactId>tika-core</artifactId> <version>2.9.1</version> </dependency> <!-- Lombok --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> </dependencies>

注意：LangChain4j版本迭代较快，请根据官方文档使用最新版本。如果使用OpenAI，还需添加langchain4j-open-ai依赖。

2.3 基础设施准备：启动Milvus

使用Docker快速启动一个单机版Milvus：

# 拉取最新镜像 docker pull milvusdb/milvus:latest # 运行Milvus单机版 docker run -d --name milvus-standalone \ -p 19530:19530 \ -p 9091:9091 \ milvusdb/milvus:latest

启动后，Milvus的gRPC服务端口（19530）和Web管理端口（9091）将暴露在本地。可以通过http://localhost:9091访问Milvus Attu（管理界面）进行可视化操作。

3. RAG核心链路实现：从文档到答案

我们将按照索引构建、检索召回、重排、生成的顺序，实现一个最小可运行的RAG问答服务。

3.1 第一步：文档接入、清洗与切片

原始文档需要被处理成结构化的文本块。切片策略是影响召回精度的首要因素。

关键配置类：DocumentProcessorConfig

import dev.langchain4j.data.document.Document; import dev.langchain4j.data.document.DocumentSplitter; import dev.langchain4j.data.document.splitter.DocumentSplitters; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import java.nio.file.Path; import java.nio.file.Paths; @Configuration public class DocumentProcessorConfig { @Value("${rag.document.chunk-size:500}") private int chunkSize; @Value("${rag.document.chunk-overlap:50}") private int chunkOverlap; /** * 配置文档分割器。 * 使用递归字符分割器，按段落、句子、单词等自然边界分割。 * chunkSize: 每个文本块的最大字符数。 * chunkOverlap: 块与块之间的重叠字符数，用于保持上下文连贯。 */ @Bean public DocumentSplitter documentSplitter() { return DocumentSplitters.recursive(chunkSize, chunkOverlap); } /** * 加载文档（示例：从文件系统）。 * 实际项目中可能需要支持PDF、Word、HTML、Notion、Confluence等多种来源。 */ public Document loadDocument(String filePath) throws IOException { Path path = Paths.get(filePath); // LangChain4j 提供了多种DocumentLoader，这里使用文本文件加载器 // 对于PDF等复杂格式，需要集成Apache Tika或PDFBox Document document = FileSystemDocumentLoader.loadDocument(path); return document; } }

切片策略调优要点：

• chunkSize（块大小）：通常设置在200-1000字符之间。太小会丢失上下文，太大会引入噪声。对于技术文档，500左右是个不错的起点。
• chunkOverlap（块重叠）：设置重叠可以防止关键信息被切在块边界而丢失。通常为块大小的10%-20%。
• 更高级的策略：可以按标题分割、按语义分割（使用嵌入模型计算句子相似度进行切分），或者混合策略。

3.2 第二步：向量化与索引构建

文本块需要被转化为向量（嵌入），并存入向量数据库。

关键服务类：EmbeddingService与VectorStoreService

import dev.langchain4j.data.embedding.Embedding; import dev.langchain4j.model.embedding.EmbeddingModel; import dev.langchain4j.store.embedding.EmbeddingStore; import dev.langchain4j.store.embedding.milvus.MilvusEmbeddingStore; import lombok.RequiredArgsConstructor; import org.springframework.stereotype.Service; import java.util.List; @Service @RequiredArgsConstructor public class VectorStoreService { private final EmbeddingModel embeddingModel; // 注入嵌入模型Bean private final EmbeddingStore<TextSegment> embeddingStore; // 注入向量存储Bean /** * 将文档列表向量化并存入Milvus。 * @param textSegments 分割后的文本块列表 */ public void indexDocuments(List<TextSegment> textSegments) { // 批量生成向量 List<Embedding> embeddings = embeddingModel.embedAll(textSegments).content(); // 将文本块与其对应的向量一起存储 embeddingStore.addAll(embeddings, textSegments); // Milvus会自动创建集合（Collection）和索引（Index） } /** * 根据查询文本检索相似向量。 * @param query 用户查询 * @param maxResults 最大返回结果数（召回数） * @return 检索到的文本块列表 */ public List<EmbeddingMatch<TextSegment>> search(String query, int maxResults) { // 将查询文本转化为向量 Embedding queryEmbedding = embeddingModel.embed(query).content(); // 在向量库中进行相似度搜索 return embeddingStore.findRelevant(queryEmbedding, maxResults); } }

配置嵌入模型和向量存储：

@Configuration public class EmbeddingConfig { @Bean public EmbeddingModel embeddingModel() { // 使用本地嵌入模型（All-MiniLM-L6-v2），无需API Key return new AllMiniLmL6V2EmbeddingModel(); // 若使用OpenAI: return new OpenAiEmbeddingModel("your-api-key", "text-embedding-ada-002"); } @Bean public EmbeddingStore<TextSegment> embeddingStore() { // 配置Milvus连接和集合参数 MilvusEmbeddingStore.Configuration config = MilvusEmbeddingStore.Configuration.builder() .host("localhost") .port(19530) .collectionName("rag_demo_collection") .dimension(384) // 必须与嵌入模型维度一致！All-MiniLM-L6-v2是384维 .indexType(IndexType.IVF_FLAT) .metricType(MetricType.COSINE) .build(); return new MilvusEmbeddingStore(config); } }

关键点：dimension必须与你选用的嵌入模型输出的向量维度完全一致，否则存储和检索会失败。

3.3 第三步：混合检索与重排序策略

单纯使用向量检索（语义搜索）可能在某些场景下失效，例如专有名词、缩写、代码片段。混合检索结合了语义搜索和关键词搜索（如BM25），能提升召回率。

实现混合检索服务：

@Service public class HybridRetrievalService { private final VectorStoreService vectorStoreService; private final KeywordSearchService keywordSearchService; // 假设有一个基于Lucene/Elasticsearch的关键词检索服务 private final RerankerService rerankerService; public List<TextSegment> hybridSearch(String query, int initialRecallCount) { // 1. 并行执行两种检索 List<EmbeddingMatch<TextSegment>> vectorResults = vectorStoreService.search(query, initialRecallCount * 2); // 多召回一些 List<TextSegment> keywordResults = keywordSearchService.search(query, initialRecallCount * 2); // 2. 结果融合（简单去重后合并） Set<TextSegment> combinedSet = new LinkedHashSet<>(); // 可以给不同来源的结果赋予权重，这里简单合并 vectorResults.forEach(match -> combinedSet.add(match.embedded())); combinedSet.addAll(keywordResults); List<TextSegment> combinedList = new ArrayList<>(combinedSet); // 3. 重排序：使用重排模型对合并后的结果进行精排 if (rerankerService != null && !combinedList.isEmpty()) { combinedList = rerankerService.rerank(query, combinedList); } // 4. 返回Top N个最终结果 int finalTopN = 5; // 最终交给LLM的上下文数量 return combinedList.subList(0, Math.min(finalTopN, combinedList.size())); } }

实现重排服务：

重排模型通常是一个交叉编码器（Cross-Encoder），它同时接收查询和文档，输出一个相关性分数，比双编码器（如向量模型）的点积计算更精确。

@Service public class RerankerService { // 这里以调用远程重排模型API为例，本地部署类似 public List<TextSegment> rerank(String query, List<TextSegment> candidates) { // 构造 (query, document) 对 List<Pair<String, String>> pairs = candidates.stream() .map(seg -> Pair.of(query, seg.text())) .collect(Collectors.toList()); // 调用重排模型API获取分数（伪代码，实际需集成具体SDK） // List<Float> scores = rerankerModelClient.predict(pairs); List<Float> scores = mockRerankScores(pairs); // 模拟 // 根据分数对候选文档排序 List<IndexedScore> indexedScores = new ArrayList<>(); for (int i = 0; i < candidates.size(); i++) { indexedScores.add(new IndexedScore(i, scores.get(i))); } indexedScores.sort((a, b) -> Float.compare(b.score, a.score)); // 降序 // 返回重排后的文档列表 return indexedScores.stream() .map(is -> candidates.get(is.index)) .collect(Collectors.toList()); } private static class IndexedScore { int index; float score; // ... constructor, getters } }

3.4 第四步：提示工程与答案生成

将重排后的顶级相关文档作为上下文，构造提示词，调用LLM生成最终答案。

关键服务类：QAService

@Service @RequiredArgsConstructor public class QAService { private final HybridRetrievalService retrievalService; private final ChatLanguageModel chatModel; // 注入LLM，如OpenAiChatModel或Ollama public String answerQuestion(String userQuestion) { // 1. 检索相关文档片段 List<TextSegment> relevantSegments = retrievalService.hybridSearch(userQuestion, 10); // 2. 构建提示词（Prompt） String context = relevantSegments.stream() .map(TextSegment::text) .collect(Collectors.joining("\n\n---\n\n")); String promptTemplate = """ 请基于以下上下文信息回答问题。如果上下文信息不足以回答问题，请直接说“根据已知信息无法回答该问题”，不要编造信息。 上下文： %s 问题：%s 请用中文给出专业、准确的答案： """; String prompt = String.format(promptTemplate, context, userQuestion); // 3. 调用LLM生成答案 Response<AiMessage> response = chatModel.generate(prompt); return response.content().text(); } }

配置LLM：

@Configuration public class LlmConfig { @Bean @ConditionalOnProperty(name = "llm.provider", havingValue = "openai") public ChatLanguageModel openAiChatModel(@Value("${openai.api.key}") String apiKey) { return OpenAiChatModel.builder() .apiKey(apiKey) .modelName("gpt-3.5-turbo") .temperature(0.2) // 低温度使输出更确定 .build(); } @Bean @ConditionalOnProperty(name = "llm.provider", havingValue = "ollama") public ChatLanguageModel ollamaChatModel() { return OllamaChatModel.builder() .baseUrl("http://localhost:11434") .modelName("qwen:7b") .temperature(0.2) .build(); } }

3.5 第五步：组装与API暴露

最后，我们创建一个REST控制器来提供问答接口。

@RestController @RequestMapping("/api/rag") @RequiredArgsConstructor public class RagController { private final QAService qaService; @PostMapping("/ask") public ResponseEntity<AnswerResponse> askQuestion(@RequestBody QuestionRequest request) { try { String answer = qaService.answerQuestion(request.getQuestion()); return ResponseEntity.ok(new AnswerResponse(answer)); } catch (Exception e) { return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR) .body(new AnswerResponse("系统处理问题时出错：" + e.getMessage())); } } // 请求/响应DTO @Data public static class QuestionRequest { private String question; } @Data public static class AnswerResponse { private String answer; // 可以扩展，如返回引用的文档片段ID public AnswerResponse(String answer) { this.answer = answer; } } }

启动Spring Boot应用后，就可以通过POST /api/rag/ask接口进行提问了。

4. 工程化落地：关键问题与调优策略

项目能运行只是第一步，要让RAG系统在生产环境稳定、高效地工作，还需要解决一系列工程问题。

4.1 多知识库管理与路由

当系统内有多个独立的知识库（如产品手册、内部API文档、客服问答库）时，需要根据问题自动或手动选择正确的知识库进行检索。

解决方案：

1. 元数据过滤：在存储向量时，为每个文本块添加knowledge_base_id等元数据。检索时，通过元数据过滤器限定搜索范围。
2. 路由模型：训练一个轻量级分类模型，根据用户问题判断其所属的知识库类别。
3. 前端选择：在用户界面上让用户手动选择知识库。

在Milvus中，可以在创建集合时定义元数据字段，并在搜索时通过expr参数进行过滤。

4.2 检索结果冲突与去重

混合检索或从不同来源召回的结果可能存在大量重复或高度相似的片段，直接交给LLM会浪费上下文窗口并可能造成混淆。

处理策略：

• 基于嵌入的去重：计算召回片段之间的余弦相似度，超过阈值则去重。
• 基于内容的去重：使用MinHash、SimHash等算法进行文本去重。
• 多样化重排：在重排模型中引入多样性惩罚，避免返回内容过于同质化的结果。

4.3 文档更新与增量索引

知识库的内容是动态变化的。需要一套机制来处理文档的增、删、改。

• 增量更新：为每个文档块生成唯一ID（如基于内容哈希）。更新时，先删除旧文档对应的所有块，再插入新块。Milvus支持通过ID删除。
• 版本管理：更复杂的场景可能需要维护文档版本，检索时指定版本号。
• 定时任务：设置定时任务扫描文档源（如Git仓库、Confluence），发现变更后触发索引更新。

4.4 效果评估与监控

没有评估就无法优化。需要建立一套评估体系。

• 人工评估：构建测试集（Q&A对），定期人工评估答案的准确性、相关性和流畅性。
• 自动评估指标：
  • 检索阶段：计算召回率（Recall@K）、平均精度（MAP）、归一化折损累计增益（NDCG）。
  • 生成阶段：使用ROUGE、BLEU等指标对比生成答案与参考答案的相似度，但需谨慎，这些指标与人类判断并非完全一致。
• 业务监控：记录用户提问、检索到的文档、生成的答案、用户反馈（如有）。分析高频未命中问题、低满意度问题，针对性优化切片策略或补充知识库。

4.5 性能与成本优化

• 索引优化：根据数据规模和查询性能要求，选择合适的Milvus索引类型（如IVF_FLAT, HNSW）和参数。
• 缓存策略：对高频或相同的问题及其检索结果进行缓存，减少对向量数据库和LLM的调用。
• 异步处理：文档解析、向量化、索引构建等耗时操作应异步执行，避免阻塞主请求链路。
• LLM调用优化：合理设置上下文窗口大小，对答案长度进行限制。考虑使用更经济的模型或对非关键查询使用缓存答案。

5. 常见问题排查清单

在开发和运维RAG系统时，你会遇到各种问题。下面是一个快速排查清单。

6. 进阶方向与最佳实践

掌握了基础链路和问题排查后，可以考虑以下方向进一步提升系统能力：

• Self-RAG / Adaptive RAG：让模型自己判断是否需要检索、何时检索、检索什么，实现更智能的检索决策。
• 多模态RAG：支持图像、表格、音频等非文本知识的检索与生成。
• 图增强检索：利用知识图谱中的实体关系来改善检索路径，解决复杂、多跳问题。
• Agentic RAG：将RAG系统作为智能体（Agent）的工具之一，使其能够自主规划、调用工具、完成复杂任务。
• 端到端评估与持续学习：建立自动化评估流水线，利用用户反馈数据持续优化切片、检索和生成模型。

构建一个高质量的RAG系统是一个持续迭代的过程。从简单的向量检索开始，逐步引入更精细的文档处理、混合检索、重排序和提示工程，同时建立完善的评估、监控和更新机制，才能使其真正成为可靠的知识助手。本文提供的代码和思路是一个坚实的起点，在实际项目中，请务必根据你的具体数据、领域和性能要求进行深入的调优和测试。