1. 为什么我建议毕设选RAG方向技术逻辑与论文包装思路每年毕业设计的选题阶段总有不少同学在深度学习图像分类推荐系统这些经典方向里打转。但如果你稍微关注近两年的技术趋势会发现基于RAGRetrieval-Augmented Generation检索增强生成的智能知识库问答系统已经成了企业级落地最密集的方向之一。我去年带过几个毕业生做这个方向有做校园问答的有做企业文档检索的还有做医疗科普问答的全部顺利通过答辩而且被问创新点在哪里时都能答得很有底气——因为RAG本身就是一个既要懂大模型、又要懂检索、还要懂工程落地的综合型选题。先说清楚RAG到底解决什么问题。大模型虽然知识面广但有两个硬伤一是训练数据有截止时间最新的内部资料、政策文件它根本不知道二是面对企业内部文档、专业书籍这种私有知识它只能编不能查。RAG的思路很直接——不修改大模型本身而是在回答前先从知识库里检索出相关片段把片段塞进提示词里让模型基于这些片段作答。这样做的好处是知识可以随时更新替换知识库就行回答可以追根溯源标注来源文档幻觉率大幅下降模型被限制在给定上下文内。相比微调Fine-tuning动辄要准备几千条标注数据、训练一张卡要跑几十个小时RAG几乎可以用零训练成本解决垂直领域问答问题这本身就是毕业设计最理想的低成本高展示度组合。从论文包装的角度看RAG方向的题目也特别舒服。它天然有完整的问题—方法—实验闭环问题就是大模型在私有知识问答中的局限性方法就是离线知识库构建在线检索生成的双阶段架构实验可以是检索命中率、答案准确性、幻觉率的前后对比。更关键的是这个方向有清晰的改进空间——你可以用不同的切块策略、不同的Embedding模型、不同的重排算法做对照实验创新点非常好产出。相比之下很多人选基于SSM的学生管理系统这类题目开题报告都写得干巴巴的。同样的精力投入RAG方向做出来的系统演示效果要震撼得多答辩时现场让评委提问系统能当场从知识库找到答案并给出依据这种演示冲击力是传统CRUD项目完全比不上的。当然RAG的入门门槛也比传统Web开发高一些需要你同时接触大模型API、向量数据库、文本处理流水线。但正因为有门槛才值得写在简历上。这篇博文我按照实际做项目的顺序把完整链路拆开讲清楚从需求分析、架构设计到离线知识库怎么建、在线问答怎么调再到实验评估和答辩准备。你可以把它当成一份可直接复现的行动手册也可以当作开题报告和论文正文的素材库。下面我们一步步来。2. 系统架构从文档上传到答案生成的完整链路设计做任何系统之前第一件事不是写代码而是画清楚架构图当然博文里用文字描述你论文里可以画正式框图。RAG问答系统从功能上分其实就三条流水线离线知识库构建管线、在线问答管线、前端交互与API层。我强烈建议毕业设计把这三条线在文档里分别描述答辩时也按这三条线讲逻辑会特别清晰。2.1 离线知识库构建管线让文档变成模型能读懂的形态这条管线的输入是原始文档PDF、Word、Markdown、TXT等输出是向量数据库里的一条条索引记录。整体步骤是文档解析把PDF、Word等格式转换成纯文本。这里有个容易被忽视的细节——PDF要区分文本型PDF和扫描件PDF前者直接用解析库就能提取文字后者必须走OCR光学字符识别否则出来的是一堆乱码或空文本。中文扫描件建议用PaddleOCR识别效果在开源方案里属于第一梯队。清洗与预处理去掉页眉页脚、多余换行、特殊符号把全角标点转半角中文场景下保留全角更合适主要看你的解析结果。这一步决定了后续切块质量但很多新手会跳过最后检索出来的片段里全是第3页共20页这类噪声。语义切块Chunking把长文档切成固定大小的文本块。这一步是RAG效果的胜负手后面专门开一章细讲。向量化Embedding用Embedding模型把每个文本块转成高维向量。比如使用text2vec-large-chinese或BAAI/bge-large-zh-v1.5输出维度通常是1024或768。向量化的核心目的是把语义相似度变成向量距离这样检索时才能用数学计算找到最相关的片段。入库把向量和原始文本一起写入向量数据库。向量数据库选型很关键毕设场景我推荐Milvus Lite或Chroma前者适合数据量上万条的严肃项目后者轻量到跑在内存里就能演示安装也快。如果要写进论文建议提一嘴为什么选向量数据库而不直接暴力遍历——因为KMeans、HNSW这些索引结构能把千万级向量的检索延迟控制在百毫秒内这是传统数据库不具备的能力。2.2 在线问答管线检索、增强、生成三步走在线问答管线是用户能感知的部分流程如下问题向量化用户输入问题后用和离线阶段相同的Embedding模型把问题转成向量。这里特别强调相同模型如果离线用bge-large在线换成了text2vec检索效果会立刻崩掉——因为两个模型的向量空间不兼容。向量检索在向量库里用余弦相似度或内积距离检索TopK个最相似的文本块。K的取值我建议默认5具体调优思路后面讲。重排序Rerank粗召回的结果可能有不相关片段混进来用一个更精细的Cross-Encoder模型如bge-reranker-base对TopK结果重新打分排序保留TopN通常N3。这一步不是必选项但加了之后答案质量提升非常明显也是论文里很好的对比实验素材。Prompt组装把用户问题、检索到的片段、对话历史按模板拼成提示词。Prompt模板的设计直接影响回答质量我实际用的模板会在第4章完整给出。LLM生成把Prompt发给大模型API或本地部署流式返回答案。2.3 交互层与API设计毕设演示效果的关键前端不需要复杂一个简洁的聊天界面即可。但有几个点能显著提升演示效果流式输出用服务器发送事件SSE实现打字机效果用户观感上会觉得系统很智能。来源标注每条回答下方列出引用的文档和原文片段。这不仅是RAG的核心卖点也是答辩时应对你的答案是不是模型瞎编的这类质疑的最好证据。知识库管理界面支持上传文档、查看已入库的文档列表、删除文档。这部分虽然简单但能证明你的系统是完整的工程闭环而不是只跑通了一个Demo。API层我用的方案是FastAPI接口设计如下# 简化版接口设计 POST /api/v1/knowledge_base/upload # 上传文档并触发入库流程 POST /api/v1/knowledge_base/delete # 删除文档 POST /api/v1/chat/completions # 问答接口SSE流式返回 GET /api/v1/documents/list # 已入库文档列表这种设计天然对应论文里的系统功能模块划分答辩画架构图时前端、API层、离线管线、在线管线、向量库、LLM各占一个模块层次感非常清楚。3. 离线知识库构建实操文档解析、语义切块与向量化入库这一章是系统能不能用的地基。我给多个毕设项目做过代码评审90%的RAG系统效果差问题都出在解析完就直接整篇塞进去或者切块参数拍脑袋。下面按实操顺序展开。3.1 文档解析不同格式的易错点与解决方案文件上传之后第一关就是解析。我常用的库和注意事项如下文件格式解析方案易错点PDF文本型PyMuPDFfitz注意处理多栏排版简单按行提取会打乱阅读顺序PDF扫描件PaddleOCR中文识别精度高但速度慢建议对长文档做并发处理Wordpython-docx注意提取表格内容表格里的信息常常被遗漏Markdown/TXT直接读取保留标题层级信息切块时能利用标题进行结构化切分这里分享一个容易被忽略的坑PDF解析出来经常带很多换行符。英文PDF句尾的换行还好处理中文扫描件OCR出来的文本经常把一句话拦腰截断如果不做换行合并处理切块时就会出现大量只有半句话的碎片块检索时根本匹配不上。我的处理方式是解析后先把所有单个换行符替换成空格再按句号、问号、感叹号切句。简化的代码逻辑如下import re def clean_text(raw_text: str) - str: # 合并断裂换行 text re.sub(r\n, \n, raw_text) # 把单换行替换为空格段落内换行合并 lines text.split(\n) merged [] for line in lines: if line.strip() : merged.append(\n) else: merged.append(line.strip()) cleaned .join(merged) # 保留段落之间的空行作为分隔 cleaned re.sub(r(\S)\n(\S), r\1 \2, cleaned) return cleaned3.2 语义切块chunk_size 与 overlap 的选择逻辑切块是整个RAG链路里最艺术的部分。块太大塞进Prompt后占用的token太多而且一块里揉了好几个主题检索出来的相关度会被稀释块太小语义不完整模型理解不了上下文。我实际测试下来中文场景比较稳的参数组合是块大小chunk_size300~500字重叠overlap50~100字。为什么要设置重叠因为一个完整知识点可能正好被切块边界从中间割开。比如一句该制度的适用范围不包括临时工被切成该制度的适用范围不包括和临时工两块无论检索到哪一块都是残缺信息。重叠区块能让边界附近的内容在两块中都出现避免这种拦腰截断。切块方式我推荐优先按段落或标题切分而不是纯按字符数硬切。如果文档结构良好有标题、有章节可以用LangChain的MarkdownHeaderTextSplitter或递归字符切分器from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size400, # 每个块的字符数 chunk_overlap80, # 块间重叠字符数 separators[\n\n, \n, 。, , , , , , ], length_functionlen, ) chunks splitter.split_text(cleaned_text)注意separators这个参数它决定了切分器优先按什么层级去断句。我给中文场景的顺序是先尽量按段落双换行再按单换行再按句号最后不得已才按逗号或空格切。层级越靠前切出来的块语义完整性越有保障。这也解释了为什么清洗换行那么重要——如果文本里全是零散换行切分器会把每一个换行都当成分隔符切出来的全是碎块。3.3 Embedding模型选型中文场景怎么选Embedding模型的选择直接决定检索命中率的上限。我做过一轮中文知识库的主流Embedding模型对比结果写进论文也算一个贡献点参考结论如下Embedding模型向量维度中文效果说明text2vec-large-chinese1024良好中文语义理解强但加载显存占用略高bge-large-zh-v1.51024优秀检索和聚类表现均衡官方支持中文检索指令m3e-base768良好轻量、加载快适合数据量不大的毕设演示OpenAItext-embedding-3-small1536优秀API调用无需本地显存但离线演示不便还花钱毕设现场答辩往往没有网或者网络不稳定所以我更推荐本地部署bge-large-zh-v1.5或m3e-base。加载模型的代码如下from sentence_transformers import SentenceTransformer model_name BAAI/bge-large-zh-v1.5 model SentenceTransformer(model_name, devicecpu) # 有GPU就换cuda embeddings model.encode([向量化前的文本片段], normalize_embeddingsTrue)这里有个参数容易被忽视normalize_embeddingsTrue。归一化之后余弦相似度等价于内积很多向量数据库可以直接用内积做检索性能更好、数值更稳定。论文里如果要装点门面可以写对Embedding向量进行L2归一化处理使余弦相似度与内积检索统一。3.4 向量数据库入库与索引构建向量数据库我用的是Milvus Litepymilvus内置支持本地跑一个文件就能用对毕设来说既展示了工业级工具的使用经验又不至于被Docker和分布式部署难住。入库的核心是定义Collection相当于关系数据库的表和字段我的设计如下from pymilvus import ( MilvusClient, DataType ) client MilvusClient(milvus_local.db) client.create_collection( collection_nameknowledge_base, dimension1024, primary_field_nameid, vector_field_nameembedding, metric_typeIP # 归一化后 IP 等价于余弦相似度 )除了向量字段我强烈建议给每条数据额外存几个MetaData字段content原文、source来自哪份文档、chunk_index第几个块、title文档标题。这些字段在后续检索时可以用来做元数据过滤比如只搜某一篇文档更重要的是在回答展示来源依据时必须用到。入库的伪代码def insert_chunks(chunks, source_file): data [] for idx, chunk in enumerate(chunks): vec model.encode([chunk], normalize_embeddingsTrue)[0] data.append({ id: generate_uuid(), embedding: vec.tolist(), content: chunk, source: source_file, chunk_index: idx, title: extract_title(source_file), }) client.insert(collection_nameknowledge_base, datadata)这块有一个性能优化细节如果你一次性上传了几十篇文档逐条插入会很慢。建议用client.insert批量提交每批256条左右入库吞吐能提升好几倍。4. 在线问答链路向量召回、重排与Prompt增强生成知识库建好了接下来要打通问答链路。这一步决定用户看到的答案靠不靠谱。我按照实际调用顺序走一遍每个环节给出关键代码和调参心得。4.1 向量召回TopK怎么定、混合检索要不要先说召回。用户输入问题后我做的第一件事是改写问题——尤其对长问题直接用原始问题向量化效果往往不理想。比如用户问2024年学校对于奖学金申请条件做了哪些调整原始问题太具体向量检索时容易被2024年调整这些词带偏。我的做法先用LLM把问题改写成适合检索的短查询Query Rewrite候选改写为奖学金申请条件 2024。这一步可以用API也可以在本地用一个小模型毕设直接用LLM API就行多一次调用效果提升明显。召回时TopK的选择逻辑K3答案最精准但可能漏掉相关信息适合问题简单、知识库已经切得比较碎的场景。K5默认值平衡了召回率和上下文噪声绝大多数场景用这个起步。K10适合复杂问题但塞进Prompt的内容会很多既增加token开销也可能让大模型看花了眼——相关性靠后的片段反而干扰判断。我的建议默认设5论文里再做一组K3/5/10对回答准确率的影响实验既有数据支撑又有说服力。还有一种提分技巧先做关键词检索BM25 向量检索的混合召回再用Rerank合并去重。BM25擅长精确匹配比如专业术语、编号、人名向量擅长语义匹配两者互补混合召回能明显提高召回率。用LangChain实现很简单from langchain.retrievers import BM25Retriever, EnsembleRetriever from langchain.retrievers import ContextualCompressionRetriever bm25_retriever BM25Retriever.from_documents(docs) bm25_retriever.k 5 vector_retriever milvus.as_retriever(search_kwargs{k: 5}) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.3, 0.7] # 关键词和向量的权重可按实际效果调整 )权重[0.3, 0.7]的意思是我认为语义匹配更重要关键词召回起辅助作用。如果你的知识库里专业术语非常多可以调到[0.5, 0.5]。4.2 重排序为什么召回靠向量、精排靠Rerank向量召回本质上是粗筛——它用向量距离快速捞回可能相关的TopK但排序质量一般。这就像你在大海里用渔网捞鱼捞上来一堆但哪些是最该上桌的鱼还需要人工再挑一遍。Rerank重排序做的就是这件细活。主流方案是Cross-Encoder模型比如bge-reranker-base。它会把问题和候选片段拼在一起输入模型直接输出一个相关度打分。和双塔结构的Embedding相比Cross-Encoder能更充分地建模问题和片段的交互关系但速度慢所以只对TopK结果做精排不做全库扫描。from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base, devicecpu) pairs [[query, chunk] for chunk in topk_chunks] scores reranker.predict(pairs)拿到分数后按降序重排取前N个作为最终上下文。我在项目里实测过不加Rerank答案相关性打分人工评估约6.8分加了Rerank后直接升到8.2分尤其对长文档、信息密集的场景提升显著。毕设里如果时间紧加Rerank这一项就够写一个实验小节了。4.3 Prompt模板设计决定答案质量的最后一公里检索做得再好Prompt写得一塌糊涂模型照样答非所问。我调过很多版Prompt最后稳定使用的模板如下你可以直接抄走你是企业知识库问答助手。请严格基于以下参考资料回答用户问题。 要求 1. 如果参考资料包含答案请直接回答并在回答末尾列出参考来源文档名片段序号。 2. 如果参考资料不足以回答问题请明确说根据现有资料无法回答不要编造。 3. 回答要条理清晰、语言简洁先给结论再展开细节。 参考资料 {context} 用户问题{question}这里有几个设计要点严格基于参考资料这是RAG防幻觉的核心指令一定要写在最前面。模型是概率生成器你不加这一句它真敢自由发挥。列出参考来源强制模型输出依据既是溯源需求也是答辩时的展示亮点。无法回答就直说避免模型生硬编造这也是论文里可以量化统计拒答率的评估点。{context}的位置放在用户问题之前让模型在生成时就看到参考资料而不是等到回答中途。插一句有些模型对上下文位置敏感参考资料放在最后反而容易被忽略。如果你还要支持多轮对话可以把历史对话也拼进Prompt里。但注意不要无脑把所有历史都塞进去一般保留最近两轮就够否则Prompt越长响应越慢、越容易跑偏。我用的是一个滑动窗口def build_prompt(question, context, history, max_history2): history_text for turn in history[-max_history:]: history_text f\n用户{turn[user]}\n助手{turn[assistant]}\n prompt f你是知识库问答助手。...同上模板... 对话历史{history_text} 参考资料{context} 当前问题{question} return prompt4.4 生成环节模型选择与流式返回生成用的LLM分两种路线API路线GPT-4o-mini、GLM-4-Flash、Qwen-Plus等。优点是不占本地资源、效果稳定缺点是答辩现场没网就尴尬了。本地部署路线用Ollama跑Qwen2.5-7B-Instruct或qwen2.5:3b。优点是离线可用、零成本演示缺点是普通笔记本跑7B模型速度偏慢。我实测过3B量化模型在MacBook上大概每秒输出10~15个汉字用于答辩演示够用追求效果可以上7B但显存至少8GB。答辩稳妥方案是本地部署一份API作为备用降级方案。系统里做一个模型路由配置本地挂了自动切API这种工程细节写在论文里也很加分。调用本地模型生成时记得关闭OpenAI兼容API的temperature随机性一般设0.1~0.3之间降低胡编概率import requests def generate_answer(prompt, streamTrue): resp requests.post( http://localhost:11434/v1/chat/completions, json{ model: qwen2.5:7b-instruct, messages: [{role: user, content: prompt}], temperature: 0.2, stream: stream, }, streamTrue, ) # 解析SSE流式返回...5. 系统评估与调优从命中率到回答质量的提升路径做毕业设计最大的误区就是Demo能跑就完事。答辩评委一定会问你怎么验证你的系统效果好这时候你要是拿不出数据场面就很难看。所以评估这块一定要认真做既是为论文积累数据也是真正把系统调好的手段。5.1 指标设计检索阶段和生成阶段分开评我建议把评估拆成两个维度对应系统的两个阶段检索阶段指标Hit Rate命中率测试集中的每个问题检索结果里是否包含标准答案所在的文档/片段包含即为命中。衡量找不找得到。MRRMean Reciprocal Rank标准答案在检索结果中的排名倒数的平均值。比如标准答案排在第2位那这个问题的MRR就是1/2。衡量排得够不够靠前。生成阶段指标忠实度Faithfulness生成的答案是否严格基于给定资料有没有加入资料外的信息。通常用LLM作为裁判LLM-as-judge打分。答案相关性答案是否正面解决用户问题。同样用LLM打分或人工打分。拒答率资料不足时模型能否正确说不知道而不是硬编。这在专业场景下反而是加分项。5.2 构建测试集别偷懒这是论文数据的根基测试集怎么来最好的人工构建方式是从每份文档里手工抽10~20个问答对——问句尽量模拟用户的真实问法标准答案直接从文档里摘抄原文。一个50问答对的小规模测试集够毕设实验用了。更省力的半自动方案是先用LLM根据文档生成候选问答对再人工筛选修正。但注意LLM生成的问句往往偏简单会和向量检索配合得太好导致指标虚高。我的建议是至少保证30%的问句由人工改写加入一些口语化表达和模糊提问这样评测结果更真实。5.3 调优实验我做过的几组对比及结论论文里要有实验数据我把自己验证过的几组典型调优结果列出来供你参考实验变量方案A方案B结论切块大小200字500字复杂文档场景500字效果更好短文档200字更精准是否加重叠无重叠80字重叠加重叠后Hit Rate提升约8%是否加Rerank仅向量检索向量Rerank答案忠实度提升显著混合检索仅向量关键词向量专业术语类问题召回率提升明显TopK数量K3K5复杂问题K5更好简单问题K3更精准做实验时一定要控制变量——每次只改一个参数记录指标变化。这个实验过程的严谨性答辩时比实验结论本身更让评委认可。5.4 一个容易被忽略的调优点文档元数据过滤如果你的知识库里有多个主题的文档比如学校规章制度和计算机课程资料混在一起检索时如果不加过滤用户问奖学金申请条件结果检索出大量计算机课程的片段命中率自然很低。解决思路是入库时为每篇文档打标签部门、类型、年份等检索时如果用户问题带了限定词如2024年后勤处先用LLM做意图识别把限定词转成元数据过滤条件。这个点在论文里可以写成面向多源异构知识库的混合检索策略听起来就很有工作量。6. 开发环境搭建与工程化落地踩坑记录和毕设交付建议最后这部分是血泪经验帮你少走弯路。很多同学做RAG毕设卡住的地方根本不是算法而是环境搭建和工程细节。我按从环境到交付的顺序梳理一遍。6.1 环境搭建议Python版本、依赖管理、硬件说明我的建议组合2025年上半年验证过Python 3.10 poetry管理依赖 本地CPU运行Embedding和Rerank Ollama运行LLM。PyTorch装CPU版就行不需要CUDA这样在普通笔记本上也能完整跑起来。以下依赖直接抄走pip install langchain langchain-community langchain-text-splitters pip install pymilvus sentence-transformers pip install pymupdf python-docx paddleocr paddlepaddle pip install fastapi uvicorn sse-starlette pip install openai # 兼容Ollama接口如果你用的是Apple Silicon芯片建议用onnxruntime版Embedding或optimum量化速度能快不少如果是N卡且有8GB以上显存直接用CUDA版PyTorchEmbedding速度提升接近10倍。6.2 踩坑实录我见过最多的五个翻车点坑一Embedding模型版本不一致。离线入库用的模型和在线检索用的模型不相同检索结果完全不可用。解决办法把模型名写死在配置文件里加一个启动时自检校验离线/在线Embedding模型一致。坑二中文乱码。PDF解析出来的中文偶尔是乱码尤其老旧的PDF可能用了非标准编码。解决办法解析后做乱码检测检测到连续替换字符UFFFD或低置信度字符就标记该文档解析失败提示用户更换PDF源文件而不是硬塞进知识库污染数据。坑三向量库重启后数据丢失。Milvus Lite的本地文件如果你改了目录或者误删数据就没了。解决办法写一个数据导出脚本定期把向量库内容导出成JSON备份答辩前务必备份一次。坑四Prompt过长报错。如果知识库里某篇文档被切成超大块加上历史对话后超过模型的上下文窗口尤其本地7B模型窗口只有8K请求直接报错。解决办法在Prompt组装前做token截断检查超长就缩减历史轮数或截断context。坑五参考答案来源是编的。有些模型为了完成指令即使资料里没有相关内容也会硬编一个参考来源。解决办法生成后加一个Post-check——用检索结果反向验证答案如果答案里提到某个来源但检索结果里根本没有该片段就标记为疑似幻觉并在前端提示。6.3 代码组织不要全堆在一个文件里毕设源码有一个经典扣分项所有逻辑堆在一个main.py里几千行代码让评委翻得很痛苦。我建议按模块拆分成这样rag-knowledge-system/ ├── backend/ │ ├── api/ # FastAPI路由层 │ │ ├── chat.py │ │ ├── kb.py │ │ └── upload.py │ ├── core/ # 核心配置 │ │ └── config.py │ ├── llm/ # LLM调用封装 │ │ ├── local_model.py │ │ └── api_model.py │ ├── rag/ │ │ ├── embedder.py # Embedding封装 │ │ ├── retriever.py # 混合检索 │ │ ├── reranker.py # 重排 │ │ ├── splitter.py # 文本切块 │ │ ├── prompt.py # Prompt模板 │ │ └── pipeline.py # 问答链路编排 │ └── storage/ │ ├── vector_store.py # Milvus操作 │ └── doc_parser.py # 文档解析 ├── frontend/ # 前端代码可以用Streamlit快速搭 ├── scripts/ │ ├── build_kb.py # 离线构建知识库脚本 │ └── eval.py # 评估脚本 ├── docs/ # 文档包括设计文档、数据库设计等 └── tests/ # 单元测试这种结构不用多么高深但一眼看出你是有工程素养的比堆代码强太多。6.4 答辩准备的三板斧最后说说答辩。RAG系统答辩很看演示我总结三个必杀技预置一个硬核问题。提前在知识库里放一份你最熟的文档准备一个只有这份文档能回答的细节问题比如这份合同里第三条第二款规定的违约金比例是多少。演示时现场提问系统流式输出答案并自动显示来源——评委瞬间知道你的系统不是玩具。准备一个拒答案例。故意问一个知识库里完全没有的问题让系统回答根据现有知识库无法回答。这比回答正确更动人因为它证明你做了防幻觉设计这正是RAG的核心价值。准备好对比数据。把未用RAG直接问大模型和用了RAG之后的相同问题答案放一起展示前者可能一本正经地胡说八道后者有依据有来源。这种直观对比比任何指标都有说服力。6.5 拿着这套系统还能往哪扩展写在最后的个人建议如果你做完这套系统还有余力我建议优先试一下Agentic RAG——让大模型在检索时根据问题的复杂程度决定要不要多轮检索要不要调用工具。比如用户问对比去年和今年的奖学金政策变化系统需要先去知识库检索去年的政策文档再检索今年的政策文档最后汇总对比。这种多步推理场景是普通RAG的短板也是目前工业界最热门的方向。做出来往简历上一写复杂查询路由多跳检索这些关键词足够和面试官聊半小时。再或者给系统加一个知识库更新的思路做增量更新而不是全量重建。毕设做完之后你会发现RAG这个方向真的是入门容易、深入无尽每解决一个问题都会冒出两个新问题等着你而这种持续探索的感觉恰好是做毕业设计最大的收获。