简介：这是面向人工智能、物联网、自动化、电子信息等专业学生和研发人员的RAG本地知识库与LLM微调智能问答系统完整项目包，覆盖比赛提交、课程作业、毕业设计及企业原型演示等多种应用场景，涉及本地知识库构建、检索增强生成、大模型微调及问答交互等关键环节。资源共190个文件，约2.58MB，目录结构清晰：既有Python后端、前端JS/CSS、JSON配置等Web系统核心代码，也包含C语言基础示例、图片素材、说明文档与设计报告，便于按模块对照学习和二次开发。已有87人学习/下载。项目源码经过严格测试，运行稳定、易部署；配套实战教程覆盖从环境配置、数据处理、模型微调到界面部署的完整链路，帮助读者系统理解系统搭建流程；设计文档和研究报告则能为课程论文或毕业答辩提供参考。对于有基础的开发者，可直接扩展功能模块并应用到学术研究或实际业务中，部署期遇到问题也可与作者私信交流获得支持。
1. 为什么要把RAG和微调拼在一起：这套系统的出发点
先说一个场景。我手头有几百份技术文档、产品手册和内部纪要，散落在各个目录里。每次想查一个具体问题，要么翻半天文件夹，要么搜索出一堆无关结果。更烦的是，把这些文档丢给通用大模型，它压根不看你的资料，张口就按自己的理解编，回答得还挺自信。这种“一本正经胡说八道”放在内部知识问答场景里，基本就是事故现场。
后来我搭了这套RAG本地知识库+LLM微调智能问答系统，才算把这个问题治住。RAG负责让模型“查得到”私有文档里的真实信息，微调负责让模型“说人话、按规矩说话”——一个是外挂知识，一个是改造能力，两者合在一起，才是一套能落地到具体业务的智能问答系统，而不是一个聊天的demo。
这套系统的结构其实不复杂，核心就四块：知识库处理与向量化、检索模块、大模型底座、问答服务。选型上我最终定了：BGE系列的Embedding模型做向量化、FAISS做向量检索、Qwen系列开源模型做底座、LoRA微调方案调整生成风格和领域能力、FastAPI封装服务。整套下来，普通单卡的服务器就能跑，不需要动辄几十万的训练集群。这也是我坚持选择开源可私有化方案的原因——知识库里的东西都是业务资产，不能送出去二次加工。
项目附带源码和一个完整的实战教程，从文档清洗到训练数据构造再到接口部署都覆盖了。这篇文我就按自己搭系统的思路，把关键链路、参数选择、踩过的坑一次讲清楚。适合两类人看：一类是想给团队做内部知识库问答的工程师，另一类是把RAG和微调结合在一起研究的学习者。
2. 检索链路：从文档切分到混合召回，这一步决定系统上限
很多人都以为RAG系统的效果取决于大模型选得好不好，其实大模型只是生成端，真正决定回答质量上限的是检索端——文档没检索对，后面再怎么调prompt都白搭。所以我先把检索链路单独拉出来讲。
2.1 文档加载与切分策略：别小看这个预处理环节
知识库里通常什么格式都有：PDF、Word、Markdown、TXT，甚至还有扫描件。PDF处理是第一个坑，直接用pdfplumber或者PyMuPDF提取文本，遇到表格和双栏排版经常乱序。我的经验是：能转Markdown的先转Markdown，结构化程度高，后续切分也干净；确实只有PDF的，用PyMuPDF按块提取，再做一次文本清洗，把多余换行、页眉页脚、乱码字符滤掉。
切分这一步最容易被低估。切得太碎，检索到的片段缺乏上下文，模型看不懂；切得太长，向量检索精度下降，还容易混入无关信息。我实测下来，按固定窗口切分，chunk_size设500到800个字符、overlap设50到100，是一个对大部分中文技术文档都稳的起点。要注意overlap不能省，它能保证句子和段落之间的语义连续性，否则一个完整的技术方案很可能被腰斩成两段，检索时只召回半截，答出来的内容自然残缺。
更讲究一点的做法是语义切分，按Markdown标题、段落、列表层级来做结构化切块。我在源码里实现了一个简单的递归切分器：先按一级标题切，再按二级标题切，最后对仍然超长的块做固定窗口兜底。效果比纯固定窗口好不少，缺点是实现稍麻烦。我建议你先跑通固定窗口，再逐步升级。
2.2 Embedding选型与向量化
向量化的作用是把文本变成计算机能算相似度的数字序列。Embedding模型选不好，后面所有环节都跟着遭殃。中文场景下，我推荐BGE系列（比如bge-large-zh-v1.5）或者M3E系列，它们在中文语义匹配上的表现比很多通用模型稳定得多，而且都支持开源商用。
向量化之后就是存向量。我在这个项目里用了FAISS，原因很简单：本地知识库的规模通常在几万到几十万条向量之间，FAISS完全够用，索引快、内存占用可控，而且不需要单独部署一个服务。如果你的文档量级到了百万级以上，或者需要复杂的元数据过滤，再考虑Milvus或Qdrant不迟，没必要一开始就上重型武器。
这里有一个细节值得注意：向量化之后一定要记得保存“文档ID到向量ID”的映射关系。否则你检索到了向量，却不知道它对应哪一段原始文本，答引用来源的时候只能抓瞎。我最初写第一版的时候就把这个映射漏了，结果每次检索回来都要全量遍历一遍文档列表去反查内容，慢得离谱，后来做了一次大重构才修好。
2.3 混合检索与重排：单靠向量检索不够
纯向量检索有一个很典型的毛病：对专业缩写、编号、型号、人名这类精确匹配场景非常不友好。比如用户搜“GPU驱动安装报错1003”，语义相近但字面差异大，向量检索可能召回一些“安装显卡驱动”“系统报错排查”之类的泛泛内容，唯独把真正的报错文档丢在后面。这是因为Embedding模型擅长理解语义，不擅长精确匹配字符。
解决思路是加一路BM25关键词检索，形成多路召回。BM25是经典的词频统计检索算法，对精确词匹配非常有效。具体做法是：同一段文档分别建向量索引和BM25索引，查询时两路同时跑，各自返回Top N结果，然后做分数融合。融合我推荐用Reciprocal Rank Fusion（RRF），它的思路是对两路结果的排名做倒数加权，不需要费心归一化不同量纲的分数，简单好用。我用的公式是：score = sum(1 / (k + rank))，k一般取60，实测效果很稳。
融合之后通常还需要一步重排（rerank），用更强的模型对候选片段做精细打分。我选的是BGE系列的reranker，它能把“相关但不够准确”的片段进一步过滤掉。不夸张地说，加了这个环节之后，检索命中率提升了十个百分点以上。代价是多花一点推理时间，但在知识库场景下完全值得。
3. 生成端：LoRA微调的选型理由与训练细节
3.1 微调到底解决了什么问题
很多人一开始会把微调和RAG搞混，以为它们解决的是同一件事。其实它们的优势完全不同。RAG解决的是“信息时效性和私有性”问题——文档可以随时更新，模型不用重训；微调解决的是“生成规则与风格”问题——让模型在回答时遵循固定的格式、语气和领域表达习惯。
举个例子：纯RAG系统虽然检索到了正确的政策条款，但回答时可能啰嗦、不分点、不给出处，或者夹带无关的客套话。而经过微调之后，模型会稳定地输出“先给结论，再分点说明，最后附引用来源”的结构化回答，这在业务场景里非常关键。所以我做这个项目时定下的原则是：知识靠RAG，规矩靠微调，两者互不替代。
3.2 为什么选LoRA而不是全量微调
当前主流的微调方式有三种：全量微调、Freeze微调、LoRA微调。它们的差别在于“改多少参数”。
| 方式 | 参数量 | 显存需求 | 训练速度 | 风险 |
|---|---|---|---|---|
| 全量微调 | 全部参数 | 极高，7B模型也要多卡 | 慢 | 容易灾难性遗忘 |
| Freeze微调 | 仅分类头/部分层 | 中等 | 中等 | 能力提升有限 |
| LoRA微调 | 少量旁路参数 | 低，单卡可跑 | 快 | 调参不当会欠拟合 |
我最终选了LoRA。原因很直接：第一，本地训练环境通常只有一张消费级显卡，全量微调跑不起来；第二，LoRA只训练注入的低秩矩阵，显存压力小，7B模型用QLoRA甚至能在24GB显存上跑起来；第三，LoRA训练完之后可以单独导出adapter权重，想回退到原始模型只需不加载adapter即可，试错成本极低。
3.3 训练数据构造与参数配置
微调效果好坏，训练数据质量占八成。我从知识库里提取QA对的方法有两种：一是人工整理高频问题，结合文档内容写标准答案；二是用大模型辅助生成，把文档片段丢给一个更强的模型，让它基于片段生成问题和答案，然后人工抽检清洗。
数据格式我用的是对话式模板，每条包含instruction和output两个字段。这一点很重要，训练时如果格式跟推理时不一致，效果会大打折扣。我的训练数据样例大致长这样：
{ "instruction": "请根据以下资料回答：如何解决GPU驱动安装报错？", "output": "遇到GPU驱动安装报错时，先检查驱动版本与系统内核的兼容性，再按以下步骤排查：..." }训练参数方面，我跑过一组比较稳的LoRA配置：rank设16，alpha设32，学习率2e-4，epoch数控制在2到3个，warmup设0.1。rank不是越大越好，太大训练变慢而且容易过拟合；太小则表达能力不足。另外建议用float16混合精度训练，速度和显存都有明显改善。
一个常见坑是灾难性遗忘——模型学完领域数据后，把原来的通用能力忘了。我的对策是训练数据里掺入20%到30%的通用对话数据，相当于给模型“留点底子”。这个方法听上去简单，实际效果比什么正则化技巧都管用。
4. 源码链路拆解：一个问答请求的完整旅程
4.1 模块划分与工程结构
源码工程我按职责分成五个目录：data_loader负责文档加载和清洗，chunker负责文本切分，embedder负责向量化，retriever负责混合检索和重排，llm_service负责模型加载、微调适配和推理。最后用FastAPI把它们串成一个Web服务。
核心的问答接口逻辑大致如下：
@app.post("/chat") async def chat(request: ChatRequest): # 1. 对用户query向量化 query_vector = embedder.embed(request.query) # 2. 混合检索：向量召回 + BM25召回 vector_hits = retriever.vector_search(query_vector, top_k=10) bm25_hits = retriever.bm25_search(request.query, top_k=10) # 3. RRF融合 + rerank重排 fused = rrf_fusion(vector_hits, bm25_hits, k=60) candidates = retriever.rerank(request.query, fused, top_k=4) # 4. 拼装prompt context = build_context(candidates) prompt = build_prompt(request.query, context) # 5. 调用微调后的LLM生成答案 answer = llm_service.generate(prompt) return {"answer": answer, "sources": candidates}4.2 Prompt拼装：被低估的关键一环
代码里最不起眼但最影响体验的，是build_prompt这个函数。我给模型设计的提示词包含四个部分：角色设定、任务要求、参考资料、输出格式约束。特别是输出格式这一条，会明确要求“如果参考资料没有相关内容，请直接说明无法回答”，从源头抑制模型胡编乱造。
一个实用技巧是：把检索到的文档片段按段落标号嵌入Prompt，同时要求模型在回答中引用编号。比如“根据[1][3]两处资料，结论是……”。这样效果立竿见影——回答有据可循，用户也能自己回到原文核对。这个设计被很多商用问答系统采用，强烈建议你照抄。
4.3 服务化与并发处理
FastAPI跑起来很容易，但推理这块需要注意并发限制。大模型推理是显存密集型操作，如果同时进来多个请求，很容易导致显存溢出。我的方案是给推理接口加一个信号量限制并发数为1，其余请求排队等待；同时在生成参数里开启流式输出，让用户看到逐字输出，体验上比干等转圈好很多。
还有一个容易被忽略的点：加载Embedding模型和LLM不要放在同一个GPU上抢显存。我的做法是Embedding模型用CPU推理，只把LLM放到GPU，速度不但没慢多少，反而让GPU专注做一件事，整体吞吐更稳定。
5. 实测效果与高频坑位：哪些改动真正让系统变好用
5.1 与纯RAG、纯微调的对比结论
我分别跑过纯RAG、纯微调、RAG+微调三组实验，用同一批测试问题做评估。纯RAG的问题是回答风格不一致，同一个问题换个问法，输出结构就变了；纯微调的问题是遇到知识库新增内容完全无力，模型只能凭训练时的记忆作答，一旦知识过期就露馅。两者结合之后的系统，回答准确率提升明显，而且输出结构稳定，基本达到了我想要的业务可用水平。
尤其要提的是引用正确率。加装了重排和引用编号之后，引用来源的错误率大幅下降，用户点开引用能真的找到对应段落，这个体验对内部知识库工具来说至关重要。
5.2 高频问题与避坑经验
坑位一：向量索引重新构建时映射错乱。这个问题我吃过一次大亏。知识库更新后，我重新跑了一遍向量化，但旧索引文件没有清理，新旧数据混在一起，导致检索结果张冠李戴。后来我约定每次重建都写一个新的索引目录，并在文件名中带上版本号，从机制上杜绝覆盖混乱。
坑位二：LoRA微调后模型输出的格式偏了。有一次我为了提高领域术语准确率，把epoch从3加到8，结果模型输出开始出现重复、乱序的症状。这就是典型的过拟合。回退到3个epoch并把学习率降到1e-4之后恢复正常。微调不是训练轮数越多越好，一定要留着验证集看效果，跑完一个epoch就测一次生成质量，而不是等到最后才看。
坑位三：中文Embedding对口语化问题不友好。用户提问常常带口语、错字、简写，比如“那个显卡老报错咋整”。直接用原始文本检索效果很差。我的解法是加一个查询改写环节：先用一个轻量模型把口语化问题改写成书面化的关键词组合，再拿去检索。这一招让回答满意度提升了不少。相关代码在源码里有现成实现，可以直接参考。
坑位四：知识库切片后丢失表格信息。纯文本提取对表格支持不好，切片时表格内容经常被拆得面目全非。目前比较务实的做法是对表格单独处理：检测到表格结构时，把它整体作为一个chunk存储，并在文本化时保留表头和行列关系。虽然不如专业版式解析那么完美，但已经能满足大部分查询需求。
6. 最后再分享两个我自己用的实用思路
第一个是关于评估。RAG系统没有一套“跑完就安心”的评估办法，我养成的习惯是维护一份固定的测试问题集，每次改完检索参数或者微调参数，都拿同一份问题集跑一遍，用回答质量和检索命中率两个指标对比。没有这份基线，你根本不知道改动的效果是变好了还是变坏了。
第二个是迭代顺序。如果你刚开始搞这套系统，我建议先把RAG链路做扎实，暂时不碰微调，跑通之后再逐步加微调、调参数。不要一上来就想着微调模型，否则出问题时根本定位不了是检索的问题还是生成的问题，排查成本会高到让你怀疑人生。
这套系统目前在我们内部已经稳定跑了大半年，知识库文档从最初的几百份涨到几千份，检索速度和回答质量都没掉链子。我自己的感受是，RAG和微调结合这件事，难度不在某个单独技术点，而在于把整条链路加工得让模型用得舒服——文档切得合适、检索召回得准、提示词约束得住、微调风格调得对。把这四点做到位，一套本地化的智能问答系统其实没有想象中那么遥不可及。
本文还有配套的精品资源，点击获取
