Eino学习笔记-2
date
Apr 11, 2025
slug
eino-learning-notes-2
status
Published
tags
Eino
LLM
summary
Eino学习笔记，继续学习，想参加黑客马拉松。
type
Post
Components
大模型应用开发的三种应用模式：
- 直接对话模式：处理用户输入并生成相应回答
- 知识处理模式：对文本文档进行语义化处理、存储和检索
- 工具调用模式：基于上下文做出决策并调用相应工具
Eino将常用能力抽象为可复用的组件（Components）
组件抽象和几种模式对应关系如下：
对话处理类组件：
- 模块化处理和大模型交互参数的组件抽象：
ChatTemplate
- 直接和大模型交互的组件抽象：
ChatModel
文本语义处理类组件：
- 获取和处理文本文档的组件抽象：
Document.Loader、Document.Transformer
- 文本文档语义化处理的组件抽象：
Embedding
- Embedding之后将数据索引进行存储的组件抽象：
Indexer
- 将语义相关文本文档进行索引和召回的组件抽象：
Retriever
决策执行类组件：
大模型能够做决策并调用工具的组件抽象：
ToolsNode自定义组件：
用户自定义代码逻辑的组件抽象：
Lambda Eino的组件抽象秉持着以下设计原则：
- 模块化和标准化：将一系列功能相同的能力抽象成统一的模块，组件间职能明确、边界清晰，支持灵活的组合。
- 可扩展性，接口的设计保持尽可能小的模块能力约束，让组件的开发者能方便的实现自定义组件的开发。
- 可复用性，把最常用的能力和实现进行封装，提供给开发者开箱即用的工具使用。
Chain & Graph 编排功能
编排：对Components原子能力进行组合、串联。
- 不能让业务逻辑融入到编排中。
- 大模型应用的核心是 “对提供原子能力的组件” 进行组合串联，组件是编排的 “第一公民”。
- 抽象视角看编排：编排是在构建一张网络，数据则在这个网络中流动，网络的每个节点都对流动的数据有格式/内容的要求，一个能顺畅流动的数据网络，关键就是 “上下游节点间的数据格式是否对齐？”。
- 业务场景的复杂度会反映在编排产物的复杂性上，只有横向的治理能力才能让复杂场景不失控。
- 大模型是会持续保持高速发展的，大模型应用也是，只有具备扩展能力的应用才拥有生命力。
Eino提供了基于Graph模型（edge+node）的，以组件为原子节点的，以上下游类型对齐为基础的编排解决方案。
- 以组件为核心，规范了业务功能的封装方式。
- 业务逻辑复杂度封装到组件内部，编排层拥有更全局的视角，让逻辑层次变得清晰。
- 提供了切面能力，callback机制支持了基于节点的统一治理能力（什么是切面能力）
- 提供了call option的机制，扩展性是快速迭代中的系统最基本的诉求
- 提供了“类型对齐”的开发方式的强化，降低开发者心智负担，把golang的类型安全特性发挥出来
- 提供了“流的自动转换”能力，让“流”在编排系统的复杂性来源榜中除名（Eino流式编程）
Graph缺点：基于 “点” “边” 模型的 Graph 在使用时，要求开发者要使用
graph.AddXXXNode() 和 graph.AddEdge() 两个接口来创建一个数据通道，强大但是略显复杂。
Eino 封装了接口更易于使用的 Chain。Chain 是对 Graph 的封装，除了 “环” 之外，Chain 暴露了几乎所有 Graph 的能力。