Praktik terbaik untuk mengonfigurasi Analisis Percakapan di Looker

Analisis Percakapan menggunakan Gemini untuk Google Cloud menafsirkan pertanyaan bahasa alami, menggunakan model semantik (LookML), nilai data, dan konfigurasi agen data Looker sebagai sumber kebenarannya. Kualitas responsnya terkait dengan seberapa efektif Anda menyiapkan input ini.

Panduan ini memberikan strategi dan praktik terbaik bagi developer dan administrator LookML untuk mengonfigurasi dan mengoptimalkan Analisis Percakapan. Dengan mengikuti rekomendasi ini untuk model LookML, Jelajah, dan agen data, Anda dapat meningkatkan adopsi pengguna dan memastikan bahwa pengguna mendapatkan jawaban yang akurat, relevan, dan berguna untuk pertanyaan mereka. Panduan ini mencakup praktik terbaik yang terkait dengan Analisis Percakapan, mengikuti alur logis yang dimulai dengan mengembangkan fondasi yang kuat dalam LookML model, mengonfigurasi Eksplorasi yang didasarkan pada model ini, dan membangun agen data yang menggunakan Eksplorasi ini sebagai sumber data.

Praktik terbaik LookML untuk Analisis Percakapan

Conversational Analytics menafsirkan pertanyaan bahasa alami dengan memanfaatkan input utama berikut:

  • Model LookML: Agen mengambil skema untuk Eksplorasi yang terhubung dengannya. Skema mencakup kolom (dimensi, ukuran), kolom hanya filter (filter, parameter), dan label, deskripsi, serta sinonim yang sesuai yang ditentukan dalam model LookML yang mendasari Jelajah Looker. Untuk daftar lengkap parameter LookML yang dianalisis oleh Analisis Percakapan, lihat ringkasan Analisis Percakapan.
  • Nilai kolom yang berbeda: Agen dapat mengambil sampel nilai data dan melakukan penelusuran fuzzy untuk memeriksa nilai kolom tertentu dalam database pokok. Metode ini memungkinkan agen memilih kolom yang benar, menerapkan nilai filter yang benar, dan mengidentifikasi kategori dan entity yang tersedia yang mungkin ditanyakan pengguna.

Efektivitas Analisis Percakapan terkait langsung dengan kualitas dan kejelasan input ini. Tabel berikut berisi cara umum LookML yang tidak jelas atau ambigu dapat memengaruhi Analisis Percakapan secara negatif, beserta solusi untuk mengurangi latensi serta meningkatkan output dan pengalaman pengguna.

Masalah kualitas LookML Solusi untuk Analisis Percakapan yang lebih jelas
Kurang jelas dan konflik penamaan: Kolom yang tidak memiliki label yang jelas, memiliki definisi yang ambigu, atau memiliki nama yang serupa di berbagai tampilan dapat menyebabkan pemilihan kolom yang salah. Terapkan label yang jelas dan deskripsi yang menyeluruh:
  • Gunakan parameter label untuk memberi kolom nama yang intuitif dan sesuai untuk bisnis.
  • Gunakan parameter description untuk memberikan konteks penting, definisi bahasa alami, dan terminologi khusus industri. Analisis Percakapan menggunakan deskripsi untuk mengidentifikasi arti kolom dan memetakan istilah pengguna dengan lebih baik.
Pembengkakan kolom: Menampilkan terlalu banyak kolom — seperti ID internal, kolom duplikat dari gabungan, atau penghitungan perantara — akan membuat opsi yang tersedia untuk Analisis Percakapan menjadi berantakan. Menyembunyikan kolom yang tidak relevan: Pastikan semua kunci utama, kunci asing, dan kolom teknis tetap tersembunyi.

(Opsional) Perluas Eksplorasi: Untuk Eksplorasi dengan banyak kolom, pertimbangkan untuk membuat versi khusus untuk Analisis Percakapan dengan memperluas Eksplorasi yang ada.
Pemuatan database untuk pengambilan sampel dan penelusuran: Pengambilan nilai sampel dan saran dari database dapat berjalan lambat atau menimbulkan pemuatan yang tidak perlu, terutama saat pengguna mereferensikan nilai data tertentu dalam kueri. Menentukan saran di LookML: Hindari kueri database real-time untuk saran kolom dengan meng-hard-code nilai atau mengarahkan ke dimensi yang lebih efisien:
Pemuatan database untuk kueri data: Kueri yang besar atau tidak efisien dapat meningkatkan latensi dan pemuatan database. Mengoptimalkan kueri data: Patuhi praktik terbaik umum untuk mengoptimalkan performa kueri, seperti menggunakan aggregate awareness dan logika gabungan yang efisien.
Definisi LookML yang tidak lengkap: Mengandalkan kolom kustom tingkat dasbor atau kalkulasi tabel membuat logika bisnis penting tidak dapat diakses oleh Analisis Percakapan. Menggabungkan logika kustom: Mengonversi kolom kustom atau kalkulasi tabel yang penting dan umum digunakan menjadi dimensi dan ukuran LookML.
Data yang tidak teratur: Jenis data yang tidak konsisten atau tidak terstruktur dengan baik berikut membuat Analisis Percakapan sulit menafsirkan kueri secara akurat.
  • Variasi nilai: Kapitalisasi atau konvensi penamaan yang tidak konsisten (misalnya, campuran nilai complete, Complete, dan COMPLETE) dapat menyebabkan duplikasi data atau hubungan data yang salah dalam Analisis Percakapan.
  • Jenis data yang tidak konsisten: Kolom yang seharusnya berupa numerik dan yang berisi nilai string sesekali akan memaksa jenis kolom menjadi string, yang mencegah operasi numerik.
  • Ambiguitas zona waktu: Kurangnya zona waktu standar di kolom stempel waktu dapat menyebabkan pemfilteran atau agregasi yang salah.
 Mengatasi kualitas data: Jika memungkinkan, tandai masalah kualitas data (nilai, jenis, zona waktu yang tidak konsisten) yang Anda identifikasi selama kurasi data. Bekerja sama dengan tim data engineering untuk membersihkan data sumber atau menerapkan transformasi di lapisan ETL/pemodelan data.

Poin-poin penting LookML

Ingat poin-poin penting ini saat menentukan LookML untuk Eksplorasi yang akan digunakan sebagai sumber data untuk Analisis Percakapan:

  • Gunakan label yang jelas dan tepat: Pilih label untuk data Anda yang mencerminkan cara pengguna bisnis Anda berbicara. Hindari singkatan teknis seperti "amt_usd_curr" dan gunakan "Amount (USD)".
  • Aktifkan pemetaan yang lancar: Gunakan sinonim dan deskripsi untuk membantu agen memetakan pertanyaan pengguna ke kolom yang benar.
  • Memusatkan penghitungan: Tentukan penghitungan yang sering digunakan secara langsung sebagai dimensi atau ukuran LookML untuk memastikan satu sumber tepercaya dan mengurangi latensi.
  • Menyederhanakan konteks: Sembunyikan kolom teknis atau khusus internal di LookML (seperti kunci asing atau ID mentah) untuk memastikan hanya kolom yang diperlukan untuk menjawab pertanyaan bisnis yang ditampilkan ke Analisis Percakapan. Berfokus hanya pada kolom yang relevan akan mengurangi gangguan dan meningkatkan akurasi pemilihan kolom.
  • Mengoptimalkan data contoh dan kueri penelusuran fuzzy: Tentukan nilai hardcode dalam parameter suggestions, atau gunakan suggest_dimension dan suggest_explore untuk kueri database yang lebih efisien.
  • Mengoptimalkan kueri data: Patuhi praktik terbaik Looker umum untuk mengoptimalkan performa kueri, seperti menggunakan aggregate awareness dan logika gabungan yang efisien.

Untuk mengetahui praktik terbaik lainnya dalam menulis LookML yang bersih dan efisien, lihat dokumentasi berikut:

Praktik terbaik untuk menyiapkan Eksplorasi yang akan digunakan dengan Analisis Percakapan

Untuk membantu Analisis Percakapan memberikan jawaban yang paling bermanfaat, pertimbangkan untuk mengikuti praktik terbaik berikut saat menentukan Eksplorasi yang akan digunakan sebagai sumber data untuk Analisis Percakapan:

  • Di LookML pokok Eksplorasi Anda, tentukan hanya kolom yang berguna untuk analisis oleh pengguna akhir.
    • Beri setiap kolom nama dan deskripsi yang jelas dan ringkas.
    • Sertakan nilai sampel jika relevan. Nilai contoh sangat membantu untuk kolom jenis string.
  • Pertimbangkan untuk menyeleksi Eksplorasi khusus agen data yang menggunakan kembali konten.
    • Gunakan extends untuk membuat LookML yang sudah ada dan mengatur kolom yang dibutuhkan agen. Di Aktivitas Sistem, pengguna dapat melihat kolom yang digunakan dalam kueri yang dibuat oleh agen dan memutuskan kolom yang akan dikecualikan.
    • Gunakan penyempurnaan LookML tingkat kolom untuk membuat deskripsi yang dibuat khusus untuk agen — "Gunakan kolom Pesanan saat pengguna merujuk ke Penjualan".

Praktik terbaik untuk membuat agen data

Setelah membangun fondasi yang kuat dengan praktik terbaik LookML dan Eksplorasi yang dikonfigurasi dengan baik, Anda dapat membangun agen data untuk memberikan pengalaman percakapan yang disesuaikan untuk kasus penggunaan atau grup pengguna tertentu. Agen data terhubung ke maksimal lima Eksplorasi dan menggunakan petunjuk bahasa alami untuk memberikan konteks, menentukan terminologi, dan menetapkan pedoman perilaku.

Mengikuti praktik terbaik saat membuat agen dan menulis petunjuk sangat penting untuk menyesuaikan respons agen agar memenuhi kebutuhan pengguna tertentu dan meningkatkan akurasi secara keseluruhan. Praktik terbaik ini mencakup merancang agen khusus untuk domain tertentu dan menulis petunjuk yang jelas dan efektif.

Membangun agen khusus

Meskipun Anda mungkin tergoda untuk membuat satu agen data global untuk menangani semua pertanyaan bisnis, performa agen akan lebih baik jika mereka dikhususkan untuk domain tertentu, seperti analisis penjualan, pemasaran, atau produk. Agen yang berfokus pada satu atau beberapa Eksplorasi yang terkait erat dapat diberi petunjuk yang lebih presisi, sehingga mengurangi ambiguitas dan meningkatkan akurasi respons.

Saat mendesain agen, hindari membuat satu agen untuk menangani semua model data yang tidak terkait. Sebagai gantinya, buat agen yang berfokus untuk area bisnis yang berbeda, yang hanya terhubung ke Eksplorasi yang terkait erat. Misalnya, alih-alih satu agen untuk semua data perusahaan, buat "Agen Pendapatan" yang berfokus secara khusus pada Eksplorasi Orders dan Transactions.

Menulis petunjuk agen yang efektif

Petunjuk agen adalah alat utama Anda untuk menyesuaikan perilaku agen data dan memasukkan logika bisnis serta terminologi unik organisasi Anda ke dalamnya. Anggap petunjuk sebagai cara untuk melatih agen Anda tentang cara menafsirkan pertanyaan pengguna, menangani ambiguitas, dan merespons dengan cara yang paling membantu pengguna Anda. Petunjuk yang ditulis dengan baik adalah kunci untuk menghasilkan jawaban yang akurat, relevan, dan andal.

Masukkan petunjuk agen Anda di kolom Petunjuk saat Anda membuat agen data. Untuk mengetahui informasi selengkapnya tentang cara membuat agen, lihat halaman dokumentasi Membuat dan mengelola agen data Jelajah.

Untuk menulis petunjuk yang efektif, ikuti praktik terbaik berikut:

  • Tentukan konteks bisnis dan perilaku default: Latih agen tentang logika dan terminologi unik organisasi Anda. Gunakan petunjuk untuk menentukan akronim (misalnya, "LY berarti Tahun Lalu"), menjelaskan logika pemfilteran umum, atau menetapkan perilaku default untuk menghindari ambiguitas (misalnya, "Jika tidak ada date_created yang diberikan, filter ke 6 bulan terakhir").
  • Gunakan sintaksis LookML dan filter: Saat merujuk ke kolom atau menerapkan filter dalam petunjuk, gunakan sintaksis LookML (misalnya, events.date_created) dan sintaksis filter (misalnya, "last 6 months"). Hal ini memastikan bahwa agen memahami kolom atau filter mana yang akan diterapkan. Misalnya: "Saat pengguna bertanya tentang 'region', gunakan kolom account_holder.geo_region."
  • Ringkas: Tulis dengan jelas dan hindari kata-kata yang tidak perlu atau pengulangan dalam petunjuk.
  • Hindari redundansi: Jangan menduplikasi informasi yang ada di LookML, seperti deskripsi atau sinonim kolom. Untuk mempelajari lebih lanjut kapan harus menentukan konteks di LookML versus petunjuk agen, lihat Kapan harus menambahkan konteks ke LookML versus Analisis Percakapan. Hindari juga menjelaskan konsep dasar yang sudah dipahami agen, seperti perbedaan antara dimensi dan ukuran atau cara melakukan pemfilteran tanggal dasar.

Batasan petunjuk agen

Perhatikan batasan Analisis Percakapan berikut saat menulis petunjuk agen:

  • Analisis Percakapan tidak mendukung pembuatan kueri yang berisi parameter pivots. Meskipun Analisis Percakapan dapat menampilkan data untuk beberapa dimensi sekaligus, Analisis Percakapan tidak dapat memutar data tersebut ke dalam kolom terpisah seperti yang dapat dilakukan UI Jelajah Looker. Sebagai gantinya, data ditampilkan dalam format "panjang" atau "diratakan", sehingga data dikelompokkan secara horizontal, bukan vertikal.
  • Tidak seperti LookML yang diatur, petunjuk sering kali berupa teks bebas dan dapat menjadi "usang" seiring berkembangnya model data yang mendasarinya dari waktu ke waktu. Untuk menghindari petunjuk yang tidak berlaku dengan agen data Eksplorasi, gunakan kueri terverifikasi untuk menentukan pasangan pertanyaan bahasa alami dan kueri Eksplorasi yang sesuai.

Contoh petunjuk agen

Berikut beberapa contoh petunjuk untuk agen data yang terhubung ke Eksplorasi Looker yang disebut Item Pesanan dan Produk:

# Define a persona and provide instructions on how to propose suggestions
You are a helpful data assistant. After answering the user's question, please provide 2-3 relevant follow-up questions they might be interested in exploring based on the data.
Anticipate the user's needs. Suggest potential next questions or related analyses after each response.
Always offer suggestions for deeper dives into the data.
Your tone should be professional and concise.

# Business Terms
# Define how business terms map to LookML fields or data values that can't be captured in LookML synonyms or descriptions.
Terms:
  EOP: End of Period. This is the last day of the period.
  LY: Last Year.
  Month-over-month: This is a measure of `type: period_over_period` with `period: month`.

# Default Behaviors
# Define how to handle ambiguous or underspecified queries.
When users mention Orders, you must apply a filter of `Status` like `COMPLETED`. Consider this a **hard-coded requirement**. Do not attempt to verify this filter by querying sample values; proceed directly to the calculation using this exact string.
Defaults:
  Date Filter: If no `created_date` is specified by the user, filter order_items.created_date to "last 12 months".
  Product Grouping: If "group by product" is requested without specifying name or category, use `products.category`.

# Related Fields
# Provide instructions for what other related fields the agent should fetch information from
Include parent dimensions like Category when asking for "item level" data.

Kapan harus menambahkan konteks ke LookML versus Analisis Percakapan

Di Conversational Analytics, Anda dapat menambahkan konteks ke LookML atau di dalam petunjuk agen. Saat Anda memutuskan tempat untuk menambahkan konteks, terapkan panduan berikut:

  • Konteks yang harus berlaku untuk semua pengguna Eksplorasi harus ditambahkan langsung ke model LookML Anda, karena Eksplorasi Looker dapat digunakan di beberapa tempat, termasuk di dasbor dan Analisis Percakapan. Jika konteks hanya boleh berlaku untuk pengguna tertentu, pertimbangkan untuk menggunakan fitur LookML seperti atribut pengguna untuk membuat pengalaman yang disesuaikan.
  • Prioritaskan LookML untuk metadata khusus kolom dan persyaratan berat. Tempatkan metadata khusus kolom, termasuk sinonim dan deskripsi, langsung di LookML, bukan di petunjuk agen. Persyaratan untuk hal-hal seperti nilai filter default atau kolom tersembunyi sebaiknya ditangani di LookML untuk memastikan persyaratan tersebut dipatuhi.
  • Jangan menduplikasi informasi yang sudah diketahui agen, seperti cara membuat kueri Looker, penjelasan dimensi atau ukuran, Eksplorasi yang dapat diakses, atau cara melakukan pemfilteran tanggal dasar. Demikian pula, jangan tentukan istilah yang sama di LookML dan dalam petunjuk agen.

Konteks agen harus kualitatif dan berfokus pada pengguna, dan ada banyak agen yang melayani pengguna yang berbeda dari satu Eksplorasi. LookML bagus untuk menentukan apa itu kolom, tetapi biasanya tidak dapat menentukan strategi bisnis atau perhitungan prediktif. Contoh konteks yang harus disertakan dalam petunjuk agen, tetapi tidak dalam LookML, adalah sebagai berikut:

  • Siapa pengguna yang berinteraksi dengan agen? Apa peran mereka? Apakah mereka berasal dari dalam atau luar perusahaan? Apa pengalaman analisis mereka sebelumnya?
  • Apa tujuan pengguna? Jenis keputusan apa yang ingin mereka buat di akhir percakapan?
  • Apa saja jenis pertanyaan yang akan diajukan pengguna ini?
  • Kolom apa yang paling relevan bagi pengguna ini? Misalnya, kolom mana yang harus dapat diakses oleh pengguna ini, apakah filter tertentu harus selalu diterapkan, atau apakah beberapa kolom harus diprioritaskan untuk pengguna ini?