企业官网建设流程全解析

简介：408-RAG是一套面向计算机专业考研学生的本地化智能问答与知识检索系统，针对备考全国硕士研究生统一招生考试中知识点分散、检索效率低、专业术语理解困难等痛点，将检索增强生成、向量数据库索引与大型语言模型推理能力整合到同一套可离线运行的方案中。资源包共21个文件，约94KB，以13个Python源码文件为核心，覆盖数据预处理、检索问答与评测等模块，另含txt说明、docx附赠资料、md文档、json配置、env_example环境变量示例及LICENSE、gitignore等工程文件，结构清晰，便于按模块阅读与二次开发。目前已有57人学习下载。读者可借此理解RAG问答系统的完整实现链路，包括知识库构建、向量索引、检索召回与答案生成，并参考评测脚本与示例数据自行替换考研资料，搭建专属的本地化备考助手，同时学习环境配置与项目组织方式，为课程设计或毕业项目提供可复用的工程模板。

1. 408 备考信息过载：为什么本地 RAG 比囤网盘资料更管用

每年到了 408 复习中后期，几乎所有人都会掉进同一个坑：资料越囤越多，脑子越来越乱。王道四本单科书、历年真题、教材扫描件、自己整理的笔记、各种强化课讲义，加起来动辄几个 G。真正做题时想查一个「页表项和页目录项的区别」，却要在五六个 PDF 里来回翻，翻到最后连原本要做的题都忘了。更麻烦的是，408 四门课交叉点极多，数据结构里的图算法会牵扯到计组的存储结构，操作系统的虚拟内存又和计组的 Cache 映射方式互相印证，靠关键词搜索根本串不起来。

这个标题讲的 RAG 系统，本质就是给这种信息过载开一副后悔药：把散落的 408 资料切块、向量化、存进本地向量数据库，再用大语言模型做推理和生成，问一句「快表 TLB 命中时为什么不需要访问内存」就能直接拿到带出处的答案。它适合两类人：一是已经过了一遍基础、进入刷题和查漏阶段的考生；二是想自己动手搭一套本地知识库、顺便把 RAG 检索增强生成这套技术栈摸熟的人。整套东西跑在本地，资料不出机器，断网也能用，这一点对备考场景很关键。

2. 拆解 408-RAG 的技术栈：向量数据库、嵌入模型和 LLM 怎么分工

2.1 一条 408 问题从输入到答案的完整链路

先把链路讲清楚，后面写代码才不会迷路。用户在界面输入「进程和线程的区别」，系统先做查询改写，把口语化问题补全成「操作系统中进程与线程在资源分配、调度单位、并发性上的区别」。接着嵌入模型把这句话编码成一个高维向量，去向量数据库里做相似度检索，召回最相关的若干文本块。这些文本块连同原始问题一起塞进提示词模板，交给大语言模型推理，最后输出答案并附上来源页码。

这条链路里，向量数据库负责「找得准」，嵌入模型负责「表示得对」，LLM 负责「说得清」。三者缺一不可，但优先级不同。我的经验是：检索召回率决定上限，LLM 只决定表达质量。如果召回的都是无关段落，再强的模型也只能胡编。所以 408-RAG 的功夫，七成花在切块和检索上，三成才是模型选型。

2.2 向量数据库选型：本地场景下为什么优先考虑 Chroma 或 FAISS

向量数据库选型是热词里问得最多的。放到 408 备考这个场景，约束很明确：单机、数据量小（几万到几十万块）、要能持久化、最好零运维。按这个标准，Chroma 和 FAISS 是最稳的两个选择。

我一般会先用 Chroma 把流程跑通，因为它的collection概念天然适合按科目分库，比如os、ds、co、cn四个集合。等数据量真的上来了，再换 FAISS 做索引优化。Milvus 这类分布式方案在单机备考场景里只会增加踩坑面积，不建议一上来就上。

2.3 嵌入模型和 LLM 的本地化组合

嵌入模型决定向量质量。中文 408 资料里夹杂大量英文缩写（TLB、DMA、CPI），所以嵌入模型必须中英文都扛得住。常见做法是用BAAI/bge-small-zh-v1.5或bge-m3，前者轻量、后者多语言更强。LLM 侧，本地跑首选 Ollama 拉qwen2.5:7b或glm4:9b，显存 8G 以上就能跑量化版。如果机器实在吃力，嵌入模型本地跑、LLM 走 API 也是可以的，但资料隐私就打了折扣，自己权衡。

这里有个容易忽略的点：嵌入模型和 LLM 最好用同一套 tokenizer 生态下的东西，否则中文标点和公式符号的处理会出现细微偏差，检索时表现为「明明该召回却没召回」。这不是玄学，是分词边界问题。

3. 从零搭一套 408 本地知识库：切块、入库、检索的最小可跑代码

3.1 资料预处理：把 PDF 和笔记切成能检索的块

408 资料主要是 PDF 和 Markdown 笔记。PDF 里最头疼的是双栏排版和公式，直接抽文本会串行。我一般先用pymupdf抽文本，再按标题层级切块。切块大小控制在 500 到 800 字，重叠 100 字，保证跨段落的上下文不被切断。

import fitz # pymupdf from langchain.text_splitter import RecursiveCharacterTextSplitter def extract_pdf_text(pdf_path): doc = fitz.open(pdf_path) full_text = [] for page in doc: # 按块抽取，尽量保留阅读顺序 full_text.append(page.get_text("text")) return "\n".join(full_text) def split_into_chunks(text, chunk_size=600, overlap=100): splitter = RecursiveCharacterTextSplitter( chunk_size=chunk_size, chunk_overlap=overlap, separators=["\n第", "\n一、", "\n1.", "\n\n", "\n", "。", " "] ) return splitter.split_text(text) raw = extract_pdf_text("os_wangdao.pdf") chunks = split_into_chunks(raw) print(f"共切出 {len(chunks)} 块")

这段代码的逻辑是：先整本抽文本，再用递归切分器按中文标点和标题符号逐级切。separators的顺序很关键，把「\n第」放最前面，是为了优先在章节标题处断开，避免把一道题的题干和解析切到两个块里。chunk_size设 600 是权衡：太小则上下文不足，太大则检索精度下降。如果你的资料公式多，建议额外用unstructured库做版面分析，但那是另一个坑，先跑通文本版再说。

3.2 向量化入库：Chroma 持久化与元数据设计

切完块就要入库。元数据一定要带subject（科目）和source（来源文件），后面做过滤检索全靠它。

import chromadb from sentence_transformers import SentenceTransformer client = chromadb.PersistentClient(path="./408_vectordb") model = SentenceTransformer("BAAI/bge-small-zh-v1.5") collection = client.get_or_create_collection( name="408_os", metadata={"hnsw:space": "cosine"} ) def add_chunks(chunks, subject, source): embeddings = model.encode(chunks, normalize_embeddings=True).tolist() ids = [f"{subject}_{source}_{i}" for i in range(len(chunks))] metadatas = [{"subject": subject, "source": source} for _ in chunks] collection.add( embeddings=embeddings, documents=chunks, metadatas=metadatas, ids=ids ) add_chunks(chunks, subject="os", source="os_wangdao.pdf")

逻辑说明：PersistentClient把数据落盘到本地目录，重启不丢。normalize_embeddings=True让向量归一化，配合 cosine 距离，检索更稳。ids必须唯一，用「科目_来源_序号」拼出来最省事。参数上，hnsw:space选 cosine 而不是 l2，是因为中文文本向量的方向比长度更有意义。入库后可以用collection.count()确认块数，如果和切块数对不上，多半是 id 冲突或空块被过滤了。

3.3 检索与生成：把召回结果喂给本地 LLM

检索时先编码问题，再取 top-k。k 一般设 3 到 5，408 这种知识点密集的场景，k 太小会漏，太大会引入噪声干扰模型。

import ollama def ask_408(question, k=4): q_vec = model.encode([question], normalize_embeddings=True).tolist() results = collection.query(query_embeddings=q_vec, n_results=k) context = "\n---\n".join(results["documents"][0]) prompt = f"""你是 408 考研助教。根据以下资料回答问题，不要编造。 资料： {context} 问题：{question} 回答时标注依据的段落。""" resp = ollama.chat(model="qwen2.5:7b", messages=[ {"role": "user", "content": prompt} ]) return resp["message"]["content"] print(ask_408("进程和线程的区别是什么"))

这段是整条链路的核心。query返回的documents是嵌套列表，取[0]才是当前问题的召回结果。提示词里明确写「不要编造」和「标注依据」，能显著降低幻觉。ollama.chat默认走本地 11434 端口，模型名要和ollama list里的一致。如果回答明显跑偏，先打印context看召回内容，八成是检索环节的问题，而不是模型不行。

4. 408-RAG 避坑记录：检索命中率低、公式乱码和显存爆炸

4.1 现象：问「快表」召回的全是「快排」

原因：嵌入模型对中文短词区分度不够，加上切块时把「快表」和「快排」放进了相似上下文。解决：在查询改写阶段补全术语，把「快表」改写成「快表 TLB 转换检测缓冲区」，同时给元数据加科目过滤，只在co集合里搜。实测命中率能从 40% 提到 75% 以上。

4.2 现象：PDF 里的公式检索出来是乱码

原因：pymupdf对数学公式的文本抽取会丢失符号，向量化后变成噪声。解决：公式密集的章节单独用 OCR 或 LaTeX 抽取，存成结构化文本再入库；或者干脆在切块时跳过纯公式页，靠文字描述召回。别指望嵌入模型能理解乱码公式。

4.3 现象：本地 LLM 回答到一半卡死或显存溢出

原因：qwen2.5:7b全精度加载需要 14G 以上显存，8G 卡直接爆。解决：用 Ollama 的量化版本（如qwen2.5:7b-instruct-q4_K_M），显存占用降到 5G 左右。同时把num_ctx限制在 4096，避免长上下文吃满显存。如果还不行，嵌入模型和 LLM 分时加载，别同时驻留。

4.4 现象：同一道题问两次，答案不一致

原因：LLM 的 temperature 默认偏高，生成有随机性。解决：把temperature设成 0.1 到 0.3，top_p设 0.9。备考场景要的是稳定复现，不是创意写作。另外检索的 top-k 固定下来，别每次随机采样。

4.5 现象：新增笔记后检索不到

原因：Chroma 的 collection 没有自动重建索引，新块入库后 hnsw 索引需要刷新。解决：入库后调用collection.count()确认，必要时重建 collection。更稳的做法是每次批量入库后重启一次客户端，让索引落盘。

5. 把 408-RAG 用出复利：查询改写、重排序和自建评测集

跑通最小链路只是开始，真正拉开差距的是检索质量优化。第一个技巧是查询改写：用 LLM 把口语化问题扩写成带术语的标准问法，再拿去检索。比如「那个地址转换的东西」改写成「虚拟地址到物理地址转换 页表 TLB」，召回率提升非常明显。

第二个技巧是加一层重排序。先用向量检索召回 top-20，再用一个交叉编码器（如bge-reranker-base）对这 20 条精排，取前 4 条喂给 LLM。这一步能把「看起来相关但实际没用」的块过滤掉，代价是多花一点算力。408 知识点密集，重排序的收益比通用问答场景更高。

第三个技巧是自建评测集。从历年真题里挑 50 道有明确答案的题，人工标注每道题应该召回哪几个块，然后跑脚本算 hit rate。没有评测集，你永远不知道改动是变好还是变坏。

def evaluate_hit_rate(qa_pairs, k=4): hit = 0 for q, gold_source in qa_pairs: q_vec = model.encode([q], normalize_embeddings=True).tolist() res = collection.query(query_embeddings=q_vec, n_results=k) sources = [m["source"] for m in res["metadatas"][0]] if gold_source in sources: hit += 1 return hit / len(qa_pairs)

这个脚本很土，但极其实用。qa_pairs是「问题 + 正确来源文件」的列表，跑一遍就知道当前配置的 hit rate。我自己的习惯是每次调整切块大小或 top-k，都先跑这个脚本，数字不涨就不合并改动。搭 408-RAG 这件事，最怕的不是技术难，而是凭感觉调参。把评测跑起来，把召回内容打印出来看，比换更大的模型管用得多。希望帮到你。

本文还有配套的精品资源，点击获取