Modernisation d'HCL Informix : exploiter les données existantes pour l'IA grâce à VectorBlade

Bon, très bien. Herzlich willkommen au webinaire consacré à HCL Informix et à Vector Blade. Je m'appelle Steffen Kleber, je suis chercheur en chef chez Action, je travaille dans cette entreprise depuis plus de neuf ans maintenant et je suis responsable de nos systèmes de bases de données, de notre stratégie et de nos initiatives en matière d'IA au sein de ces systèmes.

Ce dont nous souhaitons parler aujourd’hui, c’est d’une part, bien sûr, de Vector Blade, l’extension pour HCL Informix qui permet d’interroger des données vectorielles et de travailler avec celles-ci, mais aussi, dans une certaine mesure, de la situation dans son ensemble : quelle place occupe Informix dans le paysage actuel de l’IA ? Avant d’entrer dans les détails, j’aimerais aborder les tendances et replacer le tout dans son contexte. D’une part, il est évident que l’IA, de manière générale, modifie notre compréhension de ce que nous pouvons réellement faire avec les données.

En d'autres termes, on travaillait traditionnellement avec des données structurées. On disposait de tableaux, de schémas fixes, et on utilisait pour cela des bases de données relationnelles. L'IA permet désormais de traiter des données non structurées, c'est-à-dire des textes, des images, des vidéos et des fichiers audio, et ce, même en les combinant entre eux.

Il est également possible de traiter conjointement des données structurées et non structurées. Tout cela est rendu possible grâce au type de données vectoriel et à la recherche par similarité. Cela signifie que nous ne sommes plus limités aux requêtes relationnelles (requêtes SQL), mais que nous pouvons également interroger les données en fonction de leur signification, et non plus uniquement à partir de mots-clés exacts.

Et c'est justement ce qui rend cette solution très intéressante dans le contexte de l'entreprise, car plusieurs études – à commencer par le premier rapport publié dès 1998, mais également confirmées par des rapports récents de Gartner et d'IDC – montrent qu'en réalité, 80 % des données d'entreprise sont non structurées. Autrement dit, il s’agit des e-mails, des pages Confluence, des documentations au format PDF qui se trouvent un peu partout et qui recèlent justement une telle valeur qu’il est important d’en tirer parti et d’en extraire de la valeur. D’un autre côté, l’IA modifie bien sûr la manière dont on traite les données.

Avant l'ère de l'IA, nous travaillions bien sûr principalement de manière manuelle. Concrètement, nous gérions et mettions en place des pipelines, nous gérions les schémas, nous nettoyions les données à la main, nous recherchions les erreurs de données, nous administrions les systèmes, nous mettions en place des structures de reporting, tout cela manuellement. La première avancée apportée par l'IA est que l'ensemble de ce processus peut désormais se dérouler sous forme de dialogue.

Cela signifie que nous pouvons bien sûr utiliser le langage naturel pour demander l'analyse de nos données. Mais nous pouvons également formuler des instructions ou poser des questions en langage naturel pour savoir comment utiliser le système, quelles erreurs il peut potentiellement générer et quelles sont les possibilités d'optimisation. Cela facilite grandement l'accès à ces systèmes, même pour les personnes qui n'ont que peu ou pas de connaissances techniques.

Ce qu'il faut retenir, c'est que tout cela est bien sûr encore contrôlé par l'homme. Cela signifie que je dois poser activement des questions à mon système. En d'autres termes, je dois en principe déjà identifier les problèmes et me contenter de demander comment l'ensemble peut être résolu.

À l'ère de l'IA, nous nous orientons vers des agents autonomes. Cela signifie qu'ils sont guidés par des objectifs. En tant qu'être humain, je n'ai donc plus besoin de savoir quel est l'objectif ni comment y parvenir ; je peux laisser ces agents travailler de manière autonome.

Ils détectent les problèmes de manière autonome, ils planifient et mettent en œuvre des solutions, ce qui permet justement d'assurer la maintenance des systèmes 24 heures sur 24, d'effectuer des requêtes automatisées, et peut-être même que les agents identifient des structures ou des problèmes dans les données que l'on n'aurait jamais pu repérer en tant qu'être humain. Nous avons justement ces deux aspects. D'une part, l'IA permet de traiter davantage de données, mais elle nous permet également d'adopter une approche totalement différente vis-à-vis des données.

La question qui se pose alors naturellement est la suivante : les bases de données ont-elles encore leur place aujourd’hui ? Et c’est l’un des messages clés que nous souhaitons faire passer aujourd’hui. Les bases de données relationnelles restent très importantes ; elles constituent toujours le socle fiable sur lequel reposent l’IA et les agents.

Il ne faut pas l'oublier. Les bases de données sont fiables de par leur conception même. Nous connaissons tous les propriétés ACID, et c'est particulièrement important à l'ère des agents : ceux-ci doivent pouvoir travailler sur des données cohérentes et considérer la base de données comme une source unique de vérité.

En d’autres termes, je dispose d’un système qui garantit la cohérence et la qualité de mes données, sans qu’elles soient dispersées dans différentes structures de dossiers, etc. À titre d’anecdote : j’ai par exemple assisté à un webinaire organisé par Antropic, qui réfléchit à la manière dont des agents pourraient travailler ensemble sur des fichiers. Ce sont là des problèmes que le monde des bases de données a déjà résolus depuis des décennies.

simultanéité et les applications multiutilisateur. Informix est particulièrement adapté à ce type d'application, car il est multimodal et extensible. Cela signifie qu'Informix peut stocker différents types de données, et pas seulement des données structurées.

Avec Vector Blade, dont il est question aujourd’hui, nous ajoutons les vecteurs à l’ensemble, ce qui nous permet d’étendre HCL Informix de manière à ce qu’il soit également prêt pour les applications d’IA. De plus, les agents modifient légèrement le « charge de travail » que nous envoyons aux systèmes. Les agents effectuent beaucoup plus de requêtes répétitives à haute simultanéité , et c’est là que les décennies d’optimisation de l’ requête et de la sécurité des systèmes de bases de données portent leurs fruits, permettant de garantir la rapidité et la sécurité de ces requêtes d’agents.

Les bases de données restent aujourd'hui encore très pertinentes, en particulier pour les agents. Voici les principales informations que nous souhaitons vous communiquer aujourd'hui : HCL Informix sera compatible avec l'IA. Nous pourrons donc mettre en œuvre l'IA là où les données se trouvent déjà.

Cela est rendu possible grâce au type de données vectorielles natif et au MCP. De plus, nous nous pencherons bien sûr sur les interfaces linguistiques qui permettent de « dialoguer » avec les données, et nous examinerons les perspectives d'avenir. Il s'agit d'outils basés sur des agents qui permettent justement de travailler plus facilement avec le système et de bénéficier d'une aide à l'administration.

Bon, parlons d'abord du Vector Blade. Pour replacer les choses dans leur contexte, ce modèle issu des systèmes RAG (Retrieval Augmented Generation) est en réalité assez connu. Je voudrais néanmoins revenir brièvement sur ce point ici.

Qu'avons-nous ? Nous disposons d'une grande quantité de données non structurées. Il peut s'agir de textes, d'images ou de vidéos.

Nous décomposons ces données en blocs à l'aide d'un mécanisme de segmentation, puis nous les intégrons dans un espace vectoriel. Cela signifie que nous utilisons un modèle d'intégration qui, en principe, mappe ces blocs sur un espace de haute dimension, et chacun de ces blocs devient un point dans cet espace. Nous stockons ensuite ces vecteurs, qui décrivent justement ces points, dans la base de données, dans notre cas HCL Informix Vector Blade, ce qui nous permet ensuite, grâce à une recherche par similarité, de récupérer des documents pertinents, des segments pertinents, de les transmettre à un modèle et ainsi d’obtenir des réponses qui reposent sur des données que nous ne stockons en réalité pas.

Mais aussi dans le savoir-faire propriétaire de l'entreprise. Grâce à HCL Informix Vector Blade, nous disposons désormais de cette fonctionnalité en natif dans Informix. Cela signifie qu'il s'agit d'un composant intégré au serveur de base de données.

Elles se trouvent juste à côté des données relationnelles. Je n'ai donc pas besoin d'un système supplémentaire pour gérer mes embeddings et mes données vectorielles, et je n'ai ainsi pas non plus besoin de connectivité supplémentaire ni de configuration de sécurité. Je peux interroger l'ensemble via la même interface SQL habituelle dont je dispose déjà.

L'ensemble est isolé et évolutif. Nous avons conçu l'Informix Vector Blade de manière à ce que les routines qu'il contient s'exécutent dans une classe VP distincte, appelée LVec. Cela signifie que toutes les opérations et tous les threads utilisés par le Vector Blade n'affectent pas les threads existants du système de base de données opérationnel.

De plus, la fiabilité, dont nous avons bien sûr besoin pour un tel système de base de données, n'en est pas affectée. Il fonctionne de manière isolée. Voyons brièvement comment cela fonctionne.

Nous disposons donc de documents et de données d'images. Par exemple, nous allons maintenant construire le pipeline au niveau de la couche applicative. Les documents sont découpés en blocs, intégrés à l'aide d'un modèle d'embedding, puis convertis en vecteurs, qui sont ensuite enregistrés dans la base de données Blade.

C'est là un point essentiel qu'il faut bien comprendre. Informix et Vector Blade servent à interroger et à stocker ces blocs ou ces vecteurs. Le reste se passe au niveau de la couche applicative.

Le reste dépend généralement de l'application. Autrement dit : comment segmenter mes données, et de quelles données est-ce que je dispose exactement ? Informix, grâce à Vector Blade, est toutefois capable de gérer la granularité des vecteurs.

Concrètement, j'enregistre mes vecteurs dans la base de données, dans Vector Blade, et je peux ensuite, lorsque j'ai une requête, par exemple : « Quels ont été les chiffres de vente l'année dernière ? » La question est alors potentiellement décomposée en « chunks » ou des mots-clés sont sélectionnés. Ceux-ci sont à nouveau traités par le même modèle d’embedding, ce qui me permet d’obtenir un vecteur décrivant ma question, puis je peux effectuer une recherche par similarité.

La recherche par similarité consiste à examiner mon espace à haute dimension et à rechercher les points de cet espace qui sont particulièrement proches de mon vecteur, celui qui correspond à ma question. Je peux donc utiliser des mesures de similarité dans l’espace vectoriel pour déterminer quels « chunks », quels vecteurs, correspondent le mieux à ma question. Vector Blade me renvoie alors ces chunks pertinents, que je peux ensuite fournir comme contexte à mon LLM afin d’obtenir une réponse à ma question.

Et cette réponse se rapporte bien sûr au contexte que j'ai tiré du Vector Blade. J'ai brièvement évoqué l'isolation tout à l'heure. C'est relativement important.

Nous voyons ici à nouveau toutes les tâches liées à la base de données qui existent à ce jour. Celles-ci sont indépendantes du Vector Blade. Dans le Blade, je peux insérer des vecteurs, les consulter et même les modifier.

Cela signifie que nous prenons également en charge les opérations de modification. Comment puis-je m'y mettre dès maintenant ? Pour commencer, je dois installer le module dans le répertoire Informix, plus précisément dans le répertoire Extend.

Nous partons d'une image, d'un modèle d'embedding. Cela signifie que nous disposons déjà d'une fonction. J'y reviendrai plus tard lorsque j'aborderai les fonctions importantes.

Nous disposons d’une fonction qui facilite la conversion de texte en représentations vectorielles. Nous n’avons donc pas nécessairement besoin de tout mettre en place au niveau de la couche applicative. Nous proposons un modèle de représentation qui permet tout simplement de se lancer et de tester facilement.

Et tout cela s'appuie sur OpenAI. Pour l'utiliser, il suffit de définir une clé OpenAI via la variable d'environnement, qui sera ensuite utilisée pour appeler un modèle d'embedding. Je peux ensuite enregistrer le Blade dans la base de données. De nombreux exemples sont fournis, ce qui me permet de commencer immédiatement à utiliser le système. Je voudrais passer en revue les principales fonctions qui sont déjà prédéfinies.

Ce qu’il faut comprendre ici, c’est que le Vector Blade, du fait qu’il fonctionne de manière indépendante, enregistre en principe les embeddings séparément. Il existe, comme indiqué ici sous le nom de « Lens Table Name », des tables au sein du Vector Blade, ainsi que des tables au format Informix. Les embeddings sont stockés au format Informix, mais leur consultation s’effectue via cette table « Lens ».

Cela signifie que je peux créer ici une table de vecteurs à l'aide de la fonction « L Vector Create Table ». Je dois simplement indiquer le nombre de dimensions de mes vecteurs. Cela dépend simplement du modèle d'embedding que j'utilise.

Les modèles d'embedding ont différentes dimensions de sortie, généralement 384, 768 ou 1 534. Ce sont les modèles les plus courants. Bien sûr, plus ces dimensions sont grandes, plus mes requêtes seront précises au final et plus je pourrai représenter de données différentes, mais plus le temps d'exécution de l'embedding et de la recherche sera long.

Voici un exemple : je peux créer une table de démonstration simple comportant trois dimensions. De la même manière, je peux bien sûr supprimer une table à l'aide de la commande « Drop Table » en indiquant le nom de la table. Et pour y insérer des données, j'ai d'une part la possibilité d'exécuter ce qu'on appelle un « Sync Insert » : je précise le nom de la table, et une telle table vectorielle présente alors toujours le même schéma.

Il y a un identifiant (ID), une colonne de vecteur et une colonne de métadonnées. L’exemple ci-dessous l’illustre bien : l’identifiant « 1 » pour cette tupla, puis le vecteur sous forme de chaîne de caractères, et « métadonnées » peut également être n’importe quelle chaîne de caractères. Je pourrais donc, par exemple, créer un document au format JSON.

De la même manière, je peux également supprimer ces tuples à l'aide de leur ID, c'est-à-dire via une opération « Sync Delete ». Et pour accélérer considérablement la recherche, il existe des structures d'index. Les structures d'index sont un concept bien connu dans le domaine des bases de données.

En principe, je privilégie la capacité de mise à jour au détriment de la vitesse de récupération ou de la vitesse de requête. Lorsque je dispose d'un index, la requête est généralement plus rapide. Cela a toujours été le cas pour les arbres B et autres structures similaires.

Mais si j'ajoute de nouveaux tuples, je dois également mettre à jour l'index. Ce que je peux donc faire ici, c'est indiquer le nom de la table, préciser le type d'index — j'y reviendrai plus en détail un peu plus tard — et le nombre de partitions pour l'index. Il s'agit d'un paramètre d'optimisation des performances.

L'index est ainsi automatiquement créé sur la colonne vectorielle. Et puis vient la fonction la plus importante : « L Vector Search ». C'est celle qui me permet de mettre en œuvre ma recherche.

Je précise à nouveau le nom de la table et le vecteur de recherche. Il s’agit donc du vecteur que j’obtiens lorsque je génère un vecteur à partir de ma requête à l’aide d’un modèle d’embedding ; c’est en quelque sorte le point que je recherche dans mon espace vectoriel. Et maintenant, Vector Blade effectue une recherche par similarité autour de ce point : quels sont les points les plus proches ?

Je peux maintenant indiquer ici le nombre de « voisins » que je souhaite avoir. Il s'agit là aussi d'un paramètre de réglage qui dépend en partie de l'application. En général, on cherche à obtenir un contexte composé de trois à dix « chunks », que l'on souhaite ensuite fournir comme contexte à son modèle de langage de grande capacité (LLM).

Il s'agit de la fonction d'embedding dont je viens de parler, qui permet de calculer assez facilement un tel embedding si je dispose d'une clé OpenAI et que je l'ai définie dans la variable d'environnement. L'appel est très simple : je saisis une chaîne de caractères et la procédure renvoie alors un vecteur. Et ce qui est génial, c'est que je peux aussi combiner le tout.

Je peux donc effectuer une instruction INSERT, spécifier la table, indiquer l'ID, puis appeler cette fonction d'embedding à la place du vecteur afin de calculer directement l'embedding, sans avoir à le faire manuellement. Il existe également un autre ensemble de fonctions prédéfinies. Il y a notamment une fonction de distance, ce qui signifie que je peux calculer manuellement des distances.

C'est justement sur cela que repose, en fin de compte, la fonction de recherche. Je peux comparer des vecteurs entre eux. Je peux effectuer une recherche en ajoutant un filtre supplémentaire.

C'est très intéressant. Cela signifie que je peux encore effectuer des requêtes sur les métadonnées à l'aide de primitives simples. Par exemple, pour vérifier si un mot-clé spécifique est présent ou si une clé donnée est respectée.

Je reviendrai plus tard sur l'importance de la recherche dont je viens de parler. C'est particulièrement important dans le contexte de l'entreprise. En général, j'effectue mes recherches en fonction de certains critères et non pas sur l'ensemble de ma base de données.

Et puis il y a l'opération de synchronisation en masse, qui me permet, à partir de ma table Informix, que j'y aie inséré des vecteurs ou que la table existe déjà, de synchroniser en une seule fois, en masse, tous mes vecteurs avec la table de vecteurs dans Vector Blade. Il existe toute une série de types d'index pris en charge. Il s’agit, si l’on Si l’on se documente un peu sur l’espace vectoriel, des types courants.

Il existe un index plat qui permet en fait d'effectuer une recherche exacte. Cela signifie que j'obtiens vraiment une précision de 100 %. Il y a aussi la quantification, qui, en principe, compresse la représentation vectorielle.

Cela me donne généralement des résultats relativement imprécis, mais très rapides. Et il existe le HNSW, c'est-à-dire un indice arborescent, le « Hierarchical Navigable Small World Index ». À l'instar d'un arbre classique, il commence par un niveau de granularité grossier, recherche le premier voisin, puis, à partir de ce voisin, poursuit son exploration en adoptant un niveau de granularité plus fin.

Il existe différents types d'index que l'on peut évaluer. Comme toujours, un index représente en principe un compromis entre vitesse et précision. Si j'ai besoin d'une précision de 100 %, je devrais alors opter pour l'index plat.

Mais si j'accepte qu'il y ait un résultat non pertinent parmi mes dix résultats, alors je peux tout à fait utiliser un tel indice HNSW.

Bon, passons à la démonstration. J'ai préparé deux choses. D'une part, j'ai tout mis en place pour que nous puissions tester le tout de manière pratique dans la console.

Une seconde. Je partage à nouveau mon écran. Zoomons encore un peu.

J'espère que c'est bien clair. Nous allons maintenant revenir à une base de données, nous allons créer une base de données de test. Et ce que nous pouvons faire maintenant, c'est tester un peu les fonctions qui sont déjà disponibles.

Nous pouvons essayer une fonction de distance entre deux vecteurs, 111 et Et ici, on peut en principe spécifier le type de fonction de distance. Une distance L2 est une simple distance spatiale. Cela signifie qu’elle calcule la différence de chaque composante, élève le tout au carré, additionne le résultat et, enfin, en extrait la racine carrée, ce qui me donne ainsi une idée de la distance réelle qui sépare les points dans l’espace.

Ici, dans ce cas, 15. Et il existe d'autres mesures de distance, par exemple la distance cosinus. Et on constate ici que la distance est nulle, car la distance cosinus ne dépend pas de la distance proprement dite, mais de la direction.

Ce qui importe dans ce genre de récupération, c’est que c’est en réalité la direction qui compte, et non la longueur du vecteur. On constate que 111 et 101010 pointent exactement dans la même direction. Cela signifie qu’ils expriment très probablement la même chose, d’après le modèle d’embedding ou, plus précisément, compte tenu de la manière dont ces modèles sont conçus.

Cela signifie que la distance est ici nulle. Ils sont donc très similaires. La distance cosinus est généralement utilisée pour les recherches par similarité.

En réalité, L2-Distanz ne sert qu'aux calculs mathématiques et moins à cette recherche par similarité. Voici ce que je peux faire à titre d'exemple : je vais créer une table Informix. Il s'agit d'une instruction Create Table tout à fait classique : j'ai un identifiant, un embedding et des métadonnées, et je peux maintenant y insérer une série de valeurs.

D'abord, il y a zéro avec -100, -100, -100. Une chaîne d'exemple. Et je peux maintenant ajouter deux autres tuples de la même manière.

Et ce que je peux faire maintenant, c'est utiliser cette fonction LVector pour créer une nouvelle table dans Vector Blade. Donc : LVector Create Table, je nomme la table « eins », dimension trois, car les vecteurs de cette table ont une dimension de trois. Il s'agit en effet exactement de ceux que j'ai déjà insérés dans la table Informix.

Et ce que je fais maintenant, c'est que j'utilise la fonction « Bulk Sync », comme je l'ai expliqué tout à l'heure. Je spécifie la table Informix, je spécifie la table Vector-Blade, la colonne ID et la colonne vecteur. Et la routine m’aide alors à synchroniser une fois tous les vecteurs déjà présents dans la table Informix avec ma table Vector-Blade.

Et ce que je peux faire maintenant, c'est lancer une requête SQL tout à fait classique, que nous allons examiner de plus près. J'ai deux tables ici. J'ai la table Informix et j'ai la table Vector Blade.

Utilise donc maintenant la fonction de recherche pour trouver un vecteur de recherche, le 222 dans ce cas précis. C'est celui qui provient du modèle d'embedding mentionné dans ma question. Je précise que je souhaite obtenir trois voisins, calculés selon la distance cosinus.

Je l'affecte au type « LVector Search Result ». Il s'agit justement de cette structure composée d'un identifiant, d'un vecteur et d'un champ de métadonnées. Et ce que je dois faire maintenant, c'est joindre ces deux tables.

Je prends donc l'ID Vector de ma table Informix et la colonne ID de ma table Search issue de mon Vector Blade, je les joins ensemble, puis je trie le tout en fonction de la distance obtenue par la recherche par similarité. Lorsque j’exécute maintenant cette opération, je constate que 222 est le plus proche de 101010 selon la distance cosinus. C’est exactement l’exemple que nous avons vu tout à l’heure.

La distance est nulle. Par rapport à 004, la distance est de 0,42 et, par rapport à -100,-100,-100, la distance cosinus est maximale, soit deux. Cela signifie qu’ils sont exactement opposés l’un à l’autre et qu’ils pointent exactement dans des directions opposées.

C'est logique. C'est donc la construction « requête » que je peux utiliser à la fin pour calculer une distance vectorielle à l'aide d'une seule requête SQL. Et maintenant, j’ai bien sûr la possibilité d’utiliser toutes les données contenues dans ma table Informix : grâce à cet identifiant, j’obtiens les éléments voisins, et je peux désormais utiliser toutes les colonnes de ma table Informix, qu’il s’agisse de données de type chaîne de caractères ou de données entières, en les intégrant comme contexte dans mon LLM, ce qui me permet d’obtenir le contexte dont j’ai besoin pour répondre à ma question.

Comme je l'ai déjà dit tout à l'heure, tout cela repose en grande partie sur la logique qui se déroule en réalité au niveau de l'application. Cela signifie que nous disposons ici d'une petite application de démonstration qui permet de présenter le processus de bout en bout. Je partage à nouveau mon écran et je suis encore en train de chercher.

Il s'agit d'une application de démonstration que nous avons développée en interne à des fins de démonstration. Ce que l'on peut faire ici, c'est vérifier des documents. Concrètement, je peux sélectionner des documents via « Upload Document », puis les télécharger.

Et j'ai pris la newsletter Informix de la semaine dernière, qui m'est parvenue via la liste de diffusion, et je peux désormais mettre le tout en ligne. Ce que fait l'application à présent, c'est qu'elle analyse le document et le découpe automatiquement en segments pertinents. Nous utilisons ici le « semantic chunking » : cela signifie qu’elle tente de diviser le document à des limites logiques, puis utilise un modèle d’embedding pour intégrer l’ensemble dans Informix.

Nous voyons maintenant que tout a bien fonctionné. Nous avons généré 29 chunks et je constate également que le document est chargé. Je peux désormais poser ici des questions portant spécifiquement sur ce document.

La fonction « Nullif » faisait partie de la newsletter. Cela signifie que nous pouvons toujours nous demander ce que fait réellement cette fonction. Et ce que nous voyons ici, de ce côté-ci, c'est que dans le journal d'activité, nous constatons que l'ensemble est interrogé et nous pouvons désormais vérifier quels chunks ont réellement été utilisés.

Et nous voyons maintenant ici, dans ce document, l’astuce technique « Funktion Nullif » : c’est le fragment qu’il a identifié comme le plus pertinent, précisément parce que l’ensemble a été converti en « Embarqué », puis repéré grâce à la recherche par similarité. Il a utilisé ce fragment ainsi que d’autres fragments, puis a fait appel à GPT 4.0 en lui précisant qu’il s’agissait d’un assistant chargé de répondre à des questions sur des documents ; il a joint ces trois fragments et a demandé ce que faisait la fonction « Nullif ». Et voici le résultat que nous obtenons : un aperçu de la fonction `nullif`, sa syntaxe, ses différents arguments, et il explique en gros ce que fait la fonction, à savoir renvoyer « null » lorsque les arguments sont identiques.

Et c'est justement ce à quoi fait référence le premier argument. Faut-il bien sûr concevoir une telle application de manière à la limiter, afin qu'elle ne réponde réellement qu'à partir de ce qu'elle peut trouver dans les chunks, dans le contexte ? Les grands modèles de langage (LLM) disposent en effet d'un certain savoir de base.

En d'autres termes, si je posais maintenant une question qui ne figure pas dans le document, il se pourrait quand même que j'obtienne une réponse.

Mais d'un autre côté, il y a bien sûr l'ensemble de la propriété intellectuelle de mon entreprise, toutes mes connaissances au sein de l’entreprise, qui ne sont bien sûr accessibles au public nulle part, je peux les mettre à la disposition de l’IA grâce à une telle application, et ce en toute sécurité, si j’utilise par exemple des modèles d’IA hébergés par mes soins, ce qui me permet de profiter tout autant de l’IA, sans avoir à rendre mes données publiques où que ce soit. Je partage à nouveau mon écran. Est-ce qu’il a disparu ?

Bon, je vais faire une toute petite pause ici et j'en profite pour parcourir les questions, car en principe, la partie consacrée à la « Vector Plate » est terminée. Ensuite, nous verrons un peu comment tout cela s'inscrit dans le contexte plus large de l'IA. Monsieur le Dr.

Aspiazu demande : « À l'avenir, l'IA rendra-t-elle les systèmes de bases de données comme Informix obsolètes ? » Je ne pense pas. Je pense que nous aurons encore davantage besoin de la cohérence et de la fiabilité des systèmes de bases de données, mais aussi de la possibilité de travailler sur des données dans le cadre des « Asset Properties », sous « High- simultanéité ». Les agents utiliseront donc des bases de données, et nous avons précisément besoin de ces propriétés, qui ont été optimisées et étudiées depuis des décennies.

C'est justement de ça dont nous aurons besoin. Je pense que ce rôle va prendre encore plus d'importance et que cela restera une base de données fiable. La distance cosinus indique-t-elle la direction d'un vecteur ?

La direction d'un vecteur est indiquée par le vecteur lui-même, c'est-à-dire, en principe, la combinaison de toutes ses dimensions. La distance cosinus indique l'angle entre deux vecteurs. Le cosinus de cet angle correspond donc à la distance cosinus.

Si l'on imagine donc qu'un vecteur pointe dans cette direction et qu'un autre vecteur pointe dans cette direction, alors la distance cosinus correspond exactement au cosinus de l'angle qui les sépare. Cela signifie qu’un vecteur orienté ainsi et un vecteur orienté ainsi, mais beaucoup plus long – c’est ce que nous venons de voir –, ont une distance cosinus nulle, car l’angle qui les sépare n’existe tout simplement pas. Combien d’espace cet exemple tiré de la newsletter occupe-t-il à lui seul ?

Je ne peux pas vous répondre comme ça, sur-le-champ. Il faudrait que je vérifie cela. Monsieur Aspeato, vous avez encore levé la main.

Vous souhaitez poser une autre question ? D'accord. Je vais d'abord poursuivre sur ce sujet.

Nous serons ravis de répondre à vos questions à la fin. Si vous envisagez actuellement, dans le cadre de votre entreprise, de développer ou de mettre en œuvre ce type d’applications, la question qui se pose naturellement est la suivante : puis-je utiliser la base de données dont je dispose déjà ou ai-je besoin d’une base de données vectorielle spécifique ? Et je pense qu’il est toujours important de bien souligner cette distinction.

Une base de données multimodale, telle que HCL Informix, est particulièrement adaptée lorsque l'on dispose déjà d'une base de données relationnelle et que l'on souhaite tester cette solution ou développer ce type d'applications ; elle présente bien sûr l'empreinte d'un système de base de données à part entière. L'ensemble est optimisé pour les charges de travail relationnelles. Cela signifie que l'on n'obtiendra pas des performances de récupération de l'ordre de quelques millisecondes.

On s'en approche, mais le grand avantage, c'est que l'on stocke l'ensemble de manière unifiée avec les propriétés des ressources. Cela signifie que l'on stocke ensemble ses données vectorielles et ses données relationnelles, et l'on bénéficie bien sûr de l'avantage d'avoir un seul système à gérer. Si l’on ajoutait maintenant une base de données vectorielles distincte – il existe différentes bases de données sur le marché –, celle-ci aurait bien sûr un encombrement relativement faible.

Je peux très bien déployer cela sur n'importe quel appareil en périphérie et obtenir ainsi une vitesse optimale pour la recherche vectorielle, mais je dois alors tenir compte, lors de l'exploitation, du fait que la cohérence est distribuée. Cela signifie que si je pars du principe que j’insère un tuple dans ma base de données relationnelle tout en insérant simultanément l’embedding dans la base de données vectorielle, je dois bien sûr m’assurer que cela se fasse via les « Asset Properties », c’est-à-dire soit entièrement, soit pas du tout. Sinon, l’un des deux systèmes sera désynchronisé.

Et je dois bien sûr également tenir compte de la maintenance et de l'administration d'un tel « déploiement » distribué. C'est bien plus complexe qu'un système monolithique. Et ce que j'ai déjà brièvement évoqué tout à l'heure, c'est la recherche hybride, qui est justement très importante, car elle est nécessaire dans les applications pratiques.

Il s'agit en effet de la combinaison entre la recherche par similarité et la recherche par mots-clés ou les filtres relationnels, que l'on connaît déjà. Voici un exemple simple : j'ai deux documents, « Machine A » et « Machine B ». L'une peut être mise hors tension en débranchant la prise, tandis que l'autre doit être mise hors tension correctement via l'interface.

Si, en tant qu'utilisateur, je pose maintenant la question : « Comment éteindre la machine B ? », il peut tout à fait arriver, selon la façon dont mon application est conçue, que j'obtienne les deux extraits, car ils correspondent bien sûr tous les deux, et l'IA me dit alors qu'on peut débrancher la prise ou utiliser l'interface, car elle ne peut bien sûr générer que la réponse issue du contexte qui lui est fourni. Si j’utilise maintenant la recherche hybride, je peux bien sûr, grâce à la recherche par mot-clé, exclure le document concernant la machine A ; je n’obtiens alors que le document relatif à la machine B comme contexte, ce qui permet bien sûr à mon LLM de répondre correctement. C’est là un avantage majeur de systèmes tels qu’Informix avec Vector Blade.

Je peux continuer à utiliser la recherche relationnelle et l'étendre grâce à la recherche par similarité. Dans notre requête précédente, j'aurais également pu préciser que je souhaitais n'inclure dans mon ensemble de résultats que les ID inférieurs à trois ou inférieurs à deux. Bon, comment tout cela s’inscrit-il désormais dans le tableau d’ensemble et que faisons-nous chez HCL et Actian pour envisager le tout dans un contexte plus large ?

Le premier point que je souhaite aborder est le « Model Context Protocol », que beaucoup d'entre vous connaissent certainement déjà. La raison d'être de ce protocole est simple : les LLM disposent d'un savoir limité. Les LLM ont été formés à un moment donné.

À partir de ce moment-là, ils ne disposent en principe plus d’aucune nouvelle information. Bien sûr, les modèles que nous utilisons actuellement via les services d’OpenAI ou d’autres plateformes ont bien sûr accès à de nouvelles données, à Internet, en temps réel, mais nous souhaitons bien sûr donner au système accès à nos données en temps réel au sein de l’entreprise et nous souhaitons également lui donner la possibilité d’effectuer des actions. Et le problème fondamental est désormais le suivant : comment puis-je connecter ces LLM isolés au monde extérieur et comment puis-je gérer le contexte ?

Et ce que je pourrais bien sûr faire tout simplement, c'est créer une application et y intégrer ensuite le pilote de chaque outil que je souhaite utiliser. C'est-à-dire le client JDBC de ma base de données, une API de mon serveur de messagerie. Ou ce genre de choses.

Cela signifie que chacune de mes applications devrait connaître chacune de mes API d'outils. Je dois donc créer n fois m intégrations. C'est en réalité impossible à gérer et à faire évoluer.

La solution réside dans un langage commun pour cette couche, et c'est précisément ce qui a motivé la création du Model Context Protocol. On dit que c’est le « port USB-C » des applications d’IA. Il s’agit d’une norme open source qui vient d’être transférée par Anthropic à la Linux Foundation ; c’est donc véritablement la norme de facto, qui assure la correspondance entre les API spécifiques à chaque outil et l’API générique du MCP.

Comme chaque fournisseur met à disposition un serveur MCP, je peux y connecter n'importe quel agent et n'importe quel LLM. Les agents ont ainsi la possibilité, conformément à la norme MCP, de détecter de manière dynamique les outils mis à disposition via le serveur. Cela signifie que je peux lancer un agent ; celui-ci peut alors vérifier quels outils sont disponibles sur le serveur MCP, puis sélectionner les outils adaptés à une tâche spécifique, par exemple pour exécuter une requête SQL ou modifier un paramètre de configuration.

Nous avons également déployé un serveur MCP pour HCL Informix. Celui-ci permet justement aux agents de prendre des décisions en se basant sur les données réelles du système, réduisant ainsi les « hallucinations ». Il donne accès aux données et aux métadonnées.

Cela signifie que nous permettons ainsi un accès très granulaire au schéma, à la logique métier, mais aussi aux procédures et aux données elles-mêmes. Il y a des fonctions, il y a le schéma, il y a le « Read SQL », qui correspond à une simple requête de lecture des données. Notre approche consiste à transformer ainsi les agents passifs en utilisateurs actifs.

Cela signifie que nous allons intégrer des outils de création et d'administration à ce serveur MCP, qui permettra justement aux agents d'insérer et de modifier des données, ainsi que d'effectuer des tâches administratives sur le système de base de données. Nous y reviendrons plus tard, lorsque nous examinerons la feuille de route relative aux agents. Il convient bien sûr de prendre ces informations avec prudence.

Il faut être très prudent à ce sujet, et c’est justement pour cela qu’il est important de disposer de MCP comme couche de sécurité entre l’environnement des agents et celui de la base de données. Car c’est le seul niveau d’abstraction qui permette réellement, grâce à des mécanismes d’accès finement granulaires, à des mécanismes de « gouvernance » et à ce qu’on appelle des «Guard Rails», de limiter ce que l’agent peut réellement faire et d’être vraiment sûr de ne pas interférer avec les systèmes en fonctionnement. Le deuxième point que nous avons brièvement évoqué tout à l’heure dans l’introduction concerne les analyses orientées dialogue.

Une affirmation très simple : chaque chiffre au sein de l'entreprise a une histoire, et c'est justement cela qui compte au final. Quand je pose une question ou que j'examine un tableau de bord , j'apporte moi-même un certain contexte afin de pouvoir replacer ce chiffre dans son contexte. Le nombre de clients correspond-il à ce que je suppose, ou quelque chose comme ça ?

Un agent ne dispose bien sûr pas de ce contexte. Cela signifie que si je demande à un agent : « Combien avons-nous gagné au dernier trimestre ? », celui-ci peut donner ces quatre réponses, et chacune d'entre elles serait en réalité correcte. Mais uniquement pour les personnes concernées au sein de l'entreprise.

Il est donc important, pour ce type d'analyses, de fournir un contexte à un agent. Et c'est précisément là que réside le problème. En effet, les LLM sont probabilistes.

Cela signifie que je peux poser deux fois la même question et obtenir deux réponses différentes, car l'agent a décidé, en fonction de mon schéma de base de données, de formuler une autre requête. Celle-ci peut être tout aussi correcte, mais pas dans le contexte dans lequel je la pose, car je travaille, par exemple, au service financier. Le problème, c'est que les grands modèles linguistiques sont très flexibles, mais, comme je l'ai dit, imprévisibles.

Et bien sûr, l'analyse classique est fiable. Nous connaissons les tableaux de bord et la BI classique, mais ils sont très rigides. Cela signifie que si je fais une demande aujourd'hui pour connaître nos résultats financiers, je devrai peut-être d'abord m'adresser à l'équipe BI, qui devra d'abord créer un tableau de bord .

J'aurai peut-être la réponse d'ici la fin de la semaine. La solution que nous avons mise au point à cet effet est Actian AI Analyst. Elle combine les avantages des deux approches.

Il est flexible et fiable. Il s'agit en principe d'un agent linguistique naturel qui me fournit des réponses fiables et reproductibles, car il est ancré dans le contexte professionnel. Voici un bref aperçu de cette solution que nous avons développée.

Nous pouvons formuler des requêtes métier en langage naturel et obtenir des analyses instantanées. Pas de tableaux de bord, personne n'a besoin d'écrire de requêtes SQL. Cela signifie que tout le monde, y compris les personnes sans compétences techniques, peut utiliser cet outil pour obtenir des informations sur les données HCL ou Informix, par exemple.

L'analyste IA s'appuie pour cela sur un modèle sémantique. Ce modèle contient toutes les définitions métier, ainsi que tous les indicateurs que j'ai validés ou que quelqu'un d'autre a validés. En d'autres termes, ce modèle sémantique décrit en principe mon ensemble de données et ma base de données.

Chaque réponse explique clairement comment le résultat a été obtenu. Autrement dit, on voit toutes les étapes de raisonnement suivies par l'agent pour traiter la requête. On voit la requête qui a été formulée, et l'outil s'intègre facilement aux outils que les équipes utilisent au quotidien : Slack, Teams, ou encore un navigateur Web.

Ce qui est intéressant, c'est que je peux vraiment mettre cela en place en quelques heures et obtenir des réponses à mes résultats en moins d'une minute. Voici un bref aperçu du fonctionnement de tout cela. Comment fait-on pour que de telles requêtes soient réellement reproductibles et correctes ?

Nous acceptons toutes les demandes commerciales qui nous parviennent. Nous laissons l'agent agir librement. L'agent identifie l'intention, décrit ou crée un modèle de requête, mais n'est pas autorisé à envoyer une requête SQL définitive.

Ce modèle est ensuite acheminé à travers cette couche sémantique, qui contient toutes les informations métier, où les espaces réservés sont alors remplacés par les définitions réelles. Cela signifie que si je demande : « Combien avons-nous de clients actifs ? », cet espace réservé « client actif » est remplacé par la définition réelle. La requête est ensuite exécutée en lecture seule.

Les données restent donc dans la base de données. Je n'obtiens que le résultat et j'obtiens finalement une réponse fiable. Bien sûr, on peut dire que cela ne fait en principe que déplacer le problème vers la création de cette couche sémantique en tant que véritable source de vérité.

Et pour cela aussi, nous disposons d’un agent, le Steward Agent, qui construit, entretient et surveille cette couche sémantique. Il récupère donc la documentation, les pages Confluence, partout où ma logique métier est expliquée, il les intègre dans la couche sémantique et dispose d’une boucle de rétroaction : ainsi, chaque fois que j’effectue une requête et que j’ai une conversation avec l’agent, il en extrait des informations et améliore cette couche sémantique au fil du temps. L’AI Analyst est un moyen de communiquer finalement de manière vraiment naturelle avec Informix.

Et pour terminer aujourd’hui, voyons à nouveau où nous en sommes dans le domaine de l’IA agentique. Commençons par rappeler très brièvement la différence entre l’IA agentique et les applications classiques. Comme je l’ai déjà dit au début : l’un des aspects les plus importants de l’IA agentique est que le système dans son ensemble est orienté vers un objectif.

L'utilisateur peut toujours définir la destination, mais il n'a plus besoin de savoir comment fonctionne le processus. Comme dans l'exemple précédent : je peux poser une question, je peux définir la destination et la réponse que je souhaite obtenir. Mais je n'ai plus besoin d'être capable de formuler la requête SQL correspondante.

Les agents disposent d'une phase de planification. Cela signifie qu'ils décomposent les tâches, qu'ils planifient de manière autonome et qu'ils bénéficient d'une boucle de rétroaction leur permettant, pendant l'exécution, d'ajuster à nouveau l'ensemble en fonction des résultats obtenus lors des premières étapes. Ils disposent d'un contexte et d'une mémoire.

En d'autres termes, si j'ai déjà effectué certaines tâches, il peut en garder la trace dans une mémoire à court terme et dans une mémoire à long terme afin de s'améliorer continuellement. Cela signifie qu'un agent peut, au fil du temps, devenir mon assistant personnel, en sachant ce que je préfère, comment j'effectue mes tâches, et ainsi de suite. Et c'est là que MCP entre en jeu.

Les agents peuvent utiliser des outils. Cela signifie qu’un agent peut accéder de manière autonome à des systèmes externes via le MCP, en respectant les mécanismes de sécurité du serveur MCP ainsi que les restrictions et les mécanismes de sécurité. Réfléchissons-y un instant.

C'est en quelque sorte une source d'inspiration si vous souhaitez créer différents agents au sein de votre entreprise à l'aide du serveur MCP et d'Informix. De tels cas d'utilisation existent en réalité tout au long du cycle de vie des données. Au stade de la collecte des données, on peut dire que les agents agissent en fait comme des opérateurs.

Cela signifie que je peux avoir des agents chargés de la collecte de données. Je peux appeler mon agent par téléphone et lui dire : « Je sors d'une réunion avec un client. Voici les informations que j'ai recueillies. »

Ajoute ça dans ma base de données de prospects, s'il te plaît. Je peux créer un agent de migration des données qui transférera automatiquement les données d'une base de données vers ma base de données « interne ». En matière de gestion des données, on peut dire que les agents jouent en fait le rôle de conservateurs.

Cela signifie que je peux vérifier la qualité des données et les enrichir automatiquement. Je peux retracer la provenance des données. C'est justement ce qui est très important à l'ère de l'IA : d'où proviennent mes mesures ?

D'où proviennent mes données ? Comme nous venons de le voir, les agents agissent en réalité comme des analystes lorsqu'ils exploitent ces données. Cela signifie que je peux bien sûr formuler des requêtes verbales.

Je peux également créer un agent capable de générer des « tableau de bord s », voire de traiter des requêtes multimodales. Cela signifie que mon agent pourrait interroger une combinaison de documents, d'e-mails, d'images et de données relationnelles afin de formuler une réponse. Les possibilités sont nombreuses.

Et l’un des principaux points sensibles, bien sûr : l’administration des bases de données. Les agents jouent le rôle d’administrateurs. Ils peuvent apporter leur aide, voire prendre en charge certaines tâches ; par exemple, un « System Health Agent » qui surveille mon système 24 heures sur 24 et signale de manière proactive les problèmes, voire les résout d’emblée.

Ou encore l'optimisation de la base de données. Nous le savons tous, un système comporte des centaines de paramètres d'optimisation. Le schéma, la configuration, tout cela peut être optimisé, et un agent peut aider à adapter l'ensemble à l'charge de travail .

Tout cela sert d'inspiration pour ce qu'on peut mettre en œuvre. À quoi peut ressembler ce genre de chose, ce qu'on fait habituellement ? On dispose ici de la base de données « utilisateur ».

On dispose bien sûr d’un serveur MCP pour la base de données « utilisateur », afin que l’agent puisse y accéder en toute sécurité. Et je dispose d’une manière ou d’une autre de données de télémétrie ou de journaux que j’extrais du système. Et voici ce que je devrais faire lorsque je développe une telle application : je devrais enregistrer toutes ces données dans une base de données de métriques, afin de ne pas perturber le fonctionnement opérationnel du système lorsque j’interroge ces métriques à l’aide d’agents.

L'agent a désormais accès aux données, aux journaux ou aux données de télémétrie. Cela signifie, par exemple, qu'il connaît également le niveau d'utilisation de la mémoire et peut ainsi prendre des décisions. Pour effectuer ce raisonnement, un tel agent a besoin d'un modèle linguistique de grande envergure.

Je peux pour l'instant mettre cela en place de manière relativement naïve, en envoyant simplement le tout à OpenAI ou à Tropic à l'aide d'un modèle hébergé publiquement. Ou bien je peux choisir de garder le contrôle grâce à un modèle privé que j'héberge moi-même sur interne . Dans tous les cas, ce qu'il faut faire, c'est intercaler une couche proxy qui abstraie le tout et qui mette également en place des garde-fous supplémentaires.

Pour résumer : c'est exactement ce que nous prévoyons de faire lorsque nous développerons des agents prêts à l'emploi, désormais pour tous nos systèmes de bases de données. Nous allons ainsi intercaler une couche proxy. Celle-ci dispose d'un moteur d'exécution pour les modèles locaux, peut être connectée en option à un modèle public et intègre justement toutes ces mesures de sécurité qui sont essentielles pour les entreprises.

Il s'agit donc de la couche de contrôle située entre mon agent et les modèles publics, par exemple en matière de sécurité et de chiffrement, mais aussi d'audit. Cela signifie que chaque requête doit être consignée dans un journal. Je souhaite savoir combien de jetons sont utilisés.

Je suis capable d'établir un budget et d'identifier et de masquer les données à caractère personnel avant qu'elles ne soient effectivement transmises aux modèles publics. Et pour ce qui est du calendrier : ce que nous avons déjà publié en avril, c'est la version 1 du serveur MCP. Il s'agissait d'une mise en route sécurisée avec authentification et accès en lecture seule.

Nous avons publié la version 1.1 il y a une semaine et demie ou deux. Elle permet déjà de mettre le tout en production. Autrement dit, les premières mesures de sécurité sont déjà en place.

Nous avons intégré la fonctionnalité de journalisation et autorisons les opérations d'écriture avec « Human in the Loop » ; l'ensemble sera ensuite encore enrichi, dans la prochaine version, par des outils d'administration et diverses fonctionnalités d'orchestration. Parallèlement, nous travaillons sur les agents. Cela signifie que les agents dédiés à l'administration des bases de données seront disponibles en accès anticipé vers la fin de l'année.

Ce qui nous importe ici, et je l’ai brièvement évoqué tout à l’heure, c’est que nous parlons de systèmes qui constituent, en principe, le cœur de toutes nos entreprises. Il ne faut donc pas y travailler à la légère avec des agents et risquer de perdre des données, de compromettre les systèmes, etc. En d’autres termes, nous privilégions la fiabilité plutôt que le battage médiatique.

Nous souhaitons nous développer en toute sécurité. Cela signifie que nous voulons mettre en place progressivement des cas d'utilisation en bénéficiant du niveau de sécurité nécessaire pour le faire de manière véritablement fiable. Nous voulons avoir un contrôle total sur l'utilisation de l'IA et, surtout, préserver notre souveraineté.

Cela signifie qu'il est toujours possible d'héberger ses propres modèles et de conserver un contrôle total pour tous ceux qui souhaitent être indépendants des modèles globaux. Nous essayons de limiter au maximum l'impact de tout cela sur l'environnement de production. Comme je viens de le dire, il n'est en réalité pas acceptable que ces applications perturbent le fonctionnement opérationnel, et l'autonomie sera configurable.

Cela signifie qu’un tel agent peut formuler des propositions que je, en tant qu’utilisateur, mets moi-même en œuvre. Grâce à l’approche « Human in the Loop », il peut faire des propositions que je n’ai plus qu’à valider, ou bien les systèmes peuvent également fonctionner de manière autonome. C’est en quelque sorte la feuille de route qui indique la direction à suivre et vers laquelle nous souhaitons évoluer avec prudence, mais avec certitude.

Bon, pour résumer, voici les principaux points à retenir de cette journée : HCL Informix se prépare à l'IA. L'IA s'installe là où se trouvent déjà les données, car nous disposons du type de données vectorielles natif et de MCP. Nous avons vu qu'il est possible de « dialoguer » avec ses données et qu'il existe des solutions permettant un accès en langage naturel.

Et nous avons vu ce que l'avenir nous réserve. Les outils basés sur des agents simplifieront et amélioreront notre travail, tant dans la manière dont nous utilisons nos systèmes que dans la façon dont nous les configurons et les administrons. Bon, et pour conclure : HCL Informix est prêt à prendre en charge vos cas d'utilisation de l'IA, et nous serons ravis de poursuivre la discussion et de répondre à vos questions.

D'accord. Est-il possible que différentes personnes obtiennent des résultats différents en fonction de leurs requêtes en langage naturel et de requêtes similaires ? Exactement, cela peut arriver.

C'est exactement ce que j'ai souligné sur la diapositive présentant les différentes réponses. Cet analyste IA connaît mon rôle en tant qu'utilisateur. Je peux créer différents utilisateurs ayant chacun un rôle différent.

Le système sait donc que je fais partie du service financier, comment je définis, par exemple, un client actif au sein de mon service, et qu’avec la même requête, quelqu’un d’autre peut obtenir un résultat différent en fonction de la définition des indicateurs qui est valable dans ce contexte. Le tout est basé sur les rôles, ce qui me permet d’obtenir systématiquement le bon contexte. La mémoire à court terme et la mémoire à long terme sont-elles partagées entre les différents utilisateurs ?

Non, c'est très important, car cela peut bien sûr aussi concerner les mécanismes de mise en cache, notamment la mise en cache des requêtes, ce qui constitue évidemment une porte d'entrée majeure pour les fuites ou les problèmes de sécurité. Non, tout cela n'est pas partagé. La mémoire à court terme et les connaissances à long terme sont-elles interchangeables ?

Quelles informations sont enregistrées lors de l'audit et quel est le volume de données requis ? Où sont stockées les données d'audit : en dehors de l'instance ou dans le système de fichiers ? Il existe désormais deux contextes différents à cet égard.

Je peux également configurer la mémoire à court terme et les connaissances à long terme. Je peux personnaliser une invite système dans le contexte de l'AI Analyst. Cela me permet également de configurer le comportement de mon agent, de consulter ce qu'il a actuellement en mémoire et de le configurer.

Quelles informations sont enregistrées lors de l'audit et quel est le volume de données requis ? Actuellement, chez nous, toutes ces informations sont enregistrées dans une base de données. Bien sûr, si l'on développe un agent générique, comme dans cette architecture de référence que je viens de vous montrer, il est possible d'y connecter n'importe quel système.

Il s'agit généralement d'un système de base de données opérationnel ou d'un système NoSQL, dans lequel on y transfère ces journaux à très haute fréquence. Et le volume de données nécessaire dépend bien sûr de la durée pendant laquelle je suis éventuellement tenu, en vertu de la réglementation, de conserver ces données. Ainsi, si je mets en place un système et que je dois conserver toutes les données de manière vérifiable pendant 30 jours, je dois les conserver pendant toute cette durée.

Ensuite, je pourrai probablement l'archiver. Et encore une question : même si les rôles sont identiques ? Non, si j'ai le même rôle, je peux concevoir via ce système.

C'est précisément la différence entre un LLM « pur », qui peut me donner différentes réponses pour une même requête, et notre système, qui résout ce problème grâce à cette traduction par étapes, grâce à cette traduction en deux étapes. Bon, nous sommes à la fin du temps imparti. Je ne sais pas pourquoi je suis sorti un instant.

Je vous remercie en tout cas de votre attention et je serais ravi que nous puissions échanger à nouveau à l'occasion d'un événement quelconque ou, si vous le souhaitez, par e-mail, si vous avez des questions complémentaires. Je vous remercie encore et vous souhaite une bonne soirée. Merci pour vos commentaires.