Selama beberapa tahun terakhir, kami beralih ke web yang lebih aman dengan menganjurkan agar situs-situs menerapkan enkripsi HTTPS. Dan tahun lalu, kami juga membantu pengguna mengerti bahwa situs HTTP tidak aman dengan ...
Selama beberapa tahun terakhir, kami beralih ke web yang lebih aman dengan menganjurkan agar situs-situs menerapkan enkripsi HTTPS. Dan tahun lalu, kami juga membantu pengguna mengerti bahwa situs HTTP tidak aman dengan secara bertahap menandai sebagian besar halaman HTTP sebagai “not secure”. Mulai bulan Juli 2018 bersamaan dengan rilis Chrome 68, Chrome akan menandai semua situs HTTP sebagai “not secure”.


Di Chrome 68, omnibox akan menampilkan tanda “Not secure” untuk semua halaman HTTP.

Developer telah mengalihkan situs mereka ke HTTPS dan membuat web lebih aman untuk semua orang. Kemajuan tahun lalu sungguh luar biasa, dan terus berlanjut sampai sekarang:

  • Lebih dari 68% lalu lintas Chrome di Android dan Windows sekarang terlindungi
  • Lebih dari 78% lalu lintas Chrome di Chrome OS dan Mac sekarang terlindungi
  • 81 dari 100 situs teratas di web secara default menggunakan HTTPS
Chrome didedikasikan agar proses penyiapan HTTPS bisa dilakukan semudah mungkin. Audit konten campuran sekarang sudah tersedia untuk membantu developer melakukan migrasi situs mereka ke HTTPS dalam versi Node CLI terbaru dari Lighthouse, fitur otomatis untuk memperbarui halaman web. Audit baru di Lighthouse ini membantu developer menemukan sumber daya apa yang dimuat situs dengan menggunakan HTTP, dan apa yang siap untuk diupgrade ke HTTPS hanya dengan mengubah referensi sub-sumber daya ke versi HTTPS.

Lighthouse adalah fitur developer otomatis untuk memperbarui halaman web.

Antarmuka baru Chrome akan membantu pengguna mengerti bahwa semua situs HTTP tidak aman, dan secara bertahap mengalihkan web ke versi web HTTPS yang aman secara default. HTTPS lebih mudah dan lebih murah daripada sebelumnya, dan HTTPS akan membuka kunci peningkatan kinerja dan fitur kuat baru yang terlalu sensitif untuk HTTP. Developer, pelajari panduan penyiapan kami untuk memulai.

Diposting oleh Emily Schechter, Chrome Security Product Manager



Daftarkan diri anda untuk #GooglePlay, seri webinar Google play pertama yang dirancang khusus untuk developer Indonesia. Kami akan membahas tentang masalah utama dari kebijakan Google Play dan fitur kunci Play console yang relevan untuk Anda. Akan ada sesi tanya jawab pada webinar ini, dimana Anda bisa mengajukan pertanyaan langsung kepada tim Google Play. Jangan lewatkan kesempatan menarik ini dan daftarkan diri Anda sekarang ...


Daftarkan diri anda untuk #GooglePlay, seri webinar Google play pertama yang dirancang khusus untuk developer Indonesia. Kami akan membahas tentang masalah utama dari kebijakan Google Play dan fitur kunci Play console yang relevan untuk Anda. Akan ada sesi tanya jawab pada webinar ini, dimana Anda bisa mengajukan pertanyaan langsung kepada tim Google Play. Jangan lewatkan kesempatan menarik ini dan daftarkan diri Anda sekarang: goo.gl/YgVayV

Sesi Mendatang:

February 22, 2018, 3:00-4:00 PM (WIB)
Mulai dengan kebijakan Google Play

March 22, 2017, 3:00-4:00 PM (WIB)
PlaySchool Webinar: Fitur Utama Play Console

Sampai ketemu di sesi webinarnya! Registrasi sekarang: goo.gl/YgVayV


Terima kasih,


Tim Google Play

Catatan editor: Artikel berikut ini diposting di Medium oleh Martin Schierle, Mobile Solutions Consultant, Google.
Catatan editor: Artikel berikut ini diposting di Medium oleh Martin Schierle, Mobile Solutions Consultant, Google.

TL;DR: Setiap kali menguji kinerja AMP, ingatlah bahwa pengujian dari situs aslinya akan berpotensi mencakup penyetelan server yang kurang optimal seperti header cache yang buruk atau optimalisasi gambar yang hilang. Serta hasil kecepatan terbesar (mendekati muat instan selama prerendering) tidak akan tercermin dalam alat kinerja dan metrik yang biasa digunakan.

Developer yang mengimplementasikan AMP menginginkan loading yang sangat cepat, dan karenanya sering penasaran ingin melihat seberapa cepat situs mereka meningkat dengan AMP. Namun, ketika menjalankan salah satu dari banyak alat kinerja yang ada (mis. PageSpeed Insights atau Lighthouse) terkadang memberikan hasil yang mengejutkan dan tampaknya kurang optimal.
Untuk memahami mengapa hal ini terjadi, penting untuk disadari bahwa AMP mempercepat situs web pada tiga level yang berbeda:
  1. AMP sendiri sudah sangat cepat, karena JS kustom dilarang, critical path tidak diblokir, CSS dibuat inline dan banyak optimalisasi lainnya. Namun, mungkin masih ada hambatan dari sisi server, mis. gambar yang tidak dioptimalkan atau header cache yang tidak memadai, yang sulit diatasi oleh library AMP sisi klien.
  2. Level percepatan kedua dicapai melalui caching oleh AMP Cache (mis. Google AMP Cache), yang akan mengoptimalkan gambar, menambahkan petunjuk prefetch, mempersingkat html, menyajikan melalui HTTP/2, serta banyak optimalisasi lainnya. Perlu diingat bahwa sebagian besar optimalisasi tersebut juga bisa dilakukan di situs aslinya.
  3. Level peningkatan percepatan ketiga (dan yang paling berpengaruh) adalah berdasarkan fakta bahwa AMP bisa dirender terlebih dahulu dengan cara yang aman dan terlindungi, dengan melakukan pra-perenderan aset saja di viewport pertama, dan tidak mengeksekusi skrip pihak ketiga. Hal ini dijelaskan secara lebih detail di sini.
Jadi, jika pemeriksaan kinerja dilakukan pada AMP di situs aslinya, skor kecepatan (meskipun biasanya jauh lebih cepat daripada kanonis) belum mewakili semuanya. Cara lebih baik untuk mengujinya adalah dengan menjalankan uji kinerja di situs yang sama dengan yang disediakan salah satu AMP Cache (Anda bisa menggunakan alat ini untuk mendapatkan URL cache bagi Google AMP Cache). Ini akan memasukkan optimalisasi melalui cache ke dalam pengukuran. Skor ini sudah jauh lebih baik, dan pada dasarnya juga menunjukkan apa yang bisa Anda capai di host Anda sendiri dengan menerapkan optimalisasi seperti yang telah dijelaskan sebelumnya.
Mari kita lihat seperti apa tampilan halaman yang sesungguhnya, inilah salah satu halaman contoh kami dari ampbyexample.com:

measure1
Hasil terperinci bisa ditemukan di sini. Bagan ini dengan jelas menggambarkan bagaimana kinerja meningkat bila diukur dari AMP Cache sebagai ganti situs asli di hampir semua metrik. Sorotan pertama, misalnya, 0,9 detik lebih cepat dari cache.
Sayangnya, kejadian ketiga dan terpenting (nyaris langsung dimuat selama pra-perenderan) sulit diukur dengan alat biasa, karena ini harus diukur dalam aliran yang berasal dari situs atau aplikasi yang dikunjungi sebelumnya. Namun, tentu saja suatu halaman bisa langsung ditampilkan, asalkan semua konten yang terlihat sudah dirender sebelumnya. Webpagetest.org memungkinkan untuk menguji aliran seperti ini melalui opsi pembuatan skrip, tetapi rumit dan rawan-error untuk dipersiapkan serta dipelihara. Skrip terlihat seperti ini:
// don’t log data for first navigation step

logData 0 

// navigate to the first page (e.g. Google SRP) which prerenders AMP

navigate INSERT_URL_CALLED_BEFORE_AMP

// sleep a bit to give prerendering time,
// a user normally also doesn’t click through immediately

sleep 10

// start logging now for clickthrough to AMP

logData 1

// click through, insert correct query expression
// to find the right link to click for your doc

execAndWait document.querySelector(‘[…]’).click();
Saat menambahkannya, perbandingan lengkap ketiga mode tersebut terlihat seperti ini (dengan hasil terperinci bisa dilihat di sini):

measure2.png
Ini menunjukkan keuntungan dari pra-perenderan, sehingga render bisa dimulai hampir seketika itu juga (66ms) dan secara visual lengkap serta interaktif setelah kira-kira 1 detik.
Jadi, setiap kali pengujian kinerja AMP dilakukan, ingatlah bahwa tidak semua keuntungan kecepatan itu langsung terlihat jelas, karena beberapa akan masuk melalui caching dan terutama pra-perenderan.

Diposting di Medium oleh Martin Schierle, Mobile Solutions Consultant, Google

Mengoptimalkan pengalaman iklan di aplikasi Anda untuk bermacam-macam audience bisa merupakan hal yang sulit. Menampilkan iklan kepada pengguna yang tepat bisa meningkatkan keseluruhan pengalaman iklan dan membantu memaksimalkan pendapatan aplikasi Anda.
Mengoptimalkan pengalaman iklan di aplikasi Anda untuk bermacam-macam audience bisa merupakan hal yang sulit. Menampilkan iklan kepada pengguna yang tepat bisa meningkatkan keseluruhan pengalaman iklan dan membantu memaksimalkan pendapatan aplikasi Anda.

AdMob telah meluncurkan fitur baru yang memungkinkan Anda menentukan rating konten untuk iklan Google yang disajikan di aplikasi. Dengan sinyal max_ad_content_rating signal baru, kini Anda bisa memilih rating konten dari permintaan Google yang ingin diperoleh pada basis per-permintaan.

Empat pilihan rating konten menawarkan tingkat detail yang Anda butuhkan untuk memberi pengguna di setiap tingkat dengan pengalaman pengguna yang lebih baik.

Empat pilihan rating konten baru tersebut adalah:

  • G: Konten yang cocok untuk audience umum 
  • PG: Konten yang cocok untuk sebagian besar audience dengan bimbingan orang tua 
  • T: Konten yang cocok untuk audience remaja dan yang lebih tua 
  • MA: Konten yang hanya cocok untuk audience dewasa 


Anda bisa mulai mengirimkan sinyal max_ad_content_rating baru di Google Mobile Ads SDK dengan mengikuti panduan Android dan iOS ini.

 Untuk mempelajari lebih lanjut tentang sinyal baru dan pilihan rating konten, kunjungi pusat bantuan AdMob atau hubungi tim akun Google Anda.

Diposting oleh Alexa Haushalter, Product Manager, AdMob

Diposting oleh Andrew Ahn, Product Manager, Google Play
Aplikasi menghidupkan perangkat -- sehingga Anda bisa memesan tumpangan dengan seketika, terhubung dan berbagi memori dengan teman, diberi tahu tentang event terkini, bermain game dengan pemain di seluruh dunia, dan menyelesaikan pekerjaan di kantor atau di jalan. Google Play berkomitmen untuk menyediakan pengalaman aman bagi miliaran pengguna Android untuk mencari dan menemukan aplikasi semacam itu. Selama bertahun-tahun, komitmen ini membuat Google Play menjadi tempat yang tepercaya dan lebih aman. Tahun lalu kami bisa mencegah lebih dari separuh kemungkinan pengguna menginstal aplikasi berbahaya, melindungi pengguna serta perangkat mereka dari bahaya, dan membuat Google Play menjadi tempat yang lebih sulit ditembus bagi mereka yang berusaha menyalahgunakan ekosistem aplikasi untuk keuntungan mereka sendiri.
 Diposting oleh Andrew Ahn, Product Manager, Google Play
Aplikasi menghidupkan perangkat -- sehingga Anda bisa memesan tumpangan dengan seketika, terhubung dan berbagi memori dengan teman, diberi tahu tentang event terkini, bermain game dengan pemain di seluruh dunia, dan menyelesaikan pekerjaan di kantor atau di jalan. Google Play berkomitmen untuk menyediakan pengalaman aman bagi miliaran pengguna Android untuk mencari dan menemukan aplikasi semacam itu. Selama bertahun-tahun, komitmen ini membuat Google Play menjadi tempat yang tepercaya dan lebih aman. Tahun lalu kami bisa mencegah lebih dari separuh kemungkinan pengguna menginstal aplikasi berbahaya, melindungi pengguna serta perangkat mereka dari bahaya, dan membuat Google Play menjadi tempat yang lebih sulit ditembus bagi mereka yang berusaha menyalahgunakan ekosistem aplikasi untuk keuntungan mereka sendiri.

Pada tahun 2017, kami mencopot lebih dari 700.000 aplikasi yang melanggar kebijakan Google Play, naik 70% daripada aplikasi yang dicopot pada tahun 2016. Namun tidak hanya mencopot lebih banyak aplikasi berbahaya, kami juga bisa mengidentifikasi dan melakukan tindakan lebih awal terhadap mereka. Bahkan, 99% aplikasi dengan konten berbahaya bisa diidentifikasi dan ditolak sebelum siapa pun dapat menginstalnya. Hal ini bisa terjadi melalui peningkatan signifikan kemampuan kami dalam mendeteksi penyalahgunaan - seperti pemalsuan, konten yang tidak pantas, atau malware - melalui model dan teknik machine learning baru.

Kami juga telah mengembangkan model dan teknik deteksi baru yang bisa mengidentifikasi pelanggar berulang dan jaringan developer jahat dalam skala besar. Hal ini mengakibatkan dicopotnya 100.000 developer jahat di tahun 2017, dan mempersulit aktor jahat untuk membuat akun baru dan coba memublikasikan kumpulan aplikasi berbahaya lainnya.

Berikut adalah beberapa contoh aplikasi berbahaya yang kami berikan tindakan pada tahun 2017:

Copycats


Mencoba menipu pengguna dengan memalsukan aplikasi terkenal adalah salah satu pelanggaran yang paling sering terjadi. Judul yang terkenal mendapatkan banyak lalu lintas penelusuran untuk kata kunci tertentu, jadi aktor jahat mencoba menghimpun penginstalan dengan memanfaatkan lalu lintas tersebut. Mereka melakukannya dengan mencoba memasukkan aplikasi tiruan ke Play Store melalui metode yang menipu seperti menggunakan karakter unicode yang membingungkan dan menyembunyikan ikon aplikasi palsu di tempat yang berbeda. Pada tahun 2017, kami mencopot lebih dari seperempat juta aplikasi yang memalsukan identitas.

Konten yang tidak pantas


Kami tidak mengizinkan aplikasi yang memuat atau mempromosikan konten yang tidak pantas, seperti pornografi, kekerasan ekstrem, kebencian, dan aktivitas ilegal. Model machine learning yang disempurnakan memilah sejumlah besar kiriman aplikasi masuk dan menandainya terhadap potensi pelanggaran, membantu pengulas untuk secara efektif mendeteksi dan menertibkan aplikasi bermasalah. Puluhan ribu aplikasi dengan konten yang tidak pantas dicopot tahun lalu sebagai hasil dari metode deteksi yang lebih baik.

Potentially Harmful Applications (PHA)


PHA adalah jenis malware yang bisa membahayakan pengguna atau perangkat mereka -- mis., Aplikasi yang melakukan penipuan SMS, bertindak seperti trojan, atau melakukan phishing informasi pengguna. Meski kecil jumlahnya, PHA merupakan ancaman bagi pengguna Android dan kami banyak berinvestasi untuk menjauhkan mereka dari Play Store. Menemukan aplikasi berbahaya ini tidaklah mudah karena developer jahat bekerja keras agar aplikasi mereka terlihat absah, tetapi dengan peluncuran Google Play Protect di tahun 2017, rata-rata tingkat penginstalan PHA per tahun di Google Play berkurang sebesar 50 persen dari tahun ke tahun.

Terlepas dari penyempurnaan kemampuan deteksi baru yang menyebabkan pencopotan aplikasi berbahaya dan developer jahat mencatat rekor tertinggi, kami tahu beberapa dari mereka berhasil menghindari dan mengelabui lapisan pertahanan kami. Kami menganggap masalah ini dengan sangat serius, dan akan terus menyempurnakan kemampuan agar bisa lebih baik dalam mendeteksi dan melindungi pengguna dari aplikasi yang berbahaya dan aktor jahat di belakangnya. Kami berkomitmen untuk menjadikan Google Play sebagai app store paling tepercaya dan aman di dunia.

Menurut Anda seberapa bermanfaatkah entri blog ini?


Diposting oleh Laurence Moroney, Developer Advocate

Dengan senang hati kami umumkan bahwa TensorFlow 1.5 sekarang tersedia untuk umum! Install sekarang untuk menikmati beragam fitur baru yang bisa Anda nikmati!

Eager Execution for TensorFlow

Diposting oleh Laurence Moroney, Developer Advocate

Dengan senang hati kami umumkan bahwa TensorFlow 1.5 sekarang tersedia untuk umum! Install sekarang untuk menikmati beragam fitur baru yang bisa Anda nikmati!

Eager Execution for TensorFlow


Pertama, Eager Execution for TensorFlow kini tersedia sebagai versi preview. Kami telah mendengar banyak masukan tentang gaya pemrograman TensorFlow, dan bagaimana developer benar-benar menginginkan gaya pemrograman imperatif, define-by-run. Dengan mengaktifkan Eager Execution for TensorFlow, Anda bisa menjalankan operasi TensorFlow segera setelah mereka dipanggil dari Python. Hal ini mempermudah kita ketika ingin memulai TensorFlow, dan menjadikan riset serta development lebih intuitif.

Misalnya, bayangkan sebuah komputasi sederhana seperti perkalian matriks. Sekarang ini, di TensorFlow kodenya terlihat seperti ini:
x = tf.placeholder(tf.float32, shape=[1, 1])
m = tf.matmul(x, x)

with tf.Session() as sess:
  print(sess.run(m, feed_dict={x: [[2.]]}))

Jika Anda mengaktifkan Eager Execution for TensorFlow, kodenya akan terlihat seperti ini:
x = [[2.]]
m = tf.matmul(x, x)

print(m)

Anda bisa mempelajari lebih lanjut tentang Eager Execution for TensorFlow di sini (lihat panduan pengguna yang tertaut di bagian bawah halaman, dan juga presentasi ini) serta dokumentasi API di sini.

TensorFlow Lite


Versi preview Developer TensorFlow Lite dibangun ke dalam versi 1.5. TensorFlow Lite, solusi ringan TensorFlow untuk perangkat mobile dan embedded devices, memungkinkan Anda mengambil model TensorFlow terlatih dan mengubahnya menjadi file .tflite yang kemudian bisa dijalankan pada perangkat mobile dengan latensi rendah. Dengan demikian pelatihan tidak harus dilakukan pada perangkat, dan perangkat juga tidak perlu mengupload data ke cloud untuk membuatnya berfungsi. Jadi, andaikata Anda ingin mengklasifikasikan gambar, model terlatih bisa diterapkan ke perangkat dan klasifikasi gambar dilakukan secara langsung di perangkat.

TensorFlow Lite menyertakan contoh aplikasi untuk membantu Anda memulai. Aplikasi ini menggunakan model MobileNet dari 1001 kategori gambar unik. Ia mengenali gambar dan mencocokkannya dengan sejumlah kategori, lalu mencantumkan 3 teratas yang dikenalinya. Aplikasi ini tersedia di Android dan iOS.

Anda bisa mempelajari lebih lanjut tentang TensorFlow Lite, dan cara mengonversi model agar tersedia pada seluler di sini.

Update Akselerasi GPU


Jika Anda menggunakan Akselerasi GPU pada Windows atau Linux, TensorFlow 1.5 sekarang memiliki dukungan bawaan CUDA 9 dan cuDNN 7.

Untuk mempelajari lebih lanjut tentang Compute Unified Device Architecture (CUDA) 9 dari NVidia, cek situs NVidia di sini.

Ini diperkuat CUDA Deep Neural Network Library (cuDNN), rilis terbaru yang merupakan versi 7. Dukungan untuk hal ini sekarang disertakan dalam TensorFlow 1.5.

Berikut adalah beberapa artikel Medium mengenai dukungan GPU pada Windows dan Linux, dan cara menginstalnya pada workstation Anda (jika mendukung hardware yang disyaratkan)

Update Situs Dokumentasi


Bersama dengan rilis ini, kami juga merombak situs dokumentasi, termasuk alur Memulai disempurnakan yang akan membantu Anda dari tidak berpengetahuan hingga membangun neural network untuk mengklasifikasikan berbagai tipe iris dalam waktu yang sangat singkat. Cobalah!

Penyempurnaan Lainnya


Selain fitur-fitur ini, ada banyak penyempurnaan lain untuk Accelerated Linear Algebra (XLA), update RunConfig dan banyak lagi. Lihat catatan rilis di sini.

Menginstal TensorFlow 1.5


Untuk mendapatkan TensorFlow 1.5, Anda bisa menggunakan penginstalan pip standar (atau pip3 jika Anda menggunakan python3)
$  pip install --ignore-installed --upgrade tensorflow

TL;DR: Kami membuat perubahan mengenai bagaimana AMP bekerja di platform seperti Google Search yang akan menyebabkan halaman yang ditautkan muncul di bawah URL publisher sebagai ganti ruang URL google.com/amp selagi mempertahankan kinerja dan keuntungan privasi dari layanan AMP Cache.
TL;DR: Kami membuat perubahan mengenai bagaimana AMP bekerja di platform seperti Google Search yang akan menyebabkan halaman yang ditautkan muncul di bawah URL publisher sebagai ganti ruang URL google.com/amp selagi mempertahankan kinerja dan keuntungan privasi dari layanan AMP Cache.

Saat pertama kali meluncurkan AMP di Google Search, kami melakukan kompromi besar: untuk mendapatkan pengalaman pengguna seperti yang diinginkan pengguna, instant loading, kami harus memulai pemuatan halaman sebelum pengguna mengklik. Seperti yang kami jelaskan dalam entri blog mendalam tahun lalu,  alasan privasi adalah sebab mengapa pemuatan halaman dari server publisher tidak mungkin dilakukan. Publisher tidak boleh tahu apa yang diminati pengguna sampai mereka secara aktif membuka halamannya. Sebagai gantinya, halaman AMP dimuat dari Google AMP Cache, tetapi dengan tindakan tersebut, URL berubah dan menyertakan awalan URL google.com/amp/.

Kami adalah penggemar URL yang relevan dan menyadari bahwa ini tidaklah ideal. Banyak dari kalian pasti setuju. Ini adalah masukan #1 yang kami dengar tentang AMP. Kami berusaha untuk memastikan bahwa URL ini muncul dalam beberapa tempat saja. Seiring waktu, aplikasi asli Google Search di Android dan iOS akan mulai menampilkan URL publisher secara default dan kami bekerja dengan vendor browser untuk membagikan URL publisher dari sebuah artikel jika memungkinkan. Namun, kami tidak bisa memperbaiki status URL yang paling krusial: di web dan URL browser bar.

Beberapa bulan kami berusaha memperbaiki masalah ini, dan hari ini, kami akhirnya yakin bahwa kami menemukan sebuah solusi: Seperti yang direkomendasikan oleh W3C TAG, kami ingin mengimplementasikan versi baru layanan AMP Cache berdasarkan standar Web Packaging yang muncul. Berdasarkan standar web ini, navigasi AMP dari Google Search bisa memanfaatkan preloading perlindungan-privasi dan kinerja server Google, sembari tetap mempertahankan URL seperti yang diinginkan penayang dan konteks keamanan utama dari web, sumbernya, tetap terjaga. Kami telah membangun prototipe berbasis Browser Chrome dan versi eksperimental Google Search untuk memastikan bahwa ini benar-benar menghasilkan kinerja dan UX yang diinginkan dalam kasus penggunaan nyata. Langkah ini memberi kami keyakinan bahwa kami memiliki solusi yang menjanjikan untuk masalah sulit ini dan akan segera menjadi standar bagi pengguna menghadapi konten AMP di web.

Langkah berikutnya adalah melakukan implementasi penuh standar web baru di browser web dan Google AMP Cache. Tujuan kami adalah agar Web Packaging tersedia di sebanyak mungkin browser (bagaimanapun juga, Web Packaging bisa digunakan untuk hal menarik lainnya selain AMP seperti halaman offline, pemuatan modul ES6, dan penggabungan sumber daya). Secara khusus, kami ingin mengembangkan pekerjaan yang ada di WebKit agar memasukkan implementasi Web Packaging dan implementasi tim Google Chrome akan dimulai.

Kami sangat senang dengan pekerjaan yang sedang berjalan ini dan kami berharap perubahan ini bisa sampai ke tangan pengguna di paruh kedua tahun 2018. Terima kasih untuk semua masukan Anda mengenai masalah ini dan kami akan terus mengupdate perkembangan di blog ini!



Interaksi suara dengan teknologi menjadi bagian penting dalam kehidupan kita — mulai dari menggunakan ponsel untuk mengetahui kondisi lalu lintas ke tempat kerja hingga menggunakan perangkat cerdas di rumah untuk menyalakan lampu atau memutar musik. Google Assistant dirancang untuk menyediakan bantuan dan informasi pada berbagai platform, dan dibuat untuk menyatukan sejumlah produk — seperti Google Maps, Search, Google Photos, layanan pihak ketiga, dan banyak lagi. Untuk beberapa produk ini, kami telah merilis panduan evaluasi khusus, seperti ...


Interaksi suara dengan teknologi menjadi bagian penting dalam kehidupan kita — mulai dari menggunakan ponsel untuk mengetahui kondisi lalu lintas ke tempat kerja hingga menggunakan perangkat cerdas di rumah untuk menyalakan lampu atau memutar musik. Google Assistant dirancang untuk menyediakan bantuan dan informasi pada berbagai platform, dan dibuat untuk menyatukan sejumlah produk — seperti Google Maps, Search, Google Photos, layanan pihak ketiga, dan banyak lagi. Untuk beberapa produk ini, kami telah merilis panduan evaluasi khusus, seperti Search Quality Rating Guidelines. Namun, Asisten Google memerlukan panduan sendiri, karena banyak dari interaksinya memanfaatkan apa yang disebut dengan "teknologi eyes-free," ketika tidak ada layar sebagai bagian dari pengalaman.

Di masa lalu, kami menerima permintaan untuk melihat panduan evaluasi kami dari para akademisi yang meneliti penyempurnaan dalam interaksi suara, penjawab pertanyaan dan eksplorasi yang dipandu suara. Untuk memudahkan evaluasinya, kami menerbitkan beberapa panduan Google Assistant yang pertama. Harapan kami dengan membuat panduan ini bersifat publik adalah untuk membantu komunitas riset membangun dan mengevaluasi sistem mereka sendiri.

Membuat Panduan
Bagi banyak kueri, respons ditampilkan di layar (seperti ponsel) dengan grafik, tabel, atau elemen interaktif, seperti yang bisa Anda lihat pada [cuaca pekan ini].
Namun respons dengan suara sangat berbeda daripada hasil tampilan, karena apa yang ada di layar perlu diterjemahkan ke dalam ucapan yang mempunyai arti. Selain itu, konten respons suara terkadang berasal dari web, dan dalam kasus ini, kita harus memberi pengguna link ke sumber aslinya. Meskipun pengguna yang melihat perangkat seluler bisa mengklik untuk membaca halaman web aslinya, solusi eyes-free menghadirkan tantangan yang unik. Untuk menghasilkan respons audio yang optimal, kita menggunakan kombinasi pengetahuan linguistik eksplisit dan solusi deep learning yang memungkinkan kita untuk menghasilkan jawaban yang gramatikal, fasih dan ringkas.

Bagaimana kita memastikan bahwa kita secara konsisten memenuhi harapan pengguna akan kualitas, di semua jenis jawaban dan bahasa? Salah satu alat yang kita gunakan untuk mengukurnya adalah evaluasi manusia. Di sini, kami meminta penilai untuk memastikan bahwa jawaban-jawaban itu memuaskan dalam beberapa dimensi:
  • Kepuasan atas Informasi: konten jawaban harus merupakan informasi yang dibutuhkan pengguna.
  • Panjang: Bila jawaban yang ditampilkan terlalu panjang, pengguna bisa dengan cepat memindainya secara visual dan menemukan informasi yang relevan. Hal ini tidak mungkin dilakukan untuk jawaban dengan suara. Jauh lebih penting untuk memastikan bahwa kita memberikan sejumlah informasi yang membantu, dengan tidak terlalu banyak maupun terlalu sedikit. Beberapa hasil kerja kami sebelumnya saat ini sedang digunakan untuk mengidentifikasi fragmen jawaban yang paling relevan.
  • Formulasi: jauh lebih mudah memahami jawaban tertulis yang terformulasi dengan buruk daripada jawaban lisan yang tidak jelas, jadi kita harus lebih berhati-hati dalam memastikan kebenaran gramatikal.
  • Elokusi: jawaban lisan harus memiliki pengucapan dan intonasi yang tepat. Penyempurnaan dalam menghasilkan text-to-speech, seperti WaveNet dan Tacotron 2, dengan cepat mengurangi jarak dengan kinerja manusia.
Versi panduan terbaru bisa ditemukan di sini. Tentu saja, panduan sering diupdate, dan ini hanya merupakan ringkasan dari sesuatu yang hidup, evaluasi yang selalu berproses dan berubah!