面对多样的LLM应用需求，不管是主流如LangChain这样的基础开发框架，还是以云服务提供的低代码开发平台，都试图在提供基础组件抽象的基础上，提供更便捷的组装与编排这些组件的方式，以帮助构建更高级的AI工作流应用。比如年初发布的LangChain新版本中就引入了LangGraph，以帮助构建Graph表示的AI工作流。（彻底搞懂LangGraph：构建强大的Multi-Agent多智能体应用的LangChain新利器）
最近，另一家主流LLM框架LlamaIndex推出了一项新beta特性：Workflows。提供了一种与LangGraph不同、事件驱动的框架，以编排复杂的RAG或Agent应用工作流，支持灵活的分支、并行与循环等处理。
我们将分成两篇来给大家深入解析与介绍LlamaIndex Workflows：
Workflows的思想、概念与简单演示
基于Workflows构建多分支与循环的复杂LLM应用
回顾：为什么需要Workflows
以两种主流LLM应用开发框架LangChain与LlamaIndex来看，它们都提供了大量的基础组件封装，将常见的RAG或Agent应用开发中常用到的流程环节进行了抽象，简化了开发并避免锁定到特定的底层设施（如大模型、向量库）。利用它们提供的API可以在极短的时间内开发出大模型应用，比如在LlamaIndex中，几行代码可以快速完成一个RAG原型：
......
documents = SimpleDirectoryReader("../data").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()
response = query_engine.query('你的问题')
print(response)但这里的问题是：当面对复杂的业务与优化需求时，不断出现更多的RAG工作模块与算法（重写、路由、排序、图索引等），如何用最佳的方法来组合与协调这些组件，实现更复杂的工作流程？
在框架的早期，可以总结成两种主要方式：
提供更高层的组件与API的封装。比如简单的向量检索器是VectorIndexRetriever，但现在需要增加路由功能，就封装一个带有路由的RouterRetriever；简单的查询引擎是QueryEngine，但现在需要增加重排功能，就增加一个可以传入Reranker模块的参数。
提供链式或DAG（单向无环图）结构的可编排方法。最具代表性的是LangChain框架中的Chain（链）与LCEL（LangChain表达语言）特性；以及LlamaIndex在年初推出的Query Pipeline（查询管道）声明式API特性。它们都在一定程度上提供了编排能力。
LlamaIndex的Query Pipeline提供了一定的编排能力
尽管如此，这种受限的工作流编排仍然面临较大的局限性：
* 高层的组件或API封装缺乏足够的灵活性。体现在：
随着需求的复杂化，需要封装更多的高层组件，框架变得更臃肿。
高层组件的内部过于“黑盒”。比如很难对LangChain或LlamaIndex的ReActAgent组件构建的智能体的执行过程做更精细化的控制。
* 链式或DAG结构的流程无法支持循环，限制了使用场景。但在如今的很多AI工作流中，比如智能体的反思（Relfection）以及一些新的RAG范式（如C-RAG等）都需要循环的支持。
* 不够简洁与直观，也难以调试。
基于这样一些原因，提供一种更强大的工作流定义与编排的支持，也成为了开发框架的发力重点，典型的就是之前介绍过的LangGraph以及本篇将一窥究竟的LlamaIndex Workflows。
LlamaIndex Workflows初探
LlamaIndex Workflows是LlamaIndex近期推出（仍然是测试版）的用来替代之前Query Pipeline（查询管道）的新特性。与LangGraph不同的是，其没有采用类似LangCraph基于图结构的流程编排模式，而是采用了一种事件驱动的工作流编排方式：
工作流中的每个环节被作为step（步骤，代表一个处理动作），每个step可以选择接收（类似订阅）一种或多种event（事件）做处理，并同样可以发送一种或多种event给其他step。通过这种方式，把多个step自然的连接起来形成完整的Workflow。
在这种架构中，工作流的运行不是由框架来根据预先的定义（比如Graph）来调度任务组件执行，而是由组件自身决定：你想接收什么event，做什么处理，并发出什么event。如果组件B接受了A发出的某种event，那么B就会在A发出event后触发执行。
看一个这种方式定义的模拟复杂工作流：
图中涉及到LlamaIndex Workflows中的一些关键概念：
Workflow（工作流）
工作流代表一个复杂的RAG、Agent或者任意复合形式的LLM应用的端到端流程。创建完工作流后，调用run方法，并输入任务即可启动。
Workflow类似LangGraph中的Graph。
Step（步骤）
步骤代表工作流中的单个任务，你可以自由的定义步骤内容。每个步骤接收输入事件（订阅），并返回输出事件。当输入事件发生时，这个步骤就会自动执行。步骤使用Python函数定义。
Step类似LangGraph中的Node。
Event（事件）
事件是一个步骤的输入输出，也是工作流各个步骤之间的数据载体。当事件发生时，“订阅”该事件的步骤就会执行，同时从事件中取出必要数据。事件是一个Pydantic类型对象，可以自由定义结构。注意两个特殊事件：
StartEvent与StopEvent是两个系统事件，代表工作流开始与结束。
StartEvent由框架派发，接收StartEvent的步骤代表工作流的开始。
StopEvent由框架接收，发送StopEvent的步骤代表没有后续步骤。
Event是LlamaIndex中连接Step的机制，作用类似LangGraph中的Edge（边），但机制完全不同。
Context（上下文）
Context是一个用来在整个工作流内自动流转的上下文状态对象，放入Context中的数据可以被所有步骤接收和读取到，可以理解为全局变量。
Context类似LangGraph中的State（状态），但LlamaIndex中各Step的数据交换更多通过event传递，而不是Context。
最后总结：LlamaIndex Workflows是通过一种事件驱动、自我管理的任务组件（step）来组装与编排复杂工作流的方式。此外还具有可视化（生成流程图）、可单步调试、可复用工作流等特性。
Hello,Workflows!
现在我们用LlamaIndex的Workflows来实现一个最简单的带Rerank重排功能的RAG工作流。其工作流程图如下：
这个简单的Workflow反映了一个经典RAG流程的两个工作阶段，索引（indexing）与生成（generate）阶段。这里把两个阶段做成不同的分支，是为了便于一次索引后做多次生成，也体现了Workflows的一个特征：一个Workflow的入口step可以有多个，只要这个step接收StartEvent事件。
看下这个Workflow的简单实现代码：
fromllama_index.core.workflow importEvent
fromllama_index.core.schema importNodeWithScore
#定义两个事件
classRetrieverEvent(Event):
nodes: list[NodeWithScore]
classRerankEvent(Event):
nodes: list[NodeWithScore]
fromllama_index.core importSimpleDirectoryReader, VectorStoreIndex
fromllama_index.core.response_synthesizers importCompactAndRefine
fromllama_index.core.postprocessor.llm_rerank importLLMRerank
fromllama_index.core.workflow import(
Context,
Workflow,
StartEvent,
StopEvent,
step,
)
fromllama_index.llms.openai importOpenAI
fromllama_index.embeddings.openai importOpenAIEmbedding
#workflow定义
classRAGWorkflow(Workflow):
@step
asyncdefindexing(self, ctx: Context, ev: StartEvent)-> StopEvent | None:
#不带query参数，表示索引阶段
ifnotev.get("query"):
documents = SimpleDirectoryReader(input_files=['../../data/sales_tips1.txt']).load_data()
index = VectorStoreIndex.from_documents(documents=documents)
print("Indexing complete")
returnStopEvent(result=index)
else:
returnNone
@step
asyncdefretrieve(
self, ctx: Context, ev: StartEvent)-> RetrieverEvent | None:
#带query参数，表示生成阶段
ifnotev.get("query"):
returnNone
query = ev.get("query")
index = ev.get("index")
awaitctx.set("query", query)
retriever = index.as_retriever(similarity_top_k=2)
nodes = awaitretriever.aretrieve(query)
returnRetrieverEvent(nodes=nodes)
@step
asyncdefrerank(self, ctx: Context, ev: RetrieverEvent)-> RerankEvent:
ranker = LLMRerank(
choice_batch_size=5, top_n=3, llm=OpenAI(model="gpt-4o-mini")
)
new_nodes = ranker.postprocess_nodes(
ev.nodes, query_str=awaitctx.get("query", default=None)
)
returnRerankEvent(nodes=new_nodes)
@step
asyncdefgenerate(self, ctx: Context, ev: RerankEvent)-> StopEvent:
llm = OpenAI(model="gpt-4o-mini")
summarizer = CompactAndRefine(llm=llm, streaming=True, verbose=True)
query = awaitctx.get("query", default=None)
response = awaitsummarizer.asynthesize(query, nodes=ev.nodes)
returnStopEvent(result=response)
w = RAGWorkflow()代码非常清晰易懂：其中四个函数定义了四个step，各个step之间通过输入的event与返回的event进行连接，并驱动整个工作流的自动运行。这里也能体现Workflows与LangGraph的最大区别：LangGraph通过定义图中的edge来体现流程节点之间的关系；而Workflows则是通过step之间的event传递来体现。
你可以通过如下代码运行工作流并测试：
w = RAGWorkflow()
#索引阶段
index = awaitw.run()
#生成阶段，需要带入问题和创建好的索引
result = awaitw.run(query="你的问题", index=index)
asyncforchunk inresult.async_response_gen():
print(chunk, end="", flush=True此外，Workflows提供了工具对定义的Workflow进行可视化，使用如下代码：
fromllama_index.utils.workflow importdraw_all_possible_flows
draw_all_possible_flows(
RAGWorkflow, filename="RAG.html"
)可以生成可视化的工作流程图：
如果你使用过LlamaIndex，可能会觉得这里的代码似乎更复杂化了，这并不意外：Workflows（以及LangChain的LangGraph）显然都是为了更复杂与更灵活化的LLM应用场景而设计，而非简单应用。
下一篇我们将分析如何使用Workflows实现一个复杂的Agent工作流。
| 欢迎光临 链载Ai (https://www.lianzai.com/) | Powered by Discuz! X3.5 |