Platform data untuk beban kerja AI di Azure

Platform data adalah serangkaian teknologi terintegrasi yang dirancang untuk mengelola persyaratan beban kerja dengan menyerap data sumber lalu memfilter, menggabungkan, dan menyiapkannya untuk dikonsumsi.

Data memiliki karakteristik berbeda yang didasarkan pada penggunaan yang dimaksudkan. Kami sangat menyarankan Agar Anda memahami prinsip-prinsip desain alur data yang baik sebelum Anda menjelajahi kemampuan teknologi yang dijelaskan artikel ini. Untuk informasi selengkapnya, lihat Desain data pelatihan dan Desain data grounding.

Platform ini juga memenuhi kebutuhan penyimpanan ketika data berada di titik-titik tertentu dalam alur. Jika beban kerja kompleks dan menangani data skala besar, maka Anda dapat mendistribusikan tugas alur di antara berbagai komponen. Untuk kasus penggunaan yang lebih sederhana, evaluasi apakah Anda dapat menggunakan data sumber di penyimpanan yang menawarkan kemampuan gabungan tersebut.

Tanyakan pada diri Anda pertanyaan berikut sehingga Anda dapat menghindari merancang arsitektur yang terlalu kompleks untuk platform data Anda. Selalu yang terbaik untuk menjaga hal-hal sederhana ketika Anda bisa.

• Dapatkah aplikasi Anda memiliki kekuatan prediktif yang diharapkan dengan menyerap data dari satu sumber?
• Apakah pilihan awal penyimpanan data Anda mendukung kemampuan pergudangan data?
• Apakah data sumber sudah dioptimalkan untuk pencarian AI?

Jika Anda menjawab ya untuk pertanyaan-pertanyaan ini, maka Anda dapat menyederhanakan arsitektur Anda dengan memungkinkan aplikasi mengakses sumber data secara langsung. Pendekatan ini menghilangkan kebutuhan akan komponen arsitektur big data seperti penyerapan data, integrasi penyimpanan analitis, dan pemrosesan data eksternal. Jika database sumber dapat menangani pencarian yang diperlukan, mengintegrasikan kemampuan indeks pencarian langsung ke database sumber dapat menjadi pendekatan praktis. Pastikan bahwa sumber dapat menskalakan secara hemat biaya untuk memenuhi tuntutan baru.

Misalnya, Azure Cosmos DB mendukung pencarian vektor, sehingga Anda mungkin tidak memerlukan indeks lain. Kasus penggunaan lain adalah menggunakan replika baca sebagai titik akhir untuk operasi pencarian. Untuk database SQL yang memiliki replika baca, pencarian langsung ke replika ini dapat mengoptimalkan performa. Manfaatkan kemampuan bawaan database untuk menyederhanakan arsitektur sebanyak mungkin.

Arsitektur platform data untuk beban kerja skala besar lebih kompleks.

Menyerap data dari beberapa sumber data dan mengatur pencarian di berbagai platform dapat menjadi kompleks dan tidak efisien. Selain itu, Anda masih memerlukan beberapa ekstrak, transformasi, dan pemuatan (ETL); ekstrak, muat, dan transformasi (ELT); atau ekstrak dan muat (EL) proses untuk membentuk ulang data dalam penyimpanan data. Skenario menjadi lebih kompleks karena data membutuhkan lebih banyak pemrosesan. Anda perlu menambahkan banyak komponen ke arsitektur untuk menangani alur end-to-end dari penyerapan hingga kueri penyajian. Banyak teknologi big data sangat khusus dan dibangun untuk menangani tugas pemrosesan tersebut secara efektif.

Salah satu teknologi tersebut adalah indeks pencarian. Keuntungan utama menambahkan indeks terpisah adalah kemampuannya untuk mengelola kueri secara efisien dan memproses data dalam volume besar yang memiliki throughput tinggi. Fungsi ini membongkar kemampuan AI dari sumber data asli sehingga indeks dapat fokus pada fungsi utamanya, melayani kueri.

Pilih platform berdasarkan fungsionalitas dan tujuan khususnya, dan pertimbangkan persyaratan fungsional dan teknis Anda. Jika arsitektur Anda berkembang untuk menangani kasus penggunaan yang kompleks, fokus pada bagian berikut tentang penyimpanan data agregat, alur pemrosesan, dan indeks pencarian.

Rekomendasi

Berikut adalah ringkasan rekomendasi yang disediakan dalam artikel ini.

Pertimbangan untuk menyimpan data agregat

Dalam beban kerja AI, data bergerak melalui berbagai tahap penyimpanan dan pemrosesan dengan bantuan alur yang mengatur alur kerja di antara tahap ini. Satu tahap kunci adalah penyimpanan data yang berisi data yang diserap dan dikumpulkan dari beberapa sumber. Anda memerlukan penyimpanan ini untuk melakukan pemrosesan hingga data mencapai status yang sesuai untuk pelatihan atau pengindeksan. Fokus utama adalah memastikan bahwa data secara akurat mencerminkan sumbernya.

Platform data untuk penyimpanan ini harus memenuhi standar keamanan yang diterapkan pada sumber data, hemat biaya, dan mendukung integrasi dengan tugas pemrosesan ETL, ELT, dan EL. Opsi bervariasi dari penyimpanan dasar hingga teknologi big data berdasarkan volume data. Pilih penyimpanan ekonomis yang membantu Anda mencapai keandalan dan performa yang cukup.

Bagian berikut ini menyediakan panduan tentang kemampuan yang perlu dipertimbangkan saat Anda memilih teknologi penyimpanan data. Untuk informasi selengkapnya, lihat Alur pemrosesan data.

Persyaratan fungsional

• Dapatkah platform menangani berbagai format data?

  Penyimpanan data harus dapat menyimpan berbagai format data dan mengubahnya ke format lain jika perlu.

  Misalkan alur penyerapan Anda sumber data dari database relasional dan file Parquet, sehingga mendukung data terstruktur dan semistruktur. Anda ingin mengonversi data relasional ke format Parquet sesuai dengan definisi skemanya. Platform data harus memiliki kemampuan bawaan untuk melakukan transformasi tersebut tanpa Anda menulis kode kustom.

• Apakah Anda berharap untuk menyimpan beberapa versi data?

  Nilai dan skema data dapat berubah dari waktu ke waktu, dan mengelola beberapa versi data menjadi penting.

  Sistem sumber biasanya hanya menyimpan data saat ini, bukan data historis. Jika penting untuk menyimpan data historis, Anda mungkin perlu menduplikasi himpunan data besar dari sistem sumber. Dalam hal ini, penerapan versi dapat membedakan data saat ini dari data historis.

  Dalam beberapa kasus, Anda mungkin perlu mempertahankan salinan data untuk kasus penggunaan yang berbeda. Untuk mendukung skenario ini, Anda mungkin perlu membuat fork data. Setiap fork dapat bermutasi secara independen untuk meningkatkan kualitas dan kegunaannya. Platform data Anda harus dapat mempertahankan penerapan versi fork tersebut dengan benar.

  Platform data Anda harus dapat menyimpan versi data dari waktu ke waktu untuk memberikan konteks historis. Konteks ini bermanfaat untuk memproses dan melatih model AI karena menawarkan beberapa pengamatan daripada hanya satu titik waktu.

• Apakah platform memiliki kemampuan manajemen siklus hidup data bawaan?

  Manajemen siklus hidup data (DLM) adalah proses untuk mengelola data dari pembuatannya hingga penghapusannya, dengan tahapan seperti pengumpulan data, penyimpanan, penggunaan, pengarsipan, dan pembuangan.

  Tanpa DLM, data dapat tumbuh secara tidak terkendali, sering mengakibatkan beberapa salinan saat bergerak melalui tingkat kualitas. Platform data harus memiliki kemampuan DLM untuk mencegah pertumbuhan data yang tidak terbatas.

  Pertimbangkan skenario ini. Langkah praproses perlu diulang untuk menyempurnakan data sampai mencapai kualitas yang dapat diterima untuk tujuan pelatihan. Platform data Anda harus dapat menghapus salinan data perantara.

  Dalam beberapa kasus, Anda mungkin perlu menyimpan data untuk audit peraturan. Platform data harus memiliki kemampuan penyimpanan dingin untuk data yang jarang diakses sehingga Anda dapat mengarsipkannya dengan biaya yang lebih rendah.

• Apakah platform mendukung fitur tata kelola data?

  Auditabilitas adalah aspek penting untuk beban kerja AI. Penyimpanan data harus mempertahankan jejak audit yang dapat melacak akses data, memastikan privasi, dan memahami asal data.

  Gunakan fitur kamus data untuk Mengelola metadata, jenis data, tujuan, dan silsilah data. Fitur ini sangat penting ketika data diserap dari beberapa sumber.

• Apakah Anda berencana untuk melakukan pelatihan dengan data produksi?

  Ada dua pendekatan untuk penyebaran, penyebaran model, dan penyebaran kode. Dalam penyebaran model, data produksi digunakan dalam pengembangan, yang memerlukan langkah-langkah keamanan yang ketat. Dalam penyebaran kode, model tidak melihat data produksi sampai dalam produksi. Meskipun penyebaran kode menyederhanakan masalah keamanan di lingkungan pengembangan, penyebaran kode dapat meningkatkan biaya komputasi. Pendekatan apa pun yang Anda pilih, platform data Anda harus mendukung lingkungan terpisah untuk pengembangan dan produksi.

• Apakah Anda memprioritaskan fitur kenyamanan daripada fitur fungsi utama?

  Saat Anda memilih platform data untuk AI atau pembelajaran mesin, jangan hanya mengandalkan kemampuan notebook-nya. Meskipun notebook berguna untuk analisis data eksploratif, buku catatan seharusnya bukan faktor penentu. Sumber daya komputasi untuk notebook biasanya berada di luar cakupan penyimpanan data agregasi. Mereka biasanya terintegrasi dengan sumber daya lain, seperti Azure Pembelajaran Mesin.

Persyaratan nonfungsi

• Berapa banyak data yang Anda harapkan untuk disimpan?

  Beban kerja AI menghasilkan banyak data. Volume dapat meningkat secara signifikan karena beberapa versi dan metadata tambahan.

  Skalabilitas untuk penyimpanan dan throughput penting. Platform data harus secara efisien mengonsumsi data dari alur penyerapan saat menangani volume data, mengelola penulisan bersamaan, dan memastikan performa penulisan individu tanpa degradasi. Kriteria tersebut juga berlaku untuk alur pemrosesan yang membaca, memproses, dan bahkan menulis kembali ke toko.

  Ketika Anda membuat keputusan, pertimbangkan seluruh proses karena penyerapan dan pemrosesan sering terjadi secara bersamaan. Desain harus dapat mengelola pergerakan dan pemrosesan data yang sering. Platform data harus menawarkan tingkat paralelisme yang tinggi untuk memproses data secara efektif.

  Teknologi platform harus memancarkan telemetri yang memberikan wawasan yang bermakna tentang throughput dan performa operasi baca dan tulis.

• Apakah data ini menyimpan komponen penting yang berkontribusi pada target keandalan beban kerja?

  Pilih penyimpanan data yang meningkatkan keandalan dan skalabilitas dengan menggunakan beberapa instans. Penyimpanan big data sering memiliki pengontrol bawaan yang mengatur pemrosesan data di seluruh instans. Jika satu salinan gagal, maka salinan lain dapat digunakan.

  Perlu diingat bahwa data tidak melayani tujuannya jika tidak benar atau dapat diakses. Platform data harus menjamin durabilitas dan memastikan bahwa data tetap utuh. Pastikan API yang mengkueri data dapat diakses. Selain itu, pertimbangkan penyimpanan data yang memiliki fitur cadangan.

  Secara umum, Anda tidak perlu mencadangkan data ini. Namun, jika biaya agregasi data setiap kali dari awal secara signifikan tinggi, Anda dapat mempertimbangkan untuk merehidrasi data dari cadangan.

• Apakah Anda memiliki batasan biaya?

  Jika keandalan dan performa data cukup, pertimbangkan dampak biayanya.

  Sistem harus dioptimalkan untuk menulis sekali, membaca banyak untuk menghindari pengeluaran berlebih pada penyimpanan data. Data pelatihan atau grounding penting tetapi tidak penting seperti database produksi, yang membutuhkan responsivitas instan. Fokusnya adalah menyeimbangkan biaya dengan efisiensi yang cukup untuk memaksimalkan pengembalian investasi.

Persyaratan sebelumnya mungkin secara alami membuat Anda mempertimbangkan untuk menggunakan data lake karena menawarkan DLM, tingkat kualitas, pengamatan, dan dukungan untuk format file yang beragam. Jika beban kerja Anda sudah menggunakan data lake, manfaatkan sumber daya tersebut untuk memenuhi kebutuhan AI Anda. Atau, Anda dapat memilih opsi penyimpanan lain, seperti Azure Blob Storage, yang menyediakan beberapa tingkat DLM, kemampuan pemantauan, dan tingkat transaksi tinggi.

Pertimbangan untuk memproses data

Anda harus memproses data di penyimpanan data agregat untuk meningkatkan utilitasnya di hilir. Alur ETL melakukan tugas ini, yang paling penting pada titik-titik berikut:

• Lapisan penyerapan

  Alur bertanggung jawab untuk mengumpulkan data dari berbagai sumber dan memindahkannya ke penyimpanan data agregat. Selama proses ini, alur biasanya melakukan praproses dasar dan bahkan mungkin menyusun data dalam format yang dapat dikueri.

  Untuk meminimalkan kebutuhan akan kode kustom, kami sarankan untuk membongkar sebagian besar tanggung jawab ini ke platform data. Saat Anda memilih teknologi, pertimbangkan karakteristik ETL yang diperlukan untuk mendukung pelatihan dan augmentasi model.

• Lapisan pemrosesan

  Data dari penyimpanan data agregat mengalami pemrosesan ekstensif sebelum dapat digunakan untuk pengindeksan atau kasus penggunaan pelatihan model. Alur pemrosesan memerlukan tingkat keandalan dan penskalaan yang mirip dengan alur penyerapan. Perbedaan utamanya adalah jenis pemrosesan yang dilakukan pada data.

  Proses ini melibatkan pencakupan dan restrukturisasi data yang signifikan. Proses ini mencakup tugas seperti pengenalan entitas, mengintegrasikan data tambahan ke dalam himpunan data, dan melakukan pencarian. Proses ini mungkin juga termasuk menghapus data yang tidak perlu dan menerapkan logika data melalui platform orkestrasi data.

Tahap pemrosesan data dapat menghasilkan berbagai output, yang mendarat di tujuan yang berbeda untuk niat yang berbeda. Tujuan utamanya adalah untuk menyiapkan dan mentransfer data dari penyimpanan data agregat untuk dikonsumsi oleh tujuan akhir. Konsumen dapat menarik data saat diperlukan, atau lapisan pemrosesan dapat mendorong data saat sudah siap.

Bagian berikut memberikan panduan untuk dipertimbangkan saat Anda memilih teknologi pemrosesan data yang memiliki kemampuan ETL.

Persyaratan fungsional

• Apa dukungan untuk menyambungkan ke sumber data?

  Data yang perlu diproses mungkin disimpan dalam database relasional, sumber big data, atau berbagai solusi penyimpanan.

  Sebagian besar teknologi pemrosesan data mendukung integrasi bawaan yang memungkinkan Anda terhubung ke berbagai sumber data tanpa menulis kode. Konektor memiliki fitur seperti kemampuan untuk menyalin data dari sumber ke sink, melakukan pencarian, dan menerapkan beberapa bentuk tata kelola data. Ada alat yang menawarkan fitur seret dan letakkan untuk menghindari pengodean yang tidak perlu.

  Pilih platform data yang memudahkan integrasi dengan sumber data yang diharapkan.

• Dapatkah platform memproses berbagai format data?

  Data mungkin datang dalam berbagai format, seperti data terstruktur seperti database dan JSON, data yang tidak terstruktur seperti gambar dan dokumen, atau data streaming seperti data dari perangkat Internet of Things. Alur harus dapat menangani jenis file yang diharapkan.

• Apakah platform menawarkan fitur untuk persiapan dan cakupan data?

  Anda harus memproses data yang ingin Anda gunakan untuk pelatihan atau augmentasi hingga cocok untuk pelatihan, penyempurnaan, atau pengindeksan. Strategi desain data Anda harus secara eksplisit menguraikan persyaratan.

  Artikel berikut ini menjelaskan pertimbangan spesifik:

  • Mendesain data pelatihan untuk beban kerja AI di Azure
  • Mendesain data grounding untuk beban kerja AI di Azure

  Sebagai bagian dari pembersihan dasar, platform menghapus duplikat, mengisi nilai yang hilang, dan menghilangkan kebisingan asing selama penyerapan. Untuk kasus penggunaan tertentu, seperti menerapkan pola RAG, kami sarankan Anda menurunkan potongan huruf kecil.

  Meskipun langkah-langkah pra-pemrosesan ini diperlukan, platform ini juga harus mendukung manipulasi data kaya yang khusus untuk kebutuhan Anda. Proses ini melibatkan pemuatan, cakupan ulang, dan transformasi data. Untuk model tertentu, platform harus dapat mengkueri sumber eksternal untuk analisis dokumen, seperti kecerdasan dokumen atau alat AI lainnya. Pekerjaan ini diperlukan untuk menyiapkan data dan untuk pengayaan data.

  Jika penyimpanan data Anda mendukung tingkat pemrosesan ini, Anda dapat melokalisasi tahap ini di penyimpanan tanpa memindahkannya ke tempat lain. Jika tidak, Anda memerlukan teknologi eksternal seperti Azure Databricks atau Azure Data Factory. Teknologi ini cocok untuk memindahkan data dan melakukan manipulasi, seperti pemfilteran, mengisi nilai yang hilang, dan menstandarkan casing string. Untuk tugas yang lebih kompleks, platform hosting pekerjaan biasanya diperlukan. Anda dapat menggunakan kumpulan Spark untuk orkestrasi big data.

  Dalam kasus penggunaan tertentu, Anda mungkin ingin eksternalisasi tanggung jawab ini kepada konsumen data. Misalnya, model AI yang menggunakan pembelajaran mesin menawarkan kemampuan pemrosesan pekerjaan untuk membaca, memanipulasi, dan menulis data dengan menggunakan kode Python kustom.

  Contoh lain adalah implementasi RAG. Langkah pemrosesan umum adalah pemotongan, di mana dokumen dibagi menjadi beberapa gugus, dan setiap gugus menjadi baris dalam indeks. Ini juga menyimpan penyematan, yang sering dihasilkan layanan OpenAI, untuk potongan-potongan ini. Dalam pencarian AI, proses ini diatur dalam alur kerja pengindeksan, baik dengan menggunakan OpenAI atau Azure AI Search.

• Apakah ada orkestrator bawaan untuk mengelola alur kerja?

  Tugas pemrosesan bersifat modular dan berjalan sebagai pekerjaan. Platform harus memiliki kemampuan orkestrasi yang memecah alur kerja menjadi langkah atau pekerjaan. Setiap pekerjaan harus ditentukan, dijalankan, dan dipantau secara independen.

  Dalam alur kerja yang kompleks, langkah-langkah tertentu bergantung pada keberhasilan penyelesaian yang sebelumnya. Orkestrator harus menangani dependensi pekerjaan dan memastikan bahwa tugas selesai dalam urutan yang benar.

  Desain data adalah proses berulang, sehingga alat orkestrator harus cukup fleksibel untuk memodifikasi alur kerja dengan mudah. Anda harus dapat menyuntikkan langkah-langkah baru atau menyesuaikan langkah-langkah yang ada tanpa menulis ulang sebagian besar kode.

  Data Factory adalah pilihan populer karena menyediakan kumpulan fitur yang kaya untuk mengelola alur kerja data. Azure Databricks juga dapat mengelola alur kerja yang kompleks dan menjadwalkan dan memantau pekerjaan. Anda juga harus mempertimbangkan implikasi biaya. Misalnya, fitur Azure Databricks mungkin luas, tetapi juga mahal. Opsi alternatif sumber terbuka, seperti Apache NiFi, mungkin lebih hemat biaya.

  Pada akhirnya, alat mana yang Anda pilih tergantung pada apa yang diizinkan organisasi Anda dan keterampilan yang nyaman bagi tim beban kerja.

Persyaratan nonfungsi

Saat Anda memilih alur pemrosesan, sangat penting untuk menyeimbangkan throughput dan pengamatan. Alur harus memproses dan mendaratkan data yang diperlukan dengan andal untuk model atau indeks dalam jangka waktu yang memadai. Ini harus cukup ringan untuk mendukung kebutuhan Anda saat ini dan dapat diskalakan untuk pertumbuhan di masa depan. Tim harus memutuskan berapa banyak yang mereka butuhkan untuk masa depan-bukti platform untuk menghindari utang teknis nanti. Pertimbangan utama termasuk frekuensi dan volume penyerapan data, keandalan proses, dan kebutuhan pengamatan untuk memantau dan mengatasi masalah dengan segera.

• Berapa banyak data yang Anda harapkan untuk diserap?

  Untuk tahap penyerapan dan pemrosesan, pertimbangkan skalabilitas dan kecepatan platform untuk menangani tugas. Misalnya, Anda berharap untuk memuat 10 terabyte data setiap hari ke dalam indeks atau untuk pelatihan model. Platform penyerapan data Anda harus dapat memproses volume sebanyak itu dan dengan throughput yang diharapkan. Dalam hal ini, menggunakan Azure Logic Apps mungkin tidak layak karena dapat gagal di bawah beban seperti itu. Sebaliknya, Data Factory lebih cocok untuk skala pemrosesan data ini.

  Salah satu cara untuk menangani volume tinggi adalah melalui paralelisme karena memungkinkan penanganan dan pemrosesan data yang lebih efisien. Platform seperti Azure Databricks dapat mengatur tugas dengan membuat beberapa instans untuk pekerjaan yang sama dan mendistribusikan beban secara efisien.

  Selain itu, pertimbangkan latensi yang dapat ditoleransi dan kompleksitas pekerjaan. Misalnya, pembersihan data melibatkan validasi dan berpotensi mengganti bidang yang tidak valid atau menutupi informasi sensitif. Tugas-tugas ini, meskipun dasar, memerlukan sumber daya yang signifikan karena setiap baris diproses secara individual, yang menambah waktu keseluruhan.

• Kemampuan pemantauan apa yang Anda butuhkan?

  Alur pemrosesan data harus memiliki kemampuan pemantauan dan memberikan wawasan tentang performa dan status pekerjaan alur.

  Anda harus dapat melacak kemajuan pekerjaan. Misalkan alur menjalankan pekerjaan pembersihan data yang tidak selesai atau selesai sebagian. Mungkin ada dampak hilir pada kualitas data yang modelnya dilatih, yang mungkin memengaruhi daya prediktif.

  Mirip dengan komponen lain dalam beban kerja, Anda harus mengaktifkan log, metrik, dan pemberitahuan pada alur data untuk memahami perilakunya. Kumpulkan dan analisis metrik performa untuk memahami aspek efisiensi dan keandalan.

  Identifikasi celah apa pun dalam telemetri bawaan, dan tentukan pemantauan tambahan apa yang perlu Anda terapkan. Pemantauan ini mungkin melibatkan penambahan pengelogan atau metrik kustom untuk menangkap detail spesifik tentang langkah-langkah pekerjaan.

• Berapa banyak keandalan yang Anda harapkan dari platform pemrosesan data?

  Keandalan alur pemrosesan data bervariasi berdasarkan pilihan platform. Meskipun Logic Apps memiliki kemampuan orkestrasi, mungkin tidak dapat diandalkan seperti Data Factory. Data Factory, yang dihosting pada kluster Azure Kubernetes Service (AKS), mungkin memiliki karakteristik keandalan yang berbeda.

  Penyiapan instans tunggal dianggap sebagai titik kegagalan. Pilih platform yang mendukung fitur keandalan, seperti beberapa instans, untuk memenuhi kebutuhan Anda.

  Platform ini juga harus mendukung fitur ketahanan. Misalnya, orkestrator harus secara otomatis mencoba kembali tugas yang gagal, yang mengurangi kebutuhan akan mulai ulang manual.

  Pemrosesan batch dapat kurang dapat diandalkan daripada inferensi, tergantung pada persyaratan kesegaran dan latensi data. Jika pelatihan terjadi setiap minggu dan pemrosesan membutuhkan waktu satu hari, kegagalan sesekali dapat diterima karena ada cukup waktu untuk mencoba kembali.

• Apakah ada batasan biaya?

  Ketika Anda mempertimbangkan efektivitas biaya dari alur pemrosesan data, penting untuk memilih solusi yang memenuhi kebutuhan Anda tanpa biaya yang tidak perlu. Jika persyaratan Anda tidak membenarkan fitur lanjutan Azure Databricks, opsi yang lebih ekonomis seperti Data Factory mungkin cukup. Selain itu, alat sumber terbuka seperti Apache Airflow atau Apache NiFi dapat memberikan kemampuan yang kuat dengan biaya yang lebih rendah. Kuncinya adalah menghindari pengeluaran berlebih pada fitur yang tidak Anda butuhkan dan memilih platform yang menyeimbangkan fungsionalitas dan efisiensi biaya.

• Apa saja persyaratan keamanan pada alur kerja dan pada data yang Anda proses?

  Jelaskan tentang persyaratan keamanan, privasi, dan residensi data. Misalnya, pertimbangkan persyaratan peraturan geografis apa pun. Mematuhi persyaratan residensi data dengan memastikan bahwa data disimpan dan diproses dalam wilayah tertentu. Anda mungkin perlu menjalankan alur terpisah untuk berbagai wilayah, seperti untuk Eropa dan lainnya untuk Amerika, untuk memenuhi peraturan kepatuhan lokal.

  Platform alur data harus mendukung manajemen identitas dan akses untuk memastikan bahwa hanya identitas resmi yang memiliki akses ke pekerjaan atau langkah-langkah tertentu dalam alur kerja. Misalnya, jika proses ETL Anda terdiri dari beberapa alur kerja, dan salah satunya menangani data yang sangat rahasia, platform harus memungkinkan Anda membatasi akses ke alur kerja tersebut sambil menjaga yang lain dapat diakses. Kemampuan ini membantu Anda memenuhi persyaratan keamanan tanpa memerlukan platform terpisah untuk tingkat sensitivitas data yang berbeda. Idealnya, platform harus memberikan dukungan bawaan untuk isolasi tersebut yang memungkinkan manajemen data yang efisien dan aman.

Alur pemrosesan data dapat menghasilkan data ke indeks pencarian atau alur pelatihan model. Bergantung pada kasus penggunaan, lihat bagian tentang indeks pencarian atau penyimpanan fitur.

Pertimbangan untuk indeks pencarian

Indeks pencarian dirancang untuk menyimpan data kontekstual atau grounding untuk dikirim ke titik akhir inferensi model, bersama dengan prompt. Kedua panggilan, kueri indeks dan pemanggilan titik akhir inferensi, terjadi dalam konteks layanan permintaan HTTP klien yang sama. Tidak seperti proses ETL yang menangani pekerjaan offline dan batch, indeks ini mendukung inferensi real time, yang membutuhkan performa dan keandalan tinggi. Ini khusus untuk kueri AI dan menawarkan fitur seperti pengindeksan dan pemfilteran kata kunci, yang bukan tipikal penyimpanan big data. Tujuannya adalah untuk memiliki penyimpanan data baca-banyak berperforma tinggi, tulis-sekali yang mendukung kueri dadakan dan fuzzy. Penyimpanan data ini dapat memberikan hasil yang relevan tanpa kueri yang tepat.

Persyaratan fungsional

• Jenis pencarian apa yang didukung indeks pencarian?

  Kueri yang diterima sistem pada dasarnya adalah pencarian, dan indeks perlu mendukung kemampuan pencarian yang kaya. Untuk RAG, pencarian vektor tidak dapat dinegosiasikan karena data disimpan sebagai vektor terhitung, atau penyematan, yang digunakan untuk pencarian.

  Pencarian vektor sangat kuat, dan menggabungkannya dengan pemfilteran dan pencarian teks lengkap meningkatkan efektivitas indeks pencarian. Desain data Anda harus memperhitungkan menggabungkan jenis pencarian ini, seperti vektor, pencarian teks lengkap, pemfilteran, dan jenis data khusus seperti lokasi geografis.

  Desain data Anda harus secara eksplisit menyatakan persyaratan tersebut. Untuk informasi selengkapnya, lihat Kueri yang efisien dalam desain data.

• Apakah indeks mendukung data multimodal?

  Pilih teknologi indeks yang mendukung data multimodal. Misalnya, pencarian AI dapat menganalisis email, mengonversi gambar di dalamnya menjadi vektor, dan menyimpan deskripsi dalam indeks. Gunakan fungsi ini untuk mencari di berbagai modalitas konten, termasuk file gambar, video, dan audio.

• Apakah indeks mendukung kemampuan pembaruan otomatis saat data di sumber data berubah?

  Pilih indeks yang memiliki fitur pembaruan otomatis. Jika tidak tersedia, Anda perlu mendeteksi dan mendorong perubahan secara manual ke indeks. Dengan kemampuan ini, pengindeks dapat mendeteksi perubahan dalam sumber data dan menarik pembaruan secara otomatis. Dengan membongkar tanggung jawab ini ke platform, Anda dapat mengurangi overhead operasional dan menyederhanakan proses pemeliharaan.

Persyaratan nonfungsi

• Dapatkah indeks bekerja dengan data dalam volume besar?

  Indeks harus dapat menangani data dalam jumlah besar, dapat diskalakan, dan berkinerja baik untuk beban kerja pencarian yang berat. Indeks menyimpan data mentah dan semua metadata, pengayaan, dan entitas yang terkait dengannya. Dalam konteks pola RAG, satu dokumen yang dibagi menjadi beberapa gugus dapat mengakibatkan peningkatan volume data yang signifikan.

• Apakah indeks memiliki fitur keandalan bawaan?

  Pertimbangkan perataan antara keandalan titik akhir inferensi, atau model, dan penyimpanan data karena bergantung satu sama lain.

  Proses pencarian melibatkan dua langkah: mengkueri penyimpanan data lalu mengkueri titik akhir inferensi. Kedua langkah tersebut harus memiliki karakteristik keandalan yang sama. Seimbangkan tujuan keandalan Anda di antara kedua komponen untuk memastikan efektivitas pencarian.

  Untuk memastikan ketahanan, beban kerja harus mendukung jumlah pengguna bersamaan yang diharapkan dan memiliki bandwidth yang cukup untuk menangani lonjakan lalu lintas. Idealnya, platform harus bertahan dari pemadaman zona.

  Platform data harus dirancang untuk mencegah penggunaan indeks yang rusak untuk inferensi. Dalam kasus seperti itu, Anda harus dapat membangun kembali indeks dengan mudah. Indeks juga harus mendukung pertukaran yang andal antara indeks dengan menggunakan fitur seperti aliasing untuk meminimalkan waktu henti selama pertukaran indeks. Tanpa fungsionalitas ini, Anda mungkin perlu mengandalkan cadangan indeks. Mengelola cadangan hadir dengan lebih kompleksitas.

  Dari perspektif beban kerja, pahami potensi mode kegagalan atau indikator stres, seperti pembatasan. Misalnya, meskipun sistem biasanya mendukung 50 pengguna bersamaan, sistem mungkin hanya mendukung 30 pengguna selama proses pengindektan ulang yang berjalan sebagai pekerjaan latar belakang. Dalam hal ini, waktu pekerjaan latar belakang menjadi penting. Saat Anda mengevaluasi throughput indeks, sertakan kueri front-end dan pekerjaan back-end.

• Apa pendorong biaya utama dari teknologi ini?

  Saat Anda memodelkan biaya, perkirakan pengeluaran yang terkait dengan volume data, jumlah kueri, dan throughput indeks yang diharapkan. Perlu diingat bahwa indeks sebagian besar adalah platform as a service (PaaS), di mana harga diabstraksi. Tingkat penelitian dan kemampuannya untuk menghindari pembayaran berlebih untuk kapasitas atau fitur yang tidak digunakan.

  Misalnya, AI Search menagih sebagai unit, yang dapat mencakup kapasitas, throughput, dan penyimpanan. Fitur tambahan dapat menyebabkan lebih banyak biaya. Misalnya, penggunaan fitur ekstraksi gambar yang luas dapat menghasilkan tagihan yang tinggi. Dependensi, seperti fitur set keterampilan, yang berada di luar cakupan indeks tetapi merupakan bagian dari pemrosesan data dapat dikenakan biaya tambahan.

  Membayar untuk tingkat tanpa menggunakan kapasitas penuh dapat menyebabkan pembayaran berlebih. Demikian pula, jumlah tabel dalam indeks Anda dan kemampuan untuk menangani lalu lintas bersamaan memengaruhi biaya.

  Untuk memahami biaya yang terkait dengan Pencarian AI, lihat Merencanakan dan mengelola biaya AI layanan Pencarian.

• Apakah fitur keamanan indeks memenuhi desain data keamanan Anda?

  Desain data Anda harus dengan jelas menentukan persyaratan keamanan dan privasi. Dalam lingkungan pengembangan dan pengujian tempat data produksi nyata digunakan, indeks harus mendukung kemampuan yang mematuhi semua kontrol akses dan langkah-langkah keterlacakan. Tinjau fitur keamanan seperti masking data dan penghapusan informasi pribadi dalam indeks.

  Pilih indeks yang memiliki kemampuan untuk mengidentifikasi klien secara unik melalui ID Microsoft Entra. Indeks pencarian juga harus mendukung kontrol akses tingkat dokumen untuk memungkinkan relevansi kueri berdasarkan identitas. Jika indeks tidak menawarkan fitur tersebut, sesuaikan desain Anda untuk mencapai kemampuan serupa dengan filter kueri. Untuk informasi selengkapnya, lihat Filter keamanan untuk memangkas hasil di Pencarian AI.

  Idealnya, indeks pencarian harus selaras dengan persyaratan keamanan jaringan. Misalnya, jika Anda perlu memfilter lalu lintas keluar ke situs non-Microsoft dan mempertahankan pengamatan, indeks harus menawarkan kontrol keluar. Ini juga harus mendukung segmentasi jaringan. Jika komputasi back-end berada dalam jaringan virtual, konektivitas privat untuk komponen utama, termasuk indeks, sangat penting untuk menghindari paparan internet publik. Indeks harus dengan mudah diintegrasikan dengan jaringan privat dan mendukung identitas terkelola untuk autentikasi melalui ID Microsoft Entra.

Pertimbangan untuk penyimpanan fitur

Untuk model diskriminatif, desain data Anda mungkin menyertakan penyimpanan data perantara yang menyimpan data cache untuk penyempurnaan tambahan. Penyimpanan ini, yang dikenal sebagai penyimpanan fitur, memungkinkan ilmuwan data untuk menyimpan fitur sebagai langkah terakhir, di luar penyimpanan data agregat.

Penyimpanan fitur membantu data katalog untuk beberapa penggunaan dengan menambahkan metadata seperti waktu pembuatan dan asal. Tempat pendaratan menengah ini sangat ideal untuk data pelatihan emas.

toko fitur terkelola di Pembelajaran Mesin adalah opsi penyimpanan data yang terintegrasi dengan MLflow dan alat lainnya. Ini mengambil dan melatih data dari penyimpanan data agregat, menambahkan lapisan yang dapat digunakan kembali untuk silsilah data yang lebih baik dan identifikasi formal dalam Pembelajaran Mesin.

Saat Anda menggunakan penyimpanan fitur, perlakukan seperti penyimpanan data dengan pertimbangan keamanan dan akses.

Pertimbangan untuk penyimpanan data inferensi offline

Dalam beberapa skenario, penggunaan penyimpanan terpisah sesuai untuk pencarian di masa mendatang yang lebih cepat karena inferensi dilakukan pada data yang telah dikumpulkan dan telah dihitung sebelumnya, terlebih dahulu. Dalam proses ini, permintaan pengguna tidak pernah mencapai model AI. Ada beberapa manfaat:

• Peningkatan efisiensi dan pengalaman pengguna dengan mengurangi latensi. Hasil disajikan lebih cepat untuk kueri yang sering, seperti menghasilkan FAQ sebagai hasilnya.
• Panggilan inferensi dapat diskalakan lebih mudah sebagai proses batch tanpa batasan pemrosesan real-time.
• Memungkinkan prevalidasi untuk memastikan akurasi sebelum produksi.
• Karena permintaan tidak diarahkan ke titik akhir gangguan, permintaan tersebut mengurangi beban, berkontribusi pada keandalan beban kerja.
• Bisa lebih hemat biaya karena mengurangi kebutuhan akan perangkat keras berkinerja tinggi yang diperlukan untuk pemrosesan real time.

Namun, pendekatan ini hanya efektif jika Anda dapat memprediksi kemungkinan permintaan dan sebagian besar prediksi diharapkan diminta oleh pengguna. Untuk skenario dengan lebih sedikit permintaan berulang, penyimpanan inferensi offline mungkin kurang efektif.

Penyimpanan data untuk skenario ini harus dioptimalkan untuk operasi baca, harus dapat menangani data dalam volume besar dan memberikan pengambilan yang efisien. Ini juga harus dapat diintegrasikan ke dalam penyimpanan data agregat. Penyimpanan apa pun dengan kemampuan tersebut dapat dipertimbangkan, seperti Azure Cosmos DB, atau bahkan penyimpanan tabel.

Sumber

Artikel ini memberikan detail selengkapnya tentang produk Azure yang kami rekomendasikan sebagai opsi teknologi untuk pertimbangan yang dibahas dalam artikel ini.

• Pembelajaran Mesin
• Penyimpanan Blob
• Azure Databricks
• Data Factory
• Pencarian AI
• Azure Cosmos DB
• Azure Cache untuk Redis

Langkah berikutnya