Components
Trois modes d'application pour le développement d'apps autour des grands modèles :
- Mode conversation directe : traiter l'entrée utilisateur et générer une réponse
- Mode traitement de la connaissance : traiter sémantiquement, stocker et rechercher des documents texte
- Mode appel d'outils : décider à partir du contexte et appeler les outils correspondants
Eino abstrait les capacités courantes en composants réutilisables (Components).
La correspondance entre ces abstractions et les modes :
Composants de traitement de la conversation :
- Abstraction qui module les paramètres d'interaction avec le grand modèle :
ChatTemplate - Abstraction qui parle directement au grand modèle :
ChatModel
Composants de traitement sémantique du texte :
- Abstraction pour récupérer et traiter des documents texte :
Document.Loader,Document.Transformer - Abstraction pour le traitement sémantique des documents :
Embedding - Abstraction pour indexer et stocker les données après l'embedding :
Indexer - Abstraction pour indexer et rappeler les documents sémantiquement proches :
Retriever
Composants de décision et d'exécution :
Abstraction pour qu'un grand modèle décide et appelle des outils : ToolsNode
Composants personnalisés :
Abstraction pour de la logique de code définie par l'utilisateur : Lambda
Les abstractions de composants d'Eino suivent ces principes de conception :
- Modularité et standardisation : des capacités au même rôle sont abstraites en un module unifié ; les fonctions entre composants sont claires, les frontières aussi, et on peut les composer souplement.
- Extensibilité : le design des interfaces garde une contrainte de capacité aussi petite que possible, pour que les auteurs de composants puissent facilement écrire des composants custom.
- Réutilisabilité : encapsuler les capacités et implémentations les plus courantes, et donner aux développeurs des outils prêts à l'emploi.
Orchestration Chain & Graph
Orchestration : combiner et enchaîner les capacités atomiques des Components.
- Ne pas laisser la logique métier se fondre dans l'orchestration.
- Le cœur d'une app grand modèle, c'est de combiner et d'enchaîner « les composants qui fournissent des capacités atomiques ». Les composants sont les « citoyens de première classe » de l'orchestration.
- Vue abstraite : l'orchestration construit un réseau, et les données circulent dans ce réseau. Chaque nœud a des exigences de format / contenu sur les données qui passent. Pour qu'un réseau de données circule bien, la clé est : les formats de données entre nœuds amont et aval sont-ils alignés ?
- La complexité d'un scénario métier se reflète dans la complexité du produit d'orchestration. Seule une capacité de gouvernance transversale empêche les scènes complexes de déraper.
- Les grands modèles vont continuer à avancer très vite, les apps aussi. Seules les apps qui savent s'étendre ont de la vitalité.
Eino fournit une solution d'orchestration fondée sur le modèle Graph (edge+node), avec les composants comme nœuds atomiques, sur la base de l'alignement de types amont/aval.
- Les composants au centre, ce qui normalise la façon d'encapsuler les fonctions métier.
- La complexité de la logique métier est enfermée dans les composants ; la couche d'orchestration a une vue plus globale, et les couches logiques restent claires.
- Des capacités d'aspect : le mécanisme de callback permet une gouvernance unifiée au niveau des nœuds (c'est quoi, une capacité d'aspect)
- Un mécanisme de call option : l'extensibilité est le besoin le plus basique d'un système qui itère vite
- Un renforcement du mode de développement « alignement de types », pour baisser la charge mentale du développeur et faire jouer la sûreté de types de golang
- Une conversion automatique des flux, pour rayer « le flux » de la liste des sources de complexité d'un système d'orchestration (programmation par flux Eino)
Inconvénient de Graph : un Graph fondé sur le modèle « points » / « arêtes » oblige le développeur à utiliser graph.AddXXXNode() et graph.AddEdge() pour créer un canal de données. Puissant, un peu compliqué.
Eino encapsule une interface plus facile, Chain. Chain est une encapsulation de Graph ; hors les « cycles », Chain expose presque toutes les capacités de Graph.