Pinecone : ce que c'est et comment l'utiliser

Notre enjeu est presque nul et mérite d'être déclaré quand même : nous sommes Geonode et nous vendons des proxies, qui n'ont rien à voir avec les bases vectorielles. La seule adjacence est qu'un système de retrieval a besoin de quelque chose sur quoi rechercher, et si ce contenu vient du web public, quelqu'un doit le collecter — c'est notre bout du pipeline, entièrement séparé de la base. Rien dans cet article n'exige d'acheter quoi que ce soit chez nous, et la section qui argumente contre une base vectorielle managée est là parce que c'est souvent la bonne réponse.

Ce que fait une base vectorielle

Les bases ordinaires font une correspondance exacte. Une base vectorielle correspond par similarité.

Le mécanisme : un modèle d'embedding convertit du texte, des images ou d'autre contenu en une liste de nombres — un vecteur — positionné de sorte que les choses similaires se retrouvent proches. Trouver des résultats pertinents devient trouver des points proches, un problème de géométrie plutôt que de matching de chaînes.

Pinecone se décrit comme « the vector database for AI agents and applications, built for semantic search, knowledge retrieval, and long-term memory at scale », avec la capacité présentée comme une recherche « through billions of items for similar matches to any object, in milliseconds ».

La raison pour laquelle cela est devenu une infrastructure plutôt qu'une bibliothèque, c'est l'échelle. Comparer une requête à un million de vecteurs par force brute est simple et lent ; le faire en millisecondes exige des indexes de plus proche voisin approximatif, et les faire tourner de façon fiable à l'échelle est un problème d'opérations. C'est ce que vend un service managé.

Le cas d'usage dominant est la génération augmentée par retrieval : à partir de la question d'un utilisateur, trouver les passages les plus pertinents de vos propres documents et les donner à un modèle de langage comme contexte. La base fournit l'étape « trouver les passages pertinents ».

Indexes, documents et records

Le modèle de données de Pinecone a changé de forme et mérite d'être compris tel qu'il est aujourd'hui.

Un index est l'endroit où vivent les données. La documentation explique qu'« a serverless index holds your data as documents or records, depending on how the index was created: an index created with a document schema holds documents, while an index created with a dense or sparse vector type holds records ».

Un schéma de document permet à un index de faire plusieurs métiers. Selon la documentation, « a single index with a document schema can mix multiple ranking field types: a dense_vector field for semantic search, a sparse_vector field for sparse-vector retrieval, and one or more string fields with full_text_search enabled for full-text search with BM25 and Lucene queries. »

Les métadonnées n'ont pas besoin de déclaration. « Any other fields you upsert are stored as metadata, automatically indexed for filtering — no schema declaration required. »

Le conseil de conception est énoncé clairement : « One index per use case is the typical pattern. Because a document can combine vectors, text, and metadata in the same record, a single index often covers what previously required two — pick the ranking signal per query with score_by. »

Ce dernier point est le plus important. La recherche full-text est disponible aux côtés de la recherche vectorielle dans le même index — « BM25 token matching with Lucene query syntax over text fields in your schema », Pinecone gérant « tokenization, IDF, and length normalization at index time and BM25 scoring at query time ». Pas de moteur de recherche séparé, et pas de modèle pour la moitié mots-clés.

La conséquence pratique : la recherche hybride — combiner similarité sémantique et correspondance exacte de mots-clés — est un choix au moment de la requête, pas d'architecture. Cela compte, parce que la recherche purement vectorielle est notoirement faible sur les identifiants exacts, les codes produits et les noms propres rares, et BM25 y est excellent.

Namespaces

La fonctionnalité qui influe le plus sur la conception d'une application multi-tenant.

La documentation : « Within an index, records are partitioned into namespaces, and all upserts, queries, and other data read and write operations always target one namespace. »

Deux bénéfices sont nommés. Multitenancy — « when you need to isolate data between customers, you can use one namespace per customer and target each customer's writes and queries to their dedicated namespace. » Et requêtes plus rapides — « when you divide records into namespaces in a logical way, you speed up queries by ensuring only relevant records are scanned. »

Trois notes opérationnelles.

Ils sont créés implicitement. « Namespaces are created automatically during upsert. If a namespace doesn't exist, it is created implicitly. » Pratique, et cela signifie qu'une faute de frappe dans un nom de namespace produit une recherche silencieusement vide plutôt qu'une erreur.

La limite dépend de l'offre. « Namespaces per serverless index vary by plan. On the Standard and Enterprise plans, Pinecone can accommodate million-scale namespaces and beyond for specific use cases. If your application requires more than 100,000 namespaces, contact Support. »

L'isolation est le point. Pour tout ce qui contient les données de plusieurs clients, un namespace par client est le schéma, et cela fait de la fuite inter-tenant une question de bon paramètre plutôt que de bon filtre.

Embeddings : les vôtres ou les leurs

Deux approches, et le choix a de vraies conséquences.

Embedding intégré. La documentation le décrit en quatre étapes : « Create an index that is integrated with one of Pinecone's hosted embedding models. Upsert your source text. Pinecone uses the integrated model to convert the text to vectors automatically. Search with a query text. Again, Pinecone uses the integrated model to convert the text to a vector automatically. »

Plus simple — vous envoyez du texte et recevez des résultats, sans pipeline d'embedding à vous. Une restriction documentée : « Indexes with integrated embedding do not support updating or importing with text. »

Apportez vos propres vecteurs. Vous exécutez le modèle d'embedding, créez un index qui correspond à ses caractéristiques, et upserttez les vecteurs directement, en utilisant « the same external embedding model to convert a query to a vector ».

Plus de travail, plus de contrôle. Cela permet d'utiliser un modèle que Pinecone n'héberge pas, d'exécuter l'embedding en local pour des raisons de confidentialité ou de coût, et — surtout — de changer de modèle à votre rythme.

La considération qui tranche pour beaucoup de gens : changer de modèle d'embedding signifie tout ré-embedder. Les vecteurs de modèles différents ne sont pas comparables, donc un changement est un ré-index complet. L'embedding intégré facilite la construction initiale et lie la décision au catalogue de modèles du fournisseur ; apporter les vôtres rend la construction plus dure et garde le choix. Ni l'un ni l'autre n'est faux, et il vaut mieux décider délibérément plutôt que de suivre le premier tutoriel.

Charger des données à l'échelle

Une note de coût facile à rater et chère à découvrir.

La documentation est précise : « To control costs when ingesting large datasets (10,000,000+ records), use import instead of upsert. »

Deux routes d'ingestion existent. Upsert envoie les records par l'API. Import lit des fichiers Parquet depuis l'object storage, et la documentation l'appelle « the most efficient and cost-effective way to load large numbers of records into an index ».

Puisque les écritures sont facturées par million de write units, la différence entre ces deux chemins sur une charge initiale importante est un vrai chiffre, pas une erreur d'arrondi. Si vous construisez un index sur des millions de records, prévoyez le chemin import dès le départ — le rattraper après une première charge coûteuse est une leçon que personne n'a besoin de payer deux fois.

Démarrer en pratique

La forme d'une première implémentation, et les décisions qui y sont embarquées.

Créez un index et upserttez. Avec l'embedding intégré, le flux est court — vous ne touchez jamais un vecteur :

from pinecone import Pinecone

pc = Pinecone(api_key=API_KEY)

index = pc.Index(host=INDEX_HOST)

index.upsert_records(
    namespace="customer-42",
    records=[
        {"_id": "doc-1", "chunk_text": "Refunds are processed within 14 days.",
         "source": "policy.pdf", "page": 3},
        {"_id": "doc-2", "chunk_text": "Shipping to the EU takes 3-5 working days.",
         "source": "shipping.pdf", "page": 1},
    ],
)

Notez que source et page n'ont jamais été déclarés. Tout ce qui dépasse les champs de ranking est stocké en métadonnées et indexé pour le filtrage automatiquement, ce qui signifie que vous pouvez ajouter des champs plus tard sans migration.

Requête avec un filtre :

results = index.search(
    namespace="customer-42",
    query={"inputs": {"text": "how long do refunds take?"}, "top_k": 5,
           "filter": {"source": {"$eq": "policy.pdf"}}},
)

Trois décisions dans cet extrait méritent d'être prises délibérément.

Taille des chunks. Le texte que vous upserttez est l'unité qui revient, donc le chunking détermine ce que voit votre modèle. Des chunks trop petits perdent le contexte qui les rend significatifs ; trop grands, et vous récupérez surtout du texte hors sujet à côté de la phrase pertinente. Il n'y a pas de réponse universelle — quelques centaines de mots avec un peu de chevauchement est un point de départ raisonnable, et mesurer bat deviner.

Les métadonnées sont votre surface de filtre. Stockez tout ce par quoi vous pourriez plus tard restreindre : document source, date, section, langue, niveau d'accès. L'ajouter à l'upsert ne coûte rien ; l'ajouter après signifie tout ré-upsertter.

Un namespace par tenant, toujours, dès le début. Greffer l'isolation dans un index à un seul namespace veut dire tout ré-upsertter vers la bonne cible. Commencer avec des namespaces coûte un paramètre et supprime toute une catégorie d'incident futur.

Et gardez le texte source. Stockez les documents originaux quelque part que vous contrôlez, avec le code de chunking. Si vous changez de modèle d'embedding, de taille de chunk ou de stratégie de chunking — et vous le ferez — reconstruire l'index est une relance, pas un exercice d'archéologie.

Tarifs, vérifiés

D'après la page tarifaire de Pinecone, vérifiée en septembre 2026. Vérifiez avant de budgéter.

Quatre observations qui comptent pour la planification.

L'offre gratuite est vraiment utilisable pour évaluer. Deux gigaoctets de stockage et un million de read units par mois suffisent à construire un vrai prototype sur un corpus documentaire substantiel.

Builder est un forfait, pas un minimum. À 20 $/mois avec des plafonds fixes, c'est prévisible d'une façon que les offres à l'usage ne le sont pas — utile pour une petite application de production où vous préférez une facture que vous pouvez prévoir.

Standard et Enterprise sont des minimums avec dépassement. Les 50 $ et 500 $ sont des planchers, pas des plafonds. Votre coût réel est à l'usage au-dessus.

Les lectures coûtent environ quatre fois les écritures par million d'units. À 16–18 $ par million de read units contre 4–4,50 $ pour les écritures, une application lourde en lecture — ce que sont la plupart des systèmes de retrieval — verra les requêtes dominer la facture. Mettre en cache les requêtes fréquentes est donc un levier de coût direct, pas seulement de latence.

Enterprise ajoute un SLA de 99,95 % de disponibilité, un déploiement bring-your-own-cloud, des private endpoints et des journaux d'audit — l'ensemble habituel de choses qui comptent pour un processus d'achat et rien du tout pour un prototype.

Quand vous n'avez pas besoin d'une base vectorielle managée

La section qu'un fournisseur n'écrirait pas, incluse parce que c'est souvent la réponse.

Quand votre corpus est petit. En dessous d'environ cent mille vecteurs, la recherche de similarité par force brute en mémoire est assez rapide sur du matériel ordinaire. Un tableau NumPy et un produit scalaire répondent en millisecondes, ne coûtent rien, et retirent une dépendance externe de votre architecture. Le seuil où l'indexation approximative devient nécessaire est plus haut que la plupart des gens ne le supposent.

Quand vous faites déjà tourner Postgres. L'extension pgvector ajoute la recherche de similarité vectorielle à une base que vous opérez et sauvegardez déjà. Pour beaucoup d'applications, c'est la bonne réponse : un système de moins, une cohérence transactionnelle avec vos autres données, et pas de facture séparée.

Quand une bibliothèque embarquée suffit. Des bibliothèques comme FAISS ou un vector store local gèrent des millions de vecteurs dans un seul processus. Si vos données tiennent sur une machine et que le volume de requêtes est modeste, un service managé résout un problème d'opérations que vous n'avez pas.

Quand la recherche par mots-clés suffirait. Une part significative de « nous avons besoin de recherche sémantique » est bien servie par BM25, moins cher, plus rapide, entièrement explicable et meilleur sur les identifiants exacts. Essayez d'abord — et notez que si vous finissez sur Pinecone, sa recherche full-text couvre cela dans le même index.

Quand vous n'avez pas mesuré la qualité du retrieval. La base n'est généralement pas le facteur limitant d'un système de retrieval. La stratégie de chunking, le choix du modèle d'embedding et la formulation de la requête comptent bien plus, et les trois peuvent être testés avec cent lignes de code local avant toute décision d'infrastructure.

Le cas pour un service managé est réel et précis : plusieurs millions de vecteurs, un volume de requêtes exigeant une latence basse constante, une isolation multi-tenant, et une équipe qui préfère ne pas opérer un index distribué. Si deux ou plus s'appliquent, il gagne son coût.

Questions fréquentes

À quoi sert Pinecone ?

Recherche sémantique, retrieval de connaissances et mémoire à long terme pour les applications d'IA. Le schéma dominant est la génération augmentée par retrieval : trouver les passages de vos propres documents les plus pertinents pour une question, et les fournir à un modèle de langage comme contexte.

Pinecone est-il gratuit ?

Il existe une offre Starter gratuite avec jusqu'à 2 Go de stockage, 2M de write units et 1M de read units par mois, et 1 Go d'egress. C'est vraiment suffisant pour construire et évaluer un vrai prototype avant de s'engager sur une offre payante.

Combien coûte Pinecone ?

Starter est gratuit ; Builder est un forfait de 20 $/mois avec des plafonds fixes ; Standard a un minimum d'usage de 50 $/mois et Enterprise 500 $/mois ; les deux facturent le stockage à 0,33 $/Go/mois, les écritures à 4–4,50 $ par million d'units et les lectures à 16–18 $ par million, avec un egress à 0,10 $/Go après 100 Go.

Qu'est-ce qu'un namespace dans Pinecone ?

Une partition à l'intérieur d'un index. Chaque lecture et écriture cible exactement un namespace, ce qui en fait le mécanisme standard d'isolation multi-tenant — un namespace par client — et une optimisation de performance, puisque les requêtes ne scannent que la partition pertinente.

Dois-je utiliser l'embedding intégré ou mes propres vecteurs ?

L'embedding intégré est plus simple : envoyez du texte, Pinecone convertit. Apporter les vôtres vous donne le choix du modèle et la portabilité, ce qui compte parce que changer de modèle d'embedding exige de tout ré-embedder. Les indexes intégrés ne prennent pas non plus en charge la mise à jour ni l'import avec du texte.

Pinecone peut-il faire de la recherche par mots-clés en plus de la recherche vectorielle ?

Oui. Les champs string avec full_text_search activé prennent en charge le ranking BM25 avec la syntaxe de requête Lucene, dans le même index que les vecteurs dense et sparse, la méthode de scoring étant choisie par requête. Cela compte parce que la recherche purement vectorielle gère mal les identifiants exacts et les termes rares.

Comment charger des millions de records efficacement ?

Utilisez l'import depuis l'object storage plutôt que l'upsert. La documentation le recommande explicitement pour les jeux de plus de dix millions de records et le décrit comme la voie la plus économique, ce qui compte puisque les écritures sont facturées par million d'units.

Ai-je vraiment besoin d'une base vectorielle ?

Souvent non. En dessous d'environ cent mille vecteurs, la force brute en mémoire est assez rapide et gratuite. Si vous faites déjà tourner Postgres, pgvector évite un système séparé. Et une part non négligeable des besoins de « recherche sémantique » est bien servie par la recherche par mots-clés, moins chère et plus explicable.

Pour conclure

Pinecone est une base vectorielle managée qui a grandi vers quelque chose de plus large : un index peut désormais contenir ensemble des vecteurs dense, des vecteurs sparse et des champs full-text, la méthode de ranking étant choisie par requête. Cette consolidation est le changement récent le plus utile, parce que le retrieval hybride cesse d'être une décision d'architecture et devient un paramètre.

Trois choses façonnent la façon dont vous devez concevoir autour. Les namespaces sont le mécanisme d'isolation et de performance, et ils sont créés implicitement — un namespace mal tapé renvoie un résultat vide plutôt qu'une erreur. Le choix d'embedding est plus collant qu'il n'y paraît, puisque changer de modèle signifie ré-embedder tout le corpus. Et les lectures coûtent plusieurs fois ce que coûtent les écritures, ce qui fait du cache de requêtes un levier de coût direct dans un système lourd en lecture.

Les tarifs sont transparents et l'offre gratuite assez large pour répondre à la vraie question : si la qualité du retrieval est suffisante pour votre cas. Cette question ne porte pas sur la base — le chunking, le choix d'embedding et la formulation de la requête la dominent — et elle peut être tranchée en local avant qu'aucune infrastructure n'existe.

C'est le point de clôture honnête. Une base vectorielle managée gagne sa place à l'échelle, avec le multi-tenancy, ou quand vous préférez ne pas opérer un index distribué. En dessous, un tableau en mémoire ou une extension sur le Postgres que vous faites déjà tourner fera le travail pour rien, et il vaut la peine d'établir dans quelle situation vous êtes avant de signer pour l'un ou l'autre.