1. 从“调接口”到“会思考”推荐系统诊断的范式跃迁在推荐系统的日常迭代和维护中我们常常陷入一种“消防员”式的被动响应模式。线上指标如点击率、转化率突然下跌业务方一个电话过来我们第一反应是什么大概率是赶紧查日志、看监控、调接口把几个核心召回和排序服务的接口挨个调用一遍看看返回的数据对不对、有没有报错。这个过程我们称之为“调接口”式诊断。它高度依赖工程师的经验、直觉和体力面对一个由数百个微服务、数千个特征、实时与离线数据流交织而成的复杂系统这种方式的效率瓶颈和诊断深度是显而易见的。你可能会花上大半天时间才定位到是某个特征生产管道延迟了十分钟或者某个向量索引的某台机器负载异常。而“会思考”的诊断则意味着引入一个能够自主感知、分析、推理并采取行动的智能体Agent。它不再是一个被动的、需要明确指令的工具而是一个具备一定领域知识推荐系统架构、业务指标关联、故障模式和推理能力基于观察进行假设、制定验证计划的协作者。当指标异常时这个Agent能够像一位经验丰富的值班专家一样自动拉取相关数据分析可能的原因链路执行一系列诊断动作如查询特定服务状态、验证特征一致性、进行A/B实验切片分析并最终给出带有置信度的根因推测和修复建议。这不仅仅是自动化这是认知能力的升级。今天要聊的就是得物技术团队如何将这一构想落地打造一个真正“会思考”的推荐系统诊断Agent以及我们在AICon大会上分享的核心实践与思考。2. 核心设计思路构建具备领域知识的推理引擎2.1 为何是Agent而非规则引擎或传统监控在项目初期我们内部也有过争论用一套更复杂的规则引擎或者增强现有的监控告警系统是不是也能达到类似效果答案是可以缓解但无法根治。规则引擎的本质是“IF-THEN”的逻辑判断它擅长处理已知的、确定性的故障模式。例如“IF 服务A的QPS下降超过50% AND 错误率上升超过5% THEN 告警服务A可能异常”。但对于推荐系统这种多变量、强耦合、现象与根因往往相隔甚远的场景未知的故障模式即“长尾问题”才是消耗我们最多精力的部分。规则引擎无法处理它没见过的情况。传统监控系统则更侧重于“展示”和“报警”它告诉你“哪里不对了”比如某个接口耗时百分位数飙升但很少告诉你“为什么不对”以及“接下来该怎么办”。它缺乏将多个孤立指标关联起来并串联成一条因果链的能力。而Agent特别是基于大语言模型LLM驱动的Agent其核心优势在于泛化推理能力和自然语言交互能力。我们可以将推荐系统的领域知识拓扑结构、指标含义、常见故障树注入给Agent让它具备一个“专家大脑”。当面对一个异常现象时Agent能够利用这个大脑进行思考观察Observation- 思考Thought- 行动Action- 再观察形成一个循环这正是ReAct框架的核心。例如观察到“首页推荐流点击率下跌”Agent的“思考”可能是“点击率下跌可能源于召回多样性不足、排序模型分数漂移、或前端渲染问题。我先检查召回服务的各项指标。” 然后它“行动”调用召回服务的健康检查接口。根据返回结果它进行下一轮“思考”和“行动”。这个过程模拟了人类专家的诊断路径但速度和广度远超人类。2.2 架构选型为什么是ReAct 定制化工具在众多Agent框架如LangChain、AutoGPT、CrewAI和推理模式中我们选择了ReActReasoning Acting作为核心范式并在此基础上进行了深度定制。ReAct将推理和行动显式地交织在一起让Agent的“思考过程”变得可追溯、可调试这对于要求高可靠性的生产系统诊断场景至关重要。我们的架构可以简化为以下几个核心层感知与触发层对接公司内部的统一监控平台如Prometheus、夜莺、业务指标平台和日志系统。它持续监听关键指标如QPS、延迟、错误率、CTR、CVR等。当某个指标突破预设的动态阈值不是固定阈值而是基于历史数据计算的智能阈值时会自动生成一个诊断任务触发诊断Agent。Agent核心引擎层规划模块Planner基于初始异常信号如“排序服务p99延迟上涨30%”利用LLM进行任务规划。规划的输出是一个初步的诊断计划例如“第一步确认是全局性问题还是局部性问题检查所有实例第二步如果是局部性问题定位具体实例并检查其资源CPU、内存、网络第三步检查该实例的依赖服务如特征数据库、模型服务。”推理与执行模块ReAct Loop这是核心。Agent按照规划或在执行中动态调整计划循环进行Thought根据当前上下文历史观察、知识库分析现状决定下一步要做什么、为什么。Action从**工具库Toolkit**中选择一个工具并执行。工具就是对内部各种系统接口的封装。Observation获取工具执行的结果可能是JSON数据、文本日志或成功/失败状态。记忆与上下文管理保存完整的ReAct链历史确保Agent有足够的上下文进行多步推理。同时维护一个“诊断会话”将同一异常事件相关的所有诊断活动关联起来。领域工具库层这是Agent的“手和脚”。我们将所有可操作的系统接口封装成标准的工具函数。每个工具都有清晰的名称、描述、参数格式和返回值示例。这相当于教Agent学会了使用我们所有的运维和诊断工具。关键工具包括query_service_metrics(service_name, metric_type, time_range): 查询指定服务的详细监控指标。check_service_health(service_name, instance_ip): 对特定服务实例进行健康检查。retrieve_logs(service_name, keyword, time_range): 检索包含关键字的服务日志。compare_feature_version(feature_name, online_offline): 对比线上服务使用的特征版本与离线特征库中的最新版本是否一致。run_abtest_slice_analysis(experiment_id, metric): 对A/B实验进行切片分析看异常是否只发生在某个实验组。query_trace(trace_id): 根据TraceID查询全链路调用详情。知识库与反馈层包含静态的领域知识如系统架构文档、故障处理手册和动态积累的诊断案例库。每次诊断结束后无论成功与否都会经过人工复核或自动评估将本次诊断的路径、结果和有效性沉淀到案例库中用于优化Agent未来的决策。注意工具设计的核心原则工具必须“原子化”且“可靠”。一个工具只做一件事并且要有明确的成功/失败状态和结构化的返回。避免设计一个“诊断整个排序服务”的巨无霸工具而应拆分成“检查排序模型加载状态”、“验证输入特征范围”、“查询缓存命中率”等多个小工具。这降低了LLM理解和使用工具的难度也便于问题定位。2.3 大模型选型与Prompt工程实战Agent的“大脑”是大模型。我们测试了多种云端和开源模型选型的核心考量是强推理能力、长上下文支持、稳定的API以及可控的成本。最终我们选择了性能与成本平衡较好的模型作为核心推理引擎例如GPT-4系列或国内同等能力的模型并在对延迟要求极高的子任务上使用微调后的中小模型如Qwen、DeepSeek进行补充。Prompt工程是让Agent“懂业务”的关键。我们的主Agent Prompt模板包含以下几个部分你是一个资深的推荐系统运维专家负责诊断系统异常。请遵循以下步骤和原则 1. **目标**找出导致【{异常指标}】异常的根本原因。 2. **背景知识**{插入系统架构、关键服务依赖关系等知识} 3. **可用工具**{列出所有工具的名称、描述和调用示例} 4. **推理规则** - 始终遵循ReAct格式Thought: ... Action: ... Observation: ... - 一次只执行一个Action。 - 基于Observation分析后再决定下一步Action。 - 优先排查影响面最广或最可能的原因。 - 如果找到确凿证据指向某个根因可以结束诊断并给出结论。 5. **当前会话历史**{插入之前的ReAct步骤} 6. **开始诊断**当前问题是{最新的异常描述}我们通过大量历史故障案例进行“情景模拟”训练不断调整Prompt和工具描述让Agent学会像我们的高级工程师一样思考。例如教会它当发现“特征数据延迟”时不仅要报告这个现象还应进一步追问“是哪个特征生产作业失败了”以及“影响了哪些排序模型”。3. 核心诊断流程拆解与Agent实操3.1 诊断链路的启动与初步归因假设监控系统触发了一个告警“主推荐场景的‘点击率’在过去15分钟内相对下跌8%”。诊断Agent被实例化并接收到这个初始事件。第一轮思考ThoughtAgent会调用其内置的“故障模式知识”CTR下跌的可能原因是一个树状结构召回侧物品池变化、召回分数异常、排序侧模型分数漂移、特征异常、展示侧前端曝光日志丢失、UI渲染问题、用户侧流量来源变化。它会优先考虑影响最大、最可能的原因。在得物的架构中排序模型的影响通常最直接。因此它的第一个Action可能是行动Action调用query_service_metrics(service_name“ranking-service”, metric_type“model_score_stats”, time_range“15m”)查询排序服务模型输出分数的统计特征如均值、方差、分位数是否有突变。观察Observation工具返回JSON数据显示排序服务输出的预测分数p75值在10分钟前开始显著升高。第二轮思考Thought模型分数整体上移可能导致原本排名靠后的物品被排到前面而这些物品的实际点击能力可能较弱从而导致整体CTR下降。分数漂移的原因可能是输入特征异常或模型本身问题。需要验证特征。行动Action调用compare_feature_version(feature_name“user_click_7d_cnt”, online_offlineTrue)检查一个关键特征“用户7天点击次数”的线上使用版本与离线最新版本是否一致。观察Observation返回结果显示不一致线上服务使用的特征版本号是v20231027而离线特征库中该特征的最新版本是v20231103。这意味着线上服务使用了过时的特征数据。至此一个潜在的根因已经浮现特征数据更新停滞。但一个严谨的专家不会就此止步。3.2 深度下钻与根因确认第三轮思考Thought需要确认特征更新停滞是普遍现象还是仅此一例以及停滞的原因。首先检查特征更新管道。行动Action调用check_service_health(service_name“feature-pipeline-job”, instance_ip“all”)检查特征生产作业的健康状态。观察Observation返回显示负责生产user_click_7d_cnt特征的Spark作业在最近一次运行时失败。第四轮思考Thought作业失败的具体原因需要查看日志。同时需要评估这个特征过期对CTR的影响程度可以通过A/B实验的切片分析来验证。并行行动这里Agent可以展示更高级的规划能力发起两个并行的检查在实际实现中可能通过子任务或顺序执行快速完成retrieve_logs(service_name“feature-pipeline-job”, keyword“FAILED”, time_range“1h”)检索作业失败日志。run_abtest_slice_analysis(experiment_id“homepage_ranking_v2”, metric“click_rate”)分析实验各分组的CTR看是否只有使用该过期特征的分桶指标下跌。观察Observation日志显示失败原因为“依赖的用户行为日志Hive表分区不存在路径为/user_behavior/log/dt20231103”。A/B实验分析显示只有实验组B使用了包含过期特征的模型版本的CTR显著下跌对照组和实验组A正常。最终推理与报告至此Agent形成了完整的证据链。它生成最终诊断报告根因上游用户行为日志数据延迟导致特征生产作业失败进而使得排序服务使用了过期的用户点击历史特征引起模型分数分布漂移最终表现为推荐CTR下跌。证据排序服务模型输出分数p75值异常升高间接证据。关键特征user_click_7d_cnt线上版本落后直接证据。特征生产作业失败日志指向源头数据缺失根本原因。A/B实验切片分析证实了特征过期与CTR下跌的因果关系影响验证。建议动作立即检查并修复上游用户行为日志的生成和传输链路。重启失败的特征生产作业。考虑对排序服务进行特征版本热更新或回滚至上一个稳定的模型版本。这个诊断流程从触发到产出报告在Agent的自动化执行下可能只需要2-3分钟而人工完成同样的深度排查可能需要数小时。3.3 实操中的关键配置与调优点要让上述流程稳定运行以下配置和调优至关重要工具调用的超时与重试每个工具调用都必须设置合理的超时时间如5秒和重试策略如最多2次。网络抖动或目标服务临时高负载不应导致整个诊断流程失败。LLM响应的结构化解析与校验我们必须强制LLM按照严格的格式如指定的JSON Schema输出Thought和Action。我们会用解析器校验输出如果格式错误会要求LLM重试并记录此次格式错误作为优化Prompt的依据。诊断深度与循环限制为了避免Agent陷入“思考循环”或执行过多无意义的操作必须设置最大ReAct步数如20步和最大耗时如5分钟。达到限制后Agent应总结当前发现给出“未找到确定根因”的结论和已排查的路径。观察结果的摘要与提炼工具返回的原始数据特别是日志可能非常冗长。我们设计了一个“摘要工具”或让一个小模型专门负责将长的Observation提炼成关键信息再喂给主Agent进行下一步推理以节省上下文窗口和Token消耗。4. 常见问题、挑战与我们的应对策略4.1 Agent的“幻觉”与错误决策这是LLM应用的核心挑战。Agent可能会提出一个不合逻辑的Action或者对Observation做出错误解读。我们的应对策略是多层的工具层面约束工具的设计要尽可能“傻瓜化”减少歧义。例如query_service_metrics工具必须传入明确的service_name不允许Agent自己“猜测”一个服务名。Prompt工程强化在Prompt中明确加入“安全护栏”和“推理指南”例如“如果你不确定某个服务是否存在请先使用list_available_services工具进行查询而不是直接调用。”人工审核回路对于高严重级别的告警或者Agent给出的诊断结论置信度不高时系统会自动将诊断报告和完整推理链转给人工工程师进行最终确认。同时这也是一个高质量的训练数据反馈来源。多Agent投票机制对于核心场景我们尝试部署两个独立配置的Agent同时进行诊断对比它们的推理路径和结论。如果结论一致则置信度高如果不一致则触发更详细的检查或人工介入。4.2 系统复杂性与知识更新推荐系统本身在快速迭代新的服务、特征、模型不断上线。如何让Agent的知识库保持同步自动化知识抽取我们将架构文档、服务注册中心、数据血缘系统作为知识来源。通过定期的自动化脚本将这些信息结构化后更新到Agent的知识库中。例如当一个新的排序服务上线时其服务名、功能描述、依赖的关键特征会自动录入知识库。诊断案例的自学习每次成功或失败的人工复核后该诊断案例会被打上标签如“特征问题-数据延迟”、“模型问题-版本错误”存入案例库。未来遇到类似异常模式时Agent可以优先参考历史上的成功诊断路径。4.3 性能、成本与稳定性实时诊断对延迟有要求而大模型的API调用有成本和延迟。分层诊断策略并非所有告警都触发完整的Agent诊断。我们根据告警级别和类型进行分流。低级别或明确的告警如某台机器CPU100%走传统规则处理。只有高级别、现象复杂的告警如核心业务指标异常才触发完整Agent诊断。本地小模型分担任务将一些模式固定、逻辑简单的子任务如日志关键词提取、指标趋势判断交给部署在本地的、微调后的小模型7B-14B参数处理降低对昂贵大模型的依赖和调用延迟。异步与队列诊断任务进入消息队列由Agent池异步消费避免阻塞告警通道也便于做流量控制和优先级调度。4.4 评估Agent的有效性如何衡量这个诊断Agent的价值我们定义了以下几个核心指标平均诊断时间MTTD从告警触发到产出初步诊断报告的平均时间。目标是将人工诊断的平均数小时降低到分钟级。根因准确率Agent给出的首要根因经过人工复核后确认为正确的比例。我们初期接受一个“可行动建议”的准确率即即使根因不完全精确但给出的建议能引导工程师快速找到问题也算部分正确。告警降噪率由于Agent能自动关联多个相关告警并归因到一个根因事件上它能够将原本可能触发的数十条关联告警“压缩”成一条诊断报告极大降低了告警噪音。人工介入率需要工程师手动介入排查的异常事件比例。理想情况下这个比例应持续下降。5. 未来演进从诊断到自治目前我们的诊断Agent还处于“会思考的协作者”阶段它的终点是给出诊断报告和建议。接下来的演进方向是走向“自治Autonomy”即在一定规则和权限下自动执行修复动作。我们规划了几个阶段只读自动化当前阶段Agent只有查询和诊断权限。预授权操作对于一些低风险、模式固定的修复动作可以授权Agent自动执行。例如重启已知的、无状态的特征计算作业将流量从确认故障的实例切走。闭环修复对于更复杂的场景Agent可以生成修复预案如回滚方案、扩容方案提交给审批系统经快速人工审批或自动规则审批后自动执行。预测与预防利用Agent的推理能力结合历史数据和实时指标尝试在故障发生前预测风险如发现特征数据增长趋势异常预测未来可能延迟并提前发起预警或干预。这条路很长挑战也更多尤其是安全性和可靠性。但“从调接口到会思考”的这一步我们已经真切地感受到了效率与认知层面的提升。它把工程师从重复、繁琐、高负荷的“救火”中部分解放出来让他们能更专注于系统架构的优化和业务创新。这个Agent就像是我们为复杂推荐系统配备的一位不知疲倦、知识渊博的“数字孪生运维专家”7x24小时地守护着系统的稳定。