14｜业务知识管理中的LLM应用模式

Apr 8, 2024

14｜业务知识管理中的LLM应用模式-徐昊 · AI时代的软件工程-极客时间



下载APP





关闭

渠道合作

推荐作者

14｜业务知识管理中的LLM应用模式

徐昊 · 徐昊 · AI时代的软件工程

课程介绍



讲述：徐昊

时长06:39大小6.09M



你好，我是徐昊，今天我们来继续学习 AI 时代的软件工程。
经过前面的几节课的学习，我们已经看到大语言模型（Large Language Model，LLM）如何在业务知识管理的过程中辅助我们完成工作。今天，我们来总结一下在业务知识管理中，知识过程是怎么样的，以及典型的 LLM 模式有哪些。
迭代式增量交付是一个持续学习的过程当代软件开发的基本思想是通过迭代的方式增量开发系统。在每个迭代结束后，根据收集到的反馈，调整目标和方向。这种方式下，开发人员能够利用前序迭代中学习到的知识，在后续迭代中改进交付的流程和结果。
迭代交付的关键在于，不要一开始就想实现全部的功能和需求，而是从一部分核心需求开始，通过持续的反馈，不断增强和演进当前的软件，调整目标和计划，直到整个系统做完为止。
从迭代软件交付的全流程上看，整个过程处在复杂的认知行为模式（Complex）。每一次迭代的过程，就是探测（Probe）的过程，收集反馈是感知（Sense）的行为，而最后对于目标和计划的调整就是响应（Respond）。
正如我们在前面的课程中讲到的，处于复杂认知行为模式时，我们对于不可言说知识的学习，是在行动与反馈中学习的过程。因而，迭代式增量交付实际是一个持续学习的过程。
那么在迭代式增量交付这个学习过程中，业务知识管理发挥了什么作用呢？站在迭代软件交付的全流程上，去看待业务知识管理时，不难发现业务知识管理的主要作用是提炼和传递不可言说知识：
从初始的业务愿景开始，产生整体解决方案（不可言说知识的提炼）；
结合场景将整体解决方案切分成更小粒度的用户故事，以用户故事构成迭代计划（不可言说知识的传递）；
按照具体的业务场景补充验收条件（不可言说知识的传递）；
依照反馈，改进整体解决方案（不可言说知识的提炼）。
不难看出，业务知识管理中涉及到的不可言说知识，主要是整体解决方案，传递的方式是将整体解决方案切分为更小的粒度，然后通过明确验收条件的方式，强化知识传递的效果。
无法加速的反馈循环谈到复杂的认知行为模式，我们很自然地想到，能不能利用 LLM 直接加速这个反馈循环呢？也就是由人通过业务知识管理定义问题，让 LLM 直接为我们生成软件，然后我们只需要验收 LLM 构造的软件就可以了。
某种程度上说，这是 LLM 给绝大多数人带来的美好愿景。通过简单几句话的描述，LLM 就能帮助我们完成软件的开发。比如，在 ChatGPT 上线之初，我们看到过很多这样的例子：
请使用 JavaScript 编写一个贪吃蛇的游戏
然后 ChatGPT 就能够生成差不多的代码：
这一方面得益于 ChatGPT 丰富的训练语料，但更多是由于在互联网上有很多关于贪吃蛇的规则描述、示例代码等知识沉淀。也就是关于贪吃蛇的业务知识早就存在于互联网之上了，我们无需额外准备这些知识了。这里效率提升的主因并不是 LLM，而是包含在训练语料中的知识。因而我们无法跳过知识管理这一步，让 LLM 直接帮助我们生成我们想要的代码。
除去知识管理之外，目前的 LLM 系统还存在技术限制。无论是 ChatGPT，Claude 或是别的 LLM 都存在上下文的限制，也就是每一次 LLM 只能处理有限数量的 token，以及产生有限数量 token 的结果。因而 LLM 能够理解的上下文规模，以及能够生成的应用规模都是有限的。对于大型系统而言，我们无法一次性将上下文传递给 LLM，也无法从 LLM 中一次性获取整个应用。也就是说 LLM 存在一个极限的认知负载。
而就算我们准备好了全部的知识，且我们的应用规模很小，就像贪吃蛇一样，规则明确，功能简单，代码量也不多。那么这时候，反馈循环的瓶颈就变成了我们如何验证 LLM 生成的系统是正确且有效的。要时刻记得，LLM 存在“幻觉”，会编造答案。
LLM 生成的回答是基于其在训练数据中学到的模式和信息。模型的目标是根据输入提供有用和合理的文本，但并不能真正理解问题的含义。有时候，模型可能会生成看似合理但事实上不正确或不准确的答案。
这将意味着，每一次 LLM 根据我们的反馈提供新的答案时，我们都需要进行全量回归测试（Full regression test）。哪怕对于贪吃蛇如此简单的系统，我们也需要测试操作、贪吃蛇变长、贪吃蛇碰到自身导致游戏终止，以及各种边界条件。这对于人来说，是极大的认知负载。
因而，以目前 LLM（2024 年 1 月）的能力来看，对于绝大多数实际工作中的生产系统而言，我们无法直接使用 LLM，在整个系统维度形成快速的反馈循环，从而提高知识学习和传递的效率。
而且，由于 LLM 和人脑都存在认知负载超标的问题，我们仍然需要依靠业务知识管理的传统技法，比如通过用户故事去切分上下文，让 LLM 可以在有限的上下文内提供最大的帮助。也可以让人在受控的上下文内，去验证 LLM 产生的结果是否符合需求。
LLM 辅助业务知识管理的几个模式因为我们无法直接构成快速的反馈循环，我们就需要寻找其他的方式，利用 LLM 为业务知识管理提效。
首先，业务知识管理重在对于问题的定义，一旦问题定义错误，将带来成本巨大的返工和重做。那么我们首要任务就是验证对于问题的定义。然后才是根据问题定义，生成下游所需的新的知识，比如验收条件，比如业务模型。
在我们的课程中，介绍了两个不同的方式验证问题定义是否正确。第一个是由 LLM 根据业务上下文提问，通过人的回答，验证整体解决方案提取是否完整清晰；第二个是借助模型，验证业务描述是否可以通过模型展开解释。
这两个方法是完全不同的模式。第一种基于 ReAct，是 LLM 推理能力的应用，是一种更为通用的模式，在不同的场合都能使用。
第二种，则是基于这样一个前提条件——模型是凝练的业务知识，模型表示了业务概念更普遍的关联。因而，模型在某种程度上，与文字表达的业务是同一种知识的不同表现形式。那么，我们可以通过将同一个知识的不同表现形式，做相互转化，就能交叉验证其中的偏差。
这里依赖于同样的知识有不同的表示形式，应用的场景就要受到一些限制。比如，不使用业务模型的团队，就无法使用这个方法验证。
在我们的课程中，还介绍了两种生成新知识的方式。第一种方式通过多个 ChatGPT 会话（ChatGPT session）构造反馈循环，利用 LLM 提速这个循环得到最后的结果，比如利用 LLM 建模。这是一种更为通用的模式，在不同的场合都能应用。
第二种是基于 ReAct，利用 LLM 基础语料中的知识（验收条件），完成验收条件初稿的生成。在更一般的场景中，我们需要结合使用 ReAct 和思维链（Chain of Thought，CoT）完成最终结果的生成。
总结至此，如何利用 LLM 辅助业务知识管理就讲完了。可以看到，我们讲解了两种验证问题定义的方法，以及两种生成新知识的方法。你可能会有一个疑问，为什么我们不使用 LLM 帮助我们分解用户故事，而着重在业务模型和验收条件呢？
答案是可以，但是没必要。我们讲解的场景，着重放在开发团队对业务知识的验证与学习（验收条件，模型展开），以及业务知识的学习上（LLM 提问，辅助业务建模）。此时 LLM 帮助我们解决了团队瓶颈。
而用于故事分解时，我们解决的是一个庞杂认知模式（Complicated）的问题，LLM 只帮助了业务分析师。而我们之前也讲过，庞杂模式如果不是有团队的放大效应，LLM 并不能带来什么效率提升。因而，答案是，可以，但是没必要。
思考题请尝试写一个分解用户故事的 prompt 模板。
欢迎在留言区分享你的想法，我会让编辑置顶一些优质回答供大家学习讨论。

1. 迭代式增量交付是一个持续学习的过程，业务知识管理在整个过程中的作用是提炼和传递不可言说知识。 2. 无法加速的反馈循环，LLM存在认知负载的问题，无法直接构成快速的反馈循环，需要依赖传统的业务知识管理技法。 3. LLM辅助业务知识管理的几个模式包括验证问题定义的方法和生成新知识的方式，如基于ReAct的推理能力应用和利用LLM提速反馈循环得到最终结果. 4. 在业务知识管理中，LLM帮助解决了团队瓶颈，但在庞杂认知模式的问题上，LLM并不能带来效率提升.

分享给需要的人，Ta购买本课程，你将得29元

生成海报并分享

2024-04-08

赞 3

提建议

13｜构建基于TQA模式的AI Agent

直播专场（二）｜如何进行业务知识管理？

 写留言

全部留言(4)

最新
精选

范飞扬
2024-04-14 来自浙江
老师说，使用LLM帮助分解用户故事，可以，但没必要。给的理由是，庞杂模式如果不是有团队的放大效应，LLM 并不能带来什么效率提升。我就不太同意这个答案了，答案应该是看情况：有时候有必要，有时候没必要。什么时候有必要？团队里没有业务分析师，需要自己分解用户故事。而且自己不在庞杂模式，而在复杂模式下。那么就有必要使用LLM了。我感觉我的情况就是属于有必要的情况，那么，老师的思考题就很有价值了。思考题是：请尝试写一个分解用户故事的 prompt 模板。我理解，11讲就回答了怎么分解这个问题，“通过用户角色的目标，整体解决方案，用户旅程分解”。那么可以写出这个Prompt：（GPT对于这个Prompt的回复，我贴在这个留言的回复里）业务背景 ====== 这是一个教学学籍管理系统。用户角色 ====== 教职员工（As a faculty），学生（As a student）核心目标 ====== 教职员工：追踪学生是否完成了教学计划的学习；学生：按照教学计划完成课程学习整体解决方案 ====== 设定一个教学计划，其中包含学生应该完成的所有课程，以及相应的学位。为每一位学生指定一个学籍，也就是学习某个教学计划的资格。学生需要根据教学计划，注册对应的课程。学生可以根据教学计划，学习对应课程，并获得成绩。每年依据学籍以及学生选课的成绩，判断学生是否能够毕业。用户旅程 ====== 教职员工：发放录取通知、结业；学生：注册学籍、选课用户故事分解方法 ====== 需要找到不同用户角色的目标，并根据这些目标设计整体解决方案。整体解决方案中包含业务中的核心概念、关键规则和主要流程。然后我们再根据整体解决方案，设计不同角色的用户旅程。接着我们就可以从用户旅程上切分用户故事了。那么此时，用户故事只有三种写法： So that 可以满足某个用户角色的目标 So that 可以满足整体解决方案的规则或流程 So that 可以进行用户旅程的下一步任务 === 根据用户故事分解方法，写出多个用户故事。
展开
作者回复: 分解用户故事的重点不在于写出来而在于找到价值点以及roi，如果自己一个人，你完全明白价值点的话写不写出来都无所谓
共 3 条评论
3
术子米德
2024-04-09 来自日本
🤔☕️🤔☕️🤔 【R】迭代式软件交付流程 = 复杂的认知行为模式精准匹配：Probe/Sense/Respond 【.I.】迭代！= 分批。我分批，是因为我来不及，所以，完成一点交付一点，占满交付的带宽，就是最佳分批策略的实施。分批的别名就是分期。我迭代，是因为我不明白，所以，以现在所知，加前进方向，走出一步看情况，每次交付都有新知识和新问题，就是迭代的舒适节奏。矛盾在于，我们不能待在舒适区。【.I.】我写一句话需求，我自己写不出代码，大模型能刷一把写出代码，这说明，我说的需求，大模型已经门清，即这个需求对应的知识，之前已经是业界常识，大模型已经学会，而我也恰巧问对；如果大模型被我这一句话问呆滞，那么大概率是这句话背后的知识，大模型没有直接掌握，或者是我没有说清楚需求，我继续问大模型，或者我提示大模型来问我，这么我问你答、你问我答，逐步把这句没弄明白的需求，其中隐含的知识给弄明白，直到刷一把写出代码为止；而最终的瓶颈，一定会在我判定结果有效性的时候出现。【Q】迭代完成后走人，就会把这轮迭代中的知识带走，或者随风而散，如何能够边迭代边留下知识？ — by 术子米德@2024年4月8日
展开
作者回复: 代码啊
Geek_310e53
2024-08-06 来自澳大利亚
速如其名，八叉的语速更快了，1倍速就相当于常人的1.25~1.5倍速。
听水的湖
2024-04-10 来自北京
没有加群的注意通过小助手进一下课程群，方便接收后续直播通知。小助手微信号：geektime004，回复「徐昊」

