在添加LLM之前要问的六个问题

# 你到底应不应该使用大语言模型？ 来源：https://cameronmpalmer.medium.com/should-you-even-use-an-llm-b4f3b7914f4d 作者：Cameron Palmer (https://cameronmpalmer.medium.com/?source=post_page---byline--b4f3b7914f4d---------------------------------------) ## 那个做得太多的智能体 我遇到一个问题：作为一名AI落地顾问，我没有任何自动化管道来发现和筛选潜在客户，并将其录入到自托管的Twenty CRM实例中。当时我想，这个问题完全可以用大语言模型来解决。 我的潜在客户发现系统的第一个版本，把整个搜索流程都交给了一个LLM智能体：网页搜索、去重、验证以及数据库录入。结果大约10%–20%的潜在客户要么不相关、重复，要么没有被正确录入CRM。更糟糕的是，这个系统极难调试，因为每个智能体实例都采取不同的方式，并且各自遇到独特的流程和工具瓶颈。最后我不得不手动搜索CRM中800多个潜在客户的完整列表，逐一检查重复项并验证其相关性。显然，这个方案不能原样用下去。 ## “哪里能用AI？”这个思路是反的 高管们似乎痴迷于以任何可能的形式部署AI。我经常听到AI采用进展用一些随意指标衡量，比如token用量或生成的代码行数，这些根本不能判断AI的使用是有益还是有害。大语言模型本质上只是一个工具。如果你的CEO认为AI是一把锤子，并且想用它来敲打一切，那么所有东西看起来都像个钉子。这种AI架构思路是错误的。 目标不应该是说“我们是AI优先的公司”或“我们的产品使用了AI”。目标应该是用合适的工具解决最紧迫、最相关的问题。LLM是这些工具之一。首先应该问的是“我们在解决什么问题？”，而不是“哪里可以用AI？”当需要解决的问题确定后，才能确定方案。方案需要什么能力？现有方案（如果有）哪里失败了？将LLM集成到那个方案中是否真的必要？ ## LLM用确定性换取灵活性 软件开发工具箱里的每种工具都有优点和缺点，LLM也不例外。问题不在于LLM是否有用，而在于这些能力是否值得它们带来的权衡。LLM通过牺牲确定性来提供灵活性。当工作涉及自然语言解释、从丰富或多样的信息中整合、以及无法在开始时完全指定规则的逐步推理时，它们就很有用。 灵活性的提升导致可重复性和确定性的损失。LLM产生可变的输出——也就是说，对同一模型给予相同的提示两次，会产生明显不同的结果。这使得测试和失败分析比传统代码困难得多，因为成功标准往往是主观的。此外，由LLM执行的过程通常比用普通代码执行同一工作流花费更多时间且成本更高。这些局限性意味着在我们盲目假设AI会有帮助之前，需要彻底评估在方案中对AI的需求。 ## 在加入LLM之前问六个问题 在评估LLM是否有用时，通过具体问题来思考决策会很有帮助。 1. **实现方案的工作流程能否完全且提前指定？** 如果可以，你可能就不需要LLM。例如，典型的CI/CD流水线：代码被推送到远程，触发一个工作流进行lint检查、运行代码测试并部署到开发环境。这个工作流可以在开始前完全指定，并且每次都以相同方式运行。 2. **相同的输入是否必须产生相同的输出？** LLM是不确定的。如果你工作流需要在相同输入下得到相同输出，你可能要考虑排除LLM。例如：支付系统两次收到相同的发票、税区和重试请求。它必须计算出相同的总额，并避免向客户重复收费。 3. **方案是否需要在执行过程中解释出现的模糊性？** LLM在处理执行中的模糊性方面表现出色。如果文件不在指定文件夹中，方案下一步应该去哪里找？确定性规则可以在一定程度上处理模糊性，但传统规则实现需要提前思考方案执行可能偏离理想路径的所有方式。注意，这与“未执行的方案是否有一些模糊性”不同。如果方案的模糊性可以在执行开始前解决，那就先解决模糊性，然后用普通代码。 4. **方案的结果能否以低成本且准确地验证？** 现在人人都能“vibe coding”，因为代码可以用明确的标准低成本测试。如果所需功能存在、测试通过、服务器保持稳定，代码大概就可以认为是可用的。另一方面，验证医学诊断结果是否安全推荐给患者，既费时又需要专门的专业知识。通常，结果需要大量工作和/或特殊人类专业知识来验证（例如“这个法律建议正确吗？”）或者验证时间紧迫（例如“这个商业策略会成功吗？”）的情况，往往不适合使用LLM。 5. **当输出错误时会发生什么？** “当”不是“如果”。系统会失败，我们必须为此做好准备。当方案输出错误时，后果有多严重？后果是否可以缓解？一个错误地给客户15美元折扣的方案，风险远低于一个错误地给客户5000美元折扣的方案。错误的输出可以通过让方案远离后果发生点来缓解：考虑一个聊天机器人向人工支持代理建议他们应该提供什么折扣，而不是一个直接向客户提供折扣的机器人。 6. **基于LLM的方案是否显著优于更简单的替代方案？** 我推荐采用KISS方法（保持简单，笨蛋）——如果有一个基于代码的替代方案能达到基于LLM方案质量的95%（错误率、人工干预次数、成本等），那就选择基于代码的方案。 点击或按回车查看全尺寸图片 ## 将框架应用于我的潜在客户发现系统 在我的潜在客户发现系统中，我最初让LLM执行整个发现流程：搜索、去重、验证和数据库插入。模型会生成搜索查询，用MCP网页搜索工具执行查询，将返回的潜在客户与数据库中现有的进行去重，根据我的理想客户描述验证潜在客户，然后将幸存名单写入CRM。因为步骤太多，它经常出错。 让我们用这个例子来思考上一节列出的问题。 1. 工作流能否提前指定？可以——我们刚刚完整地描述了整个工作流。 2. 相同的输入必须产生相同的输出吗？是的。如果一个潜在客户文件在一次运行中有效，那么在下一次运行中也应该有效。 3. 方案是否需要解释执行过程中出现的模糊性？是的——但不是所有步骤都需要。生成查询需要解释CRM中已经存在的潜在客户类型，并编写能填补缺口的查询。但其他步骤没有模糊性：通过Decodo搜索执行查询、将结果与现有条目去重、然后插入CRM数据库。 4. 方案的结果能否以低成本且准确地验证？可以——我可以通过阅读名称、公司和职位头衔，在十秒或更短的时间内验证数据库中的潜在客户是否符合我的理想客户描述。 5. 当输出错误时会发生什么？就我的情况而言，没有人会死掉或损失大量金钱。也许我不小心向一个潜在客户发送了两次消息，或者向一个无效的潜在客户发送了消息，这都可以纠正。 6. 基于LLM的方案是否显著优于更简单的替代方案？是的——替代方案是：我自己想出查询，将它们传给一个去重搜索脚本，手动根据理想客户描述验证潜在客户，并标记最有希望的用于插入。或者我实现某种确定性的查询生成缺口填补系统和一种拙劣的基于正则表达式的关键词匹配验证系统——这两种方法都不会很有效，也不会节省时间。 ## 在模糊性存在的地方使用LLM 是否使用LLM的决策并不简单。必须做出权衡：灵活性 vs 确定性，适应性 vs 准确性，成本 vs 性能。即使在相对简单的潜在客户发现系统中，验证问题的答案也不总是明确的“是”或“否”。我发现这通常是常态：通常包含LLM的方案也同时包含确定性验证和流程自动化代码。最好的方案结合了LLM的优势和确定性代码的优势——这不是一个非此即彼的决策。 尽管许多问题可以用确定性方案解决，并且添加大语言模型并不会带来好处，但我们生活在一个许多以前无法用计算机解决的问题现在可以解决的时代。这些方案不需要你的工程师每天花数百美元在token上——它们需要你的团队评估手头的问题，并决定为正确的工作使用正确的工具。 你在哪里用确定性代码替换了LLM，从而改进了你的系统，这种替换又引入了哪些新的权衡？