Fase 4 · RAG & Knowledge Bases

Memilih vector store

Kalau kamu memakai customer-managed knowledge base, kamu memilih dan menyiapkan sendiri vector store-nya. Pilihan ini menentukan biaya, latensi, dan kemampuan filter.

Sumber asli docs.aws.amazon.com Resmi Rangkuman ~6 menit baca

Intisari

Ada quick-create: Bedrock bisa membuatkan indeks vektor untukmu — pakai ini kalau tidak punya alasan kuat.
Vector store menyimpan tiga hal: vektor, teks potongan, dan metadata yang dikelola Bedrock.
Hanya OpenSearch (Serverless dan Managed) yang mendukung penyimpanan vektor biner.
Untuk Aurora, field metadata untuk filter harus dibuat sendiri sebelum ingest.
Pilihan model embedding dan dimensi vektor membatasi vector store yang bisa dipakai.

Yang disimpan di dalamnya

Vector store untuk knowledge base bukan sekadar tempat angka. Setiap entri memuat:

Field	Isi	Kenapa perlu
Vektor	Embedding dari potongan teks	Untuk pencarian kemiripan
Teks	Potongan aslinya	Yang benar-benar dikirim ke model
Metadata Bedrock	Berkas sumber, nomor halaman, dsb.	Untuk sitasi
Metadata milikmu	Tim, tanggal, tingkat kerahasiaan	Untuk filter saat retrieval

Pilihan yang ada

Vector store	Kekuatan	Pertimbangan
OpenSearch Serverless	Jalur paling umum; hybrid search; mendukung vektor biner	Ada biaya minimum kapasitas — bukan yang paling murah untuk data kecil
Aurora PostgreSQL (pgvector)	Data relasional dan vektor di satu tempat; SQL biasa	Field metadata untuk filter harus kamu buat sendiri
Neptune Analytics	Menggabungkan graf dan vektor — GraphRAG	Untuk kasus yang butuh hubungan antar entitas
S3 vector bucket	Paling murah untuk data besar yang jarang diakses	Chunking hierarkis tidak dianjurkan di sini
Managed KB	Tidak perlu memilih sama sekali	Kendali indeks terbatas

Jangan mulai dari perdebatan vector store. Untuk hampir semua kasus belajar dan banyak kasus produksi, Managed KB atau quick-create OpenSearch Serverless sudah tepat. Pindah ke pilihan lain setelah kamu punya angka nyata soal biaya, latensi, atau kebutuhan filter yang tidak terpenuhi.

Dimensi vektor

Model embedding menentukan panjang vektor, dan indeks harus dibuat dengan dimensi yang sama. Titan Text Embeddings V2 menghasilkan 1.024 dimensi secara default, dengan pilihan 512 dan 256.

Dimensi	Konsekuensi
Lebih besar (1.024)	Kualitas retrieval lebih baik, penyimpanan dan pencarian lebih mahal
Lebih kecil (256)	Lebih murah dan lebih cepat, kualitas sedikit menurun

Yang tidak bisa dilakukan: mengganti model embedding tanpa membangun ulang seluruh indeks. Vektor dari dua model berbeda tidak sebanding, jadi migrasi berarti ingest ulang semuanya. Pilih model embedding seperti memilih skema database.

Metadata dan filter

Metadata adalah yang membuat retrieval berhenti jadi "cari di seluruh dunia". Di Bedrock, kamu melampirkan metadata lewat berkas pendamping di S3:

// panduan-cuti.pdf.metadata.json
{
  "metadataAttributes": {
    "departemen": "hr",
    "tahun": 2026,
    "kerahasiaan": "internal"
  }
}

hasil = agen.retrieve(
    knowledgeBaseId=KB_ID,
    retrievalQuery={"text": "berapa hari cuti tahunan?"},
    retrievalConfiguration={"vectorSearchConfiguration": {
        "numberOfResults": 5,
        "filter": {
            "andAll": [
                {"equals":      {"key": "departemen", "value": "hr"}},
                {"greaterThan": {"key": "tahun", "value": 2024}},
            ]
        },
    }},
)

Filter ini juga cara paling sederhana menerapkan pemisahan antar tenant atau antar tingkat kerahasiaan: sisipkan filter dari identitas pengguna, bukan dari masukan pengguna. Untuk kontrol yang lebih ketat, Managed KB punya filter berbasis ACL per dokumen.

Latihan: tambahkan berkas .metadata.json untuk tiap dokumen di bucket-mu dengan atribut departemen. Ingest ulang, lalu buktikan bahwa retrieve dengan filter departemen = hr tidak pernah mengembalikan dokumen departemen lain — walaupun isinya lebih mirip secara semantik.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.