数字人客服「喊话没反应」怎么修：13 场景模型对比、NOISE 误判双修与主路切换

展厅里最尴尬的一幕不是数字人答错，而是它压根不理人。客户站到屏前说了两遍"你们这个轴承到底怎么样啊"，屏幕上的人偶只是微笑着眨眼，一句不接。客户多半归因成"这玩意儿不行"，然后走掉。

我们遇到这个问题时，第一反应和大多数人一样：换个更聪明的大模型。这个方向是错的——它甚至会让你更晚发现真正的元凶。下面把完整的归因过程摊开，包括一个反直觉的结论：把客户的话误判成环境噪声这件事，换模型解决不了。

一、先把真实配置钉死，再谈调优

数字人项目最容易踩的第一个坑，是改了配置文件以为生效了，其实主路走的是另一段代码。动手前必须先把"当前到底谁在回答"钉死，只读，不改：

目标机：Node4(192.168.1.3)
主文件：~/fullbody_dh/backend/xiaohe_agent.py
         ├─ XIAOHE_PERSONA        ← 人设提示词
         ├─ 噪声判定逻辑（[NOISE] 分支）
         ├─ _ark_stream()         ← 豆包通道
         └─ deepseek_chat_stream()← DeepSeek 通道
知识库：~/fullbody_dh/knowledge_anrui.txt
密钥：  ~/fullbody_dh/backend/ark.key（豆包）；DeepSeek key 硬编码在 .py 里
服务：  fullbody-dh.service(:8002) + xiaohe-agent.service

二、对比方法：13 个客服应变场景，用目标系统的真实 system

比模型不能拿"你好，介绍一下你自己"这种题，那是演示稿。要比真实客服现场。而且必须把目标系统的 完整 system（噪声指令 + 人设 + 知识库全文）原样喂进去——否则你测的是"裸模型能力"，不是"上线后的表现"，而噪声指令恰恰是后面坑的来源。

我们用的 13 题分四类，直接可用作模板：

每条都记录三个数：TTFT（首字延迟）、首句完整度、总耗时。在真流式链路上，TTFT 约等于"用户听到第一声"的时间，这是体验里唯一能被感知的量。

三、实测结果：DeepSeek 胜或不输 12/13，且首字快一倍

同一套 system、同样 13 题，两个模型跑出来的对比（2026-09-14 实测）：

结论很干脆：客服主路该给 DeepSeek。豆包只在"方言呼应"这一项赢，而那恰好是最不该成为选型依据的一项——一句话的口语风格，用 prompt 加两个例句就能补上，没必要为它牺牲另外 12 项。

判读要点（照抄即可）

• 多意图看顺序。豆包曾把"你先给我放首歌"整句无视掉，直接去答公司产品——客户感知是"它没听见我说话"。
• 催问必测。"我都问了三遍了"这类句子是客服系统的照妖镜，它能同时暴露噪声误判、上下文丢失、延迟堆积三类问题。
• 别为方言锁死模型。可见偏好项要用 prompt 补，不要用架构绑。
• 警惕"演示稿型"对比。如果 13 题里有 8 题是自我介绍类，两个模型都会满分，你会得出"都行"的错误结论。

四、⚠️ 真正的元凶：[NOISE] 误判（客服事故级）

数字人的 system 里通常有这么一条指令：如果听到的是环境噪声（展厅背景音乐、旁人闲聊、影视台词），就只输出 [NOISE] 标记，代码收到这个标记就把整条输入丢掉，然后提示用户"再说一遍"。这个设计本身是合理的——展厅里确实全是噪声，不滤掉会疯狂乱答。

问题是：模型会偶发地把"客户的真实提问"也判成噪声。

实测样本："这个什么时候能发货"。
豆包误判 1/3 次，DeepSeek 误判 2/3 次。
代码收到 [NOISE] → 丢弃 + 提示重说 → 客户感知：喊话没反应。

五、双修方案

修复 1 · prompt 边界澄清（改 system）

把判定标准从"像不像噪声"改为"是不是在跟小禾说话"，并给出默认兜底：

只有明显与对话无关、且完全不像在跟小禾说话时才判 NOISE；像提问 / 催促 / 抱怨 / 打招呼一律正常回复；拿不准按正常回复。

关键在最后半句。"拿不准按正常回复"把模型的默认行为从"当作噪声"翻转为"当作对话"，这一句消掉了绝大部分误判。

修复 2 · 代码硬保护（防模型偶发）

prompt 只能压低概率，不可能归零。所以还要在代码层加一道拦截：凡是"长得像提问"的输入被判成噪声，就绕过噪声指令强制正常回复一次。加在 deepseek_chat_stream 之后、_handle 的 if noise[0]: 分支里：

_QUERY_HINT_RE = re.compile(r"[?？]|吗|呢|什么|怎么|咋|为什么|多少|几点|几号|几年|几个|哪里|哪个|哪些|谁|"
    r"有没有|能不能|可不可以|是不是|行不行|好不好|怎么办|如何|帮我|帮忙|问一下|咨询|催|快点|"
    r"发货|现货|库存|报价|价格|多少钱|贵不贵|便宜|你们|咱")

def _looks_like_query(t):
    return bool(_QUERY_HINT_RE.search((t or "").strip()))

def _force_reply_text(t):
    # 用【不含噪声指令】的 system 强制正常回复一次，返回文本或 None
    ...

# _handle 内：
if noise[0]:
    if _looks_like_query(text):
        for _seg in re.split(r"(?<=[。！？!?；;\n])", _force_reply_text(text) or ""):
            if _seg.strip():
                _tts_reply(_seg.strip())
        return
    _ask_repeat(text, "noise"); return

这一层的好处是确定性："你们""多少钱""发货""催"这些词只要出现，模型判什么都不影响结果，代码一定会回话。它牺牲的是一点"多回一句"的风险，换回来的是"不漏话"。

六、主路切换：三级兜底且可一键回滚

确定主路之后，切换动作要满足一个条件：能一键退回去。否则线上出问题你只能现场手忙脚乱。

在 deepseek_chat_stream() 里：
  切 DeepSeek 主路：注释掉 _ark_reply = _ark_stream(...)
                   与 if _ark_reply is not None: return _ark_reply
  豆包降为二级兜底：在 except Exception as e: 里先试 _ark_stream，
                   再 _fallback_reply()

最终链路：DeepSeek → 豆包 → 本地模型

七、回归验证四件套（缺一不可）

1. 保护层单测。应回复的输入必须全部判 True；真噪声（"谢谢观看""字幕 by xxx""一会儿再来""请不吝点赞订阅""关注我""点个赞"）必须全部判 False。
2. 新 prompt 下的客服输入误判率。每条输入跑 3 次——单次跑不出发概率性误判，这是最容易偷懒的地方。
3. 真噪声识别未退化。这是反向红线：别为了"不漏话"把噪声全放进来，展厅背景音一旦乱答，体验崩得更快。
4. 部署与验证。备份 xiaohe_agent.py.bak_YYYYMMDD_HHMM_<用途> → sftp 上传 → md5 比对 → sudo systemctl restart xiaohe-agent.service fullbody-dh.service → systemctl is-active + 端口 + 启动日志三处确认。

八、取舍原则：宁可多回，不可漏话

这套修复做完一定会带来副作用：某些原本被滤掉的视频台词（比如"关注我""点个赞"）现在不再被判定为噪声，数字人显得话多了一点。

但两边的代价完全不对等：

• 漏掉客户真实发言 = 客户认为设备坏了，转身走人，你连数据都拿不到。
• 多回一句视频台词 = 显得有点吵，客户笑一下就过去了。

所以默认方向永远是"宁可多回，不可漏话"。如果展厅话术视频实在多到吵，再补 prompt 示例去收紧——但那是观察之后的动作，不是默认设置。

结语

这个故障最值得记住的不是某段代码，而是那条技术判断："数字人不理人"大概率不是模型不够聪明，而是它的输入在进模型之前就被一个判定逻辑丢掉了。遇到"没反应"类问题，先去数一数有多少条输入死于 [NOISE] 分支，再去谈换模型。

我们站内在售的苏州话标准词库（3550 条）与这类线上服务是两回事，但方法是一个：先把基线量化出来，再谈效果。如果你也卡在数字人"能演示但不能真接待"的阶段，带着具体链路问题来找我们更高效。