Arsitektur referensi obrolan end-to-end OpenAI garis besar

Azure OpenAI Service
Azure Machine Learning
Azure App Service
Azure Key Vault
Azure Monitor

Aplikasi obrolan perusahaan memiliki kemampuan untuk memberdayakan karyawan melalui interaksi percakapan. Ini terutama berlaku karena kemajuan berkelanjutan dari model bahasa besar seperti model GPT OpenAI dan model LLaMA Meta. Aplikasi obrolan ini terdiri dari antarmuka pengguna untuk mengobrol, repositori data yang berisi informasi khusus domain yang berkaitan dengan kueri pengguna, model bahasa besar (LLM) yang beralasan atas data khusus domain untuk menghasilkan respons yang relevan, dan orkestrator yang mengawasi interaksi antara komponen ini.

Artikel ini menyediakan arsitektur dasar untuk membangun dan menyebarkan aplikasi obrolan perusahaan yang menggunakan model bahasa besar Azure OpenAI. Arsitektur menggunakan alur prompt Azure Pembelajaran Mesin (AML) untuk membuat alur yang dapat dieksekusi yang mengatur alur kerja dari permintaan masuk ke penyimpanan data untuk mengambil data grounding untuk LLM, bersama dengan logika Python lainnya yang diperlukan. Alur yang dapat dieksekusi disebarkan ke kluster komputasi Azure Pembelajaran Mesin di belakang titik akhir online terkelola.

Hosting antarmuka pengguna obrolan kustom (UI) mengikuti panduan aplikasi web layanan aplikasi dasar untuk menyebarkan aplikasi web yang aman, redundan zona, dan sangat tersedia di Azure App Services. Dalam arsitektur itu App Service berkomunikasi ke layanan Azure PaaS melalui integrasi jaringan virtual melalui titik akhir privat. Demikian juga, App Service UI obrolan berkomunikasi dengan titik akhir online terkelola untuk alur melalui titik akhir privat dan akses publik ke ruang kerja Azure Pembelajaran Mesin dinonaktifkan.

Penting

Artikel ini tidak mencakup komponen atau keputusan arsitektur dari aplikasi web layanan aplikasi dasar. Silakan baca artikel tersebut untuk panduan arsitektur untuk menghosting UI obrolan.

Ruang kerja Pembelajaran Mesin dikonfigurasi dengan isolasi jaringan virtual terkelola yang mengharuskan semua koneksi keluar disetujui. Dengan konfigurasi ini, jaringan virtual terkelola dibuat, bersama dengan titik akhir privat terkelola yang memungkinkan konektivitas ke sumber daya privat seperti Tempat kerja Azure Storage, Azure Container Registry, dan Azure OpenAI. Koneksi privat ini digunakan selama penulisan dan pengujian alur, dan oleh alur yang disebarkan ke komputasi Azure Pembelajaran Mesin.

Tip

Logo GitHub Artikel ini didukung oleh implementasi referensi yang menampilkan implementasi obrolan end-to-end garis besar di Azure. Implementasi ini dapat digunakan sebagai dasar untuk pengembangan solusi kustom dalam langkah pertama Anda menuju produksi.

Sistem

Diagram yang memperlihatkan arsitektur obrolan end-to-end garis besar dengan OpenAI.

Gambar 1: Arsitektur obrolan end-to-end garis besar dengan OpenAI

Unduh file Visio arsitektur ini.

Komponen

Banyak komponen arsitektur ini sama dengan sumber daya dalam aplikasi web layanan aplikasi dasar, karena hosting UI obrolan dalam arsitektur ini mengikuti arsitektur aplikasi web App Service dasar. Komponen yang disorot di bagian ini berfokus pada komponen yang digunakan untuk membangun dan mengatur alur obrolan, dan layanan data dan layanan yang mengekspos LLM.

  • Azure Pembelajaran Mesin adalah layanan cloud terkelola yang digunakan untuk melatih, menyebarkan, dan mengelola model pembelajaran mesin. Arsitektur ini menggunakan beberapa fitur azure Pembelajaran Mesin lain yang digunakan untuk mengembangkan dan menyebarkan alur yang dapat dieksekusi untuk aplikasi AI yang didukung oleh Model Bahasa Besar:
    • Alur permintaan Azure Pembelajaran Mesin adalah alat pengembangan yang memungkinkan Anda membangun, mengevaluasi, dan menyebarkan alur yang menautkan permintaan pengguna, tindakan melalui kode Python, dan panggilan ke LLM. Alur prompt digunakan dalam arsitektur ini sebagai lapisan yang mengatur alur antara prompt, penyimpanan data yang berbeda, dan LLM.
    • Titik akhir online terkelola memungkinkan Anda menyebarkan alur untuk inferensi real time. Dalam arsitektur ini, mereka terbiasa sebagai titik akhir PaaS untuk UI obrolan untuk memanggil alur prompt yang dihosting oleh Azure Pembelajaran Mesin.
  • Azure Storage digunakan untuk mempertahankan file sumber alur perintah untuk pengembangan alur perintah.
  • Azure Container Registry memungkinkan Anda membuat, menyimpan, dan mengelola gambar dan artefak kontainer dalam registri privat untuk semua jenis penyebaran kontainer. Dalam arsitektur ini, alur dimas sebagai gambar kontainer dan disimpan di Azure Container Registry.
  • Azure OpenAI adalah layanan terkelola penuh yang menyediakan akses REST API ke model bahasa besar Azure OpenAI, termasuk set model GPT-4, GPT-3.5-Turbo, dan Embeddings. Dalam arsitektur ini, selain akses model, digunakan untuk menambahkan fitur perusahaan umum seperti jaringan virtual dan tautan privat, dukungan identitas terkelola, dan pemfilteran konten.
  • Azure AI Search adalah layanan pencarian cloud yang mendukung pencarian teks lengkap, pencarian semantik, pencarian vektor, dan pencarian hibrid. Azure AI Search disertakan dalam arsitektur karena Ini adalah layanan umum yang digunakan dalam alur di belakang aplikasi obrolan. Azure AI Search dapat digunakan untuk mengambil dan mengindeks data yang relevan untuk kueri pengguna. Alur prompt mengimplementasikan pola RAG Retrieval Augmented Generation untuk mengekstrak kueri yang sesuai dari perintah, kueri AI Search, dan menggunakan hasilnya sebagai data grounding untuk model Azure OpenAI.

Alur permintaan Azure Pembelajaran Mesin

Back end untuk aplikasi obrolan perusahaan umumnya mengikuti pola yang mirip dengan alur berikut:

  • Pengguna memasukkan perintah dalam antarmuka pengguna obrolan kustom (UI)
  • Perintah tersebut dikirim ke ujung belakang oleh kode antarmuka
  • Niat pengguna (pertanyaan atau arahan) diekstrak dari prompt oleh ujung belakang
  • (opsional) Back end menentukan penyimpanan data yang menyimpan data yang relevan dengan permintaan pengguna
  • Back end meminta penyimpanan data yang relevan
  • Back end mengirimkan niat, data grounding yang relevan, dan riwayat apa pun yang disediakan dalam perintah ke LLM.
  • Back end mengembalikan hasilnya sehingga dapat ditampilkan pada antarmuka pengguna

Back end dapat diimplementasikan dalam sejumlah bahasa dan disebarkan ke berbagai layanan Azure. Dalam arsitektur ini, alur prompt Azure Pembelajaran Mesin dipilih karena memberikan pengalaman yang efisien untuk membangun, menguji, dan menyebarkan alur yang mengatur antara perintah, penyimpanan data back end, dan LLM.

Jaringan

Seiring dengan akses berbasis identitas, keamanan jaringan adalah inti dari arsitektur obrolan end-to-end garis besar menggunakan OpenAI. Dari tingkat tinggi, arsitektur jaringan memastikan hal berikut:

  • Satu titik masuk aman untuk lalu lintas UI obrolan
  • Lalu lintas jaringan difilter
  • Data saat transit dienkripsi secara end-to-end dengan TLS
  • Penyelundupan data diminimalkan dengan menjaga lalu lintas di Azure dengan menggunakan Private Link
  • Sumber daya jaringan dikelompokkan secara logis dan diisolasi satu sama lain melalui segmentasi jaringan

Alur jaringan

Diagram yang memperlihatkan arsitektur obrolan end-to-end garis besar dengan OpenAI dengan nomor alur.

Gambar 2: Alur jaringan untuk arsitektur obrolan end-to-end garis besar dengan OpenAI

Dua alur dalam diagram ini tercakup dalam aplikasi web layanan aplikasi dasar: 1. alur masuk dari pengguna akhir ke UI obrolan dan 2. alur layanan App Service ke Azure PaaS. Lihat artikel tersebut untuk detail tentang alur tersebut. Bagian ini berfokus pada alur titik akhir online Azure Pembelajaran Mesin. Berikut ini merinci alur dari UI obrolan yang berjalan di aplikasi web App Service dasar ke alur yang disebarkan ke Azure Pembelajaran Mesin komputasi:

  1. Panggilan dari UI obrolan yang dihosting App Service dirutekan melalui titik akhir privat ke titik akhir online Azure Pembelajaran Mesin.
  2. Titik akhir online merutekan panggilan ke server yang menjalankan alur yang disebarkan. Titik akhir online bertindak sebagai penyeimbang beban, dan router.
  3. Panggilan ke layanan Azure PaaS yang diperlukan oleh alur yang disebarkan dirutekan melalui titik akhir privat terkelola.

Masuk ke Azure Pembelajaran Mesin

Dalam arsitektur ini, akses publik ke ruang kerja Azure Pembelajaran Mesin dinonaktifkan dan akses dapat terjadi melalui akses privat karena mengikuti titik akhir privat untuk konfigurasi ruang kerja Azure Pembelajaran Mesin. Bahkan, titik akhir privat digunakan di seluruh arsitektur ini untuk melengkapi keamanan berbasis identitas. Misalnya, dengan mengizinkan UI obrolan Anda yang dihosting di App Service untuk terhubung ke layanan PaaS yang tidak terekspos ke Internet publik, termasuk titik akhir Azure Pembelajaran Mesin.

Akses titik akhir privat juga diperlukan untuk menyambungkan ke ruang kerja Azure Pembelajaran Mesin untuk penulisan alur.

Diagram yang memperlihatkan pengguna yang menyambungkan ke ruang kerja Azure Pembelajaran Mesin melalui jump box untuk menulis alur OpenAI dengan nomor alur.

Gambar 3: Alur jaringan untuk penulis alur prompt Azure Pembelajaran Mesin

Diagram menunjukkan penulis alur perintah yang terhubung melalui Azure Bastion ke jump box komputer virtual. Dari jump box tersebut, penulis dapat terhubung ke ruang kerja Pembelajaran Mesin melalui titik akhir privat di jaringan yang sama dengan jump box. Koneksi ke jaringan virtual juga dapat dicapai melalui gateway ExpressRoute atau VPN dan peering jaringan virtual.

Mengalir dari jaringan virtual terkelola Azure Pembelajaran Mesin ke layanan Azure PaaS

Disarankan agar ruang kerja Azure Pembelajaran Mesin dikonfigurasi untuk isolasi jaringan virtual terkelola dengan konfigurasi yang mengharuskan semua koneksi keluar disetujui. Arsitektur ini mengikuti rekomendasi tersebut. Ada dua jenis aturan keluar yang disetujui. Aturan keluar yang diperlukan adalah sumber daya yang diperlukan agar solusi berfungsi, seperti Azure Container Registry dan Azure Storage. Aturan keluar yang ditentukan pengguna adalah untuk sumber daya kustom, seperti Azure OpenAI atau Azure AI Search, yang akan digunakan alur kerja Anda. Anda bertanggung jawab untuk mengonfigurasi aturan keluar yang ditentukan pengguna, sementara aturan keluar yang diperlukan dikonfigurasi saat jaringan virtual terkelola dibuat.

Aturan keluar dapat berupa titik akhir privat, tag layanan, atau FQDN untuk titik akhir publik eksternal. Dalam arsitektur ini, konektivitas ke layanan Azure seperti Azure Container Registry, Azure Storage, Azure Key Vault, layanan Azure OpenAI, dan Azure AI Search terhubung melalui tautan privat. Meskipun tidak dalam arsitektur ini, beberapa operasi umum yang mungkin memerlukan konfigurasi aturan keluar FQDN mengunduh paket pip, mengkloning repositori GitHub, mengunduh gambar kontainer dasar dari repositori eksternal.

Segmentasi dan keamanan jaringan virtual

Jaringan dalam arsitektur ini memiliki subnet terpisah untuk yang berikut ini:

  • Application Gateway
  • Komponen integrasi App Service
  • Titik Akhir Privat
  • Azure Bastion
  • Mesin virtual jump box
  • Pelatihan - tidak digunakan untuk pelatihan model dalam arsitektur ini
  • Penilaian

Setiap subnet memiliki grup keamanan jaringan yang membatasi lalu lintas masuk dan keluar untuk subnet tersebut hanya untuk apa yang diperlukan. Tabel berikut ini memperlihatkan tampilan aturan NSG yang disederhanakan yang ditambahkan garis besar ke setiap subnet. Tabel memberikan nama dan fungsi aturan.

Subnet Masuk Keluar
snet-appGateway Tunjangan untuk IP sumber pengguna UI obrolan kami (seperti internet publik), ditambah item yang diperlukan untuk layanan Akses ke titik akhir privat Azure App Service, ditambah item yang diperlukan untuk layanan.
snet-PrivateEndpoints Izinkan hanya lalu lintas dari jaringan virtual. Izinkan hanya lalu lintas ke jaringan virtual.
snet-AppService Izinkan hanya lalu lintas dari jaringan virtual. Izinkan akses ke titik akhir privat dan Azure Monitor.
AzureBastionSubnet Lihat panduan dalam bekerja dengan akses NSG dan Azure Bastion Lihat panduan dalam bekerja dengan akses NSG dan Azure Bastion
snet-jumpbox Izinkan RDP masuk dan SSH dari subnet Host Bastion. Mengizinkan akses ke titik akhir privat
snet-agents Izinkan hanya lalu lintas dari jaringan virtual. Izinkan hanya lalu lintas ke jaringan virtual.
pelatihan snet Izinkan hanya lalu lintas dari jaringan virtual. Izinkan hanya lalu lintas ke jaringan virtual.
penilaian snet Izinkan hanya lalu lintas dari jaringan virtual. Izinkan hanya lalu lintas ke jaringan virtual.

Semua lalu lintas lainnya secara eksplisit ditolak.

Pertimbangkan poin-poin berikut saat menerapkan segmentasi dan keamanan jaringan virtual.

  • Aktifkan perlindungan DDoS untuk jaringan virtual dengan subnet yang merupakan bagian dari gateway aplikasi dengan IP publik.
  • Tambahkan NSG ke setiap subnet jika memungkinkan. Anda harus menggunakan aturan ketat yang mengaktifkan fungsionalitas solusi penuh.
  • Gunakan kelompok keamanan aplikasi. Grup keamanan aplikasi memungkinkan Anda mengelompokkan NSG, membuat pembuatan aturan lebih mudah untuk lingkungan yang kompleks.

Pemfilteran konten dan pemantauan penyalahgunaan

Layanan Azure OpenAI mencakup sistem pemfilteran konten yang menggunakan ansambel model klasifikasi untuk mendeteksi dan mencegah kategori tertentu dari konten yang berpotensi berbahaya dalam perintah input dan penyelesaian output. Kategori untuk konten yang berpotensi berbahaya ini termasuk kebencian, seksual, bahaya diri sendiri, kekerasan, kata-kata kotor, dan jailbreak (konten yang dirancang untuk melewati batasan LLM). Anda dapat mengonfigurasi ketat apa yang ingin Anda filter kontennya untuk setiap kategori, dengan opsi rendah, sedang, atau tinggi. Arsitektur referensi ini mengadopsi pendekatan yang ketat. Anda harus menyesuaikan pengaturan sesuai dengan kebutuhan Anda.

Selain pemfilteran konten, layanan Azure OpenAI menerapkan fitur pemantauan penyalahgunaan. Pemantauan penyalahgunaan adalah operasi asinkron yang dirancang untuk mendeteksi dan mengurangi instans konten dan/atau perilaku berulang yang menyarankan penggunaan layanan dengan cara yang dapat melanggar kode etik Azure OpenAI. Anda dapat meminta pengecualian pemantauan penyalahgunaan dan peninjauan manusia misalnya jika data Anda sangat sensitif atau jika ada kebijakan internal atau peraturan hukum yang berlaku yang mencegah pemrosesan data untuk deteksi penyalahgunaan.

Keandalan

Arsitektur aplikasi web App Service dasar berfokus pada redundansi zona untuk layanan regional utama. Zona ketersediaan adalah lokasi yang terpisah secara fisik dalam suatu wilayah. Mereka memberikan redundansi dalam wilayah untuk layanan pendukung ketika dua instans atau lebih disebarkan di seluruh wilayah tersebut. Ketika satu zona mengalami waktu henti, zona lain dalam wilayah tersebut mungkin masih tidak terpengaruh. Arsitektur ini juga memastikan cukup instans layanan Azure dan konfigurasi layanan tersebut untuk tersebar di seluruh zona ketersediaan. Silakan lihat garis besar untuk meninjau panduan tersebut.

Bagian ini membahas keandalan dari perspektif komponen dalam arsitektur ini yang tidak dibahas di garis besar App Service, termasuk Azure Pembelajaran Mesin, Azure OpenAI, dan Azure AI Search.

Redundansi zona untuk penyebaran alur

Penyebaran perusahaan biasanya memerlukan setidaknya redundansi zona. Untuk mencapai hal ini di Azure, sumber daya harus mendukung zona ketersediaan dan Anda harus menyebarkan setidaknya instans sumber daya atau mengaktifkan dukungan platform saat kontrol instans tidak tersedia. Saat ini, komputasi Azure Pembelajaran Mesin tidak menawarkan dukungan untuk zona ketersediaan. Untuk mengurangi dampak potensial dari bencana tingkat pusat data pada komponen AML, perlu untuk membangun kluster di berbagai wilayah bersama dengan menyebarkan load balancer untuk mendistribusikan panggilan di antara kluster ini. Anda akan menggunakan pemeriksaan kesehatan untuk membantu memastikan bahwa panggilan hanya dirutekan ke kluster yang berfungsi dengan baik.

Menyebarkan alur prompt tidak terbatas pada azure Pembelajaran Mesin kluster komputasi. Alur yang dapat dieksekusi, menjadi aplikasi kontainer, dapat disebarkan ke layanan Azure apa pun yang kompatibel dengan kontainer. Opsi ini mencakup layanan seperti Azure Kubernetes Service (AKS), Azure Functions, Azure Container Apps (ACA), dan Azure App Service. Masing-masing layanan tersebut mendukung zona ketersediaan. Untuk mencapai redundansi zona untuk eksekusi alur prompt, tanpa kompleksitas tambahan dari penyebaran multi-wilayah, Anda harus menyebarkan alur Anda ke salah satu layanan tersebut.

Berikut ini adalah arsitektur alternatif tempat alur perintah disebarkan ke Azure App Service. App Service digunakan dalam arsitektur ini karena beban kerja sudah menggunakannya untuk UI obrolan dan tidak akan mendapat manfaat dari memperkenalkan teknologi baru ke dalam beban kerja. Tim beban kerja yang memiliki pengalaman dengan AKS harus mempertimbangkan penyebaran di lingkungan tersebut, terutama jika AKS digunakan untuk komponen lain dalam beban kerja.

Diagram yang memperlihatkan arsitektur obrolan end-to-end garis besar dengan OpenAI dengan alur perintah yang disebarkan ke Azure App Service.

Gambar 4: Arsitektur obrolan end-to-end alternatif dengan OpenAI menyebarkan alur prompt ke Azure App Services

Diagram diberi nomor untuk area yang patut dicatat dalam arsitektur ini:

  1. Alur masih ditulis dalam alur prompt Azure Pembelajaran Mesin dan arsitektur jaringan Azure Pembelajaran Mesin tidak berubah. Penulis alur masih terhubung ke pengalaman penulisan ruang kerja melalui titik akhir privat dan titik akhir privat terkelola digunakan untuk menyambungkan ke layanan Azure saat menguji alur.
  2. Garis putus-putus ini menunjukkan bahwa alur yang dapat dieksekusi dalam kontainer didorong ke Azure Container Registry (ACR). Tidak ditampilkan dalam diagram adalah alur yang mengontainerisasi alur dan mendorong ke ACR.
  3. Ada Aplikasi Web lain yang disebarkan ke paket App Service yang sama yang sudah menghosting UI obrolan. Aplikasi Web baru menghosting alur prompt kontainer, yang terletak di paket App Service yang sama yang sudah berjalan minimal tiga instans, yang tersebar di zona ketersediaan. Instans App Service ini terhubung ke ACR melalui titik akhir privat saat memuat gambar kontainer alur permintaan.
  4. Kontainer alur prompt perlu terhubung ke semua layanan dependen untuk eksekusi alur. Dalam arsitektur ini yang akan ke Azure AI Search dan layanan Azure OpenAI. Layanan PaaS yang hanya diekspos ke subnet titik akhir privat yang dikelola AML sekarang juga perlu diekspos di jaringan virtual sehingga garis pandang dapat dibuat dari App Service.

Azure OpenAI - keandalan

Azure OpenAI saat ini tidak mendukung zona ketersediaan. Untuk mengurangi dampak potensial dari bencana tingkat pusat data pada penyebaran model di Azure OpenAI, perlu untuk menyebarkan Azure OpenAI ke berbagai wilayah bersama dengan menyebarkan load balancer untuk mendistribusikan panggilan di antara wilayah tersebut. Anda akan menggunakan pemeriksaan kesehatan untuk membantu memastikan bahwa panggilan hanya dirutekan ke kluster yang berfungsi dengan baik.

Untuk mendukung beberapa instans secara efektif, kami sarankan Anda eksternalisasi file penyempurnaan, seperti ke akun Azure Storage geo-redundan. Ini akan meminimalkan status yang disimpan di layanan Azure OpenAI per wilayah. Penyempurnaan masih perlu dilakukan per instans untuk menghosting penyebaran model.

Penting untuk memantau throughput yang diperlukan dalam hal Token per Menit (TPM) dan Permintaan per Menit (RPM) untuk memastikan Anda telah menetapkan TPM yang cukup dari kuota Anda untuk memenuhi permintaan penyebaran Anda dan mencegah panggilan ke model yang Anda sebarkan dibatasi. Gateway seperti Azure API Management (APIM) dapat disebarkan di depan layanan OpenAI Anda dan dapat dikonfigurasi untuk mencoba kembali jika terjadi kesalahan sementara dan pembatasan. APIM juga dapat digunakan sebagai pemutus sirkuit untuk mencegah layanan kewalahan dengan panggilan, melebihi kuotanya.

Pencarian Azure AI - keandalan

Sebarkan Azure AI Search dengan tingkat harga Standar atau di atasnya di wilayah yang mendukung zona ketersediaan dan menyebarkan tiga replika atau lebih. Replika secara otomatis tersebar merata di seluruh zona ketersediaan.

Pertimbangkan panduan berikut untuk menentukan jumlah replika dan partisi yang sesuai:

  • Ikuti panduan untuk memantau Azure AI Search.
  • Gunakan metrik pemantauan dan log dan analisis performa untuk menentukan jumlah replika yang sesuai untuk menghindari pembatasan dan partisi berbasis kueri untuk menghindari pembatasan berbasis indeks.

Azure Pembelajaran Mesin - keandalan

Jika Anda menyebarkan ke kluster komputasi di belakang titik akhir online terkelola Azure Pembelajaran Mesin, pertimbangkan panduan berikut mengenai penskalaan:

  • Ikuti panduan untuk menskalakan otomatis titik akhir online Anda untuk memastikan kapasitas yang cukup tersedia untuk memenuhi permintaan. Jika sinyal penggunaan tidak cukup tepat waktu karena penggunaan ledakan, pertimbangkan provisi berlebih untuk mencegah dampak keandalan dari terlalu sedikit instans yang tersedia.
  • Pertimbangkan untuk membuat aturan penskalaan berdasarkan metrik penyebaran seperti metrik beban CPU dan titik akhir seperti latensi permintaan.
  • Tidak kurang dari tiga instans harus disebarkan untuk penyebaran produksi aktif.
  • Hindari penyebaran terhadap instans yang digunakan. Sebagai gantinya, sebarkan ke penyebaran baru dan alihkan lalu lintas setelah penyebaran siap menerima lalu lintas.

Catatan

Panduan skalabilitas App Service yang sama dari arsitektur garis besar berlaku jika Anda menyebarkan alur Anda ke Azure App Service.

Keamanan

Arsitektur ini mengimplementasikan jaringan dan perimeter keamanan identitas. Dari perspektif jaringan, satu-satunya hal yang harus dapat diakses dari internet adalah UI obrolan melalui App Gateway. Dari perspektif identitas, UI obrolan harus mengautentikasi dan mengotorisasi permintaan. Identitas terkelola digunakan, jika memungkinkan, untuk mengautentikasi aplikasi ke layanan Azure.

Keamanan jaringan dibahas di bagian jaringan. Bagian ini membahas manajemen identitas dan akses, dan pertimbangan keamanan untuk rotasi kunci dan penyempurnaan model Azure OpenAI.

Pengelolaan identitas dan akses

Panduan berikut memperluas panduan manajemen identitas dan akses di garis besar App Service:

  • Buat identitas terkelola terpisah untuk sumber daya AML berikut, jika berlaku:
    • Ruang kerja - digunakan selama penulisan dan manajemen alur
    • Instans komputasi - digunakan saat pengujian mengalir
    • Titik akhir online - digunakan oleh alur yang disebarkan jika disebarkan ke titik akhir online terkelola
  • Menerapkan kontrol akses identitas untuk UI obrolan menggunakan ID Microsoft Entra

Peran RBAC Azure Pembelajaran Mesin

Ada lima peran default yang dapat Anda gunakan untuk mengelola akses ke ruang kerja Azure Pembelajaran Mesin Anda: AzureML Data Scientist, Operator Komputasi AzureML, Pembaca, Kontributor, dan Pemilik. Bersama dengan peran default ini, ada AzureML Workspace Koneksi ion Secrets Reader dan AzureML Registry User yang memberikan akses ke sumber daya ruang kerja seperti rahasia dan registri ruang kerja.

Arsitektur ini mengikuti prinsip hak istimewa paling sedikit dengan hanya menetapkan peran ke identitas di atas di mana mereka diperlukan. Berikut ini adalah penetapan peran.

Identitas terkelola Cakupan Penetapan peran
Identitas terkelola ruang kerja Grup sumber daya Kontributor
Identitas terkelola ruang kerja Akun Penyimpanan Ruang Kerja Kontributor Data Blob Penyimpanan
Identitas terkelola ruang kerja Akun Penyimpanan Ruang Kerja Storage File Data Privileged Reader
Identitas terkelola ruang kerja Key Vault Ruang Kerja Administrator Key Vault
Identitas terkelola ruang kerja Registri Kontainer Ruang Kerja ACRPush
Identitas terkelola titik akhir online Registri Kontainer Ruang Kerja AcrPull
Identitas terkelola titik akhir online Akun Penyimpanan Ruang Kerja Pembaca Data Blob Penyimpanan
Identitas terkelola titik akhir online Ruang kerja Azure Machine Learning Pembaca Rahasia Koneksi Ruang Kerja AzureML
Identitas terkelola instans komputasi Registri Kontainer Ruang Kerja ACRPull
Identitas terkelola instans komputasi Akun Penyimpanan Ruang Kerja Pembaca Data Blob Penyimpanan

Rotasi kunci

Ada dua layanan dalam arsitektur ini yang menggunakan autentikasi berbasis kunci: Azure OpenAI dan titik akhir online terkelola Azure Pembelajaran Mesin. Karena Anda menggunakan autentikasi berbasis kunci untuk layanan ini, penting untuk:

  • Simpan kunci di penyimpanan aman seperti Azure Key Vault untuk akses sesuai permintaan dari klien resmi (seperti Azure Web App yang menghosting kontainer alur perintah).
  • Menerapkan strategi rotasi utama. Jika Anda memutar kunci secara manual, Anda harus membuat kebijakan kedaluwarsa kunci dan menggunakan kebijakan Azure untuk memantau apakah kunci telah diputar.

Penyempurnaan model OpenAI

Jika Anda menyempurnakan model OpenAI dalam implementasi Anda, pertimbangkan panduan berikut:

  • Jika Anda mengunggah data pelatihan untuk penyempurnaan, pertimbangkan untuk menggunakan kunci yang dikelola pelanggan untuk mengenkripsi data tersebut.
  • Jika Anda menyimpan data pelatihan di penyimpanan seperti Azure Blob Storage, pertimbangkan untuk menggunakan kunci yang dikelola pelanggan untuk enkripsi data, gunakan identitas terkelola untuk mengontrol akses ke data, dan titik akhir privat untuk menyambungkan ke data.

Efisiensi kinerja

Efisiensi performa adalah kemampuan beban kerja Anda untuk diskalakan agar memenuhi permintaan yang diberikan oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Gambaran umum pilar efisiensi performa.

Bagian ini membahas efisiensi performa dari perspektif Azure Search, Azure OpenAI, dan Azure Pembelajaran Mesin.

Azure Search - efisiensi performa

Ikuti panduan untuk menganalisis performa di Azure AI Search.

Azure OpenAI - efisiensi performa

  • Tentukan apakah aplikasi Anda memerlukan throughput yang disediakan atau akan menggunakan model hosting bersama (konsumsi). Throughput yang disediakan menawarkan kapasitas pemrosesan yang dipesan untuk penyebaran model OpenAI Anda, memberikan performa dan throughput yang dapat diprediksi untuk model Anda. Model penagihan ini tidak seperti model hosting bersama (konsumsi), yang merupakan upaya terbaik dan mungkin tunduk pada tetangga yang berisik atau stresor lain di platform.
  • Untuk throughput yang disediakan, Anda harus memantau pemanfaatan yang dikelola provisi

Azure Pembelajaran Mesin - efisiensi performa

Jika menyebarkan ke Titik akhir online Azure Pembelajaran Mesin:

  • Ikuti panduan tentang cara menskalakan titik akhir online secara otomatis agar tetap selaras dengan permintaan, tanpa provisi berlebihan, terutama dalam periode penggunaan rendah.
  • Pilih SKU komputer virtual yang sesuai untuk titik akhir online untuk memenuhi target performa Anda. Anda ingin menguji performa jumlah instans yang lebih rendah dan SKU yang lebih besar vs jumlah instans yang lebih besar dan SKU yang lebih kecil untuk menemukan konfigurasi yang optimal.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Untuk melihat contoh harga untuk skenario ini, gunakan kalkulator harga Azure. Anda harus menyesuaikan contoh agar sesuai dengan penggunaan Anda, karena contoh ini hanya menyertakan komponen yang disertakan dalam arsitektur. Komponen termahal dalam skenario adalah UI obrolan & komputasi alur perintah dan Azure AI Search, jadi lihat pengoptimalan di sekitar sumber daya tersebut untuk menghemat biaya paling besar.

Compute

Alur permintaan Azure Pembelajaran Mesin mendukung beberapa opsi untuk menghosting alur yang dapat dieksekusi. Opsi ini mencakup titik akhir online terkelola di Azure Pembelajaran Mesin, Azure Kubernetes Service, Azure App Service, dan Azure Container Service. Masing-masing opsi ini memiliki model penagihannya sendiri. Pilihan komputasi berdampak pada biaya keseluruhan solusi.

Azure OpenAI

Azure OpenAI adalah layanan berbasis konsumsi, dan seperti halnya layanan berbasis konsumsi apa pun, mengontrol permintaan terhadap pasokan adalah kontrol biaya utama. Untuk melakukannya di layanan Azure OpenAI secara khusus Anda perlu menggunakan kombinasi pendekatan:

  • Mengontrol klien. Permintaan klien adalah sumber biaya utama dalam model konsumsi, karena perilaku klien pengontrol tersebut sangat penting. Semua klien harus:
    • Disetujui. Hindari mengekspos layanan singgah mendukung akses gratis untuk semua. Batasi akses baik melalui kontrol jaringan maupun identitas (kunci atau RBAC).
    • Dikontrol sendiri. Mengharuskan klien untuk menggunakan batasan pembatasan token yang ditawarkan oleh panggilan API, seperti max_tokens dan max_completions.
    • Gunakan batching, di mana praktis. Tinjau klien untuk memastikan mereka membuat batch dengan tepat.
    • Optimalkan input prompt dan panjang respons. Permintaan yang lebih panjang mengonsumsi lebih banyak token, meningkatkan biaya, namun permintaan yang kehilangan konteks yang memadai tidak membantu model menghasilkan hasil yang baik. Buat perintah ringkas yang memberikan konteks yang cukup untuk memungkinkan model menghasilkan respons yang berguna. Demikian juga, pastikan Anda mengoptimalkan batas panjang respons.
  • Penggunaan playground Azure OpenAI harus seperlunya dan pada instans praproduksi, sehingga aktivitas tersebut tidak dikenakan biaya produksi.
  • Pilih model AI yang tepat. Pemilihan model juga memainkan peran besar dalam biaya keseluruhan Azure OpenAI. Semua model memiliki kekuatan dan kelemahan dan dihargai secara individual. Menggunakan model yang benar untuk kasus penggunaan dapat memastikan Anda tidak terlalu mengesampingkan model yang lebih mahal ketika model yang lebih murah menghasilkan hasil yang dapat diterima. Dalam implementasi referensi obrolan ini, GPT 3.5-turbo dipilih melalui GPT-4 untuk menghemat sekitar besarnya biaya penyebaran model sambil mencapai hasil yang memadai.
  • Memahami titik henti penagihan - Penyempurnaan dikenakan biaya per jam. Untuk menjadi yang paling efisien, Anda harus menggunakan sebanyak mungkin waktu yang tersedia per jam untuk meningkatkan hasil penyempurnaan sambil menghindari hanya tergelincir ke periode penagihan berikutnya. Demikian juga, biaya untuk 100 gambar dari pembuatan gambar sama dengan biaya untuk 1 gambar. Maksimalkan titik jeda harga untuk keuntungan Anda.
  • Memahami model penagihan - Azure OpenAI juga tersedia dalam model penagihan berbasis komitmen melalui penawaran throughput yang disediakan. Setelah Anda memiliki pola penggunaan yang dapat diprediksi, evaluasi beralih ke model penagihan prabayar ini jika dihitung agar lebih hemat biaya pada volume penggunaan Anda.
  • Atur batas provisi - Pastikan bahwa semua kuota provisi dialokasikan hanya untuk model yang diharapkan menjadi bagian dari beban kerja, berdasarkan per model. Throughput ke model yang sudah disebarkan tidak terbatas pada kuota yang disediakan ini saat kuota dinamis diaktifkan. Perhatikan bahwa kuota tidak langsung dipetakan ke biaya dan biaya mungkin bervariasi.
  • Pantau penggunaan bayar sesuai pemakaian - Jika menggunakan bayar sesuai pemakaian, pantau penggunaan Token per Menit (TPM) dan Permintaan per Menit (RPM). Gunakan informasi tersebut untuk menginformasikan keputusan desain arsitektur seperti model apa yang akan digunakan, serta mengoptimalkan ukuran prompt.
  • Pantau penggunaan throughput yang disediakan - Jika menggunakan throughput yang disediakan, pantau pemanfaatan yang dikelola provisi untuk memastikan Anda tidak memanfaatkan throughput yang disediakan yang telah Anda beli.
  • Manajemen biaya - Ikuti panduan tentang menggunakan fitur manajemen biaya dengan OpenAI untuk memantau biaya, menetapkan anggaran untuk mengelola biaya, dan membuat pemberitahuan untuk memberi tahu pemangku kepentingan tentang risiko atau anomali.

Operasi model bahasa besar (LLMOps)

Penyebaran untuk solusi obrolan berbasis Azure OpenAI seperti arsitektur ini harus mengikuti panduan di LLMOps dengan alur prompt dengan Azure DevOps dan GitHub. Selain itu, ini harus mempertimbangkan praktik terbaik untuk CI/CD dan arsitektur yang diamankan jaringan. Panduan berikut membahas implementasi Alur dan infrastruktur terkait berdasarkan rekomendasi LLMOps. Panduan penyebaran ini tidak menyertakan elemen aplikasi front-end, yang tidak berubah dari dalam arsitektur aplikasi web redundan zona yang sangat tersedia di Garis Besar.

Pengembangan

Alur permintaan Azure Pembelajaran Mesin menawarkan pengalaman penulisan berbasis browser di studio Azure Pembelajaran Mesin atau melalui ekstensi Visual Studio Code. Kedua opsi menyimpan kode alur sebagai file. Saat menggunakan studio Azure Pembelajaran Mesin, file disimpan di Akun Azure Storage. Saat bekerja di Visual Studio Code, file disimpan di sistem file lokal Anda.

Untuk mengikuti praktik terbaik untuk pengembangan kolaboratif, file sumber harus dipertahankan dalam repositori kode sumber online seperti GitHub. Pendekatan ini memfasilitasi pelacakan semua perubahan kode, kolaborasi antara penulis alur dan integrasi dengan alur penyebaran yang menguji dan memvalidasi semua perubahan kode.

Untuk pengembangan perusahaan, Anda harus menggunakan ekstensi Visual Studio Code dan alur permintaan SDK/CLI untuk pengembangan. Penulis alur prompt dapat membangun dan menguji alurnya dari VISUAL Code dan mengintegrasikan file yang disimpan secara lokal dengan sistem kontrol sumber online dan alur. Meskipun pengalaman berbasis browser sangat cocok untuk pengembangan eksplorasi, dengan beberapa pekerjaan, itu dapat diintegrasikan dengan sistem kontrol sumber. Folder alur dapat diunduh dari halaman alur di Files panel, di-unzip, dan didorong ke sistem kontrol sumber.

Evaluasi

Anda harus menguji alur yang digunakan dalam aplikasi obrolan sama seperti Anda menguji artefak perangkat lunak lainnya. Sangat menantang untuk menentukan dan menegaskan satu jawaban "benar" untuk output LLM, tetapi Anda dapat menggunakan LLM itu sendiri untuk mengevaluasi respons. Pertimbangkan untuk menerapkan evaluasi otomatis berikut dari alur LLM Anda:

  • Akurasi Klasifikasi: Mengevaluasi apakah LLM memberikan skor "benar" atau "salah" dan menggabungkan hasil untuk menghasilkan tingkat akurasi.
  • Koherensi: Mengevaluasi seberapa baik kalimat dalam jawaban model yang diprediksi ditulis dan bagaimana mereka secara koheren terhubung satu sama lain.
  • Kefasihan: Menilai prediksi jawaban model untuk akurasi tata bahasa dan linguistiknya.
  • Groundedness Against Context: Mengevaluasi seberapa baik jawaban model yang diprediksi didasarkan pada konteks yang telah dikonfigurasi sebelumnya. Bahkan jika respons LLM benar, jika tidak dapat divalidasi terhadap konteks yang diberikan, respons tersebut tidak di-grounded.
  • Relevansi: Mengevaluasi seberapa baik jawaban model yang diprediksi selaras dengan pertanyaan yang diajukan.

Pertimbangkan panduan berikut saat menerapkan evaluasi otomatis:

  • Menghasilkan skor dari evaluasi dan mengukurnya terhadap ambang keberhasilan yang telah ditentukan sebelumnya. Gunakan skor ini untuk melaporkan uji lulus/gagal di alur Anda.
  • Beberapa pengujian ini memerlukan input data pertanyaan, konteks, dan kebenaran dasar yang telah dikonfigurasi sebelumnya.
  • Sertakan pasangan tanya jawab yang cukup untuk memastikan hasil pengujian dapat diandalkan, dengan setidaknya 100-150 pasangan yang direkomendasikan. Pasangan jawaban atas pertanyaan ini disebut sebagai "himpunan data emas" Anda. Populasi yang lebih besar mungkin diperlukan tergantung pada ukuran dan domain himpunan data Anda.
  • Hindari menggunakan LLM untuk menghasilkan salah satu data dalam himpunan data emas Anda.

Alur Penyebaran

Diagram yang memperlihatkan alur penyebaran untuk alur permintaan.

Gambar 5: Penyebaran alur perintah

  1. Teknisi prompt/ilmuwan data membuka cabang fitur tempat mereka bekerja pada tugas atau fitur tertentu. Teknisi prompt/ilmuwan data melakukan iterasi pada alur menggunakan Alur permintaan untuk Visual Studio Code, secara berkala melakukan perubahan dan mendorong perubahan tersebut ke cabang fitur.

  2. Setelah pengembangan dan eksperimen lokal selesai, teknisi prompt/ilmuwan data membuka permintaan pull dari cabang Fitur ke cabang Utama. Permintaan pull (PR) memicu alur PR. Alur ini menjalankan pemeriksaan kualitas cepat yang harus mencakup:

    • Eksekusi alur eksperimen
    • Eksekusi pengujian unit yang dikonfigurasi
    • Kompilasi basis kode
    • Analisis Kode Statis
  3. Alur dapat berisi langkah yang mengharuskan setidaknya satu anggota tim menyetujui PR secara manual sebelum menggabungkan. Pemberi izin tidak dapat menjadi committer dan mereka mush memiliki keahlian alur yang cepat dan keakraban dengan persyaratan proyek. Jika PR tidak disetujui, penggabungan diblokir. Jika PR disetujui, atau tidak ada langkah persetujuan, cabang fitur digabungkan ke cabang Utama.

  4. Penggabungan ke Utama memicu proses build dan rilis untuk lingkungan Pengembangan. Khususnya:

    a. Alur CI dipicu dari penggabungan ke Utama. Alur CI melakukan semua langkah yang dilakukan dalam alur PR, dan langkah-langkah berikut:

    • Alur eksperimen
    • Alur evaluasi
    • Mendaftarkan alur di Azure Pembelajaran Mesin Registry saat perubahan terdeteksi

    b. Alur CD dipicu setelah penyelesaian alur CI. Alur ini melakukan langkah-langkah berikut:

    • Menyebarkan alur dari Azure Pembelajaran Mesin Registry ke titik akhir online Azure Pembelajaran Mesin
    • Menjalankan pengujian integrasi yang menargetkan titik akhir online
    • Menjalankan uji asap yang menargetkan titik akhir online
  5. Proses persetujuan dibangun ke dalam proses promosi rilis - setelah disetujui, proses CI & CD yang dijelaskan dalam langkah 4.a. & 4.b. diulang, menargetkan lingkungan Uji. Langkah a. dan b. sama, kecuali bahwa pengujian penerimaan pengguna dijalankan setelah uji asap di lingkungan Uji.

  6. Proses CI & CD yang dijelaskan dalam langkah 4.a. & 4.b. dijalankan untuk mempromosikan rilis ke lingkungan Produksi setelah lingkungan Pengujian diverifikasi dan disetujui.

  7. Setelah dilepaskan ke lingkungan langsung, tugas operasional pemantauan metrik performa dan mengevaluasi LLM yang disebarkan berlangsung. Ini termasuk tetapi tidak terbatas pada:

    • Mendeteksi drift data
    • Mengamati infrastruktur
    • Mengelola biaya
    • Mengomunikasikan performa model kepada pemangku kepentingan

Panduan Penyebaran

Azure Pembelajaran Mesin Endpoints memungkinkan Anda menyebarkan model dengan cara yang memungkinkan fleksibilitas saat merilis ke produksi. Pertimbangkan strategi berikut untuk memastikan performa dan kualitas model terbaik:

  • Penyebaran biru/hijau: Dengan strategi ini, Anda dapat dengan aman menyebarkan versi baru layanan web Anda ke sekelompok pengguna atau permintaan terbatas sebelum mengarahkan semua lalu lintas ke penyebaran baru.
  • Pengujian A/B: Tidak hanya penyebaran Biru/Hijau yang efektif untuk meluncurkan perubahan dengan aman, mereka juga dapat digunakan untuk menyebarkan perilaku baru yang memungkinkan subset pengguna untuk mengevaluasi dampak perubahan.
  • Sertakan linting file Python yang merupakan bagian dari alur prompt di alur Anda. Pemeriksaan linting untuk kepatuhan terhadap standar gaya, kesalahan, kompleksitas kode, impor yang tidak digunakan, dan penamaan variabel.
  • Saat menyebarkan alur Anda ke ruang kerja Azure Pembelajaran Mesin yang terisolasi jaringan, gunakan agen yang dihost sendiri untuk menyebarkan artefak ke sumber daya Azure Anda.
  • Registri model Azure Pembelajaran Mesin hanya boleh diperbarui ketika ada perubahan pada model.
  • LLM, alur, dan UI klien harus digabungkan secara longgar. Pembaruan pada alur dan UI klien dapat dan harus dapat dibuat tanpa memengaruhi model dan sebaliknya.
  • Saat mengembangkan dan menyebarkan beberapa alur, setiap alur harus memiliki siklus hidupnya sendiri, yang memungkinkan pengalaman yang digabungkan secara longgar saat mempromosikan alur dari eksperimen ke produksi.

Infrastruktur

Saat menyebarkan komponen obrolan end-to-end Azure OpenAI dasar, beberapa layanan yang disediakan bersifat dasar dan permanen dalam arsitektur, sedangkan komponen lain bersifat lebih sementara, keberadaannya terkait dengan penyebaran.

Komponen dasar

Beberapa komponen dalam arsitektur ini ada dengan siklus hidup yang meluas di luar alur prompt individual atau penyebaran model apa pun. Sumber daya ini biasanya disebarkan sekali sebagai bagian dari penyebaran dasar oleh tim beban kerja, dan dipertahankan selain dari baru, dihapus, atau diperbarui pada alur perintah atau penyebaran model.

  • Ruang kerja Azure Machine Learning
  • Akun Azure Storage untuk ruang kerja Azure Pembelajaran Mesin
  • Azure Container Registry
  • Pencarian Azure AI
  • Azure OpenAI
  • Azure Application Insights
  • Azure Bastion
  • Azure Virtual Machine untuk jump box

Komponen Ephemeral

Beberapa sumber daya Azure lebih erat digabungkan dengan desain alur prompt tertentu, memungkinkan sumber daya ini terikat dengan siklus hidup komponen dan menjadi sementara dalam arsitektur ini. Mereka terpengaruh ketika beban kerja berkembang, seperti ketika alur ditambahkan atau dihapus atau ketika model baru diperkenalkan. Sumber daya ini dibuat ulang dan instans sebelumnya dihapus. Beberapa sumber daya ini adalah sumber daya Azure langsung dan beberapa adalah manifestasi sarana data dalam layanan yang berisinya.

  • Model dalam registri model Azure Pembelajaran Mesin harus diperbarui, jika diubah, sebagai bagian dari alur CD.
  • Gambar kontainer harus diperbarui dalam registri kontainer sebagai bagian dari alur CD.
  • Titik akhir Azure Pembelajaran Mesin dibuat saat alur permintaan disebarkan jika penyebaran mereferensikan titik akhir yang tidak ada. Titik akhir tersebut perlu diperbarui untuk menonaktifkan akses publik.
  • Penyebaran titik akhir Azure Pembelajaran Mesin diperbarui saat alur disebarkan atau dihapus.
  • Key Vault untuk UI klien harus diperbarui dengan kunci ke titik akhir saat titik akhir baru dibuat.

Pemantauan

Diagnostik dikonfigurasi untuk semua layanan. Semua layanan tetapi Azure Pembelajaran Mesin dan Azure App Service dikonfigurasi untuk mengambil semua log. Diagnostik Azure Pembelajaran Mesin dikonfigurasi untuk menangkap log audit yang merupakan semua log sumber daya yang merekam interaksi pelanggan dengan data atau pengaturan layanan. Azure App Service dikonfigurasi untuk mengambil AppServiceHTTPLogs, AppServiceConsoleLogs, AppServiceAppLogs, dan AppServicePlatformLogs.

Menyebarkan skenario ini

Untuk menyebarkan dan menjalankan implementasi referensi, ikuti langkah-langkah dalam implementasi referensi garis besar end-to-end OpenAI.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Baca selengkapnya tentang Azure OpenAI