1. 为什么要在本地折腾一个感情智能助手先把话说在前头这个项目的核心不是做一个能陪你聊天的玩具而是搭一套跑在自己机器上的 RAG 系统让它能理解、检索并回应带有情绪色彩的内容。你可以把它理解成一个懂情绪的知识库问答机器人——你喂给它一批日记、聊天记录、影评、书摘或者客服对话它不只是按关键词找答案而是能感知到这段话是开心的还是丧的再结合检索结果给出有温度的回应。为什么非要本地部署三个现实原因。第一是隐私。感情类文本是最私密的数据日记、聊天记录、心理倾诉这些东西丢到云端 API 上跑心里总归不踏实。本地跑数据不出机器这是底线。第二是成本可控。感情助手这种场景往往是长期、高频、小批量的交互按 token 计费的云服务用久了账单很难看本地部署一次到位后续只有电费。第三是可定制。情感识别这件事通用大模型的表现其实一般你得自己接情感分类模型、自己调检索策略云端 API 给你的自由度很有限。那 RAG 在这里扮演什么角色很多人以为 RAG 就是给大模型外挂一个知识库这话对但太粗。在感情助手这个场景里RAG 要解决的是**让模型记住你的历史、理解你的语境、并且检索出情绪相关的内容。普通 RAG 只做语义相似度检索你问我最近为什么总是不开心它可能给你捞出一堆提到不开心这个词的段落但真正有用的可能是三个月前你写的一段工作压力大、睡不好的记录——语义上不直接相关情绪上却高度一致。这就是为什么这个项目必须上混合检索 重排序**光靠向量相似度是不够的。这篇文章适合谁看如果你已经玩过 Ollama、跑过一两个 RAG demo但发现检索出来的东西总差点意思或者你想做一个真正能用的情感类应用而不是玩具那这篇就是写给你的。我会把整个链路的选型逻辑、踩过的坑、参数怎么调全部摊开讲。全程本地全程可复现。2. 本地部署的硬件账与模型选型别一上来就上最大的2.1 先算清楚你的机器能扛什么本地部署第一件事不是装软件是算账。大模型的显存占用有个粗略公式FP16 精度下参数量 × 2 字节 显存需求。一个 7B 模型 FP16 要 14GB 显存量化到 4bitQ4大约 4-5GBQ8 大约 7-8GB。你要是只有一张 8GB 显存的消费级卡老老实实跑 7B 的 Q4 量化版别想着上 32B。内存RAM同样关键。模型加载时如果显存不够会走 CPU 卸载offload这时候系统内存就是瓶颈。经验值是模型文件大小 × 1.5 倍作为最低内存要求。一个 4GB 的 Q4 模型至少留 6-8GB 空闲内存给它。存储方面SSD 是刚需。模型加载动辄几十秒机械硬盘会让你怀疑人生。另外向量库和原始文档也要占空间预留 50GB 比较稳妥。硬件档位显存可跑模型规模适用场景入门6-8GB7B Q4单人使用、轻量问答主流12-16GB7B Q8 / 14B Q4流畅交互、中等知识库进阶24GB14B Q8 / 32B Q4多用户、复杂推理纯 CPU无独显3B Q4应急、低频使用2.2 生成模型和嵌入模型要分开选这是新手最容易混的一点。RAG 系统里有两个模型角色生成模型负责组织语言回答和嵌入模型负责把文本转成向量。它们的要求完全不同。生成模型选型我实测下来在感情助手场景里7B 到 14B 的中文能力模型性价比最高。太大的模型回答会过于端着反而不像在跟你聊天太小的模型又容易答非所问。中文语料训练充分的模型在情感表达上明显更自然。嵌入模型则是另一套逻辑。它不需要聪明只需要向量质量高、中文语义区分度好。这里有个坑很多人直接用生成模型自带的嵌入效果往往不如专门的嵌入模型。专门的嵌入模型参数量小几百 MB但检索准确率高出一截。选嵌入模型时重点看两个指标中文语义相似度任务的表现和向量维度维度太高检索慢太低区分度不够768 到 1024 维是比较舒服的区间。2.3 情感识别模型这个项目区别于普通 RAG 的关键普通 RAG 到嵌入模型就结束了但感情助手必须多一个环节——情感标注。我的做法是在文档入库阶段对每个文本块跑一遍情感分类把情绪标签和情绪强度作为元数据存进向量库。情感分类模型不需要大一个几百 MB 的轻量分类模型足够关键是标签体系要设计好。我用的是一套五维标签正向开心、满足、负向难过、焦虑、中性、混合、强度0-1 连续值。这样检索时就能做情绪过滤——比如用户当前情绪是负向就优先召回历史上负向情绪相关的记录形成情感共鸣。提示情感分类模型和生成模型最好用不同的进程加载避免显存争抢。如果显存紧张情感分类可以放 CPU 跑它推理快、占用小。3. 混合检索与重排序RAG 效果的分水岭就在这里3.1 纯向量检索为什么在感情场景里会翻车先说结论纯向量检索在情感类文本上召回率会明显下降。原因有三。第一情感表达高度依赖具体词汇和语气词。你写今天真的绝了向量模型可能把它和今天真棒归为一类但绝了在中文里既可能是极度赞美也可能是极度无语向量空间里这两者距离很近区分不开。第二长文本的情感会被稀释。一段 500 字的日记前面 400 字在讲琐事最后 100 字才流露情绪整段嵌入后情感信号被平均掉了。第三否定和转折。向量模型对我不难过和我难过的区分能力有限这在情感场景里是致命的。所以必须引入关键词检索BM25 这类作为补充。关键词检索对精确词汇、否定词、语气词敏感正好补上向量的短板。3.2 混合检索的融合策略RRF 还是加权混合检索的核心问题是向量检索返回一批结果关键词检索返回一批结果怎么合并主流有两种做法。一种是加权求和给两路结果各分配一个权重按分数排序。另一种是RRFReciprocal Rank Fusion倒数排名融合不看具体分数只看排名把两路排名做倒数加权。我强烈推荐 RRF原因是两路检索的分数根本不可比。向量相似度是余弦距离0-1BM25 是任意正数你没法直接加权。RRF 绕开了这个问题公式很简单RRF_score(d) Σ 1 / (k rank_i(d))其中 k 是平滑常数一般取 60rank_i(d) 是文档 d 在第 i 路检索里的排名。这个方法的妙处在于一个文档只要在任意一路里排名靠前融合后就会靠前天然实现了取长补短。实际调参时k 值影响很大。k 小比如 10排名靠前的结果权重被放大适合我要最相关的几条k 大比如 100各路结果更平均适合我要覆盖面广。感情助手场景我一般用 k60兼顾两者。3.3 重排序把差不多相关变成真的相关混合检索出来的 Top-K比如 20 条其实还是粗排。真正决定最终质量的是重排序Rerank。重排序模型Cross-Encoder 架构和嵌入模型Bi-Encoder的区别在于嵌入模型是query 和 doc 分别编码再算相似度快但精度有限重排序模型是query 和 doc 拼在一起过一遍模型慢但精度高得多。所以标准做法是检索阶段用快的向量BM25捞 20-50 条重排序阶段用慢的精选 3-5 条。在感情场景里重排序还有一个特殊用法把情绪匹配度作为重排序的一个特征。我试过在重排序打分时把query 情绪标签和doc 情绪标签的一致性作为一个加权项效果提升很明显。比如用户问最近好累重排序会优先把那些情绪标签为疲惫/负向的文档排上来而不是单纯语义相似的文档。阶段方法处理量关注点粗排向量 BM25全库召回率宁滥勿缺融合RRF两路 Top-K排名合并精排Cross-Encoder 重排序Top 20-50精度情绪一致性最终取 Top 3-5-喂给生成模型3.4 分块策略情感文本不能按固定长度切通用 RAG 教程都教你按 512 token 固定切块这在感情场景里是灾难。一段完整的情绪表达被从中间切断前半段进了块 A后半段进了块 B两个块的情感都不完整。我的做法是语义分块 情绪边界保护。具体来说先按段落切如果段落太长再按句子切但绝不在一个情绪表达中间切。判断依据是情感分类模型给出的情绪强度曲线——如果相邻句子的情绪强度突变那里就是天然的分块边界。另外块之间要留重叠overlap一般 10%-20%。感情文本的上下文依赖强重叠能保证情绪语境不丢失。4. 从零搭起完整链路的落地步骤4.1 环境准备与依赖安装先把地基打好。我习惯用 Python 虚拟环境隔离避免依赖冲突。python -m venv rag_env source rag_env/bin/activate # Windows 用 rag_env\Scripts\activate核心依赖分几类模型推理框架、向量库、检索库、Web 框架。向量库我推荐轻量级的本地方案单机场景没必要上分布式。检索库用支持 BM25 的即可。Web 框架选轻量的方便快速起服务。pip install fastapi uvicorn pip install sentence-transformers pip install rank-bm25 pip install chromadb pip install transformers torch注意torch 的安装要匹配你的 CUDA 版本装错了会静默回退到 CPU推理速度差十倍。装完务必跑一句torch.cuda.is_available()验证。4.2 文档入库情感标注是第一步入库流程我拆成四步读取 → 分块 → 情感标注 → 向量化存储。读取阶段要处理多种格式txt、md、pdf、甚至聊天记录导出文件。这里有个经验聊天记录这类结构化数据要保留说话人和时间戳因为情感分析里谁说的什么时候说的很重要。分块按上一节讲的语义分块策略走。情感标注对每个块跑分类模型得到情绪标签和强度。向量化用嵌入模型把文本转成向量。最后一起存进向量库元数据里带上情绪标签、强度、时间戳、来源。# 伪代码示意展示入库的数据结构 chunk_data { text: 今天加班到十点感觉整个人被掏空了, embedding: embed_model.encode(text), metadata: { emotion_label: 负向, emotion_intensity: 0.78, timestamp: 2024-03-15, source: diary } }4.3 检索链路三路并行的实现检索时query 进来先做情感分析判断用户当前情绪然后三路并行向量检索query 嵌入后查向量库取 Top 20关键词检索BM25 查取 Top 20情绪检索按情绪标签过滤取情绪匹配度最高的 Top 10三路结果用 RRF 融合得到候选集再送重排序模型精排最后取 Top 5 喂给生成模型。这里有个细节情绪检索这一路是可选的。如果用户 query 本身没有明显情绪比如帮我找一下去年三月写的关于旅行的记录就跳过情绪路避免引入噪声。判断依据是 query 的情感强度阈值低于阈值就不启用。4.4 生成阶段Prompt 怎么设计才有温度检索出来的 5 条文档怎么组织成 prompt 喂给生成模型直接决定回答质量。我的 prompt 结构是这样的系统角色设定 检索到的上下文带情绪标注 用户当前情绪状态 用户问题 回答要求。关键在回答要求这一段。普通 RAG 只要求基于上下文回答但感情助手要额外要求先共情再回应最后才给建议。而且要根据用户当前情绪调整语气——用户负向时语气要温和、不评判用户正向时可以更活泼。提示prompt 里明确告诉模型如果检索到的内容与问题无关不要强行编造能显著降低幻觉。感情场景里编造记忆是很糟糕的体验。4.5 服务化把链路包成一个 API最后用 FastAPI 把整个链路包起来暴露两个接口/ingest入库和/chat问答。入库接口接收文档异步处理问答接口接收 query返回回答和引用的原文片段。from fastapi import FastAPI app FastAPI() app.post(/chat) async def chat(query: str): # 1. 情感分析 # 2. 三路检索 # 3. RRF 融合 # 4. 重排序 # 5. 生成 return {answer: answer, sources: sources}服务起来后前端随便接个聊天界面就能用。整个链路全本地数据不出机器。5. 实测中那些文档不会告诉你的坑5.1 情感分类模型的标签漂移我踩过最深的坑是情感分类模型的标签漂移。同一个模型今天判还行是中性明天判成负向。原因是模型对边界样本的判断不稳定尤其是中文里还行凑合一般这类模糊表达。解决办法是固定阈值 人工校准。给每个标签设一个置信度阈值低于阈值的归为中性/不确定不要强行分类。另外定期抽一批样本人工核对发现漂移就调整阈值。这个工作很枯燥但不做的话检索质量会慢慢劣化。5.2 重排序模型拖慢响应重排序精度高但慢。Cross-Encoder 要对每个 (query, doc) 对跑一次前向20 条候选就是 20 次推理。如果模型大一点单次响应能到好几秒。优化思路有三条一是减少候选数粗排 Top 20 就够别贪多二是批处理把 20 个对打包成一个 batch 一次推理比循环快得多三是模型量化重排序模型量化到 INT8 后速度提升明显精度损失可接受。我实测下来批处理 量化能把重排序耗时从 3 秒压到 500 毫秒以内。5.3 向量库的冷启动问题新库刚建好时检索效果往往很差。原因是向量空间还没被充分填充少量文档之间的相似度区分度低。这不是 bug是数据量的问题。我的经验是知识库至少要有几百个块检索才稳定。如果数据太少可以适当降低相似度阈值或者干脆退化成关键词检索为主。别指望几十条记录就能跑出好效果。5.4 情绪检索的回音壁效应情绪检索有个隐蔽的坑回音壁。如果用户长期处于负向情绪系统一直召回负向内容会强化这种情绪形成负反馈循环。这在心理健康类应用里是危险的。我的处理方式是引入情绪多样性。检索时除了召回情绪匹配的内容强制保留 1-2 条情绪相反或中性的内容让回答有出口。比如用户很丧除了共情也召回一条他过去开心时的记录轻轻提一句你之前提到过……。这个设计让助手的回应更有建设性。5.5 中文分词的细节BM25 依赖分词中文分词质量直接影响关键词检索。通用分词器对网络用语、情感词汇的处理往往不好。我的做法是自定义词典 情感词表把常见的情绪表达、网络用语加进去。另外保留标点符号很重要和在情感表达里信息量很大别在预处理时把它们洗掉。6. 还能怎么往下扩展这套链路跑通之后扩展方向其实很多。我目前在做的是引入知识图谱——把人物、事件、情绪之间的关系结构化这样检索时能做多跳推理。比如上次让我开心的那件事纯向量检索很难定位但有了图谱就能顺着开心 → 事件 → 时间这条路径找。另一个方向是情绪趋势分析。把时间维度加进检索不只回答你问的这件事还能回答你最近的情绪走势如何。这需要把情绪标签按时间聚合做成时序数据再让生成模型去解读。还有一个实用的扩展是多模态。感情记录里经常有图片如果能把图片也做嵌入用多模态模型存进同一个向量库检索时图文一起召回体验会更完整。不过这块对硬件要求高量力而行。最后提醒一句本地部署 RAG 是个持续调优的活不是一次搭好就完事。检索参数、prompt、分块策略都要根据实际使用反馈不断调整。我自己的库跑了小半年前后改了十几版检索策略才到比较满意的状态。别指望一蹴而就把它当成一个会成长的项目来做。