AI News HubLIVE
站内改写3 分钟阅读

智能体改进循环中的人类判断

AI智能体在反映团队积累的知识和判断时效果最佳。本文探讨如何将人类判断融入智能体开发的生命周期,以交易员助手为例,讲解工作流设计、工具设计和上下文工程,并介绍通过自动化评估和监测来优化智能体的改进循环。

AI智能体在反映团队长期积累的知识和判断时表现最佳。然而,许多组织的关键知识并非以文档形式存在,而是隐藏在员工的头脑中,这就是隐性知识。为了将这些隐性知识融入智能体,需要建立一个包含领域专家输入的改进循环。

本文以一家金融服务公司的交易员助手构建为例,生动展示了如何将人类判断融入智能体开发的每个环节。该智能体的目标是自动回答交易员关于市场数据的问题。传统流程中,交易员需向数据科学团队提问,数据科学家编写SQL查询并返回结果。利用LLM强大的SQL生成能力,这一工作流可以自动化:交易员能更快获得响应,数据科学家也能解放出来专注于更有价值的工作。但要使系统可靠运行,智能体必须理解金融领域的隐性规则(如“今日敞口”或“近期波动率”的解读)以及数据库的实际情况(哪些表是权威的,哪些查询模式容易出错)。这些都需要与领域专家协作才能获得。

智能体由多个组件构成,每个组件都可以通过人类判断得到改进。首先,工作流设计:虽然LLM能自主规划行动,但在高风险场景中,使用确定性代码定义部分工作流可降低延迟、节省token并确保关键步骤执行。例如,在交易员助手中,允许LLM生成SQL查询,但添加代码强制验证结果是否符合风险与合规要求,这需要风险与合规专家的输入。其次,工具设计:开发者需实现工具并配置名称、参数和描述,这些会影响LLM的调用决策。交易员助手的工具可能包括数据库schema检查、查询执行和文档检索。一个关键权衡是灵活性vs.控制:通用的execute_sql步骤允许灵活查询但风险较高,参数化查询工具更安全但能力有限。需要运行评估来确定绩效和风险特征。第三,上下文工程:早期智能体通常只给一个系统提示和工具定义,而业界已转向在初始阶段提供更丰富的上下文。例如,Anthropic的Skills标准允许团队预先策划文档、示例和领域规则,运行时让智能体按需获取。这使智能体能利用更多知识而不使系统提示臃肿。上下文工程也涉及在任务推进过程中如何演进LLM调用中的信息。人类利益相关者对输出和评估分数的反馈会影响端到端的上下文工程设计。

接下来,我们来看如何将人类判断融入智能体的改进循环。LangChain与数百家组织合作的经验表明,最成功的团队遵循紧密的迭代循环:快速构建智能体,部署到生产或类生产环境,收集每一步的数据来指导改进。快速迭代至关重要,因为决定智能体行为的是LLM的实时推理而非代码,只有将智能体置于用户面前才能收集到成功所需的数据。改进循环包括三个阶段:实现第一个版本、上线后监控并收集生产数据、实现并测试改进版本。

在进入具体阶段前,需要强调一个贯穿整个开发生命周期的原则:人力时间高回报的关键在于自动化评估,且这些评估必须与人类判断对齐。团队应让人类帮助设计和校准自动化评估器,而非手动审查大量输出。LangSmith的Align Evaluator功能提供了用户界面,使用精心挑选的示例和主题专家反馈来校准LLM作为裁判的评估器。这对于任何旨在模拟非开发者利益相关者判断的评估器都推荐使用。

具体到交易员助手的开发阶段,工程师首先应创建少量用例场景和期望行为作为测试用例,确认核心任务正确。随后与产品经理和主题专家协作,构建更全面的测试套件。使用LangSmith的数据集功能手动创建ground truth数据集,包含自然语言问题与正确答案的配对,以及好的SQL示例。开发过程中利用评估功能运行测试,LangSmith UI允许技术和非技术成员查看注释结果。通过手动测试中遇到的有趣案例扩充数据集,逐步自动化反馈循环,确保在v1发布前拥有全面的测试套件。

部署后,需要确保可靠性并快速识别问题。传统满意度调查衡量的是用户说的而非实际行为,LLM作为裁判的评估器提供了更稳健的方法。在LangSmith中设置在线评估器,自动检测用户沮丧情绪并标记相关交互供审查。团队的某个成员可以调查trace,决定问题是bug、知识缺口还是工作流弱点。例如,设置自动代码检查来检测缓慢或危险的SQL查询,以及LLM作为裁判的评估器来检测用户不满。

总之,通过将人类判断转化为自动化评估,团队可以在减少人工审查负担的同时,持续、广泛地测试智能体。LangSmith的Align Evaluator功能正是实现这一目标的关键工具。最终,通过不断循环这一改进流程,智能体将逐步吸收团队的知识和判断,实现更高的性能与可靠性。