7分钟阅读，3小时前 -- 做得太多的代理我遇到了一个问题：作为一名AI实施顾问，我没有自动化管道来发现和筛选潜在客户并将其插入到我自托管的Twenty CRM实例中。我认为我可以使用LLM（大型语言模型）来解决这个问题。我潜在客户发现系统的第一个版本给了一个LLM代理完整的侦查管道：网络搜索、去重、验证和数据库插入。大约10%-20%的潜在客户是无关的、重复的或不正确地插入到CRM中的。更糟的是，系统极其难以调试，因为代理的每个实例采取不同的方法，并遇到自己的独特过程和工具速度障碍。我最终不得不亲自手动搜索CRM中800多个潜在客户的整个列表，检查重复项并验证潜在客户的相关性。显然，这个解决方案在现状下是行不通的。“我们在哪里可以使用AI？”是逆向的高管们似乎对以任何可能的形式实施AI着迷。我常常听说AI采纳进展是通过一些任意的指标衡量的，比如令牌使用量或编写的代码行数，而这些并不衡量AI是否以有益或有害的方式被使用。大型语言模型（LLM）基本上只是一个工具。如果你的首席执行官认为AI是一把锤子，并且她想用那把锤子做所有事情，那么一切看起来都像钉子。这种方法是错误的AI解决方案架构。目标不应该是说“我们是一个以AI为先的公司”或“我们的产品使用AI”。目标应该是使用合适的工具解决最紧迫和相关的问题。LLM是这些工具之一。第一个应该问的问题是“我们要解决什么问题？”，而不是“我们在哪里可以应用AI？”当待解决的问题确定后，只有这样才能具体指出解决方案。该解决方案需要什么能力？当前的解决方案（如果有）的失败在哪里？将LLM集成到该解决方案中是否真的必要？LLM交换确定性以换取灵活性软件开发工具箱中的每种工具都有其优缺点，而LLM也不例外。问题不在于LLM是否有用，而在于其能力是否可以证明其带来的权衡是合理的。LLM通过牺牲确定性提供灵活性。当所涉及的工作需要对自然语言进行解释、在丰富或多样化的信息中进行综合以及在无法提前指定过程规则的情况下进行逐步推理时，它们是有用的。这种灵活性的提升导致重复性和确定性的损失。LLM产生可变输出，即同一提示传递给同一模型两次将产生实质上不同的结果。这使得测试和失败分析比传统代码更困难，因为成功标准往往是主观的。此外，由LLM执行的过程通常比使用普通代码执行的相同工作流耗时更长且成本更高。这些限制意味着我们在盲目假设AI会有帮助之前，需要彻底评估解决方案中对AI的需求。在添加LLM之前的六个问题在评估LLM是否有用时，思考具体问题会很有帮助。实现解决方案的工作流是否可以完全并提前指定？如果是，你可能不需要LLM。以典型的CI/CD管道为例：代码被推送到远程，触发一个工作流，该工作流进行代码检查、运行代码测试并部署到开发环境。这个工作流可以在开始之前完全指定，并且每次以相同的方式运行。是否必须相同的输入产生相同的输出？LLM是非确定性的。如果你的工作流程需要在相同的输入下导致相同的输出，你可能想要考虑排除LLM。例如：一个支付系统接收到相同的发票、税务管辖区和重试请求两次。它必须计算出相同的总额，并避免对客户进行重复收费。解决方案是否需要在执行过程中解读模糊性？LLM在执行过程中擅长处理模糊性。如果文件未位于指定文件夹中，解决方案应该接下来在哪里查找？确定性规则可以在一定程度上处理模糊性，但传统的规则实施要求提前考虑解决方案的执行可能偏离理想路径的所有方式。请注意，这与“未执行的解决方案是否有一些模糊性？”不同。如果解决方案在执行开始前有可以解决的模糊性，请先解决它，然后再使用普通代码。解决方案的结果是否可以廉价且准确地验证？现在所有人都可以轻松感觉到代码，因为代码可以根据明确的标准进行廉价测试。如果所需功能存在，测试通过，服务器保持稳定，代码可以判断为可用。