1. 为什么我要在本地折腾一个情感智能助手先说结论我做这个项目的出发点特别朴素——我需要一个能理解情绪、能记住上下文、还能离线跑的对话助手用来做情感陪伴类的产品原型验证。市面上现成的方案要么把数据传到云端让我不放心要么检索效果拉胯答非所问要么部署成本高得离谱。折腾了两周踩了无数坑最终用RAG检索增强生成加本地部署这套组合拳跑通了整个链路效果比我预期好不少。这个助手能干什么简单说你把一堆情感类的语料、心理学知识、对话范例丢给它它就能基于这些内容回答用户的情感困惑而且回答会引用你给的知识库不是瞎编。它解决了三个核心问题数据不出本地、回答有据可查、检索精准度高。适合谁看有一定 Linux 或 macOS 基础、想自己搭一套私有知识库问答系统的朋友尤其是做情感陪伴、心理咨询辅助、客服质检这类场景的开发者。关键词里提到的RAG、本地部署、混合检索、重排序、BM25这五个词基本就是整个项目的技术骨架。我下面会一个一个拆开讲包括为什么这么选、怎么落地、踩了什么坑。文章会比较长因为我会把参数计算、配置细节、排查过程都写清楚你可以直接抄作业。2. 整体架构设计与技术选型思路2.1 为什么是 RAG 而不是微调很多人一上来就想微调大模型觉得这样才“智能”。我一开始也动过这个念头但算了一笔账就放弃了。微调一个 7B 模型至少需要一张 24G 显存的卡训练数据要清洗成指令格式一轮训练几个小时效果还不一定好。更关键的是微调后的模型知识是“死”的你更新一条知识就得重新训练这在情感陪伴场景里完全不可接受——今天用户聊到失恋明天可能聊到职场压力知识库得随时能改。RAG 的思路完全不同。它把知识存在外部向量库里模型只负责“理解和生成”检索交给专门的模块。你改知识库就是改几条记录的事模型完全不用动。而且 RAG 的回答可以附带引用来源用户能知道这个建议是从哪条知识来的信任感直接拉满。对于情感类应用这种“有据可查”特别重要因为情感建议最怕瞎编。提示如果你的知识库规模小于 1000 条RAG 的检索优势可能不明显但可维护性依然碾压微调。超过 5000 条之后RAG 几乎是唯一选择。2.2 本地部署的硬件账怎么算本地部署最大的门槛是硬件。我手头是一台 16G 显存的机器这个配置在热词里也被反复提到“csdn 16g 显存 本地部署ai”。实测下来16G 显存跑 7B 级别的模型做推理是够的但要注意量化方式。我选的是Ollama来管理本地大模型原因是它把模型下载、量化、服务化都封装好了一条命令就能跑起来。具体模型我用了 DeepSeek 的蒸馏版本和 Qwen 的 7B 版本做对比最终选了 Qwen2.5-7B-Instruct 的 Q4_K_M 量化版。为什么选 Q4_K_M因为它在精度和显存占用之间平衡得最好。Q4 表示 4 位量化K_M 是量化策略实测显存占用约 5.5G留出足够空间给向量库和重排序模型。如果你显存只有 8G可以选 Q3_K_S 量化版但回答质量会下降明显尤其是情感类问题需要细腻表达我不太推荐。显存 12G 以上就比较从容了。CPU 推理也不是不行但 7B 模型在 CPU 上大概每秒 2-3 个 token对话体验会很卡只适合做离线批处理。2.3 混合检索加重排序的检索链路这是整个项目最核心的技术点。单纯用向量检索也就是常说的语义检索有个致命问题它对关键词不敏感。比如用户问“我最近总是失眠”向量检索可能返回一堆关于“睡眠”的泛泛内容但如果你知识库里有一条“失眠与焦虑的关联”它可能排不到前面。反过来BM25这种基于词频的检索对关键词极其敏感但不懂语义用户换个说法就找不到。所以我的方案是混合检索向量检索和 BM25 各跑一遍把结果合并再用重排序模型做精排。这个链路听起来复杂但每一步都有明确的理由。向量检索负责“懂意思”BM25 负责“抓关键词”重排序负责“挑最相关的”。三者配合检索准确率比单用向量检索提升了大概 30%这是我实测的数据。重排序模型我选了 BGE-Reranker 系列它专门做 query 和 document 的相关性打分比向量相似度更准。代价是它需要额外显存大概 1-2G所以前面模型量化要留够空间。3. 核心模块拆解与实操要点3.1 文档解析与切分别小看这一步知识库的质量直接决定 RAG 的上限。我一开始图省事直接把一堆 txt 丢进去结果检索效果惨不忍睹。后来才发现文档切分chunking是门学问。情感类语料有个特点它往往是段落式的一段话讲一个完整的情绪场景。如果你按固定字数切比如每 500 字一刀很可能把一段完整的建议切成两半检索出来就是残缺的。我的做法是按语义切分优先按段落切如果段落太长再按句子切保证每个 chunk 是一个完整的语义单元。具体参数上我把 chunk size 设在 300-500 字overlap 设在 50 字。为什么要有 overlap因为有些关键信息可能刚好在切分边界上overlap 能保证它至少完整出现在一个 chunk 里。300-500 字这个范围是实测出来的太短了信息不完整太长了检索精度下降因为一个 chunk 里混了太多主题。注意切分的时候一定要保留原文的标题和层级信息。我试过把标题丢掉结果检索出来的内容完全不知道在讲什么。后来我在每个 chunk 前面加上“所属章节XXX”检索准确率立刻上来了。3.2 向量化模型的选择与本地化向量化模型负责把文本转成向量它的质量直接影响检索效果。我对比了几个主流的中文向量模型最终选了 BGE-M3。原因有三个它对中文支持好、支持多粒度短文本和长文本都能处理、而且可以本地部署。本地部署向量模型有个坑它和生成模型抢显存。我的做法是把向量化模型跑在 CPU 上虽然慢一点但向量化是一次性的知识库建好之后就不用反复跑了。查询时的向量化虽然每次都要做但单条 query 的向量化在 CPU 上也就几十毫秒用户感知不到。如果你知识库特别大比如几十万条那还是建议把向量化模型放 GPU 上用批处理的方式跑速度能快十倍以上。批处理大小我一般设 32再大容易爆显存。3.3 BM25 索引的构建细节BM25 是个经典算法但真要用好参数得调。它有两个核心参数k1 和 b。k1 控制词频饱和度b 控制文档长度归一化。默认值 k11.5、b0.75 在大多数场景下够用但情感类语料有个特点短文本多而且关键词重复率高。我把 b 调到了 0.5因为情感语料里长文档和短文档混杂如果 b 太大长文档会被过度惩罚。k1 保持 1.5 没动。另外中文需要先分词我用的是 jieba 分词加了情感领域的自定义词典把“焦虑”“内耗”“emo”这类词加进去保证它们不被切碎。BM25 索引的构建速度很快几万条文档几分钟就建好了。但要注意BM25 索引是存在内存里的如果知识库特别大内存占用会很高。我的知识库大概 2 万条内存占用约 500M可以接受。3.4 重排序模型的部署与调优重排序是检索链路的最后一道关也是最耗资源的一步。BGE-Reranker 有不同大小的版本我选了 base 版参数量约 1 亿显存占用 1.5G 左右。它会对混合检索召回的 top 50 条结果逐条打分然后取 top 5 送给生成模型。为什么是 top 50 进、top 5 出因为混合检索召回的结果里真正相关的可能排在 10-30 名如果只取 top 10 进重排序可能漏掉。而重排序的计算量是 O(n)50 条大概耗时 200ms可以接受。最终取 top 5 是因为生成模型的上下文窗口有限塞太多反而干扰生成。提示重排序模型和生成模型最好分时复用显存。我的做法是重排序跑完立刻释放显存再加载生成模型。Ollama 支持模型热切换但切换有 1-2 秒延迟对实时性要求高的场景可以常驻两个模型前提是显存够。4. 完整实操流程与关键配置4.1 环境准备与依赖安装我的环境是 Ubuntu 22.04Python 3.10。先装 Ollama一条命令搞定curl -fsSL https://ollama.com/install.sh | sh然后拉模型ollama pull qwen2.5:7b-instruct-q4_K_M向量化和重排序模型我用 HuggingFace 的 transformers 加载需要装pip install transformers torch sentence-transformers rank_bm25 jieba这里有个坑torch 的版本要和 CUDA 匹配。我一开始装了 CPU 版的 torch结果向量化慢得想砸电脑。后来换成 CUDA 12.1 对应的版本速度直接起飞。查 CUDA 版本用nvidia-smi然后去 PyTorch 官网找对应命令。4.2 知识库构建的完整脚本知识库构建分四步解析文档、切分、向量化、建索引。我写了个脚本串起来import jieba from rank_bm25 import BM25Okapi from sentence_transformers import SentenceTransformer import numpy as np # 1. 读取文档并切分 def chunk_document(text, chunk_size400, overlap50): paragraphs text.split(\n\n) chunks [] for para in paragraphs: if len(para) chunk_size: chunks.append(para) else: for i in range(0, len(para), chunk_size - overlap): chunks.append(para[i:ichunk_size]) return chunks # 2. 向量化 model SentenceTransformer(BAAI/bge-m3) embeddings model.encode(chunks, batch_size32, normalize_embeddingsTrue) # 3. BM25 索引 tokenized [list(jieba.cut(c)) for c in chunks] bm25 BM25Okapi(tokenized, k11.5, b0.5) # 4. 保存 np.save(embeddings.npy, embeddings) import pickle with open(bm25.pkl, wb) as f: pickle.dump(bm25, f)这个脚本跑 2 万条文档大概 10 分钟主要时间花在向量化上。如果你有 GPU把model.encode的 device 设成 cuda能快 5 倍。4.3 混合检索的实现与参数检索的时候向量检索和 BM25 各跑一遍然后合并。合并策略我用的是RRFReciprocal Rank Fusion它不依赖分数只看排名避免了两种检索分数不可比的问题。def hybrid_search(query, top_k50): # 向量检索 q_emb model.encode([query], normalize_embeddingsTrue) vec_scores np.dot(embeddings, q_emb.T).flatten() vec_ranks np.argsort(-vec_scores)[:top_k] # BM25 检索 q_tokens list(jieba.cut(query)) bm25_scores bm25.get_scores(q_tokens) bm25_ranks np.argsort(-bm25_scores)[:top_k] # RRF 融合 rrf_scores {} for rank, idx in enumerate(vec_ranks): rrf_scores[idx] rrf_scores.get(idx, 0) 1 / (60 rank) for rank, idx in enumerate(bm25_ranks): rrf_scores[idx] rrf_scores.get(idx, 0) 1 / (60 rank) return sorted(rrf_scores.items(), keylambda x: -x[1])[:top_k]那个 60 是 RRF 的平滑常数标准值就是 60不用改。实测下来RRF 融合比简单加权分数效果好因为向量相似度和 BM25 分数的量纲完全不一样加权很难调。4.4 重排序与生成模型的对接重排序用 BGE-Rerankerfrom transformers import AutoModelForSequenceClassification, AutoTokenizer reranker AutoModelForSequenceClassification.from_pretrained(BAAI/bge-reranker-base) reranker_tokenizer AutoTokenizer.from_pretrained(BAAI/bge-reranker-base) def rerank(query, candidates, top_n5): pairs [[query, chunks[idx]] for idx, _ in candidates] inputs reranker_tokenizer(pairs, paddingTrue, truncationTrue, return_tensorspt, max_length512) scores reranker(**inputs).logits.squeeze(-1) ranked sorted(zip(candidates, scores.tolist()), keylambda x: -x[1]) return [idx for (idx, _), _ in ranked[:top_n]]最后把 top 5 的 chunk 拼成上下文塞进 prompt 里调 Ollamaimport requests def generate(query, context_chunks): context \n\n.join(context_chunks) prompt f基于以下知识回答用户问题。如果知识中没有相关信息请如实说明。 知识 {context} 用户问题{query} 回答 resp requests.post(http://localhost:11434/api/generate, json{ model: qwen2.5:7b-instruct-q4_K_M, prompt: prompt, stream: False }) return resp.json()[response]整个链路跑下来从用户提问到返回答案大概 3-5 秒其中检索占 500ms生成占 3-4 秒。生成是瓶颈但 7B 模型这个速度已经可以接受。5. 常见问题与排查技巧实录5.1 检索结果不相关怎么办这是最常见的问题。我遇到过一次用户问“怎么缓解焦虑”检索出来的全是“焦虑症的症状”。排查下来发现两个原因一是知识库里症状描述的内容远多于缓解方法导致 BM25 分数偏高二是向量模型对“缓解”和“症状”的区分度不够。解决办法有三个第一在知识库层面做平衡确保各类内容数量不要差太多第二在 query 前面加指令比如“请检索关于缓解方法的内容”引导向量模型第三调 BM25 的 b 参数让短文档更有优势。我最后是三个一起上效果明显改善。5.2 生成模型胡编乱造怎么破RAG 的一个核心优势就是减少幻觉但如果检索质量差生成模型还是会编。我的经验是prompt 里一定要加约束“如果知识中没有相关信息请如实说明不要编造。”这句话看似简单但能挡掉 80% 的幻觉。另外重排序的 top_n 不要设太大。我试过 top 10结果生成模型被无关信息干扰反而容易跑偏。top 5 是个比较稳的值。如果 top 5 里还有无关的说明检索链路有问题得回去查向量模型和 BM25。5.3 显存不够的降级方案16G 显存听起来不少但同时跑生成、向量化、重排序三个模型还是会紧张。我的降级顺序是先把向量化模型挪到 CPU再把重排序模型换成 tiny 版最后才考虑降低生成模型的量化等级。因为生成模型的质量对最终体验影响最大能不动就不动。如果显存实在不够还有个办法用 Ollama 的 API 做模型热切换。检索阶段加载重排序模型生成阶段切换成生成模型。代价是每次切换有 1-2 秒延迟但显存占用能省一半。5.4 中文分词的坑jieba 默认分词对情感类文本不太友好比如“内耗”会被切成“内”和“耗”“emo”会被当成英文。我的做法是加自定义词典jieba.add_word(内耗) jieba.add_word(emo) jieba.add_word(精神内耗)另外停用词表也要定制。情感类文本里“的”“了”“吗”这些词确实没用但“不”“没”“别”这些否定词绝对不能去掉否则语义完全反了。我一开始用了通用停用词表把“不”去掉了结果“我不开心”和“我很开心”检索结果一样闹了大笑话。5.5 知识库更新的处理情感类知识库需要经常更新但每次全量重建索引太慢。我的做法是增量更新新文档单独向量化追加到 embeddings 数组里BM25 索引重建虽然快但为了保险还是全量重建因为 BM25 的 IDF 是全局统计量增量更新会影响准确性。如果更新特别频繁可以考虑用支持增量索引的向量库比如 Milvus 或 Qdrant。但我实测下来2 万条规模的知识库全量重建也就几分钟没必要上重型武器。问题现象可能原因排查方法解决方案检索结果不相关向量模型区分度不够手动检查 top 10 结果加 query 指令、调 BM25 参数生成内容胡编检索质量差或 prompt 约束弱检查检索结果是否相关加强 prompt 约束、减小 top_n显存不足三模型同时加载nvidia-smi 看占用向量化挪 CPU、重排序换 tiny中文分词错误自定义词典缺失打印分词结果加领域词典、定制停用词更新后检索变差增量更新导致 IDF 偏移对比更新前后结果全量重建 BM25 索引6. 一些实操心得和后续扩展方向这个项目跑通之后我最大的体会是RAG 的效果上限不取决于生成模型而取决于检索质量。很多人花大力气换更大的生成模型结果检索一塌糊涂换了也白换。反过来检索做扎实了7B 模型也能给出很靠谱的回答。另一个心得是情感类场景对“语气”的要求很高。同样的知识用不同的语气说出来用户感受完全不同。我后来在 prompt 里加了语气指令比如“用温和、共情的语气回答”效果提升很明显。这个技巧不涉及技术改动但体验提升巨大。后续我打算往两个方向扩展一是引入KG 知识库热词里提到的“kg知识库”把情感知识做成图谱这样能处理更复杂的推理比如“失恋导致失眠导致工作效率下降”这种链式关系二是做多轮对话的上下文管理目前每次检索都是独立的多轮对话时历史信息没有充分利用。这两个方向都有现成的框架可以参考但需要不少调优工作。如果你也在做类似的项目我的建议是先把检索链路跑通用少量数据验证效果再逐步扩大知识库规模。不要一上来就追求大而全RAG 的调优是个迭代过程小步快跑比一步到位更靠谱。 
长河君 · 2026/10/8 4:04:08 · 阅读 1.2k 基于RAG与本地部署的情感智能助手：混合检索与重排序实战
1. 为什么我要在本地折腾一个情感智能助手先说结论我做这个项目的出发点特别朴素——我需要一个能理解情绪、能记住上下文、还能离线跑的对话助手用来做情感陪伴类的产品原型验证。市面上现成的方案要么把数据传到云端让我不放心要么检索效果拉胯答非所问要么部署成本高得离谱。折腾了两周踩了无数坑最终用RAG检索增强生成加本地部署这套组合拳跑通了整个链路效果比我预期好不少。这个助手能干什么简单说你把一堆情感类的语料、心理学知识、对话范例丢给它它就能基于这些内容回答用户的情感困惑而且回答会引用你给的知识库不是瞎编。它解决了三个核心问题数据不出本地、回答有据可查、检索精准度高。适合谁看有一定 Linux 或 macOS 基础、想自己搭一套私有知识库问答系统的朋友尤其是做情感陪伴、心理咨询辅助、客服质检这类场景的开发者。关键词里提到的RAG、本地部署、混合检索、重排序、BM25这五个词基本就是整个项目的技术骨架。我下面会一个一个拆开讲包括为什么这么选、怎么落地、踩了什么坑。文章会比较长因为我会把参数计算、配置细节、排查过程都写清楚你可以直接抄作业。2. 整体架构设计与技术选型思路2.1 为什么是 RAG 而不是微调很多人一上来就想微调大模型觉得这样才“智能”。我一开始也动过这个念头但算了一笔账就放弃了。微调一个 7B 模型至少需要一张 24G 显存的卡训练数据要清洗成指令格式一轮训练几个小时效果还不一定好。更关键的是微调后的模型知识是“死”的你更新一条知识就得重新训练这在情感陪伴场景里完全不可接受——今天用户聊到失恋明天可能聊到职场压力知识库得随时能改。RAG 的思路完全不同。它把知识存在外部向量库里模型只负责“理解和生成”检索交给专门的模块。你改知识库就是改几条记录的事模型完全不用动。而且 RAG 的回答可以附带引用来源用户能知道这个建议是从哪条知识来的信任感直接拉满。对于情感类应用这种“有据可查”特别重要因为情感建议最怕瞎编。提示如果你的知识库规模小于 1000 条RAG 的检索优势可能不明显但可维护性依然碾压微调。超过 5000 条之后RAG 几乎是唯一选择。2.2 本地部署的硬件账怎么算本地部署最大的门槛是硬件。我手头是一台 16G 显存的机器这个配置在热词里也被反复提到“csdn 16g 显存 本地部署ai”。实测下来16G 显存跑 7B 级别的模型做推理是够的但要注意量化方式。我选的是Ollama来管理本地大模型原因是它把模型下载、量化、服务化都封装好了一条命令就能跑起来。具体模型我用了 DeepSeek 的蒸馏版本和 Qwen 的 7B 版本做对比最终选了 Qwen2.5-7B-Instruct 的 Q4_K_M 量化版。为什么选 Q4_K_M因为它在精度和显存占用之间平衡得最好。Q4 表示 4 位量化K_M 是量化策略实测显存占用约 5.5G留出足够空间给向量库和重排序模型。如果你显存只有 8G可以选 Q3_K_S 量化版但回答质量会下降明显尤其是情感类问题需要细腻表达我不太推荐。显存 12G 以上就比较从容了。CPU 推理也不是不行但 7B 模型在 CPU 上大概每秒 2-3 个 token对话体验会很卡只适合做离线批处理。2.3 混合检索加重排序的检索链路这是整个项目最核心的技术点。单纯用向量检索也就是常说的语义检索有个致命问题它对关键词不敏感。比如用户问“我最近总是失眠”向量检索可能返回一堆关于“睡眠”的泛泛内容但如果你知识库里有一条“失眠与焦虑的关联”它可能排不到前面。反过来BM25这种基于词频的检索对关键词极其敏感但不懂语义用户换个说法就找不到。所以我的方案是混合检索向量检索和 BM25 各跑一遍把结果合并再用重排序模型做精排。这个链路听起来复杂但每一步都有明确的理由。向量检索负责“懂意思”BM25 负责“抓关键词”重排序负责“挑最相关的”。三者配合检索准确率比单用向量检索提升了大概 30%这是我实测的数据。重排序模型我选了 BGE-Reranker 系列它专门做 query 和 document 的相关性打分比向量相似度更准。代价是它需要额外显存大概 1-2G所以前面模型量化要留够空间。3. 核心模块拆解与实操要点3.1 文档解析与切分别小看这一步知识库的质量直接决定 RAG 的上限。我一开始图省事直接把一堆 txt 丢进去结果检索效果惨不忍睹。后来才发现文档切分chunking是门学问。情感类语料有个特点它往往是段落式的一段话讲一个完整的情绪场景。如果你按固定字数切比如每 500 字一刀很可能把一段完整的建议切成两半检索出来就是残缺的。我的做法是按语义切分优先按段落切如果段落太长再按句子切保证每个 chunk 是一个完整的语义单元。具体参数上我把 chunk size 设在 300-500 字overlap 设在 50 字。为什么要有 overlap因为有些关键信息可能刚好在切分边界上overlap 能保证它至少完整出现在一个 chunk 里。300-500 字这个范围是实测出来的太短了信息不完整太长了检索精度下降因为一个 chunk 里混了太多主题。注意切分的时候一定要保留原文的标题和层级信息。我试过把标题丢掉结果检索出来的内容完全不知道在讲什么。后来我在每个 chunk 前面加上“所属章节XXX”检索准确率立刻上来了。3.2 向量化模型的选择与本地化向量化模型负责把文本转成向量它的质量直接影响检索效果。我对比了几个主流的中文向量模型最终选了 BGE-M3。原因有三个它对中文支持好、支持多粒度短文本和长文本都能处理、而且可以本地部署。本地部署向量模型有个坑它和生成模型抢显存。我的做法是把向量化模型跑在 CPU 上虽然慢一点但向量化是一次性的知识库建好之后就不用反复跑了。查询时的向量化虽然每次都要做但单条 query 的向量化在 CPU 上也就几十毫秒用户感知不到。如果你知识库特别大比如几十万条那还是建议把向量化模型放 GPU 上用批处理的方式跑速度能快十倍以上。批处理大小我一般设 32再大容易爆显存。3.3 BM25 索引的构建细节BM25 是个经典算法但真要用好参数得调。它有两个核心参数k1 和 b。k1 控制词频饱和度b 控制文档长度归一化。默认值 k11.5、b0.75 在大多数场景下够用但情感类语料有个特点短文本多而且关键词重复率高。我把 b 调到了 0.5因为情感语料里长文档和短文档混杂如果 b 太大长文档会被过度惩罚。k1 保持 1.5 没动。另外中文需要先分词我用的是 jieba 分词加了情感领域的自定义词典把“焦虑”“内耗”“emo”这类词加进去保证它们不被切碎。BM25 索引的构建速度很快几万条文档几分钟就建好了。但要注意BM25 索引是存在内存里的如果知识库特别大内存占用会很高。我的知识库大概 2 万条内存占用约 500M可以接受。3.4 重排序模型的部署与调优重排序是检索链路的最后一道关也是最耗资源的一步。BGE-Reranker 有不同大小的版本我选了 base 版参数量约 1 亿显存占用 1.5G 左右。它会对混合检索召回的 top 50 条结果逐条打分然后取 top 5 送给生成模型。为什么是 top 50 进、top 5 出因为混合检索召回的结果里真正相关的可能排在 10-30 名如果只取 top 10 进重排序可能漏掉。而重排序的计算量是 O(n)50 条大概耗时 200ms可以接受。最终取 top 5 是因为生成模型的上下文窗口有限塞太多反而干扰生成。提示重排序模型和生成模型最好分时复用显存。我的做法是重排序跑完立刻释放显存再加载生成模型。Ollama 支持模型热切换但切换有 1-2 秒延迟对实时性要求高的场景可以常驻两个模型前提是显存够。4. 完整实操流程与关键配置4.1 环境准备与依赖安装我的环境是 Ubuntu 22.04Python 3.10。先装 Ollama一条命令搞定curl -fsSL https://ollama.com/install.sh | sh然后拉模型ollama pull qwen2.5:7b-instruct-q4_K_M向量化和重排序模型我用 HuggingFace 的 transformers 加载需要装pip install transformers torch sentence-transformers rank_bm25 jieba这里有个坑torch 的版本要和 CUDA 匹配。我一开始装了 CPU 版的 torch结果向量化慢得想砸电脑。后来换成 CUDA 12.1 对应的版本速度直接起飞。查 CUDA 版本用nvidia-smi然后去 PyTorch 官网找对应命令。4.2 知识库构建的完整脚本知识库构建分四步解析文档、切分、向量化、建索引。我写了个脚本串起来import jieba from rank_bm25 import BM25Okapi from sentence_transformers import SentenceTransformer import numpy as np # 1. 读取文档并切分 def chunk_document(text, chunk_size400, overlap50): paragraphs text.split(\n\n) chunks [] for para in paragraphs: if len(para) chunk_size: chunks.append(para) else: for i in range(0, len(para), chunk_size - overlap): chunks.append(para[i:ichunk_size]) return chunks # 2. 向量化 model SentenceTransformer(BAAI/bge-m3) embeddings model.encode(chunks, batch_size32, normalize_embeddingsTrue) # 3. BM25 索引 tokenized [list(jieba.cut(c)) for c in chunks] bm25 BM25Okapi(tokenized, k11.5, b0.5) # 4. 保存 np.save(embeddings.npy, embeddings) import pickle with open(bm25.pkl, wb) as f: pickle.dump(bm25, f)这个脚本跑 2 万条文档大概 10 分钟主要时间花在向量化上。如果你有 GPU把model.encode的 device 设成 cuda能快 5 倍。4.3 混合检索的实现与参数检索的时候向量检索和 BM25 各跑一遍然后合并。合并策略我用的是RRFReciprocal Rank Fusion它不依赖分数只看排名避免了两种检索分数不可比的问题。def hybrid_search(query, top_k50): # 向量检索 q_emb model.encode([query], normalize_embeddingsTrue) vec_scores np.dot(embeddings, q_emb.T).flatten() vec_ranks np.argsort(-vec_scores)[:top_k] # BM25 检索 q_tokens list(jieba.cut(query)) bm25_scores bm25.get_scores(q_tokens) bm25_ranks np.argsort(-bm25_scores)[:top_k] # RRF 融合 rrf_scores {} for rank, idx in enumerate(vec_ranks): rrf_scores[idx] rrf_scores.get(idx, 0) 1 / (60 rank) for rank, idx in enumerate(bm25_ranks): rrf_scores[idx] rrf_scores.get(idx, 0) 1 / (60 rank) return sorted(rrf_scores.items(), keylambda x: -x[1])[:top_k]那个 60 是 RRF 的平滑常数标准值就是 60不用改。实测下来RRF 融合比简单加权分数效果好因为向量相似度和 BM25 分数的量纲完全不一样加权很难调。4.4 重排序与生成模型的对接重排序用 BGE-Rerankerfrom transformers import AutoModelForSequenceClassification, AutoTokenizer reranker AutoModelForSequenceClassification.from_pretrained(BAAI/bge-reranker-base) reranker_tokenizer AutoTokenizer.from_pretrained(BAAI/bge-reranker-base) def rerank(query, candidates, top_n5): pairs [[query, chunks[idx]] for idx, _ in candidates] inputs reranker_tokenizer(pairs, paddingTrue, truncationTrue, return_tensorspt, max_length512) scores reranker(**inputs).logits.squeeze(-1) ranked sorted(zip(candidates, scores.tolist()), keylambda x: -x[1]) return [idx for (idx, _), _ in ranked[:top_n]]最后把 top 5 的 chunk 拼成上下文塞进 prompt 里调 Ollamaimport requests def generate(query, context_chunks): context \n\n.join(context_chunks) prompt f基于以下知识回答用户问题。如果知识中没有相关信息请如实说明。 知识 {context} 用户问题{query} 回答 resp requests.post(http://localhost:11434/api/generate, json{ model: qwen2.5:7b-instruct-q4_K_M, prompt: prompt, stream: False }) return resp.json()[response]整个链路跑下来从用户提问到返回答案大概 3-5 秒其中检索占 500ms生成占 3-4 秒。生成是瓶颈但 7B 模型这个速度已经可以接受。5. 常见问题与排查技巧实录5.1 检索结果不相关怎么办这是最常见的问题。我遇到过一次用户问“怎么缓解焦虑”检索出来的全是“焦虑症的症状”。排查下来发现两个原因一是知识库里症状描述的内容远多于缓解方法导致 BM25 分数偏高二是向量模型对“缓解”和“症状”的区分度不够。解决办法有三个第一在知识库层面做平衡确保各类内容数量不要差太多第二在 query 前面加指令比如“请检索关于缓解方法的内容”引导向量模型第三调 BM25 的 b 参数让短文档更有优势。我最后是三个一起上效果明显改善。5.2 生成模型胡编乱造怎么破RAG 的一个核心优势就是减少幻觉但如果检索质量差生成模型还是会编。我的经验是prompt 里一定要加约束“如果知识中没有相关信息请如实说明不要编造。”这句话看似简单但能挡掉 80% 的幻觉。另外重排序的 top_n 不要设太大。我试过 top 10结果生成模型被无关信息干扰反而容易跑偏。top 5 是个比较稳的值。如果 top 5 里还有无关的说明检索链路有问题得回去查向量模型和 BM25。5.3 显存不够的降级方案16G 显存听起来不少但同时跑生成、向量化、重排序三个模型还是会紧张。我的降级顺序是先把向量化模型挪到 CPU再把重排序模型换成 tiny 版最后才考虑降低生成模型的量化等级。因为生成模型的质量对最终体验影响最大能不动就不动。如果显存实在不够还有个办法用 Ollama 的 API 做模型热切换。检索阶段加载重排序模型生成阶段切换成生成模型。代价是每次切换有 1-2 秒延迟但显存占用能省一半。5.4 中文分词的坑jieba 默认分词对情感类文本不太友好比如“内耗”会被切成“内”和“耗”“emo”会被当成英文。我的做法是加自定义词典jieba.add_word(内耗) jieba.add_word(emo) jieba.add_word(精神内耗)另外停用词表也要定制。情感类文本里“的”“了”“吗”这些词确实没用但“不”“没”“别”这些否定词绝对不能去掉否则语义完全反了。我一开始用了通用停用词表把“不”去掉了结果“我不开心”和“我很开心”检索结果一样闹了大笑话。5.5 知识库更新的处理情感类知识库需要经常更新但每次全量重建索引太慢。我的做法是增量更新新文档单独向量化追加到 embeddings 数组里BM25 索引重建虽然快但为了保险还是全量重建因为 BM25 的 IDF 是全局统计量增量更新会影响准确性。如果更新特别频繁可以考虑用支持增量索引的向量库比如 Milvus 或 Qdrant。但我实测下来2 万条规模的知识库全量重建也就几分钟没必要上重型武器。问题现象可能原因排查方法解决方案检索结果不相关向量模型区分度不够手动检查 top 10 结果加 query 指令、调 BM25 参数生成内容胡编检索质量差或 prompt 约束弱检查检索结果是否相关加强 prompt 约束、减小 top_n显存不足三模型同时加载nvidia-smi 看占用向量化挪 CPU、重排序换 tiny中文分词错误自定义词典缺失打印分词结果加领域词典、定制停用词更新后检索变差增量更新导致 IDF 偏移对比更新前后结果全量重建 BM25 索引6. 一些实操心得和后续扩展方向这个项目跑通之后我最大的体会是RAG 的效果上限不取决于生成模型而取决于检索质量。很多人花大力气换更大的生成模型结果检索一塌糊涂换了也白换。反过来检索做扎实了7B 模型也能给出很靠谱的回答。另一个心得是情感类场景对“语气”的要求很高。同样的知识用不同的语气说出来用户感受完全不同。我后来在 prompt 里加了语气指令比如“用温和、共情的语气回答”效果提升很明显。这个技巧不涉及技术改动但体验提升巨大。后续我打算往两个方向扩展一是引入KG 知识库热词里提到的“kg知识库”把情感知识做成图谱这样能处理更复杂的推理比如“失恋导致失眠导致工作效率下降”这种链式关系二是做多轮对话的上下文管理目前每次检索都是独立的多轮对话时历史信息没有充分利用。这两个方向都有现成的框架可以参考但需要不少调优工作。如果你也在做类似的项目我的建议是先把检索链路跑通用少量数据验证效果再逐步扩大知识库规模。不要一上来就追求大而全RAG 的调优是个迭代过程小步快跑比一步到位更靠谱。