Pinecone : définition, fonctionnement et exemple en Python

Pinecone est une base de données spécialisée dans un seul type de donnée : le vecteur. Dans une application d'IA générative, chaque document, paragraphe ou image est converti en embedding, une liste de plusieurs centaines de nombres qui encode son sens. Retrouver les contenus pertinents pour une question revient alors à chercher les vecteurs les plus proches de celui de la question. Pinecone fait exactement cela, à l'échelle de millions ou de milliards de vecteurs.

L'entreprise a été fondée en 2019 par Edo Liberty, ancien responsable de laboratoire de recherche chez Amazon et Yahoo, et a ouvert son service au public en 2021. L'essor des LLM et du RAG à partir de 2023 en a fait l'une des bases vectorielles les plus citées. En 2024, Pinecone a lancé une architecture serverless qui sépare le stockage, confié à un stockage objet, de la puissance de calcul, allouée à la demande.

Son positionnement est net : Pinecone est un service managé, et uniquement cela. Il n'existe pas de version open source à installer sur vos serveurs. On crée un index par API, on y écrit, on l'interroge, et l'éditeur se charge de la réplication, des sauvegardes et de la montée en charge. C'est ce qui le distingue de bases comme Weaviate ou Qdrant, open source et auto-hébergeables.

À retenir : Pinecone ne génère pas de texte et ne comprend pas les documents. Il stocke des vecteurs produits par un modèle d'embedding et retrouve rapidement les plus proches.

Une plateforme de support veut retrouver les réponses de sa FAQ les plus proches d'une question client, en isolant les données de chacun de ses clients. Le code suivant utilise le SDK officiel (paquet pinecone) et un modèle d'embedding open source exécuté localement.

import os

from pinecone import Pinecone, ServerlessSpec
from sentence_transformers import SentenceTransformer

pc = Pinecone(api_key=os.environ["PINECONE_API_KEY"])
encoder = SentenceTransformer("sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2")

# 1. Index serverless : la dimension est celle du modèle (384)
index_name = "support-faq"
if not pc.has_index(index_name):
    pc.create_index(
        name=index_name,
        dimension=384,
        metric="cosine",
        spec=ServerlessSpec(cloud="aws", region="eu-west-1"),
    )
index = pc.Index(index_name)

# 2. Upsert : identifiant, vecteur et métadonnées, dans le namespace du client
faq = [
    {"id": "faq-001", "text": "Le remboursement intervient sous 14 jours après réception du retour.", "produit": "boutique", "annee": 2026},
    {"id": "faq-002", "text": "Les frais de livraison sont offerts dès 50 euros d'achat.", "produit": "boutique", "annee": 2025},
    {"id": "faq-003", "text": "L'abonnement peut être résilié à tout moment depuis l'espace client.", "produit": "abonnement", "annee": 2026},
]
index.upsert(
    vectors=[
        {
            "id": item["id"],
            "values": encoder.encode(item["text"]).tolist(),
            "metadata": {"text": item["text"], "produit": item["produit"], "annee": item["annee"]},
        }
        for item in faq
    ],
    namespace="client-acme",
)

# 3. Query : les 3 vecteurs les plus proches, filtrés sur les métadonnées
question = "Sous quel délai suis-je remboursé ?"
results = index.query(
    namespace="client-acme",
    vector=encoder.encode(question).tolist(),
    top_k=3,
    filter={"produit": {"$eq": "boutique"}, "annee": {"$gte": 2025}},
    include_metadata=True,
)
for match in results.matches:
    print(match.id, round(match.score, 3), match.metadata["text"])

Trois points méritent attention. La dimension de l'index doit correspondre exactement à celle du modèle d'embedding, et la question doit être vectorisée avec ce même modèle. Le texte d'origine est stocké dans les métadonnées pour pouvoir l'afficher ou le transmettre au LLM sans seconde requête. Enfin, le filtre restreint la recherche aux vecteurs dont les métadonnées respectent les conditions, avec des opérateurs proches de ceux de MongoDB ($eq, $in, $gte, $and...). Dans un RAG, ces résultats sont ensuite injectés dans le prompt, souvent par l'intermédiaire de LangChain ou de LlamaIndex, qui disposent d'intégrations officielles.

Pinecone structure les données sur trois niveaux, qu'il faut concevoir avant d'écrire le premier vecteur.

• Index : le conteneur principal, défini par une dimension, une métrique et une région. Un index est dense (vecteurs d'embeddings classiques) ou creux (vecteurs de termes pour la recherche lexicale). On crée en général un index par modèle d'embedding.
• Namespace : une partition de l'index. Requêtes et écritures ciblent toujours un namespace, ce qui garantit l'isolation des données. On l'utilise pour séparer les clients d'un SaaS, les environnements ou les langues. Supprimer toutes les données d'un client revient à supprimer son namespace.
• Métadonnées : des paires clé-valeur (texte, nombre, booléen, liste de textes) attachées à chaque vecteur. Elles servent à filtrer la recherche (par date, source, droit d'accès) et à restituer le contenu.

L'architecture serverless

Dans l'architecture serverless, les vecteurs sont stockés sur un stockage objet et regroupés en fichiers indexés. Les requêtes sont traitées par des ressources de calcul allouées à la demande, qui ne chargent que les portions utiles de l'index. Conséquence pratique : il n'y a plus de capacité à réserver, et la facturation suit les volumes stockés, lus et écrits. L'architecture historique à base de pods, où l'on choisissait le type et le nombre de machines, laisse place à ce modèle, désormais recommandé par l'éditeur.

La recherche hybride

La recherche vectorielle seule rate parfois des correspondances exactes : un code produit, un nom propre, un acronyme interne. Pinecone répond à ce besoin avec des vecteurs creux, qui encodent la présence et le poids des termes. On peut stocker vecteurs denses et creux dans un même index et pondérer leur contribution, ou interroger un index dense et un index creux puis fusionner les classements, par exemple avec la Reciprocal Rank Fusion. Un modèle de reranking hébergé peut ensuite réordonner les meilleurs résultats.

Le choix d'une base vectorielle se joue moins sur la qualité de la recherche, comparable d'une solution à l'autre, que sur le modèle d'exploitation. Voici comment Pinecone se situe face aux trois alternatives les plus fréquentes.

Une démarche fréquente consiste à prototyper avec un index en mémoire ou pgvector, puis à choisir la base de production selon les contraintes : souveraineté des données et réversibilité orientent vers une solution open source, absence d'équipe d'exploitation vers Pinecone. Notre article Pinecone : la base de données vectorielle managée revient en détail sur le fonctionnement des bases vectorielles.