Belajar Data Architect - Vector & Unstructured Data

#Pendahuluan

Setelah di episode 21 kita merancang fondasi AI-ready, sekarang kita masuk ke salah satu komponen paling baru dalam arsitektur data: pengelolaan data tidak terstruktur. Selama puluhan tahun, data yang bisa dikelola dengan baik hanyalah yang berbentuk tabel. Padahal sebagian besar data organisasi — dokumen, email, chat, gambar, audio, kode — hidup di luar tabel.

Mengapa episode ini penting? Karena di era LLM, data tidak terstruktur akhirnya bisa dicari secara semantik — bukan hanya keyword. Vector database dan embedding pipeline mengubah dokumen yang selama ini "menumpuk" menjadi aset yang bisa di-query. Arsitek yang menguasai ini memperluas nilai data organisasi secara fundamental.

#Kenapa Vector Database

Data tidak terstruktur tidak punya kolom yang bisa di-WHERE. Solusinya: ubah menjadi embedding — vektor angka yang merepresentasikan makna — lalu cari berdasarkan kemiripan vektor.

"cara reset password" → [0.12, -0.04, 0.87, ...]  (512/1536 dimensi)
"password lupa gimana" → [0.11, -0.03, 0.85, ...]  (dekat → relevan)
"harga produk terbaru" → [0.71, 0.22, -0.51, ...]  (jauh → tidak relevan)

Vector database menyimpan embedding ini dan menjawab pertanyaan "mana dokumen yang paling mirip dengan query ini?" dalam milidetik. Contoh: Milvus, Qdrant, Weaviate, pgvector (PostgreSQL), OpenSearch.

#Embedding Pipeline

Embedding tidak terjadi dengan sendirinya — ia pipeline data yang harus dirancang, dimonitor, dan di-update:

1. INGEST:  dokumen dikumpulkan (source: wiki, file share, drive, email)
2. CHUNK:   dokumen dipecah menjadi potongan (chunk) yang bermakna
3. EMBED:   tiap chunk diubah jadi vektor via embedding model
4. INDEX:   vektor + metadata disimpan di vector DB
5. UPDATE:  dokumen berubah → chunk di-re-embed → versi dipertahankan

#Chunking: Keputusan Arsitektural

Ukuran chunk sangat menentukan kualitas retrieval. Terlalu besar → makna campur aduk, retrieval tidak presisi. Terlalu kecil → konteks hilang. Strategi umum:

- fixed-size: potong per N token (sederhana, kadang memotong di tengah kalimat)
- structural: potong per paragraf/section (lebih bermakna, pakai struktur dokumen)
- semantic:  potong saat makna bergeser (paling bagus, paling mahal)
- parent-child: simpan chunk kecil untuk retrieval + parent untuk konteks

Keputusan chunking harus diuji dengan metrik retrieval (recall@k), bukan asal pilih — dan didokumentasikan sebagai keputusan arsitektur.

#Indexing dan Metadata

Chunk disimpan bersama metadata: sumber dokumen, versi, timestamp, access scope, owner. Metadata inilah yang memungkinkan filter akses dan governance pada retrieval:

{
  "id": "doc-42-chunk-7",
  "vector": [0.12, -0.04, ...],
  "text": "Langkah reset password: ...",
  "metadata": {
    "source": "wiki/sop-it",
    "version": 3,
    "access_scope": "internal",
    "owner": "tim-it",
    "updated_at": "2026-08-01"
  }
}

#Mengelola Data Tidak Terstruktur secara Umum

Vector DB hanyalah bagian dari pengelolaan data tidak terstruktur yang lebih luas. Arsitek juga harus mengatur:

• Raw storage: dokumen asli disimpan di object storage dengan metadata (seperti bronze layer di episode 6).
• Catalog & lineage: data tidak terstruktur juga masuk catalog (episode 8) — sumber, versi, dan siapa yang meng-update.
• Lifecycle: dokumen usang diarsipkan; versi lama dipertahankan sesuai aturan (episode 14).
• Quality: dokumen duplikat, chunk kosong, dan embedding yang gagal dimonitor (episode 9).

#Knowledge Graph

Knowledge graph menghubungkan entitas dalam data tidak terstruktur: "dokumen A menyebut produk B yang dimiliki tim C dan dipakai sistem D". Berbeda dari vector (kesamaan makna), graph menyimpan hubungan eksplisit antar entitas.

[Alice] --bekerja di--> [Tim Data]
[Alice] --menulis--> [Dokumen SOP-42]
[Dokumen SOP-42] --membahas--> [Sistem Billing]
[Tim Data] --memiliki--> [Sistem Billing]

Kegunaan praktis: menjawab pertanyaan "sistem apa yang terdampak jika SOP-42 diubah?" atau "siapa yang paling tahu tentang sistem billing?" — mirip lineage, tapi untuk data tidak terstruktur.

Pola umum: vector untuk retrieval, graph untuk relasi, keduanya saling melengkapi dalam arsitektur RAG lanjutan.

#Praktik: Membangun Vector Pipeline

#Step 1: Pilih Sumber dan Use Case

Mulai dari satu sumber (misal wiki internal) dan satu kebutuhan (chat tanya jawab SOP).

#Step 2: Siapkan Pipeline

- ingest: scheduler (Airflow) menarik dokumen yang berubah
- chunk + embed: proses Python (langchain/llama-index atau langsung SDK)
- store: pgvector (mulai dari sini, upgrade ke Qdrant/Milvus jika besar)
- retrieval: API dengan filter metadata (access_scope, owner)

#Step 3: Tetapkan SLO

- freshness: perubahan dokumen ter-reflect ≤ 1 jam
- completeness: ≥ 99% dokumen berhasil di-embed
- retrieval quality: recall@5 ≥ 0.8 pada golden set pertanyaan
- staleness: versi lama tidak lagi muncul di retrieval

#Step 4: Pasang Monitoring

Pantau pipeline seperti pipeline lain: kegagalan embedding, dokumen yang tidak pernah berhasil, dan retrieval quality yang menurun (episode 9).

#Penutup

Inti yang harus dibawa pulang:

• Vector DB memungkinkan pencarian semantik atas data tidak terstruktur.
• Embedding pipeline = ingest → chunk → embed → index → update; chunking menentukan kualitas.
• Simpan raw dokumen agar bisa re-embed saat model berganti.
• Metadata & access scope pada chunk adalah kunci governance untuk retrieval.
• Knowledge graph menambahkan lapisan relasi antar entitas; melengkapi vector.
• Vector pipeline butuh SLO dan monitoring seperti pipeline lain.

Di episode 23 selanjutnya kita akan membahas Multi-Cloud & Hybrid Data — portabilitas data, federation, dan strategi vendor di dunia yang tidak hanya satu cloud. Sampai jumpa di episode 23!