本地RAG文档问答系统搭建指南：原理、代码与避坑

我把一沓 PDF 沿着目录摊开，想找一个参数配置的具体取值，结果 Ctrl+F 按了七次，搜出来的全是目录摘要，真正有用的一句话卡在表格备注里。这就是我最开始想搭 RAG 文档问答系统的原因：把这些本地文档喂给一套能检索、能回答、能给出处的程序，让“翻文档找答案”变成“直接问，答案和页码一起出来”。

这篇文章写给零基础读者，目标非常明确：你用一台普通笔记本，把 PDF、Word、TXT、Markdown 放进一个文件夹，运行两条命令，就能拥有一个完全跑在本机的文档智能问答服务。文档不出本机，模型用开源权重，所有代码都会贴出来，不需要先学完一遍深度学习再动手。我会把选型理由、核心原理、完整代码、跑通之后才遇到的坑全部摊开讲，你照着做，今天大概率能把系统跑起来。

1. 先别急着装环境，想清楚RAG替你做掉了哪些事

很多教程上来就让你装一堆包，结果装完也不知道每一步为什么要这么做。我想反过来，先用最直白的方式说清楚这套东西到底在解决什么问题，你心里有底之后，后面填代码就顺了。

1.1 RAG的本质：给大模型一本书，允许它当场翻

RAG 全称 Retrieval-Augmented Generation，中文叫检索增强生成。拆开看就两步：先从你的文档仓库里把跟问题相关的片段捞出来，再让大模型对着这些片段组织回答。关键是“当场翻找”，不是“背下来”。

用一个开卷考试的类比你就明白了。大模型平时读过海量资料，但它不可能记住你的产品手册、合同条款、内部 SOP。你直接问它某个私人文档里的细节，它只能要么瞎编，要么说不知道。RAG 做的事情，就是开考前递一张小抄：把你的文档切成一堆小碎片，存进检索库，用户提问时系统拿问题去库里找最相关的几段，然后让大模型基于这几段正式作答。大模型不需要真的“知道”你的文档，它只需要把给你的资料读懂再回答，准确率就会高很多。

1.2 用RAG而不是微调，真实原因是什么

很多人第一次听说知识库方案时，会纠结另一个方向：把我的领域知识“微调”进大模型不也一样吗？表面看都是让模型更懂你的业务，实际差别非常大。微调是把知识写到模型权重里，你需要大量配对样本、训练显卡和调试时间，而且一旦文档更新，就要重新训练。RAG 不一样，它把“知识存取”这件事放在模型外面，问答发生时才临时检索，文档改了，只要重新入库，模型下一次回答就跟着变。

我个人的判断是：如果你的目标就是“让模型会回答我现有文档里的问题”，RAG 是性价比最高的起点。微调更适合做“模型的行为范式改变”，比如要让它学会某种固定的输出格式、某种语气风格。那不是本文要覆盖的内容。

1.3 什么样的文档适合做成RAG问答

不是所有资料塞进去都能得到好效果。RAG 擅长的是“答案就藏在某一段落里”的问题。比如产品手册里查配置参数、合同里看违约条款、论文里找某段结论、FAQ 里检索标准回答。这类问题有一个共同点：文档里有明确的局部答案，检索能把它找出来。

不太适合直接硬塞的情况也要说清楚。扫描版的 PDF 里面根本没有文字层，直接读取出来是一堆乱码，需要先做 OCR 再入库。高度依赖表格、图表表达的文档，切成文本块后信息结构会丢失，问答效果会打折扣。还有一类“跨章节综合题”，比如“这本书的核心逻辑是什么”，它需要吃进多个章节才能回答，单靠 TopK 检索几个片段往往答不完整。碰到这类需求，建议先做章节摘要，把摘要结果建成一个独立知识库再做问答。

2. 我的本地部署配置：不追求顶配，追求今天能跑通

确定要搭之后，第一件事不是写代码，而是选型。这一节我会把我现在实际在用的组合完整列出来，并且说清楚每一项为什么这么选。

2.1 硬件门槛到底有多低

先给结论：CPU 16G 内存的笔记本，就能把这套系统跑起来。我实测过的最基础配置是一台普通 i5 处理器的 Windows 笔记本，16G 内存，没有独显。对话模型用的 3B 量化版本，Embedding 模型大概 1.2G，Chroma 向量库是纯嵌入式，没有独立服务。整体资源占用集中在推理那一刻，问答时能明显感觉到风扇转起来，但不会卡死，一次回答大约需要十到二十秒。

如果你的电脑配置好一点，体验会舒服很多：有 8G 以上显存，可以把对话模型换成 7B 甚至 14B 参数版本，回答质量明显上一个台阶。如果只能纯 CPU，也千万别强行上 14B，一次回答等五分钟会很崩溃，3B 是可靠下限。

2.2 对话模型为什么选3B级别

本地部署的方案里，对话模型是我的核心主力。我选择的是 Qwen2.5 的 3B 量化版本，在 Ollama 里的标识是 qwen2.5:3b。选它的原因主要有三个：中文效果在同体积模型里排在第一梯队；量化后权重只有两个 G 左右，内存压力小；Ollama 一条命令就能拉下来，不需要手动处理模型格式。

你可能觉得 3B 太小，会不会很傻。实测下来，用作 RAG 的“阅读器”角色完全够用，因为真正复杂的逻辑是检索完成的，模型的工作只是把资料读懂然后用通顺的话说出来。如果你有条件使用 7B 或 14B，把代码里对应的模型名换掉就能升级，不需要改其他代码。

2.3 Embedding模型：问答质量的隐形天花板

很多人把注意力都放在对话模型上，忽略了一个更关键的角色：Embedding 模型。它负责把你的文档切片和用户问题都转成向量，检索能不能找到正确段落，完全看它。我选的是开源的 bge-m3，中文检索能力强，支持最长 8192 token 的输入，模型体积 1.2G 左右，在 Ollama 中也直接能拉取。

简单解释一下“向量”这个抽象概念：它本质上是把一段文字压缩成一个长串数字，要求是现代模型做到的，语义上接近的句子，它们对应的数学向量在空间里的距离也越近。Embedding 模型好坏，直接影响“问得近似但不完全相同，还能不能找到原段落”这件事。中文场景里，优先选在中文语料上训练过的模型，比那种笼统一揽子多语言的通用模型要准得多，这一点算是我的经验之谈。

2.4 向量库和框架：能少依赖就少依赖

向量库负责存储文本向量，并在提问时快速检索最相似的向量。我选择 Chroma，理由是它在嵌入式模式下一个目录就能跑，不需要单独部署服务，尤其适合个人知识库这种轻量场景。你写PersistentClient(path="./chroma_db")，所有索引就落在这个目录里，备份迁移都很省事。

至于是否套用 LangChain 这类大型框架，我踩过不少坑之后反而选择不硬套。LangChain 抽象层级多，版本升级频繁，你照着一个旧教程写完，可能哪一天 import 就报错了，而且内部封装的黑盒逻辑让你很难排查“为什么没检索到”。本文代码里，文档加载用 pypdf 和 python-docx，文本切分手写，Embedding 和对话都直接调 Ollama 的 API，只有向量存储和检索使用 Chroma。这套组合依赖少、逻辑透明，出了问题我大概能猜到是哪一环。

3. RAG五段式流水线，每一段到底在干什么

代码之前，先把 RAG 的完整链路吃透。整个流程可以分成五段：文档加载、文档切分、文本向量化、检索召回、生成回答。这一节我一段一段拆开讲，同时也解释参数背后的逻辑。

3.1 文档加载：先把“PDF里的字”变成干净的纯文本

这一步看似简单，其实坑很多。PDF 解析不是把文件读出来就完事，文件的字体编码、分栏排版、页眉页脚都会让提取出的文本变得很杂乱。加载环节的目标只有一个：把不同格式的文档统一成干净的字符串，交给后续切分。我平时支持的格式包括 PDF、DOCX、TXT、MD、HTML，每种格式用对应的解析库读取，然后把每页或每段文本用换行拼起来。

文档加载阶段不需要做语义工作，但必须做基础清洗。比如页眉页脚会在每页重复出现，如果不清除，切分后的多个片段里都会混入相同噪音；HTML 的脚本标签和样式表要过滤掉；PDF 里常见的人工换行会导致一句话被拆成两半，影响后面的切分质量。我的经验是：在加载阶段多花几分钟处理脏数据，比之后调任何参数都有效。

3.2 文档切分：500字符块加100字符重叠是怎么定出来的

加载完的文档通常很长，你不能把整篇 PDF 作为一个整体入库。原因很直接：一是大模型上下文窗口有限，塞不进几十万字；二是即便塞得进去，检索时要找一个问题的对应片段，等于大海捞针，噪声太大。所以必须把文档切成大小适中的片段，每个片段作为一个独立检索单元。

我默认的切分参数是：每块 500 字符，相邻块之间重叠 100 字符。这两个数字不是玄学，而是来自实际经验的经验值。分块太小，单个片段语义内容不足，检索到之后模型也看不出来龙去脉；分块太大，一个片段里塞了多个主题，检索命中率下降。500 字符对中文来大约是一页半的内容量，既能保留完整语义，又不至于太臃肿。重叠则是为了防“截断问题”——如果一个关键信息正好落在块边界上，下一块也会保留这部分内容，不会出现内容丢失。

切分还有一个容易被忽略的技巧：切分点尽量落在句号、问号、感叹号或换行符之后。简单说就是别硬切，宁可往左找最近的一个断句符号，也别把一句话拦腰截断。后面的代码里我会提供一个自带这个逻辑的切分函数。

3.3 文本向量化：把语义变成坐标点

切分完成后，每个文档片段都要交给 Embedding 模型转成一个向量。向量化之后，Chroma 会把这些向量和原始文本、元数据一起存入索引。这里必须理解的关键点是：检索阶段比较的不是文本本身，而是文本对应的向量。向量之间的距离越近，代表语义上越相似。

用一个生活类比：把文档片段想象成地图上的城市，向量就是它的经纬度坐标。语义接近的内容，天然落在相近的区域。用户提问时，系统先把问题也变成一个向量坐标，然后去地图上找最近的几个“城市”，返回它们的原始文本。Chroma 内部使用 HNSW 索引来做近似最近邻搜索，速度快，适合几十万条级别的本地库。创建 collection 时我特意指定hnsw:space为 cosine 余弦距离，因为余弦距离在文本召回里比欧氏距离更符合“语义相似”的判断习惯。

3.4 检索召回：别一次给太多，TopK有讲究

向量化只是开始，检索环节需要决定“召回多少个片段”。我默认设置 TopK=5，也就是返回最相关的 5 个片段。道理很简单：少了，答案可能不完整；多了，会有一堆无关内容干扰大模型，导致回答变得冗长、跑题。5 这个数字是我在中等长度文档集上反复试出来的平衡点。

检索的结果不只是文本，还必须带上元数据。元数据里最重要的一项就是原始文件路径，这样问答系统可以把答案和出处对应起来。如果你不给模型元数据，它回答时根本不知道自己引用的是哪一段，可追溯性就不存在了。另外，Chroma 的 query 接口可以返回距离值，这个值可以用来判断当前检索质量——如果最短距离已经很高，说明知识库里可能根本没有用户想问的内容，后续可以据此做“不知道”的兜底。这部分我会在避坑章节展开。

3.5 生成回答：给大模型一份开卷小抄再让它答题

检索到 5 个相关片段之后，不能直接把它们丢给模型说“你看看”，而是要按照固定模板拼进 Prompt。Prompt 在这里扮演了双重角色：既把资料传给模型，又规定模型的输出边界。我通常会在 Prompt 里明确写三句话：只能依据下面资料回答；资料里没有的信息不要编造；如果确实找不到就明确说不知道。这样能显著减少一本正经的胡说八道。

调用本地模型时我还设置了两个重要参数：temperature=0.2，控制随机性，回答更忠于资料；num_ctx=4096，扩大模型实际可用的上下文窗口。这个细节很多人会忽略，默认上下文可能只有 2048 token，一旦资料拼接后超过这个长度，后面内容会被静默截断，答案自然残缺。把上下文开到 4096，等于给“开卷考试”留出足够大的可翻阅范围。

4. 完整代码直接抄，我按三步把流程跑通

好了，原理讲完，进入最实用的部分。下面的代码我按两个文件组织：index.py负责整理文档、建索引；ask.py负责检索和回答。额外再给一个可选的 Web 搜索框。你只需要把自己电脑上的文档放进一个目录，一条命令建索引，一条命令启动问答。

4.1 准备依赖与模型

创建工程目录，比如rag_qa，把文档放到docs子目录下。requirements.txt内容如下，我特意没有锁死精确版本，只要求最低版本，避免你照着装的时候因为版本过于老旧报错。

pypdf>=5.0.0 python-docx>=1.1.0 beautifulsoup4>=4.12.0 chromadb>=0.5.0 requests>=2.31.0 gradio>=4.44.0

安装依赖并使用 Ollama 拉取两个模型：

pip install -r requirements.txt ollama pull qwen2.5:3b ollama pull bge-m3

Ollama 安装后需要保持后台运行，Windows 和 macOS 上装完就直接驻留了。你可以先用ollama run qwen2.5:3b启动对话测试一下，问一句“你好”，确认模型正常再继续。这一步能提前排掉 OLLAMA 服务没有就绪的问题，后面写代码就不会被环境因素反复折磨。

4.2 索引模块 index.py：读取-切分-入库

完整代码在这里，保存为index.py。核心逻辑分四段：扫描目录收集文件、解析文件成纯文本、按句切分片段、向量化后写入 Chroma。

import argparse from pathlib import Path import requests import chromadb EMBED_MODEL = "bge-m3" SUPPORTED_SUFFIX = {".pdf", ".docx", ".txt", ".md", ".html"} def get_embedding(text: str) -> list: resp = requests.post( "http://localhost:11434/api/embed", json={"model": EMBED_MODEL, "input": [text]}, timeout=60, ) resp.raise_for_status() return resp.json()["embeddings"][0] def load_document(path: Path) -> str: suffix = path.suffix.lower() if suffix == ".pdf": from pypdf import PdfReader reader = PdfReader(str(path)) pages = [] for page in reader.pages: pages.append(page.extract_text() or "") return "\n\n".join(pages) if suffix == ".docx": import docx doc = docx.Document(str(path)) return "\n\n".join(p.text for p in doc.paragraphs) if suffix in {".txt", ".md"}: return path.read_text(encoding="utf-8", errors="ignore") if suffix == ".html": from bs4 import BeautifulSoup html = path.read_text(encoding="utf-8", errors="ignore") return BeautifulSoup(html, "html.parser").get_text("\n") raise ValueError(f"暂不支持的文件类型: {suffix}") def split_text(text: str, chunk_size: int = 500, overlap: int = 100) -> list: text = text.replace("\r\n", "\n").strip() chunks = [] start = 0 while start < len(text): end = min(start + chunk_size, len(text)) if end < len(text): # 优先在句子断点处切断，避免一句话被切得七零八落 for sep in ["。", "！", "？", "\n"]: pos = text.rfind(sep, start, end) if pos != -1: end = pos + 1 break chunk = text[start:end].strip() if chunk: chunks.append(chunk) if end >= len(text): break start = max(0, end - overlap) return chunks def collect_files(root: Path) -> list: files = [] for p in root.rglob("*"): if p.is_file() and p.suffix.lower() in SUPPORTED_SUFFIX: files.append(p) return files def build_index(paths: list, rebuild: bool = False): client = chromadb.PersistentClient(path="./chroma_db") if rebuild: try: client.delete_collection("docs") except Exception: pass collection = client.get_or_create_collection( name="docs", metadata={"hnsw:space": "cosine"}, ) ids, embeddings, documents, metadatas = [], [], [], [] for path in paths: text = load_document(path) chunks = split_text(text) for idx, chunk in enumerate(chunks): ids.append(f"{path.stem}_{idx}") embeddings.append(get_embedding(chunk)) documents.append(chunk) metadatas.append({"source": str(path)}) print(f"已处理: {path}，切分 {len(chunks)} 段") batch_size = 16 for i in range(0, len(ids), batch_size): collection.add( ids=ids[i:i + batch_size], embeddings=embeddings[i:i + batch_size], documents=documents[i:i + batch_size], metadatas=metadatas[i:i + batch_size], ) print(f"索引完成，共 {len(ids)} 个片段") if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument("--path", type=str, default="./docs") parser.add_argument("--rebuild", action="store_true") args = parser.parse_args() root = Path(args.path) files = collect_files(root) if not files: raise SystemExit(f"目录下没有找到支持的文档: {root}") build_index([str(f) for f in files], rebuild=args.rebuild)

代码里我保留了一个隐蔽但很重要的变量：批次量batch_size=16。如果你一次性把几百个片段全部 add 进去，Chroma 也能跑，但把大量嵌入数据一次性塞进内存容易让低配置机器卡顿。每 16 条写一次，是一个在速度与内存之间比较合适的折中。第一次建索引会比较慢，因为 Embedding 模型和对话模型首次调用都需要加载权重，耐心等一会儿。

4.3 问答模块 ask.py：检索加生成合体

第二个文件保存为ask.py，负责查询向量库、拼接 Prompt、请求本地模型生成答案，并且把参考来源一并返回。完整代码如下。

import argparse import requests import chromadb MODEL = "qwen2.5:3b" EMBED_MODEL = "bge-m3" TOP_K = 5 def get_embedding(text: str) -> list: resp = requests.post( "http://localhost:11434/api/embed", json={"model": EMBED_MODEL, "input": [text]}, timeout=60, ) resp.raise_for_status() return resp.json()["embeddings"][0] def retrieve(question: str, top_k: int = TOP_K): client = chromadb.PersistentClient(path="./chroma_db") collection = client.get_or_create_collection( name="docs", metadata={"hnsw:space": "cosine"}, ) res = collection.query( query_embeddings=[get_embedding(question)], n_results=top_k, include=["documents", "metadatas", "distances"], ) return res["documents"][0], res["metadatas"][0], res["distances"][0] def ask(question: str, top_k: int = TOP_K): docs, metas, distances = retrieve(question, top_k) context = "\n\n".join( f"[片段{i + 1}] 来源: {meta['source']}\n{doc}" for i, (doc, meta) in enumerate(zip(docs, metas)) ) prompt = f"""你是一个严谨的文档问答助手。请只根据下面提供的资料回答问题，不要使用资料之外的知识。 资料： {context} 问题：{question} 要求： 1. 如果资料中没有明确答案，请回答“资料中没有找到相关信息”。 2. 回答尽量简洁、准确，可以直接引用资料中的原话。 3. 不要编造出处。 回答：""" resp = requests.post( "http://localhost:11434/api/chat", json={ "model": MODEL, "messages": [{"role": "user", "content": prompt}], "stream": False, "options": {"temperature": 0.2, "num_ctx": 4096}, }, timeout=120, ) resp.raise_for_status() answer = resp.json()["message"]["content"] sources = [m["source"] for m in metas] return answer, sources if __name__ == "__main__": parser = argparse.ArgumentParser() parser.add_argument("--question", type=str, default=None) args = parser.parse_args() if args.question: answer, sources = ask(args.question) print(answer) print("\n来源文件：") for s in set(sources): print(f"- {s}") else: import gradio as gr def ask_ui(question: str): answer, sources = ask(question) source_text = "\n".join(f"- {s}" for s in set(sources)) return f"{answer}\n\n参考来源：\n{source_text}" gr.Interface( fn=ask_ui, inputs=gr.Textbox(label="输入问题"), outputs=gr.Markdown(label="回答"), title="本地文档问答", ).launch()

这里的 Prompt 写法是关键。我明确要求模型只使用资料，并且给出“没有找到就直说”的兜底规则。实际运行中你会发现，这个规则能挡住大量无效输出。ask.py支持两种模式：不加参数运行会打开一个 Gradio 网页界面；加--question "你的问题"则直接在命令行输出答案和来源，适合快速验证或脚本调用。

4.4 三步跑通，你能看到什么

第一步，把文档放进docs目录。第二步，运行建索引导：

python index.py --path docs --rebuild

看到“索引完成，共 XX 个片段”就算成功。第三步，启动问答：

python ask.py

浏览器会自动打开一个搜索框，输入“这份文档里关于XX是怎么规定的”，下方会返回答案和来源文件。如果想在终端快速体验，用python ask.py --question "..."也一样。

5. 跑通之后接踵而至的坑，逐个拆给你看

建索引和问答顺利跑通只是第一步，真正让我花了大量时间调优的，是下面这几个跑通之后才会出现的问题。每一类我都给出定位方法和修复思路，你遇到时可以对照排查。

5.1 分块参数导致的“答案只有一半”

现象是你的问题明明能从一个段落里找到答案，但回答总是缺后半截细节。最典型的原因是：答案恰好分布在两个相邻分块的交界处，而你检索时只命中了其中一块，另一块因为相似度不够高被排到了后面。分块参数在这里起了决定作用。

我当时遇到过一个产品手册场景，参数表格正好被硬切在中间，上半张表在片段A，下半张表在片段B，检索到片段A之后，模型给出的答案只有半个参数含义。解决方案有两个，你组合着用：一是把块大小从 500 调到 800，让单块装下更多内容；二是把重叠从 100 调到 150，让关键文本在相邻块里重复出现，任何一个块被召回，另一块的内容也不至于全丢。

5.2 问A返回一堆B，检索噪声从哪来

有时你会看到模型明明有资料，却答非所问，因为检索回来的 5 个片段里混入了 3 个不相关的段落。根本原因是问题短、文档片段也多，向量匹配不够精准。特别是问专有名词、编号、型号这类问题，纯向量检索经常抓不住重点。

我的建议是分层处理：先看 Chroma 返回的distances，余弦距离越接近 0 越相关，如果最低距离都大于 0.5，基本可以判定没有可靠答案。接着做关键词兜底：在检索前把问题里的关键编号、英文缩写单独抽出来，用全文匹配过滤一遍文档。最后，如果仍然有噪声，可以把 TopK 调到 8 再配合下一节的“重排序”做精排。先增召回再精排，是提升检索精准率的通用思路。

5.3 一本正经地编答案，别急着怪模型

本地小模型确实容易编，但很多时候不是模型笨，而是 Prompt 和参数没设到位。温度参数temperature如果保持默认的 0.7，生成时会更自由，自由过头就会脱离资料“自行发挥”。我在代码里设置 0.2，压缩了随机性，让回答更接近原文。

另一个编答案的诱因是检索片段没拼进 Prompt。你要是只看返回的最终回答，不看中间过程的 context，就很难判断是不是检索失效。调试方法很简单：把ask()里拼接好的context打印出来，人工检查这 5 个片段到底相不相关。如果连人工都觉得不相关，说明问题出在检索；如果人工觉得相关模型还写跑偏，才需要改 Prompt 或调温度。我强烈建议你按这个顺序做定位，能省很多时间。

5.4 新文档入库后，回答还是旧的

这个问题几乎每个人都会遇到。原因多半出在索引更新策略上：我代码里的文档片段 ID 是文件名_序号，同一个文件重新入库时，旧片段会被新片段覆盖，但如果你删掉了某个文档，它的旧片段并不会自动消失。这会导致向量库里残留一堆已经删除的文档内容，问答时还在返回旧资料。

处理方式不复杂：小规模知识库最省事的办法是更新后直接--rebuild重建整个索引；如果文档数量多、重建太慢，就改成用文件内容做去重，比如用文件哈希作为 ID 的一部分，入库前先删除该哈希对应的所有旧向量。我在本地实践里用的是重建方案，又快又干净，只要文档库不是上百万量级，重建完全能接受。

5.5 还没提到的一个隐性坑：模型首轮加载极慢

你应该会发现，第一次调用 Ollama 生成回答时等待时间特别长，后续再问就快了。这是正常的冷启动，模型权重需要加载到内存。如果是连续服务场景，可以在启动脚本里先发一个空请求，或者干脆保持 Ollama 常驻，避免每次问答都经历一次冷启动。这个问题不算 bug，但第一次体验很容易误判为程序卡死，等你三分钟没反应差点关掉，结果它突然回答出来了。别问我怎么知道。

6. 下一步升级思路：从能用变成好用

如果你已经把这套系统跑通，而且解决了上面几个常见问题，剩下的就是把它打磨得更顺手。下面这几个升级方向，按投入产出比排了序，可以逐个尝试。

6.1 混合检索：向量召回和关键词召回互补

纯向量检索在“语义相似”上很强，但在“专有名词、编号、英文缩写”上不稳定。混合检索的思路是把两套结果合并：一个通道走向量，另一个通道走关键词（BM25），然后把排名分相加。关键词通道可以用rank_bm25库，配合 jieba 做中文分词。比如问“HTTPS 的握手过程”，BM25 能直接抓包含“HTTPS”的段落，向量通道可以抓更泛的“加密连接”相关内容，两层一叠加，召回质量立刻提升一个档位。

简易实现思路：分别跑向量检索和 BM25 检索，各取前 10 条，把相同片段的排名位置按加权公式合并，最终取分数最高的 5 条。权重一般向量 0.6、关键词 0.4，具体可以按文档风格微调，公式类文档关键词权重要更高。

6.2 重排序模型：召回的二次精排

混合检索解决“有没有召回”的问题，重排序解决“召回顺序对不对”的问题。重排序模型也叫 Cross-Encoder，它不把文本单独转向量，而是把问题和文档片段拼成一个整体再打分，所以语义捕捉能力比双向量检索更强，当然速度也更慢。常用做法是先用向量检索快速召回前 20 条，再用重排序模型精排取前 5 条，既有速度又有质量。

这类开源重排序模型现在已经有了相当不错的体积和效果取舍，本地跑起来压力也不大。引入后我的明显感受是：模型回答时的坚定感强了很多，因为它拿到的片段都是正确答案，不再靠运气。

6.3 多轮对话怎么加才不破坏检索

用户经常连续追问：“它大概在哪一章？”“那参数怎么配置？”如果不记住上文，系统会把“它”当成一个单独的检索问题，匹配效果很差。基础做法是把最近几轮对话历史拼进 Prompt，让模型理解追问的指代，但这里有一个关键点：向量检索仍然只应该使用“当前问题”，而不是整个对话历史。直接把历史拿去检索，会让召回结果被前面的话题带偏。

更规范的方案是先做一遍“问题改写”：把“那参数怎么配置”结合历史改写为“前面提到的那个XX参数该怎么配置”，用改写后的完整问句去检索，再把原始问题和历史一起交给模型生成回答。这个改造能让多轮问答体验明显变自然。

6.4 再往后还能做的三件事

第一，文档监控与自动更新：用文件系统监听库，目录里新增文档后自动增量入库，省去手动--rebuild。第二，多知识库隔离：把不同主题的文档放到不同 collection，query 时按用户选择的空间检索，适合团队内部多个资料库并行使用。第三，把问答能力封装成 HTTP API 接口，方便对接其他应用。

我实践下来最大的体会是：RAG 系统真正花时间的部分不是模型选型，而是文档清洗、分块参数和检索调优。一个没清洗干净的 PDF、一个不合理的重叠值，比换一个更大参数的模型更能影响最终效果。所以我的建议很朴素：先跑通，再按上述顺序逐步优化，不要在一开始就追求一步到位。这样无论你后续做本地知识库还是更复杂的自动化问答，都有一个扎实的底子在。