基于BM25与Spring Boot的教材知识库RAG系统实战：从文档解析到检索基线搭建

1. 项目缘起：从“章鱼哥”到知识库，一个全栈RAG的实战起点

最近在社区里看到不少朋友在聊“Vibe Coding”和“RAG”，感觉这两个词快成新一代的“八股文”了。特别是那个“章鱼哥解题”系列，挺有意思的，它不像传统教程那样按部就班，更像是在解决一个具体、有趣的问题中，把前后端、AI、数据库这些技术串起来。这期要搞的是“教材知识库与检索基线”，说白了，就是给你一堆教材（比如PDF、Word文档），你能不能让AI像学霸一样，快速从里面找到答案并组织成通顺的回复？这就是RAG（检索增强生成）最经典的应用场景。

我自己之前也折腾过几个知识库项目，从最简单的关键词匹配到复杂的向量检索都踩过坑。这次借着“章鱼哥解题02”这个由头，我想抛开那些高大上的概念，实实在在地走一遍搭建流程。目标很明确：搭建一个最小可行产品（MVP）级别的教材知识库，并实现一个基础的检索基线。这个基线不仅要能“找得到”，还得为后续的优化（比如混合检索、重排序）打好地基。你会发现，全栈思维在这里至关重要——前端怎么让用户舒服地提问，后端如何高效处理查询和文档，AI模型怎么精准地生成答案，每一步都环环相扣。

2. 核心需求拆解：知识库到底要解决什么问题？

在动手写代码之前，我们必须想清楚这个“教材知识库”要干嘛。很多人一上来就找开源框架、调API，结果做出来的东西要么慢，要么不准，根本用不起来。根据“章鱼哥”的场景和常见的教学需求，我们可以把核心目标拆解为三层。

2.1 功能目标：精准、快速、可解释

第一层是功能目标，也就是用户能直接感受到的。

1. 精准检索（Recall & Precision）：这是核心中的核心。用户问“牛顿第二定律的公式是什么？”，系统必须能从《大学物理》教材的相应章节中准确找到相关内容，而不是返回一堆关于牛顿生平的段落。这涉及到检索的“召回率”（找到所有相关段落）和“精确率”（返回的段落是否都相关）。
2. 快速响应（Low Latency）：无论是学生考前突击，还是老师备课，都等不起。从用户提问到看到答案，整个流程（检索+生成）最好能在几秒内完成。这对后端架构和检索效率提出了要求。
3. 答案可读与可解释（Readability & Attribution）：AI生成的答案不能是生硬的片段堆砌，需要连贯、自然。更重要的是，必须注明答案来源（例如，来自《高等数学（第七版）》第120页）。这既是学术规范，也方便用户回溯核查，增加信任度。
4. 多格式文档支持：教材可能是PDF、Word、PPT甚至扫描图片。系统需要有能力解析这些常见格式，提取出纯文本和必要的元数据（如标题、章节）。

2.2 技术目标：构建一个可迭代的基线系统

第二层是技术目标，这是我们开发者要搭建的基石。

1. 建立检索基线（Baseline Retrieval）：在引入复杂的向量数据库和深度学习模型之前，先建立一个简单可靠的基线系统。这里BM25算法是绝佳的选择。它基于关键词的词频和逆文档频率进行搜索，虽然不理解语义，但在很多领域匹配任务上表现非常稳健，速度快，资源消耗小，是衡量更高级检索方法的“标尺”。
2. 设计可扩展的流水线（Pipeline）：整个系统应该被设计成一条清晰的流水线：文档加载 → 文本分割 → 向量化/索引 → 检索 → 重排 → 提示工程 → 生成。每个环节相对独立，方便日后替换或升级。例如，今天用BM25做检索，明天可以无缝接入Milvus做向量检索，后天可以加上一个重排序模型。
3. 全栈贯通（Full-Stack Integration）：这不是一个单纯的算法Demo。我们需要一个简单的前端界面供用户输入问题、展示答案和来源；一个健壮的后端服务来处理文档管理、检索逻辑和AI模型调用；以及一个持久化的存储来存放文档块和索引。

2.3 非功能目标：为真实环境做准备

第三层往往被忽略，但决定了项目能否从玩具变成工具。

1. 成本可控：特别是使用商用大模型API（如DeepSeek、Qwen）时，需要监控token消耗，设计缓存策略，避免因热门问题导致账单爆炸。
2. 部署简便：理想情况下，使用Docker Compose就能在本地或一台服务器上启动所有服务（前端、后端、数据库、检索服务）。
3. 内容安全与权限：虽然本次是实战项目，但真实场景下需考虑教材版权、用户访问权限等问题。

3. 技术选型与架构设计：为什么是这些组合？

明确了目标，就可以开始挑选“兵器”了。选型的原则是：在满足核心需求的前提下，选择社区活跃、文档清晰、易于集成和后续替换的技术。避免为了“炫技”而引入不必要的复杂度。

3.1 后端与检索核心

• 语言与框架：Spring Boot 3。Java生态成熟，性能好，尤其适合构建需要稳定处理并发请求的后端服务。Spring Boot能快速集成数据库、安全、监控等组件。虽然Python在AI领域更流行，但用Java构建核心业务逻辑和API层，通过HTTP或gRPC与Python的AI服务通信，是一种常见的、职责清晰的架构。
• 检索基线算法：BM25（Elasticsearch / Lucene实现）。如前所述，BM25是我们的基线。直接使用Elasticsearch（ES）或Apache Lucene库。ES提供了开箱即用的BM25支持、强大的全文搜索能力和便捷的REST API，但它本身是一个需要维护的中间件。对于这个MVP，为了极致轻量，我们可以考虑使用Lucene Core库直接在Java应用中嵌入索引和检索能力，减少外部依赖。
• 文本处理与向量化（为未来准备）：Sentence-Transformers + ONNX Runtime。虽然基线用BM25，但架构要为向量检索留好接口。我们可以用Python的sentence-transformers库生成文本的向量表示，然后通过ONNX Runtime将其转换为可在Java中高效运行的模型，避免跨语言调用的开销。初始阶段，生成的向量可以暂时存到数据库（如PostgreSQL的vector扩展）或本地文件，待后续引入Milvus或Qdrant等专业向量数据库。
• 大模型API：DeepSeek / Qwen。国内稳定、性价比高的选择。DeepSeek V4 Pro等模型在代码和推理上表现突出。通过其提供的API，我们可以完成答案生成的关键一步。

3.2 前端与数据存储

• 前端：React + Vite + Ant Design。React生态丰富，Vite构建速度快，Ant Design提供了大量现成的、美观的UI组件，能让我们快速搭建出一个可用的管理界面和问答界面。
• 数据库：PostgreSQL。作为主数据库，存储用户信息、文档元数据、对话记录等。强烈推荐使用pgvector扩展，这样同一套数据库系统就能同时处理结构化数据和向量数据，简化架构。这也是为什么热词里提到“linux 安装pgsql 开启rag 默认密码”，PostgreSQL在RAG系统中确实扮演着核心存储角色。
• 文档解析：Apache Tika + PDFBox。Tika是一个内容分析工具包，能处理几乎所有常见文档格式，提取文本和元数据。对于PDF，特别是复杂排版的教材，PDFBox能提供更精细的控制。

3.3 整体架构图景

基于以上选型，我们的系统架构会呈现如下形态：

1. 文档注入端：用户通过前端上传教材（PDF等）。后端接收文件，调用Tika/PDFBox解析，得到纯文本。
2. 文本处理流水线：纯文本经过清洗（去无用字符、格式化）后，被文本分割器（Text Splitter）切分成大小适中的“块”（Chunks）。这里的分块策略至关重要，块太大检索不精准，块太小会丢失上下文。通常按段落、按固定字符数（如500字）或使用语义分割模型进行。
3. 索引构建：
   • BM25索引：对每个文本块，使用Lucene建立倒排索引。
   • 向量索引（预留）：每个文本块通过ONNX Runtime的嵌入模型转换为向量，存入PostgreSQL的vector类型字段中。
4. 问答检索端：用户在前端提问。后端接收到问题后：
   • 同时进行BM25检索和（未来的）向量检索。
   • BM25检索快速返回一批基于关键词的相关文本块。
   • （未来）向量检索返回语义上相似的文本块。
   • 当前基线，我们只使用BM25的结果，取Top-K个（比如5个）相关度最高的块。
5. 答案生成：将用户问题和检索到的Top-K个文本块，通过精心设计的提示词（Prompt）组合成上下文，发送给DeepSeek/Qwen的Chat API。要求模型基于给定的上下文生成答案，并引用来源。
6. 结果呈现：前端展示AI生成的答案，并在答案下方清晰地列出引用的文本块及其出处（如文件名、章节标题）。

这个架构清晰地将传统全文检索（BM25）和现代语义检索（向量）的路径分开，让我们可以专注于打磨基线，同时为未来升级铺平道路。

4. 实战第一步：搭建基础环境与数据管道

理论说再多不如动手。我们首先把项目架子搭起来，并实现最枯燥但最重要的第一步：把一堆杂乱的教材文档，变成干净、可检索的文本块。

4.1 项目初始化与依赖管理

我们创建一个标准的Maven多模块项目，结构清晰：

textbook-rag-baseline/ ├── pom.xml (父工程) ├── rag-core/ // 核心业务逻辑：文档处理、检索 ├── rag-api/ // Spring Boot Web API 层 ├── rag-web/ // React前端项目 └── docker-compose.yml // 服务编排

在rag-core的pom.xml中，引入关键依赖：

<!-- Apache Lucene for BM25 --> <dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-core</artifactId> <version>9.10.0</version> </dependency> <dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-queryparser</artifactId> <version>9.10.0</version> </dependency> <!-- Apache Tika for document parsing --> <dependency> <groupId>org.apache.tika</groupId> <artifactId>tika-core</artifactId> <version>2.9.2</version> </dependency> <dependency> <groupId>org.apache.tika</groupId> <artifactId>tika-parser-standard-package</artifactId> <version>2.9.2</version> </dependency> <!-- PostgreSQL & Connection Pool --> <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>com.zaxxer</groupId> <artifactId>HikariCP</artifactId> </dependency>

同时，用Docker Compose快速拉起一个PostgreSQL数据库，并启用pgvector：

version: '3.8' services: postgres: image: ankane/pgvector:latest # 这个镜像预装了pgvector environment: POSTGRES_DB: textbook_rag POSTGRES_USER: admin POSTGRES_PASSWORD: your_secure_password_here # 务必修改！ ports: - "5432:5432" volumes: - postgres_data:/var/lib/postgresql/data volumes: postgres_data:

注意：永远不要使用“默认密码”或简单密码。热词中“linux 安装pgsql 开启rag 默认密码”是一个危险的提示，在生产环境中必须设置强密码，并通过环境变量注入，而非写在代码或Compose文件里。

4.2 文档解析与文本分块：细节决定成败

这是整个流水线的数据入口，质量直接决定上限。我们创建一个DocumentProcessor服务类。

1. 解析文档：

@Service public class DocumentProcessor { @Autowired private Tika tika; // 注入Tika实例 public ParsedDocument parse(File file) throws IOException, TikaException { Metadata metadata = new Metadata(); // 尝试从文件名、路径获取更多信息 metadata.set(TikaCoreProperties.RESOURCE_NAME_KEY, file.getName()); try (InputStream stream = TikaInputStream.get(file.toPath())) { String content = tika.parseToString(stream, metadata); // 提取元数据 String title = metadata.get(TikaCoreProperties.TITLE); if (StringUtils.isBlank(title)) { title = file.getName(); } // ... 提取其他元数据如作者、页数等 return new ParsedDocument(file.getName(), title, content, metadata); } } }

2. 文本分块（Chunking）： 这是最容易出问题的一步。直接按固定字符数（如500）切割会切断句子和段落，破坏语义。更好的策略是“递归式字符分割”：

public List<TextChunk> splitIntoChunks(ParsedDocument doc, int chunkSize, int chunkOverlap) { String text = doc.getContent(); // 1. 首先尝试按段落分割（\n\n） List<String> paragraphs = Arrays.stream(text.split("\\n\\n+")) .filter(p -> !p.trim().isEmpty()) .collect(Collectors.toList()); List<TextChunk> chunks = new ArrayList<>(); StringBuilder currentChunk = new StringBuilder(); for (String para : paragraphs) { // 如果当前段落加上新段落会超过chunkSize，且当前块已有内容，则保存当前块 if (currentChunk.length() + para.length() > chunkSize && currentChunk.length() > 0) { chunks.add(createChunk(currentChunk.toString(), doc)); // 开启新块，并保留重叠部分（滑动窗口） // 这里简化处理：新块从上一块的末尾部分开始 String lastChunkText = currentChunk.toString(); int overlapStart = Math.max(0, lastChunkText.length() - chunkOverlap); currentChunk = new StringBuilder(lastChunkText.substring(overlapStart)); } currentChunk.append(para).append("\n\n"); } // 添加最后一个块 if (currentChunk.length() > 0) { chunks.add(createChunk(currentChunk.toString(), doc)); } return chunks; }

实操心得：chunkSize和chunkOverlap是两个关键超参数。对于教材类文本，chunkSize=500-800字符，chunkOverlap=100-150字符是个不错的起点。重叠部分能防止关键信息被割裂在块边界。一定要为每个TextChunk保存完整的元数据：来源文档ID、文档名、在原文中的起始/结束位置（偏移量）。这是后续实现“精确引用”的生命线。

5. 实现BM25检索基线：让Lucene引擎转起来

有了干净的文本块，我们就可以构建检索的核心——BM25索引了。我们将索引操作封装成一个服务BM25RetrievalService。

5.1 构建内存中的Lucene索引

我们不引入Elasticsearch，而是直接用Lucene在应用内存或本地文件系统建索引，轻量且可控。

@Component public class BM25RetrievalService { private Directory directory; private IndexWriter writer; private IndexSearcher searcher; private final Path indexPath = Paths.get("./data/lucene-index"); @PostConstruct public void init() throws IOException { // 创建索引目录 Files.createDirectories(indexPath); directory = FSDirectory.open(indexPath); // 配置索引写入器，使用BM25相似度算法 IndexWriterConfig config = new IndexWriterConfig(new StandardAnalyzer()); config.setSimilarity(new BM25Similarity()); // 关键！设置BM25算法 config.setOpenMode(IndexWriterConfig.OpenMode.CREATE_OR_APPEND); writer = new IndexWriter(directory, config); // 先不打开searcher，等索引构建完再打开 } public void indexChunk(TextChunk chunk) throws IOException { Document doc = new Document(); // 存储字段：用于检索 doc.add(new TextField("content", chunk.getText(), Field.Store.YES)); // 存储字段：用于展示和引用 doc.add(new StringField("chunk_id", chunk.getId(), Field.Store.YES)); doc.add(new StringField("doc_name", chunk.getDocumentName(), Field.Store.YES)); doc.add(new StringField("doc_title", chunk.getDocumentTitle(), Field.Store.YES)); // 可以存储起始位置，用于高亮 doc.add(new IntPoint("start_offset", chunk.getStartOffset())); doc.add(new IntPoint("end_offset", chunk.getEndOffset())); doc.add(new StoredField("start_offset_s", chunk.getStartOffset())); doc.add(new StoredField("end_offset_s", chunk.getEndOffset())); writer.addDocument(doc); } public void commitAndRefresh() throws IOException { writer.commit(); writer.close(); // 重新打开搜索器以获取最新索引 DirectoryReader reader = DirectoryReader.open(directory); searcher = new IndexSearcher(reader); searcher.setSimilarity(new BM25Similarity()); // 搜索器也需设置 } }

关键点解析：BM25Similarity()是核心，它决定了文档打分的算法。TextField会对内容进行分析（分词、转小写等）并建立倒排索引，适用于全文搜索。StringField是整体索引，不分词，适合精确匹配。IntPoint和StoredField的配合，是为了既能做范围查询，又能存储值用于返回。

5.2 执行查询与处理结果

索引构建好后，就可以响应用户的查询了。

public List<RetrievedChunk> search(String query, int topK) throws IOException, ParseException { if (searcher == null) { throw new IllegalStateException("Searcher not initialized. Call commitAndRefresh first."); } // 使用QueryParser解析用户查询字符串 QueryParser parser = new QueryParser("content", new StandardAnalyzer()); Query luceneQuery = parser.parse(QueryParser.escape(query)); // 转义特殊字符 // 执行搜索 TopDocs topDocs = searcher.search(luceneQuery, topK); List<RetrievedChunk> results = new ArrayList<>(); for (ScoreDoc scoreDoc : topDocs.scoreDocs) { Document doc = searcher.doc(scoreDoc.doc); RetrievedChunk chunk = new RetrievedChunk(); chunk.setScore(scoreDoc.score); // BM25相关性分数 chunk.setText(doc.get("content")); chunk.setChunkId(doc.get("chunk_id")); chunk.setDocumentName(doc.get("doc_name")); chunk.setDocumentTitle(doc.get("doc_title")); chunk.setStartOffset(Integer.parseInt(doc.get("start_offset_s"))); chunk.setEndOffset(Integer.parseInt(doc.get("end_offset_s"))); results.add(chunk); } return results; }

避坑指南：QueryParser.escape(query)非常重要。如果用户输入了“C++”或“test*”这样的包含Lucene特殊字符（+, -, &&, ||, !, ( ), { }, [ ], ^, ”, ~, *, ?, :, /）的查询，不进行转义会导致解析异常。这是线上服务的一个常见故障点。

5.3 BM25的局限性认知

至此，我们的检索基线就完成了。但必须清醒认识到BM25的边界：

• 词汇不匹配问题：用户问“机器学习模型如何避免过拟合”，教材里写的是“防止过拟合的策略”，BM25可能因为关键词不匹配而检索失败。这是语义搜索（向量检索）要解决的。
• 无语义理解：BM25不知道“苹果”公司和“苹果”水果的区别。
• 长尾词权重过高：一些非常生僻的专业术语，因为逆文档频率（IDF）极高，可能会获得不成比例的高分，挤占更相关但用词更常见的结果。

所以，我们称它为“基线”。它的价值在于：快速验证流程、提供初步可用的结果、作为后续更高级检索算法（如向量检索、混合检索）的对比基准。

6. 集成大模型生成答案：Prompt工程是关键

检索到了相关的文本块，下一步就是让大模型“消化”这些材料，生成一个友好的答案。这里的关键是提示词（Prompt）工程。一个糟糕的Prompt会让最强大的模型输出垃圾。

6.1 设计系统化的Prompt模板

我们不能把问题和文本块简单拼接就扔给API。需要设计一个结构化的Prompt，明确告诉模型角色、任务、输入格式和输出要求。

public class PromptEngineer { private static final String PROMPT_TEMPLATE = """ 你是一个专业的教学助手，负责根据提供的教材内容片段，准确、清晰地回答学生的问题。 请严格遵守以下规则： 1. 答案必须严格基于下方提供的【相关上下文】生成。如果上下文不包含回答问题所需的信息，请直接说“根据提供的资料，我无法回答这个问题”。 2. 答案应组织得条理清晰，易于理解。 3. **必须**在答案中引用所使用的上下文。引用格式为：【文档名《文档标题》】。 4. 不要提及“根据上下文”或“如上文所述”这类模糊表述，直接引用具体来源。 5. 如果上下文信息存在矛盾，请指出这一点。 学生问题：%s 【相关上下文】 %s 请根据以上上下文，生成回答： """; public String buildPrompt(String userQuestion, List<RetrievedChunk> chunks) { // 将检索到的块格式化成上下文 StringBuilder contextBuilder = new StringBuilder(); for (RetrievedChunk chunk : chunks) { contextBuilder.append("来自 ") .append(chunk.getDocumentName()) .append("《") .append(chunk.getDocumentTitle()) .append("》") .append(" 的内容：\n") .append(chunk.getText()) .append("\n---\n"); } String context = contextBuilder.toString(); // 注意：需要计算总token数，避免超出模型限制。这里简单截断。 if (estimateTokens(context) > 6000) { // 假设模型上下文窗口为8K，留出空间给问题和答案 context = truncateTextByTokens(context, 6000); } return String.format(PROMPT_TEMPLATE, userQuestion, context); } // 简单的token估算（实际应用应使用模型对应的tokenizer） private int estimateTokens(String text) { // 近似估算：英文~1token/4字符，中文~1token/2字符。此处简化处理。 return text.length() / 2; } }

6.2 调用大模型API并解析结果

我们封装一个简单的AIClient来调用DeepSeek或Qwen的API。

@Service public class AIClientService { @Value("${ai.api.key}") private String apiKey; @Value("${ai.api.endpoint}") private String apiEndpoint; private final RestTemplate restTemplate; private final ObjectMapper objectMapper; public String generateAnswer(String prompt) { // 构建请求体，以DeepSeek V4 Pro为例 Map<String, Object> requestBody = new HashMap<>(); requestBody.put("model", "deepseek-chat"); List<Map<String, String>> messages = new ArrayList<>(); messages.add(Map.of("role", "user", "content", prompt)); requestBody.put("messages", messages); requestBody.put("temperature", 0.1); // 低温度，让输出更确定、更基于事实 requestBody.put("max_tokens", 1500); HttpHeaders headers = new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.setBearerAuth(apiKey); HttpEntity<Map<String, Object>> request = new HttpEntity<>(requestBody, headers); try { ResponseEntity<String> response = restTemplate.postForEntity(apiEndpoint, request, String.class); Map<String, Object> responseMap = objectMapper.readValue(response.getBody(), Map.class); // 解析响应，获取assistant的回复内容 // 实际解析逻辑需根据API返回格式调整，此处为示例 List<Map> choices = (List<Map>) responseMap.get("choices"); if (choices != null && !choices.isEmpty()) { Map<String, String> message = (Map<String, String>) choices.get(0).get("message"); return message.get("content"); } } catch (Exception e) { // 记录日志，并返回友好的错误信息 return "抱歉，AI服务暂时不可用，请稍后再试。"; } return "未能生成答案。"; } }

成本与性能优化提示：temperature设为较低值（如0.1）对于知识问答类任务很合适，能减少模型的随意发挥。务必在发送前估算Prompt的token数，并设置合理的max_tokens。对于长文档，可以考虑“Map-Reduce”策略：先让模型对每个检索到的块分别生成摘要或答案要点，再综合起来生成最终答案，但这会显著增加API调用次数和成本。

7. 前后端联调与效果初验

最后，我们把所有模块串联起来，提供一个完整的API，并搭建一个极简的前端进行测试。

7.1 构建RESTful API

在rag-api模块中，我们创建控制器：

@RestController @RequestMapping("/api/knowledge") public class KnowledgeBaseController { @Autowired private DocumentProcessingService docService; @Autowired private BM25RetrievalService retrievalService; @Autowired private AIClientService aiClient; @Autowired private PromptEngineer promptEngineer; @PostMapping("/upload") public ResponseEntity<String> uploadDocument(@RequestParam("file") MultipartFile file) { // 1. 保存文件 // 2. 调用docService解析并分块 // 3. 将块索引到BM25和向量库（预留） // 4. 返回处理结果 return ResponseEntity.ok("文档处理并索引完成"); } @PostMapping("/ask") public ResponseEntity<AnswerDTO> askQuestion(@RequestBody QuestionRequest request) { // 1. 使用BM25检索相关文本块 List<RetrievedChunk> chunks = retrievalService.search(request.getQuestion(), 5); // 2. 构建Prompt String prompt = promptEngineer.buildPrompt(request.getQuestion(), chunks); // 3. 调用大模型生成答案 String aiAnswer = aiClient.generateAnswer(prompt); // 4. 组装返回结果（包含答案和引用的来源列表） AnswerDTO answer = new AnswerDTO(); answer.setAnswer(aiAnswer); answer.setSources(chunks.stream().map(c -> new SourceDTO(c.getDocumentTitle(), c.getText())).collect(Collectors.toList())); return ResponseEntity.ok(answer); } }

7.2 简易React前端

前端使用React + Ant Design，核心是一个问答界面：

import React, { useState } from 'react'; import { Input, Button, Card, List, message } from 'antd'; const { TextArea } = Input; const QAInterface = () => { const [question, setQuestion] = useState(''); const [answer, setAnswer] = useState(''); const [sources, setSources] = useState([]); const [loading, setLoading] = useState(false); const handleAsk = async () => { if (!question.trim()) { message.warning('请输入问题'); return; } setLoading(true); try { const response = await fetch('/api/knowledge/ask', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ question }), }); const data = await response.json(); setAnswer(data.answer); setSources(data.sources || []); } catch (error) { message.error('请求失败'); } finally { setLoading(false); } }; return ( <div style={{ padding: '20px' }}> <h2>教材知识库问答</h2> <TextArea rows={4} value={question} onChange={(e) => setQuestion(e.target.value)} placeholder="请输入关于教材内容的问题..." /> <Button type="primary" onClick={handleAsk} loading={loading} style={{ marginTop: '10px' }}> 提问 </Button> {answer && ( <Card title="答案" style={{ marginTop: '20px' }}> <div style={{ whiteSpace: 'pre-wrap' }}>{answer}</div> </Card> )} {sources.length > 0 && ( <Card title="参考来源" style={{ marginTop: '20px' }}> <List dataSource={sources} renderItem={(item, index) => ( <List.Item> <List.Item.Meta title={`来源 ${index + 1}: ${item.docTitle}`} description={ <div style={{ maxHeight: '100px', overflow: 'auto' }}> {item.text} </div> } /> </List.Item> )} /> </Card> )} </div> ); }; export default QAInterface;

7.3 实测与基线评估

上传几本教材PDF（如计算机导论、线性代数），然后问一些问题。你会发现：

• 对于事实型、关键词匹配度高的问题，如“TCP和UDP的主要区别是什么？”，系统通常能快速从《计算机网络》教材中找到准确段落并生成好答案。
• 对于需要综合、推理或表述不同的问题，如“请用通俗的例子解释一下什么是梯度下降？”，效果可能不稳定。要么检索不到最相关的段落，要么模型生成的答案不够“通俗”。
• 检索结果的质量直接影响最终答案。如果BM25返回的前5个块都不够相关，再好的大模型也难为无米之炊。

这就是我们的基线水平。它已经是一个能工作的RAG系统，但离“好用”还有距离。接下来的优化方向非常明确：改进检索质量。这正是“检索基线”的意义所在——我们有了一个可以衡量进步的原点。

8. 从基线到优化：明确的进阶路线图

项目不会止步于此。这个基线系统就像一辆能跑的汽车，接下来我们要给它升级引擎、改善悬挂、装上导航。

1. 引入向量检索与混合搜索这是最直接的升级。将文本块通过sentence-transformers模型（如all-MiniLM-L6-v2）转换为向量，存入PostgreSQL的pgvector扩展中。当用户提问时：

• 将问题也转换为向量。
• 在向量数据库中进行相似度搜索（余弦相似度），返回Top-N个最相似的块。
• 关键步骤：将BM25的结果和向量检索的结果进行融合（Hybrid Search）。简单的做法可以是加权求和（如 BM25_score * 0.4 + Vector_similarity * 0.6），或者使用RRF（Reciprocal Rank Fusion）等更复杂的算法。这能同时利用关键词匹配和语义匹配的优势。

2. 实现重排序（Re-ranking）混合检索返回的候选集可能仍然有噪音。可以引入一个轻量级的、专门用于重排序的模型（如BAAI/bge-reranker-base），对Top-20或Top-30的候选块进行更精细的相关性打分，重新排序后再取Top-5送给大模型。这能显著提升最终上下文的质量。

3. 优化文本分块与元数据尝试更智能的分块策略，如按章节标题分割、使用语义分割模型。为每个块添加更丰富的元数据（所属章节、重要程度标签等），在检索时可以利用这些元数据进行过滤或加权。

4. 前端与用户体验优化实现流式输出（SSE），让答案逐字显示；增加对话历史管理；实现来源的高亮显示；构建一个文档管理后台，方便上传、查看和删除知识库内容。

5. 系统监控与评估建立评估体系，不仅靠人工测试，可以构建一个测试集（Q&A对），定期跑批处理，计算检索的命中率、答案的准确率（可以用GPT-4作为裁判）。监控API调用耗时、Token消耗和成本。

搭建这个基线系统的过程，远比直接调用某个现成的LangChain或Dify流水线收获更大。你亲手处理了文档解析、文本分块、索引构建、查询处理、Prompt工程和系统集成中的每一个细节。当遇到检索不准时，你会去检查分块策略；当答案胡言乱语时，你会去优化Prompt。这种对系统每一环的掌控感，是“Vibe Coding”和“全栈实战”的精髓——不是在框架的阴影下填空，而是在理解的基础上创造。从这个坚实的基线出发，无论是向混合检索、Agentic RAG迈进，还是应对更复杂的业务场景，你都有了清晰的路径和调试的底气。