游戏客服系统选型调研与知识库（AI-ready）设计

状态

Accepted（调研结论 + 分阶段整合计划）。P1 已落地（FAQ 投票/搜索/标签 + 工单玩家上下文）。

1. 背景

Croupier 自带轻量客服模块（Ticket/TicketComment/Feedback/FAQ/FAQCategory），覆盖后台工单流转与 FAQ 展示，但相比专业游戏客服系统缺少：玩家上下文、知识库治理（投票/缺口）、AI 能力。本文调研主流方案，回答三个问题：

要不要直接集成商用/开源客服系统？
游戏场景"必须"的能力是哪些？
FAQ 如何演进为对人 + 对 AI 双友好的知识库？

2. 专业客服系统对比

2.1 国际方案

系统	定位	游戏优化	核心能力	计费	评价
Helpshift	手游客服专用（Supercell 系厂商常用，2021 被 Scopely 收购）	★★★★★	in-game 原生 SDK（不打断游戏）、QuickSearch Bot、自动附带玩家上下文（playerId/区服/等级/设备/网络）、Intent 意图分类	按 MAU 计费	游戏客服标杆；闭源 SaaS，工单数据在对方，深度 GM 联动需 webhook
Zendesk	全能型市占第一	★★★	Suite+Guide 知识库、AI agent、SLA、多语言	$19–115/agent/月	大厂游戏公司用的最多（如 Riot）；贵，游戏特化弱于 Helpshift
Intercom	AI 化最深	★★	Fin AI 客服（按解决量计费）、消息式交互	$0.99/-resolution + 高额席位	AI 体验最好；贵；SaaS 数据外流
Freshdesk/Freshservice	高性价比全能	★★	工单+知识库+Bot	$0–79/agent/月	功能全但无游戏特化
tawk.to / Crisp	轻量聊天	★	实时聊天 widget	免费起	不适合工单制 GM 场景

2.2 国内方案

系统	游戏方案	核心能力	备注
网易七鱼	游戏行业版	in-game SDK、玩家 360 视图（订单/充值联动）、智能机器人、常见问题自动联想	国内手游客服最成熟方案之一
智齿科技	游戏行业方案	全渠道接入+工单+AI 机器人+呼叫	37 互娱等客户
Udesk	游戏行业方案	玩家上下文视图、工单 SLA	传统企业客服强
美洽	轻量在线客服	在线聊天+轻工单	中小团队

2.3 开源方案

系统	类型	评价
Chatwoot / Freescout / UVDesk	通用工单/聊天	无游戏特化；玩家上下文、in-game SDK 都要自建；集成成本 ≈ 自建
RAGFlow / Dify / FastGPT	AI 知识库平台	可作为 AI 层的外挂，不解决工单；知识库双写治理复杂

2.4 结论：不自建 SaaS 集成，借鉴模型自整合

理由：

工单数据主权：客服工单含玩家隐私与充值纠纷，GM 平台（croupier）的工单必须留在自有库，SaaS 方案数据外流且双向同步成本高；
GM 联动是 croupier 独有优势：工单处理常需要查玩家/补单/改数据——这些正是 croupier 的函数调用能力。工单在自家系统里可以直接跳转 GM 操作页面/函数执行，任何 SaaS 都做不到；
游戏必须能力可拆解：Helpshift/七鱼的核心差异其实就三件事——玩家上下文自动附带、in-game 入口、AI 知识库——均可分阶段自建（见 §4）。

3. 游戏客服"必须能力"清单

#	能力	现状	目标	阶段
1	工单玩家上下文（playerId/区服/等级/设备/OS/语言/充值档）	仅有 playerId/contact	结构化列 + extra JSON	P1 ✅
2	FAQ 投票治理（有用/无用计数驱动内容优化）	无	helpful/unhelpful 计数 + 投票端点	P1 ✅
3	FAQ 搜索与标签过滤（人用）	无	关键词 + 标签过滤	P1 ✅
4	FAQ→知识库演进（slug/摘要/多语言/状态机）	部分（tags/sort/visible）	对人+对 AI 双友好结构	P1 ✅（slug/summary）
5	玩家侧 API（in-game SDK 对接：创建/查询工单、查 FAQ）	仅后台 API	玩家 token 认证的公开只读/提交端点	P2
6	反馈→工单转化（Feedback 一键升级 Ticket）	两套独立模型	转化端点 + 关联	P2
7	AI RAG 机器人（知识库问答 + 引用返回）	无	pgvector + embedding，检索 API	P3
8	知识缺口队列（AI 未命中/差评 FAQ → 待补知识）	无	依赖 #2/#7 的数据	P3
9	工单 SLA（DueAt 已有）+ 升级/重开	部分	状态机补全（重开/升级）	P2
10	满意度评价（CSAT）	Feedback.Rating 近似	工单关闭时评价	P2

4. 知识库设计（AI + 人双友好）

4.1 FAQ = 知识库吗？

FAQ 是知识库的一种呈现形态（Q&A 对），不是全部。游戏知识库实际有三类内容：

FAQ：玩家问法 → 标准答案（本次演进主体）；
运营公告/维护说明：时效性内容（可后续作为 FAQ 的 category）；
GM 内部 SOP：客服处理流程（如"充值未到账排查步骤"）——对 AI 客服尤其重要（内部检索，不对外）。

4.2 数据模型（P1 落地部分）

FAQ
├── 分类（现有 FAQCategory）
├── 问题/答案（现有，答案支持 Markdown）
├── Tags []string        # 治理标签（JSON 列，已现有）
├── Slug                 # P1 新增：稳定引用 ID（AI 引用返回、deep link）
├── Summary              # P1 新增：给 AI 的短摘要（RAG chunk 的 title 部分）
├── HelpfulCount         # P1 新增：有用投票
├── UnhelpfulCount       # P1 新增：无用投票
├── Views / Sort / Visible（已现有）

多语言：问题/答案文本沿用 spec.LocalizedText（zh-CN/en-US）契约思路，后续若拆多语言列需独立提案；当前先以"一FAQ 一主语言 + tags 标注语言"运行。

4.3 人的消费路径

后台（客服/运营）：分类树管理、标签筛选、关键词搜索、投票/浏览量排序找待优化内容（unhelpful/(helpful+unhelpful) 比率高的进队列）；
玩家（P2 API / in-game SDK）：分类浏览 → 搜索 → 阅读详情 →「有用/无用」一键反馈（负反馈后引导提工单，形成闭环）。

4.4 AI 的消费路径（RAG，P3）

玩家提问 → embedding → pgvector 相似检索（filter: tags/category/visible）
        → top-k FAQ（slug+summary+answer chunk）
        → LLM 生成回答（必须附带 slug 引用）
        → 命中率低/用户负反馈 → 知识缺口队列 → 人工补 FAQ

向量库选型：

方案	优点	缺点	结论
pgvector	已有 PG，零新组件；HNSW 索引百万级向量够用；可 JOIN 业务表（FAQ 治理字段直接过滤）	规模上限低于专用库	推荐起步
Qdrant	性能/过滤强、Rust 单二进制部署轻	新组件	FAQ 量级 >50 万或 QPS 高时迁移
Milvus	亿级	重（etcd+多组件）	游戏知识库基本用不到
Weaviate	内置 embedding 模块	新组件	不必要
Chroma	原型友好	生产弱	仅试验
ClickHouse 向量检索	已有 CH	向量功能新、无 HNSW 成熟度	不做主库

结论：pgvector 起步——croupier meta 库已运行 PG，加扩展即可（CREATE EXTENSION vector），FAQ 级数据量（千~万条 × chunks）远在 pgvector 舒适区；未来量大再按需迁移 Qdrant，检索接口层做抽象（/knowledge/search 先关键词、后向量，DTO 不变）。

4.5 为什么不直接上"聊天机器人平台"（Dify/RAGFlow）

知识库治理必须与工单/反馈同库闭环（差评→缺口→补内容→AI 生效的飞轮），外挂平台会让知识出现第二事实源。P3 的 AI 层以自建薄检索 API + 可替换的 LLM provider实现，知识库本体始终在 croupier。

4.6 检索 Provider 接口（P3 落地契约，2026-09-28 设计；未实施）

知识本体始终在 croupier（faqs 表 + slug/summary/tags），检索层做可插拔 Provider：pgvector 内置起步（§4.4 结论），WeKnora（腾讯开源）/ Dify / RAGFlow 等平台经 HTTP 适配接入——它们的文档解析、embedding、重排能力适合承接 §4.1 第 2/3 类内容（公告长文、GM 内部 SOP），与 FAQ 的结构化 Q&A 互补。外接平台只做检索执行器，不做事实源。

Go 接口（internal/knowledge，命名草案）：

// Hit 必须携带 FAQ slug——「AI 引用可回链」是硬契约（见 §6 checklist）。
type Hit struct {
    Slug     string  `json:"slug"`
    Score    float32 `json:"score"`
    Question string  `json:"question"`
    Answer   string  `json:"answer"`
    Summary  string  `json:"summary"`
    Locale   string  `json:"locale"` // BCP47
}

type SearchRequest struct {
    Query    string
    TopK     int
    GameID   string
    Env      string
    Category string
    Tags     []string
    Visible  *bool // 治理字段必须可下推过滤
}

type IndexableDoc struct {
    Slug     string
    Locale   string
    Question string
    Summary  string
    Answer   string
    Tags     []string
    Category string
    Chunks   []string
}

type Provider interface {
    Name() string
    Upsert(ctx context.Context, doc IndexableDoc) error // 幂等：slug+chunkIdx 定位
    Delete(ctx context.Context, slug string) error
    Search(ctx context.Context, req SearchRequest) ([]Hit, error)
    Healthz(ctx context.Context) error
}

REST 面（走平台统一 API 响应契约，禁止 envelope）：

POST /api/v1/knowledge/search：AI 消费入口（game scope 过滤；hit 必带 slug）
POST /api/v1/knowledge/reindex：按分类/全量重建（admin；风险定级走审批）
GET /api/v1/knowledge/status：provider 名、索引条数、最近索引时间、健康

接入配置（canonical lowerCamelCase）：

yaml

knowledge:
  provider: pgvector # pgvector | http
  http: # provider=http 时生效（WeKnora / Dify / RAGFlow 等）
    baseUrl: http://weknora:8080
    apiKey: ""
    datasetId: ""
    timeout: 5000

同步链路：FAQ CRUD → 异步 upsert/delete 到 provider（失败进重试与知识缺口队列，不阻塞主链路）；存量无 slug 行不进向量索引（迁移补 slug 后才可检索）。多语言沿用 §4.2「一 FAQ 一主语言」现状。

P3 实施顺序：pgvector driver（CREATE EXTENSION vector + chunk 表 + 相似检索）→ /knowledge/search（先关键词后向量，DTO 不变）→ http driver（WeKnora 适配为首个外接实现）。

5. 已落地

P2（本轮）

POST /api/v1/feedback/:id/convert：反馈一键转工单（携带玩家上下文与原文，幂等——重复转化返回原工单）；反馈标记 triaged
POST /api/v1/tickets/:id/rate：CSAT 满意度（1-5，仅 resolved/closed 可评，重开自动清分）；迁移 0010（rating/rated_by/rated_at）
前端：反馈列表「转工单」直连新端点（已转化置灰），工单详情满意度星级

P1

迁移 0005_support_context.sql：faqs 增加 slug/summary/helpful_count/unhelpful_count；tickets 增加 server_id/player_level/device_os/device_model/language/extra（JSON）；
FAQ API：POST /api/v1/faqs/{id}/vote、列表支持 search/tag 过滤与投票排序；
Ticket API：创建/详情透传玩家上下文；
详见 internal/api/faq/、internal/api/ticket/、internal/db/migrate/migrations/0005_support_context.sql。

6. Review Checklist

新增客服字段必须先过 §3 能力清单定位（属于哪一阶段、是否必须）；
模型加列必须走编号迁移（make migrate-hash 后提交），禁止只改 struct；
FAQ 内容字段命名遵循 LocalizedText 契约（BCP47 key）；
AI 相关迭代必须保留「人工可治理」出口：投票、缺口队列、引用返回缺一不可。

游戏客服系统选型调研与知识库（AI-ready）设计 ​

状态 ​

1. 背景 ​

2. 专业客服系统对比 ​

2.1 国际方案 ​

2.2 国内方案 ​

2.3 开源方案 ​

2.4 结论：不自建 SaaS 集成，借鉴模型自整合 ​

3. 游戏客服"必须能力"清单 ​

4. 知识库设计（AI + 人双友好） ​

4.1 FAQ = 知识库吗？ ​

4.2 数据模型（P1 落地部分） ​

4.3 人的消费路径 ​

4.4 AI 的消费路径（RAG，P3） ​

4.5 为什么不直接上"聊天机器人平台"（Dify/RAGFlow） ​

4.6 检索 Provider 接口（P3 落地契约，2026-09-28 设计；未实施） ​

5. 已落地 ​

P2（本轮） ​

P1 ​

6. Review Checklist ​