Amazon Bedrock Knowledge Bases: Anatomi ve Confluence Şeklindeki Soru

Konsol sihirbazının arkasındaki varsayılan#

Amazon Bedrock Knowledge Bases; bir konnektörü, bir chunker'ı, bir embedding modelini, bir vektör mağazasını ve bir retrieval API'sini tek bir yönetilen yüzeyde paketler. Confluence konnektörü aslında kılık değiştirmiş bir vektör mağazası kararıdır: AWS dokümantasyonu, Confluence Cloud'un "şu anda" yalnızca OpenSearch Serverless vektör mağazası ile kullanılabildiğini açıkça belirtir ve aynı kilitlenme SharePoint ve Salesforce için de geçerlidir. Bu tek kısıt mimariyi iki yola ayırır; konnektörü bağlamadan önce seçim yapmak sizi yeniden yazımdan kurtarır.

Bu yazı, altyapı seçen biri için bir değerlendirme okumasıdır; bir deployment denemesi raporu değil. Aşağıdaki sayıların hepsi güncel AWS sayfalarından alıntıdır, bağlantılar satır içinde verilmiştir. Mayıs 2026 itibarıyla doğru kabul edin ve karar gününde yeniden doğrulayın.

Bir Bedrock Knowledge Base aslında nedir#

Bir KB beş bileşenden oluşur. Ortadaki üçünü AWS işletir; uçtaki ikisini siz işletirsiniz.

1. Veri kaynağı konnektörü. Siz yapılandırırsınız, ingestion işini AWS yürütür. Seçenekler: S3, Confluence, SharePoint, Salesforce, Web Crawler, Custom (Aralık 2024 GA) ve Redshift, Glue ve S3 Tables için ayrı bir "structured" şekli. Konnektör indeksine bakın.
2. Chunking ve parsing. AWS yürütür. Stratejiler arasında sabit boyutlu, anlamsal ve hiyerarşik var; Bedrock Data Automation karmaşık PDF'lerin yerleşim duyarlı parsing'ini yapar.
3. Embedding modeli. AWS yürütür, token başına ödersiniz. Bölgedeki varsayılanlar Titan Text Embeddings V2 ve Cohere Embed v3'tür. Bedrock fiyatlandırma sayfası tek doğru kaynaktır.
4. Vektör mağazası. Veritabanını siz işletirsiniz; konsolda "benim için oluştur" seçeneği yalnızca OpenSearch Serverless'tır. Aurora PostgreSQL pgvector, OpenSearch Managed Cluster, Pinecone, MongoDB Atlas, Redis Enterprise Cloud, Neptune Analytics ve S3 Vectors desteklenen alternatiflerdir; prerequisites sayfası bunları listeler.
5. Retrieval API. AWS yürütür. Retrieve sıralanmış chunk'ları döner; RetrieveAndGenerate aynı çağrıya bir model invocation'ı zincirler. Sorgunun embedding'i, vektör mağazası okuması ve (isteğe bağlı olarak) generation modeli için ödeme yaparsınız.

Bir ingestion işi, kaynağı gezen, her dokümanı chunk'layan, her chunk'ı embed eden ve vektör mağazasına yazan bir konnektör çalışmasıdır. Bir Retrieve çağrısı sorguyu bir kez embed edip mağazaya vurur. Veri düzlemi bundan ibaret.

Veri kaynakları#

Konnektör listesi büyümeye devam ediyor; akılda tutmaya değer farklar auth yüzeyi, "yalnızca cloud mu" ve ne ingest edildiği.

Preview olarak işaretli konnektörler değişebilir. Confluence, SharePoint ve Salesforce için "yalnızca OpenSearch Serverless" kilidi Bedrock Confluence konnektör sayfasında belgelenir ve SharePoint ile Salesforce sayfalarında da aynı kısıt tekrarlanır.

İki noktanın altını çizmek lazım. Birincisi, Custom konnektörü ilk launch yüzeyindeki en yaygın "streaming data'mız var" boşluğunu kapattı; kaynağınız bir wiki değil de bir event stream ise doğru cevap budur. İkincisi, structured KB'ler vektör KB'lerle konsol sihirbazını paylaşır ama tablo bir mağaza üzerinde SQL üretirler. Veriniz satırlardan oluşuyorsa, bir embedding pipeline'ı onun etrafında zorlamayın.

Listede olmayan kaynaklar (GitHub repo, Hugging Face dataset)#

Sık gelen bir soru: "Bu GitHub repo'sunu veya bu Hugging Face dataset'ini knowledge base olarak indeksleyebilir miyim?" İkisinin de birinci sınıf Bedrock konnektörü yok. İki desen işliyor, üçüncüsü ise tuzak.

S3 üzerinden dolaylı yol. Repo'yu veya dataset'i bir S3 bucket'a periyodik olarak senkronlayın. GitHub için push'ta tetiklenen küçük bir Lambda veya günlük git clone --depth=1 ile versiyonlanmış bir prefix'e yazmak yeterli. Hugging Face için huggingface_hub.snapshot_download(repo_id="org/name", repo_type="dataset", local_dir=...) sonrası aws s3 sync kanonik şekildir. S3 veri kaynağını o bucket'a yönlendirin. S3 fiyatlandırma şekli korunur, Aurora pgvector seçilebilir kalır ve sync ritmi sizde kalır. Korpus okuma ağırlıklı ise doğru varsayılan budur.

Custom data source. Custom konnektörü kullanın ve dokümanları KnowledgeBaseDocuments ingestion API'si üzerinden push edin. Bu yol; chunking'i doküman bazında kontrol etmek istediğinizde, S3 konnektörünün taşımayacağı metadata'yı eklemeniz gerektiğinde (monorepo içinde dosya yolları, dataset kartı bölümleri, commit SHA'ları) veya kaynak batch sync'i israfa çevirecek kadar sık güncellendiğinde mantıklı. Karşılığında freshness ve silme semantiğini kodunuz sahiplenir.

Web Crawler tuzağı. Bedrock'un Web Crawler'ını github.com/org/repo veya huggingface.co/datasets/org/name üzerine yöneltmek cazip görünür. Yapmayın. İki platform da anonim crawler'ları sıkı rate-limit'ler; rendered HTML, chunking sonrası gürültüye dönüşen bir app shell ile sarılır; konnektör kaynak başına auth yapmadığı için private repo'lar ve gated dataset'ler tamamen erişim dışıdır.

Vektör mağazası seçimleri#

Aşağıdaki karar, ilk dalı veri kaynağı tipinden alır; çünkü o dalı AWS sizin için zaten seçmiş durumda. Confluence, SharePoint ve Salesforce konnektörleri bugün yalnızca OpenSearch Serverless ile kullanılabiliyor; S3, Custom ve Web Crawler korpusları desteklenen herhangi bir mağazada yer alabilir.

S3-only korpuslar için Aurora pgvector neden varsayılan. Bedrock KB için AWS Prescriptive Guidance, Aurora pgvector'ı birinci sınıf bir mağaza olarak listeler. Aurora Serverless v2 küçük bir minimum ACU'ya kadar ölçeklenebilir (güncel minimumlar için Aurora Serverless v2 dokümanına bakın), index taşınabilirdir ve ekibiniz büyük ihtimalle zaten Postgres işletiyor. Karşılığında index yaşam döngüsünü sahiplenirsiniz: ANALYZE, vacuum, HNSW veya IVFFlat üzerinde ANN parametre seçimi.

OpenSearch Serverless doğru tercih şu durumlarda: retrieval gecikmesi darboğaz ise, başka workload'lar için zaten bir OpenSearch koleksiyonu işletiyorsanız veya hybrid search ve k-NN ayarına ihtiyacınız varsa. Bedeli maliyet şeklinde gizli. OpenSearch Serverless kapasite sayfası minimum baseline ayak izine sahip bir OCU bazlı fiyatlandırma modeli belgeler. Sizing yaparken güncel OCU minimumlarını o sayfadan alıntılayın, çünkü taban değer aşağı yönlü hareket ediyor.

S3 Vectors en yeni seçenek. Bedrock KB ile S3 Vectors sayfası entegrasyonu ve maliyet tarafını anlatır, ama özellik bir sıcak yol için seçmeden önce gecikme paritesini ölçmeyi hak edecek kadar yeni.

Confluence konnektörüne yakından bakış#

Confluence iç RAG projelerinde en çok talep edilen korpus, o yüzden konnektör kendi başlığını hak ediyor.

Vektör mağazası kilidi. Bedrock Confluence konnektör sayfası birebir şunu söyler: "Amazon Bedrock supports connecting to Confluence Cloud instances. Currently, only Amazon OpenSearch Serverless vector store is available to use with this data source." Aynı kısıt SharePoint ve Salesforce konnektörleri için de belgelenmiştir. Bunlardan herhangi birini bir KB'ye bağladığınız anda OpenSearch Serverless baseline ayak izi faturanıza dahil olur. Confluence bağlıyken Aurora pgvector seçilebilir bir mağaza değildir.

Preview durumu. Aynı sayfada şu da geçer: "Confluence data source connector is in preview release and is subject to change." Yapılandırma alanlarını, sync semantiğini ve OpenSearch Serverless kilidinin kendisini hareketli hedefler olarak ele alın; production'a geçişten önce sayfayı yeniden okuyun.

Katı endpoint kısıtı. Konnektör sayfası desteklenen ürün olarak Confluence Cloud'u adlandırır. Confluence Server, Confluence Data Center ve özel bir alan adının arkasındaki herhangi bir self-hosted instance menüde değildir. Bir demoya söz vermeden önce korpus host adının .atlassian.net ile bittiğini doğrulayın.

Auth. İki mod: AWS Secrets Manager'da saklanan admin email ve API token ile Basic, veya kayıtlı bir Atlassian uygulaması ve refresh-token akışı ile OAuth 2.0. Atlassian, parola tabanlı basic auth'u deprecate etti (API token tabanlısını değil) ve REST tüketicilerini OAuth 2.0 yönüne yönlendiriyor; Bedrock konnektörünün BASIC modu API token kullanır ve hala desteklenir, ancak token rotasyon politikaları sıkılaştırıldı.

Neyin ingest edildiği. Sayfalar, blog yazıları, yorumlar ve ekler. Görüntü, tablo, grafik veya diyagram içeriği çıkarılmaz; konnektör sayfası açıkça "Confluence data sources don't support multimodal data, such as tables, charts, diagrams, or other images" der. Ek dosya işlemesi, KB'de yapılandırdığınız parsing stratejisine bağlı. Bedrock Data Automation karmaşık PDF'lerden metin çıkarır; varsayılan parser düz metin ve yaygın formatları işler. Çok büyük ekler parser tarafından sessizce kırpılabilir. Değerlendirmenizde işaretlemeye değer.

ACL davranışı. Tüm yüzeyin en yanlış okunan özelliği. Confluence space ve sayfa kısıtlamaları retrieval zamanında kullanıcı bazlı uygulanmaz. KB üzerinde bedrock:Retrieve yetkisi olan herhangi bir principal index'teki her chunk'ı görür. Kullanıcı bazlı filtrelemeye ihtiyacınız varsa seçenekleriniz şunlardır: ingestion'ı tek bir erişim katmanına uyan space'lerle sınırlandırın, korpusu katmana göre birden fazla KB'ye bölün veya Retrieve çağrılarında metadata filtreleme uygulayın. Bunların hiçbiri ACL passthrough ile aynı şey değildir.

Sync. Artımlı sync güncellenme timestamp'leri üzerinden çalışır. Confluence'taki silme işlemleri yayılır ama anlık değildir. Desteklenen sync modları için konnektör dokümanlarına bakın.

Bütçelenmesi gereken yaygın tuzaklar. Büyük bir space'in ilk tam sync'i sırasında Atlassian uygulama başına rate limit'leri, karışık space ingestion'ının token bütçenizi şişirmesi ve uzlaşmanız gereken kısmi sync durumlarına neden olan rate-limit darbeleri.

Taslak: bir Confluence veri kaynağı#

Önemli olan çağrının şekli. AWS CLI'nin create-data-source referansı ve Confluence configuration şeması tam alan setini belgeler.

aws bedrock-agent create-data-source \  --knowledge-base-id "$KB_ID" \  --name "confluence-internal-docs" \  --data-source-configuration '{    "type": "CONFLUENCE",    "confluenceConfiguration": {      "sourceConfiguration": {        "hostUrl": "https://example.atlassian.net",        "hostType": "SAAS",        "authType": "OAUTH2_CLIENT_CREDENTIALS",        "credentialsSecretArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:bedrock/confluence-oauth"      },      "crawlerConfiguration": {        "filterConfiguration": {          "type": "PATTERN",          "patternObjectFilter": {            "filters": [              {                "objectType": "Page",                "inclusionFilters": ["^/spaces/ENG/.*"]              }            ]          }        }      }    }  }'

Ingestion işi bittiğinde bir retrieval çağrısı:

aws bedrock-agent-runtime retrieve \  --knowledge-base-id "$KB_ID" \  --retrieval-query '{"text": "incident severity matrisimiz nedir"}' \  --retrieval-configuration '{    "vectorSearchConfiguration": {      "numberOfResults": 5,      "overrideSearchType": "HYBRID"    }  }'

Burada HYBRID search kullanılabiliyor çünkü Confluence OpenSearch Serverless'ı zorunlu kılıyor; pgvector destekli bir S3 KB'sinde varsayılan olan SEMANTIC'i kullanırsınız. Override'ların tam seti için retrieve CLI referansına bakın.

Her iki çağrı da JSON döner; hiçbiri başarı satırı basmaz. create-data-source dataSourceId'yi ve bir CREATING durumu döner, retrieve ise bir retrievalResults array'i döner. Script'lerinizi bu şekle göre planlayın.

Maliyet şekli#

Üç kalem, her biri ayrı fiyatlandırılır. Aşağıdaki tüm sayılar Mayıs 2026 itibarıyla Bedrock fiyatlandırma sayfasından ve OpenSearch Serverless fiyatlandırma sayfasından alıntıdır. Karar gününde yeniden doğrulayın.

Ingestion. Embedding modelinin token başına ücretinde embedding token'ları için ödeme yaparsınız. Titan Text Embeddings V2 Bedrock fiyatlandırma sayfasında listelenir; korpus token sayınızı listelenen ücretle çarpın. Parsing için Bedrock Data Automation'ı açarsanız, aynı sayfada belgelenmiş bir sayfa başına işleme ücreti de ödersiniz.

Sorgu. Her Retrieve çağrısı sorguyu embed eder (küçük bir token harcaması) ve vektör mağazasını okur. RetrieveAndGenerate kullanırsanız, ek olarak generation modeli invocation'ı için ödersiniz; bu genellikle sorgu başına en yüksek kalemdir.

Vektör mağazası baseline'ı. Ekipleri yakalayan kalem budur. OpenSearch Serverless OCU saati başına faturalanır ve trafikten bağımsız bir minimum baseline ayak izi vardır. Aurora Serverless v2 pgvector ile ACU saati başına faturalanır ve boştayken küçük bir tabana ölçeklenebilir. OpenSearch baseline'ı, ilk sorgu inmeden önce küçük korpus faturanızı ele geçirebilir.

Hipotetik 50.000 dokümanlı bir korpus ve günde 100 sorgu için işlenmiş matematik:

• Ingestion embedding'leri: doküman başına yaklaşık 3.000 token ile 50.000 doküman 150 milyon token eder. Titan V2'nin Bedrock fiyatlandırma sayfasından 1K başına ücretiyle çarpın. Sonuç tekrarlayan değil, tek seferlik bir harcama.
• Sorgu embedding'leri: günde 100 sorgu × 30 gün × ~200 token, aynı ücrette ayda 600.000 token. Önemsiz.
• Generation (RetrieveAndGenerate ise): ayda 3.000 sorgu × seçtiğiniz modelin 1K çıkış ücreti. Generation'ı açtığınızda genellikle en büyük kalem.
• Vektör mağazası baseline'ı: OpenSearch Serverless minimum OCU ayak izi × OCU saati ücreti × ayda 730 saat, buna karşılık Aurora Serverless v2 minimum ACU × ACU saati ücreti × 730. Bu kadar küçük korpuslarda Aurora tabanı belirgin biçimde daha düşük.

Bedrock KB fiyatlandırması hakkında tek bir şey hatırlayacaksanız, hobi ölçeği faturayı production ölçeği faturadan ayıranın vektör mağazası baseline'ı olduğunu hatırlayın. Embedding token'ları genellikle yuvarlama hatasında kalır.

Bedrock KB ne zaman kullanılmamalı#

Bedrock KB; korpusunuz yapılandırılmamışsa, kaynaklarınız S3 veya cloud SaaS konnektörlerinden biriyse ve retrieval'da kullanıcı bazlı ACL gerekmiyorsa uygundur. Yanlış araç olduğu durumlar:

• Confluence Server veya Data Center. Self-hosted Confluence desteklenmez. Hem Cloud hem Server'ı destekleyen Amazon Kendra'nın Confluence konnektörünü kullanın veya kendi ingestion'ınızı yazın. Kendra konnektör dokümantasyonu yüzeyi kapsar.
• Sorgu zamanında kullanıcı bazlı ACL. Retrieval sonuçlarınız her kullanıcının kaynak sistem izinlerine uymalıysa, ya Kendra'ya (birçok konnektöründe yerel ACL passthrough'u vardır) ya da sorgu zamanında kullanıcı izinlerini çözen elle yazılmış bir pipeline'a ihtiyacınız var.
• Hybrid graph artı vektör. Anlamlı biçimde graph şekilli bilgi Neptune Analytics'e veya vektör destekli özel bir graph veritabanına uygundur.
• Çok küçük korpuslar (~1.000 dokümanın altında). Korpusun tamamını bir model bağlamına sığdırmak veya tek süreçli bir FAISS index'i çalıştırmak genellikle daha basit ve ucuz.
• Çok büyük korpuslar (~10 milyon chunk'ın üzerinde). Özel bir vektör veritabanı, bir OpenSearch Managed Cluster veya özel bir pipeline size KB yönetilen yüzeyinin açığa çıkarmadığı tuning kollarını verir.

Kendi kurma seçeneği de geçerli bir tercih (S3 artı bir Lambda chunker artı pgvector veya OpenSearch artı küçük bir retrieval servisi). Yönetilen konnektör ve chunking yüzeyinden vazgeçersiniz; embedding modeli değişimleri, parsing stratejisi, sync semantiği ve maliyet takibi üzerinde tam kontrol kazanırsınız. Hızla evrilteceğiniz bir korpus için bu kontrol, yönetilen rahatlıktan daha değerli.

Yaygın tuzaklar#

• Confluence space izinlerini retrieval'da uygulanıyormuş gibi varsaymak. Uygulanmaz.
• Küçük bir POC için OpenSearch Serverless seçip baseline faturasıyla karşılaşmak.
• Structured KB'leri (text-to-SQL) vektör KB'lerle aynı mimari diyagramda karıştırmak. Bir konsol sihirbazını paylaşırlar, runtime'ı değil.
• Confluence konnektörünün self-hosted Confluence için çalıştığını varsaymak. Çalışmaz.
• Custom veri kaynaklarının yalnızca push olduğunu unutmak; tazeliği kodunuz sahiplenir.
• Retrieve yeterken RetrieveAndGenerate kullanmak. Her iki şekilde de fazladan bir model invocation'ı ödersiniz.

Kapanış#

Öneri üç sınıra oturuyor. Korpusunuz yalnızca S3 ise ve yaklaşık bir milyon dokümanın altındaysa, Bedrock KB'yi Aurora PostgreSQL pgvector üzerinde kullanın; taşınabilir bir index'iniz olur ve OpenSearch Serverless baseline ayak izinden kaçınırsınız. Korpusunuz Confluence, SharePoint veya Salesforce içermek zorundaysa, OpenSearch Serverless baseline'ını sabit bir giriş bedeli olarak bütçeleyin ve ACL ile multimodal ihtiyaçlarına göre Bedrock KB ile Kendra arasında seçim yapın. Her iki zarfın dışında (Confluence Server, retrieval'da kullanıcı bazlı ACL, graph şekilli veri, çok büyük korpuslar) kontrolünüzdeki bir vektör mağazasına karşı kendi pipeline'ınızı kurun.

Kaynaklar#

• Retrieve data and generate AI responses with Amazon Bedrock Knowledge Bases - Bir Bedrock Knowledge Base'in ne olduğu ve nasıl kurulduğuna dair kanonik AWS dokümantasyonu
• Connect a data source to your knowledge base - Konnektör başına yapılandırma içeren desteklenen konnektörlerin tam matrisi
• Connect to Confluence for your knowledge base - Confluence konnektörü için yalnızca Cloud kısıtı ve desteklenen auth modları
• Connect your knowledge base to a custom data source - Aralık 2024'te GA olan Custom konnektörü için dokümantasyon
• Prerequisites for using a vector store you created for a knowledge base - Desteklenen vektör mağazaları ve gerekli index ayarları
• Using S3 Vectors with Amazon Bedrock Knowledge Bases - En yeni vektör mağazası entegrasyonu; yayın gününde güncelliği doğrulayın
• Managing capacity limits for Amazon OpenSearch Serverless - Baseline maliyeti belirleyen OCU tabanları ve redundancy semantikleri
• Amazon Bedrock Pricing - Embedding ve generation modeli fiyatlandırması için tek doğru kaynak
• RAG fully managed with Amazon Bedrock (AWS Prescriptive Guidance) - Bedrock tabanlı RAG için resmi karar çerçeveleme dokümanı
• Amazon Bedrock Knowledge Bases now supports custom connectors and ingestion of streaming data - Custom konnektörü için GA duyurusu
• Amazon Bedrock Knowledge Bases now supports Amazon OpenSearch Managed Cluster for vector storage - Eklenen vektör mağazası seçeneği
• Dive deep into vector data stores using Amazon Bedrock Knowledge Bases - Desteklenen vektör mağazalarının AWS imzalı karşılaştırması
• Amazon Kendra Confluence connector documentation - Bedrock KB uymadığında yerli ACL alternatifi
• Atlassian deprecation notice for Basic auth with passwords on Confluence Cloud - Deprecation'ın kapsamı (parolalar, API token'lar değil) ve OAuth 2.0 geçiş yönlendirmesi