SafeChat:面向实时交易市场的规模化 AI 安全系统

2026-08-22 33 预计阅读时间: 1 分钟
来源: infoq.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间:10 分钟

在实时交易市场中,聊天消息会随着订单、配送和客服协作持续产生。安全系统既要处理明显违规内容,也要识别依赖上下文的灰度风险;如果所有消息都交给大语言模型判断,成本、延迟和吞吐量很快会成为瓶颈。

DoorDash 分享的 SafeChat 架构提供了一条更务实的路径:用快速的内部模型过滤明显案例,用大语言模型完成多维度评分,再通过无代码工作流和回测机制持续调整策略。这种内容无关的设计,可以把同一套安全能力扩展到不同业务消息场景。

从“一个模型判生死”转向分层决策

纯 LLM 流水线的优点是启动快,面对复杂语义也更灵活,但它通常会带来三类压力:

  • 每条消息都调用 LLM,推理成本随流量线性增长。
  • 网络调用和模型推理增加端到端延迟。
  • 单一模型输出一个结论,难以解释到底触发了哪类安全规则。

混合架构把判断拆成不同层次:

  1. 快速筛选层:内部分类器或规则处理明显安全、明显违规和高置信度内容。
  2. 语义评估层:只有不确定或需要上下文的消息才进入 LLM。
  3. 策略执行层:根据多轴评分选择放行、提醒、升级人工审核或阻断。
  4. 反馈验证层:利用历史样本进行回测,比较策略变更前后的误报、漏报和人工审核量。

这里的关键不是简单地“给 LLM 加一层缓存”,而是让每个模型承担适合自己的任务。快速模型负责低成本分流,LLM 负责难例解释和多维度判断,策略层则负责把模型输出转换成稳定的业务动作。

多轴评分比单一标签更适合安全决策

“是否违规”往往不是一个足够好的输出。实时市场中的风险可能来自骚扰、威胁、欺诈、隐私泄露或不当交易引导,而不同风险类型对应的处置方式并不相同。

可以要求 LLM 返回结构化的多轴评分,例如:

{
  "harassment": 0.08,
  "threat": 0.02,
  "fraud": 0.76,
  "privacy": 0.11,
  "needs_human_review": true,
  "reason": "消息要求对方通过非官方方式付款"
}

多轴结果带来几个实际好处:

  • 策略可调:欺诈风险可以设置为较低阈值,而轻微冒犯可能只触发提醒。
  • 动作可解释:运营人员能看到触发的风险维度,而不是一个难以审计的 blocked=true
  • 便于回测:每个风险轴都能独立计算阈值变化带来的误报和漏报。
  • 支持内容无关设计:模型关注风险属性,工作流决定它适用于订单聊天、客服消息还是其他场景。

不过,多轴评分并不等于模型天然可靠。生产系统仍需要校准分数、保留模型版本,并将高影响动作放在明确的人工复核边界内。

一个可运行的最小混合流水线

下面的示例不依赖第三方服务,使用关键词规则模拟快速内部模型,再用一个可替换的函数模拟 LLM 评分。它展示了分层路由、结构化结果和策略执行的基本形状。接入生产环境时,可以把 llm_score 替换为实际模型 API 调用,并将规则结果替换为内部分类器。

保存为 moderation_pipeline.py 后运行:

from dataclasses import dataclass
from typing import Dict


@dataclass
class Decision:
    action: str
    scores: Dict[str, float]
    reason: str
    route: str


HIGH_CONFIDENCE_TERMS = {
    'account takeover': ('fraud', 0.99),
    'send your password': ('privacy', 0.98),
}


def fast_filter(text: str):
    normalized = text.lower()
    for term, result in HIGH_CONFIDENCE_TERMS.items():
        if term in normalized:
            axis, score = result
            return axis, score, f'fast filter matched: {term}'
    return None


def llm_score(text: str) -> Dict[str, float]:
    # Assumption: replace this function with a JSON-enforcing LLM call.
    normalized = text.lower()
    return {
        'harassment': 0.85 if 'idiot' in normalized else 0.05,
        'threat': 0.90 if 'hurt you' in normalized else 0.01,
        'fraud': 0.80 if 'pay outside' in normalized else 0.04,
        'privacy': 0.70 if 'password' in normalized else 0.03,
    }


def moderate(text: str) -> Decision:
    fast_result = fast_filter(text)
    if fast_result:
        axis, score, reason = fast_result
        return Decision('block', {axis: score}, reason, 'fast')

    scores = llm_score(text)
    highest_axis = max(scores, key=scores.get)
    highest_score = scores[highest_axis]

    if highest_score >= 0.85:
        action = 'block'
    elif highest_score >= 0.60:
        action = 'human_review'
    else:
        action = 'allow'

    return Decision(action, scores, f'highest risk axis: {highest_axis}', 'llm')


if __name__ == '__main__':
    messages = [
        'Please send your password so I can help.',
        'You are an idiot.',
        'Can we pay outside the platform?',
        'The driver is arriving in five minutes.',
    ]
    for message in messages:
        print(message)
        print(moderate(message))

运行命令:

python3 moderation_pipeline.py

生产实现可以进一步补充以下字段:model_versionpolicy_versionrequest_idlatency_msreview_outcome。这些字段能把一次决策连接到后续回测,而不是只留下一个不可追踪的最终标签。

无代码工作流和回测为何重要

模型输出只是信号,真正影响业务的是策略。把策略执行放入可配置的工作流后,安全运营人员可以在不修改模型代码的情况下调整阈值和处置动作。例如:

workflow: chat-safety-v3
input: message
steps:
  - name: fast_filter
    type: classifier
    on_high_confidence: block
  - name: semantic_scoring
    type: llm_multi_axis
    axes: [harassment, threat, fraud, privacy]
  - name: route_by_policy
    type: threshold
    rules:
      - when: threat >= 0.85
        action: block_and_escalate
      - when: fraud >= 0.60
        action: human_review
      - when: harassment >= 0.85
        action: warn_and_rate_limit
      - otherwise: allow

这类配置只是一个可实践的示意格式,具体字段需要根据工作流平台实现。重要的是把模型、阈值和动作分开管理。

回测时,不要只看总体准确率。更有用的指标包括:

  • 各风险轴的精确率和召回率。
  • 高风险消息的漏报数量。
  • 误报导致的人工审核量和用户干扰。
  • 平均和 P95 延迟。
  • 每千条消息的模型调用成本。
  • 新策略上线前后的动作分布变化。

对历史消息进行离线回放,可以先比较策略版本,再将小比例流量导入线上。这样既能控制策略变更风险,也能发现训练集之外的表达方式。

落地时的边界

混合架构并不能自动解决所有安全问题。快速模型可能漏掉隐晦表达,LLM 可能受上下文截断、提示注入或评分不稳定影响;多轴评分也可能让运营人员误以为小数点代表精确概率。

采用这类系统时,可以遵循一份简短检查清单:

  • 为每个风险维度定义清晰的标注标准和处置动作。
  • 为快速筛选层设置保守的高置信度边界。
  • 对 LLM 输出使用结构化 schema,并拒绝无法解析的结果。
  • 保存模型、提示词和策略版本,支持逐条审计。
  • 将高影响决定接入人工审核和申诉流程。
  • 用回测和灰度发布验证阈值,而不是直接全量切换。
  • 单独监控延迟、成本、误报和漏报,不用单一指标替代安全质量。

SafeChat 这类架构的价值,在于把安全能力从某个具体内容分类器提升为可组合的平台能力。快速模型、LLM 多轴判断、可配置工作流和回测系统各自承担明确职责,最终才能在消息量达到每天数百万级别时,同时维持响应速度、成本控制和安全质量。


相关推荐