手把手教你构建企业级RAG智慧问答系统：融合MySQL关键词检索与Milvus语义检索的完整实践

手把手教你构建企业级RAG智慧问答系统融合MySQL关键词检索与Milvus语义检索的完整实践本文基于传智教育EduRAG项目深入剖析一个完整的RAG检索增强生成智慧问答系统的设计与实现。系统采用两级检索架构第一级BM25关键词匹配快速返回高频问答第二级RAG语义检索处理复杂专业问题并结合BERT查询分类、四种检索策略、BGE-M3混合检索、BGE-Reranker重排序等技术构建了一个工程化、可落地的企业级问答系统。一、项目背景为什么需要RAG随着ChatGPT等大语言模型LLM的广泛应用AI在教育、客服、医疗等垂直领域的落地需求日益迫切。然而通用大模型存在两个致命问题知识时效性模型训练数据截止日期后的事件完全不知私有知识盲区无法获取企业内部的专有知识和文档这导致大模型在垂直场景中频繁出现幻觉Hallucination——一本正经地胡说八道。解决这一问题的两条主流路径是微调Fine-tuning将领域知识融入模型参数成本高、更新困难RAGRetrieval-Augmented Generation检索增强生成外挂知识库实时检索相关文档喂给LLM成本低、知识可热更新 ✅本文介绍的EduRAG智慧问答系统正是基于RAG架构结合LangChain Qwen大模型 Milvus向量数据库 MySQL为IT教育培训场景打造的智能答疑平台。二、系统整体架构2.1 两级检索架构设计系统的核心设计理念是快慢结合、分级响应用户查询 │ ▼ ┌─────────────────────────────────────────────┐ │ 第1级BM25关键词匹配 (MySQL FAQ知识库) │ │ ├─ Softmax分数 ≥ 0.85 → 直接返回预存答案 │ │ └─ 分数 0.85 → 进入第2级 │ └─────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ 第2级RAG语义检索 (Milvus向量知识库) │ │ ├─ BERT查询分类 (通用知识/专业咨询) │ │ ├─ LLM策略选择 (直接/子查询/HyDE/回溯) │ │ ├─ BGE-M3混合检索 (Dense Sparse) │ │ ├─ BGE-Reranker重排序 │ │ └─ LLM基于上下文生成最终答案 │ └─────────────────────────────────────────────┘2.2 技术栈全景图层次技术选型作用LLMQwen-Plus (DashScope API)答案生成、策略选择向量数据库Milvus 2.5存储文档向量混合检索关系数据库MySQL存储FAQ问答对、对话历史缓存Redis预分词缓存、查询结果缓存嵌入模型BGE-M3生成DenseSparse双路向量重排序BGE-Reranker-LargeCross-Encoder精排查询分类BERT (bert-base-chinese)二分类通用知识/专业咨询关键词检索BM25 (rank-bm25)FAQ快速匹配分词jieba中文分词框架LangChain文档加载、Prompt管理2.3 项目目录结构integrated_qa_system/ ├── config.ini # 全局配置数据库/LLM/检索参数 ├── main.py # 集成系统主入口 ├── base/ │ ├── config.py # 配置管理类 │ └── logger.py # 日志系统 ├── mysql_qa/ # MySQL FAQ 问答子系统 │ ├── db/mysql_client.py # MySQL客户端 │ ├── cache/redis_client.py # Redis缓存客户端 │ ├── retrieval/bm25_search.py # BM25检索引擎 │ ├── utils/preprocess.py # 中文预处理(分词) │ └── mysql_main.py # 独立运行入口 ├── rag_qa/ # RAG 语义问答子系统 │ ├── core/ │ │ ├── document_processor.py # 文档加载与父子块切分 │ │ ├── vector_store.py # Milvus向量存储与混合检索 │ │ ├── prompts.py # Prompt模板管理 │ │ ├── query_classifier.py # BERT查询分类器 │ │ ├── strategy_selector.py # LLM检索策略选择器 │ │ └── rag_system.py # RAG系统核心逻辑 │ ├── edu_document_loaders/ # 自定义文档加载器(OCR) │ ├── edu_text_spliter/ # 中文递归文本分割器 │ └── rag_main.py # 独立运行入口 └── requirements.txt三、第1级检索基于MySQL的FAQ关键词匹配3.1 设计思路对于高频、明确的知识点问答如AI学科学费是多少直接通过关键词匹配返回数据库中预存的答案速度极快毫秒级无需消耗LLM Token。3.2 BM25算法比TF-IDF更智能的关键词匹配BM25是TF-IDF的改进版核心优化在于词频饱和处理词频达到一定程度后不再线性增长避免长文档的偏向文档长度归一化防止长文档因词多而获得不合理的优势可调参数k1和b分别控制词频饱和度和长度归一化程度# BM25检索的核心代码结构classBM25Search:def__init__(self,redis_client,mysql_client):self.redis_clientredis_client self.mysql_clientmysql_client self.bm25Noneself._load_data()# 加载数据 → 分词 → 构建BM25索引defsearch(self,query,threshold0.85):# 1. 检查Redis查询缓存cachedself.redis_client.get_answer(query)ifcached:returncached,False# 2. jieba分词query_tokenspreprocess_text(query)# 3. BM25计算分数scoresself.bm25.get_scores(query_tokens)# 4. Softmax归一化 → 阈值判断softmax_scoresself._softmax(scores)best_idxsoftmax_scores.argmax()ifsoftmax_scores[best_idx]threshold:answerself.mysql_client.fetch_answer(self.original_questions[best_idx])returnanswer,False# 命中不需要RAGreturnNone,True# 未命中进入RAG3.3 Redis缓存加速重复查询系统使用Redis实现了两层缓存预分词缓存qa_tokenized_questions首次启动后将MySQL中所有问题的分词结果写入Redis后续启动直接读取避免重复分词查询结果缓存answer:{query}对命中阈值的高频查询缓存答案相同查询秒级返回3.4 Softmax阈值设计直接使用BM25的原始分数范围不确定不同查询之间难以比较。系统使用Softmax将分数归一化到[0,1]区间使得0.85的阈值具有跨查询的一致性解释。四、第2级检索基于Milvus的RAG语义检索当BM25关键词匹配失败时用户问题措辞与FAQ差异较大或涉及知识库文档中的深层内容系统进入RAG管线。4.1 文档处理管线多格式加载 父子块切分这是RAG系统的基础——如何将非结构化的文档转化为可检索的知识单元。多格式文档加载系统支持6种文件格式的自动加载每种都有对应的自定义加载器格式加载器特点.txtTextLoaderUTF-8编码.pdfOCRPDFLoader含图片OCR识别.docxOCRDOCLoader含图片OCR识别.ppt/.pptxOCRPPTLoader幻灯片含图片OCR.jpg/.pngOCRIMGLoader纯图片OCR.mdUnstructuredMarkdownLoader保留标题层级# 文件类型 → 加载器映射document_loaders{.txt:TextLoader,.pdf:OCRPDFLoader,.docx:OCRDOCLoader,.ppt:OCRPPTLoader,.pptx:OCRPPTLoader,.jpg:OCRIMGLoader,.png:OCRIMGLoader,.md:UnstructuredMarkdownLoader}父子块Parent-Child Chunk策略这是系统的关键设计之一。直接在文档切分时面临一个两难小块如200字符检索精度高但上下文不足LLM无法给出完整答案大块如1500字符上下文充足但检索时噪音大精度降低父子块策略优雅地解决了这个矛盾┌──────────────────────────────────────────────┐ │ 父块 (1200字符) ← 返回给LLM作为完整上下文 │ │ ┌──────────┬──────────┬──────────┬──────────┐ │ │ │ 子块1 │ 子块2 │ 子块3 │ 子块4 │ │ │ │ (300字符) │ (300字符) │ (300字符) │ (300字符) │ │ │ │ 检索用 │ 检索用 │ 检索用 │ 检索用 │ │ │ └──────────┴──────────┴──────────┴──────────┘ │ └──────────────────────────────────────────────┘子块300字符向量化后用于精确检索父块1200字符检索命中子块后返回其所属的完整父块作为LLM的上下文实现中Markdown文件使用MarkdownTextSplitter保留标题层级其他文件使用自定义的ChineseRecursiveTextSplitter按中文标点智能切分。4.2 向量存储BGE-M3双路嵌入 混合检索为什么选择BGE-M3BGE-M3BAAI/bge-m3是目前业界领先的多语言嵌入模型其独特之处在于同时输出两种向量Dense Vector稠密向量1024维捕获深层语义擅长理解同义改写Sparse Vector稀疏向量词汇级保留关键词信息擅长精确匹配Milvus集合Schema设计schema.add_field(id,DataType.VARCHAR,is_primaryTrue)# MD5主键schema.add_field(text,DataType.VARCHAR,max_length65535)# 子块文本schema.add_field(dense_vector,DataType.FLOAT_VECTOR,dim1024)# 稠密向量schema.add_field(sparse_vector,DataType.SPARSE_FLOAT_VECTOR)# 稀疏向量schema.add_field(parent_id,DataType.VARCHAR)# 父块IDschema.add_field(parent_content,DataType.VARCHAR,max_length65535)# 父块完整内容schema.add_field(source,DataType.VARCHAR)# 学科类别索引设计稠密向量IVF_FLAT内积度量nlist128稀疏向量SPARSE_INVERTED_INDEX倒排索引drop_ratio0.2混合检索 重排序流程这是系统的核心检索管线共5个步骤defhybrid_search_with_rerank(self,query,k5,source_filterNone):# Step 1: BGE-M3 生成查询的 Dense Sparse 向量query_embeddingsself.embedding_function([query])# Step 2: 构造稠密向量搜索请求 (内积度量, Top-K)dense_requestAnnSearchRequest(data[query_embeddings[dense][0]],anns_fielddense_vector,param{metric_type:IP},limitk,)# Step 3: 构造稀疏向量搜索请求 (内积度量, Top-K)sparse_requestAnnSearchRequest(data[sparse_query_vector],anns_fieldsparse_vector,param{metric_type:IP},limitk,)# Step 4: 混合检索 — 加权融合两路结果# 权重: 稀疏0.7, 稠密1.0 (侧重关键词匹配适合专业知识检索)rankerWeightedRanker(0.7,1.0)resultsself.client.hybrid_search(collection_nameself.collection_name,reqs[sparse_request,dense_request],rankerranker,limitk,)[0]# Step 5: 父文档去重 → BGE-Reranker精排 → Top-M 输出parent_docsself._get_unique_parent_docs(sub_chunks)iflen(parent_docs)2:pairs[[query,doc.page_content]fordocinparent_docs]scoresself.reranker.predict(pairs)# Cross-Encoder打分rankedsorted(zip(scores,parent_docs),reverseTrue)return[docfor_,docinranked[:CANDIDATE_M]]returnparent_docs[:CANDIDATE_M]关键设计决策稀疏向量权重0.7高于稠密向量1.0这是因为专业知识检索更依赖关键词精确匹配稀疏向量在这方面表现更优稠密向量贡献语义泛化能力避免因措辞不同而漏召回五、RAG核心管线查询分类 → 策略选择 → 检索 → 生成5.1 BERT查询意图分类通用知识 vs 专业咨询在进入昂贵的检索流程之前系统先用一个轻量级BERT分类器判断查询意图通用知识如5×9等于多少、“今天天气怎么样”直接用LLM自身知识回答跳过检索专业咨询如AI学科课程大纲是什么触发完整RAG流程classQueryClassifier:defpredict_category(self,query):self.model.eval()encodingself.tokenizer(query,truncationTrue,paddingTrue,max_length128)withtorch.no_grad():outputsself.model(**encoding)predictiontorch.argmax(outputs.logits,dim1).item()return专业咨询ifprediction1else通用知识模型使用bert-base-chinese基座在5000条人工标注数据上微调80/20训练验证划分训练3个epoch。设计收益简单问题秒回无需检索复杂问题精准检索用户体验和成本兼得。5.2 LLM策略选择四种检索策略智能切换这是系统最具创新性的设计之一——不是所有查询都用同样的检索方式而是让LLM根据查询特征动态选择最优策略策略原理适用场景示例直接检索原始查询直接检索查询意图明确“AI学科学费多少”HyDELLM生成假设答案 → 用答案检索查询较抽象“人工智能在教育领域有哪些应用”子查询检索LLM拆分复杂查询 → 分别检索 → 合并去重查询涉及多方面比较“比较Milvus和Zilliz Cloud的优缺点”回溯检索LLM简化为基础问题 → 用简化问题检索查询过于具体“我有100亿条数据想存到Milvus可以吗”策略选择器使用Few-Shot Prompt引导LLM做出判断设置temperature0.1确保输出稳定classStrategySelector:defselect_strategy(self,query):promptself.strategy_prompt_template.format(queryquery)resultself.call_dashscope(prompt)returnresult.strip()ifresultelse直接检索HyDE策略的实现原理HyDEHypothetical Document Embeddings解决了一个核心问题短查询与长文档之间的语义鸿沟。用户查询AI的应用只有几个字而知识库文档可能有几千字二者的嵌入向量在空间中可能相距甚远。解决方式让LLM先脑补一段假设答案再用这个详细文本去检索def_retrieve_with_hyde(self,query):# 1. LLM生成假设答案hypo_answerself.llm(hyde_prompt_template.format(queryquery))# 2. 用假设答案而非原始查询进行检索returnself.vector_store.hybrid_search_with_rerank(hypo_answer,kRETRIEVAL_K)5.3 RAG答案生成最终阶段系统将检索到的文档片段拼接到Prompt中让LLM基于上下文生成答案defgenerate_answer(self,query,source_filterNone):# Step 1: BERT分类categoryself.query_classifier.predict_category(query)# Step 2a: 通用知识 → LLM直接回答ifcategory通用知识:returnself.llm(rag_prompt.format(context,questionquery))# Step 2b: 专业咨询 → 完整RAG流程strategyself.strategy_selector.select_strategy(query)context_docsself.retrieve_and_merge(query,strategystrategy)context\n\n.join([doc.page_contentfordocincontext_docs])returnself.llm(rag_prompt.format(contextcontext,questionquery,phoneCUSTOMER_SERVICE_PHONE))Prompt模板设计遵循上下文优先原则你是一个智能助手帮助用户回答问题。 如果提供了上下文请基于上下文回答如果没有上下文请直接根据你的知识回答。 如果答案来源于检索到的文档请在回答中说明。 上下文: {context} 问题: {question} 如果无法回答请回复信息不足无法回答请联系人工客服电话{phone}。六、系统集成融合FAQ与RAG的统一入口最终main.py即IntegratedQASystem类将两大子系统整合为统一的服务classIntegratedQASystem:def__init__(self):# 初始化所有子系统self.mysql_clientMySQLClient()self.redis_clientRedisClient()self.bm25_searchBM25Search(redis_client,mysql_client)self.clientOpenAI(api_key...,base_url...)self.vector_storeVectorStore()self.rag_systemRAGSystem(vector_store,self.call_dashscope)defquery(self,query,source_filterNone,session_idNone):# 第1级: BM25关键词匹配answer,need_ragself.bm25_search.search(query,threshold0.85)ifanswer:yieldanswer,True# 命中直接返回# 第2级: RAG语义检索elifneed_rag:answerself.rag_system.generate_answer(query,source_filter)yieldanswer,Trueelse:yield未找到答案,True对话历史管理系统使用MySQL的conversations表持久化存储对话历史支持多轮对话CREATETABLEconversations(idINTAUTO_INCREMENTPRIMARYKEY,session_idVARCHAR(36)NOTNULL,-- UUID会话标识questionTEXTNOTNULL,answerTEXTNOTNULL,timestampDATETIMENOTNULL,INDEXidx_session_id(session_id));每次对话后自动记录每次保留最近5轮历史超出部分自动清理。每个会话通过UUID4唯一标识不同会话互不干扰。七、工程化设计亮点7.1 配置中心化所有配置数据库、LLM API、检索参数集中在config.ini中管理[mysql] host localhost user root password 123456789 database subject_kg [llm] model_name qwen-plus dashscope_api_key sk-xxx dashscope_base_url https://dashscope.aliyuncs.com/compatible-mode/v1 [retrieval] parent_chunk_size 1200 child_chunk_size 300 chunk_overlap 50 retrieval_k 5 candidate_m 2Config类使用configparser读取所有参数都有fallback默认值配置文件缺失时系统仍可运行。7.2 日志系统统一的日志系统同时输出到控制台和文件支持按时间回溯排查问题loggersetup_logging()# 格式: 2024-01-15 10:30:45,123 - EduRAG - INFO - 处理查询: AI学科学费7.3 异常降级策略整个系统设计遵循部分失败不影响整体的原则BM25索引为空 → 直接降级到RAGLLM API调用失败 → 返回带客服电话的兜底回复Redis连接失败 → 回退到MySQL直接查询策略选择失败 → 默认使用直接检索7.4 可独立运行与组合使用每个子系统都可以独立运行# 仅使用MySQL FAQ检索python mysql_qa/mysql_main.py# 仅使用RAG语义检索python rag_qa/rag_main.py# 数据处理模式导入文档到Milvuspython rag_qa/rag_main.py--data_processing--data_dir./data# 完整集成系统python main.py八、总结与展望核心收获本文详细剖析了一个生产级的RAG问答系统核心要点包括两级检索架构BM25关键词匹配快 RAG语义检索准兼顾速度和精度父子块策略小块检索精度 大块返回上下文解决检索精度与上下文的矛盾混合检索BGE-M3 Dense语义 Sparse关键词双路检索取长补短智能策略选择4种检索策略 LLM动态选择不同查询不同处理查询分类前置BERT二分类简单问题不走RAG节省成本多层缓存Redis缓存分词结果和查询答案大幅提速工程化设计配置中心化、日志统一、异常降级、模块解耦技术栈速查组件技术大模型Qwen-Plus (DashScope)向量数据库Milvus嵌入模型BGE-M3重排序BGE-Reranker-Large查询分类BERT-Chinese关键词检索BM25 jieba关系数据库MySQL缓存Redis框架LangChain PyTorch Transformers这套架构不仅适用于教育领域稍加改造即可应用于客服系统、知识管理、技术文档问答等任何需要基于私有知识回答问题的场景。希望本文能为正在探索RAG落地的你提供一些实用的参考。参考项目传智教育 EduRAG 智慧问答项目 V1.0关键技术LangChain · Milvus · BGE-M3 · BM25 · BERT · Qwen · Redis · MySQL本文为原创内容欢迎在评论区交流讨论。如果觉得有帮助请点赞收藏支持~