AI agent产品设计实践：解决业务中的半确定性问题

问题概述

最近，我们团队探索了将AI agent引入到现有的业务系统中，旨在应对业务流程中的一些半确定性问题的挑战。这篇文章汇集了我们从实践中总结出的经验，并提出了如何在实际业务场景中发挥AI的真实价值的思考。此外，我们设计了一个专门针对这类问题的抽象产品框架，期望能够为寻求类似解决方案的朋友们提供启发。我们的目标是在更多现有的业务系统中合理地引入不同的AI agent，以高效地解决复杂问题。

我们尝试解决的问题被称为“半确定性闭合问题”，这个名字听起来很复杂，但其实它描述了以下两个核心特征：

1. 半确定性：意味着这些问题不能简单地通过明确的逻辑规则来编码解决，同时，仅靠枚举所有可能性来处理，也会显得极为繁琐且易于遗漏。绝大多数情况下，我们的代码逻辑都是确定的，是'if this then that'的结构，或者是通过switch case枚举能搞定的，这类问题其实不需要LLM。

2. 闭合问题：这类问题具有清晰的定义，其输入和输出都是有确定答案的，不同于开放式的、发散性的对话（chat）。

我们之所以选择这类问题，主要是因为业务需求的驱动。业务系统中有不少此类问题，之前解决的都不是特别好。要么是分类遗漏、不准确，要么需要人工介入做兜底判断，难以完全自动化。我们希望引入AI agent来提升效率和准确度。同时，在实测过程中我们也发现，尽管目前的AI语言模型，如OpenAI（OAI）等，在技术和产品化方面取得了显著进展，但在实际工程应用和成本效益分析方面，我们仍然面临许多挑战，比如响应时间、使用限制、以及token的成本等。相比之下，这类问题受目前的限制影响最小。

实操中，我们选取了车辆风险定价的匹配问题，作为第一个应用agent来解决的业务问题。先简单介绍下业务背景和问题背景：我们在美国运营了一个车损互助平台（Good Driver Mutuality，GDM），用互助服务替代传统车险中collision and comprehensive的部分。因此，我们需要对每位用户及其车辆进行风险评估，以决定他们是否可以加入，以及他们加入时需要“支付的价格”（实际上是预存一笔互助金，但简单起见就理解为价格好了）。显然，这个风险定价与车辆的型号密切相关。市场上已有成熟的精算方法和价格引擎来评估车辆的风险定价。在实际的业务操作中，用户在加入流程中输入车辆的VIN码，我们的后端通过调用API服务对VIN进行解码和信息查询，从而获得这台车辆的品牌、型号、年份等信息，进而输入到价格引擎中以获得基于车辆的风险成本。

尽管原理看起来简单，实际操作中却发现有许多“例外情况”：

• 首先，考虑到美国汽车市场的发展历史，市场上存在大量不同年代的车型，每个车型还有其独特的make、model、type等属性，且VIN码的编码在几十年前并不像现在这样标准化。

• 其次，不同的精算模型和价格引擎的命名规则并不完全相同，导致同一款车型在不同数据库中的表示方式可能有所不同。比如同一台车，可能在一家的数据库中是Audi / A4 / 2.0T / 2013 / quattro /  sportback，另一家中，就成了Audi / A4 / 2.0_TFSI / 2013 / quattro_sp ，这里用“/”表示了数据库中的不同字段。如图所示，在不同的引擎中，数据库的记录方式绝大部分是匹配的，但都有自己的编码方式。这在定价场景中尤为关键，因为即使是外观和年份相同的车辆，微小的差异，比如变速箱类型，也可能导致风险成本的显著差异。

在实践中，我们选择车辆风险定价的匹配问题作为AI代理首次尝试解决的业务问题。面对众多的挑战，如不同年代车型的多样性、VIN码的非标准化以及不同价格引擎之间的命名不一致等，我们发现传统的解决方案往往不尽人意。例如，通过最常见的VIN码解析服务（如NHTSA或Carfax）解析出的信息，可能与任何一个报价引擎都不完全一致，有时甚至在报价引擎中找不到相应的数据记录。这时候，一般的做法是流转到人工，由有经验的专家来找到一个与之最为近似的车型，在不同的定价引擎中取一个合理的值。这些挑战让自动化处理变得困难，尤其是当新车型上市或某款车型极为罕见时。

我们之前的解决方案往往停留在大方向的匹配上，最终会出现需要从多个候选车型中选择一个的情况（通常是3-5个选项）。虽然我们采用了一些模糊匹配的处理方法，但仍然难以精确锁定到一个特定的车型。为了在实际业务中能够即时向用户提供报价，我们最终选择了一个折中方案——选择候选车型中价格位于中等水平的车型。这种方法在精确度上做了妥协，换取在大多数场景下实时地提供出一个“不那么坏的”报价。然而，即使如此，仍然存在一些情况下，基于规则的匹配方法完全无法找到匹配的车型，即所谓的N=0情况。例如，一个典型的困难案例是，某个价格引擎将特斯拉Model 3的某个版本简写为“tesla_3”，这种情况在未遇到之前几乎不可能预见并提前处理。

通过引入AI代理，我们希望能够提高匹配的灵活性和准确性，特别是在处理这些高度复杂和多变的数据匹配问题时。我们的目标是通过AI的学习和适应能力，逐步减少对人工干预的依赖，提升业务流程的自动化水平和效率。

通过以上的分析，我们认为这个问题很适合用AI agent来进行优化。主要因为：

1. 半确定性问题的理想解决方案：我们面临的挑战是典型的半确定性问题，通过已确定的规则和API服务，我们能迅速将问题简化为信息匹配任务。我们对结果有明确的要求：匹配到现有价格引擎中的特定记录，并以确定的JSON格式输出。在这种情况下，我们不会遇到大模型API用量限制和token超量带来的成本过高问题。

2. 清晰定义的闭合问题：AI agent需要处理的是一个确定且定义清楚的闭合问题。VIN匹配本质上是一个涉及多个NLP子任务的复杂1text match问题，而这也是LLM最擅长的领域之一。

3. 丰富的行业知识库：LLM的训练数据带来了基本无限广度的知识。我们实测发现，LLM对汽车行业的专有名词、术语及背景知识，特别是各种缩写，具有出色的理解能力。通过在指令和提示（instructions and prompt）中加入约束和原理性描述，AI agent的表现不亚于一位拥有多年汽车行业经验的业务专家。

4. 超越匹配的能力：结合联网浏览能力，AI agent不仅能完成匹配任务，还能解决如新车型难以及时匹配的问题。通过联网搜索和推理，agent能够找到与新车型风险成本最相近的历史车型，并给出最可靠的匹配结果。

5. 用户体验的考虑：这是用户加入流程中的一个小环节，用户对整个加入过程的时间预期较为宽松。因此，我们在代理的反馈时效上有更大的容忍度，这有利于我们接受当前大模型API的响应时间。考虑到当前token生成速度仍然较慢，对用户体验的影响还是挺大的，这一点尤为重要。

除了车型匹配问题，我们的业务场景中还存在许多类似的情况，基本都可以归类为匹配问题。因此，我们希望通过这个具体的产品功能，找到一个通用的产品和工程设计结构，快速将不同的agent部署到业务系统中的各个关键位置。在实施之前，我们总结了一些产品和工程实现上的期望：

1. 能够无缝嵌入到已有的业务流程的中间，即流程的上下游可以不感知AI agent；

2. 可插拔，能够方便的从原有系统逐渐过渡到有agent参与的流程，这样可以有兜底逻辑；

3. 具备所见即所得的agent调试后台，方便业务人员/产品经理迭代和测试agent的效果（类似于OAI的playground）；

4. 具备输入和输出的约束层，保证系统中的上下游模块不会受到带有agent的模块的干扰，让agent只在我们希望的领域内工作；

5. 能够很方便的升级agent的能力。目前各家LLM的发展非常快，我们希望在业务系统中服务的agent能很容易的升级能力。

带着这样的一些期望，我们给出了一个业务系统中加入AI agent模块的大致方案（如图所示），当然最后真实的工程实践要更复杂一些，但基本思路非常直接：

• Process A 和 B分别是业务系统中的上下游，在我们具体的实践中，这里的input是车辆的VIN码

• 在预处理(preprocessing)环节中，我们仍然需要像之前一样调用VIN的解析服务，得到解析出来的车辆信息，并利用已知的确定的匹配规则，筛选出报价引擎中匹配的备选记录。这一步，我们可以沿用之前使用过的规则匹配的逻辑。

• 构建prompt环节(prompt construction)，我们利用prompt engineering的一些技巧，将预处理中得到的信息和报价引擎中潜在的匹配目标等信息组装成最合适的prompt。这一步中，我们会在构建agent的时候，反复尝试各种prompt的效果，且会通过CoT+few shot等方法来提升效果。

• 在构建AI agent的时候，我们经过比较，选取了DIFY来托管我们的agent服务。DIFY能够同时提供多个LLM的api接入，有非常方便的playground功能，以及不错的knowledge base的管理功能，对于logs的管理和标注等工具也不错。能够让产品经理们所见即所得的调试和debug。DIFY还能直接生成可使用的API，与工程代码结合起来非常简单，很大幅度的帮我们的开发团队降低了做这样一个agent应用的难度

• 最后，我们加入了一个对输出结果进行约束的模块Output Validation，确保对下游Process没有影响。

在这个实际案例中，我们对agent的要求是根据合理推测和行业知识，帮我们从报价引擎的潜在匹配目标中找到最匹配的车型，且对于未出现过的车型，要从已有的车型库中选取风险匹配程度最高的。最终，输出端的约束是一个确定的匹配车型信息，用于在接下来的精算系统中使用。

在具体实现这个功能的时候，我们让产品经理、算法工程师和业务系统工程师同时推进，所以开发的很快，2周不到就把这个功能上线了。具体说来：

• 产品经理直接在DIFY上创建agent应用，并直接通过playground与agent交互，迭代prompt和instruction，并完善agent需要的knowledge base。这里的角色也可以是负责业务的同事来做，他的核心是通过自己对业务的了解，能大致判断出agent返回结果的好坏，判断这个问题是否能够被AI agent较好的解决。根据我们的实操经验，这一步的进展会非常快。基本上了解业务的人只要有基本对于AI和prompt的理解，都能很快的写出一个表现及格的agent。

• 业务系统的工程师，则在工程架构上对已有系统做调整和开发，将原有的流程升级成适配加入AI agent流程。这一步是传统的工程设计问题，具备一定设计能力的工程师也都可以较好的完成。

• 算法工程师一方面帮助产品经理评估agent能力，优化prompt。但更关键的，会在需要的节点加入annotation收集badcase，用来做后续的持续效果优化。这其中经典的data science套路，仍然是非常能够提升效果的。与业务专家一起看badcase，重新标注数据，清洗数据，搭baseline，反复实验，先通过人对该问题的理解，确定了一些比较好的规则，能比较准的把preprocessing的match结果确定在10条内，然后再用CoT引导大模型进行逐步思考，并给出例子（few shot），最终形成一套结果最优的prompt engineering。

再来说最关键的结果：总体说来，这个问题被agent解决的非常好。定量来看：

• 原来在纯粹的规则匹配且无人工介入的情况下，按照每次是从3-5个车型中随机选取1个来计算，我们基本可以认为准确率为20%~33%，再加上有时候因为匹配不上的情况，还需要适当下调这个匹配的准确率

• 在不做preprocessing的优化之前，只提供knowlesge，直接调用LLM通过RAG来给出匹配结果，选出来的结果由有经验的业务专家来判断其靠谱程度。这样下来提升的效果有限，准确的概率也只是在35%-40%间

• 通过preprocessing的优化，并将我们观测出来的一些经验和理解作为few shot放入prompt后，结果提升明显。我们选取了range match rate作为评判标准，也是由业务专家判断匹配的车型是否跟他的认知经验相符，而这个match rate 达到了97.8%！（我们测试了Carmax网站上的100多条VIN码）

这个提升和match rate还是让我们很开心的，确实是肉眼可见的大提升，也基本可以认为这个问题通过引入AI agent已经解决了。

在业务流程中引入AI agent时，除了后端的架构设计，也需要考虑前端产品的影响。在我们具体的实操案例中，我们认为这个过程不需要透露给用户，可以做无感知处理。而且，在绝大多数这样的闭合问题上，无感知处理都是最合理的。只要加入agent后不会显著的增加用户的等待时间，基本上前端无感知都是好的处理方法。

但如果加入agent的环节恰好会中断用户的正常流程，则需要在前端做相应的处理。例如，我们准备接下来会去解决的另一个问题，在用户加入流程中，让AI辅助判断用户是否满足加入条件。这种情况下，用户的流程会被中断，等待LLM的返回结果，这时候产品前端就需要做相应的提示。我们的观点是对于使用了AI agent的过程，还是应该明确告知用户，并充分利用LLM的理解和文字生成能力，在交互上对用户的告知做到比之前更加的简洁明了。这样用户的交互体验相对来说更好一些。当然，这只是我们的观点，关于如何在C端产品中更好的融入AI agent，已经有很多的讨论了，之后我们也会再写一遍关于如何设计to C的AI产品的分享。

自从ChatGPT惊艳亮相至今已有一年半的时间，这期间，Gen AI的发展可以用“日新月异”来形容，几乎每天都有新的进展。这不仅为科技行业带来了革命性的变化，也对我们这些从业者提出了极高的认知更新要求。我们的团队也在不断地学习和尝试最新的产品，探索大语言模型（LLM）的能力如何真正被融入到我们的业务中，并评估它们能带来的价值大小。我们的业务和商业模式中，应该以什么样的方式和顺序去结合AI的能力，才是商业上合理且可持续的。这期间有一些思考：

1. AI的辅助前提：AI的能力并不意味着能够解决那些我们自己还没想清楚的问题。如果对业务逻辑不够了解，寄希望于AI来解决问题是不现实的。例如有效利用AI来辅助编程的前提是，你自己必须是一个优秀的工程师，能够清晰地评估什么样的工作成果是优秀的，改进的方向在哪里，才能用prompt engineering、RAG、CoT等一系列技巧让AI解决问题。

2. 逐步应用AI：暂时还不能期待AI直接解决大问题。在我们的业务中，最有价值的当然是让AI直接解决用户出事故后的“定损理赔+服务流程”（实际上互助服务并不是理赔，但简单起见可以理解为类似流程）。业界也说了很多年AI定损，用户拍照拍视频就直接给出定损方案和估价，自动走后续的流程，把人工干预降到最低，能大幅降低adjustment expense且加快处理时效。这自然是非常好的故事，但现实中离的还比较远。

3. 从小处着手：对于业务中的小而复杂的问题，AI确实提供了不少可行的解决方案。从解决小问题入手，不仅可以实现效率的实质提升，还可以低成本、快反馈地探索AI对业务的具体贡献，积累经验，为更大范围的应用打下基础。这对于一个公司认识到AI能多大程度对自身业务产生促进，是非常有帮助的。客观的认知到AI的能力边界和局限性，同时切实的理解自己业务中的重要问题需要AI具备什么样的能力前提，都可以通过解决一个这样的“小问题”来积累很直观的认知。

4. 行业知识与AI的结合：我相信，很多行业知识、实践经验及问题尚未被LLM充分触及，许多数据和知识还未结构化。还有很多的low hanging fruits，在AI技术的帮助下，低成本实现效率提升的可能性大，这些都是短期内可能见到的趋势。

综上，就是我们最近将AI agent应用到业务能力优化的一次实操经验分享，感谢你的阅读。如果能对你有一点点的启发和帮助，我就很开心了，欢迎大家一起讨论。同时，如果你对我们在做的事情有兴趣，也欢迎联系我呀！