Pinecone: Nedir ve Nasıl Kullanılır

Çıkarımız neredeyse sıfır ve yine de belirtmeye değer: biz Geonode ve vekil satıyoruz; bunların vektör veritabanlarıyla ilgisi yok. Tek komşuluk, bir geri getirme sisteminin üzerine arama yapacak bir şeye ihtiyaç duyması ve bu içerik kamuya açık webden geliyorsa birinin onu toplaması gerektiğidir — bu, boru hattının bizim ucumuzdur ve veritabanından tamamen ayrıdır. Bu yazının hiçbir yerinde bizden bir şey satın almanız gerekmez; yönetilen vektör veritabanına karşı çıkan bölüm, sıklıkla doğru cevap olduğu için eklendi.

Vektör veritabanı ne yapar

Sıradan veritabanları tam eşleşir. Vektör veritabanı benzerliğe göre eşleşir.

Mekanizma: bir embedding modeli metni, görselleri veya başka içeriği bir sayı listesine — bir vektöre — çevirir; benzer şeyler birbirine yakın duracak şekilde konumlanır. İlgili sonuçları bulmak, yakındaki noktaları bulmak olur; bir dize eşleştirme değil, bir geometri problemidir.

Pinecone kendini "the vector database for AI agents and applications, built for semantic search, knowledge retrieval, and long-term memory at scale" olarak tanımlar; yetenek "through billions of items for similar matches to any object, in milliseconds" diye çerçevelenir.

Bunun bir kütüphane değil altyapı olmasının nedeni ölçek. Bir sorguyu bir milyon vektörle kaba kuvvetle karşılaştırmak basit ve yavaştır; bunu milisaniyelerde yapmak yaklaşık en yakın komşu indexes gerektirir ve bunları ölçekte güvenilir işletmek bir operasyon problemidir. Yönetilen hizmetin sattığı budur.

Baskın kullanım durumu geri getirme ile artırılmış üretimdir: kullanıcının sorusu verildiğinde kendi belgelerinizden en ilgili pasajları bulun ve bir dil modeline bağlam olarak verin. Veritabanı "ilgili pasajları bul" adımını sağlar.

Indexes, belgeler ve records

Pinecone'un veri modeli şekil değiştirdi ve mevcut haliyle anlaşılmaya değer.

Index, verinin yaşadığı yerdir. Belgelendirme şunu açıklar: "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".

Bir belge şeması tek bir index'in birkaç iş yapmasını sağlar. Belgelendirmeye göre "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."

Meta veri bildirim gerektirmez. "Any other fields you upsert are stored as metadata, automatically indexed for filtering — no schema declaration required."

Tasarım rehberi açıkça belirtilir: "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."

Son nokta asıl önemli olan. Tam metin arama, vektör aramanın yanında aynı index'te kullanılabilir — "BM25 token matching with Lucene query syntax over text fields in your schema"; Pinecone "tokenization, IDF, and length normalization at index time and BM25 scoring at query time" işini üstlenir. Ayrı arama motoru yok, anahtar kelime yarısı için model de yok.

Pratik sonuç: hibrit arama — anlamsal benzerliği tam anahtar kelime eşleştirmesiyle birleştirmek — bir mimari değil, sorgu anı seçimidir. Bu önemlidir çünkü salt vektör arama tam tanımlayıcılarda, ürün kodlarında ve nadir özel adlarda kötü şöhretle zayıftır; BM25 tam bunlarda mükemmeldir.

Namespaces

Çok kiracılı bir uygulamayı nasıl tasarladığınızı en çok etkileyen özellik.

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

İki fayda adlandırılır. Çok kiracılık — "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." Ve daha hızlı sorgular — "when you divide records into namespaces in a logical way, you speed up queries by ensuring only relevant records are scanned."

Üç operasyonel not.

Örtük oluşturulurlar. "Namespaces are created automatically during upsert. If a namespace doesn't exist, it is created implicitly." Kullanışlıdır ve bir namespace adındaki yazım hatası hata yerine sessizce boş bir arama üretir.

Limit plana bağlıdır. "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."

İzolasyon asıl meseledir. Birkaç müşterinin verisini tutan her şey için müşteri başına bir namespace kalıptır; kiracılar arası sızıntı bir süzgeci değil bir parametreyi doğru yapmak meselesi olur.

Embeddings: sizinki mi onunki mi

İki yaklaşım, ve seçimin gerçek sonuçları var.

Entegre embedding. Belgelendirme bunu dört adımda anlatır: "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."

Daha basit — metin gönderir, sonuç alırsınız; kendi embedding boru hattınız yoktur. Belgelenmiş bir kısıt: "Indexes with integrated embedding do not support updating or importing with text."

Kendi vektörlerinizi getirin. Embedding modelini siz çalıştırır, özelliklerine uyan bir index oluşturur ve vektörleri doğrudan upsert edersiniz; "the same external embedding model to convert a query to a vector" kullanırsınız.

Daha çok iş, daha çok kontrol. Pinecone'un barındırmadığı bir modeli kullanmanızı, gizlilik veya maliyet için embedding'i yerelde çalıştırmanızı ve — kritik olarak — modelleri kendi takviminizde değiştirmenizi sağlar.

Birçok kişi için kararı veren husus: embedding modelini değiştirmek her şeyi yeniden embed etmek demektir. Farklı modellerin vektörleri karşılaştırılamaz, bu yüzden geçiş tam bir yeniden index'tir. Entegre embedding ilk kurulumu kolaylaştırır ve kararı satıcının model kataloğuna bağlar; kendinizinkini getirmek kurulumu zorlaştırır ve seçimi sizde tutar. İkisi de yanlış değil; ilk izlediğiniz öğreticiye göre değil, bilinçli karar vermeye değer.

Ölçekte veri yükleme

Gözden kaçması kolay, keşfi pahalı bir maliyet notu.

Belgelendirme somut: "To control costs when ingesting large datasets (10,000,000+ records), use import instead of upsert."

İki alma yolu vardır. Upsert, records'ı API üzerinden gönderir. Import, nesne depolamasından Parquet dosyalarını okur ve belgelendirme bunu "the most efficient and cost-effective way to load large numbers of records into an index" diye adlandırır.

Yazmalar milyon write units başına faturalandığı için büyük bir ilk yüklemede bu iki yol arasındaki fark yuvarlama hatası değil gerçek bir sayıdır. Milyonlarca record üzerinde bir index kuruyorsanız import yolunu baştan planlayın — pahalı bir ilk yüklemeden sonra uyarlamak, kimsenin iki kez ödemesi gerekmeyen bir derstir.

Pratikte başlamak

İlk uygulamanın şekli ve içine gömülü kararlar.

Bir index oluşturun ve upsert edin. Entegre embedding ile akış kısadır — bir vektöre hiç dokunmazsınız:

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},
    ],
)

source ve page'in hiç bildirilmediğine dikkat edin. Sıralama alanlarının ötesindeki her şey meta veri olarak saklanır ve süzme için otomatik index'lenir; yani alanları sonra, göç olmadan ekleyebilirsiniz.

Süzgeçli sorgu:

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

Bu parçadaki üç karar bilinçli alınmaya değer.

Chunk boyutu. Upsert ettiğiniz metin geri gelen birimdir, dolayısıyla parçalama modelin ne gördüğünü belirler. Çok küçük parçalar onları anlamlı kılan bağlamı kaybeder; çok büyükler ilgili cümlenin yanında çoğunlukla ilgisiz metin getirir. Evrensel cevap yoktur — biraz örtüşmeli birkaç yüz kelime makul bir başlangıçtır ve ölçmek tahminden iyidir.

Meta veri süzgeç yüzeyinizdir. Sonra daraltmak isteyebileceğiniz her şeyi saklayın: kaynak belge, tarih, bölüm, dil, erişim düzeyi. Upsert anında eklemek bedelsizdir; sonradan eklemek yeniden upsert demektir.

Kiracı başına namespace, her zaman, baştan. Tek namespace'li bir index'e sonradan izolasyon eklemek, her şeyi doğru hedefe yeniden upsert etmek demektir. Namespaces ile başlamak bir parametreye mal olur ve gelecekteki bir olay kategorisini kaldırır.

Ve kaynak metni saklayın. Orijinal belgeleri, parçalama koduyla birlikte kontrol ettiğiniz bir yerde tutun. Embedding modelini, chunk boyutunu veya parçalama stratejisini değiştirirseniz — ve değiştireceksiniz — index'i yeniden kurmak arkeoloji değil yeniden çalıştırmadır.

Fiyatlandırma, doğrulandı

Pinecone'un kendi fiyat sayfasından, Eylül 2026'da kontrol edildi. Bütçelemeden önce doğrulayın.

Planlama için önemli dört gözlem.

Ücretsiz katman değerlendirme için gerçekten kullanılabilir. İki gigabayt depolama ve ayda bir milyon read units, kayda değer bir belge kümesi üzerinde gerçek bir prototip kurmaya yeter.

Builder sabit ücrettir, asgari değil. Ayda 20 $ ve sabit tavanlarla, kullanıma dayalı planların olmadığı şekilde öngörülebilirdir — faturayı kestirmek istediğiniz küçük bir üretim uygulaması için yararlıdır.

Standard ve Enterprise aşım içeren asgarilerdir. 50 $ ve 500 $ tabandır, tavan değil. Gerçek maliyetiniz bunların üzerindeki kullanımdır.

Okumalar, milyon units başına yazmaların kabaca dört katına mal olur. Milyon read units için 16–18 $'a karşı yazmalar için 4–4,50 $ ile, okuma ağırlıklı bir uygulama — çoğu geri getirme sistemi böyledir — sorguların faturaya hükmettiğini görür. Sık sorguları önbelleğe almak bu yüzden yalnızca gecikme değil doğrudan bir maliyet koludur.

Enterprise %99,95 uptime SLA, bring-your-own-cloud dağıtımı, private endpoints ve denetim günlükleri ekler — bir tedarik sürecinde önemsenen ve bir prototip için hiç önemsenmeyen olağan küme.

Yönetilen vektör veritabanına ihtiyaç duymadığınız zaman

Bir satıcının yazmayacağı bölüm; sıklıkla cevap olduğu için eklendi.

Derleminiz küçükken. Kabaca yüz bin vektörün altında bellek içi kaba kuvvet benzerlik araması sıradan donanımda yeterince hızlıdır. Bir NumPy dizisi ve bir nokta çarpımı milisaniyelerde yanıt verir, hiçbir şey tutmaz ve mimariden dış bir bağımlılığı kaldırır. Yaklaşık indekslemenin gerekli olduğu eşik çoğu insanın sandığından yüksektir.

Zaten Postgres çalıştırıyorsanız. pgvector eklentisi, zaten işlettiğiniz ve yedeklediğiniz bir veritabanına vektör benzerlik araması ekler. Birçok uygulama için doğru cevap budur: bir sistem daha az, diğer verilerinizle işlemsel tutarlılık, ayrı fatura yok.

Gömülü bir kütüphane yetiyorsa. FAISS gibi kütüphaneler veya yerel bir vector store tek süreçte milyonlarca vektörü kaldırır. Veriniz bir makineye sığıyorsa ve sorgu hacmi mütevazıysa, yönetilen hizmet sahip olmadığınız bir operasyon problemini çözüyordur.

Anahtar kelime araması işe yarayacaksa. "Anlamsal aramaya ihtiyacımız var"ın anlamlı bir payı BM25 ile iyi karşılanır: daha ucuz, daha hızlı, tamamen açıklanabilir ve tam tanımlayıcılarda daha iyidir. Önce deneyin — ve Pinecone'a düşerseniz tam metin aramasının bunu aynı index'te karşıladığını not edin.

Geri getirme kalitesini ölçmediyseniz. Veritabanı genellikle bir geri getirme sistemindeki sınırlayıcı faktör değildir. Parçalama stratejisi, embedding modeli seçimi ve sorgu formülasyonu çok daha önemlidir; üçü de herhangi bir altyapı kararından önce yüz satır yerel kodla test edilebilir.

Yönetilen bir hizmet lehindeki gerekçe gerçek ve özgüdür: milyonlarca vektör, tutarlı düşük gecikme isteyen sorgu hacmi, çok kiracılı izolasyon ve dağıtık bir index işletmek istemeyen bir ekip. Bunlardan iki veya daha fazlası geçerliyse maliyetini hak eder.

Sık sorulanlar

Pinecone ne için kullanılır?

Yapay zeka uygulamaları için anlamsal arama, bilgi geri getirme ve uzun süreli bellek. Baskın kalıp geri getirme ile artırılmış üretimdir: bir soruya en ilgili kendi belge pasajlarınızı bulmak ve bunları bir dil modeline bağlam olarak vermek.

Pinecone ücretsiz mi?

Aylık 2 GB'a kadar depolama, 2M write units ve 1M read units ile 1 GB egress sunan ücretsiz bir Starter planı var. Ücretli bir plana bağlanmadan gerçek bir prototip kurup değerlendirmek için gerçekten yeter.

Pinecone ne kadar tutar?

Starter ücretsizdir; Builder sabit tavanlarla ayda 20 $ düz ücrettir; Standard'ın aylık 50 $, Enterprise'ın 500 $ kullanım asgarisi vardır; ikisi de depolamayı 0,33 $/GB/ay, yazmaları milyon units başına 4–4,50 $, okumaları milyon başına 16–18 $ faturalar; egress 100 GB'tan sonra 0,10 $/GB'tır.

Pinecone'da namespace nedir?

Bir index içindeki bölüm. Her okuma ve yazma tam olarak bir namespace'i hedefler; bu da onu çok kiracılı izolasyonun standart mekanizması — müşteri başına bir namespace — ve bir performans iyileştirmesi yapar, çünkü sorgular yalnızca ilgili bölümü tarar.

Entegre embedding mi kendi vektörlerim mi?

Entegre embedding daha basittir: metin gönderin, Pinecone dönüştürsün. Kendinizinkini getirmek model seçimi ve taşınabilirlik verir; embedding modelini değiştirmek her şeyi yeniden embed etmeyi gerektirdiği için bu önemlidir. Entegre indexes ayrıca metinle güncellemeyi veya import'u desteklemez.

Pinecone vektör aramanın yanı sıra anahtar kelime araması da yapabilir mi?

Evet. full_text_search etkin string alanları Lucene sorgu sözdizimiyle BM25 sıralamasını, yoğun ve seyrek vektörlerle aynı index'te destekler; skor yöntemi sorgu başına seçilir. Bu önemlidir çünkü salt vektör arama tam tanımlayıcıları ve nadir terimleri kötü idare eder.

Milyonlarca record'u verimli nasıl yüklerim?

Upsert yerine nesne depolamasından import kullanın. Belgelendirme bunu on milyon kaydın üzerindeki veri kümeleri için açıkça önerir ve en uygun maliyetli yol olarak tanımlar; yazmalar milyon units üzerinden faturalandığı için bu önemlidir.

Hiç vektör veritabanına ihtiyacım var mı?

Çoğu zaman hayır. Kabaca yüz bin vektörün altında bellek içi kaba kuvvet yeterince hızlı ve ücretsizdir. Zaten Postgres çalıştırıyorsanız pgvector ayrı bir sistemi önler. Ve "anlamsal arama" gereksinimlerinin adil bir payı daha ucuz ve daha açıklanabilir anahtar kelime aramasıyla iyi karşılanır.

Kapanış

Pinecone, daha geniş bir şeye büyümüş yönetilen bir vektör veritabanıdır: tek bir index artık yoğun vektörleri, seyrek vektörleri ve tam metin alanlarını birlikte tutabilir; sıralama yöntemi sorgu başına seçilir. Bu birleşme en yararlı yakın değişikliktir, çünkü hibrit geri getirme bir mimari karar olmaktan çıkar ve bir parametre olur.

Tasarımı üç şey şekillendirir. Namespaces izolasyon ve performans mekanizmasıdır ve örtük oluşturulur — yanlış yazılmış bir namespace hata yerine boş sonuç döner. Embedding seçimi göründüğünden daha yapışkandır, çünkü model değiştirmek tüm derlemi yeniden embed etmek demektir. Okumalar yazmaların birkaç katına mal olur; bu da okuma ağırlıklı bir sistemde sorgu önbelleğini doğrudan bir maliyet kolu yapar.

Fiyatlandırma şeffaftır ve ücretsiz katman asıl soruyu yanıtlamaya yetecek kadar büyüktür: geri getirme kalitesi kullanım durumunuz için yeterince iyi mi. Bu soru veritabanı hakkında değildir — parçalama, embedding seçimi ve sorgu formülasyonu ona hükmeder — ve herhangi bir altyapı var olmadan yerelde yanıtlanabilir.

Dürüst kapanış noktası budur. Yönetilen bir vektör veritabanı ölçekte, çok kiracılıkta veya dağıtık bir index işletmek istemediğinizde yerini hak eder. Bunun altında bellek içi bir dizi veya zaten çalıştırdığınız Postgres üzerindeki bir eklenti işi bedavaya yapar; ikisinden birine kaydolmadan önce hangi durumda olduğunuzu saptamaya değer.