Cara Memisahkan Data, Instruksi, dan Metadata dalam Pipeline RAG

RAG sering digambar terlalu rapi di slide: user bertanya, retriever mencari dokumen, model menjawab.

Di sistem produksi, isinya jauh lebih messy.

Ada system policy, developer instruction, query user, hasil vector search, metadata dokumen, tool response, citation, permission, history percakapan, dan mungkin memory. Semuanya akhirnya bertemu di satu proses inference.

Kalau seluruh elemen itu dimasukkan sebagai string panjang tanpa boundary, kita membuat masalah sendiri. Model dipaksa menebak mana perintah, mana fakta, dan mana informasi tentang fakta.

Karena itu, salah satu prinsip desain RAG yang makin penting adalah separation of concerns: pisahkan data, instruksi, dan metadata sejak ingestion sampai generation.

Tiga kategori yang sering tercampur

Instruksi menjelaskan apa yang harus dilakukan sistem.

Contohnya: jawab hanya berdasarkan sumber yang tersedia, jangan menampilkan data yang user tidak berhak lihat, atau minta konfirmasi sebelum melakukan aksi sensitif.

Data adalah materi yang dipakai untuk menjawab.

Contohnya: isi kebijakan refund, spesifikasi produk, kontrak, halaman web, tiket support, atau catatan CRM.

Metadata menjelaskan data.

Contohnya: source URL, document ID, author, timestamp, access level, content type, tenant, version, language, trust class, atau checksum.

Masalah muncul ketika metadata disisipkan ke data tanpa struktur, atau ketika data eksternal diberi posisi yang membuatnya tampak seperti instruction.

Dalam konteks prompt injection, pencampuran ini berbahaya karena kalimat dari dokumen dapat mencoba berperilaku seperti command.

Mulai dari ingestion, bukan dari prompt

Separation yang baik dimulai sebelum embedding dibuat.

Saat dokumen masuk, pipeline sebaiknya mempertahankan identitas dan provenance. Jangan hanya mengambil body text lalu melupakan semuanya.

Minimal, organisasi perlu tahu:

dokumen berasal dari mana,

siapa yang memasukkannya,

kapan diambil,

versi apa,

siapa yang boleh mengakses,

apakah sumber internal atau eksternal,

dan apakah kontennya user-generated.

Untuk use case sensitif, bisa ditambah approval state, classification, retention rule, atau trust tier.

Data tersebut tidak harus semuanya dikirim ke model. Sebagian dapat tetap berada di application layer untuk filtering dan authorization.

Ini penting: metadata bukan sekadar dekorasi citation. Metadata bisa menjadi control plane.

Chunking jangan membuang boundary

Chunking sering dilakukan semata-mata untuk optimasi token dan retrieval. Padahal chunk juga perlu membawa hubungan dengan dokumen induk.

Kalau satu paragraf policy dipotong tanpa title, section, date, dan version, model mungkin kehilangan konteks penting.

Lebih buruk lagi, kalau potongan user comment dan policy resmi masuk collection yang sama tanpa label, retriever dapat memilih keduanya berdasarkan similarity semata.

Jadi setiap chunk idealnya punya structured envelope.

Secara konseptual:

Content: teks yang akan digunakan model sebagai data.

Source: identitas dokumen.

Authority: kelas kewenangan sumber.

Freshness: kapan terakhir valid.

Access: siapa yang boleh melihat.

Trust: internal approved, internal unreviewed, external, atau user-generated.

Relation: bagian dari dokumen apa.

Tidak ada format universal yang wajib dipakai. Yang penting boundary tersebut benar-benar ada dan konsisten.

Retrieval harus memfilter sebelum ranking

Pipeline yang lemah sering melakukan vector search dulu, baru mengecek permission setelah hasil muncul.

Untuk beberapa arsitektur, itu bisa menciptakan risiko kebocoran melalui ranking, logging, cache, atau bug aplikasi.

Lebih sehat jika access control dan tenant boundary menjadi bagian dari retrieval query atau diterapkan sedekat mungkin dengan storage.

Lalu ranking mempertimbangkan bukan hanya semantic relevance, tetapi juga authority dan freshness ketika use case membutuhkan.

Contoh: user bertanya “Berapa batas refund?”

Retriever menemukan:

policy resmi v4, update minggu lalu,

FAQ lama tahun lalu,

komentar agent support,

dan dokumen vendor eksternal.

Similarity tertinggi belum tentu sumber terbaik.

Aplikasi dapat memprioritaskan policy resmi sebagai authoritative source, sementara sumber lain menjadi supporting context atau bahkan dikeluarkan.

Ini contoh metadata mengendalikan retrieval sebelum model mulai reasoning.

Context construction perlu eksplisit

Setelah retrieval selesai, jangan hanya melakukan concatenation seperti:

SYSTEM + USER + DOC1 + DOC2 + DOC3.

Buat struktur logis.

Policy layer berisi instruksi aplikasi yang berasal dari sumber tepercaya.

User layer berisi intent user.

Evidence layer berisi retrieved content dan secara eksplisit dilabel sebagai data dari sumber tertentu.

Metadata layer dapat ditempatkan dalam format terstruktur yang mudah diparsing, atau sebagian ditahan di aplikasi untuk policy decision.

Tool layer dipisahkan lagi, dengan schema yang menentukan capability yang benar-benar tersedia.

Model tetap bisa menerima semuanya dalam satu context window, tetapi semantic role-nya jangan kabur.

OpenAI dan Microsoft sama-sama menekankan pentingnya instruction hierarchy serta perlakuan terhadap external/retrieved content sebagai untrusted. Prinsip ini sejalan dengan desain context yang membedakan policy dari evidence.

Jangan masukkan secret ke prompt hanya karena convenient

Kesalahan klasik lain adalah menyisipkan token, API key, internal routing rule, atau data sensitif ke prompt karena model dianggap perlu “tahu semuanya”.

Kalau data tersebut tidak perlu untuk reasoning, jangan masukkan.

Gunakan tool abstraction. Model cukup tahu fungsi yang boleh dipanggil dan parameter yang relevan. Credential tetap berada di backend.

Prinsip yang sama berlaku untuk metadata internal. Tidak semua metadata perlu terlihat model.

Contoh: internal risk score mungkin cukup dipakai policy engine untuk menolak suatu sumber. Model hanya perlu tahu bahwa sumber tersebut tidak tersedia.

Semakin sedikit sensitive context yang masuk ke model, semakin kecil blast radius jika prompt injection berhasil memengaruhi output.

Pisahkan retrieval decision dari action authorization

RAG awalnya banyak dipakai untuk Q&A. Sekarang RAG sering menjadi input agent yang bisa melakukan tindakan.

Di sini boundary baru diperlukan.

Retrieved data boleh membantu model menyimpulkan bahwa “vendor meminta dokumen KYC”. Tetapi data tersebut tidak boleh otomatis mengotorisasi agent untuk mengirim KYC.

Action authorization perlu policy terpisah.

Model mengusulkan: send_document(vendor, file).

Policy engine memeriksa: apakah user meminta pengiriman? Apakah vendor termasuk allowlist? Apakah file boleh keluar? Apakah perlu approval? Apakah domain cocok dengan vendor record?

Baru setelah itu tool call dijalankan.

Dengan pola ini, instruksi berbahaya dalam retrieved document menghadapi boundary tambahan.

Metadata untuk audit dan observability

Ketika model menghasilkan jawaban, pertahankan jejak sumber.

Tim perlu bisa menjawab:

Dokumen mana yang ter-retrieve?

Chunk mana yang benar-benar masuk ke context?

Apa skor relevance-nya?

Apa trust class-nya?

Tool apa yang dipanggil sesudahnya?

Apakah ada policy block?

Apakah user memberi confirmation?

Tanpa observability seperti ini, debugging prompt injection atau poisoning menjadi sulit karena tim hanya melihat output akhir.

Untuk high-risk use case, provenance chain dari source sampai action sangat bernilai.

Contoh arsitektur sederhana

Bayangkan customer support assistant.

Sumber pertama adalah policy resmi perusahaan. Trust tinggi, read-only, versioned.

Sumber kedua adalah FAQ internal. Trust menengah, perlu review berkala.

Sumber ketiga adalah tiket lama. Banyak user-generated text, jadi trust rendah walaupun sering berguna untuk contoh kasus.

Retriever mencari seluruh sumber yang user berhak akses, tetapi policy resmi mendapat authority boost untuk pertanyaan aturan.

Context builder memberi label setiap chunk sebagai evidence, bukan instruction.

Model menyusun jawaban.

Jika model ingin melakukan refund, tool call masuk policy gateway. Gateway memeriksa nilai transaksi, status order, role user, dan limit. Refund tertentu meminta approval manusia.

Notice bahwa RAG menyediakan fakta. RAG tidak menentukan permission.

Itulah separation yang sehat.

Bagaimana tim non-engineering ikut berperan

Content team perlu menjaga status dokumen: approved, outdated, draft, atau deprecated.

Security team menentukan trust boundary dan monitoring.

Product team menentukan kapan AI boleh berubah dari “menjawab” menjadi “bertindak”.

Engineering memastikan metadata tidak hilang sepanjang pipeline.

Legal atau compliance mungkin menentukan kategori data yang tidak boleh keluar dari tenant tertentu.

Tanpa koordinasi ini, pipeline teknis yang rapi tetap dapat memakai sumber yang governance-nya kacau.

Jangan jadikan vector database tempat sampah

Karena ingestion mudah, organisasi tergoda memasukkan semua dokumen. “Nanti AI yang cari sendiri.”

Itu strategi yang buruk.

Semakin besar collection, semakin besar pula kebutuhan classification, provenance, de-duplication, freshness control, dan permission enforcement.

RAG yang bagus bukan yang paling banyak dokumennya. RAG yang bagus adalah yang mampu menemukan evidence relevan sambil mempertahankan boundary trust.

Pada akhirnya, pemisahan data, instruksi, dan metadata bukan sekadar persoalan prompt formatting. Ia adalah desain arsitektur.

Instruksi menentukan tujuan dan batas.

Data memberi evidence.

Metadata memberi konteks tentang evidence.

Policy menentukan apakah tindakan diizinkan.

Kalau empat hal itu tetap terpisah, sistem lebih mudah diaudit, lebih mudah diamankan, dan lebih mudah dikembangkan.

Kalau semuanya dilebur menjadi satu blok teks, kita sedang meminta model menyelesaikan problem keamanan yang seharusnya diselesaikan oleh arsitektur.

Pisahkan juga jalur untuk fakta dan jalur untuk kontrol

Arsitektur yang matang biasanya mempunyai satu perbedaan penting: fakta boleh datang dari banyak sumber, tetapi kontrol tidak.

Harga, spesifikasi, status order, atau isi dokumen dapat berasal dari retrieval. Sebaliknya permission, authorization rule, rate limit, allowed destination, dan approval requirement sebaiknya datang dari control plane yang tidak dapat ditulis ulang oleh dokumen yang sedang dibaca model.

Ini terlihat obvious ketika dijelaskan, tetapi implementasi sering melanggar prinsip tersebut secara tidak sengaja. Misalnya tool mengembalikan field `next_action` yang dibuat oleh user eksternal, lalu agent memperlakukannya sebagai perintah. Atau knowledge article berisi kalimat operasional lama yang sekarang bertentangan dengan policy backend, tetapi model tetap mengeksekusinya karena article lebih mudah dibaca daripada rule engine.

Solusinya bukan melarang model melihat informasi operasional. Solusinya memastikan source of truth untuk kontrol tetap berada di sistem yang tepat.

Untuk aplikasi agentic, pola yang sehat adalah: retrieval memberi evidence, model mengusulkan keputusan, policy engine memvalidasi, lalu tool mengeksekusi capability yang sudah dibatasi.

Kalau sebuah keputusan tidak lolos policy, model tidak bisa “berdebat” sampai mendapat izin. Itu boundary deterministik.

Dengan pola ini, metadata juga mendapat tempat yang lebih jelas. Metadata yang membantu reasoning dapat diberikan ke model. Metadata yang sensitif atau khusus authorization dapat dipakai aplikasi tanpa perlu diekspos ke context. Kita tidak perlu memilih antara semuanya visible atau semuanya hidden.

Separation akhirnya membuat sistem lebih modular. Retriever dapat diganti tanpa mengubah policy. Model dapat di-upgrade tanpa kehilangan permission boundary. Knowledge base dapat bertambah tanpa memberi dokumen baru hak untuk menciptakan capability baru. Itu bukan hanya lebih aman, tetapi juga lebih mudah dioperasikan.