Metadata Filtering: Pengaman Wajib RAG Brand Indonesia di 2026

TL;DR: Metadata filtering adalah fondasi keamanan dan akurasi sistem RAG di lingkungan bisnis. Dengan menambahkan atribut seperti tenant, kategori, tanggal validitas, dan bahasa pada setiap chunk, brand Indonesia dapat mencegah kebocoran konten antar pelanggan, memastikan jawaban memakai dokumen terbaru, dan memangkas biaya inferensi. Skema metadata sebaiknya dirancang sebelum chunk pertama di-embed.

Saat membantu klien Atmo (LMS) menyiapkan asisten AI internal, kami menemukan kasus klasik: chatbot kadang menjawab pertanyaan kurikulum 2026 dengan dokumen kurikulum 2023 yang masih ada di vector store. Dokumen lama secara semantik mirip, tetapi praktis menyesatkan. Solusinya bukan ganti model atau perbaiki prompt, melainkan menambah satu field metadata valid_from dan filter di setiap kueri.

Pengalaman ini bukan kasus tunggal. Banyak tim yang mempercepat peluncuran RAG dengan menyimpan seluruh corpus tanpa atribut, lalu kebingungan saat akurasi turun di produksi. Metadata filtering menutup celah ini secara struktural.

Apa Risiko Sistem RAG Tanpa Filter

Tiga kelas masalah yang sering muncul di brand growth-stage:

1. Bocor antar pelanggan: Sistem multi-tenant tanpa filter tenant_id bisa mencampur dokumen pelanggan A dengan B. Implikasinya bukan hanya akurasi, tetapi kepatuhan PP PSE dan UU PDP.
2. Jawaban kadaluarsa: Tanpa filter valid_from atau published_at, dokumen lama yang secara vector similarity mirip akan ikut muncul.
3. Konteks bahasa salah: Chunk berbahasa Inggris muncul di percakapan Bahasa Indonesia karena tidak ada filter language.

Dalam praktik, ketiga masalah ini sering muncul bersamaan dan baru terdeteksi saat pelanggan komplain. Filter metadata mencegah keseluruhan kelas error ini, bukan hanya kasus per kasus.

Skema Metadata Minimum yang Saya Pakai

Skema ini bisa diperluas, tetapi enam field ini sudah menutup mayoritas kasus produksi yang saya temui di klien Indonesia. Praktik standar di industri, misal pedoman dari Pinecone dan dokumentasi pgvector, menyarankan field-field serupa sejak awal.

Pre-filter, Post-filter, atau Hybrid

Pemilihan strategi filter mempengaruhi performa dan recall.

Pre-filter menyaring dokumen sebelum perhitungan kemiripan. Cocok untuk filter selektif tinggi (misal tenant_id) yang langsung memangkas corpus. Risiko: kalau hasil filter sangat sedikit, indeks vektor mungkin tidak menemukan kandidat baik.

Post-filter menjalankan kemiripan dulu, baru menyaring top-k. Cocok untuk filter yang sebagian kecil corpus saja yang lolos. Risiko: hasil top-k bisa kosong setelah filter, perlu fallback ke top-k lebih besar.

Hybrid mengombinasikan keduanya, misal pre-filter untuk tenant_id dan post-filter untuk valid_to. Saya gunakan pola ini di hampir semua sistem produksi karena memberikan keseimbangan antara biaya, recall, dan keamanan.

Studi Kasus Singkat: Vetmo Knowledge Base

Saat membangun knowledge base internal Vetmo (klien layanan kesehatan hewan), kami memisahkan dokumen klinis dari dokumen marketing dengan field category (klinis vs marketing) dan audience (internal_dokter vs pemilik_hewan). Sebelum filter ini diterapkan, dokter sering kebingungan saat asisten AI menjawab dengan tone marketing. Setelah filter audience aktif, akurasi tone naik signifikan dan tim dokter mulai memakai sistem secara rutin. Pelajarannya: filter metadata bukan hanya soal data benar, tetapi juga soal jawaban yang tepat untuk audiens yang tepat.

Bagaimana Mengevaluasi Setelah Filter Aktif

Kombinasikan filter dengan praktik LLM-as-judge atau eval set manual mingguan. Buat 30-50 pasangan kueri-jawaban gold dari pengguna nyata, lalu monitor metrik:

• Recall@5 setelah filter, apakah jawaban benar masih masuk top-5.
• Hit rate filter, persentase kueri yang masih mendapat hasil.
• Latensi P95, untuk memastikan filter tidak menambah delay tidak proporsional.

Pertahankan dashboard sederhana yang dipantau mingguan. Per Mei 2026, banyak vendor vector DB sudah menyediakan native observability untuk metrik ini.

Pertanyaan Umum

Apakah metadata filtering menggantikan reranking?

Tidak. Filter bekerja dengan aturan boolean, reranking memberi skor relevansi pada kandidat yang lolos. Sistem produksi yang baik biasanya memakai keduanya.

Bagaimana cara menambah field metadata pada chunk yang sudah ada?

Re-ingest atau lakukan update mass per dokumen. Kebanyakan vector DB modern mendukung update metadata tanpa re-embed, jadi biaya operasional relatif rendah.

Apakah field metadata membuat indeks lebih lambat?

Hanya jika tidak diberi indeks sekunder. Pastikan field yang sering difilter (terutama tenant_id) di-indeks pada level metadata vektor.

Bagaimana dengan filter dinamis berdasarkan peran pengguna?

Pakai pola attribute-based access control. Saat kueri, sistem auth mengirim daftar peran, lalu filter audience IN (peran) diterapkan otomatis.

Berapa banyak field metadata yang ideal?

Mulai dari 5-7 field inti. Tambahkan hanya jika ada kasus penggunaan terbukti. Terlalu banyak field menambah kompleksitas tanpa nilai jelas.

Penutup: Filter Sebelum Embed, Bukan Setelah Krisis

Banyak tim yang baru menambahkan metadata filtering setelah insiden produksi. Pendekatan yang lebih sehat adalah merancang skema metadata sebelum batch embedding pertama, lalu menyesuaikan saat pola pemakaian nyata muncul. Untuk brand Indonesia yang membangun chatbot internal, asisten layanan, atau search semantic publik, fondasi ini lebih penting daripada memilih model embedding tercanggih.