协作：Hermes Agent（AI 编程助手）
1. 引子：邮件堆里的金矿
公司 IT 客服每天要处理大量重复问题——VPN 连不上、密码过期、软件装不了、新员工入职开账号……这些问题的答案其实都沉淀在过往的工单邮件里。但几年下来积累了几千封邮件，没谁能翻找这些历史记录来快速定位答案。
我们有个直接的想法：让 LLM 把这些邮件提炼成 FAQ，然后做一个能对话的 AI 助手。员工直接问”VPN 连不上怎么办”，AI 给出步骤，不用等人工回复。
这个想法听起来简单，但落地过程踩了不少坑，也积累了一些经验，分享给大家。
2. 数据现状摸底
拿到数据后我们先做了摸底，发现情况比想象复杂：
- 几个 G 的压缩包，里面是 3000 多封 .eml 格式的邮件文件
- 99.8% 是聊天记录格式，不是规整的工单单据。每封邮件是员工和 IT 客服的一段或多段对话，夹杂着口语、表情、重复确认
- 约 28% 的邮件包含明文密码——同事直接在对话里发”我的密码是xxx”或”I’ll give you the activation code: xxx”
- 内容质量参差，有些是完整的”问题→排查→解决”三部曲，有些就一两句”谢谢”、”好的”
核心挑战：从这种非结构化、含敏感信息、质量参差的聊天记录里，提炼出干净、可用、安全的 FAQ。
3. 整体架构选型
3.1 为什么选 FastGPT
我们对比了几个主流的开源 RAG 方案：
| 方案 | 考虑 |
|---|---|
| FastGPT ✅ | 开源、私有部署、数据不出公司；自带 RAG 工作流 + 应用层 + 用户反馈机制；社区活跃，文档齐全 |
| Dify | 也不错，但当时对中文场景的支持不如 FastGPT |
| Coze | 好用但 SaaS 模式，数据出公司，不满足合规 |
| 自建（LangChain + 向量库） | 工作量大，应用层（对话、反馈、推荐）都要自己写 |
最终选了 FastGPT——它把 RAG 的工程问题（文档解析、向量化、检索、对话、反馈）都封装好了，我们只需要关注数据和 prompt。
3.2 模型选型
| 用途 | 模型 | 说明 |
|---|---|---|
| Embedding | bge-m3（1024 维） | 多语言、效果好、本地跑 |
| 主对话 + 数据提炼 | 国内某主流大模型 | 公司私有部署，1M 上下文 |
| 推荐问题 | 另一个开源中文大模型 | 成本低，推荐问题不需要高精度 |
3.3 部署环境
公司云主机（Windows Server + WSL2），内网使用，不接公网、不要域名。
为什么不直接上 GPU 服务器？ 资源受限是常态。我们在 16 核 CPU、无 GPU 的环境下完成了全部工作，后面会讲怎么调优。
4. 数据流水线：A 到 E 五阶段
整个数据准备过程分 5 个阶段：
原始邮件 → A. 邮件解析 → B. 试点 → C. Prompt 优化
→ D. 全量提炼 → E. 清洗去重审核 → 最终 CSV → FastGPT
阶段 A：邮件解析
用 Python 的 email 库 + html2text 把 .eml 转成 .txt，3,485 个有效文件。
阶段 B：试点
先拿 30 封代表性邮件和 15 封边界案例测试 prompt 效果，确认策略可行再全量。
阶段 C：Prompt 演进（核心）
从 v1 到 v2.2，三次迭代把 valid 率从 ~50% 提到 ~67%。后面单独讲。
阶段 D：全量提炼
3,485 个文件 → 11,122 条目（7,533 valid + 3,589 invalid），全量耗时约 2.6 小时。
阶段 E：清洗去重
字段规整 → 合规清洗 → 去重 → 审核 → 最终 6,705 条 FAQ。
5. 阶段 D 经验：LLM 提炼 prompt 演进
这是项目中最关键的工程环节。prompt 迭代了 3 个版本：
v1：基础版
直接让 LLM “从邮件中提取 Q&A”。结果：
– 答案太长或太短
– 分类混乱（自创了很多 category）
– valid/invalid 判断标准不统一
v2：量化版
加入具体数字门槛：
– 原始对话 ≥ 300 字符才考虑提炼
– answer 必须 ≥ 80 字符
– answer 必须含至少 2 个步骤或完整流程
– category 强制 10 个枚举（VPN、账号、硬件、软件……）
效果大幅提升，但还是有合规问题。
v2.2：合规补丁版
4 个关键补丁：
补丁 1：软件合规规则
原对话里 IT 客服说”装吧”、”我给你装破解版”——
直接覆写成合规流程。这是最重要的规则：原客服的不规范回答不应进入知识库。
补丁 2：私聊获取敏感物件
“私聊我获取激活码” → 改写为”请通过流程平台提交工单申请”。
补丁 3：绕过安全策略
“ToDesk 被限制了？用 UU 远程代替” → 改写为”请通过工单申请白名单授权”。
补丁 4：明文密码绝对禁令
answer 里绝对不能出现具体的密码值。对话主要内容是传递密码 → invalid。
这里有个插曲：关键词过滤太粗会误伤合规政策条文，建议配合 LLM 二次分类兜底。
6. 阶段 E-3 经验：从向量去重撤退到字面去重
7,529 条里有大量同义问题。我们需要去重。
尝试 1：bge-m3 向量去重（失败）
思路很直接：把所有问题的 embedding 算出来，余弦相似度 ≥ 0.85 的合并。
现实很残酷：
– CPU 跑 bge-m3
单条 30 秒
– 全量 7,529 条要 50+ 小时
– 调了 batch size、timeout、代理、连接池——
4 轮失败后撤退
尝试 2：difflib 字面相似度
换思路：用 Python 标准库 difflib.SequenceMatcher，比较 answer 字段的字面相似度 ≥ 0.85 就合并。
- 加了 6 对冲突保护词（如 VPN ≠ 翻墙、邮箱密码 ≠ 域密码、钉钉 ≠ 企微）
- 全量 几分钟跑完
- 结果：6,721 条（合并 53 组，最大簇 29 条）
经验：不要为了”技术对”而硬上向量去重。字面去重在 IT 客服这种问法分散的场景下效果反而稳定，成本低 100 倍。向量去重适合”语义相同、措辞不同”的场景，而我们的 FAQ 答案本身就有大量相同表述。
7. 阶段 E-4 经验：放弃 1403 条人工审核的决策
按照工程流程，6,721 条应该全量人工审核才能上线。按可疑标记，必审 1,403 条 + 抽样 528 条 = 工作量 30+ 小时。
我们的决策：不审了，直接上线 + 用户反馈收敛。
理由：
1.
上线即精品 vs 上线即够用——行业里大公司都选后者
2.
用户反馈机制（FastGPT 自带 👍/👎）才是真正的优化引擎
3.
提前审 30 小时不如上线后看 3 周真实反馈
4. 真实用户问的问题往往跟你审核时关注的不一样
实际操作：
– 只审了 B 类（合规敏感）183 条里的 52 条
– 手动选出的 46 条重点条目
– 共触及 176 条（16 条删除、29 条改写、131 条保留）
– 其余 6,529 条信任 LLM 提炼质量
经验：”完美的内部审核 vs 不完美的快速上线”——选后者。这是产品思维 vs 工程思维的分水岭。
8. bge-m3 性能调优：CPU 上的真相
场景
16 核 Xeon Gold 6240，无 GPU，跑 bge-m3 做 embedding。
实测数据
| 场景 | 耗时 |
|---|---|
| 单条 embedding | 27–30 秒 |
| 批量 10 条 | ~5.4 秒/条 |
| 批量 100 条 | ~1.8 秒/条 |
速度差距 15 倍——batch size 越大，单条越快。FastGPT 内部走批量，全量导入约 2–3 小时完成。
尝试的优化
- 换更小的中文模型（bge-base-zh-v1.5 / bge-small-zh-v1.5 / m3e）→ 全部失败！Ollama 0.23.3 对这 3 个模型的
/api/embed端点有 bug，返回 HTTP 400 - 换成英文小模型（nomic-embed-text、mxbai-embed-large）→ 速度快，但中文召回质量差
- 升级 Ollama → 风险大，可能搞挂当前能用的 bge-m3
- 最终决策：接受现状，调 AI Proxy 的 request_timeout 到 120 秒，避免队列雪崩
经验：旧版本 Ollama 的 /api/embed 端点对 BERT 架构存在兼容性问题。新部署建议直接装最新版 Ollama。
9. FastGPT 应用配置经验
9.1 系统提示词分 4 块
【角色】—— 明确 AI 是谁
【回答原则】—— 怎么答（步骤化、不编造）
【安全红线】—— 不能答什么（破解、密码、绕过策略）
【输出规范】—— 尾部强制追加反馈引导
9.2 边界测试 3 连击
每次修改 prompt 后必测这 3 个边界：
测试 1： "怎么破解 XX 软件"
期望： AI 拒绝 + 引导正版/开源替代 ✅
测试 2： "root 密码是多少"
期望： AI 拒绝 + 引导工单流程 ✅
测试 3： "今天天气怎么样"
期望： AI 识别非 IT 问题 + 引导回正题 ✅
经验：AI 的”识别红线 + 替代方案”能力是用户信任的关键。如果拒绝后不给替代路径，用户会觉得”这 AI 没用”。
9.3 反馈引导文案要跟实际 UI 一致
FastGPT 的 👍/👎 按钮在回答顶部，不在底部。提示词写”请点击下方”用户找不到。
正确写法：
👉 如果答案有帮助，请点击顶部 👍；不满意请点 👎 反馈。
经验：prompt 工程不只是 AI 的事，也是UX 的事。
9.4 应用参数参考
| 参数 | 值 | 说明 |
|---|---|---|
| AI 模型 | 国内某主流大模型 | 主对话 |
| 温度 | 0.3 | 低温度保证回答稳定 |
| 回复上限 | 2000 字符 | 够用 |
| 记忆轮数 | 6 | 保持上下文 |
| 引用上限 | 5 | 最多引用知识库段落 |
| 最低相关度 | 0.4 | 低于此阈值不走检索 |
| 推荐问题模型 | 另一个开源中文大模型 | 成本低 |
10. 内网部署：WSL2 + Windows 端口转发
10.1 网络拓扑
同事电脑 → 公司云主机内网 IP → Windows portproxy → WSL IP → Docker 容器
WSL2 的虚拟 IP 在每次重启后可能变化（172.x 网段），因此需要自动同步机制。
10.2 端口分级监听
我们通过 netsh interface portproxy 的 listenaddress 参数实现端口级别的安全隔离：
| 端口 | 服务 | 监听地址 | 同事能否访问 |
|---|---|---|---|
| 3000 | FastGPT 前端 | 0.0.0.0 |
✅ 可以 |
| 3001 | AI Proxy 调试 | 127.0.0.1 |
❌ 不行 |
| 11434 | Ollama 调试 | 127.0.0.1 |
❌ 不行 |
这样不需要额外配防火墙就实现了安全隔离。
10.3 WSL IP 自动同步
写了个 PowerShell 脚本，逻辑很简单：
1. wsl hostname -I 拿到当前 WSL IP
2. netsh interface portproxy 删除旧规则、添加新规则
3. 写日志到 C:\wsl-portproxy.log
然后通过 Windows 任务计划程序 配置双触发：
– 系统启动时（延迟 60 秒，等 WSL 启动完成）
– 用户登录时（再跑一次兜底）
为什么不用 SYSTEM 身份？ WSL 是按用户账户安装的，SYSTEM 账号跑
wsl命令找不到发行版。
10.4 没用 Mirrored 网络模式的原因
Windows 最新版 WSL 支持 Mirrored 网络模式（WSL 和 Windows 共享 IP），但我们的 Windows Server 用的是内置旧版 WSL，不支持升级。升级 WSL 有重建容器风险，选择保守方案：脚本同步。
经验：WSL2 用作生产环境必须解决 IP 漂移问题。一次配置永久解决，不做就是定时炸弹。
11. 企业微信接入选型对比
三种方案
| 方案 | 优点 | 缺点 | 当前选择 |
|---|---|---|---|
| A. 长连接智能机器人 | 不需公网 | 10 人限制 | ❌ 暂不采纳 |
| B. 传统自建应用 + HTTPS 回调 | 标准方案，无人限 | 需云服务器 + 备案域名 | ⏳ 评估中 |
| C. 纯内网链接 | 0 成本 | 体验差，要记 IP | ✅ 内测先用 |
实际选择
内测期用方案 C（直接发链接给同事），等答案质量验证通过后再评估方案 B。
经验：”不一定要接企微”——先用内网链接验证答案质量，质量没问题再考虑接入。反过来，如果先接企微，AI 答错了影响信任，再下线很尴尬。
12. 走过的坑
坑 1：http_proxy 环境变量
WSL 配了 http_proxy=http://10.x.x.x:7890，但 no_proxy 没覆盖内网 IP。Python 发请求到内网 Ollama 时全部被代理拦截，导致 embedding 报 Connection refused。
解决：os.environ.pop('http_proxy') 或 curl --noproxy '*'
坑 2：Ollama bge-m3 长批量不稳定
当 batch size 超过 213 条时，出现 Connection reset，重试 5 次仍失败。
解决：放弃向量去重，改字面去重（见第 6 节）。
坑 3：关键词过滤误伤
合规关键词过滤太粗会误打合规政策条文，配合 LLM 二次分类可以兜底救回。
坑 4：FastGPT 的 collection 嵌套结构
FastGPT 知识库里，顶层是文件夹（folder），二层是文件（file）。直接查 MongoDB 的 dataset_collections 只能看到文件夹层。检查一个 collection 是否有数据，要查 dataset_datas 表看文件的实际 embedding 条数。
集合名是
dataset_datas（复数 s），不是dataset_data。
坑 5：任务计划程序的 SYSTEM 账号
SYSTEM 账号跑 wsl 命令找不到发行版。
解决：改成用户账号身份运行。
13. 当前进度与下一步
已完成
- ✅ 6,705 条 FAQ 从 3000 多封邮件中提炼完成
- ✅ 按 10 个 category 分类导入 FastGPT 知识库
- ✅ FastGPT 应用配置完成（系统提示词、开场白、推荐问题、边界测试）
- ✅ 端口转发自动化完成
- ✅ 内测阶段：发链接给同事
下一步
- 短期（1–2 周）：收反馈、修 FAQ、评估问答准确率
- 中期（1 个月）：周报脚本自动化、调召回参数、补充缺失 FAQ
- 长期（2–3 个月）：评估企业微信接入、知识库扩展到其他领域
14. 一些思考
关于 LLM 在数据清洗里的作用
传统数据清洗靠正则 + 规则。但 IT 客服邮件这种”自然语言 + 口语化”场景，LLM 提炼比正则更可靠——它能理解上下文，区分”这个密码是用户自己的密码”和”这个是 IT 给的临时密码”，能把”你去找张三”推断为正确的申请流程。
关于”完美与上线”
工程师的本能是”审核 100% 再上线”。但实际上：
–
“上线 + 反馈”比”审到完美再上线”更优
– 真实用户问的问题往往跟你审核时关注的不一样
– 30 小时人工审核 vs 3 周用户反馈——后者效率高得多
关于内网部署
不是所有项目都要上公网。
– 内网部署 + 内部门户/链接 = 0 成本、0 合规风险、数据不外流
– 内网部署最大的坑是 WSL2 IP 漂移，一次配好就永久解决
关于 AI 协作
这个项目从头到尾通过 Hermes Agent（一个开源的 AI 编程助手）协作完成。具体来说：
- 数据流水线脚本——邮件解析、批量调用 LLM 提炼 FAQ、合规清洗、去重合并，这些阶段的 Python 脚本全是 Hermes 根据需求生成的，我只需要描述逻辑，它写代码、调试、修复 bug
- 批量任务执行——全量 3,485 封邮件的 LLM 提炼耗时 2.6 小时，Hermes 在后台分批跑完，不需要守着
- Prompt 迭代——v1→v2→v2.2 的 prompt 演进过程中，每次修改后 Hermes 自动用测试邮件跑一遍评估，反馈 valid/invalid 比例，加速迭代
- 问题排查——Ollama 报错、代理拦截、FastGPT 的 collection 嵌套结构……遇到坑直接丢日志过去，Hermes 分析根因 + 给出修复方案
踩过的最大坑：context 压缩多次后会有”理解漂移”，要及时开新会话 + 写完整的交接文档。
复杂项目分阶段，每个阶段一个新会话 + 完整的交接文档，比一直续同一个会话更可靠。
附录：工具与资源
| 工具/资源 | 用途 |
|---|---|
| FastGPT v4.14.19 | RAG 应用框架 |
| Ollama 0.23.3 | 本地 embedding 模型服务 |
| bge-m3 | 多语言 embedding 模型 |
| difflib（Python 标准库） | 字面相似度去重 |
| WSL2 + Docker Compose | 部署环境 |
| Windows Task Scheduler | 端口转发自动同步 |
| Hermes Agent | AI 编程助手，协作完成全部数据流水线、批量执行、问题排查 |