Service de recherche sémantique utilisant une base de données vectorielle Pinecone derrière un serveur MCP.

Un modèle de langage ne peut répondre qu’à partir de ce qu’il a vu pendant son entraînement. Les normes d’ingénierie, les manuels de politique, les spécifications des produits et les wikis internes lui restent invisibles, à moins que ces documents ne soient fournis au moment où la question est posée. Le processus décrit ici gère ce problème pour des collections PDF : les documents sont intégrés une seule fois dans Pinecone, et tout agent IA peut les interroger via un serveur MCP construit avec le SDK FastMCP.

Pourquoi la recherche par mots-clés est insuffisante

La recherche simple par mots-clés semble être la solution évidente, mais les gens formulent rarement leurs questions avec les mots exacts utilisés dans la documentation, ce qui fait que des passages pertinents échappent. Les dictionnaires de synonymes et l’expansion des requêtes aident, mais tous deux dépendent de relations entre mots définies manuellement. Aucun de ces systèmes ne comprend le sens réel des mots.

La recherche sémantique emprunte une voie différente. Les documents et les requêtes sont tous deux transformés en embeddings vectoriels qui codent le sens, et la pertinence est évaluée en comparant ces vecteurs à l’aide de la similarité cosinus, une mesure indiquant dans quelle mesure deux vecteurs pointent dans la même direction dans l’espace d’embedding. Un score plus élevé signifie un lien sémantique plus fort, de sorte que des passages liés apparaissent même si le vocabulaire diffère complètement. Une question telle que « Comment les plantes transforment-elles la lumière solaire en énergie ? » peut faire ressortir des textes sur les chloroplastes et la photosynthèse, même si aucun de ces termes n’y figure.

Deux composants : la base de données vectorielle et le serveur MCP

Le système se divise en deux parties qui peuvent évoluer indépendamment : un pipeline d’ingestion et un serveur MCP. L’ingestion s’exécute une fois par document. Par la suite, n’importe quel agent connecté peut interroger à plusieurs reprises les mêmes connaissances indexées via le serveur.

Le pipeline d’ingestion transforme les PDF bruts en vecteurs recherchables. Il extrait le texte, le divise en blocs chevauchants, crée des embeddings à l’aide de Pinecone Inference et enregistre les vecteurs dans un index Pinecone. L’embedding d’une grande collection nécessite de réels ressources de calcul, c’est pourquoi un simple journal permet d’éviter les travaux redondants. Pour chaque fichier indexé, il stocke l’heure de l’embedding le plus récent. Lors du prochain exécution, le pipeline compare l’heure de modification actuelle de chaque fichier avec celle enregistrée. Un document modifié reçoit de nouveaux embeddings, tandis qu’un document inchangé conserve ses vecteurs existants. La base de données reste à jour avec les modifications des documents, et aucune requête d’embedding redondante n’a lieu.

Le serveur MCP, basé sur FastMCP, reçoit une question en langue naturelle d’un agent, l’incorpore, effectue une recherche de similarité auprès de Pinecone et renvoie les fragments ayant le score le plus élevé. Comme l’interface est MCP, plusieurs applications d’IA peuvent partager un même service de récupération sans rien savoir de la base de données vectorielle ou du modèle d’incorporation qui la sous-tend.

La séparation de ces deux composants était intentionnelle. Il est possible de changer de modèle d’incorporation, d’adapter la méthode de segmentation en fragments ou de reconstruire l’index vectoriel sans toucher à l’interface MCP ni à aucun agent qui s’y réfère.

Création du pipeline d’incorporation et de segmentation

Les PDF sont conçus pour les yeux humains, et non pour la recherche par machine ; ils doivent donc d’abord être transformés en une représentation qui capture leur sens. Le processus commence par l’extraction du texte de chaque fichier à l’aide de la bibliothèque pypdf de Python, en lisant page par page et en regroupant les résultats en une seule chaîne de caractères afin de faciliter leur traitement ultérieur. Il prend en charge aussi bien des fichiers individuels que des dossiers entiers, ce qui permet d’indexer de nouveaux ensembles de documents sans modifier la partie de recherche.

Choix de la méthode de segmentation

Avec le texte extrait, le document est divisé en parties plus petites appelées chunks, et ce choix s’est avéré être l’un des plus déterminants dans l’ensemble du processus. Les modèles d’incorporation disposent de fenêtres de contexte fixes, ce qui exclut l’incorporation d’un document entier en un seul vecteur. Même lorsque le document entre dans ces limites, une seule incorporation de tout le fichier fournit une représentation vague et générale, car plusieurs sujets non liés sont regroupés, ce qui réduit la précision de la récupération.

Chaque document est donc divisé en blocs de taille fixe qui se chevauchent, ce qui permet à chaque embedding de représenter une portion de texte plus petite et plus ciblée. Le choix de la taille relève d’un équilibre entre le contexte et la spécificité. Les petits blocs permettent généralement des résultats plus précis, car chaque embedding capture une idée plus restreinte, bien qu’ils génèrent davantage de vecteurs et augmentent le temps d’indexation ainsi que l’espace de stockage. Les gros blocs conservent plus de contexte environnant et réduisent le nombre de vecteurs, mais chaque embedding couvre une plus large gamme d’informations, ce qui peut nuire à la précision. La segmentation sémantique ou tenant compte des phrases constitue une option plus sophistiquée, mais la segmentation simple à taille fixe s’est avérée être une base simple et efficace pour les recherches polyvalentes.

chunks = [
    text[i:i+500]
    for i in range(0, len(text), 450)
]

/*
Fixed-size overlapping chunk generation used during document ingestion.
A chunk length of 500 characters and a stride of 450 characters preserve
contextual continuity while maintaining semantic specificity.
*/

Embeddings avec Pinecone

Ensuite, les fragments de texte deviennent des embeddings. Un embedding est une représentation numérique dense d’un texte qui en encode le sens. Plutôt que de rechercher des mots-clés, la recherche sémantique compare des vecteurs, ce qui permet aux passages similaires de correspondre malgré des vocabulaires différents. Les vecteurs de « chat » et de « chien » se trouvent proches l’un de l’autre dans l’espace des embeddings, tandis que ceux de « chat » et d’« avion » sont éloignés l’un de l’autre, ce qui permet de calculer la similarité de manière mathématique et non par une correspondance exacte des mots.

Le modèle d’embedding utilisé ici est le multilingual-e5-large hébergé par Pinecone, auquel on accède via l’API Pinecone Inference. Un service hébergé signifie qu’il n’y a pas de modèle d’apprentissage automatique à déployer ou à maintenir, ce qui permet au code de traitement des données de se concentrer sur la gestion des documents et de simplifier l’architecture.

Celui-ci a été choisi car il est optimisé pour la récupération sémantique et couvre plus d’une centaine de langues. La famille E5 traite également les requêtes et les extraits de documents comme des types d’entrée distincts, ce qui est idéal pour la récupération d’informations. Lors de l’indexation, les fragments sont intégrés en tant qu’extraits, car ce sont eux qui constituent le contenu recherchable. Lors de la requête, la question de l’utilisateur est intégrée en tant que requête. Tous deux se retrouvent dans le même espace sémantique, ce qui augmente les chances de trouver le matériel adéquat, même lorsque la formulation diffère considérablement.

En termes de débit, les blocs sont envoyés à l’API par lots de 96, ce qui est le plus grand lot autorisé actuellement par Pinecone Inference pour le modèle multilingual-e5-large. Envoyer de nombreux blocs par requête réduit le nombre d’appels à l’API, permet une utilisation plus efficace des ressources et accélère l’indexation par rapport à l’envoi progressif des blocs un par un. Les embeddings finis ainsi que leurs métadonnées sont ensuite stockés dans la base de données vectorielle Pinecone, prêts à être récupérés.

embeddings = pc.inference.embed(
    model="multilingual-e5-large",
    inputs=batch,
    parameters={"input_type": "passage"}
)

Le serveur MCP pour la recherche sémantique

Une fois les documents indexés, les agents ont besoin d’un moyen d’y accéder. Plutôt que d’exposer directement la base de données vectorielle aux applications, un serveur Model Context Protocol développé avec FastMCP sert d’intermédiaire. MCP offre aux applications d’IA une méthode standard pour appeler des outils, permettant ainsi à tout client compatible d’utiliser la récupération de données sans avoir connaissance de la base de données ou du modèle d’incorporation sous-jacent. Cette couche supplémentaire permet au code de récupération d’être réutilisé, de rester facile à maintenir et de rester déconnecté des applications qui l’utilisent.

La récupération de données est la principale fonction du serveur. Lorsqu’un agent soumet une question, le serveur l’incorpore à l’aide du même modèle multilingual-e5-large utilisé lors de l’indexation, effectue une recherche de similarité sur l’index Pinecone et renvoie les fragments les mieux classés. L’utilisation d’un seul modèle des deux côtés permet aux fragments et aux requêtes de rester dans le même espace sémantique, ce qui rend leur comparaison significative.

Afin d’améliorer la qualité des résultats, l’outil de recherche ne renvoie que des correspondances présentant une similarité cosinus supérieure à 0,82. Dans les expériences, des scores supérieurs à cette valeur indiquaient généralement une forte adéquation sémantique entre la requête et le fragment de texte, tandis que des scores plus bas correspondaient au mieux à des liens peu étroits. L’élimination des correspondances moins pertinentes fournit aux modèles de langage ultérieurs un contexte plus pertinent. Une question telle que « Comment soumettre un rapport de dépenses ? » peut atteindre la bonne page de politique même si le document l’exprime différemment. En plus de la recherche, le serveur met à disposition des outils pour gérer la base de données vectorielle : insérer des vecteurs, les supprimer et lister les index disponibles.

Puisque le système est conçu pour une mise en œuvre d’entreprise, la sécurité fait partie intégrante de sa conception. Les identifiants proviennent de Azure Key Vault, et toute demande nécessite une clé API valide avant que toute opération de récupération ne soit effectuée. Les détails sensibles relatifs à l’infrastructure restent à l’écart des applications clientes, et l’accès aux documents indexés est protégé.

results = index.query(
    vector=query_embedding,
    top_k=5,
    include_metadata=True
)

Ce que le projet montre sur l’utilisation de RAG pour les documents internes

Un système de recherche sémantique efficace dépend autant des décisions d’ingénierie que des modèles de langage qui le sous-tendent. La stratégie de segmentation, le modèle d’incorporation, l’approche de regroupement des données et l’architecture de récupération influencent directement la qualité, l’échelle et la facilité de maintenance. En plaçant les opérations d’ingestion et de récupération derrière un serveur MCP, on obtient un système modulaire, réutilisable, facile à maintenir et facile à étendre au fur et à mesure que les besoins évoluent.

La version actuelle constitue une base solide offrant de larges possibilités d’évolution. Le découpage sémantique des données, le réclassement des modèles, la recherche hybride ainsi que des métadonnées plus riches pourraient tous améliorer davantage les résultats de recherche tout en préservant la structure modulaire. À mesure que la génération augmentée par la recherche devient courante dans l’IA d’entreprise, une recherche sémantique fiable devient un élément de base des systèmes de production, et associer Pinecone Inference à une couche de recherche MCP représente une méthode pratique et scalable pour créer une recherche sémantique réutilisable.