GoG RAG 客服机器人

项目背景

Guns of Glory 是 FunPlus 出品的一款全球发行的 SLG 手游，我参与了这款产品超过十年的海外运营工作。

在实际运营中，客服团队面临一个持续存在的效率问题：玩家的常见问题（账号绑定、游戏机制、活动规则等）其实早有标准答案，但这些答案分散在官方 FAQ、社区攻略、运营文档中。玩家找不到答案就提工单，客服反复回答同样的问题。

我想验证一个假设：能不能用 AI 自动回答这些高频客服问题，同时保证回答准确、成本可控？

选择 Guns of Glory 作为实验对象，是因为我对这款产品足够熟悉，能够准确判断每一条 AI 回答的对错 —— 这在 AI 系统的评估中至关重要。

问题定义

核心产品问题：如何让 AI 基于有限的游戏知识库，准确回答玩家的客服问题？

这个问题背后有三个约束条件需要平衡：

1. 准确性 —— 客服回答不能有幻觉，错误答案比没有答案更糟糕
2. 成本 —— 一个 20-40 万 DAU 的游戏，日均 200-250 张工单，方案必须在商业上可行
3. 延迟 —— 面向玩家的场景，等待时间不能太长

方案设计：RAG vs Long Context 对比实验

这个项目最大的亮点不是"做了一个 RAG chatbot"，而是我同时实现了两种技术方案，用相同的测试集做了定量对比，然后基于数据给出了产品决策建议。

为什么做对比实验？

RAG 是目前 AI 客服的主流方案，但它的工程复杂度高、链路中有多个可能丢失语义的环节。随着大模型的 context window 不断扩展（qwen3.5-plus 支持 128K tokens），一个自然的疑问出现了：如果知识库不大，直接把所有文档塞进 prompt 让模型自己找答案，会不会更简单、效果更好？

我决定不猜测，而是实际跑一遍看数据。

RAG 方案：检索增强生成

技术路线：

玩家提问 → HuggingFace all-MiniLM-L6-v2 本地 Embedding（384 维）
         → Supabase pgvector 向量相似度检索（Top-3）
         → 检索片段 + 问题拼接为 Prompt
         → DashScope qwen3.5-plus 生成回答
         → 返回回答 + 来源引用

关键技术决策：

• Embedding 模型选择本地运行的 MiniLM，而非云端 API。原因是 DashScope 套餐不含 embedding 服务，与其阻塞项目等 API 权限，不如用开源方案先跑通。这个决策本身就体现了工程实用主义 —— 在资源约束下选择可行方案，而不是理论最优方案。
• 向量数据库复用 Supabase pgvector，而非 Pinecone 或 Weaviate 等专用向量库。对于 158 条数据的规模，pgvector 完全够用，且我已有 Supabase 基础设施。
• Chunking 策略区分 FAQ 和 Guide：FAQ 作为单条保留（天然的检索单元），Guide 按段落边界切分（~500 tokens，50 tokens 重叠）。

Long Context 方案：全量文档直接输入

技术路线：

玩家提问 → 全部 102 篇文档拼接为上下文（~42K tokens）
         → 文档 + 问题一起发送给 DashScope qwen3.5-plus（128K window）
         → 模型在全部文档中自行定位相关信息
         → 返回回答

这个方案的搭建时间不到一小时，代码量是 RAG 的五分之一。不需要 embedding 模型，不需要向量数据库，不需要 chunking 策略。

对比维度

实验结果

使用 15 个测试问题（涵盖简单 FAQ 查找、跨文档综合、边界情况、超出范围），对两个方案进行了端到端测试。

定量结果

质量对比

在简单 FAQ 查找类问题上，两者表现相当 —— 回答准确，引用清晰。

差距出现在需要综合多篇文档的复杂问题上。例如"怎么防御敌人的集结攻击"：

• RAG 基于检索到的 3 个片段回答，给出了藏兵、采集、医院容量三个策略
• Long Context 综合了 5-6 篇文档的信息，额外提到了和平护盾的使用时机，并给出了具体操作步骤

Long Context 在这类问题上的回答更完整、更有层次感，甚至语气更自然（它会称呼玩家为"Lord"）。

Trade-off 分析

Long Context 赢了质量，RAG 赢了效率。这不是一个"谁更好"的问题，而是一个成本-质量的权衡。

以一个日均 400 次查询的游戏产品为例：

Long Context 的 token 消耗是 RAG 的 68 倍。在生产环境中，这个差距意味着每月多花 ¥4,000-5,000。

技术架构

┌──────────────────────────────────────────────┐
│                  Vercel                       │
│          React/Vite 前端                      │
│        左右分栏对比 UI                         │
│     预设问题 · 延迟/Token 展示                  │
└──────────────┬───────────────────┬────────────┘
               │                   │
          /api/rag           /api/long-context
               │                   │
┌──────────────▼───────────────────▼────────────┐
│                Railway                         │
│             FastAPI 后端                        │
├────────────────────┬─────────────────────────┤
│    RAG Pipeline    │  Long Context Pipeline   │
│                    │                          │
│  MiniLM Embedding  │  全量文档拼接              │
│       ↓            │       ↓                  │
│  Supabase 检索     │  DashScope qwen3.5-plus  │
│       ↓            │                          │
│  qwen3.5-plus 生成 │                          │
└────────────────────┴─────────────────────────┘

数据层：

• 102 篇知识文档（49 条爬取 FAQ + 34 篇社区攻略 + 15 条手动编写高频客服 FAQ + 4 条补充修正）
• 158 个 RAG chunks（存储于 Supabase pgvector，384 维向量）

部署：

• 后端：Railway（Python 3.11 + FastAPI + sentence-transformers）
• 前端：Vercel（React + Vite）
• 数据库：Supabase（pgvector 扩展）
• LLM：DashScope Coding Plan（qwen3.5-plus）

PM 视角的思考

决策框架：什么时候选 RAG，什么时候选 Long Context？

关键判断变量是：查询频率 × 文档规模 × 延迟容忍度。

游戏客服场景的最终建议

纯 AI 客服不现实 —— 复杂工单（支付纠纷、bug 核查、情绪安抚）仍然需要人工。更合理的模型是 AI 处理一线 + 人工处理升级。

AI 的价值不是替代人，而是让人聚焦在真正需要人的地方。

RAG 系统评估的难点

这个项目让我深刻体会到，搭建 RAG 不难，评估 RAG 很难。

• 检索质量和生成质量是两个独立的维度：检索到了正确的文档，不代表 LLM 能给出正确的回答；检索到了错误的文档，LLM 有时候反而能基于部分信息给出合理的推断。
• 评估需要领域专家：我能评估 Guns of Glory 的回答对不对，是因为我运营了十年。换一个不熟悉的游戏，评估成本会高得多。
• 失败分析比成功率更有价值：14/15 的准确率背后，那 1 个失败案例（resonance 机制的 FAQ 被 chunker 误删）揭示了整条链路的脆弱点 —— 数据质量 > 模型质量 > 检索策略。