AI客服国标落地一个月：从工程角度看，真正要改的是三处数据结构

9月1日《顾客联络服务人工与智能客户服务协同要求》（GB/T 47746---2026）实施，到现在一个多月。

10月12日媒体实测20家平台，多数首屏找不到人工入口；10月15日香港消委会公布，今年首九个月客服类投诉3078宗，按年升近六成，其中AI相关投诉升幅超过140%。

站在工程视角，这些问题大部分不是模型能力问题，而是三处数据结构没设计好。

一、会话上下文没有跨通道传递

新国标要求人机切换时完整同步信息，不得要求消费者重复陈述。

现实里转人工的实现通常是：新建一个工单，把最近N轮对话拼成文本塞进"备注"字段。坐席看到一坨没有结构的文本，第一反应还是重新问。

可落地的做法是三层结构：

json 复制代码

{
  "session_id": "s_20261024_001",
  "entities": {"order_no": "...", "phone": "...", "sku": "..."},
  "attachments": [{"type": "image", "url": "...", "captured_at": "..."}],
  "intent_trail": [{"turn": 3, "intent": "refund", "confidence": 0.62}],
  "handoff_reason": "intent_low_confidence"
}

关键在 entities 和 attachments：它们必须由机器人侧主动抽取并落库，而不是靠坐席从对话记录里肉眼找。

判断标准很朴素：坐席接手后，第一句话不该是"请问您订单号是多少"。

二、知识库条目缺元数据

大部分企业知识库的表结构只有 id / question / answer / category。

缺三样东西，直接导致答错：

updated_at：这条什么时候改的
effective_from / effective_to：什么时候生效、什么时候失效
owner：谁负责这条

没有有效期，模型就会拿2023年的活动规则回答2026年的问题；没有责任人，出错之后没人认领。

腾讯云开发者社区10月22日那篇《企业知识库越大为何还答错》讲的是同一件事：先按权限、版本、有效期过滤，再做检索。检索质量的上限，是过滤质量。

一条最小可用的表结构：

sql 复制代码

ALTER TABLE kb_entry
  ADD COLUMN updated_at   DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
  ADD COLUMN effective_to DATETIME NULL,
  ADD COLUMN owner        VARCHAR(64) NOT NULL,
  ADD COLUMN version      INT NOT NULL DEFAULT 1;

有了 effective_to，检索时就能加一句 WHERE effective_to IS NULL OR effective_to > NOW()，把过期内容挡在召回之外。

三、答复层没有身份标识

国标和消委会提示都指向同一点：企业要对AI答复承担主体责任。

工程上要做到可追溯，答复体里至少要带三个字段：

json 复制代码

{
  "answer_id": "a_...",
  "generated_by": "ai",
  "citations": [{"kb_id": 10231, "version": 3}],
  "disclosed": true
}

citations 是给内部看的，用于出问题时回溯"这句话是从哪条知识来的"；disclosed 是给用户看的，标记这条答复已声明为AI生成。

我们自己那套客服系统，首屏问候写了"我是智能客服"，但后面每条答复没带标识------对照61项要求自查时，这是没过的一项。

需要避开的三个实现坑

别把拦截率当指标。 一旦以"减少转人工"为优化目标，产品会自然走向隐藏入口，这是消委会点名的第一类陷阱。
别让AI直接承诺金额。 退款、赔付、违约金这类，AI只做记录和转交，金额必须人工确认后回写。
转人工的触发条件要写死。 关键词命中、低置信度、连续两轮未解决、涉及人身财产安全、老人与未成年人，任一命中就转，不要靠模型自己判断。

小结

这三处改动的共同点：都不需要换模型，也不需要买新系统，改的是表结构和消息协议。

对技术团队来说，这比调提示词的收益更确定，也更经得起审计。

我们专注小微企业知识库与AI客服落地。

你那边转人工的触发条件是怎么写的？欢迎交流。