企业官网建设流程全解析

1. 为什么我要在本地折腾一个情感智能助手

先说结论：我做这个项目的出发点特别朴素——我需要一个能随时聊天、能记住我说过的话、还能感知我情绪状态的对话助手，但我不想把每天的碎碎念和情绪记录上传到任何云端服务。这个需求听起来简单，实际上把 RAG、本地大模型部署、情感识别三件事揉在一起之后，坑比我想象的多得多。

所谓RAG，全称是检索增强生成（Retrieval-Augmented Generation），通俗讲就是给大模型配一个"外挂记忆库"：模型本身的知识是训练时冻结的，但通过 RAG，我们可以在每次提问时先从本地知识库里检索相关内容，再把这些内容作为上下文喂给模型，让它基于你的私有资料回答。而"情感智能助手"则是在这个基础上再加一层：识别用户输入的情绪倾向，并让回复带上相应的情感色彩。

这套东西适合谁？我认为有三类人值得动手：一是对隐私敏感、希望所有对话数据留在本机的用户；二是想系统学习 RAG 工程落地的开发者，因为情感场景比纯问答场景多了不少工程细节；三是想做个人知识管理、日记分析、情绪追踪的普通用户。哪怕你只是想在 Mac 上搭一个属于自己的知识库问答，这篇文章里的流程也能直接复用。

我前后迭代了三版，从最初用现成框架拼装，到后来自己调检索策略和情感分类模块，踩过的坑基本覆盖了本地部署 RAG 的典型问题。下面我把整套思路、选型逻辑、实操步骤和排查经验完整拆开讲。

2. 整体架构设计与技术选型思路

2.1 为什么是"本地部署 + RAG + 情感层"这个组合

很多人第一反应是直接调云端 API，省事。但情感助手这个场景有个特殊性：用户输入的内容往往是私密的情绪表达，日记、吐槽、焦虑记录，这些东西一旦上云，隐私边界就模糊了。本地部署的核心价值不是省钱，而是数据不出本机。

那为什么一定要 RAG？因为通用大模型对你的个人历史一无所知。你上周说过"最近项目压力大"，这周你说"还是老样子"，没有 RAG 的模型根本不知道"老样子"指什么。RAG 让助手具备长期记忆能力，这是情感陪伴类应用的关键。

情感层则是这个项目的差异化所在。普通 RAG 问答只关心"答得对不对"，情感助手还要关心"答得合不合适"。同样一个问题，用户愤怒时和低落时需要的回复语气完全不同。所以我在检索之后、生成之前，插入了一个情感识别环节，用它来调节 prompt 的情感指令。

2.2 核心组件选型与理由

我把整个系统拆成五个模块，每个模块的选型都经过实际对比：

这里重点说下 Ollama 的选择。我试过直接用 llama.cpp，性能确实更可控，但模型格式转换、量化参数、上下文长度配置都要手动搞，对想快速验证的人不友好。Ollama 把这些封装好了，一条命令拉模型，改个 Modelfile 就能调系统提示词，实测下来在 Mac 上很稳。至于为什么不用 vLLM，主要是它更偏向服务端高并发场景，个人本地用属于杀鸡用牛刀。

向量模型选 bge-small-zh 是个权衡。bge-large 效果更好但显存占用高，small 版本在中文语义检索上已经够用，而且它只有约 100MB，加载快。情感识别我没用大模型，而是用了一个轻量中文情感分类模型加关键词规则兜底，原因是情感判断本身不需要太强的推理能力，用大模型反而慢且浪费。

2.3 数据流是怎么走的

整个流程我用文字描述一遍，方便你建立全局观：

用户输入一句话 → 情感识别模块判断情绪标签（正向/中性/负向 + 强度）→ 把用户输入向量化 → 在 Chroma 里检索最相关的历史片段 → 把检索结果 + 情感标签 + 用户输入组装成 prompt → 送给 Ollama 里的模型生成 → 返回带情感色彩的回复 → 把本轮对话写回知识库。

这个链路里有两个容易忽略的点：一是写回知识库这一步，很多人做 RAG 只做检索不做写入，导致助手永远记不住新对话；二是情感标签要参与 prompt 组装，否则情感识别就是白做。这两点后面会详细展开。

3. 环境准备与本地模型部署实操

3.1 硬件与系统前提

先说硬件门槛，避免你白忙活。我实测的配置是：Mac M 系列芯片 16GB 内存，跑 7B 量化模型流畅，14B 量化模型勉强能跑但响应慢。如果是 Windows + 独立显卡，8GB 显存能跑 7B 量化，12GB 以上可以上 14B。纯 CPU 也能跑，但 7B 模型生成速度大概每秒 2-5 个 token，聊天体验会比较煎熬。

内存这块有个经验值：模型参数量 × 量化位数 ÷ 8 大致是显存/内存占用。比如 7B 模型用 4bit 量化，大约需要 3.5GB 左右，加上上下文缓存和向量库，留 8GB 余量比较稳妥。这个估算不精确，但能帮你快速判断机器能不能扛。

3.2 Ollama 安装与模型拉取

Ollama 的安装在各平台都很直接，Mac 和 Windows 下载安装包双击即可，Linux 用官方脚本。安装完验证：

ollama --version

拉取模型时，我建议先拉一个中文能力较好的 7B 量化版本做验证：

ollama pull qwen2.5:7b

拉完之后测试一下：

ollama run qwen2.5:7b

能正常对话就说明运行时没问题。这里有个细节：Ollama 默认的上下文长度可能不够 RAG 用，因为我们要塞检索结果进去。可以通过 Modelfile 调整：

# 创建自定义 Modelfile FROM qwen2.5:7b PARAMETER num_ctx 8192 PARAMETER temperature 0.7

然后ollama create my-assistant -f Modelfile生成自定义模型。num_ctx设 8192 是因为检索结果加上对话历史很容易超过默认的 2048，上下文被截断会导致模型"看不见"检索内容，这是新手最常见的坑之一。

3.3 Python 环境与依赖安装

我习惯用 conda 建独立环境，避免依赖冲突：

conda create -n rag-emotion python=3.10 conda activate rag-emotion pip install chromadb sentence-transformers ollama langchain

版本上有个注意点：sentence-transformers和chromadb对numpy版本比较敏感，如果装完报 numpy 相关的错，锁定numpy<2.0通常能解决。我踩过一次，排查了半小时才发现是 numpy 2.x 的兼容问题。

3.4 向量模型与情感模型的本地加载

向量模型用 sentence-transformers 加载：

from sentence_transformers import SentenceTransformer embed_model = SentenceTransformer('BAAI/bge-small-zh-v1.5')

第一次运行会自动下载模型，之后缓存在本地。情感识别我推荐用一个轻量中文分类模型，或者更简单的方式——用关键词词典加规则。别小看规则，在情感识别这种任务上，精心设计的词典在短文本上准确率并不低，而且零延迟、零依赖。我的做法是两者结合：模型给一个基础判断，规则做修正。

4. RAG 知识库构建的核心细节

4.1 文档切分策略决定检索质量

RAG 效果好不好，七成看切分。我见过太多人把整篇文档直接塞进去，结果检索出来的是一大坨无关内容。切分的核心原则是：每个 chunk 要语义完整且长度适中。

我的经验参数是：中文文本每块 300-500 字，块之间重叠 50-80 字。重叠是为了避免关键信息正好被切在边界上。切分不能只按字数硬切，最好按段落、按语义边界切。比如按句号、换行符先粗切，再合并到目标长度。

def split_text(text, chunk_size=400, overlap=60): paragraphs = text.split('\n') chunks = [] current = "" for para in paragraphs: if len(current) + len(para) <= chunk_size: current += para + '\n' else: if current: chunks.append(current.strip()) current = para + '\n' if current: chunks.append(current.strip()) return chunks

这段代码是简化版，实际用的时候建议加上按标点二次切分的逻辑。为什么要重叠？想象一句话被切成"我今天很"和"难过因为工作"，检索时两半都语义不完整，重叠能让至少一个 chunk 包含完整语义。

4.2 向量化与入库

切分完就向量化入库。Chroma 的用法很直接：

import chromadb client = chromadb.PersistentClient(path="./my_knowledge") collection = client.get_or_create_collection("emotion_diary") def add_documents(chunks, metadatas=None): embeddings = embed_model.encode(chunks).tolist() ids = [f"doc_{i}" for i in range(len(chunks))] collection.add( embeddings=embeddings, documents=chunks, ids=ids, metadatas=metadatas or [{} for _ in chunks] )

PersistentClient是关键，它会把数据存到磁盘，重启不丢。用内存版的话每次重启知识库就空了，这是新手常犯的错。metadata 我建议至少存两个字段：时间戳和来源类型（是用户对话还是导入文档），后面做时间加权检索时会用到。

4.3 检索策略：不只是向量相似度

纯向量检索有个问题：它只看语义相似，不看时间。但情感助手场景里，最近的对话往往更重要。你三天前说心情不好，和三个月前说心情不好，权重应该不一样。

我的做法是混合打分：最终得分 = 向量相似度 × 0.7 + 时间衰减因子 × 0.3。时间衰减用指数衰减，半衰期设 7 天左右：

import math from datetime import datetime def time_decay(timestamp, half_life_days=7): days = (datetime.now() - timestamp).days return math.pow(0.5, days / half_life_days)

检索时先取 top 20 候选，再用混合得分重排取 top 5。实测下来，这个改动让助手对"最近"相关问题的回答质量提升明显。另外，检索数量别贪多，塞太多上下文反而会稀释关键信息，还挤占上下文窗口。5 条左右是个甜点值。

4.4 知识库的写入闭环

前面提过，只检索不写入的 RAG 是"失忆"的。每轮对话结束后，要把用户输入和助手回复一起写入知识库。但这里有个坑：如果每句话都写，知识库会迅速膨胀且充满噪音。

我的策略是选择性写入：只写入包含情绪信息、事实信息或明确偏好的句子。用一个简单的过滤规则，比如句子长度超过 15 字、包含情感词或第一人称陈述。这样知识库保持精炼，检索质量也更高。写入时打上时间戳和类型标签，方便后续加权。

5. 情感识别模块的实现与调优

5.1 情感标签体系怎么设计

情感识别不是简单分正负。我设计的是一个二维体系：极性（正向/中性/负向）加强度（1-5）。为什么加强度？因为"有点烦"和"非常崩溃"需要的回复完全不同。前者可以轻松调侃，后者必须认真安抚。

标签体系设计要克制，别搞太细。我一开始设计了十几种情绪（焦虑、愤怒、悲伤、喜悦……），结果分类器准确率惨不忍睹，而且下游 prompt 也没法针对每种情绪写不同指令。最后收敛到三极性加五级强度，够用且稳定。

5.2 规则与模型结合的实现

纯模型方案在短文本上容易翻车，比如"呵呵"这种词，模型可能判成中性，实际是负向。所以我用规则做兜底和修正：

negative_words = ["烦", "累", "崩溃", "难过", "焦虑", "压力", "不想"] positive_words = ["开心", "顺利", "喜欢", "棒", "谢谢", "舒服"] def rule_based_emotion(text): neg = sum(1 for w in negative_words if w in text) pos = sum(1 for w in positive_words if w in text) if neg > pos: return "negative", min(5, neg + 2) elif pos > neg: return "positive", min(5, pos + 2) return "neutral", 1

模型判断和规则判断冲突时，我优先信规则，因为规则是我针对场景调过的。这个"模型 + 规则"的组合在实测中比纯模型稳定不少，尤其是处理网络用语和口语化表达时。

5.3 情感标签如何影响生成

这是整个项目最容易被做废的一环。识别出情感但不影响生成，等于没做。我的做法是把情感标签转成 prompt 里的情感指令：

emotion_prompts = { ("negative", 4): "用户情绪低落且强烈，请用温和、共情、不评判的语气回应，先接纳情绪再给建议。", ("negative", 2): "用户略有负面情绪，可以轻松回应，适当给予鼓励。", ("positive", 3): "用户心情不错，可以积极互动，分享喜悦。", ("neutral", 1): "用户情绪平稳，正常专业回应即可。" }

然后把这个指令拼进系统提示词。实测下来，加了情感指令之后，回复的"人味"明显提升。这里有个细节：情感指令要放在系统提示词靠前的位置，因为模型对开头的指令遵循度更高。

6. 常见问题与排查技巧实录

6.1 检索不到相关内容怎么办

这是最高频的问题。排查顺序我总结成一张表：

我踩过最坑的一次是向量模型用了英文的，中文检索效果极差，换 bge-small-zh 之后立刻正常。所以向量模型一定要选中文优化的。

6.2 模型回答忽略检索内容

这个问题的典型表现是：检索明明返回了正确内容，模型却按自己的知识瞎答。原因通常是上下文太长被截断，或者 prompt 里检索内容的位置不对。

解决思路：一是确认num_ctx够大；二是把检索内容放在 prompt 的显眼位置，并用明确的分隔符标记，比如：

以下是相关背景信息： --- {retrieved_content} --- 请基于以上信息回答用户问题。

明确告诉模型"基于以上信息"，比把内容随便塞进去效果好很多。

6.3 响应速度慢的优化

本地部署慢是常态，但可以优化。我的几个手段：一是用更小的量化模型，7B 的 q4 量化比 q8 快一倍不止；二是减少检索条数，从 10 条降到 5 条；三是限制生成的最大 token 数，情感助手不需要长篇大论，num_predict设 256 通常够；四是向量模型常驻内存，别每次重新加载。

6.4 情感判断不准的修正

情感识别出错时，先看是不是反讽或网络用语。这类文本规则和模型都容易翻车。我的处理方式是维护一个"特殊表达词典"，把"呵呵""fine""随便吧"这类词手动标注极性。这个词典是长期积累的，用久了准确率会越来越高。

7. 我踩过的坑和几条实在经验

第一个坑是知识库无限膨胀。我一开始每句话都写回，两周后知识库上万条，检索质量断崖式下降，因为噪音太多。后来加了写入过滤，只留有价值的内容，检索立刻清爽了。所以记住：RAG 的知识库不是越大越好，是越精越好。

第二个坑是上下文窗口溢出。检索 10 条加对话历史，轻松超过 4096，模型直接"失忆"。解决办法是动态控制检索条数，根据当前对话历史长度调整，历史长了就少检索几条。

第三个坑是情感指令被模型忽略。我最初把情感指令放在 prompt 末尾，效果很差。后来移到系统提示词开头，遵循度明显提升。模型对指令位置是有偏好的，这个细节文档里不会写，只能自己试。

最后一个经验：先跑通最小闭环再优化。我第一版就想把情感、检索、记忆全做完美，结果卡了两周。后来改成先做一个能检索能回答的简单版本，跑通之后再逐个加情感层、时间加权、写入过滤，效率高多了。RAG 这种系统，模块之间的耦合问题只有跑起来才暴露，纸上设计再完美也没用。

如果你也想动手，我的建议是从一个最小的本地问答开始，先让 Ollama 和 Chroma 跑起来，能回答一个关于你自己文档的问题，然后再往上叠情感和记忆。这个顺序能让你每一步都有正反馈，不至于中途放弃。