TL;DR
Semantic layer adalah lapisan definisi yang nyimpen arti resmi tiap metrik bisnis, misalnya omzet, pelanggan aktif, dan margin, dalam bentuk yang bisa dibaca mesin. Tanpa lapisan ini, AI harus nebak rumus dari nama kolom, dan tebakannya sering meleset. Dengan lapisan ini, tiap pertanyaan diterjemahkan ke rumus yang sama, jadi angkanya konsisten siapa pun yang nanya.
Semantic layer adalah lapisan definisi yang nyimpen arti resmi tiap metrik bisnis dalam bentuk yang bisa dibaca mesin. Omzet, pelanggan aktif, margin kotor, semuanya punya satu rumus tertulis di situ.
Tanpa lapisan ini, AI yang kamu sambungin ke database cuma punya nama tabel dan nama kolom buat nebak. Tebakannya kadang bener, kadang meleset jauh.
Aku bakal jelasin isi semantic layer, cara nyusun versi pertamanya, dan kesalahan yang paling sering bikin proyek ini mandek.
Semantic layer adalah kumpulan definisi metrik dan dimensi yang duduk di antara database dan alat yang nanya ke database. Isinya rumus, filter wajib, dan hubungan antartabel. Waktu ada yang nanya "omzet bulan lalu berapa", lapisan ini yang nerjemahin pertanyaan itu jadi query dengan rumus yang udah disepakati.
Bedanya sama dokumentasi biasa: semantic layer dieksekusi, bukan cuma dibaca. Kalau kamu ubah definisi omzet di sana, semua dashboard dan semua jawaban AI ikut berubah.
Konsep ini udah lama dipakai di tool BI. Yang baru sekarang, lapisan yang sama dipakai buat ngasih konteks ke model bahasa. Dokumentasi dbt punya penjelasan teknis soal cara nyusun semantic model di docs.getdbt.com.
Karena AI nebak dari nama kolom. Kolom total di tabel transaksi bisa berarti total sebelum diskon, sesudah diskon, atau sudah termasuk ongkir. Model bahasa nggak bisa tau yang mana tanpa dikasih tau.
Masalahnya, hasil tebakan itu keliatan meyakinkan. Query-nya jalan, angkanya keluar rapi, format rupiahnya bener. Yang salah cuma isinya.
Ini beda sama error biasa. Query yang error langsung ketauan. Query yang jalan tapi salah rumus baru ketauan pas rapat, waktu angkanya beda sama laporan finance.
Kalau kamu belum familiar sama istilah metric dan KPI, dua halaman itu bisa jadi bacaan pendahulu.
Empat komponen ini yang paling sering muncul.
Contoh satu metrik dalam format YAML sederhana:
metric:
name: omzet_bersih
label: "Omzet Bersih"
deskripsi: "Nilai transaksi setelah diskon, belum termasuk ongkir"
rumus: "SUM(qty * harga_satuan - diskon)"
filter_wajib: "status_transaksi = 'selesai'"
dimensi: [tanggal, kategori_produk, kota, channel]
pemilik: "tim-finance"Baris filter_wajib itu yang paling sering dilupain. Tanpa dia, transaksi batal ikut kehitung dan angkanya menggelembung.
Lima langkah ini bisa kamu kerjain dalam satu hari kerja buat metrik inti.
Habis itu tes. Ajukan 10 pertanyaan dari daftar tadi, bandingin hasilnya sama laporan manual. Beda sedikit pun catat penyebabnya.
Di dataset latihan ngulikdata, tabel toko_berkah punya 18.412 baris transaksi periode Januari sampai Juni 2025. Waktu aku minta tiga orang beda ngitung omzet semester itu tanpa definisi tertulis, hasilnya begini.
| Versi | Rumus dipakai | Hasil |
|---|---|---|
| Tim penjualan | SUM(qty * harga_satuan), semua status | Rp 412.750.000 |
| Tim gudang | SUM(qty * harga_satuan), status selesai | Rp 389.220.000 |
| Tim finance | SUM(qty * harga_satuan - diskon), status selesai | Rp 356.480.000 |
Selisih versi tertinggi dan terendah: Rp 56.270.000, atau 15,8% dari angka finance. Nggak ada yang salah hitung. Mereka cuma jawab pertanyaan yang beda pakai kata yang sama.
Waktu aku kasih ketiga rumus itu ke asisten AI tanpa nandain mana yang resmi, dia milih versi pertama di 7 dari 10 percobaan. Alasannya masuk akal: itu rumus paling sederhana. Sayangnya itu juga yang paling jauh dari laporan resmi.
Setelah omzet_bersih ditulis sebagai satu-satunya metrik omzet di semantic layer, sepuluh percobaan berikutnya semuanya keluar di Rp 356.480.000.
Kalau kerjaan rekap kamu masih di spreadsheet, prinsipnya sama. Filter wajib itu setara argumen kriteria di SUMIFS, dan sering banget kelewat.
retur dibuang. Tulis alasannya di kolom deskripsi.Pakai satu tes sederhana: minta tiga orang beda nanya hal yang sama lewat AI, di hari yang beda. Kalau ketiganya dapat angka identik, lapisannya kerja.
Ukuran kedua: berapa lama waktu dari pertanyaan sampai angka. Sebelum ada definisi tertulis, permintaan data sederhana di tim aku biasanya nunggu balasan 1 sampai 2 hari kerja. Setelah 8 metrik inti masuk semantic layer, sebagian besar pertanyaan itu kejawab langsung tanpa perlu ngantre.
Kalau kamu lagi nyusun struktur metriknya dari atas ke bawah, tulisan soal metric tree nyambung banget sama topik ini. Buat nentuin metrik utama yang jadi acuan semua orang, cek juga north star metric untuk bisnis kecil.
Data warehouse nyimpen datanya. Semantic layer nyimpen artinya. Di warehouse kamu punya tabel transaksi dengan kolom qty dan harga. Di semantic layer kamu nulis bahwa omzet = SUM(qty * harga) untuk transaksi berstatus selesai. Warehouse jawab pertanyaan data ada di mana, semantic layer jawab pertanyaan angka ini dihitung gimana.
Nggak harus. Kamu bisa mulai dari satu file YAML atau bahkan satu spreadsheet berisi nama metrik, rumus, filter, dan pemiliknya. Tool kayak dbt Semantic Layer, Cube, atau LookML bantu waktu jumlah metriknya udah puluhan dan banyak orang ikut ngedit. Untuk 10 sampai 15 metrik awal, dokumen sederhana udah cukup.
Mulai dari 5 sampai 10 metrik yang paling sering ditanya di grup kerja kamu. Biasanya omzet, jumlah transaksi, pelanggan aktif, rata-rata nilai transaksi, dan margin kotor. Kalau kamu mulai dari 40 metrik sekaligus, separuhnya bakal basi sebelum sempat dipakai dan malah bikin AI makin bingung milih.
SQL yang secara sintaks benar belum tentu benar secara bisnis. AI bisa nulis query rapi tapi lupa buang transaksi batal, atau pakai kolom harga sebelum diskon. Hasilnya query jalan mulus dan angkanya keluar, cuma angkanya beda dari laporan resmi. Semantic layer nutup celah ini dengan ngunci filter dan rumusnya di depan.
Satu orang pemilik per metrik, biasanya orang yang paling sering pakai angka itu buat ambil keputusan. Finance pegang margin, tim penjualan pegang omzet dan target, tim produk pegang pelanggan aktif. Kalau pemiliknya nggak jelas, definisinya bakal diubah diam-diam dan kamu balik lagi ke masalah awal.
Tiga hal yang layak kamu bawa dari sini. Pertama, AI salah jawab bukan karena modelnya bodoh, tapi karena definisi metriknya nggak pernah ditulis. Kedua, semantic layer minimal cuma butuh satu file berisi rumus, filter wajib, dan pemilik. Ketiga, selisih 15,8% di contoh toko_berkah tadi bisa muncul di data kamu juga tanpa ada yang sadar.
Coba mulai minggu ini: tulis definisi resmi buat satu metrik yang paling sering diperdebatkan di kantor kamu, lengkap sama filter wajibnya. Satu metrik dulu.
Mau latihan nulis query yang ngunci filter dengan benar? Kulik latihan SQL di NgulikSQL dan biasakan tiap query punya klausa WHERE yang kamu bisa jelasin alasannya.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Tools AI bisa bikin chart dan ringkas data dalam hitungan detik. Jadi Python masih perlu dipelajari analis di 2026? Jawabannya iya, tapi alasannya udah beda dari 3 tahun lalu.
Aku tes forecasting AI di data penjualan 4 cabang toko grosir. Hasilnya lebih akurat dari tebakan manual, tapi meleset parah di satu titik yang mahal.
Cara ngolah ribuan review pelanggan jadi insight pakai AI, dari nyusun prompt yang konsisten, ngasih label, sampai ngubah hasilnya jadi rekomendasi yang bisa dieksekusi.