• 用大语言模型+prompt的方式可以快速低开发成本地实现原来需要多环节传统编程+监督学习训练语言模型才能够完成的任务，但是也带来一些问题，例如模型性能不稳定，因为是黑箱流程难以调试等等。

• 解决的方法是，用传统编程思维将任务拆解成若干个子流程，再借助LLM的能力，用自然语言的方式对将每个子流程进行“编程”成“prompt函数”。

• 如此，可以在确保程序稳健性、透明性、可调试性的前提下借助LLM兼顾开发效率和降低代码编程难度。

• 课程免费学习地址：https://learn.deeplearning.ai/chatgpt-building-system

Large language Models, the Chat Format and Tokens / 大语言模型，对话格式及令牌（分词）

• LLM是如何炼成的：先训练基础模型，再finetune基础模型到一个能够听从指示的模型。

• 使用包含成对问题和答案的数据集进行微调

• 使用人类对finetune后的模型输出结果进行打分

• 使得finetune的模型能够更可能地输出高评分的结果（RLHF）

• 关于Token：

• 直译过来是“令牌”，但是在LLM语境中可以理解为分词，即模型处理单词的最小结构

• token的分词方式和词汇长度和词频有关，越频繁使用及越短的词，越容易被完整保留；反之则越容易被拆分。

• 一个token平均为4个字母，或者3/4个英文单词长度，因此模型能处理的实际单词数会少于token数。

• gpt API中的角色指定：System, user and Assistant Message

• 可以在一个message中同时以system的身份指定gpt的角色，以及以user的身份传递要处理的具体任务，assistant则是AI回复的内容，这种传递方法主要是通过传入历史对话来让AI获得足够的对话context（上下文）。

• 可以从返回的'usage'字段中获得提交的和消耗的token数

• 使用LLM API+prompting构建对话应用相比传统基于监督学习的对话模型训练: 如图所示，把几个月的工作缩短到几个小时，因为跳过了标注数据、训练和复杂调试的过程，而是直接利用prompt去“诱导”LLM使用合适的zero-shot learning（零次学习）能力来完成特定任务。

Classification / 分类

• 在大语言模型出现之前，对特定情境下的对话根据内容进行分类是一个挺麻烦的事，没想到在LLM加持下用一个类似“自然语言编程”的方式就完成了。

Moderation / 自我审查

• OpenAI 提供了一个成为“Moderation”，即具备自我审查功能的监测点，能够检测用户输入的内容中暴力、仇恨等不良内容的倾向；同时能够调整检测的阈值。

• 关于上述代码的补充：
在许多编程语言中，f""" ... """是一种特殊的字符串格式，通常称为"F-strings"（在Python中被称为f-string）。在这种字符串中，字母f的作用是使字符串成为一个格式化字符串，允许在字符串中嵌入变量或表达式的值。

• Avoiding Prompt Injections / 防止注入攻击

• 定制化的AI对话系统通常是为特定场景设计的，这时候则要防止用户使用注入攻击跳出设定好的对话情景。

• 一个可行的办法是，在真正开始处理用户的对话之前，先设定一个检测机制，看是否存在注入攻击。

Chain of Thought Reasoning / 思维链

• 与其直接让gpt直接给出答案，而是预先构建好一个思维链（判别步骤），引导AI一步一步地给出答案，使整个决策过程更稳定和透明。

• 实现方法：在 system_message 中传入所有的前置信息，以及决策的分解过程：

• 完成之后，gpt就可以根据我们设定好的决策过程来回答问题：

• 注意，我们在设计思维链的时候设计“最长”思维链即可，而不需要设想所有可能性，因为AI具备一定的泛化能力；当实际情况不符合我们设定的情况时，AI会直接跳出思维链，零次学习能力进行回复，如下所示：

• 如果只希望向用户输出最终回复结果，而不暴露思维过程的话，可以用之前设定好的分隔符（delimiter）对回复进行分隔，然后只向用户显示回复最后一部分：

Chaining Prompts / 提示链

• 这一节是上一节的延伸，说明了如何将一个复杂任务拆解成多个简单任务，并让 gpt 进行逐个解决。

• 其实思路有点像传统编程方法中将任务拆解成条件然后执行，区别是传统编程中还需要将拆解后的小任务写成机器可以理解的代码语言，而使用 LLM 模型则可以使用自然语言去定义这些任务。

• 优点包括：

• 节省 token（跳过不必要的步骤）；

• 容易调试和跟踪；

• 进行格式化的输出，从而引入外部工具。

• 下面这个 case 显示了，如何通过提示链，限定输出的内容，即包含产品信息的 python list，或超出回答范围时只回复空集 [ ]

• 我们可以将输出的 list 形式的 str 字符串，再转换回事实上的 python list

• 结合这个方法，我们就可以根据初次回复（提取用户问题中的产品名称和类别），从产品数据库字典中提取相关具体信息：

• 最后，提取出来的产品信息就可以作为 context（放在”assistant“中），让 AI 根据精确数据做出回复。

• 最后总结的要点：对问题更为专注；内容限定；省钱（省 token）

Check output / 输出检查

• Moderation API 是 openAI GPT AI 内置的一个内容审查功能，能够检测指定内容中各种不良倾向的评分

• 还有一个进行审查的方式就是进行套娃，即让 GPT 自己审查自己生成的内容，例如以下 case 就是关于 GPT 审查 AI 回复客户的内容是否和问题及事实相关。

Building an End-to-End System / 构建端到端系统

• 结合前几章的内容，通过 gpt 借助思维链+自然语言的方式构建一个带信息提取匹配、内容质量评估、伦理审查并自动更新对话记录的端到端对话系统。

• 以下是一个智能客服案例，能够自动根据用户问题提取相关产品回答，并在这个过程中进行自我审查评估；并带有 debug 流程

• 借助上一步构建的 function，就可以搭建一个能够实现连续对话的机器人对话框。

Evaluation part I / 输出评价-第一部分

• 需要对输出进行评价的原因是，使用 LLM 构建问答类应用在短时间内跳过了传统监督学习的大部分流程，很容易导出输出结果的不稳定和带有偏见。

• 在实际项目中，对输出进行评价的步骤是：

• 先观察用 LLM 问答系统输出的最初几个回答，然后根据质量进行 prompt 调整。

• 然后测试更多问答，收集其中有问题的问答，再根据有问题的问答进行调整。

• 建立一个（AI）评估机制，对输出进行自动化评价。

• 收集用户的不良反馈案例，prompt 进行进一步调整。

• 下面这个例子示范了如何根据传入的产品信息和类别列表回答用户的问题，重点是以指定格式输出，并且用了通话记录作为示范的方式（few shot prompting），去提示怎么回答用户问题：

• 以下是一个困难案例（即前面所说的 tricky example），用户在一句话中问了太多问题，以至于回答中出现了非 JSON 格式的输出：

• 以下是改进的 prompt，强调了只输出 JSON 格式的信息，并增加了一个回复案例：

• 有趣的点是，修改完 prompt 后，不仅要在之前没有通过的问题上进行测试，还要在已经通过的问题上做测试，确保目前的所有问题样本都能够 pass：

• 接下来，我们可以构建一个评价标准，具体方法是：

• 先构建一个作为正确示范的问答数据集；

• 再构建一个能够自动提取问答数据集中问题部分，然后让 AI 做出回答，再比较 AI 回答和示范答案之间的差异性的函数（注意，因为这里的回答是 JSON 格式的产品名称，所以可以直接比对产品名称及数量）；

• 最后在调整 prompt 的过程中，多次运行这套评价体系，来比对每次调整 prompt 回答正确率是否提升。

• 如果回答和案例完全相符，得返回1，如果完全不相符，则返回0

Evaluation part II / 输出评价-第二部分

• 上一节中，展示了如何使用正确回答数据库，对规则性的输出（例如只要求回答对应产品名称）进行评价；这一节中，则要展示如何对复杂的，非规则化的回答进行评价，例如下面这种回答。

• 要对这一类型的回复进行评价，解决的方法是，先人工列出评价回复的几个标准（例如是否和提供的资料不符合，是否正面回答了问题等），然后用 LLM 去根据这些标准逐条评价回复：

• 另一个方法则类似上一节中的方法，即直接比对 AI 回复和理想答案中差异性，但是这里的差异性不能直接计算（因为不是固定格式输出），而是仍采用人工的方法设定比较标准，然后再用 LLM 去做比较评分：

• 以下是理想回复案例：

• 以下是比较文本内容的 prompt（来自 openAI 社区 evals project：https://github.com/openai/evals/blob/main/evals/registry/modelgraded/fact.yaml）：

• 以下是评价示例：