构建专业AI应用的10个教训

LLM 正在各行各业得到应用。传统工程领域也不例外。

在过去的两年里，我一直与工程领域专家合作构建基于 LLM 的工具。这些工程师包括流程工程师、可靠性工程师、网络安全分析师等等，他们每天的大部分时间都花在日志、规范、原理图和报告上，执行故障排除、故障模式分析、测试计划、合规性检查等任务。

LLM（逻辑逻辑模型）的前景令人瞩目：凭借其丰富的预训练知识，理论上，LLM 可以像领域专家一样进行推理，加速工程工作中繁琐的模式匹配部分，从而让专家腾​​出时间进行更高层次的决策。

然而，实际情况却远非如此简单。“只需添加一个聊天框”很少能转化为实用的工程工具。令人印象深刻的演示与工程师真正信任和使用的系统之间仍然存在着巨大的鸿沟。

这完全取决于如何定义问题、如何构建工作流程以及如何将其集成到工程师的实际工作环境中。

在这篇文章中，我想分享我从过去的项目中总结出的 10 个经验教训。它们只是我的“现场笔记”，而不是一份全面的清单。但如果您也计划构建或正在构建面向领域专家的LLM应用程序，我希望这些经验教训能帮助您避免一些痛苦的死胡同。

我将这些经验教训分为三个阶段，这与典型的LLM项目阶段完全吻合：

• 开始之前：明确问题并设定合理的预期。
• 项目进行中：设计清晰的工作流程并在各个环节贯彻结构。
• 构建完成后：集成到工程师的工作环境中，并使用实际案例进行评估。

考虑到这些，让我们开始吧。

第一阶段：开始之前

在编写任何一行代码之前所做的一切，很大程度上决定了LLM项目的成败。

这意味着，如果您一开始就找错了问题，或者没有设定合理的预期，那么无论您的应用程序在技术上多么完善，它都很难在后期获得认可。

接下来，我想分享一些关于打好基础的经验教训。

教训1：并非所有问题都能或应该用机器学习模型 (LLM) 解决

每当我遇到工程师提出的新用例时，我都会努力挑战自己“优先使用 LLM”的固有思维，并认真地问自己：我能否在不使用 LLM 的情况下解决这个问题？

对于核心推理逻辑，也就是你想要自动化的决策瓶颈，通常至少有三类方法可供考虑：

• 基于规则和分析的方法
• 数据驱动的机器学习模型
• LLM

基于规则和分析的方法成本低、透明且易于测试。然而，它们可能不够灵活，在复杂的现实环境中能力有限。

经典的机器学习模型，即使是简单的回归或分类模型，通常也能提供快速、可靠且易于扩展的决策。但是，它们需要历史数据（通常还需要标签）来学习模式。

另一方面，如果核心挑战在于理解、综合或生成来自复杂数据制品的语言，那么 LLM 就大有可为。想象一下，你需要快速浏览 50 份事件报告，才能找到可能相关的报告；或者将自由文本日志转换为带标签的结构化事件。但是，机器学习模型 (LLM) 成本高昂、速度慢，而且通常无法像你期望的那样确定性地运行。

在决定使用 LLM 解决特定问题之前，请先问问自己：

• 80% 的问题能否用规则引擎、分析模型或传统模型解决？如果可以，那就从这些方法入手。如果需要，以后可以随时添加 LLM。
• 这项任务是否需要精确且可复现的数值结果？如果是，那么就将计算工作保留在分析代码或机器学习模型中，只将 LLM 用于解释或提供上下文信息。
• 是否没有人参与审核和批准输出结果？如果是，那么 LLM 可能不是一个好的选择，因为它很少能提供强有力的保证。

在我们预期的速度和数据量下，LLM 调用成本是否过高或速度是否过慢？如果您需要每分钟处理数千条日志或警报，仅依靠 LLM 很快就会在成本和延迟方面遇到瓶颈。

如果您的答案大多是“否”，那么您可能已经找到了一个值得探索 LLM 的合适案例。

教训2：从一开始就树立正确的思维模式

一旦我确信基于 LLM 的解决方案适合特定用例，下一步就是与相关人员建立正确的思维模式。领域专家。

我认为工具的定位至关重要。我通常采用一种在实践中非常有效的框架：我们的LLM工具的目标是增强而非自动化。LLM只是帮助您（即领域专家）更快地分析、更快地进行分类和探索，但您仍然是决策者。

这种区别非常重要。

当您将LLM工具定位为增强工具时，工程师往往会热情地使用它，因为他们认为它可以提高工作效率，减少繁琐的工作。

另一方面，如果他们感觉到新工具可能会威胁到他们的角色或自主权，他们就会疏远项目，并且对您提供的支持非常有限。

从开发人员（也就是你我）的角度来看，这种“增强而非取代”的心态也能降低焦虑。为什么？因为它让讨论错误变得容易得多！当LLM出错时（这种情况肯定会发生），对话不会简单地变成“你的AI失败了”，而是会变成“这个建议虽然不太准确，但仍然很有见地，给了我一些启发”。这是一种截然不同的动态。

下次当你为领域专家构建LLM应用时，请尝试强调以下几点：

• LLM充其量只是初级助手。它们速度很快，可以全天候工作，但并非总是正确。
• 专家才是审核者和最终决策者。你经验丰富、谨慎负责。

一旦这种思维模式建立起来，你会发现工程师们开始从“这能帮到我吗？”的角度来评估你的解决方案，而不是“这能取代我吗？”。这对于建立信任和提高采用率至关重要。

教训3：与专家共同设计并定义“更好”的含义

一旦我们达成共识，认为 LLM 适合当前任务，并且目标是增强而非自动化，接下来我要弄清楚的关键点是：

“对于这项任务而言，‘更好’究竟意味着什么？”

为了真正理解这一点，你需要尽早让领域专家参与到设计流程中来。

具体来说，你应该花时间与领域专家坐下来，了解他们目前是如何解决问题的，并记录他们使用的工具以及参考的文档/规范。记住要请他们指出真正的痛点在哪里，并更好地理解哪些可以接受“近似”的方案，以及哪些类型的错误是令人恼火或不可接受的。

与领域专家进行这些对话的一个具体成果是，用他们自己的语言对“更好”达成共识。这些是你要优化的指标，例如节省的分类处理时间、减少的虚假线索数量或省略的人工步骤数量。

一旦定义了这些指标，你就能自动获得一个实际的基准线（即当前人工流程所需的时间），以便后续评估你的解决方案。

除了技术层面的影响，我认为心理层面的影响也同样重要：通过尽早让专家参与进来，你向他们表明你真心实意地想要了解他们的工作方式。仅此一点就足以赢得信任。

第二阶段：项目实施期间

一切准备就绪后，你就可以开始构建了。真是令人兴奋！

根据我的经验，你需要做出一些重要的决定，以确保你的努力能够真正赢得信任并被采纳。让我们来谈谈这些决策点。

教训4：是辅助驾驶，而非自动驾驶

我经常看到（我自己也一样）人们渴望构建“完全自主”的系统。作为一名数据科学家，谁能抵挡住构建一个只需按一下按钮就能为用户提供最终答案的人工智能系统的诱惑呢？

然而，现实情况远没有那么光鲜亮丽，却也更加有效。在实践中，这种“自动驾驶”思维很少能与领域专家有效沟通，因为它从根本上违背了工程师习惯于理解系统逻辑和故障模式的现实。

如果你的LLM应用程序只是在后台运行所有程序，然后只显示最终结果，通常会发生两种情况：

• 工程师不信任结果，因为他们看不到结果是如何得出的。
• 即使他们发现明显的错误，也无法纠正。

因此，我更倾向于在系统中设置多个控制点，让专家能够影响LLM的行为，而不是默认采用“自动驾驶”模式。例如，与其让 LLM 自动对所有 500 个告警进行分类并创建工单，我们可以设计一个系统，先将告警分组为 5 个候选事件线程，然后暂停，向专家展示分组依据和每个线程的关键日志行。之后，专家可以合并或拆分分组。专家批准分组后，LLM 即可生成工单草稿。

是的，从用户界面角度来看，这确实增加了一些工作，因为您需要实现人工输入机制，清晰地展示中间推理过程和结果等等。但回报是实实在在的：您的专家团队将受益匪浅。他们会真正信任并使用你的系统，因为它让他们感觉自己能够掌控一切。

教训5：在选择框架之前，先关注工作流程、角色和数据流

一旦进入实施阶段，许多开发者（包括我以前也是）首先会问的一个常见问题是：

“我应该使用哪个LLM应用框架？LangGraph？CrewAI？AutoGen？还是其他什么？”

这种直觉完全可以理解。毕竟，市面上有那么多漂亮的框架，选择“正确”的框架似乎是第一个重大决定。但是，对于与工程领域专家一起进行原型设计来说，我认为这通常不是正确的起点。

以我的经验来看，对于第一个版本，你可以使用经典的from openai import OpenAI或from google import genai（或者你喜欢的任何其他LLM提供商）来构建。

为什么？因为现阶段最紧迫的问题不是选择哪个框架，而是：

“LLM（逻辑逻辑模型）真的能帮助完成这个特定领域的任务吗？”

而且你需要尽快验证这一点。

为此，我想重点关注三个支柱，而不是框架：

• 流水线设计：我们如何将问题分解成清晰的步骤？
• 角色设计：我们应该如何指示 LLM 在每个步骤中的行为？
• 数据流和上下文设计：每个步骤的输入和输出是什么？

如果你将每次 LLM 调用都视为一个纯函数，例如：

输入 → LLM 推理 → 输出

那么，你可以使用常规的控制流将这些“函数”连接起来，例如 if/else 条件语句、for/while 循环、重试等，这些对于你作为开发人员来说已经很自然了。

这同样适用于工具调用。如果 LLM 决定需要调用某个工具，它可以简单地输出函数名和相关参数，然后你的常规代码就可以执行该函数并将结果反馈到下一次 LLM 调用中。

你真的不需要框架来表达管道。

当然，我并不是说你应该避免使用框架。它们在生产环境中非常有用，因为它们开箱即用地提供了可观测性、并发性、状态管理等功能。但在早期阶段，我认为保持简单是一个好策略，这样你就可以与领域专家更快地迭代。

一旦你与专家验证了关键假设，将你的管道/角色/数据设计迁移到更适合生产环境的框架就不会那么困难了。

在我看来，这就是精益开发的实践。

教训6：在尝试代理之前先试试工作流

最近，关于工作流和代理的讨论很多。该领域的每一家主要厂商似乎都急于强调他们是在“构建智能体”，而不是仅仅“运行预定义的工作流程”。

作为开发者，我们很容易受到这种诱惑：

“没错，我们当然应该构建能够自主解决问题的智能体，对吧？”

不。

从理论上讲，人工智能智能体听起来极具吸引力。但在实践中，尤其是在工程领域，我认为精心设计的、具有领域特定逻辑的工作流程已经可以解决很大一部分实际问题。

关键在于：它能显著降低随机性。

在大多数情况下，工程师已经遵循一定的工作流程来解决特定问题。与其让LLM智能体“重新发现”该工作流程，不如将这些“领域知识”直接转化为确定性的、分阶段的工作流程。这样做能立即带来以下几个好处：

• 工作流更容易调试。如果系统开始出现异常行为，您可以轻松找到导致问题的步骤。
• 领域专家可以轻松理解你正在构建的东西，因为工作流自然地映射到他们的思维模型中。
• 工作流自然而然地会吸引人类的反馈。它们可以轻松暂停、接受新的输入，然后恢复运行。
• 你会获得更加一致的行为。相同的输入会导致相似的路径或结果，这在工程问题解决中至关重要。

再次强调，我并不是说人工智能代理毫无用处。当然，在很多情况下，更灵活、更像代理的行为是合理的。但我建议始终从一个清晰、确定性的工作流开始，明确地编码领域知识，并与专家验证它是否真的有用。如果遇到简单工作流无法解决的限制，你可以引入更多代理行为。

是的，这听起来可能很枯燥。但你的最终目标是以一种可预测、可解释的方式解决问题，从而创造业务价值，而不是一些花哨的代理演示。始终牢记这一点很重要。

教训7：尽可能地构建结构——输入、输出和知识

人们普遍认为学习逻辑模型（LLM）擅长处理自由格式的文本。因此，人们自然而然地会想：我们只需输入报告和日志，然后让模型进行推理，对吗？

不对。

以我的经验来看，尤其是在工程领域，这样做会大大降低模型的性能。事实上，LLM 的表现往往……当你提供结构化的输入并要求它们生成结构化的输出时，效果会更好。

工程工件通常已经是半结构化的形式。与其将整个原始文档直接导入提示符，我发现先提取并结构化关键信息非常有用。例如，对于自由文本的事件报告，我们可以将其解析为以下 JSON：

{
  "incident_id": "...",
  "equipment": "...",
  "symptoms": ["..."],
  "start_time": "...",
  "end_time": "...",
  "suspected_causes": ["..."],
  "mitigations": ["..."]
}

这个结构化步骤可以通过多种方式完成：我们可以使用经典的正则表达式，或者开发一些辅助脚本。我们甚至可以使用一个独立的逻辑逻辑模型（LLM），其唯一任务就是将自由文本规范化为一致的模式。

这样，你就可以为主要的推理逻辑逻辑模型提供一个清晰的事件视图。此外，有了这种结构，你就可以要求LLM在得出结论时引用具体事实，这能节省大量的调试时间。

如果你正在使用RAG方法，也应该从这个结构化的层级检索数据，而不是原始的PDF或日志。从干净的结构化工件中检索数据，可以获得更高的精度和更可靠的引用。

现在，在输出方面，如果你想将LLM集成到更大的工作流程中，结构化几乎是必需的。具体来说，这意味着与其问：

“解释一下发生了什么以及我们接下来应该做什么。”

我更倾向于这样问：

“请用你的分析结果填写这个JSON模式。”

{
  "likely_causes": [
    {"name": "...", "confidence": "low|medium|high", "evidence_ids": ["..."] }
  ],
  "recommended_next_steps": [
    {"description": "...", "priority": 1}
  ],
  "summary": "short free-text summary for the human"
}

通常，这被定义为一个 Pydantic 模型，您可以利用“结构化输出”功能来明确指示 LLM 生成符合该模型的输出。

我过去常常把 LLM 看作是“文本输入，文本输出”。但现在我更倾向于把它看作是“结构输入，结构输出”，这在需要精确性和鲁棒性的工程领域尤其如此。

教训8：不要忘记分析型 AI

我知道我们正在构建基于 LLM 的解决方案。但正如我们在第一课中所学到的，LLM并非你唯一的工具。我们还有“传统”的分析型AI模型。

在许多工程领域，应用经典的分析型AI/ML方法来解决各种问题（例如异常检测、时间序列预测、聚类、分类等等）有着悠久的历史。

这些方法仍然非常有价值，在很多情况下，它们应该承担繁重的工作，而不是被弃用。

为了有效地解决当前问题，很多时候值得考虑采用分析型AI+GenAI的混合方法：使用分析型ML来处理模式匹配和检测等繁重的工作，而LLM则在其基础上进行推理、解释并推荐后续步骤。

例如，假设你每周有数千起事件。你可以先使用经典的聚类算法将相似的事件分组，并计算每个聚类的一些汇总统计数据。然后，工作流程可以将这些聚类分析结果输入到逻辑逻辑模型 (LLM) 中，并要求其标记每个模式，描述其含义，并建议首先检查哪些内容。之后，工程师会审查并完善这些标签。

那么，这为什么重要呢？因为分析方法能够提供结构化数据的速度、可靠性和精确性。它们具有确定性，可以扩展到数百万个数据点，而且不会产生虚假信息。另一方面，LLM 的优势在于综合、上下文和沟通。您应该根据各自的优势来使用它们。

第三阶段：构建之后

您已经构建了一个技术上可行的系统。现在到了最难的部分：如何让它被广泛采用。无论您的实现多么巧妙，一个被束之高阁的工具都毫无价值。

在本节中，我想分享关于集成和评估的最后两个经验教训。您希望确保您的系统能够真正落地应用，并通过实际案例赢得信任，对吗？

教训9：整合到工程师实际工作环境中

一个独立的用户界面，例如简单的网页应用或笔记本，对于探索和获取第一手反馈来说完全没问题。但要想真正推广应用，你应该跳出应用的功能本身，关注应用在工程师的工作流程中出现的位置。

工程师们每天都依赖一系列工具。如果你的LLM工具只是“又一个带有登录和聊天框的网页应用”，那么它很难融入工程师的日常工作流程。人们可能会尝试一两次，但当工作繁忙时，他们就会回到自己习惯的工具。

那么，如何解决这个问题呢？

此时，我会问自己这样一个问题：

“在现有的工作流程中，这个应用会在哪个环节实际使用？它在那里会是什么样子？”

在公关方面实践，这意味着什么？

最强大的集成方式通常是用户界面级别的嵌入。这基本上意味着将 LLM 功能直接嵌入到工程师已使用的工具中。例如，在标准的日志查看器中，除了常见的仪表盘图表之外，还可以添加一个侧边栏，其中包含“汇总所选事件”或“建议后续诊断步骤”等按钮。这样，工程师就能在不中断其日常工作流程的情况下，利用 LLM 的智能功能。

不过，需要注意一点：用户界面级别的嵌入通常需要工具所属团队的支持。如果可能，请尽早建立这种关系。

然后，与其使用通用的聊天窗口，我建议使用带有具体动词的按钮，这些动词应与工程师思考任务的方式相匹配，例如汇总、分组、解释或比较。如果工程师有后续问题、需要澄清，或者希望在 LLM 生成初始输出后输入自由形式的反馈，仍然可以保留聊天界面（或类似界面）。但此处的主要交互应该是针对特定任务的操作，而不是开放式的对话。

同样重要的是：您应该使 LLM 的上下文动态化和自适应。如果系统已经知道专家正在查看哪个事件或时间窗口，请将该上下文直接传递给 LLM 调用。不要让他们将 ID、日志或描述复制粘贴到另一个用户界面中。

如果这种集成做得好，尝试（并最终采用）它的门槛就会大大降低。而对于您作为开发人员来说，由于它是在真实条件下测试的，因此更容易获得更丰富、更真实的反馈。

教训10：评估、评估、再评估

发布第一个版本后，您可能会认为工作已经完成。但实际上，这恰恰是真正工作的开始。

这是评估的开始。

我想在这里讨论两点：

• 让系统以工程师可以检查的方式展示其工作。
• 与专家坐下来，一起分析实际案例。

让我们依次讨论它们。

首先，要让系统展示其工作过程。我说的“展示工作过程”并非仅仅指最终结果。我希望系统能够以合理的详细程度，展现三个具体方面：它查看了哪些内容、采取了哪些步骤，以及LLM（逻辑逻辑模型）的置信度如何。

• 查看了哪些内容：这本质上就是LLM所使用的证据。最佳实践是始终指示LLM在得出结论或建议时引用具体证据。这些证据可以是具体的日志行、具体的事件ID，或是支持该论断的规范章节。还记得我们在第七课中讨论的结构化输入吗？这对于LLM的引用管理和验证非常有用。
• 采取了哪些步骤：这指的是LLM生成的推理过程。在这里，我会展示流程中关键中间步骤的输出。如果您采用的是多步骤工作流程（第五课和第六课），那么这些步骤应该已经作为单独的LLM调用或函数存在。如果您强制执行结构化输出，那么在用户界面上呈现这些输出就变得轻而易举。
• LLM 的置信度：最后，我几乎总是要求 LLM 输出一个置信度等级（低/中/高），并简要说明分配该置信度等级的原因。实际上，您会得到类似这样的结果：“LLM 基于 B 和 C 得出 A 的结论，置信度为中等，因为存在 D 和 E 假设。” 工程师们更容易接受这种表述，而这再次证明，这是建立信任的关键一步。

现在，我们来看第二点：使用真实案例与专家进行评估。

我的建议是，一旦系统能够正确展示其工作过程，就应该安排与领域专家进行专门的评估会议。

这就像进行用户测试。

典型的会议流程如下：您和专家选择一组真实案例。这些案例可以包含典型案例、边缘案例以及一些已知结果的历史案例。你们一起将这些案例输入到工具中运行。在此过程中，请专家边思考边说：您期望该工具在此处做什么？此总结是否准确？这些建议的后续步骤是否合理？您是否同意所引用的证据确实支持结论？同时，请务必详细记录工具在哪些方面明显节省了时间、在哪些方面仍然存在不足，以及目前缺少哪些重要的背景信息。

与专家进行几次讨论后，您可以将结果与我们之前定义的“更好”（第三课）联系起来。这不必是“正式”的定量评估，但相信我，即使是一些具体的前后对比也能让人眼前一亮，并为您持续迭代解决方案奠定坚实的基础。

4、结束语

现在，回顾这十条经验教训，您发现了哪些反复出现的主题？

以下是我的发现：

首先，尊重领域专家的专业知识。从领域工程师的实际工作方式出发，真正了解他们的痛点和需求。将您的工具视为辅助工具，而不是取代他们。始终让专家掌控全局。

其次，构建系统。从简单的 SDK 调用、确定性工作流程、结构化输入/输出入手，如果合适，可以将传统分析方法与 LLM 相结合。记住，LLM 只是一个更大系统中的组件，而不是完整的解决方案。

第三，将部署视为开始，而非结束。交付第一个可用版本的那一刻，您才能真正开始与专家进行有意义的对话。一起分析实际案例，收集他们的反馈，并不断迭代。

当然，这些经验只是我目前在为工程师构建 LLM 应用时的一些心得体会，并非唯一的方法。不过，它们对我帮助很大，我希望它们也能为您带来一些启发。

原文链接：Ten Lessons of Building LLM Applications for Engineers

汇智网翻译整理，转载请标明出处