大模型反欺诈项目从开发、测试到部署应如何设计流程，Agent 框架选型需要关注哪些工程约束？｜拼多多算法面经解析

60 秒回答模板

我会先把大模型反欺诈项目定位清楚：它通常不应该一上来就替代风控决策，而是先作为案件分析、风险线索归因、规则解释、证据摘要或人工审核辅助系统。流程上第一步是定义业务边界，包括识别什么类型的欺诈风险、输入有哪些行为特征和文本证据、输出是风险分、原因解释、处置建议还是人工复核任务，以及误判和漏判的成本。第二步是数据和基线建设，整理历史案件、规则命中、人工审核结论、用户行为、关系网络和交易上下文等数据，并做脱敏、去重、标签校验和时间切分，避免数据泄露。第三步是设计 Agent 架构：大模型负责理解、规划和解释，RAG 提供规则和案例知识，工具调用负责查询特征、关系、名单、模型分数和业务状态；有副作用的动作必须经过权限、确认和审计。第四步是开发和测试，先用 mock 工具和固定样本跑通流程，再做单元测试、工具调用测试、Prompt 回归、离线回放、对抗测试、幻觉和越权测试、延迟成本测试。第五步是部署，先 shadow 模式旁路观察，再人工审核辅助、小流量灰度、分层放量，监控准确率、召回率、误杀率、漏放率、解释一致性、工具失败率、P95 延迟、成本和安全告警。Agent 框架选型上，我不会只看是否流行，而会看它是否支持可控状态机、工具 schema、权限隔离、可观测性、重试超时、并发、版本管理、评测集成和生产服务治理。反欺诈场景更适合可控的 workflow 或 graph agent，而不是完全自由的多 Agent 自主协作。

考点 边界优先

难度 真实面经题

回答目标 让面试官看到你能把大模型反欺诈项目讲成可上线、可审计、可评估的工程系统，而不是一个 Agent Demo。

深入解析

先定义反欺诈任务边界

反欺诈不是一个泛泛的聊天场景，必须先说明系统要解决哪类问题：识别异常行为、账号风险、团伙模式、虚假资料、套利路径，还是帮助审核人员总结案件证据。输出也要区分风险评分、原因解释、处置建议和自动执行动作。不同输出对应不同风险等级，尤其是拦截、限制、转人工、复核等影响用户的动作，不能让大模型自由决定。

数据建设要防泄露和偏差

训练或评测数据可以来自历史案件、规则命中日志、人工审核记录、行为序列、关系特征、交易上下文、申诉结果和对抗样本，但要做脱敏、权限控制和时间切分。反欺诈数据很容易出现标签延迟、样本选择偏差和规则泄露，例如模型看到未来审核结果或后验处置字段，离线效果会虚高，线上却失效。

大模型应和风控系统分工

传统风控模型和规则擅长稳定、低延迟、高吞吐的风险打分；大模型更适合解释、归因、跨证据总结、自然语言规则理解和审核辅助。回答时要避免把大模型说成万能判官。成熟架构通常是规则和模型给出候选风险，大模型结合知识库和工具结果生成结构化分析，再由人工或策略系统决定最终处置。

Agent 工具链要可控可审计

Agent 可以调用特征查询、规则库、知识库、关系查询、名单查询、业务状态、历史案件检索、相似风险模式检索等工具。每个工具都要有明确 schema、权限、超时、重试、返回格式和审计日志。对写操作或处置类工具，要加入二次确认、幂等键、审批流和回滚或补偿机制，避免模型误调用造成业务损失。

开发阶段先固化流程和契约

开发流程可以从需求文档、风险分级、数据字典、工具接口、Prompt 模板、输出 schema 和评测集开始。先用 mock 数据和 mock 工具跑通完整链路，再接真实只读工具。Prompt、工具版本、模型版本和规则版本都要可追踪，否则线上 badcase 很难复现。

测试要覆盖质量、安全和工程稳定性

测试不能只看几个样例是否答得像。离线要做历史案件回放、不同欺诈类型分层、误杀和漏放分析、解释一致性评估、工具调用准确性、无证据拒答、Prompt injection、越权查询、敏感信息泄漏和对抗样本测试。工程上还要测超时、下游工具失败、并发峰值、缓存失效、成本预算和降级路径。

部署要从旁路到灰度逐步放量

反欺诈项目上线建议先 shadow 模式旁路运行，只记录 Agent 结论但不影响业务处置；再进入人工审核辅助，让审核员看到证据摘要和建议；效果稳定后按业务线、风险类型、置信度和用户群灰度。每一步都要有回滚策略、人工兜底和告警阈值，不能一次性全量接入核心风控链路。

框架选型看生产约束而不是名气

Agent 框架要关注状态管理、确定性流程、工具 schema、异步并发、可观测性、权限隔离、错误恢复、评测集成、模型切换、服务部署和团队技术栈兼容。图式工作流适合强流程控制，轻量自研框架适合强约束场景，生态型框架适合快速接工具但要治理复杂度。反欺诈更重可控、可测、可审计，而不是追求 Agent 自主性。

易错点

把项目流程讲成训练模型、调 Prompt、上线三步，缺少数据、评测、灰度和监控闭环。
默认大模型可以直接做反欺诈处置，忽略误杀、漏放、申诉和审计风险。
只说用了某个 Agent 框架，没有解释为什么适合生产工程约束。
没有区分只读分析工具和有副作用处置工具，缺少权限、确认、幂等和回滚设计。
离线评测只看准确率，不处理时间穿越、标签延迟、样本偏差和欺诈类型分层。
忽略 Prompt injection、越权查询、敏感数据泄露和下游工具失败等安全测试。

面试官追问

为什么反欺诈场景不建议让大模型直接做最终拦截？

因为反欺诈处置有高业务风险，误杀会伤害正常用户，漏放会造成损失。大模型存在幻觉、上下文缺失和不稳定输出，更适合做证据组织、归因和建议，最终处置应由规则、风控策略、人工审核或受控流程决定。

如何构建大模型反欺诈项目的评测集？

可以按历史案件时间切分，覆盖不同欺诈类型、正常样本、边界样本、申诉成功样本和对抗样本。标注不仅要有风险结论，还要有证据链、处置依据和解释质量标准，方便评估模型是否真正基于证据判断。

Agent 工具调用失败时怎么处理？

要按工具重要性分级。关键工具失败时应停止给确定结论，输出无法判断或转人工；非关键工具失败可以降级为少证据分析。系统还要记录失败原因、重试次数和下游耗时，便于监控和复盘。

Agent 框架选型会重点比较哪些能力？

重点看状态机控制、工具 schema、可观测性、并发和超时、权限隔离、版本管理、评测集成、部署方式和团队维护成本。反欺诈项目通常更适合可控流程框架，而不是完全开放的自主多 Agent。

上线后如何判断项目真的有效？

要同时看业务效果和工程质量：风险召回、误杀率、漏放率、人工审核效率、案件解释一致性、申诉率、工具失败率、P95 延迟、单次成本和安全告警。只看模型回答质量不够。