Semantic Layer: Cara Bikin AI Nggak Salah Jawab Pertanyaan Data
Blog/AI untuk Analis/Semantic Layer: Cara Bikin AI Nggak Salah Jawab Pertanyaan Data

Semantic Layer: Cara Bikin AI Nggak Salah Jawab Pertanyaan Data

BimaBima
·6 November 2025·8 menit baca

Penulis

Bima

Bima

Founder & Data Professional

Bagikan

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.

Apa itu semantic layer?

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.

Kenapa AI sering salah jawab tanpa semantic layer?

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.

Apa aja isi semantic layer?

Empat komponen ini yang paling sering muncul.

  1. Entity: objek utama bisnis kamu. Pelanggan, produk, transaksi, toko. Tiap entity punya kunci unik.
  2. Dimension: sudut pandang buat motong angka. Tanggal, kategori produk, kota, channel penjualan.
  3. Measure: angka mentah yang diagregasi. Jumlah qty, jumlah nilai transaksi, hitungan baris.
  4. Metric: measure yang udah dikasih rumus dan filter resmi. Di sinilah aturan bisnisnya dikunci.

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.

Gimana cara nyusun semantic layer pertama?

Lima langkah ini bisa kamu kerjain dalam satu hari kerja buat metrik inti.

  1. Kumpulin pertanyaan nyata. Buka grup WhatsApp kerja atau riwayat permintaan data tiga bulan terakhir. Catat 30 pertanyaan yang paling sering muncul.
  2. Tarik nama metriknya. Dari 30 pertanyaan itu biasanya cuma keluar 6 sampai 10 metrik unik. Sisanya cuma beda filter.
  3. Tulis rumus resmi per metrik. Duduk bareng orang yang pakai angka itu. Tanya satu hal: transaksi mana yang harus dibuang. Jawabannya jadi filter wajib.
  4. Simpan dalam satu file. YAML, JSON, atau tabel spreadsheet. Yang penting satu tempat, punya kolom rumus, filter, dan pemilik.
  5. Sambungin ke alat tanya-jawabnya. Kalau kamu pakai asisten AI, taruh isi file ini di konteks sistem sebelum dia nulis query. Kalau pakai tool semantic layer, import file-nya langsung.

Habis itu tes. Ajukan 10 pertanyaan dari daftar tadi, bandingin hasilnya sama laporan manual. Beda sedikit pun catat penyebabnya.

Contoh kasus: tiga versi omzet di toko_berkah

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.

VersiRumus dipakaiHasil
Tim penjualanSUM(qty * harga_satuan), semua statusRp 412.750.000
Tim gudangSUM(qty * harga_satuan), status selesaiRp 389.220.000
Tim financeSUM(qty * harga_satuan - diskon), status selesaiRp 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.

Kesalahan umum waktu bikin semantic layer

  • Nulis definisi tanpa pemilik. Metrik tanpa nama pemilik bakal diubah diam-diam. Satu nama per metrik, bukan satu tim yang kabur.
  • Bikin 40 metrik sekaligus. Separuhnya nggak pernah kepake dan malah bikin AI susah milih. Mulai dari yang beneran ditanya tiap minggu.
  • Nggak nyimpen alasan filternya. Enam bulan lagi nggak ada yang inget kenapa status retur dibuang. Tulis alasannya di kolom deskripsi.
  • Nganggap ini proyek sekali jadi. Definisi bisnis berubah. Jadwalkan tinjauan tiap kuartal, cukup 30 menit.
  • Lupa ngecek kualitas data sumbernya. Rumus paling rapi pun tetap kasih angka aneh kalau tabelnya punya duplikat. Cek dulu data quality sebelum nulis definisi.

Gimana ngukur semantic layer kamu udah jalan?

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.

FAQ

Apa bedanya semantic layer dan data warehouse?

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.

Apakah semantic layer harus pakai tool khusus?

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.

Berapa banyak metrik yang sebaiknya masuk di awal?

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.

Kenapa AI masih salah walau SQL-nya kelihatan benar?

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.

Siapa yang harus ngurus definisi metriknya?

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.

Penutup

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.

Coba Langsung

Mau praktek langsung? Mulai latihan SQL gratis

Latihan interaktif, langsung di browser.

Buka NgulikSQL →
Bagikan:
Bima
Ditulis oleh

Bima

Founder & Data Professional

Founder Ngulik Data. Passionate about making data analysis accessible for everyone.

Artikel terkait

Python vs Tools AI buat Analis: Masih Perlu Belajar Coding?
AI untuk Analis
12 Juli 2026•7 menit baca

Python vs Tools AI buat Analis: Masih Perlu Belajar Coding?

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.

BimaBima
Forecasting Penjualan dengan AI: Realistis atau Overhyped?
AI untuk Analis
9 Juli 2026•9 menit baca

Forecasting Penjualan dengan AI: Realistis atau Overhyped?

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.

BimaBima
Analisa Sentimen dengan AI: Olah Review Pelanggan Jadi Insight
AI untuk Analis
6 Juli 2026•10 menit baca

Analisa Sentimen dengan AI: Olah Review Pelanggan Jadi Insight

Cara ngolah ribuan review pelanggan jadi insight pakai AI, dari nyusun prompt yang konsisten, ngasih label, sampai ngubah hasilnya jadi rekomendasi yang bisa dieksekusi.

BimaBima
Kembali ke Blog
Ngulik Data logoNgulik Data

Platform edukasi data lengkap untuk professionals Indonesia. Belajar SQL, Data Analysis, dan lebih banyak lagi dengan praktek langsung dan feedback real-time.

© 2026 Ngulik Data. Semua hak dilindungi.

TAUTAN
BantuanHargaDatasetBlogAfiliasi
LEGAL
Syarat & KetentuanKebijakan Privasi
Ngulik Data
DatasetLeaderboardBlogStore