Composants du noyau sémantique

Le noyau sémantique fournit de nombreux composants différents, qui peuvent être utilisés individuellement ou ensemble. Cet article donne une vue d’ensemble des différents composants et explique la relation entre eux.

Connecteurs de service AI

Les connecteurs de service AI du noyau sémantique fournissent une couche d’abstraction qui expose plusieurs types de services IA provenant de différents fournisseurs via une interface commune. Les services pris en charge incluent l’achèvement de discussion, la génération de texte, la génération d'incorporations, texte en image, image en texte, texte en audio et audio en texte.

Lorsqu'une implémentation est enregistrée avec le noyau, les services de génération de conversation ou de génération de texte seront utilisés par défaut pour tous les appels de méthodes au noyau. Aucun des autres services pris en charge n’est utilisé automatiquement.

Connecteurs de stockage de vecteurs (mémoire)

Les connecteurs de la boutique de vecteurs du noyau sémantique fournissent une couche d’abstraction qui permet l'accès à des boutiques de vecteurs de différents fournisseurs grâce à une interface commune. Le noyau n'utilise pas automatiquement de stockage de vecteurs enregistrés, mais la recherche vectorielle peut facilement être exposée sous forme de plug-in pour le noyau ; dans ce cas, le plug-in est mis à la disposition des modèles de suggestion et du modèle d'IA pour l'achèvement de conversation.

Fonctions et plug-ins

Les plug-ins sont des conteneurs de fonctions nommés. Chacun peut contenir une ou plusieurs fonctions. Les plug-ins peuvent être inscrits auprès du noyau, ce qui permet au noyau de les utiliser de deux façons :

1. Faites-les connaître à l'IA de génération de réponses, afin que l'IA puisse les choisir pour l'invocation.
2. Rendez-les disponibles pour être appelées à partir d’un modèle pendant le rendu du modèle.

Les fonctions peuvent facilement être créées à partir de nombreuses sources, notamment à partir de code natif, de spécifications OpenAPI, de ITextSearch implémentations pour des scénarios RAG, mais également à partir de modèles d’invite.

Modèles d’invite

Les modèles d’invite permettent à un développeur ou un ingénieur d’invite de créer un modèle qui combine le contexte et les instructions pour l’IA avec l’entrée utilisateur et la sortie de fonction. Par exemple, le modèle peut contenir des instructions pour le modèle IA d’achèvement de conversation et des espaces réservés pour l’entrée utilisateur, ainsi que des appels codés en dur aux plug-ins qui doivent toujours être exécutés avant d’appeler le modèle IA d’achèvement de conversation.

Les modèles d’invite peuvent être utilisés de deux façons :

1. En tant que point de départ d’un flux d’achèvement de conversation en demandant au noyau d’afficher le modèle et d’appeler le modèle IA d’achèvement de conversation avec le résultat rendu.
2. En tant que fonction de plug-in, afin qu’elle puisse être appelée de la même façon que n’importe quelle autre fonction peut être.

Lorsqu’un modèle d’invite est utilisé, il sera d’abord rendu, et toutes les références de fonctions codées en dur qu’il contient seront exécutées. L’invite rendue est ensuite passée au modèle IA d’achèvement de conversation. Le résultat généré par l’IA est retourné à l’appelant. Si le modèle de message d'invite avait été enregistré en tant que fonction de plug-in, la fonction aurait peut-être été choisie pour l'exécution par le modèle d'IA de complétion de conversation et, dans ce cas, l'appelant est Noyau Sémantique, au nom du modèle IA.

L’utilisation de modèles d’invite en tant que fonctions de plugin de cette façon peut entraîner des flux plutôt complexes. Prenons par exemple le scénario dans lequel un modèle d’invite A est inscrit en tant que plug-in. En même temps, un modèle d’invite différent B peut être passé au noyau pour démarrer le processus de finalisation de la conversation. B peut avoir un appel codé en dur pour A. Cela entraînerait les étapes suivantes :

1. B le rendu démarre et l’exécution du script d'invite recherche une référence à A
2. A est rendu.
3. La sortie rendue de A est transmise au modèle d'IA de complétion de conversation.
4. Le résultat du modèle IA d’achèvement de conversation est retourné à B.
5. Le rendu de B se termine.
6. La sortie rendue de B est transmise au modèle d'IA de complétion de conversation.
7. Le résultat du modèle IA d'achèvement de chat est retourné à l’appelant.

Considérez également le scénario où il n’existe aucun appel codé en dur de B à A. Si l’appel de fonction est activé, le modèle IA d’achèvement de conversation peut toujours décider que A doit être invoqué(e), car elle nécessite des données ou des fonctionnalités que A peut fournir.

L'enregistrement des modèles d'invite comme fonctions de plugin permet de développer des fonctionnalités décrites à l'aide du langage humain plutôt qu'avec du code réel. La séparation des fonctionnalités dans un plug-in comme celui-ci permet au modèle IA de raisonner séparément au flux d’exécution principal et peut entraîner des taux de réussite plus élevés par le modèle IA, car il peut se concentrer sur un problème unique à la fois.

Consultez le diagramme suivant pour comprendre le flux simple qui démarre à partir d’un modèle de prompt.

Filtres

Les filtres permettent d’effectuer des actions personnalisées avant et après des événements spécifiques pendant le flux d’achèvement de conversation. Ces événements sont les suivants :

1. Avant et après l'invocation de la fonction.
2. Avant et après le rendu de l’invite.

Les filtres doivent être inscrits auprès du noyau pour être appelés pendant le processus de finalisation de la conversation.

Notez que, étant donné que les modèles d’invite sont toujours convertis en KernelFunctions avant l’exécution, les filtres de fonction et d’invite sont appelés pour un modèle d’invite. Étant donné que les filtres sont imbriqués lorsque plusieurs sont disponibles, les filtres de fonction sont les filtres externes et les filtres d’invite sont les filtres internes.