Workflow design - 版本历史

2024年7月29日 (一) 07:11 Riguz

2024-07-29T07:11:56Z

←上一版本		2024年7月29日 (一) 07:11的版本
第1行：		第1行：
	随着2023年大模型在国内的发展成熟，现在大家逐步开始真正关注到大模型应用的开发上。有人说，2024年是大模型应用的落地元年。的确，看似无所不能的大模型，也并不是直接丢到一个系统就能用的，如何开发大模型应用，实际上还处于一个刚起步的阶段。一些成熟的技术，经历过许多人摸索后，总能给出一个"best practice"~~；对于大模型应用开发来说，却仍还在探索阶段。~~		随着2023年大模型在国内的发展成熟，现在大家开始真正关注到大模型应用的开发上。有人说，2024年是大模型应用的落地元年。看似无所不能的大模型，却并不能直接集成到一个系统中，如何开发大模型应用，目前仍然处于一个刚起步的阶段。一些成熟的技术，经历过许多人摸索后，总能找到一个现有的"best practice"；对于大模型应用开发来说，谁也不敢说他的做法已经是“best practice”。
	~~目前，一个看起来比较靠谱的模型，是这样定义大模型应用开发的几个level的：~~
			目前，有一个看起来比较靠谱的模型，是这样定义大模型应用开发的几个Level的：

	[[Image: LLM-app-levels.png\|600px]]		[[Image: LLM-app-levels.png\|600px]]

Riguz：/* 未来展望 */

2024-07-29T07:07:56Z

未来展望

@@ 第768行： / 第768行： @@
 * 图像生成：类似Coze的图像流，包含文生图以及图像处理等
 * 自定义插件：允许用户接入已有的API，或者通过FaaS部署一个新的自定义插件
 关于我们为什么要做Workflow，感兴趣可以从这里<ref>AI Con总结和KPP工作流 方案汇报 https://365.kdocs.cn/l/crXXklzrerKF</ref>了解更多的背景信息。

Riguz：/* 未来展望 */

2024-07-29T07:00:13Z

未来展望

←上一版本		2024年7月29日 (一) 07:00的版本
第758行：		第758行：
	= 未来展望 =		= 未来展望 =

	~~关于为什么要做Workflow，感兴趣可以从这里了解一些其他的信息~~<ref>AI Con总结和KPP工作流方案汇报 https://365.kdocs.cn/l/crXXklzrerKF</ref>。		工作流模型是一个高度可扩展的模型，
			可以通过添加新的节点类型、插件等，
			实现更复杂的功能。

			一些在计划内的功能有：

			* RAG：知识库检索
			* 代码执行：执行一段python或者Javascript代码，可以用来定制一些特殊的逻辑
			* 图像生成：类似Coze的图像流，包含文生图以及图像处理等
			* 自定义插件：允许用户接入已有的API，或者通过FaaS部署一个新的自定义插件

			关于我们为什么要做Workflow，感兴趣可以从这里<ref>AI Con总结和KPP工作流方案汇报 https://365.kdocs.cn/l/crXXklzrerKF</ref>了解更多的背景信息。

Riguz：/* CLI测试工具 */

2024-07-29T06:52:43Z

CLI测试工具

←上一版本		2024年7月29日 (一) 06:52的版本
第751行：		第751行：
	比如，工作流A运行有问题，但是由于权限问题，排查问题的人员无法在界面上看到A；		比如，工作流A运行有问题，但是由于权限问题，排查问题的人员无法在界面上看到A；
	或者由于实现的层级嵌套较深，很难判断到底是前端问题，还是后端接口问题，还是工作流执行引擎的问题。		或者由于实现的层级嵌套较深，很难判断到底是前端问题，还是后端接口问题，还是工作流执行引擎的问题。
	~~为此，我们开发了一个CLI工具用来直接执行工作流JSON：~~
			为此，我们开发了一个CLI工具用来直接执行工作流JSON，可以比较方便地运行和查看工作流执行结果：

	[[Image:workflow-cli.gif\|600px]]		[[Image:workflow-cli.gif\|600px]]

Riguz：/* 开发一个CLI测试工具 */

2024-07-29T06:50:52Z

开发一个CLI测试工具

←上一版本		2024年7月29日 (一) 06:50的版本
第744行：		第744行：
	或者说单元测试应该更充分。		或者说单元测试应该更充分。

	=== ~~开发一个CLI测试工具~~ ===		=== CLI测试工具 ===
	除了单元测试、集成测试等方式来测试工作流的执行之外，		除了单元测试、集成测试等方式来测试工作流的执行之外，
	很多时候，我们需要定位分析问题，		很多时候，我们需要定位分析问题，

Riguz：/* 开发一个CLI测试工具 */

2024-07-29T06:50:18Z

开发一个CLI测试工具

←上一版本		2024年7月29日 (一) 06:50的版本
第751行：		第751行：
	比如，工作流A运行有问题，但是由于权限问题，排查问题的人员无法在界面上看到A；		比如，工作流A运行有问题，但是由于权限问题，排查问题的人员无法在界面上看到A；
	或者由于实现的层级嵌套较深，很难判断到底是前端问题，还是后端接口问题，还是工作流执行引擎的问题。		或者由于实现的层级嵌套较深，很难判断到底是前端问题，还是后端接口问题，还是工作流执行引擎的问题。
	~~为此，我们开发了一个CLI工具用来直接~~		为此，我们开发了一个CLI工具用来直接执行工作流JSON：

			[[Image:workflow-cli.gif\|600px]]

	= 未来展望 =		= 未来展望 =

	关于为什么要做Workflow，感兴趣可以从这里了解一些其他的信息<ref>AI Con总结和KPP工作流方案汇报 https://365.kdocs.cn/l/crXXklzrerKF</ref>。		关于为什么要做Workflow，感兴趣可以从这里了解一些其他的信息<ref>AI Con总结和KPP工作流方案汇报 https://365.kdocs.cn/l/crXXklzrerKF</ref>。

Riguz：/* 开发一个CLI测试工具 */

2024-07-29T06:47:16Z

开发一个CLI测试工具

←上一版本		2024年7月29日 (一) 06:47的版本
第745行：		第745行：

	=== 开发一个CLI测试工具 ===		=== 开发一个CLI测试工具 ===
			除了单元测试、集成测试等方式来测试工作流的执行之外，
			很多时候，我们需要定位分析问题，
			是很麻烦的。

			比如，工作流A运行有问题，但是由于权限问题，排查问题的人员无法在界面上看到A；
			或者由于实现的层级嵌套较深，很难判断到底是前端问题，还是后端接口问题，还是工作流执行引擎的问题。
			为此，我们开发了一个CLI工具用来直接

	= 未来展望 =		= 未来展望 =

	关于为什么要做Workflow，感兴趣可以从这里了解一些其他的信息<ref>AI Con总结和KPP工作流方案汇报 https://365.kdocs.cn/l/crXXklzrerKF</ref>。		关于为什么要做Workflow，感兴趣可以从这里了解一些其他的信息<ref>AI Con总结和KPP工作流方案汇报 https://365.kdocs.cn/l/crXXklzrerKF</ref>。

Riguz：/* 自动化集成测试 */

2024-07-29T06:42:58Z

自动化集成测试

←上一版本		2024年7月29日 (一) 06:42的版本
第739行：		第739行：
	在这个集成测试中，除了网关的调用是通过Mock Server替代外，其他的调用方式都与实际一致。		在这个集成测试中，除了网关的调用是通过Mock Server替代外，其他的调用方式都与实际一致。
	在执行完成后，我们捕获事件，验证产生的事件数目以及是否包含预期的事件，来判断执行结果是否符合预期。		在执行完成后，我们捕获事件，验证产生的事件数目以及是否包含预期的事件，来判断执行结果是否符合预期。

			当然，集成测试的成本较高，我们需要维护一些典型的测试场景（工作流JSON），因此很难覆盖到逻辑的细节。
			这也意味着集成测试的数目理论上应该远小于单元测试，
			或者说单元测试应该更充分。

	=== 开发一个CLI测试工具 ===		=== 开发一个CLI测试工具 ===

Riguz：/* 自动化集成测试 */

2024-07-29T06:40:28Z

自动化集成测试

←上一版本		2024年7月29日 (一) 06:40的版本
第688行：		第688行：

	=== 自动化集成测试 ===		=== 自动化集成测试 ===
			对于一个工作流执行，如何进行集成测试呢？得益于事件驱动架构，
			我们不需要关心工作流执行的Side effect，只需要关心事件即可。
			也就是说，对于一个给定的工作流，它是否产生了符合预期的事件。

			例如，我们有一个用例测试条件节点：

			<syntaxhighlight lang="go">
			func TestExecutor_ShouldReturnLlm1Result_WhenExecute_GivenConditionMatchesLlm1(t *testing.T) {
			server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
			w.Header().Set("Content-Type", "application/json")
			w.WriteHeader(http.StatusOK)
			w.Write([]byte(`{"code":"Success","message":"成功","external_id":"a9331df1-2adb-4fad-a154-5d8767196bb2","created":1718264704,"task_id":"llm-chat-azure-gpt-35-turbo-version-0125/ac57f2f54fe1d40be193966e5875b3a8","usage":{"completion_tokens":77,"prompt_tokens":52,"total_tokens":129},"choices":[{"index":0,"finish_reason":"stop","logprobs":0,"text":"Yes"}]}`))
			}))

			data, _ := os.ReadFile("./schema/cases/llm-condition.json")
			json, err := workflow.Parse(data)
			assert.NilError(t, err)
			builder := workflow.NewWorkflowBuilder(json, workflow.GatewayConfig{
			BaseUrl: server.URL,
			})
			dag, errs := builder.ValidateAndToDAG()
			assert.Equal(t, len(errs), 0)
			executor, err := workflow.NewExecutor(*dag)
			assert.NilError(t, err)
			channel := executor.Subscribe()
			go func() {
			w := workflow.NewEmptyWorkflowContext(context.TODO())
			w.SetParameters(map[string]any{
			"input": "what's the main product of kingsoft?",
			})
			err := executor.ExecSync(w)
			assert.NilError(t, err)
			}()
			events := []workflow.WorkflowEvent{}
			for e := range channel {
			events = append(events, e)
			}

			assert.Equal(t, len(events), 12)

			assertEventsContains(t, events, func(e workflow.WorkflowEvent) bool {
			return e.Type() == workflow.NodeSkipped && e.(workflow.NodeSkippedEvent).Node == "llm2"
			})
			assertEventsContains(t, events, func(e workflow.WorkflowEvent) bool {
			return e.Type() == workflow.JsonResponseGenerated && e.(workflow.JsonResponseEvent).Data["output"] == "Yes"
			})
			}
			</syntaxhighlight>

			在这个集成测试中，除了网关的调用是通过Mock Server替代外，其他的调用方式都与实际一致。
			在执行完成后，我们捕获事件，验证产生的事件数目以及是否包含预期的事件，来判断执行结果是否符合预期。

	=== 开发一个CLI测试工具 ===		=== 开发一个CLI测试工具 ===

Riguz：/* 使用TDD */

2024-07-29T06:33:58Z

使用TDD

@@ 第625行： / 第625行： @@
 对于GptAdaptor我们有这些测试用例：
-<syntaxhighlight lang="bash">
+<syntaxhighlight lang="go">
 // 如果大模型节点的返回格式是JSON且模型支持JSON模式，那么需要设置json_object参数，并在提示词中描述json结构
 func TestGptAdaptor_ShouldAddJsonMode_GivenOutputIsJson(t *testing.T) {
@@ 第659行： / 第659行： @@
 	assert.Equal(t, req.Messages[0].Content, "so he is a clean robot? what else do you know about him?")
+}
 </syntaxhighlight>
 === 自动化集成测试 ===

Workflow design - 版本历史

2024年7月29日 (一) 07:11 Riguz

Riguz：​/* 未来展望 */

Riguz：​/* 未来展望 */

Riguz：​/* CLI测试工具 */

Riguz：​/* 开发一个CLI测试工具 */

Riguz：​/* 开发一个CLI测试工具 */

Riguz：​/* 开发一个CLI测试工具 */

Riguz：​/* 自动化集成测试 */

Riguz：​/* 自动化集成测试 */

Riguz：​/* 使用TDD */

Riguz：/* 未来展望 */

Riguz：/* 未来展望 */

Riguz：/* CLI测试工具 */

Riguz：/* 开发一个CLI测试工具 */

Riguz：/* 开发一个CLI测试工具 */

Riguz：/* 开发一个CLI测试工具 */

Riguz：/* 自动化集成测试 */

Riguz：/* 自动化集成测试 */

Riguz：/* 使用TDD */