WEBVTT 00:00:00.000 --> 00:00:02.580 Bayangkan ini, Anda sedang bekerja di sebuah aplikasi di perusahaan. 00:00:02.760 --> 00:00:07.680 Mungkin itu portal SDM basis data dukungan pelanggan atau wiki internal dengan semua kebijakan yang harus Anda ikuti. 00:00:08.000 --> 00:00:09.160 Anda mengetik pertanyaan kepada pencari. 00:00:09.740 --> 00:00:12.600 Sesuatu seperti, bagaimana cara mengajukan laporan pengelolaan untuk makan lama? 00:00:13.100 --> 00:00:14.260 Anda berkadang terdapat apa yang Anda dapatkan? 00:00:14.740 --> 00:00:15.100 Tidak ada. 00:00:15.560 --> 00:00:19.600 Atau lebih buruk lagi, daftar PDF acak dari 3 tahun lalu yang tidak cocok dengan kata-kata yang Anda ketik. 00:00:19.960 --> 00:00:21.580 Pencarian adalah sesuatu yang kita gunakan setiap hari. 00:00:22.200 --> 00:00:23.460 Dan seringkali hasilnya buruk. 00:00:23.980 --> 00:00:25.220 Tapi begini, sebenarnya tidak harus begitu. 00:00:25.720 --> 00:00:27.980 Bagaimana jika aplikasi Anda benar-benar bisa memahami apa yang Anda tanya? 00:00:27.980 --> 00:00:30.580 Bagaimana jika aplikasi tersebut bisa mencari seperti Google? 00:00:30.760 --> 00:00:33.340 Menemukan jawaban yang tepat meskipun Anda tidak menggunakan kata-kata yang sempur. 00:00:33.580 --> 00:00:35.140 Hari ini kita akan membahas Azure ASEC. 00:00:35.580 --> 00:00:36.260 Apa itu sebenarnya? 00:00:36.820 --> 00:00:40.260 Bagaimana cara kerjanya dan mengapa ini menjadi mesin pencari yang diandalkan aplikasi modern? 00:00:40.840 --> 00:00:42.200 Ambil kopi Anda dan mari kita mulai. 00:00:42.800 --> 00:00:43.560 Pengaruh pencari yang gagal. 00:00:43.880 --> 00:00:47.760 Untuk memahami mengapa pencarian biasanya gagal, kita harus melihat bagaimana sebagian besar aplikasi melakukan. 00:00:48.060 --> 00:00:50.700 Cara tradisional disebut pencarian kata kunci atau pencarian leksikan. 00:00:51.000 --> 00:00:56.480 Anda mengetik kata laptop ke dalam kotak dan sistem akan mencari setiap dokumen yang berisi kata yang tepat itu. 00:00:56.480 --> 00:01:00.820 Di balik layar, banyak dari sistem ini menggunakan algoritma yang disebut PM25. 00:01:01.280 --> 00:01:03.440 Ini tidak rumit, tetapi cukup cerdas dengan caranya sendiri. 00:01:04.120 --> 00:01:06.100 PM25 memberi peringkat hasil berdasarkan beberapa hal. 00:01:06.700 --> 00:01:11.940 Seberapa sering istilah pencarian Anda muncul dalam dokumen, seberapa panjang dokumen tersebut, dan seberapa langkah istilah tersebut di seluruh data. 00:01:12.840 --> 00:01:18.140 Bayangkan ini sebagai penghitung kata yang sangat canggih, yang menentukan dokumen mana yang paling relevan berdasarkan faktor-faktor tersebut. 00:01:18.620 --> 00:01:19.520 Disinilah letak kegagalan. 00:01:19.880 --> 00:01:20.740 Bahasa manusia itu berantakan. 00:01:21.080 --> 00:01:23.720 Orang tidak mengajukan pertanyaan menggunakan kata-kata yang sama dengan yang digunakan. 00:01:24.020 --> 00:01:25.260 Izinkan saya memberikan contoh konkret. 00:01:25.260 --> 00:01:27.500 Seorang pengguna mengetik ini ke dalam portal dukung. 00:01:28.200 --> 00:01:30.380 Laptop saya terus membeku saat melakukan panggilan video. 00:01:31.400 --> 00:01:38.040 Pencarian kata kunci akan dengan patuh mencari dokumen yang berisi laptop, terus membeku saat panggilan, dan video, dan video. 00:01:38.960 --> 00:01:43.160 Namun bagaimana jika artikel terbaik tentang topik tersebut berjudul mengatasi sistem yang hasil terpet? 00:01:43.840 --> 00:01:45.980 Atau mengelola pelambatan CPU pada laptop yang terhubung dok? 00:01:46.540 --> 00:01:47.980 Pencarian kata kunci benar-benar tersebut. 00:01:48.540 --> 00:01:48.740 Kenapa? 00:01:49.020 --> 00:01:49.960 Karena kata-katanya tidak cocok. 00:01:49.960 --> 00:01:51.240 Masalah intinya ada ini. 00:01:51.640 --> 00:01:52.860 Pencarian kata kunci memahami ejan. 00:01:53.260 --> 00:01:55.700 Ini memahami pola karakter tetapi tidak memahami makna. 00:01:56.420 --> 00:01:59.460 Anda mendapatkan hasil yang memiliki huruf yang benar tetapi seringkali konten yang salah. 00:01:59.780 --> 00:02:02.780 Jadi, jika pencocokan kata yang tepat menyisakan banyak jelah, apa alternatifnya? 00:02:03.840 --> 00:02:04.940 Cara baru pencarian vektor. 00:02:05.540 --> 00:02:08.180 Jadi pencarian vektor ini adalah cara kerja yang benar-benar berbeda. 00:02:08.620 --> 00:02:11.200 Alih-alih mencocokkan kata yang tepat, pencarian yang mencocokkan makna. 00:02:11.200 --> 00:02:12.620 Kedengarannya abstrak, jadi mari kita benar. 00:02:13.200 --> 00:02:15.560 Definisi paling sederhana yang perlu Anda tahu adalah ini, 00:02:15.660 --> 00:02:18.420 vektor hanyalah daftar angka yang mewakili sesuatu yang bisa diolah komputer. 00:02:19.100 --> 00:02:20.040 Hanya itu daftar angka. 00:02:20.740 --> 00:02:23.680 Embedding adalah jenis vektor khusus yang menangkap makna dari sebuah teks. 00:02:24.100 --> 00:02:26.340 Ia mengambil kalimat, paragraf, bahkan seluruh dokumen, 00:02:26.680 --> 00:02:28.440 lalu mengubahnya menjadi daftar angka yang panjang. 00:02:28.800 --> 00:02:31.520 Komputer tidak memahami kata-katanya tetapi ia memahami angka-angkanya. 00:02:31.940 --> 00:02:32.940 Ini ada analogi yang bisa membantuk. 00:02:33.280 --> 00:02:34.780 Bayangkan vektor seperti koordinat di sebuah peta. 00:02:35.220 --> 00:02:36.800 Di peta tempat yang serupa berada berdekatan. 00:02:36.800 --> 00:02:39.840 Dalam ruang vektor, konsep yang serupa juga berada berdekatan. 00:02:40.080 --> 00:02:42.780 Vektor untuk raja dan vektor untuk ratu berada saling berdekatan 00:02:42.780 --> 00:02:44.420 karena keduanya mewakili ide yang berkaitan. 00:02:45.140 --> 00:02:47.540 Vektor untuk raja dan vektor untuk apel berada berjauhan. 00:02:48.280 --> 00:02:50.620 Komputer tidak tahu arti raja dalam pengertian manusia, 00:02:50.860 --> 00:02:54.780 tetapi ia bisa mengukur jarak antara koordinatnya dengan koordinat kata atau dokumen lain. 00:02:55.480 --> 00:02:56.960 Ini seperti memiliki GPS untuk ide. 00:02:57.600 --> 00:03:00.540 Sistem tahu seberapa jauh jarak antar konsep hanya dengan melihat angka-angkanya. 00:03:01.100 --> 00:03:02.420 Saat Anda mencari menggunakan vektor, 00:03:02.820 --> 00:03:04.640 sistem mengubah query Anda menjadi embedding. 00:03:04.640 --> 00:03:07.720 Kemudian ia menemukan dokumen yang embeddingnya paling dekat dengan milen. 00:03:08.360 --> 00:03:10.840 Ia menemukan hal-hal yang secara semantik serupa yang berbagi makna, 00:03:10.980 --> 00:03:12.180 bukan sekadar kosa kata. 00:03:12.960 --> 00:03:15.320 Bayangkan Anda sedang mencari dokumen tentang cara-cara mengatasi laptop. 00:03:15.500 --> 00:03:18.860 Dengan pencarian kata kunci, Anda harus mengetik kata macet atau hang secara tepat. 00:03:19.560 --> 00:03:22.280 Namun dengan pencarian vektor, Anda bisa mengetik komputer saya terus terkunci 00:03:22.280 --> 00:03:23.740 dan sistem akan menemukan dokumen yang tepat. 00:03:24.140 --> 00:03:25.520 Itulah kekuatan dari memahami makna. 00:03:26.220 --> 00:03:27.780 Mari kembali ke contoh pencarian kita yang rusak tadi. 00:03:28.220 --> 00:03:30.240 Seorang pengguna mengetik laptop saya terus macet. 00:03:30.240 --> 00:03:34.800 Dengan pencarian vektor, sistem bisa menampilkan artikel tentang sistem yang hang saat rapat teams 00:03:34.800 --> 00:03:37.080 meskipun tidak ada satupun kata tersebut dalam query. 00:03:37.880 --> 00:03:38.220 Mengapa? 00:03:38.620 --> 00:03:42.060 Karena makna sistem hang sangat dekat dengan komputer macet dalam ruang vektor. 00:03:43.340 --> 00:03:45.420 Konsep-konsep ini berada saling berdekatan di peta tersebut. 00:03:46.020 --> 00:03:48.620 Sistem tidak peduli dengan kata yang tepat, ia peduli dengan apa yang Anda maksud. 00:03:49.220 --> 00:03:49.800 Tidak terobosan. 00:03:50.280 --> 00:03:52.620 Komputer mulai memahami maksud, bukan sekadar ejaan. 00:03:53.160 --> 00:03:55.860 Mereka menemukan jawaban yang mungkin terlewatkan sepenuhnya oleh pencarian kata kunci. 00:03:56.160 --> 00:03:57.640 Namun pencarian vektor juga memiliki kelemahan. 00:03:57.640 --> 00:04:00.540 Pencarian ini bisa melewatkan kecocokan tepat yang sangat krusial. 00:04:01.420 --> 00:04:06.300 Jika seorang teknisi mencari kode kesalahan spesifik seperti GalatX8000070570, 00:04:06.660 --> 00:04:09.820 pencarian vektor mungkin memprioritaskan dokumen tentang kesalahan disk 00:04:09.820 --> 00:04:13.880 atau kerusakan sistem file, alih-alih dokumen tepat yang membedah kode tersebut. 00:04:14.780 --> 00:04:16.160 Metode ini mengorbankan pesisi demi pemah. 00:04:16.560 --> 00:04:17.440 Jadi kita punya dua metode. 00:04:17.820 --> 00:04:19.300 Pencarian kata kunci sangat bagus untuk resisi. 00:04:19.600 --> 00:04:22.300 Metode ini sangat akurat untuk istilah exact ID product dan nomor kontrol. 00:04:22.600 --> 00:04:23.840 Pencarian vektor sangat bagus untuk mat. 00:04:23.840 --> 00:04:28.120 Metode ini menemukan jawaban yang tepat bahkan soal Anda tidak menggunakan kata-kata yang masih memiliki kelemahan. 00:04:28.700 --> 00:04:29.960 Dan itu menimbulkan pertanyaan jelas. 00:04:30.320 --> 00:04:33.340 Bagaimana jika Anda bisa menggabungkan kedua pendekatan dan pendekatan dan mendapatkan keunggulan? 00:04:33.720 --> 00:04:34.520 Perobosan hibrida. 00:04:34.860 --> 00:04:36.560 Pencarian hibrida adalah yang terbaik dari kedua dunia. 00:04:37.020 --> 00:04:39.780 Metode ini menjalankan pencarian kata kunci dan vektor secara bersamaan, 00:04:40.000 --> 00:04:41.920 lalu menggabungkan hasilnya menjadi satu daftar peringkat. 00:04:42.460 --> 00:04:44.920 Alih-alih memiliki salah satu sistem menggunakan metode yang disebut 00:04:44.920 --> 00:04:47.040 reciprocal rank vision atau RRF. 00:04:47.040 --> 00:04:48.100 Inilah cara kerjanya. 00:04:48.460 --> 00:04:52.640 RRF melihat peringkat setiap dokumen dalam hasil kata kunci dan peringkatnya dalam hasil vektor. 00:04:53.280 --> 00:04:54.120 Pemberikan skor gabungan. 00:04:54.640 --> 00:04:56.640 Jika semua dokumen bagus di keduanya, ia akan mendapat ingat. 00:04:56.980 --> 00:04:59.060 Ini seperti mengambil dua pendapat ahli dan merata-rata-nganya. 00:04:59.600 --> 00:05:01.860 Jawaban akhirnya lebih andal daripada salah satu metode saja. 00:05:02.520 --> 00:05:06.200 Hal ini penting karena pencarian kata kunci dan vektor memiliki keunggulan yang berbeda secara mendasar. 00:05:06.700 --> 00:05:08.340 Pencarian kata kunci unggul dalam kecocokan yang eksat. 00:05:08.340 --> 00:05:12.160 Ini adalah andal Anda untuk ID produk, nomor kontrak, nama spesifik, dan kode kesalahan. 00:05:12.680 --> 00:05:13.620 Metode ini tepat diprediksi. 00:05:14.380 --> 00:05:18.760 Pencarian vektor unggul dalam kemiripan semantik menemukan dokumen yang berbagi matemat dengan query Anda 00:05:18.760 --> 00:05:20.400 meskipun kata-kata persisnya tidak muncul. 00:05:21.220 --> 00:05:22.960 Bersama-sama mereka menutupi kelemahan satu sama lain. 00:05:23.400 --> 00:05:26.340 Sistem menangkap kecocokan eksak dan kecocokan konsep dalam satu query. 00:05:26.820 --> 00:05:27.940 Itulah kekuatan yang sebelumnya. 00:05:28.000 --> 00:05:29.060 Dan ini bukan sekadar teori. 00:05:29.900 --> 00:05:35.420 Penelitian tentang pencarian hibrida perusahaan menunjukkan tingkat presisi pengambilan 70 hingga 80 persen tergantung pada kumpulan data. 00:05:35.420 --> 00:05:39.560 Itu sekitar 15 hingga 20 persentase lebih tinggi daripada yang Anda dapatkan dengan pencarian vektor. 00:05:39.880 --> 00:05:42.800 Perbedaannya signifikan dan terlihat dalam hasil bisnis yang nyata. 00:05:43.380 --> 00:05:44.560 Ambil contoh platform akuntansi sero. 00:05:45.120 --> 00:05:49.240 Mereka menerapkan pencarian hibrida dalam pengalaman dukungan pelanggan mereka melalui perusahaan bernama Coveo. 00:05:49.800 --> 00:05:53.220 Dalam tiga bulan, mereka melihat peningkatan 20 persen dalam resolusi sualayan. 00:05:53.760 --> 00:05:57.000 Pelanggan menemukan jawaban sendiri lebih sering tanpa perlu menghubungi dukungan. 00:05:57.980 --> 00:06:02.700 Klien lain dalam studi kasus yang sama melihat pengurangan waktu penyelesaian hingga 40 persen untuk kasus dukungan. 00:06:02.700 --> 00:06:08.520 Itu berarti agen menemukan informasi yang tepat lebih cepat, pelanggan mendapatkan jawaban lebih kilat, dan biaya dukungan menurun. 00:06:09.040 --> 00:06:11.700 Itu bukan sekadar fitur bagus, melainkan dampak terukur pada laba perusahaan. 00:06:12.600 --> 00:06:13.180 Ini poin kuncinya. 00:06:13.600 --> 00:06:17.620 Pencarian hibrida bukan sekadar peningkatan atau centang pada daftar fitur, melainkan jawab lebih baik secara terukur. 00:06:18.000 --> 00:06:20.780 Pencarian ini memberikan presisi yang lebih baik, perolehan yang lebih baik, dan hasil penggunaan. 00:06:21.160 --> 00:06:25.200 Kombinasi pendekatan inilah yang membuat Azure AI Search begitu hebat untuk aplikasi modern. 00:06:25.200 --> 00:06:30.440 Namun, ada teknologi lain yang dibuka oleh kombinasi ini yang sedang mendapat banyak perhatian saat ini. 00:06:31.000 --> 00:06:32.800 Teknologi ini disebut RAG, koneksi RAG. 00:06:33.020 --> 00:06:34.120 Jadi mari kita bicara tentang RAG. 00:06:34.640 --> 00:06:36.600 RAG adalah singkatan dari Trivial Augmented Generous. 00:06:36.920 --> 00:06:39.120 Istilah yang cukup panjang, namun ini ada definisi paling sederhananya. 00:06:39.480 --> 00:06:43.020 Ini adalah kerangka kerja yang memberi asisten AI akses ke informasi yang tidak mereka pelajari saat pelatih. 00:06:43.680 --> 00:06:47.840 Model bahasa besar seperti GPT tahu banyak tentang sejarah, sains, dan pemrograman. 00:06:47.840 --> 00:06:55.040 Tetapi mereka tidak tahu dokumen internal, kebijakan, riwayat pelanggan, atau prosedur spesifik tim Anda, atau prosedur spesifik tim Anda. 00:06:55.280 --> 00:06:59.260 Kebanyakan orang berpikir Anda bisa langsung memasukkan semua pengetahuan internal itu ke dalam modelnya. 00:06:59.440 --> 00:06:59.980 Itu tidak berhasil. 00:07:00.340 --> 00:07:01.760 Cara itu mahal dan sulit untuk diperbarukan. 00:07:02.040 --> 00:07:03.340 RAG mengatasi masalah yang cerdas. 00:07:03.660 --> 00:07:09.380 Alih-alih memaksakan semuanya ke dalam model, Anda mengambil informasi yang relevan dari basis pengetahuan saat seseorang mengajukan pertanyaan. 00:07:09.920 --> 00:07:13.720 Anda mengambil query pengguna, mencari data internal Anda, menemukan dokumen yang paling relevan, 00:07:13.720 --> 00:07:17.040 lalu memasukkan konteks tersebut ke dalam LLM bersama dengan pertanyaan aslinya. 00:07:17.040 --> 00:07:19.740 LLM kemudian menghasilkan jawaban yang dihasilkan pada data Anda. 00:07:20.200 --> 00:07:20.860 Itulah keajaibannya. 00:07:21.280 --> 00:07:24.260 Nah, Azure AI Search adalah bagian pencarian dari persamaan tersebut. 00:07:24.820 --> 00:07:28.000 Ini adalah mesin yang menemukan dokumen yang tepat agar LLM dapat menjawab dengan akurat. 00:07:29.060 --> 00:07:32.500 Tanpa lapisan pencarian yang solid, sistem RAG hanya akan sebagus dokumen yang ditemukannya. 00:07:33.300 --> 00:07:37.740 Dan disinilah pencarian hibrida benar-benar unggul karena QR RAG seringkali berupa pertanyaan bahasa alami, 00:07:37.860 --> 00:07:40.940 sementara jawabannya sering berada dalam dokumen yang menggunakan terminologi yang sama sekali berbeda. 00:07:41.160 --> 00:07:43.340 Ijinkan saya memberikan beberapa angkapan yang menunjukkan perbedaannya. 00:07:43.340 --> 00:07:52.480 Sebuah studi tentang pencarian aplikasi perusahaan menemukan bahwa kerangka kerja RAG hibrida meningkatkan akurasi pencarian top-kase sebesar 18 hingga 25 kali lipat dibandingkan pencarian kata kunci saja. 00:07:53.020 --> 00:07:56.180 Akurasi penyelesaian tugas alur kerja meningkat hingga 21 kali lipat. 00:07:56.180 --> 00:08:02.060 Artinya, pengguna jauh lebih mungkin berhasil menyelesaikan tugas yang kompleks jika didukung oleh sistem RAG yang menggunakan pencarian hibrida. 00:08:03.060 --> 00:08:10.900 Secara keseluruhan, sistem RAG yang diimplementasikan dengan benar dapat meningkatkan akurasi pencarian rata-rata sebesar 85% dengan beberapa doma yang khusus mendekati akurasi 99%. 00:08:10.900 --> 00:08:18.920 Dan karena LLM menghasilkan jawaban berdasarkan konteks yang diambil alih-alih tebakannya sendiri, sistem RAG menunjukkan sekitar 40% pengurangan dalam respons halusinasi. 00:08:19.600 --> 00:08:22.820 Inilah sebabnya Azure AI Search sangat penting untuk membangun agen AI dan kopilot. 00:08:22.820 --> 00:08:28.220 Azure AI Search menyediakan pengambilan berbasis fakta yang kokoh sehingga membuat LLM dapat dipercaya dalam konteks bisnis. 00:08:28.580 --> 00:08:35.380 Jika Anda membangun asisten yang perlu menjawab pertanyaan secara akurat dan mencantumkan sumbernya, pencarian hibrida ditambah RAG adalah arsitektur yang akan Anda piwi. 00:08:35.720 --> 00:08:38.120 Jadi, pencarian hibrida dan RAG adalah kombinasi yang kuat. 00:08:38.800 --> 00:08:40.380 Namun, seperti apa bentuknya dalam praktik? 00:08:41.620 --> 00:08:44.460 Dampak di dunia nyata. Jadi, di mana hal ini berlaku ternyata dalam praktik? 00:08:44.860 --> 00:08:46.120 Izinkan saya memberikan beberapa contoh. 00:08:46.380 --> 00:08:47.920 E-commerce mungkin adalah contoh yang paling familiar. 00:08:48.700 --> 00:08:50.860 Seorang pelanggan mengetik sepatu lari nyaman ke dalam bilapnya. 00:08:50.860 --> 00:08:55.860 Daftar produk mungkin menyebutnya alas kaki atletik berbantalan karena tim pemasaran memilih kata-kata yang berbeda. 00:08:56.740 --> 00:08:58.860 Pencarian kata kunci saja akan sepenuhnya melewatkan kecocokan tersebut. 00:08:59.660 --> 00:09:04.860 Dengan Azure AI Search, sistem memahami bahwa nyaman dan berbantalan memiliki arti yang kurang lebih sama dalam konteks ini. 00:09:05.380 --> 00:09:08.100 Sistem menampilkan produk yang tepat bahkan saat kata-katanya tidak sama persis. 00:09:08.420 --> 00:09:12.000 Itulah pelanggan yang menemukan apa yang mereka inginkan alih-alih meninggalkan situs dengan rasa first. 00:09:12.180 --> 00:09:13.820 Portal dukungan pelanggan bekerja dengan cara yang sama. 00:09:14.260 --> 00:09:16.800 Bayangkan seorang pelanggan, bagaimana cara membatalkan langgan saat. 00:09:16.800 --> 00:09:20.320 Kebijakan yang relevan mungkin berjudul Terminasi Perjanjian Layanan. 00:09:20.860 --> 00:09:25.400 Pencarian hibrida menemukan dokumen yang tepat tersebut melalui pencocokan kata kunci pada terminologi hukum, 00:09:25.540 --> 00:09:30.020 tetapi juga menampilkan FAQ terkait tentang mengakhiri paket Anda lebih awal melalui kemiripan semantik. 00:09:30.420 --> 00:09:30.540 Fan. 00:09:31.820 --> 00:09:35.340 Pelanggan mendapatkan jawaban yang komprehensif alih-alih harus menggali lima artikel berbeda. 00:09:36.300 --> 00:09:37.920 Pengambilan dokumen hukum adalah contoh lainnya. 00:09:37.920 --> 00:09:42.200 Pengacara perlu mencari kontrak berdasarkan nomor klausul dan referensi bagian yang tepat. 00:09:42.780 --> 00:09:44.100 Itu adalah ranah kata kunci murni, 00:09:44.220 --> 00:09:46.880 tetapi mereka juga perlu menemukan bahas yang serupa di berbagai perjanjian, 00:09:46.980 --> 00:09:48.220 bahkan ketika kata-katanya bervariasi. 00:09:48.820 --> 00:09:50.920 Pencarian hibrida menangani keduanya dalam satu query, 00:09:51.080 --> 00:09:52.280 dan di industri yang diatur ketat, 00:09:52.380 --> 00:09:55.620 kemampuan untuk melacak mengapa hasil muncul sangat penting untuk kepatuhan. 00:09:56.180 --> 00:09:57.560 Basis pengeteral juga mendapatkan manfaat. 00:09:57.560 --> 00:10:02.160 Seorang karyawan yang mencari kebijakan cuti mendapatkan dokumen resmi HR, 00:10:02.340 --> 00:10:06.020 tetapi juga email terkait dari tim hukum tentang sisa hari cuti dan pembaruan terkini 00:10:06.020 --> 00:10:08.160 yang diposting di intranet perusahaan. 00:10:09.420 --> 00:10:11.780 Pencarian memahami bahwa semua ini terhubung ke pertanyaan sama. 00:10:12.580 --> 00:10:14.040 Manufaktur adalah contoh yang kurang jelas, 00:10:14.160 --> 00:10:15.100 namun merupakan contoh yang kuat. 00:10:15.860 --> 00:10:18.840 Seorang teknisi mengetik perbaikan motor panas berlebih ke dalam antarmuka pencarian. 00:10:19.600 --> 00:10:22.060 Sistem mengembalikan bagian pemecahan masalah dari menu peralatan 00:10:22.060 --> 00:10:24.880 ditambah diagram pindahian yang menunjukkan bagian-bagian yang relevan. 00:10:25.520 --> 00:10:27.080 Meskipun diagram tersebut berupa gambar, 00:10:27.080 --> 00:10:30.300 Azure AI Search dapat mengekstrak dan mengekstrak dan mengindeks konten teksnya 00:10:30.300 --> 00:10:31.640 sehingga muncul dalam hasil pencarian. 00:10:31.960 --> 00:10:34.600 Penang merah dari semua contoh ini adalah data tidak terstruktur. 00:10:35.440 --> 00:10:37.800 PDF dokumen Word, tiga dukungan email gambar pindahian. 00:10:38.540 --> 00:10:40.560 Query basis data tradisional dan pencarian kata kunci 00:10:40.560 --> 00:10:42.220 tidak pernah dirancang untuk jenis data seperti itu. 00:10:42.800 --> 00:10:44.800 Azure AI Search dibangun khusus untuk dunia ini 00:10:44.800 --> 00:10:47.640 dan semakin Anda melihatnya, semakin jelas bahwa pencarian hibrida 00:10:47.640 --> 00:10:48.860 bukan sekadar fitur pelengkap. 00:10:49.400 --> 00:10:51.800 Ini adalah bagian mendasar dari cara aplikasi modern dibangun. 00:10:52.740 --> 00:10:53.600 Oke, marketingannya bersatu. 00:10:54.200 --> 00:10:55.800 Jadi bagaimana semua ini sebenarnya bekerja di balik layar? 00:10:55.800 --> 00:10:58.520 Azure AI Search memiliki tiga blok penyusun utama. 00:10:59.080 --> 00:11:01.140 Sumber data, pengindeks, dan indeks pencarian. 00:11:02.060 --> 00:11:03.900 Sumber data adalah tempat informasi yang Anda berada. 00:11:04.420 --> 00:11:07.620 Bisa berupa blok storage, database Azure SQL, Cosmos DB, 00:11:07.980 --> 00:11:08.880 atau bahkan SharePoint. 00:11:09.640 --> 00:11:11.380 Ini adalah bahan mentah yang perlu dibuat agar dapat dicari. 00:11:11.920 --> 00:11:14.180 Anggap saja seperti tumpukan dokumen yang menunggu untuk diatur. 00:11:14.880 --> 00:11:17.500 Pengindeks adalah saluran yang membaca data dari sumber tersebut, 00:11:18.020 --> 00:11:21.220 mengekstrak kontennya, menerapkan pengayaan AI yang telah Anda konfigurasikan, 00:11:21.580 --> 00:11:22.600 lalu membangun indeks pencarian. 00:11:22.600 --> 00:11:24.680 Berikut cara sederhana untuk membayangkan. 00:11:25.320 --> 00:11:28.080 Bayangkan seorang pustakawan berjalan ke gudang yang penuh dengan buku. 00:11:28.620 --> 00:11:30.820 Mereka membaca setiap buku, membuat catatan terperinci, 00:11:31.040 --> 00:11:32.600 mengidentifikasi tema dan entitas utama, 00:11:32.700 --> 00:11:34.260 lalu mengatur semuanya ke dalam katalog kartu. 00:11:34.760 --> 00:11:37.000 Proses membaca dan mencatat itulah yang disebut proses pengindeks. 00:11:37.100 --> 00:11:38.920 Indeks pencarian adalah katalog kartu tersebut. 00:11:39.200 --> 00:11:40.180 Itu bukanlah buku-bukunya sendiri. 00:11:40.880 --> 00:11:42.660 Itu adalah sistem terstruktur dan teroptimasi 00:11:42.660 --> 00:11:45.280 yang mungkinkan Anda menemukan apa yang Anda butuhkan dalam hitungan mili detik. 00:11:45.280 --> 00:11:48.320 Saat Anda mengetik query, sistem tidak kembali ke dokumen asli 00:11:48.320 --> 00:11:49.440 dan memindainya, MIT. 00:11:50.240 --> 00:11:51.860 Sebaliknya, sistem mencari di indeks 00:11:51.860 --> 00:11:53.980 yang sudah mengetahui dengan tepat di mana lokasi segalanya. 00:11:54.580 --> 00:11:56.720 Praorganisasi ini disebut indeks terbalik, inverted indicate. 00:11:57.260 --> 00:11:59.560 Alihalih menyimpan dokumen dengan daftar kata yang dikandungnya, 00:11:59.680 --> 00:12:01.480 Anda menyimpan kata dengan daftar dokumen yang memuat. 00:12:01.940 --> 00:12:03.400 Itu berarti saat Anda mencari sebuah istilah, 00:12:03.500 --> 00:12:04.680 Anda langsung melompat ke tempat yang terbaik. 00:12:05.120 --> 00:12:06.320 Tidak perlu membalap balik setiap halaman. 00:12:06.820 --> 00:12:08.220 Hasilnya adalah peningkatan kecepatan masif. 00:12:08.660 --> 00:12:10.780 Alihalih harus memindai setiap dokumen yang membutuhkan waktu. 00:12:10.780 --> 00:12:12.360 Lebih lama seiring bertambahnya data, 00:12:12.640 --> 00:12:14.040 Anda langsung melompat ke lokasi yang tepat. 00:12:14.820 --> 00:12:16.940 Dengan jutaan dokumen, perbedaan tersebut adalah perbedaan 00:12:16.940 --> 00:12:18.760 antara pencarian yang memakan waktu beberapa detik 00:12:18.760 --> 00:12:20.020 dan yang memakan waktu beberapa detik. 00:12:20.580 --> 00:12:22.540 Jadi sekarang Anda memahami apa itu Azure Eye Search, 00:12:22.660 --> 00:12:23.760 bagaimana komponen intinya bersatu, 00:12:23.820 --> 00:12:25.360 dan mengapa pencana hibrida mengubah segalanya. 00:12:26.040 --> 00:12:28.240 Mari kita simpulkan dengan beberapa hal yang bisa Anda lakukan dengan ini. 00:12:28.940 --> 00:12:30.120 Pertama, pahami data Anda. 00:12:30.600 --> 00:12:33.140 Jika datanya sudah terstruktur seperti tabel produk di SQL, 00:12:33.360 --> 00:12:34.660 catatan pelanggan dalam database, 00:12:34.880 --> 00:12:36.780 atau apapun dengan baris dan kolom yang rapi, 00:12:37.020 --> 00:12:38.480 Anda bisa langsung membuat query dengan SQL. 00:12:38.480 --> 00:12:41.440 Azure Eye Search dibangun untuk teks yang tidak terstruktur, 00:12:41.880 --> 00:12:44.020 yaitu PDF, email, dokumen Word, dan tiket dukungan. 00:12:44.760 --> 00:12:46.040 Disitulah teknologi ini memberikan nilainya. 00:12:46.360 --> 00:12:49.460 Kedua, jika Anda membangun aplikasi RHG atau asisten AI, 00:12:49.760 --> 00:12:51.460 Azure Eye Search dengan pencarian hibrida 00:12:51.460 --> 00:12:53.740 adalah mesin pengambilan data yang Anda butuhkan di baliknya. 00:12:54.180 --> 00:12:56.300 Teknologi ini memberikan kecocokan kata kunci yang tepat 00:12:56.300 --> 00:12:58.160 untuk presisi dan pemahaman semantik untuk konteks. 00:12:58.420 --> 00:13:00.420 Kombinasi itu menghasilkan jawaban yang lebih andal 00:13:00.420 --> 00:13:02.760 dan mudah dikutip daripada menggunakan salah satu pendekatan saja. 00:13:03.480 --> 00:13:05.300 Ketiga, jangan buat pengaturannya menjadi rumah. 00:13:05.860 --> 00:13:07.540 Portal Azure memiliki wizard untuk mengimpor data. 00:13:07.540 --> 00:13:09.060 Hubungkan penyimpanan blop Anda, 00:13:09.180 --> 00:13:10.540 konfigurasikan beberapa pengaturan, 00:13:10.660 --> 00:13:11.880 dan biarkan pengindeks pertama Anda. 00:13:12.240 --> 00:13:13.980 Anda bisa menjalankan pertama Anda dalam pertukungan yang satu-satunya. 00:13:14.220 --> 00:13:15.860 Jadi itulah Azure Eye Search dalam bahasa yang sederhana. 00:13:16.200 --> 00:13:17.880 Layanan ini mengambil informasi yang berantakan 00:13:17.880 --> 00:13:18.720 dan tidak terstruktur, 00:13:18.880 --> 00:13:21.000 lalu membuatnya menjadi pengetahuan yang siap dicari oleh AI. 00:13:21.300 --> 00:13:22.320 Terima kasih telah bergabung dengan saya. 00:13:22.520 --> 00:13:24.040 Pelangganan layanan, sampai jumpa di episode berikut. 00:13:24.040 --> 00:13:25.560 Terima kasih telah menonton!