L'IA générative présente de nombreuses opportunités dans le contexte des opérations et du développement, mais elle soulève également de nombreux défis pour ceux qui tentent d'intégrer l'IA générative dans une solution de sécurité.
L’un de ces défis consiste à savoir comment recueillir des informations via les LLM (Large Language Models) sur le contenu sensible qui ne peut pas être partagé avec un service d’IA tiers, comme les politiques de sécurité utilisées pour protéger les applications et les API contre la fraude et les abus.
Un deuxième défi avec les LLM est leur tendance à avoir des hallucinations, surtout lorsqu’on leur demande d’analyser ou de générer du contenu lié à un sujet sur lequel le LLM a peu de connaissances. C'est souvent le cas pour les langages spécifiques à un domaine tels que DEX . Il s'agit d'un langage purement fonctionnel, typé statiquement et non Turing-complet qui, bien que bien défini, n'est pas largement utilisé.
Le premier défi, la confidentialité des données, semble à première vue insurmontable. Les entreprises de sécurité doivent prendre très au sérieux la confidentialité et la sécurité de toutes les données clients, y compris les politiques. Ainsi, bien que l’utilisation d’un LLM pour aider à découvrir des informations sur les politiques bénéficierait à la fois aux pratiques opérationnelles et aux clients, une solution est nécessaire qui puisse tirer des informations des données sensibles sans partager ces données avec un LLM tiers, rendant impossible pour le LLM de les traiter. Le deuxième défi (les hallucinations) est un défi que l’ensemble du secteur s’efforce actuellement de surmonter, notamment en ce qui concerne les réponses concernant les politiques, les configurations et le code.
Alors que les humains voient un programme comme une séquence de caractères, le compilateur voit les choses différemment. Pour le compilateur, un programme DEX est un type de structure de données appelé AST (Abstract Syntax Tree). Cet arbre est un graphe acyclique orienté, ce qui signifie que les politiques en question sont bien adaptées à la représentation sous forme de graphe. Ainsi, la solution que nous avons trouvée exploite une base de données graphique (Neo4j) et utilise un agent GPT pour générer des requêtes GraphQL. Cette approche répond parfaitement au premier défi car nous pouvons utiliser GraphQL pour interroger une base de données graphique contenant les données tout en protégeant sa confidentialité du LLM tiers.
Le deuxième défi – les hallucinations – est plus difficile à surmonter, mais notre approche fonctionne également ici en utilisant plusieurs techniques d’IA pour atténuer le risque. De plus, GraphQL est un langage de requête largement utilisé et bien documenté, avec lequel la plupart des modèles GPT sont familiers et qui peut être facilement vérifié syntaxiquement à l'aide de nombreux outils. Cela réduit le risque d’hallucination et permet de garantir l’exactitude avant utilisation.
Les hallucinations de l’IA font référence à des cas où une IA générative produit des résultats qui ne sont pas basés sur des données ou des modèles réels, mais qui sont plutôt fabriqués ou déformés. Ces hallucinations se produisent souvent en raison de limitations ou de biais dans les données de formation de l'IA, ou lorsque l'IA tente de générer des résultats pour des situations qu'elle n'a jamais rencontrées auparavant. Les hallucinations peuvent se manifester sous la forme de contenus fabriqués ou insensés ou de conclusions qui peuvent ne pas avoir de sens logique ou ne pas être fidèles aux données d’entrée. Par exemple, une IA génératrice de texte pourrait produire des phrases qui semblent plausibles mais qui sont finalement dénuées de sens ou sans rapport avec le contexte fourni.
GraphQL est un langage de requête open source pour les API (interfaces de programmation d'applications) et un environnement d'exécution côté serveur permettant d'exécuter ces requêtes en utilisant un système de types défini pour les données. Il a été développé par Meta (Facebook) et est conçu pour fournir une alternative plus efficace, plus puissante et plus flexible aux API RESTful traditionnelles. Les API GraphQL sont définies par un schéma qui spécifie les types de données qui peuvent être interrogées ou mutées. Ce typage fort permet un meilleur outillage, une meilleure introspection et une meilleure validation.
Notre approche pour intégrer en toute sécurité l’IA générative dans la sécurité prend la forme d’un agent GPT. Bien que l'utilisation d'un langage bien documenté contribue à réduire le risque d'hallucination, nous devions trouver un moyen de limiter l'espace de sortie de notre agent dans un format qui peut être vérifié par programmation pour détecter les erreurs tout en n'envoyant aucune donnée sensible à OpenAI. L'utilisation de GraphQL comme espace de sortie fonctionne bien ici car il est suffisamment expressif pour répondre à la plupart des questions tout en étant une abstraction qui peut être vérifiée par programmation par rapport à un schéma connu.
Bien que nous ayons appliqué cette approche à DEX, elle fonctionnera pour tout ensemble de données suffisamment interconnectées et relationnelles telles que : les réseaux sociaux, les topologies de réseaux et d'infrastructures, les chaînes d'approvisionnement et les données géospatiales (cartographie).
L'architecture PC-graph se compose de composants permettant de transformer DEX en une représentation graphique. Les données graphiques résultantes sont ensuite stockées dans une base de données Neo4j. La sortie d'un agent GPT peut être soumise via API à un serveur GraphQL Apollo, qui exécute la requête sur la base de données graphique.
Notre agent utilise GPT4 pour répondre aux demandes en langage naturel d'informations sur les politiques écrites dans DEX. L'agent y parvient en comprenant l'API pc-graph et en répondant avec une requête ou une mutation appropriée qui peut ensuite être examinée et exécutée par l'utilisateur.
En plus de l'API pc-graph, notre agent comprend également les bibliothèques utilisées et certains concepts sur le langage DEX. Ces informations sont soigneusement sélectionnées pour être incluses dans le contexte lors de l'exécution afin de fournir des résultats optimaux.
L’un des défis que cela pose est que l’agent a besoin d’un contexte large pour contenir les parties pertinentes du schéma, ainsi que le matériel supplémentaire, comme la documentation neo4j-graphQL qui inclut des types, des requêtes et des mutations supplémentaires générés par la bibliothèque. Lorsque nous utilisons GPT4-8k, nous manquons tout simplement de place pour un apprentissage contextuel adéquat. Le contexte 32k donne des résultats acceptables, cependant, cela entraîne également des coûts supplémentaires. Par exemple, nous devons envoyer le SDL (Schema Definition Language) de GraphQL à chaque requête adressée à OpenAI. Cela ne poserait pas de problème si nous pouvions affiner les modèles conversationnels GPT4 avec notre schéma, supprimant ainsi la nécessité de l'inclure dans le contexte. Cependant, cela n'est actuellement pas pris en charge par OpenAI.
Nous avons trouvé trois approches d’IA qui améliorent les résultats de GPT4 :
Dans une dernière étape, nous utilisons des outils qui fournissent une vérification des erreurs de syntaxe statique pour les requêtes GraphQL afin de détecter d’éventuelles hallucinations qui auraient échappé aux atténuations initiales.
Cette conception est encore améliorée en générant initialement trois réponses potentielles dans la même invite. Cela réduit non seulement le temps et le coût d’une réponse donnée, mais améliore également la cohérence, car les aspects corrects d’une réponse sont plus susceptibles de se produire. Ce faisant, nous laissons également place à des variations aléatoires dans le but d’explorer des options improbables mais précises.
Grâce à notre approche, nous avons pu recueillir des informations sur les politiques sans partager de données privées. La qualité et la cohérence de nos résultats de requêtes se sont également considérablement améliorées avec une réduction notable des hallucinations, en particulier sur les tâches impliquant la construction de requêtes volumineuses ou complexes incluant plusieurs filtres et/ou fonctions d'agrégation.
D'une certaine manière, nous avons le droit d'avoir le beurre et l'argent du beurre ; lorsque nous sommes obligés de choisir entre un agent créatif et un agent déterministe, nous faisons tout simplement les deux.