Remote Display Analyzer

Dans les environnements de bureaux à distance modernes (Azure Virtual Desktop, Windows 365, Citrix …) l’expérience utilisateur dépend énormément du protocole d’affichage distant, du réseau, des ressources , … Quand tout fonctionne bien, personne ne s’en préoccupe. Mais dès qu’un utilisateur dit : « mon Cloud PC lag », « la vidéo est saccadée », « j’ai un délai quand je tape au clavier » … on entre immédiatement dans une zone grise. Bon courage pour comprendre la cause !

Un problème d’affichage distant peut venir de nombreux endroits : réseau, client, serveur, GPU, codec vidéo, politiques de compression et j’en passe.

C’est exactement pour cela que j’aime beaucoup un outil que j’utilise régulièrement lors de phases de troubleshooting : Remote Display Analyzer (RDA).

Cet outil permet de voir et tester en direct ce que fait réellement le protocole d’affichage distant :

Avant d’aller plus loin, je voulais remercier l’équipe RDA de m’avoir donné une licence pour réaliser mes tests.

Et pour vous guider plus facilement dans cet article très long, voici des liens rapides :

Qu’est‑ce que Remote Display Analyzer ?

Remote Display Analyzer (RDA) est un petit et très léger outil conçu pour analyser les protocoles d’affichage utilisés dans les environnements de virtualisation de poste de travail.

Il ne supporte pas que des environnements Microsoft, mais bon nombre de solutions présentes sur le marché, notamment :

  • Microsoft RDP
  • Azure Virtual Desktop
  • Windows 365
  • Citrix HDX
  • Omnissa / VMware Horizon Blast
  • Nutanix Frame

Combien coûte RDA ?

Remote Display Analyzer est décliné en plusieurs éditions afin de répondre à des besoins différents. En plus de l’édition Community, il existe une édition Personal ainsi qu’une édition Company, qui offrent des fonctionnalités avancées adaptées à des usages plus professionnels ou à grande échelle :

Il existe une version gratuite de RDA : l’édition Community permet d’accéder aux statistiques temps réel du protocole d’affichage, ce qui est largement suffisant pour de nombreux scénarios de diagnostic et de troubleshooting :

Voici un lien de téléchargement de la version gratuite de RDA. Enfin les deux autres versions payantes sont plus complètes, et remontent plus données :

Comment fonctionne RDA ?

Comme annoncé plus haut, Remote Display Analyzer ne nécessite aucune installation préalable. L’outil se présente sous la forme d’un simple exécutable qui peut être lancé directement à l’intérieur d’une session distante, sans configuration particulière.

Voici un lien vers ses fonctionnalités. Dès que RDA est lancé, il détecte automatiquement :

  • le protocole utilisé
  • le mode d’affichage actif
  • l’encodeur vidéo

Dans le cas d’Azure Virtual Desktop, Remote Display Analyzer permet également de vérifier si la session utilise RDP Shortpath.

  • RDP Shortpath est un mode de transport UDP qui permet d’améliorer les performances et de réduire la latence dans les sessions AVD.
  • Lorsque Shortpath est actif, le trafic RDP ne passe plus uniquement par le service de gateway Azure, mais peut établir un chemin direct entre le client et la machine virtuelle.

Remote Display Analyzer permet de vérifier immédiatement si la session utilise le transport TCP classique ou le mode UDP (RDP Shortpath) :

Il affiche également différentes métriques en temps réel, comme par exemple :

  • bande passante utilisée
  • latence réseau
  • nombre de frames
  • frames perdues
  • GPU

Il vous informe sur les statistiques portant sur les paquets envoyés et les contraintes potentielles sur ces derniers, mais également sur les FPS envoyés :

Enfin, il vous donne des informations utiles sur le GPU :

Dans les environnements Azure Virtual Desktop ou Windows 365 utilisant des machines virtuelles avec GPU (par exemple NV-series ou NVads), l’encodage vidéo peut être offloadé vers le GPU. Lorsque cette accélération est active :

  • la charge CPU diminue
  • l’encodage vidéo devient plus rapide
  • l’expérience utilisateur est plus fluide

Remote Display Analyzer permet de vérifier si l’encodeur vidéo GPU est réellement utilisé et d’observer en temps réel la latence de l’encodeur ainsi que le nombre de frames générées.

Cela permet notamment de vérifier que les politiques GPU sont correctement appliquées sur les session hosts AVD.

Comment interpréter les métriques de RDA ?

Certaines métriques sont particulièrement utiles pour comprendre l’expérience utilisateur.

  • FPS :
    • Un environnement fluide tourne généralement entre 25 FPS et 60 FPS
    • En dessous de 20 FPS, les utilisateurs commencent souvent à percevoir des saccades.
  • Latence round-trip :
    • < 40 ms → excellent
    • 40-80 ms → correct
    • 100 ms → visible
  • Video Encoder Latency
    • Une latence encodeur trop élevée peut indiquer : CPU saturé, GPU absent, codec mal configuré

Qu’est-ce que les « Skipped Frames » ?

Dans les protocoles d’affichage distants, toutes les images générées par l’application ne sont pas forcément envoyées au client.

Lorsque certaines ressources deviennent limitées, le protocole peut décider d’ignorer certaines images afin de maintenir une expérience utilisateur acceptable.

Remote Display Analyzer permet d’identifier trois types de frames ignorées :

Skipped frames – client

Cela signifie que le client ne peut pas décoder ou afficher les images assez rapidement. Les causes les plus fréquentes sont :

  • client peu puissant
  • GPU absent
  • décodage vidéo logiciel
  • écran haute résolution

Skipped frames – network

Dans ce cas, c’est le réseau qui devient le facteur limitant. Le protocole décide alors de réduire le flux graphique. Cela peut être causé par :

  • bande passante insuffisante
  • latence élevée
  • pertes de paquets
  • congestion réseau

Skipped frames – server

Ici le problème vient du serveur lui-même. Cela peut être dû à :

  • CPU saturé
  • GPU saturé
  • trop de sessions par host
  • encodage vidéo trop lourd

Quelques exemples de problèmes que RDA permet d’analyser :

Un premier cas fréquent concerne la latence élevée dans les sessions distantes. Les utilisateurs peuvent ressentir un délai entre l’action réalisée sur le clavier ou la souris et la réaction affichée à l’écran. Dans ce type de situation, Remote Display Analyzer permet de visualiser la latence réseau, le nombre de frames envoyées et les éventuelles frames perdues afin d’identifier si le problème vient du réseau, du serveur ou du client.

Dans l’exemple ci-dessous, RDA analyse une session Windows 11 dans Azure Virtual Desktop :

Comme la vidéo le montre, il peut être très instructif de simuler différents niveaux de latence réseau afin d’observer comment la session se comporte dans des conditions WAN plus difficiles. Remote Display Analyzer permet alors de suivre en temps réel l’impact de la latence sur la fluidité et la réactivité.

Un autre problème courant concerne les vidéos ou les animations qui deviennent saccadées. Les utilisateurs peuvent par exemple remarquer que Microsoft Teams, YouTube ou certaines applications graphiques ne sont pas fluides. Dans ce cas, l’outil permet d’analyser le nombre d’images par seconde, le codec vidéo utilisé ainsi que la bande passante réellement consommée par la session :

On rencontre également souvent des problèmes d’image floue ou de compression trop forte. Dans ces situations, le texte peut sembler légèrement dégradé ou certaines images peuvent apparaître très compressées. Remote Display Analyzer permet alors de tester différents niveaux de compression et différentes qualités d’image afin de trouver le bon compromis entre qualité visuelle et consommation réseau.

Enfin, certains environnements rencontrent des problèmes de charge CPU trop élevée sur les serveurs. Cela peut se produire lorsque l’encodage vidéo est effectué par le CPU plutôt que par le GPU. Dans ce type de scénario, RDA permet de vérifier si l’encodage GPU est réellement utilisé ou si le CPU est responsable du traitement graphique :

Peut-on modifier certains réglages graphiques avec RDA ?

Ce qui rend l’outil vraiment intéressant est une autre capacité. Remote Display Analyzer permet de modifier certains paramètres d’affichage en live pour les environnements Citrix. Cela permet de faire des tests très rapides pour comprendre l’impact réel d’une configuration. Par exemple :

  • codec vidéo
  • profondeur de couleur
  • compression
  • qualité d’image
  • frames par seconde

Comme le rappelle l’éditeur dans leur FAQ, RDA nécessite les droits administrateur pour pouvoir effectuer ces modifications.

Conclusion

Remote Display Analyzer est un outil extrêmement simple, mais particulièrement utile dans les environnements EUC.

Lorsqu’un utilisateur signale que son bureau distant est lent ou que la vidéo est saccadée, il est souvent difficile de savoir immédiatement si le problème vient du réseau, du client, du serveur ou du protocole lui-même.

Grâce à ses métriques en temps réel et à sa capacité à modifier certains paramètres graphiques à la volée, Remote Display Analyzer permet de mieux comprendre le comportement du protocole d’affichage distant.

Pour les administrateurs travaillant avec Azure Virtual Desktop, Windows 365, Citrix ou Horizon, c’est clairement un outil que je recommande d’avoir dans sa boîte à outils de troubleshooting.

Faites tourner votre propre IA RAG en local

Dans la série des démonstrations très intéressantes sur l’intelligence artificielle, j’appelle le RAG local ! Comme toujours, Alex de la chaîne YouTube The Code Wolf nous montre comment en quelques clics il est possible d’installer et tester une IA sur votre poste local, tout en y ajoutant des données spécifiques (RAG) afin d’en améliorer les réponses.

Mais qu’est-ce que le RAG ?

Le Retrieval Augmented Generation (RAG) est une approche novatrice qui combine le meilleur de deux mondes en IA : la recherche d’informations (retrieval, qui ne génère pas de réponse originale) et la génération de contenu (qui ne s’appuie que sur les données de son entraînement). Traditionnellement, les LLM génèrent du contenu en s’appuyant uniquement sur les informations apprises durant leur phase d’entraînement. Le RAG, en revanche, permet au modèle de « consulter » une base de données ou un corpus de documents externes en temps réel pour enrichir sa génération de texte. Cette capacité de recherche améliore significativement la précision, la pertinence et la richesse du contenu généré.

Datascientest.com

Comment fonctionne le RAG ?

La qualité de la base de données est un élément crucial pour le fonctionnement du RAG. Une base de données riche, variée et actualisée permet au modèle d’acquérir une connaissance approfondie et de générer des réponses plus précises et pertinentes.

La recherche d’informations joue également un rôle important en permettant au RAG de trouver les éléments les plus pertinents dans la base de données et de les utiliser pour inspirer ses réponses.

reglo.ai

Voici un exemple des étapes pour mieux comprendre les interactions :

ÉtapeDescription
1. QuestionL’utilisateur demande : « Quelle est la vitesse de la lumière dans le vide ? »
2. Embedding de texteLa question est convertie en vecteur (séquence numérique) pour capturer sa signification.
3. Corpus et base de données vectorielleLes documents sont découpés en passages courts et convertis en vecteurs, stockés dans une base de données vectorielle.
4. RechercheLe module de recherche compare les vecteurs de la question aux vecteurs des documents pour trouver les plus similaires.
5. RéponseLe LLM utilise la question et les extraits récupérés pour générer une réponse pertinente : « La vitesse de la lumière dans le vide est de 299 792 458 mètres par seconde »

Mais comment tester le RAG en local ?

Voici un exemple des ressources nécessaires pour y parvenir :

ComposantDescription
Bibliothèques et outilsSentenceTransformers pour les embeddings de texte.
– Un modèle de langage comme ollama.
– qdrant, Faiss ou Annoy pour la base de données vectorielle.
Données– Corpus de documents à utiliser pour la recherche.
– Données prétraitées et converties en vecteurs.
Environnement de développement– Python ou .NET
– Docker
Serveur RAG– Framework comme R2R (Ready-to-Run) pour déployer le pipeline RAG.
– API pour interagir avec le pipeline.

Faut-il un GPU pour faire du RAG ?

L’utilisation d’un GPU pour mettre en place le RAG n’est pas strictement nécessaire, mais elle peut grandement améliorer les performances, surtout pour les tâches de génération de texte et de traitement de grandes quantités de données. Voici quelques points à considérer :

  1. Sans GPU :
    • Possible : Tu peux utiliser un CPU pour les tâches de RAG, mais cela peut être plus lent, surtout pour les modèles de langage volumineux.
    • Limité : Les performances peuvent être limitées, ce qui peut affecter la rapidité et l’efficacité du système.
  2. Avec GPU :
    • Accélération : Un GPU peut accélérer les calculs nécessaires pour les embeddings de texte et la génération de réponses.
    • Efficacité : Améliore la capacité à traiter des requêtes en temps réel et à gérer des corpus de données plus importants.

En résumé, bien que l’on puisse mettre en place un système RAG sans GPU, l’utilisation de ce dernier est recommandée pour des performances optimales, surtout si l’on travaille avec des modèles de langage avancés et des bases de données volumineuse.

Voici donc la vidéo de The Code Wolf qui va nous servir de base à notre démonstration :

Son programme, lui-même basé sur les données de ce GitHub, met en place un chatbot intelligent utilisant des données de Zelda, grâce à la technique RAG.

Dans cet article, je vous propose de tester son application via deux machines virtuelles Azure :

Maintenant, il nous reste plus qu’à tester tout cela 😎💪

Etape 0 – Rappel des prérequis :

Afin de mettre en place une application RAG en local, nous allons avoir besoin de :

  • Un poste local ayant un GPU puissant pouvant effectuer de la virtualisation

ou

  • Un tenant Microsoft active
  • Une souscription Azure valide

Ayant des crédits Azure, je vous propose dans ma démonstration de partir sur la seconde solution. Un petit souci vient malheureusement heurter mon raisonnement : les SKUs de machine virtuelle Azure pouvant faire de la virtualisation n’ont pas de GPU puissant.

Je vais donc créer 2 machines virtuelles Azure :

  • Machine virtuelle CPU pour Docker + tests RAG CPU
  • Machine virtuelle GPU pour tests RAG GPU

Commençons par créer la première machine virtuelle CPU.

Etape I – Préparation de la machine virtuelle CPU :

Depuis le portail Azure, commencez par rechercher le service des réseaux virtuels :

Cliquez-ici pour créer votre réseau virtuel :

Nommez ce dernier, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre réseau virtuel :

Environ 30 secondes plus tard, la ressource Azure est créée, cliquez-ici :

Cliquez-ici pour déployer le service Azure Bastion :

N’attendez-pas la fin du déploiement d’Azure Bastion, recherchez le service des machines virtuelles :

Cliquez-ici pour créer votre machine virtuelle CPU :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle présente dans la famille Dasv6 :

Renseignez un compte d’administrateur local, puis cliquez sur Suivant :

Rajoutez ou non un second disque de données, puis cliquez sur Suivant :

Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle CPU :

Renseignez les identifiants renseignés lors de la création de votre VM :

Acceptez les conditions Microsoft :

Rendez-vous sur la page suivante afin de télécharger la version 9.0 de .NET :

Une fois téléchargée, lancez l’installation :

Une fois l’installation réussie, fermez l’installation :

Rendez-vous sur la page suivante afin de télécharger Visual Studio Code :

Une fois téléchargée, lancez l’installation :

Une fois l’installation réussie, redémarrez la machine virtuelle :

Quelques secondes plus tard, relancez une connexion via Azure Bastion :

Rendez-vous sur la page suivante afin de télécharger Ollama :

Une fois téléchargée, lancez l’installation :

Une fois l’installation réussie, vérifiez via l’URL suivante le bon fonctionnement du service :

http://localhost:11434/

Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :

ollama pull phi3:mini

Ollama télécharge alors la version mini de Phi3 d’environ 2 Go :

Lancez la seconde commande suivante :

ollama pull nomic-embed-text

Ollama télécharge alors un modèle ouvert d’environ 270 Mo :

Vérifiez la liste des modèles en place avec la commande suivante :

ollama list

Rendez-vous sur la page suivante afin de télécharger Docker en version Desktop :

Conservez ces 2 cases cochées, puis cliquez sur OK pour lancer l’installation :

Attendez quelques minutes que l’installation se termine :

Cliquez-ici pour redémarrer à nouveau la machine virtuelle CPU :

Quelques secondes plus tard, relancez une connexion via Azure Bastion :

Attendez si nécessaire la fin de l’installation de composants additionnels :

Depuis le menu Démarrer de la session Windows, ouvrez l’application Docker :

Acceptez les conditions d’utilisation de Docker :

Cliquez sur le bouton Finaliser :

Cliquez-ici :

Cliquez-ici :

Attendez le démarrage du service de virtualisation Docker :

Une fois le service correctement démarré, vous ne devriez voir pour le moment aucun conteneurs :

Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :

docker run -p 6333:6333 -p 6334:6334 -d --name qdrant qdrant/qdrant

Cette commande Docker permet de Qdrant, qui est une base de données vectorielle sous forme de conteneur.

Cela te permet d’utiliser Qdrant pour stocker et rechercher des vecteurs dans ton pipeline RAG :

Autorisez Docker à pouvoir passer au travers de Windows Firewall :

Retournez sur la console de Docker afin de constater le bon démarrage du conteneur :

Notre environnement de test est en place, nous allons maintenant pouvoir récupérer l’application et les données RAG.

Etape II – Chargement de la base de données vectorielle :

Ce premier programme effectue plusieurs tâches pour créer une base de données vectorielle avec Qdrant et générer des embeddings de texte à l’aide d’Ollama.

Voici un résumé des étapes :

  1. Création des clients :
    • Crée un client Qdrant pour interagir avec la base de données vectorielle.
    • Crée un client Ollama pour générer des embeddings de texte.
  2. Chargement des données :
    • Charge des enregistrements de différents fichiers JSON (lieux, boss, personnages, donjons, jeux) et les désérialise en objets ZeldaRecord.
  3. Vectorisation des données chargées :
    • Pour chaque enregistrement, génère un embedding en utilisant le client Ollama.
    • Crée une liste de structures de points (PointStruct) contenant les embeddings et les informations associées (nom et description).
  4. Insertion des données dans Qdrant :
    • Crée une collection dans Qdrant pour stocker les enregistrements vectorisés.
    • Insère les enregistrements dans la base de données Qdrant.

Téléchargez l’archive ZIP de l’application via le lien GitHub suivant, qui n’est qu’un fork du dossier original d’Alex :

Lancez l’extraction des fichiers dans un dossier local de votre choix :

Ouvrez Visual Studio Code installé précédemment, puis ouvrez le dossier créé :

Confirmez la confiance dans le dossier comme ceci :

Ouvrez le terminal de Visual Studio Code via le menu suivant :

Positionnez-vous dans le dossier populateDb, puis lancez la commande suivante :

dotnet run

Le chargement des données dans la base de données vectorielle commence :

Ouvrez le gestionnaire des tâches Windows afin constater l’utilisation du CPU pour ce traitement :

Quelques minutes plus tard, en fonction de la performance de votre machine virtuelle, le traitement se termine via le message de succès suivants :

Ouvrez la page web suivante afin de constater dans la console qdrant la création de la collection RAG, puis cliquez-ici :

http://localhost:6333/dashboard

Choisissez sur un point présent dans la liste de la collection, puis cliquez ici pour y voir plus détail :

Constatez la représentation graphique de la base de données :

Cliquez sur un des points en relation avec le premier consulté :

Cliquez à nouveau sur un des points en relation avec le second consulté :

Copiez les vecteurs d’un des points consultés :

Ouvrez Notepad pour y coller les valeurs de vecteur afin de voir comment ces derniers sont formulés :

Nos données RAG sont maintenant chargées. Nous allons maintenant pouvoir tester les prompts depuis la seconde partie de l’application.

Etape III – Lancement de prompts IA RAG :

Ce programme va nous permettre de poser des questions sur des sujets liés à Zelda et d’obtenir des réponses pertinentes en utilisant des données spécifiques grâce à la recherche vectorielle et à la génération de texte.

Avant de lancez le programme, vérifiez, et modifiez au besoin la version exacte de celle téléchargée pour phi3, puis sauvegardez vos modifications :

Positionnez-vous dans le dossier RagApp, puis lancez la commande suivante :

dotnet run

Posez une question sans rapport avec l’univers de Zelda dans un premier temps :

Posez ensuite une question en rapport avec l’univers de Zelda :

Constatez les lenteurs de réponse de l’intelligence artificielle et l’utilisation intensive du CPU :

Confirmez la durée d’utilisation du CPU en fonction de la longueur des réponses de l’IA :

Confirmez l’utilisation exclusive du CPU par la commande suivante :

ollama ps

Bien que l’utilisation d’un CPU soit possible pour certaines tâches d’IA, l’absence de GPU peut entraîner des performances réduites, des limitations dans l’utilisation de modèles avancés, une consommation accrue de ressources et des défis en termes de scalabilité.

Nous allons donc continuer les tests avec la mise en place d’une seconde machine virtuelle GPU dans Azure.

Etape IV – Préparation de la machine virtuelle GPU :

Avant de créer la machine virtuelle GPU depuis Azure, créez la règle de firewall Windows suivante sur la première machine virtuelle afin de rendre accessible qdrant :

Recherchez à nouveau le service des machines virtuelles :

Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :

Choisissez une taille de machine virtuelle présente dans la famille N :

Renseignez un compte d’administrateur local, puis cliquez sur Suivant :

Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :

Une fois la validation réussie, lancez la création des ressources Azure :

Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle GPU :

Renseignez les identifiants renseignés lors de la création de votre VM :

Acceptez les conditions Microsoft :

Rendez-vous sur la page suivante afin de télécharger la version 9.0 de .NET :

Une fois téléchargée, lancez l’installation :

Rendez-vous sur la page suivante afin de télécharger Visual Studio Code :

Une fois téléchargée, lancez l’installation :

Une fois l’installation réussie, redémarrez la machine virtuelle :

Quelques secondes plus tard, relancez une connexion via Azure Bastion :

Sur cette page, téléchargez le pilote NVIDIA GRID :

Confirmez le dossier de décompression au niveau local :

Attendez environ 30 secondes que la décompression se termine :

Après une rapide vérification système, cliquez sur Accepter et Continuer :

Cliquez sur Suivant :

Une fois l’installation terminée avec succès, cliquez sur Fermer :

Ouvrez le Gestionnaire des tâches Windows afin de constater l’apparition d’une section GPU :

Rendez-vous sur la page suivante afin de télécharger Ollama :

Une fois téléchargée, lancez l’installation :

Une fois l’installation réussie, vérifiez via l’URL suivante le bon fonctionnement du service :

http://localhost:11434/

Depuis le menu Démarrer, ouvrez l’application CMD, puis lancez la commande suivante :

ollama pull phi3:mini

Ollama télécharge alors la version mini de Phi3 d’environ 2 Go :

Lancez la seconde commande suivante :

ollama pull nomic-embed-text

Ollama télécharge alors un modèle ouvert d’environ 270 Mo :

Vérifiez la liste des modèles en place avec la commande suivante :

ollama list

Vérifiez le bon accès à qdrant situé lui sur la machine virtuelle CPU :

Téléchargez à nouveau l’archive ZIP de l’application via le lien GitHub suivant, qui n’est qu’un fork du dossier original d’Alex :

Lancez l’extraction des fichiers dans un dossier local de votre choix :

Etape V – Chargement de la base de données vectorielle :

Ouvrez Visual Studio Code, ouvrez le dossier créé, puis indiquez l’IP locale de la machine virtuelle CPU :

Modifiez également 2 fois le nom de la nouvelle collection créée sur la machine virtuelle GPU, puis Sauvegardez :

Positionnez-vous dans le dossier populateDb, puis lancez la commande suivante :

dotnet run

Ouvrez le Gestionnaire des tâches Windows afin constater l’utilisation plus efficace du GPU pour ce traitement de chargement :

Ouvrez la page web suivante afin de constater dans qdrant la création de la seconde collection RAG, puis cliquez-ici :

http://10.0.0.4:6333/dashboard

Etape VI – Lancement de prompts IA RAG :

Avant de lancez le second programme, vérifiez, et modifiez au besoin l’adresse IP, la version de phi3, la collection utilisée, puis Sauvegardez vos modifications :

Positionnez-vous dans le dossier RagApp, lancez la commande suivante, puis posez une question en rapport avec l’univers de Zelda :

dotnet run

Constatez la pleine puissance GPU pour le traitement :

Constatez la rapidité du texte généré par l’IA :

Confirmez l’utilisation du GPU par la commande suivante :

ollama ps

Conclusion

En conclusion, la mise en place d’une IA RAG (Retrieval-Augmented Generation) sur votre propre PC est un processus réalisable, même sans GPU.

Cependant, l’utilisation d’un GPU est fortement recommandée pour améliorer les performances, surtout pour les tâches de génération de texte et de traitement de grandes quantités de données.

Maintenant, il ne reste plus qu’à tester et affiner votre application et vos données pour obtenir des résultats RAG parfait😎