教训一：永远不要低估项目的复杂性。

我在开始这个项目之前就犯了最大的错误……

我低估了这个项目的复杂性！

我期待一个快速而简单的项目。

看起来很简单……计划如下：

1. 构建一个具有 3 个输入和 1 个按钮的简单工具。
2. 在后台使用 GPT-4 处理输入。
3. 用更多背景信息来扩展提示。
4. 解释一下 GPT-4 以及你期望什么样的分析。
5. 全部发送给 GPT-4 并等待响应。
6. 向用户显示响应。
7. 瞧！完成了！

“我绝对可以在 4 周甚至更短的时间内建造出它！”我想。

我错了吗？

结果是：

• 输入的文本很嘈杂而且很脏，所以我必须在将其传递给 LLM 之前清理它。
• 每个用例都是独一无二的，因此在提示中写出清晰而具体的说明很困难。
• 在最初的分析回应中，GPT-4 犯了很多错误。
• 提示增长迅速，需要许多先进的技术才能正常工作。
• 我必须添加另外 2 个模型来处理输入，然后才能将它们传递给模型进行分析。所以我最终得到了 3 个模型。

所以这个项目在很多方面都让我感到惊讶。

而每一次惊喜对于我来说都意味着更多的工作（和复杂性）。

第 2 课：很难估计任务持续时间。

当你的工作是交付一个项目时，你会遇到许多以“什么时候？”和“多长时间？”开头的问题。

当你做某件事已经做过很多次的时候，估计任务持续时间就很容易了。

但在我的项目中，这变得很棘手，因为：

• 很多任务都是我第一次做。
• 我不知道如何评估测试。
• 我经常需要改进提示，这需要未知次数的迭代。

而我则是低估之王……

当人们问我“多久？”时，我会给出最乐观的猜测。而我需要努力改变这种状况。

在人工智能工程中，大多数项目都是新颖的。

作为一名 AI 工程师，我在做项目的过程中学到了很多东西。大多数项目任务都是我第一次或第二次做。

我如何估计何时能完成一件我以前没有做过的事？

我不能！

但我会开始给出悲观的估计。

教训3：团队中的良好沟通至关重要。

避免艰难的谈话是一个坏主意。

当一切按预期进行时，沟通就变得容易。

当事情破裂时，沟通很困难。

我重视良好的沟通。我学会了在遇到困难时如何开诚布公地交谈。这对我的私人生活和工作生活都很重要。

但我有一个问题……

当事情因为我而出错时，我会感到沮丧。然后：

• 我开始责怪自己。
• 我尝试自己处理。
• 我尽力改正自己的错误。
• 我开始回避别人。

这完全是错的！这和我应该做的完全相反！

在我的项目中，一切都没有按预期进行。从前两节课中你就知道了：

• 我低估了这个项目的复杂性。
• 我低估了任务持续时间。

所以我当然开始责怪自己……

在与产品经理和项目经理的日常会议中，我并不清楚进展和问题。

双方的挫败感也与日俱增。

然后，最糟糕的事情发生了……

他们不再相信我的技能和专业知识。

他们认为我是个初学者，没有足够的资格来完成这个项目。

我看到了。

如果我进行了一些艰难的谈话，我本可以避免这种情况。

直到上周，我们才公开交谈。

太棒了！但显然太晚了。

良好的沟通并不能解决您在项目本身中遇到的挑战和困难。

但它会帮助你减轻压力和头痛。

教训4：客户的AI素养太低。

人们不知道什么是人工智能。

每个人对人工智能都有不同的看法。大多数人对人工智能的工作原理都知之甚少。所以他们的想象力填补了空白。

我工作过的客户说：“我们有一个有趣的用例。我们将看看人工智能如何处理它。”

那一刻我想：“他们不明白……”

人工智能并不擅长处理独特而有趣的用例。

人工智能擅长处理无聊、重复、明确的任务。

客户没有理解 LLM 的明显局限性：LLM 并不是在使用过程中进行学习。

每次他们使用该模型时，它都与实施期间处于同一阶段。

我们将其分为两部分：

1. 训练——这是我们“准备”模型与人类互动的时候。
2. 推理——这是实际的交互。

客户相信，他们使用人工智能的次数越多，人工智能就会越好。

对人工智能的误解会导致乐观且往往不切实际的期望。

对人工智能的误解可能导致乐观而不切实际的期望。

尽早讨论人工智能的能力和局限性至关重要。

通过让客户更加了解“人工智能”，我们​​帮助他们：

• 更深入地了解人工智能。
• 创造更多利用人工智能的想法（更多潜在项目）。
• 调整他们的期望以适应人工智能的现状。
• 将人工智能融入他们的工作场所。

了解人工智能的能力非常重要。

但了解它的局限性更重要:)

第 5 课：UI/UX 比我想象的更重要。

在项目期间，我主要关注技术、人工智能方面。

创建 LLM 提示很有挑战性。GPT-4 无法准确返回客户期望的内容。改进响应花了我很多天的时间。

这是一个漫长而又令人沮丧的过程。

当LLM终于传出好成绩的时候，我迫不及待的想和团队分享。

我很兴奋，向他们展示了进展……

但他们并不以为意！

第二天，我明白了为什么……

在那之前，我一开始只使用一个简单、粗糙的 UI。我呈现的结果看起来很糟糕。我的团队看不到进展。

我花了第二天的时间来改造 UI。

当我在新的 UI 中显示相同的结果时，他们的反应发生了变化。

他们顿时高兴起来，印象深刻。

以下是惨痛的教训（因为我讨厌设计部分）：

即使你已经完成了出色的工作，你呈现它的方式也会有很大的不同。

第六课：快速工程并未消亡。

他们说：“Prompt Engineering 已死。”

许多人预测 Prompt Engineering 即将“消亡”，因为 LLM 会为我们写提示。

但 Prompt Engineering 不会很快实现自动化，原因有三：

1. 快速工程是一项技能，而非一项简单的任务。
2. 编写出色的提示是一个需要大量测试和改进的过程。
3. LLM 的输出是不确定的。这意味着除非你测试过，否则你不知道结果是什么。

简而言之：

↳ 编写初始提示只是开始。↳
很难找到有效的提示。↳
提示工程是一个过程。↳
它需要大量的反复试验。

客户有特定要求。

所以你需要不断完善提示直到得到他们想要的东西。

在我的项目中，快速工程是最具挑战性的部分：

• 提示很长，包括很多规则和限制。
• 该提示还收到了非常长的上下文。
• 该模型从多个来源接收信息。组织这些信息并分离每个部分至关重要。
• 答复的准确性对于客户来说至关重要。
• 该模型需要大量的推理，但降低温度还不够。
• 有些上下文源包含很多噪音，所以需要清理。我通过添加另一个模型解决了这个问题。
• 经过几十次迭代才找到有效的提示。

由于这些细微差别和要求，实现自动化非常困难。