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

1. 项目缘起从“章鱼哥”到知识库一个全栈RAG的实战起点最近在社区里看到不少朋友在聊“Vibe Coding”和“RAG”感觉这两个词快成新一代的“八股文”了。特别是那个“章鱼哥解题”系列挺有意思的它不像传统教程那样按部就班更像是在解决一个具体、有趣的问题中把前后端、AI、数据库这些技术串起来。这期要搞的是“教材知识库与检索基线”说白了就是给你一堆教材比如PDF、Word文档你能不能让AI像学霸一样快速从里面找到答案并组织成通顺的回复这就是RAG检索增强生成最经典的应用场景。我自己之前也折腾过几个知识库项目从最简单的关键词匹配到复杂的向量检索都踩过坑。这次借着“章鱼哥解题02”这个由头我想抛开那些高大上的概念实实在在地走一遍搭建流程。目标很明确搭建一个最小可行产品MVP级别的教材知识库并实现一个基础的检索基线。这个基线不仅要能“找得到”还得为后续的优化比如混合检索、重排序打好地基。你会发现全栈思维在这里至关重要——前端怎么让用户舒服地提问后端如何高效处理查询和文档AI模型怎么精准地生成答案每一步都环环相扣。2. 核心需求拆解知识库到底要解决什么问题在动手写代码之前我们必须想清楚这个“教材知识库”要干嘛。很多人一上来就找开源框架、调API结果做出来的东西要么慢要么不准根本用不起来。根据“章鱼哥”的场景和常见的教学需求我们可以把核心目标拆解为三层。2.1 功能目标精准、快速、可解释第一层是功能目标也就是用户能直接感受到的。精准检索Recall Precision这是核心中的核心。用户问“牛顿第二定律的公式是什么”系统必须能从《大学物理》教材的相应章节中准确找到相关内容而不是返回一堆关于牛顿生平的段落。这涉及到检索的“召回率”找到所有相关段落和“精确率”返回的段落是否都相关。快速响应Low Latency无论是学生考前突击还是老师备课都等不起。从用户提问到看到答案整个流程检索生成最好能在几秒内完成。这对后端架构和检索效率提出了要求。答案可读与可解释Readability AttributionAI生成的答案不能是生硬的片段堆砌需要连贯、自然。更重要的是必须注明答案来源例如来自《高等数学第七版》第120页。这既是学术规范也方便用户回溯核查增加信任度。多格式文档支持教材可能是PDF、Word、PPT甚至扫描图片。系统需要有能力解析这些常见格式提取出纯文本和必要的元数据如标题、章节。2.2 技术目标构建一个可迭代的基线系统第二层是技术目标这是我们开发者要搭建的基石。建立检索基线Baseline Retrieval在引入复杂的向量数据库和深度学习模型之前先建立一个简单可靠的基线系统。这里BM25算法是绝佳的选择。它基于关键词的词频和逆文档频率进行搜索虽然不理解语义但在很多领域匹配任务上表现非常稳健速度快资源消耗小是衡量更高级检索方法的“标尺”。设计可扩展的流水线Pipeline整个系统应该被设计成一条清晰的流水线文档加载 → 文本分割 → 向量化/索引 → 检索 → 重排 → 提示工程 → 生成。每个环节相对独立方便日后替换或升级。例如今天用BM25做检索明天可以无缝接入Milvus做向量检索后天可以加上一个重排序模型。全栈贯通Full-Stack Integration这不是一个单纯的算法Demo。我们需要一个简单的前端界面供用户输入问题、展示答案和来源一个健壮的后端服务来处理文档管理、检索逻辑和AI模型调用以及一个持久化的存储来存放文档块和索引。2.3 非功能目标为真实环境做准备第三层往往被忽略但决定了项目能否从玩具变成工具。成本可控特别是使用商用大模型API如DeepSeek、Qwen时需要监控token消耗设计缓存策略避免因热门问题导致账单爆炸。部署简便理想情况下使用Docker Compose就能在本地或一台服务器上启动所有服务前端、后端、数据库、检索服务。内容安全与权限虽然本次是实战项目但真实场景下需考虑教材版权、用户访问权限等问题。3. 技术选型与架构设计为什么是这些组合明确了目标就可以开始挑选“兵器”了。选型的原则是在满足核心需求的前提下选择社区活跃、文档清晰、易于集成和后续替换的技术。避免为了“炫技”而引入不必要的复杂度。3.1 后端与检索核心语言与框架Spring Boot 3。Java生态成熟性能好尤其适合构建需要稳定处理并发请求的后端服务。Spring Boot能快速集成数据库、安全、监控等组件。虽然Python在AI领域更流行但用Java构建核心业务逻辑和API层通过HTTP或gRPC与Python的AI服务通信是一种常见的、职责清晰的架构。检索基线算法BM25Elasticsearch / Lucene实现。如前所述BM25是我们的基线。直接使用ElasticsearchES或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等专业向量数据库。大模型APIDeepSeek / 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 整体架构图景基于以上选型我们的系统架构会呈现如下形态文档注入端用户通过前端上传教材PDF等。后端接收文件调用Tika/PDFBox解析得到纯文本。文本处理流水线纯文本经过清洗去无用字符、格式化后被文本分割器Text Splitter切分成大小适中的“块”Chunks。这里的分块策略至关重要块太大检索不精准块太小会丢失上下文。通常按段落、按固定字符数如500字或使用语义分割模型进行。索引构建BM25索引对每个文本块使用Lucene建立倒排索引。向量索引预留每个文本块通过ONNX Runtime的嵌入模型转换为向量存入PostgreSQL的vector类型字段中。问答检索端用户在前端提问。后端接收到问题后同时进行BM25检索和未来的向量检索。BM25检索快速返回一批基于关键词的相关文本块。未来向量检索返回语义上相似的文本块。当前基线我们只使用BM25的结果取Top-K个比如5个相关度最高的块。答案生成将用户问题和检索到的Top-K个文本块通过精心设计的提示词Prompt组合成上下文发送给DeepSeek/Qwen的Chat API。要求模型基于给定的上下文生成答案并引用来源。结果呈现前端展示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 groupIdorg.apache.lucene/groupId artifactIdlucene-core/artifactId version9.10.0/version /dependency dependency groupIdorg.apache.lucene/groupId artifactIdlucene-queryparser/artifactId version9.10.0/version /dependency !-- Apache Tika for document parsing -- dependency groupIdorg.apache.tika/groupId artifactIdtika-core/artifactId version2.9.2/version /dependency dependency groupIdorg.apache.tika/groupId artifactIdtika-parser-standard-package/artifactId version2.9.2/version /dependency !-- PostgreSQL Connection Pool -- dependency groupIdorg.postgresql/groupId artifactIdpostgresql/artifactId scoperuntime/scope /dependency dependency groupIdcom.zaxxer/groupId artifactIdHikariCP/artifactId /dependency同时用Docker Compose快速拉起一个PostgreSQL数据库并启用pgvectorversion: 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 ListTextChunk splitIntoChunks(ParsedDocument doc, int chunkSize, int chunkOverlap) { String text doc.getContent(); // 1. 首先尝试按段落分割\n\n ListString paragraphs Arrays.stream(text.split(\\n\\n)) .filter(p - !p.trim().isEmpty()) .collect(Collectors.toList()); ListTextChunk 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是两个关键超参数。对于教材类文本chunkSize500-800字符chunkOverlap100-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 ListRetrievedChunk 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); ListRetrievedChunk 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, ListRetrievedChunk 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为例 MapString, Object requestBody new HashMap(); requestBody.put(model, deepseek-chat); ListMapString, 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); HttpEntityMapString, Object request new HttpEntity(requestBody, headers); try { ResponseEntityString response restTemplate.postForEntity(apiEndpoint, request, String.class); MapString, Object responseMap objectMapper.readValue(response.getBody(), Map.class); // 解析响应获取assistant的回复内容 // 实际解析逻辑需根据API返回格式调整此处为示例 ListMap choices (ListMap) responseMap.get(choices); if (choices ! null !choices.isEmpty()) { MapString, String message (MapString, 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 ResponseEntityString uploadDocument(RequestParam(file) MultipartFile file) { // 1. 保存文件 // 2. 调用docService解析并分块 // 3. 将块索引到BM25和向量库预留 // 4. 返回处理结果 return ResponseEntity.ok(文档处理并索引完成); } PostMapping(/ask) public ResponseEntityAnswerDTO askQuestion(RequestBody QuestionRequest request) { // 1. 使用BM25检索相关文本块 ListRetrievedChunk 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 typeprimary 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或者使用RRFReciprocal Rank Fusion等更复杂的算法。这能同时利用关键词匹配和语义匹配的优势。2. 实现重排序Re-ranking混合检索返回的候选集可能仍然有噪音。可以引入一个轻量级的、专门用于重排序的模型如BAAI/bge-reranker-base对Top-20或Top-30的候选块进行更精细的相关性打分重新排序后再取Top-5送给大模型。这能显著提升最终上下文的质量。3. 优化文本分块与元数据尝试更智能的分块策略如按章节标题分割、使用语义分割模型。为每个块添加更丰富的元数据所属章节、重要程度标签等在检索时可以利用这些元数据进行过滤或加权。4. 前端与用户体验优化实现流式输出SSE让答案逐字显示增加对话历史管理实现来源的高亮显示构建一个文档管理后台方便上传、查看和删除知识库内容。5. 系统监控与评估建立评估体系不仅靠人工测试可以构建一个测试集QA对定期跑批处理计算检索的命中率、答案的准确率可以用GPT-4作为裁判。监控API调用耗时、Token消耗和成本。搭建这个基线系统的过程远比直接调用某个现成的LangChain或Dify流水线收获更大。你亲手处理了文档解析、文本分块、索引构建、查询处理、Prompt工程和系统集成中的每一个细节。当遇到检索不准时你会去检查分块策略当答案胡言乱语时你会去优化Prompt。这种对系统每一环的掌控感是“Vibe Coding”和“全栈实战”的精髓——不是在框架的阴影下填空而是在理解的基础上创造。从这个坚实的基线出发无论是向混合检索、Agentic RAG迈进还是应对更复杂的业务场景你都有了清晰的路径和调试的底气。