Bedrock Knowledge Bases
Knowledge Bases adalah RAG terkelola AWS. Baca ini setelah kamu membangun RAG sendiri, bukan sebelumnya.
Intisari
- Knowledge Base mengambil alih seluruh pipeline: ingest, chunking, embedding, penyimpanan, retrieval.
- Kamu memilih: sumber data (S3), model embedding, vector store, dan strategi chunking.
- Dua API:
Retrieve(ambil chunk saja) danRetrieveAndGenerate(langsung jadi jawaban). - Sitasi disediakan otomatis โ dengan lokasi sumbernya.
- Baca setelah capstone. Kalau belum pernah membangun RAG manual, ini hanya jadi tombol ajaib.
Peta ke capstone-mu
| Yang kamu bangun di Fase 7 | Padanan di Knowledge Bases |
|---|---|
| Baca folder PDF/Markdown | Data source (bucket S3) |
| Fungsi chunking-mu | Chunking strategy |
| Panggil API embedding | Embeddings model |
| ChromaDB | Vector store (OpenSearch / Aurora / Pinecone) |
| Cosine similarity + filter | Retrieve API |
| Susun prompt + panggil LLM | RetrieveAndGenerate API |
| Lacak sitasi sendiri | Citations otomatis |
Kolom kanan bukan sihir โ itu kolom kiri yang dijalankan AWS. Karena kamu sudah membangunnya sendiri, kamu tahu keputusan apa yang tersembunyi di balik tiap pilihan konfigurasi, dan tahu kapan default-nya tidak cocok untuk kasusmu. Itulah alasan urutan roadmap ini: bangun dulu, baru pakai yang terkelola.
Yang kamu konfigurasi
1. Data source
- Amazon S3 โ paling umum. PDF, TXT, MD, HTML, DOC, CSV, XLSX.
- Web crawler, Confluence, SharePoint, Salesforce
- Sinkronisasi bisa dijadwalkan atau dipicu manual
2. Chunking strategy
| Strategi | Cara kerja | Untuk |
|---|---|---|
| Fixed size | Jumlah token tetap + tumpang tindih | Default; teks yang seragam |
| Hierarchical | Chunk induk dan anak; cari di anak, kirim induknya | Dokumen panjang berstruktur |
| Semantic | Potong di batas makna, bukan panjang | Teks bebas |
| None | Satu file = satu chunk | Dokumen yang sudah pendek |
| Lambda kustom | Kodemu sendiri | Kebutuhan khusus |
Hierarchical chunking layak diperhatikan. Ia mencari di chunk kecil (presisi tinggi) lalu mengirim chunk induknya yang lebih besar ke LLM (konteks utuh). Ini menyelesaikan masalah yang sama dengan contextual retrieval, dengan pendekatan berbeda.
3. Model embedding
Titan Embeddings, Cohere Embed, atau lainnya. Perhatikan dimensi dan dukungan bahasanya.
4. Vector store
| Pilihan | Catatan |
|---|---|
| OpenSearch Serverless | Default; mendukung hybrid search |
| Aurora PostgreSQL (pgvector) | Kalau sudah pakai Postgres |
| Pinecone, MongoDB Atlas, Redis | Layanan pihak ketiga |
| Neptune Analytics | Untuk GraphRAG |
Dua API
Retrieve โ hanya mengambil chunk
import boto3
agent = boto3.client("bedrock-agent-runtime", region_name="us-east-1")
r = agent.retrieve(
knowledgeBaseId="KB123456",
retrievalQuery={"text": "bagaimana cara reset password?"},
retrievalConfiguration={
"vectorSearchConfiguration": {
"numberOfResults": 5,
"overrideSearchType": "HYBRID", # SEMANTIC | HYBRID
"filter": {"equals": {"key": "kategori", "value": "panduan"}},
}
},
)
for hasil in r["retrievalResults"]:
print(hasil["score"], hasil["content"]["text"][:100])
print(hasil["location"]["s3Location"]["uri"])
Retrieve adalah yang biasanya kamu pakai di aplikasi nyata. Ia memberi
chunk-nya, dan kamu tetap mengendalikan prompt, pemilihan model, format sitasi, dan logika
tool. Ini menggantikan lapisan retrieval saja โ bukan seluruh aplikasimu.
RetrieveAndGenerate โ langsung jadi jawaban
r = agent.retrieve_and_generate(
input={"text": "bagaimana cara reset password?"},
retrieveAndGenerateConfiguration={
"type": "KNOWLEDGE_BASE",
"knowledgeBaseConfiguration": {
"knowledgeBaseId": "KB123456",
"modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-opus-5",
"generationConfiguration": {
"promptTemplate": {"textPromptTemplate": TEMPLATE_KUSTOM},
},
},
},
)
print(r["output"]["text"])
for sitasi in r["citations"]:
for ref in sitasi["retrievedReferences"]:
print(ref["location"]["s3Location"]["uri"])
Retrieve vs RetrieveAndGenerate
Retrieve | RetrieveAndGenerate | |
|---|---|---|
| Kendali prompt | Penuh | Template terbatas |
| Pemilihan model | Kamu | Ditentukan di konfigurasi |
| Bisa gabung tool lain | Ya | Tidak |
| Streaming | Kamu yang urus | Ada versi stream-nya |
| Jumlah panggilan API | Dua (retrieve lalu generate) | Satu |
| Cocok untuk | Aplikasi produksi | Prototipe cepat |
Metadata dan filter
Sertakan file <nama>.metadata.json di samping tiap dokumen di S3:
{
"metadataAttributes": {
"kategori": "panduan",
"departemen": "IT",
"tahun": 2026,
"rahasia": false
}
}
"filter": {
"andAll": [
{"equals": {"key": "departemen", "value": "IT"}},
{"greaterThanOrEquals": {"key": "tahun", "value": 2025}},
{"equals": {"key": "rahasia", "value": False}},
]
}
Filter metadata adalah mekanisme keamanan datamu. Di aplikasi multi-tenant, filter
berdasarkan org_id adalah yang mencegah data satu pelanggan bocor ke pelanggan lain.
Terapkan filter itu di sisi server, bukan berdasarkan sesuatu yang dikirim klien.
Kapan pakai KB, kapan bangun sendiri
| Pakai Knowledge Bases | Bangun sendiri |
|---|---|
| Sudah di ekosistem AWS | Butuh strategi chunking khusus |
| Chunking standar sudah cukup | Perlu contextual retrieval / reranking kustom |
| Ingin cepat jalan | Butuh kendali penuh atas prompt |
| Tidak ingin mengelola infrastruktur | Multi-cloud atau on-premise |
| Butuh sinkronisasi terjadwal bawaan | Optimasi biaya yang agresif |
Jalan tengah yang sering dipakai: KB untuk retrieval, kode sendiri untuk generation.
Pakai Retrieve, lalu susun prompt dan panggil model dengan logika aplikasimu sendiri.
Untuk sertifikasi
Yang perlu kamu bisa jelaskan:
- Alur data source โ chunking โ embedding โ vector store
- Kapan tiap strategi chunking dipilih
- Perbedaan
RetrievedanRetrieveAndGenerate - Cara filter metadata dikonfigurasi dan dipakai
- Perbandingan pilihan vector store
- Bagaimana sitasi dihasilkan dan apa isinya
- Peran IAM untuk akses KB dan sumber datanya
Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.