AI和大模型——Graph engineering

一、介绍

AI圈的名词总是很多，没有名词也要不断的制造名词，这样才会显得更加的高大上。正如软件的发展过程一样，AI的相关开发和应用也是从一个点的开发应用在逐渐的向并行的分布式的开发演进。
尤其是AI的发展在当下的速度呈现出一种爆发的情况，其自身技术的演进以及与其它领域技术的引入、融合和再发展的情况比比皆是。Graph engineering就是描述这种情况中一个技术的一个新名词。

二、Graph engineering

Graph engineering，图工程。它是解决目前AI智能体（Agent）协作变得越来越复杂的问题，提出的一种系统化设计思路。对稍微有一些开发经验的开发者来说，通过名字都可能觉得这个技术不大可能会是一种全新的创新技术。实际情况也确实如此，这顶技术本身就是借鉴了传统的算法图结构或者更接近一些的说法是借鉴了并行算法中的图处理机制。
需要注意的是，Graph engineering到目前为止并没有一个统一的标准，虽然大家有把它当成一种标准的趋势，但目前也仅仅是这样。

三、Graph模型的演进

在前面的技术谈及过程中，分析过提示词工程 (Prompt Engineering)、上下文工程 (Context Engineering)、循环工程 (Loop Engineering)、驾驭工程 (Harness Engineering)以及Workflow。那么图工程 (Graph Engineering)和它们有什么关系呢？
AI和大模型的推广是从Prompt Engineering开始的，大家要学会如何使用一个好的提示词来实现自己的目的。大家一定要记住，不管如何风吹浪打，这点是最基础的。就如人可以成为艺术家、科学家、医生等等。但吃饭是必须的。随着应用需求和AI自身的发展，为了能够让AI可以更好的理解、决策并实现与上层应用的沟通，Context Engineering就出现了，它向AI提供了更丰富、更确定的提示词。但实际的问题，往往不是一次沟通就能解决的，它需要应用与大模型反复交互，这就出现了Loop Engineering。而随着双方的更复杂的需求出现时，可能一个Loop无法解决或者说无法更方便、快捷的解决问题时，就可以采用多个Agent来实现多个Loop的组织协调一起完成任务，解决问题。这就是Graph engineering。而无论是Graph engineering还是Loop Engineering，它们处理任务的流程都属于Workflow，它们都可以看作是Workflow的一种具体的表现形态。
而不管是哪种工程，对于AI来说，都是服务于大模型的。而Harness Engineering编程在前面的分析可以知识，它可以理解为Harness+Model。那么这就简单了，这些所谓的工程都属于Harness Engineering的一部分或者说属于Harness的一部分。当然，对于AI工程范式的发展过程是有一些先后不一致的情况，比如Loop比Harness出现的要晚，可能很多人不这样认为，这就看大家怎么划分吧。各自有各自的理解，知道意思就行。

四、Graph engineering的分析

要想更好的理解Harness Engineering，就需要把到目前的AI编程范式堆栈分析一下。在前面刚刚分析了Harness Engineering的发展和演进，那么理解下面的堆栈就比较简单了。

从上面的堆栈可以看得出来，以上层需求的角度看，它就是一个从点应用到线应用再到面应用的发展过程，这和互联网开发的发展路径基本一致。从功能实现的角度看，它就是一个从手动到自循环再到自动编排的手动向自动发展的过程。
从历史发展的绝对值来看，图早就出现了，但技术发展必须用应用以及技术的特点契合时，才能够引发一种新的技术变革。这就是世人常说的“命”。正如手机上网早在诺基亚时代就出现了，但真正的移动互联时代的到来，是随着智能手机的普及才真正的出现了。
以上面的堆栈来看，就可以理解成编程中的不断的抽象的过程。特别是从循环工程到图工程，更是容易如此对比。但有过架构经验的都知道，越是抽象越是对组织之间的接口要求严格，它们间的通信和协调都必须有标准的格式。这样才能更好的解决在具像化后的沟通成本问题。
在图工程中，有一个重要的问题需要特别的说明。大家去某某单位或公司，都有可能看到类似下面的图：

但这种图它不是真正意义上的工作运行图，它是一种静态的组织架构图。这种图的特点一般是固定下来后，很长时间不会变。但实际的Graph Engineering，它的图和并行算法中的图一样，它可能是不断的变化的，有可能增加或减少节点，有可能图的节点逻辑联系会发生变化等等，从而形成一个动态的组织结构的处理。它更类似于下面的图：

这个图看上去虽然和上面的图有些类似，但实际中，执行结果可能增加或减少，判断后可能会返回调度继续处理也可能直接输出最终的结果交付。当然，从不同的角度看，可能对这个Graph Engineering的理解会有所不同，不必过于纠结，毕竟这只是一种新的提法而不是一种标准。
那么在实际中到底如何选择Loop或Graph呢？关键不在于技术本身而在于应用需求。如果设计出来的图工程可以压缩到一个Agent中的Loop完成，那么设计图工程就没有什么意义了。怎么才能判断使用图工程呢？整体来看，可以看一下，利用图设计后，这种是不是零成本的抽象？有没有明显的收益。在实际的工程中，大多可以先以Loop来设计，当问题出现后再利用图进行设计。
从具体的层次来看，要想使用图工程，需要看两点。第一是工作任务中有无并行或分支出现，这是并行的前提；第二，每个任务阶段的完成是不是有独立的可检查的结果。只要这两点是清晰的，那么基本可以考虑使用图工程了。
其实图工程的意义在于，从更高层次上进行抽象，以解决工作任务的串行、并行以及各个节点在这种机制下的有机整合，从而实现任务的最终目的。
在具体的图设计过程中，除了要掌握并行算法中的图的设计的要点外，在AI大模型的Graph Engineering工程中，先要把Loop Engineering工程深入的搞清楚，即单点串行要明白，才能更好的搞多点并行。然后才能处理AI节点（Agent）的粒度的划分、状态控制和相关成本的管理等。最后，图工程的图要与实际需求的强结合，保证不会出现图的设计逻辑和实际分离的现象。

五、总结

通过分析可以知道，Graph Engineering工程不是对其它的工程的一种替代，它是一种面对复杂场景下的再抽象。而抽象就意味着成本，如果控制不好这种成本，抽象就没有任何的意义。抽象能力是架构设计的基本功，它不但适合于传统的编程，同样适合于AI的大模型的开发设计中。