给小企业搭一套本地 AI 知识库客服：用 Ollama + 向量检索把老员工经验变成可查答案

小企业最贵的资产往往不在账上：老师傅知道某台设备哪个参数不能动，客服主管记得某个大客户的对账口径。这些经验散在微信群、Excel 和某个人的脑子里，人一走知识就断层。

这篇文章记录一套真实落地的方案：不上云、不按 token 付费，用一台闲置办公主机跑本地大模型加向量检索，让"问一句就能查到答案"变成现实。半天工作量，硬件成本为零。

为什么不直接用在线大模型

真正推到公司层面用，会遇到三个硬问题。数据边界：报价单、客户联系人、供应商结算价贴出去就不再私有。幻觉：在线模型没有你公司的资料，问"售后质保多久"它会编一个听起来合理的答案，比不回答更危险。成本不可控：每天几百次查询，按调用计费的账单会让老板很快叫停。

本地方案能解决前两个——数据不出内网，且模型只允许基于检索到的公司文档作答，检索不到就明确说没有。

整体架构：三个部件

方案只有三层，理解清楚再动手会顺很多。

文档层：把散落资料收拢成纯文本，切成小块。检索层：把每个块转成向量存进库，提问时找出最相关的几块。生成层：把"问题 + 检索到的原文"一起交给本地模型，让它只根据原文组织答案。

这就是 RAG（检索增强生成）。关键认知是：效果的七成取决于检索层，而不是模型多大。很多人一上手就纠结用 7B 还是 14B，结果答不准的真实原因是文档切分太粗、检索召回不到。

第一步：把资料收拢成可切分的文本

这一步最枯燥，但直接决定成败。实际操作的顺序是：

在 NAS 或本机建一个 kb/ 目录，按业务分子目录：kb/售后/、kb/报价/、kb/设备/。
Word、PDF 统一转成 Markdown 或 txt。PDF 是扫描件的话必须先 OCR，否则抽出来是空白。
微信群里的有效问答，人工整理成"问题—答案"成对的条目，一条一段。这类语料对客服场景的命中率最高。
每个文件开头补三行元信息：所属业务、适用时间、责任人。检索时这些词会成为有效的匹配线索。

一个容易忽略的细节：把过期文档移到 kb/_archive/ 并排除索引。否则模型会拿三年前作废的价格表回答今天的询价，这种错误比查不到更麻烦。

第二步：跑起本地模型

Ollama 是目前最省事的本地模型运行方式，Windows、Linux、macOS 都有安装包。装完拉两个模型：

# 生成用的对话模型，中文效果稳、8G 内存也能跑
ollama pull qwen2.5:7b-instruct
# 向量化用的嵌入模型，体积小、速度快
ollama pull bge-m3

验证服务在跑：

curl http://127.0.0.1:11434/api/generate -d '{
  "model": "qwen2.5:7b-instruct",
  "prompt": "用一句话说明什么是质保期",
  "stream": false
}'

硬件参考：i5 加 16G 内存的办公机跑 7B 模型，回答一段大约 5 到 12 秒，员工能接受，有独显会快数倍。内存只有 8G 就换 3B 模型。

第三步：切分、向量化与检索

切分参数最值得花时间调。经验值：每块 300 到 500 字，块间留 50 到 80 字重叠。太大会夹杂无关段落干扰模型；太小则一句话被切断，语义不完整。

向量库用 Chroma 就够了，几千到几万个块的规模，单文件存储、零运维。核心代码不到三十行：

import chromadb, requests

def embed(text):
    r = requests.post("http://127.0.0.1:11434/api/embeddings",
                      json={"model": "bge-m3", "prompt": text})
    return r.json()["embedding"]

client = chromadb.PersistentClient(path="./chroma")
col = client.get_or_create_collection("kb")

# 入库：chunks 为切好的文本块列表
for i, c in enumerate(chunks):
    col.add(ids=[f"c{i}"], embeddings=[embed(c)],
            documents=[c], metadatas=[{"src": c_src[i]}])

# 检索
hits = col.query(query_embeddings=[embed("售后质保多久")], n_results=4)

提示词必须写死约束，这是防幻觉的关键：

你是公司内部知识助手。只能根据下面提供的资料回答。
资料中没有的信息，直接回答"资料里没有查到，请联系对应负责人"，不要推测。
回答末尾列出你引用的资料来源文件名。
【资料】
{检索到的4个文本块}
【问题】
{用户问题}

第四步：给员工一个能用的入口

技术再好，入口难用就没人用。内网网页最快，Streamlit 二十行代码就能出一个输入框加回答区；企业微信机器人体验最好，员工在群里 @机器人提问不用切换工具；车间工位就把网页固定到桌面，比教人装软件现实。

实测效果与调参经验

在一家三十来人的机电维修公司跑了两个月：答对率从六成提到八成五以上，提升几乎全来自文档整理和切分调优，模型一次都没换。检索条数从 3 调到 4 有明显改善，调到 8 反而变差，无关内容开始干扰生成。要求模型标注来源文件名最受欢迎，员工看到出处才敢采用答案。使用最多的不是复杂咨询，而是"某型号用什么规格密封圈"这类查参数的问题，原来要翻纸质手册五分钟。

容易踩的坑

索引不更新：文档改了没重建索引，答的还是旧内容。加一个每晚定时重建的计划任务，成本极低。
表格类资料直接入库：价格表、参数表切分后语义碎裂。正确做法是先把表格转成"某型号的某参数是某值"的自然语句再入库。
一个大集合装所有业务：售后和报价混在一起会互相干扰。按业务分集合，提问时先选范围。
没有兜底路径：一定要在回答里带上"没查到请联系谁"，否则员工卡住就会放弃使用。
拿它当决策依据：涉及金额、合同、安全的结论必须人工复核，知识库只做检索和汇总。

小结

小企业做智能化，最有性价比的切口不是买系统，而是把已有经验变成可检索的资产。一台旧机器、半天时间、Ollama 加 Chroma，就能让新人少问十遍、老人少被打断。工作量主要在整理文档而非写代码，这也意味着任何有耐心的人都能推动，不必等预算和外包。