NOTE: ceci est une traduction de l’article original en Anglais faite par une IA.

Depuis son annonce il y a quelques mois, le Model Context Protocol (MCP) a suscité une attention considérable.

Initialement, MCP servait de mécanisme simple, essentiellement un système de plugins, permettant aux Grands Modèles de Langage (LLM) d’interagir de façon transparente avec leur environnement, améliorant ainsi les assistants et agents IA. En appliquant la théorie de Wardley pour tracer l’évolution du protocole, je dirais que MCP a dépassé l’étape I (qualifiée de genesis dans l’image), établissant une certitude de solution. De plus, son adoption généralisée suggère qu’il est déjà entré dans la phase II (qualifiée de Custom Built sur l’image).

Cet article, premier d’une série en trois parties, introduit le Model Context Protocol (MCP), un standard conçu pour permettre aux agents IA d’interagir avec divers environnements numériques au-delà des simples fenêtres de chat. Il définit des concepts clés tels que les agents, les environnements et l’autonomie, en soulignant la nécessité pour les agents d’accéder à des outils numériques via un protocole de communication structuré. MCP facilite cette interaction en définissant les MCP Servers (fournisseurs d’outils), les Hosts (applications exécutant des LLMs) et les MCP Clients, permettant ainsi aux agents d’exploiter les ressources, outils et prompts exposés par les serveurs. L’article défend l’idée que MCP est un élément clé de la prochaine révolution numérique, où les assistants IA exécuteront des tâches cognitives complexes. Il prépare également le terrain pour les prochains articles qui exploreront des implémentations concrètes avec Google VertexAI et un serveur de cybersécurité personnalisé.

Cet article détaille mon parcours dans la construction d’un hôte de chat personnalisé pour les agents d’IA, m’éloignant des solutions existantes pour acquérir une compréhension plus approfondie des technologies sous-jacentes. J’implémente un moteur de chat utilisant Vertex AI de Google et Go, en me concentrant sur la compatibilité avec l’API OpenAI pour l’intégration avec des outils comme Big-AGI. L’article couvre l’architecture centrale, incluant mon utilisation de ChatSession et GenerativeModel du SDK Vertex AI. Il approfondit l’implémentation du point de terminaison /v1/chat/completions, soulignant les défis liés aux réponses en streaming et à l’intégration des appels de fonction. Je décris également une solution de contournement pour gérer les appels de fonction dans un contexte de streaming et j’introduis le concept d’interface callable pour préparer l’implémentation du Protocole de Contexte de Modèle (MCP) dans les travaux futurs. L’objectif est de déplacer les outils en dehors de l’agent. Cela sera détaillé dans la dernière partie de cette série.

Cet ultime article d’une série en trois parties explore la séparation des outils de l’hôte grâce au Model Context Protocol (MCP), offrant flexibilité et réutilisabilité. L’auteur développe un outil basé sur MCP en Go pour exécuter des requêtes SQL via DuckDB, permettant une interaction fluide avec un chatbot tout en préservant la confidentialité. L’implémentation couvre la gestion des appels JSON-RPC, l’encapsulation des outils et leur intégration. Le projet valide l’efficacité de MCP, avec des perspectives d’évolution incluant le remplacement de VertexAI par Ollama et l’ajout de la gestion multi-session.

Note: Cet article est une traduction automatique. L’article original a été écrit en anglais.

Dans le monde hyper-compétitif d’aujourd’hui, les entreprises ne s’appuient plus uniquement sur des décisions instinctives ou intuitives ; elles dépendent d’insights basés sur les données pour rester agiles et prendre des décisions rapides et intelligentes. Cependant, les données seules ne sont pas la réponse ; elles sont le facilitateur pour créer un élan sur un volant d’inertie commercial et technologique : un modèle où les données guident les décisions, les décisions guident les actions, et ces actions génèrent de la valeur, propulsant l’entreprise vers l’avant dans un cycle auto-renforçant.

Note: Cet article est une traduction automatique. L’article original a été écrit en anglais.

Contexte

Lors d’un meetup récent que j’ai organisé dans ma ville natale de Lille, j’ai eu le plaisir d’accueillir Jean-Georges Perrin, qui a fourni une introduction complète aux contrats de données. En tant que geek, je me suis senti obligé de tester ce concept pour en saisir pleinement les implications pratiques.

L’objectif de cet article est de démontrer comment les contrats de données peuvent être appliqués et apporter de la valeur au sein d’un petit écosystème confronté à des défis inter-domaines.

Dans cet article, j’explore le concept de RAG, avec l’objectif d’écrire un RAG presque à partir de zéro pour le considérer comme un pur problème d’ingénierie. Apprendre en faisant à partir de zéro m’aidera éventuellement à découvrir une sorte d’exaptation qui peut guider mes décisions en tant qu’ingénieur et clarifier les points de confusion que j’ai dans la compréhension du système. J’ai utilisé des informations d’un article en Go car je maîtrise ce langage. Je décrirai une méthode étape par étape pour créer un RAG simple (bien que non efficace ou effectif), en notant les découvertes qui pourraient être utiles pour mon travail de consultant et d’ingénieur.