Arsitektur referensi obrolan Dasar Azure AI Foundry

Azure OpenAI Service

Layanan Azure AI

Azure App Service

Azure Monitor

Aplikasi obrolan perusahaan dapat memberdayakan karyawan melalui interaksi percakapan dengan agen AI. Kemampuan ini semakin kuat berkat kemajuan yang berkelanjutan dalam model bahasa, seperti model GPT OpenAI dan SDK orkestrasi seperti Semantic Kernel. Aplikasi obrolan ini biasanya terdiri dari komponen-komponen berikut:

Antarmuka pengguna obrolan (UI) yang diintegrasikan ke dalam aplikasi perusahaan yang lebih besar. Ini memberi pengguna pengalaman percakapan bersama fungsi bisnis lainnya.
Repositori data yang berisi informasi khusus domain yang berkaitan dengan kueri pengguna.
Model bahasa yang beralasan atas data khusus domain untuk menghasilkan respons yang relevan.
Orkestrator atau agen yang mengawasi interaksi antara sumber data, model bahasa, dan pengguna akhir.

Artikel ini menyediakan arsitektur dasar untuk membantu Anda membangun dan menyebarkan aplikasi obrolan perusahaan dengan menggunakan Azure AI Foundry dan Azure OpenAI di Foundry Models. Arsitektur ini menggunakan satu agen yang dihosting di Azure AI Foundry Agent Service. Agen menerima pesan pengguna lalu mengkueri penyimpanan data untuk mengambil informasi dasar untuk model bahasa.

UI obrolan mengikuti panduan aplikasi web layanan Azure App dasar tentang cara menyebarkan aplikasi web yang aman, redundan zona, dan sangat tersedia di App Service. Dalam arsitektur itu, App Service berkomunikasi dengan solusi platform as a service (PaaS) Azure melalui integrasi jaringan virtual melalui titik akhir privat. Dalam arsitektur UI obrolan, App Service berkomunikasi dengan agen melalui titik akhir privat. Akses publik ke portal Dan agen Azure AI Foundry dinonaktifkan.

Penting

Artikel ini tidak menjelaskan komponen atau keputusan arsitektur dari arsitektur aplikasi web App Service dasar. Baca artikel tersebut untuk panduan arsitektur tentang cara menghosting aplikasi web yang berisi UI obrolan Anda.

Arsitektur ini menggunakan penyiapan agen standar Foundry Agent Service untuk mengaktifkan keamanan, kepatuhan, dan kontrol tingkat perusahaan. Dalam konfigurasi ini, Anda membawa jaringan Anda sendiri untuk isolasi jaringan dan sumber daya Azure Anda sendiri untuk menyimpan obrolan dan status agen. Semua komunikasi antara komponen aplikasi dan layanan Azure terjadi melalui titik akhir privat, yang memastikan bahwa lalu lintas data tetap berada dalam jaringan virtual beban kerja Anda. Lalu lintas keluar dari agen secara ketat merutekan melalui Azure Firewall, yang memberlakukan aturan keluar.

Petunjuk / Saran

Implementasi referensi Foundry Agent Service menampilkan implementasi obrolan end-to-end garis besar di Azure. Ini berfungsi sebagai fondasi untuk mengembangkan solusi kustom saat Anda bergerak menuju produksi.

Arsitektur

Unduh file Visio dari arsitektur ini.

Alur kerja

Pengguna aplikasi berinteraksi dengan UI obrolan. Permintaan dirutekan melalui Azure Application Gateway. Azure Web Application Firewall memeriksa permintaan ini sebelum meneruskannya ke App Service back-end.
Saat aplikasi web menerima kueri atau instruksi pengguna, aplikasi web memanggil agen yang dibuat khusus. Aplikasi web berkomunikasi dengan agen melalui Azure AI Agent SDK. Aplikasi web memanggil agen melalui titik akhir privat dan mengautentikasi ke Azure AI Foundry dengan menggunakan identitas terkelolanya.
Agen memproses permintaan pengguna berdasarkan instruksi dalam prompt sistemnya. Untuk memenuhi niat pengguna, agen menggunakan model bahasa yang dikonfigurasi dan alat yang terhubung dan penyimpanan pengetahuan.
Agen terhubung ke penyimpanan pengetahuan (Azure AI Search) di jaringan privat melalui titik akhir privat.
Permintaan ke penyimpanan pengetahuan eksternal atau alat, seperti Wikipedia atau Bing, melintasi Azure Firewall untuk inspeksi dan penegakan kebijakan keluar.
Agen terhubung ke model bahasa yang dikonfigurasi dan melewati konteks yang relevan.
Sebelum agen mengembalikan respons terhadap UI, agen mempertahankan permintaan, respons yang dihasilkan, dan daftar penyimpanan pengetahuan yang dikonsultasikan ke dalam database memori khusus. Database ini mempertahankan riwayat percakapan lengkap, yang memungkinkan interaksi sadar konteks dan memungkinkan pengguna untuk melanjutkan percakapan dengan agen tanpa kehilangan konteks sebelumnya.

API Azure AI Foundry mendukung pengembangan pengalaman pengguna yang mengelola beberapa percakapan yang bersamaan dan terisolasi konteks.

Komponen

Arsitektur ini dibangun berdasarkan arsitektur referensi obrolan Azure AI Foundry dasar. Arsitektur ini memperkenalkan lebih banyak layanan Azure untuk memenuhi persyaratan perusahaan untuk keandalan, keamanan, dan kontrol operasional. Masing-masing komponen berikut memainkan peran tertentu dalam solusi obrolan perusahaan produksi:

Foundry Agent Service menyediakan lapisan orkestrasi untuk interaksi obrolan. Ini menghosting dan mengelola agen yang melakukan tugas-tugas berikut:
- Memproses permintaan pengguna
- Mengoordinasikan panggilan ke alat dan agen lainnya
- Menerapkan keamanan konten
- Integrasikan dengan identitas perusahaan, jaringan, dan pengamatan
Penyiapan agen standar memastikan isolasi jaringan dan memberikan kontrol atas penyimpanan data. Anda menyediakan sumber daya Azure khusus untuk status agen, riwayat obrolan, dan penyimpanan file, yang dikelola Oleh Foundry Agent Service secara eksklusif. Komponen aplikasi lain dalam beban kerja tidak boleh menggunakan sumber daya yang diperlukan ini.
- Azure Cosmos DB for NoSQL menghosting database memori beban kerja ini, yang disebut enterprise_memory, dalam langganan Anda. Database ini menyimpan status operasional agen, termasuk utas obrolan dan definisi agen. Desain ini memastikan bahwa riwayat obrolan dan konfigurasi agen terisolasi, dapat diaudit, dan dikelola sesuai dengan persyaratan tata kelola data. Foundry Agent Service mengelola database, koleksinya, dan datanya.
- Akun Azure Storage khusus menyimpan file yang diunggah selama sesi obrolan. Hosting akun ini dalam langganan Anda menyediakan kontrol akses terperinci, kemampuan audit, dan kepatuhan terhadap kebijakan residensi atau retensi data. Foundry Agent Service mengelola kontainer dan siklus hidup data dalam kontainer tersebut.
- Instans Pencarian AI khusus menyimpan indeks file yang diunggah yang dapat dicari dan dipotong dari percakapan dengan agen. Ini juga menyimpan file statis yang ditambahkan sebagai sumber pengetahuan saat agen dibuat. Foundry Agent Service mengelola indeks, skema, dan data, dan menggunakan strategi penggugusan dan logika kuerinya sendiri.
Application Gateway berfungsi sebagai titik masuk yang aman dan dapat diskalakan untuk semua lalu lintas HTTP dan HTTPS ke UI obrolan. Ini menyediakan penghentian Keamanan Lapisan Transportasi (TLS) dan perutean berbasis jalur. Ini juga mendistribusikan permintaan di seluruh zona ketersediaan, yang mendukung ketersediaan dan performa tinggi untuk tingkat aplikasi web. Ujung belakangnya adalah App Service yang menghosting kode aplikasi.
- Azure Web Application Firewall terintegrasi dengan Application Gateway untuk melindungi UI obrolan dari kerentanan dan serangan web umum. Ini memeriksa dan memfilter permintaan HTTP, yang menyediakan lapisan keamanan untuk aplikasi yang menghadap publik.
- Azure Key Vault menyimpan dan mengelola sertifikat TLS yang diperlukan Application Gateway dengan aman. Manajemen sertifikat terpusat di Key Vault mendukung rotasi, audit, dan kepatuhan otomatis dengan standar keamanan organisasi. Arsitektur ini tidak memerlukan kunci tersimpan atau rahasia lainnya.
Azure Virtual Network menyediakan isolasi jaringan untuk semua komponen. Saat Anda menempatkan sumber daya di jaringan virtual privat, Anda mengontrol lalu lintas timur-barat dan utara-selatan, memberlakukan segmentasi, menjaga lalu lintas tetap privat, dan mengaktifkan inspeksi alur masuk dan keluar. Penyiapan ini membantu Anda memenuhi persyaratan keamanan dan kepatuhan.
Azure Private Link menghubungkan semua layanan PaaS, seperti Azure Cosmos DB, Storage, AI Search, dan Foundry Agent Service, ke jaringan virtual melalui titik akhir privat. Pendekatan ini memastikan bahwa semua lalu lintas data tetap berada di tulang punggung Azure, yang menghilangkan paparan internet publik dan mengurangi permukaan serangan.
Azure Firewall memeriksa dan mengontrol semua lalu lintas keluar (keluar) dari jaringan virtual. Ini memberlakukan aturan berbasis nama domain yang sepenuhnya memenuhi syarat (FQDN), yang memastikan bahwa hanya tujuan yang disetujui yang dapat dijangkau. Konfigurasi ini membantu mencegah penyelundupan data dan memenuhi persyaratan untuk keamanan jaringan.
Azure DNS menyediakan zona Sistem Nama Domain (DNS) privat yang ditautkan ke jaringan virtual. Fitur ini memungkinkan resolusi nama untuk titik akhir privat, yang memastikan bahwa semua komunikasi layanan-ke-layanan menggunakan alamat IP privat dan tetap berada dalam batas jaringan.
Penyimpanan menghosting kode aplikasi web sebagai file ZIP untuk penyebaran ke App Service. Metode ini mendukung alur kerja penyebaran otomatis yang aman dan memisahkan artefak aplikasi dari sumber daya komputasi.

Alternatif

Arsitektur ini mencakup beberapa komponen yang dapat Anda ganti dengan layanan atau pendekatan Azure lainnya, tergantung pada persyaratan fungsional dan nonfungsi beban kerja Anda. Pertimbangkan alternatif dan trade-off berikut.

Orkestrasi obrolan

Pendekatan saat ini: Arsitektur ini menggunakan Foundry Agent Service untuk mengatur alur obrolan, termasuk mengambil data grounding dari penyimpanan pengetahuan dan memanggil model Azure OpenAI. Foundry Agent Service menyediakan orkestrasi tanpa kode dan nondeterministik. Ini menangani permintaan obrolan, manajemen utas, pemanggilan alat, keamanan konten, dan integrasi dengan identitas, jaringan, dan pengamatan. Ini menyediakan solusi database memori asli.

Pendekatan alternatif: Anda dapat menghost sendiri lapisan orkestrasi dengan menggunakan kerangka kerja seperti Semantic Kernel atau LangChain. Gunakan kerangka kerja ini untuk mengimplementasikan deterministik, alur obrolan berbasis kode, dan logika orkestrasi kustom.

Pertimbangkan alternatif ini jika beban kerja Anda memerlukan kemampuan berikut:

Kontrol deterministik yang terperinci atas urutan orkestrasi, pemanggilan alat, atau rekayasa prompt
Integrasi dengan logika bisnis kustom atau sistem eksternal yang tidak didukung oleh Foundry Agent Service secara asli
Perutean permintaan klien tingkat lanjut untuk eksperimen atau praktik penyebaran yang aman
Solusi database memori kustom yang berbeda dari solusi Foundry Agent Service asli

Orkestrasi yang dihost sendiri meningkatkan kompleksitas operasional dan mengharuskan Anda mengelola komputasi, penskalaan, dan keamanan.

Komponen tingkat aplikasi

Pendekatan saat ini: Situs web front-end antarmuka pengguna obrolan dihosting di fitur Web Apps App Service, yang menyediakan platform terkelola dan dapat diskalakan untuk aplikasi web. Web Apps terintegrasi secara asli dengan fitur jaringan dan keamanan Azure.

Pendekatan alternatif: Anda dapat menggunakan platform komputasi yang dikelola Azure lainnya, seperti Azure Container Apps atau Azure Kubernetes Service (AKS), untuk menghosting tingkat aplikasi.

Pertimbangkan alternatif ini jika beban kerja Anda memenuhi salah satu kondisi berikut:

Platform komputasi lain yang lebih baik mendukung kasus penggunaan tertentu, dan layanan kolokasi pada platform tersebut dapat meningkatkan efisiensi biaya dan menyederhanakan operasi
Aplikasi Anda memerlukan penskalakan, orkestrasi, atau jaringan kustom yang lebih canggih

App Service tetap menjadi opsi yang disukai karena kesederhanaannya dalam menghosting aplikasi web dan API mereka.

Penyimpanan data grounding (pengetahuan)

Pendekatan saat ini: Arsitektur ini menggunakan Pencarian AI sebagai penyimpanan data utama untuk pengetahuan dasar. Ini menggunakan kemampuan pencarian vektor Pencarian AI dan peringkat semantik.

Pendekatan alternatif: Anda dapat menggunakan platform data lain untuk pengetahuan dasar, seperti Azure Cosmos DB, Azure SQL Database, atau penyimpanan data pemrosesan transaksi online (OLTP) lainnya. Platform data Anda bergantung pada data estate, persyaratan kesegaran data, dan persyaratan kueri yang ada.

Pertimbangkan alternatif ini jika beban kerja Anda memenuhi salah satu kondisi berikut:

Anda sudah mengelola pengetahuan dasar Anda dalam database transaksional atau operasional yang ada
Anda memerlukan dukungan multi-model atau SDK tidak tersedia di Pencarian AI
Anda perlu berintegrasi dengan sumber data khusus atau sistem warisan

Pencarian vektor umum untuk pembuatan tertambung pengambilan tetapi tidak selalu diperlukan. Untuk informasi selengkapnya, lihat Memilih layanan Azure untuk pencarian vektor. Sebelum Anda memilih penyimpanan data, evaluasi pola akses data, latensi, dan kebutuhan skalabilitas beban kerja Anda.

Agen yang telah ditentukan sebelumnya atau agen yang dibuat secara dinamis

Pendekatan saat ini: Implementasi referensi menggunakan agen yang ditentukan secara statis yang disebarkan sebagai layanan mikro dalam Azure AI Foundry. Logika agen dan sumber data dikonfigurasi saat penyebaran dan tetap tidak berubah hingga rilis aplikasi berikutnya. Pendekatan ini berfungsi dengan baik ketika perilaku agen dan sumber data stabil dan dikontrol melalui proses DevOps.

Pendekatan alternatif: Anda dapat membuat atau memodifikasi agen secara dinamis pada runtime dengan menggunakan Azure AI Agent SDK. Pendekatan ini memungkinkan aplikasi untuk membuat instans agen sesuai permintaan, menyesuaikan permintaan sistem, atau mengonfigurasi ulang koneksi berdasarkan konteks pengguna atau logika bisnis.

Pertimbangkan agen dinamis jika beban kerja Anda memerlukan kemampuan berikut:

Perilaku agen atau sumber data yang dipersonalisasi untuk setiap pengguna atau sesi
Perubahan yang sering atau terprogram pada konfigurasi agen
Dukungan agen khusus konteks untuk pengalaman pengguna tingkat lanjut

Manajemen agen dinamis meningkatkan fleksibilitas tetapi juga memperkenalkan beban manajemen siklus hidup. Pastikan Anda memiliki kontrol yang sesuai untuk pembuatan, modifikasi, dan pembersihan agen.

Pilih pendekatan agen yang selaras dengan persyaratan pengalaman pengguna beban kerja Anda.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat Anda gunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Terapkan arsitektur ini dan beban kerja AI pada panduan desain Azure selama fase desain beban kerja Anda.

Keandalan

Keandalan membantu memastikan bahwa aplikasi Anda dapat memenuhi komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keandalan.

Arsitektur aplikasi web App Service dasar berfokus pada redundansi zona untuk layanan regional utama. Zona ketersediaan adalah lokasi yang terpisah secara fisik dalam wilayah yang memberikan redundansi saat Anda menyebarkan dua instans atau lebih di seluruh wilayah tersebut. Jika satu zona mengalami waktu henti, yang lain di wilayah tersebut mungkin tetap tidak terpengaruh. Arsitektur ini juga mendistribusikan instans dan konfigurasi layanan Azure di seluruh zona ketersediaan. Untuk informasi selengkapnya, lihat Baseline aplikasi web redundan zona yang sangat tersedia.

Bagian ini membahas keandalan untuk komponen yang tidak tercakup dalam arsitektur garis besar App Service, khususnya Azure AI Foundry dan AI Search.

Redundansi zona di lapisan orkestrasi Anda

Penyebaran perusahaan biasanya memerlukan redundansi zona untuk meminimalkan risiko gangguan layanan dari kegagalan tingkat zona. Di Azure, redundansi zona berarti menggunakan sumber daya yang mendukung zona ketersediaan dan menyebarkan setidaknya tiga instans, atau mengaktifkan redundansi tingkat platform di mana kontrol instans langsung tidak tersedia.

Dalam arsitektur ini, Azure AI Foundry menghosting kemampuan Foundry Agent Service. Keandalan agen tergantung pada ketersediaan dependensi Foundry Agent Service, yaitu Azure Cosmos DB, Storage, dan AI Search. Foundry Agent Service mengelola data dalam layanan ini, tetapi Anda mengonfigurasi keandalannya dalam langganan Anda.

Untuk mencapai redundansi zona untuk lapisan orkestrasi, ikuti rekomendasi berikut:

Aktifkan redundansi zona di akun Azure Cosmos DB for NoSQL Anda . Konfigurasi ini memastikan replikasi data sinkron di beberapa zona, yang mengurangi risiko kehilangan data atau waktu henti dari kegagalan zona tunggal.

Pertimbangkan juga distribusi global untuk mengurangi pemadaman regional dalam Azure Cosmos DB.
Gunakan penyimpanan zona redundan (ZRS) untuk akun Penyimpanan Anda. Untuk ketahanan yang lebih tinggi, gunakan penyimpanan geo-zona-redundan (GZRS), yang menggabungkan redundansi zona dan regional.
Konfigurasikan instans Pencarian AI Anda dengan setidaknya tiga replika. Konfigurasi ini memastikan bahwa layanan mendistribusikan replika di seluruh zona unik di wilayah Anda.

Jika agen Anda terintegrasi dengan dependensi khusus beban kerja lainnya, seperti koneksi alat kustom atau penyimpanan pengetahuan eksternal, pastikan dependensi tersebut memenuhi persyaratan ketersediaan dan redundansi Anda. Setiap dependensi zona tunggal atau nonredundan dapat merusak keandalan keseluruhan lapisan orkestrasi.

Portal AI Foundry, API sarana datanya, dan kemampuan Foundry Agent Service tidak menyediakan kontrol langsung untuk redundansi zona.

Keandalan dalam hosting model Azure AI Foundry

Azure AI Foundry menyediakan model sebagai hosting layanan (MaaS) dengan beberapa opsi penyebaran. Opsi ini terutama mendukung manajemen kuota dan throughput, daripada ketersediaan tinggi tradisional dalam suatu wilayah. Penyebaran model standar beroperasi di satu wilayah dan tidak mendukung zona ketersediaan. Untuk mencapai ketersediaan multi-pusat data, Anda harus menggunakan penyebaran model global atau zona data.

Untuk skenario obrolan perusahaan, sebarkan model standar zona data yang disediakan dan zona data . Konfigurasikan spillover untuk menangani kelebihan lalu lintas atau kegagalan. Jika beban kerja Anda tidak memerlukan latensi rendah atau residensi dan pemrosesan data geografis yang ketat, gunakan penyebaran global untuk ketahanan maksimum.

Azure AI Foundry tidak mendukung penyeimbangan beban tingkat lanjut atau mekanisme failover, seperti perutean round-robin atau pemutusan sirkuit, untuk penyebaran model. Jika Anda memerlukan redundansi terperinci dan kontrol failover dalam suatu wilayah, host logika akses model Anda di luar layanan terkelola. Misalnya, Anda dapat membangun gateway kustom dengan menggunakan Azure API Management. Pendekatan ini memungkinkan Anda menerapkan perutean kustom, pemeriksaan kesehatan, dan strategi failover. Tetapi juga meningkatkan kompleksitas operasional dan mengalihkan tanggung jawab atas keandalan komponen tersebut kepada tim Anda.

Anda juga dapat mengekspos model terdepan gateway sebagai alat atau penyimpanan pengetahuan berbasis API kustom untuk agen Anda. Untuk informasi selengkapnya, lihat Menggunakan gateway di depan beberapa penyebaran atau instans Azure OpenAI.

Keandalan dalam Pencarian AI untuk pengetahuan perusahaan

Sebarkan Pencarian AI dengan menggunakan tingkat harga Standar atau yang lebih tinggi di wilayah yang mendukung zona ketersediaan. Konfigurasikan setidaknya tiga replika untuk memastikan bahwa layanan mendistribusikan instans di seluruh zona ketersediaan terpisah. Konfigurasi ini memberikan ketahanan terhadap kegagalan tingkat zona dan mendukung ketersediaan tinggi untuk operasi pencarian.

Untuk menentukan jumlah replika dan partisi yang optimal untuk beban kerja Anda, gunakan metode berikut:

Pantau Pencarian AI dengan menggunakan metrik dan log bawaan. Latensi kueri, pembatasan, dan penggunaan sumber daya.
Gunakan metrik pemantauan dan log dan analisis performa untuk menentukan jumlah replika yang sesuai. Pendekatan ini membantu Anda menghindari pembatasan dari volume kueri tinggi, partisi yang tidak mencukupi, atau batasan indeks.
Pastikan keandalan pengindeksan dengan menghindari gangguan dari kesalahan pengindeksan atau pengindeksan berkala. Pertimbangkan untuk mengindeks ke dalam indeks offline dan bertukar dari indeks langsung Anda ke indeks pembangunan ulang setelah Anda memvalidasi integritas data.

Keandalan di Azure Firewall

Azure Firewall adalah titik kontrol keluar penting dalam arsitektur ini tetapi mewakili satu titik kegagalan untuk semua lalu lintas keluar. Untuk mengurangi risiko ini, sebarkan Azure Firewall di semua zona ketersediaan di wilayah Anda. Konfigurasi ini membantu mempertahankan konektivitas keluar jika zona menjadi tidak tersedia.

Jika beban kerja Anda memerlukan koneksi keluar bersamaan dalam volume tinggi, konfigurasikan Azure Firewall dengan beberapa alamat IP publik. Pendekatan ini mendistribusikan koneksi Source Network Address Translation (SNAT) di beberapa awalan alamat IP, yang mengurangi risiko kelelahan port SNAT. Kelelahan SNAT dapat menyebabkan hilangnya konektivitas keluar secara terputus-terputus atau total untuk agen dan komponen beban kerja lainnya, yang dapat mengakibatkan waktu henti fitur atau performa yang terdegradasi.

Pantau penggunaan port SNAT dan kesehatan firewall. Jika Anda mengamati kegagalan koneksi atau masalah throughput, tinjau metrik dan log firewall untuk mengidentifikasi dan mengatasi kelelahan SNAT atau hambatan lainnya.

Mengisolasi dependensi Foundry Agent Service dari komponen beban kerja serupa

Untuk memaksimalkan keandalan dan meminimalkan radius ledakan kegagalan, isolasi dependensi Foundry Agent Service secara ketat dari komponen beban kerja lain yang menggunakan layanan Azure yang sama. Secara khusus, jangan bagikan sumber daya AI Search, Azure Cosmos DB, atau Storage antara layanan agen dan komponen aplikasi lainnya. Sebagai gantinya, provisikan instans khusus untuk dependensi layanan agen yang diperlukan.

Pemisahan ini memberikan dua manfaat utama:

Ini berisi kegagalan atau penurunan performa ke satu segmen beban kerja, yang mencegah dampak bertahap di seluruh fitur aplikasi yang tidak terkait.
Ini memungkinkan Anda menerapkan proses operasional yang ditargetkan, seperti pencadangan, pemulihan, dan failover. Proses ini disetel ke persyaratan ketersediaan dan pemulihan tertentu dari alur beban kerja yang menggunakan sumber daya tersebut.

Misalnya, jika aplikasi UI obrolan Anda perlu menyimpan status transaksional di Azure Cosmos DB, provisikan akun dan database Azure Cosmos DB terpisah untuk tujuan tersebut, daripada menggunakan kembali akun atau database yang dikelola Foundry Agent Service. Bahkan jika kesederhanaan biaya atau operasional memotivasi berbagi sumber daya, risiko peristiwa keandalan yang memengaruhi fitur beban kerja yang tidak terkait melebihi potensi penghematan dalam sebagian besar skenario perusahaan.

Penting

Jika Anda mengkolokasikan data khusus beban kerja dengan dependensi agen karena alasan biaya atau operasional, jangan pernah berinteraksi langsung dengan data yang dikelola sistem, seperti pengumpulan, kontainer, atau indeks, yang dibuat Oleh Foundry Agent Service. Detail implementasi internal ini tidak terdokumentasi dan dapat berubah tanpa pemberitahuan. Akses langsung dapat merusak layanan agen atau mengakibatkan kehilangan data. Selalu gunakan API sarana data Foundry Agent Service untuk manipulasi data, dan perlakukan data yang mendasar sebagai buram dan hanya monitor.

Desain multi-wilayah

Arsitektur ini menggunakan zona ketersediaan untuk ketersediaan tinggi dalam satu wilayah Azure. Ini bukan solusi multi-wilayah. Ini tidak memiliki elemen penting berikut yang diperlukan untuk ketahanan regional dan pemulihan bencana (DR):

Ingress global dan perutean lalu lintas
Manajemen DNS untuk failover
Replikasi data atau strategi isolasi di seluruh wilayah
Sebutan aktif-aktif, aktif-pasif, atau aktif-dingin
Proses failover dan failback regional untuk memenuhi tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO)
Pertimbangan ketersediaan wilayah untuk pengalaman pengembang, termasuk portal Azure AI Foundry dan API sarana data

Jika beban kerja Anda memerlukan kelangsungan bisnis jika pemadaman regional terjadi, Anda harus merancang dan menerapkan komponen tambahan dan proses operasional di luar arsitektur ini. Secara khusus, Anda perlu mengatasi penyeimbangan beban dan failover di setiap lapisan arsitektur, termasuk area berikut:

Data grounding (penyimpanan pengetahuan)
Hosting model dan titik akhir inferensi
Lapisan orkestrasi atau agen
Lalu lintas antarmuka pengguna dan titik masuk DNS

Anda juga harus memastikan bahwa pengamatan, pemantauan, dan kontrol keamanan konten tetap beroperasi dan konsisten di seluruh wilayah.

Arsitektur garis besar ini tidak memiliki kemampuan multi-wilayah, sehingga pemadaman regional kemungkinan akan mengakibatkan hilangnya layanan dalam beban kerja Anda.

Pemulihan bencana

Arsitektur obrolan berisi komponen stateful, sehingga perencanaan DR sangat penting. Beban kerja ini biasanya memerlukan penyimpanan memori untuk sesi obrolan aktif atau dijeda. Mereka juga memerlukan penyimpanan untuk data tambahan, seperti dokumen atau gambar, ditambahkan ke utas obrolan. Lapisan orkestrasi agen mungkin juga mempertahankan status yang khusus untuk alur percakapan. Dalam arsitektur ini, Foundry Agent Service menggunakan Azure Cosmos DB, Storage, dan AI Search untuk mempertahankan status operasional dan transaksional. Siklus hidup dan kopling status ini di seluruh komponen menentukan strategi DR dan operasi pemulihan Anda.

Untuk Foundry Agent Service, pastikan Anda dapat memulihkan semua dependensi ke titik waktu yang konsisten. Pendekatan ini membantu menjaga integritas transaksi di tiga dependensi eksternal.

Rekomendasi berikut membahas DR untuk setiap layanan:

Azure Cosmos DB: Aktifkan pencadangan berkelanjutan untuk enterprise_memory database. Penyiapan ini menyediakan pemulihan point-in-time (PITR) dengan RPO tujuh hari, yang mencakup definisi agen dan utas obrolan. Uji proses pemulihan Anda secara teratur untuk mengonfirmasi bahwa proses tersebut memenuhi RTO Anda dan bahwa data yang dipulihkan tetap tersedia untuk layanan agen. Selalu pulihkan ke akun dan database yang sama.
Pencarian AI: Pencarian AI tidak memiliki kemampuan pemulihan bawaan dan tidak mendukung manipulasi indeks langsung. Jika kehilangan atau kerusakan data terjadi, Anda harus menghubungi dukungan Microsoft untuk bantuan terkait pemulihan indeks. Batasan ini dapat secara signifikan memengaruhi RTO Anda. Jika UI obrolan Anda tidak mendukung unggahan file dan Anda tidak memiliki agen yang menggunakan file statis sebagai pengetahuan, Anda mungkin tidak memerlukan rencana DR untuk Pencarian AI.

Pertahankan sumber kebenaran yang terpisah dan diperbarui secara teratur untuk pengetahuan dasar perusahaan Anda. Praktik ini memastikan bahwa Anda dapat membangun kembali indeks jika diperlukan.
Penyimpanan: Jika Anda memiliki akun penyimpanan geo-redundan, gunakan failover yang dikelola pelanggan untuk kontainer blob yang digunakan Foundry Agent Service. Penyiapan ini memungkinkan Anda memulai failover selama pemadaman regional. Jika Anda hanya menggunakan penyimpanan zona-redundan, hubungi dukungan Microsoft untuk memulihkan data. Proses ini dapat memperluas RTO Anda. Seperti halnya Pencarian AI, jika UI obrolan Anda tidak mendukung unggahan file dan Anda tidak memiliki agen yang menggunakan file statis sebagai pengetahuan, Anda mungkin tidak memerlukan rencana DR untuk kontainer blob.
Konsistensi transaksi: Jika penyimpanan status dalam beban kerja Anda mereferensikan pengidentifikasi agen Azure AI, seperti ID utas atau ID agen, koordinasikan pemulihan di semua penyimpanan data yang relevan. Memulihkan hanya subset dependensi yang dapat mengakibatkan data tanpa induk atau tidak konsisten. Rancang proses DR Anda untuk mempertahankan integritas referensial antara beban kerja Anda dan status layanan agen.
Definisi dan konfigurasi agen: Tentukan agen sebagai kode. Simpan definisi agen, koneksi, permintaan sistem, dan parameter dalam kontrol sumber. Praktik ini memungkinkan Anda menyebarkan ulang agen dari konfigurasi baik yang diketahui jika Anda kehilangan lapisan orkestrasi. Hindari membuat perubahan yang tidak terlampir pada konfigurasi agen melalui portal AI Foundry atau API sarana data. Pendekatan ini memastikan bahwa agen yang Anda sebarkan tetap dapat direproduksi.

Sebelum Anda beralih ke produksi, buat runbook pemulihan yang mengatasi kegagalan dalam status milik aplikasi dan status milik agen.

Keamanan

Keamanan memberikan jaminan terhadap serangan yang disukai dan penyalahgunaan data dan sistem berharga Anda. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keamanan.

Arsitektur ini memperluas fondasi keamanan yang ditetapkan dalam arsitektur referensi obrolan Azure AI Foundry dasar. Perbedaan utamanya adalah penambahan perimeter keamanan jaringan bersama perimeter identitas dari arsitektur dasar. Dari perspektif jaringan, Application Gateway adalah satu-satunya sumber daya yang terekspos internet. Ini membuat aplikasi UI obrolan tersedia untuk pengguna. Dari perspektif identitas, UI obrolan harus mengautentikasi dan mengotorisasi permintaan. Gunakan identitas terkelola jika memungkinkan untuk mengautentikasi aplikasi ke layanan Azure.

Bagian ini menjelaskan pertimbangan jaringan dan keamanan untuk rotasi kunci dan penyempurnaan model Azure OpenAI.

Manajemen identitas dan akses

Arsitektur ini terutama menggunakan identitas terkelola yang ditetapkan sistem untuk autentikasi layanan ke layanan. Anda juga dapat menggunakan identitas terkelola yang ditetapkan pengguna. Dalam kedua kasus, terapkan prinsip-prinsip berikut:

Mengisolasi identitas berdasarkan sumber daya dan fungsi. Provisikan identitas terkelola yang berbeda untuk komponen berikut:
- Akun Azure AI Foundry
- Setiap proyek Azure AI Foundry
- Aplikasi web
- Setiap orkestrator kustom atau kode integrasi
Tetapkan identitas ke sumber daya Azure hanya jika sumber daya tersebut harus mengautentikasi sebagai klien ke layanan Azure lain.
Gunakan jenis identitas yang cocok untuk tujuan. Jika memungkinkan, gunakan identitas beban kerja untuk aplikasi dan otomatisasi, dan gunakan identitas agen untuk agen AI.

Akses karyawan portal Azure AI Foundry

Saat Anda melakukan onboarding karyawan ke proyek Azure AI Foundry, tetapkan izin minimum yang diperlukan untuk peran mereka. Gunakan grup ID Microsoft Entra dan kontrol akses berbasis peran (RBAC) untuk memberlakukan pemisahan tugas. Misalnya, membedakan pengembang agen dari ilmuwan data yang menangani tugas penyempurnaan. Namun, waspadai keterbatasan dan risiko.

Portal Azure AI Foundry menjalankan banyak tindakan dengan menggunakan identitas layanan daripada identitas karyawan. Akibatnya, karyawan yang memiliki peran RBAC terbatas mungkin memiliki visibilitas ke dalam data sensitif, seperti utas obrolan, definisi agen, dan konfigurasi. Desain portal AI Foundry ini secara tidak sengaja dapat melewati batasan akses yang Anda inginkan dan mengekspos lebih banyak informasi daripada yang dimaksudkan.

Untuk mengurangi risiko akses yang tidak sah, batasi penggunaan portal di lingkungan produksi kepada karyawan yang memiliki kebutuhan operasional yang jelas. Untuk sebagian besar karyawan, nonaktifkan atau blokir akses ke portal Azure AI Foundry dalam produksi. Sebagai gantinya, gunakan alur penyebaran otomatis dan infrastruktur sebagai kode (IaC) untuk mengelola konfigurasi agen dan proyek.

Perlakukan pembuatan proyek baru di akun Azure AI Foundry sebagai tindakan istimewa. Proyek yang dibuat melalui portal tidak secara otomatis mewarisi kontrol keamanan jaringan yang dibuat, seperti titik akhir privat atau kelompok keamanan jaringan (NSG). Dan agen baru dalam proyek-proyek tersebut melewati perimeter keamanan yang Anda maksudkan. Terlaksakan pembuatan proyek secara eksklusif melalui proses IaC yang dapat diaudit dan terkontrol.

Penetapan peran dan koneksi proyek Azure AI Foundry

Untuk menggunakan Foundry Agent Service dalam mode Standar, proyek harus memiliki izin administratif pada dependensi Foundry Agent Service. Secara khusus, identitas terkelola proyek harus memiliki penetapan peran yang ditingkatkan pada akun Penyimpanan, Pencarian AI, dan akun Azure Cosmos DB. Izin ini menyediakan akses hampir penuh ke sumber daya ini, termasuk kemampuan untuk membaca, menulis, memodifikasi, atau menghapus data. Untuk menegakkan akses hak istimewa paling sedikit, isolasi sumber daya beban kerja Anda dari dependensi Foundry Agent Service.

Semua agen dalam satu proyek AI Foundry memiliki identitas terkelola yang sama. Jika beban kerja Anda menggunakan beberapa agen yang memerlukan akses ke set sumber daya yang berbeda, prinsip hak istimewa paling sedikit mengharuskan Anda membuat proyek Azure AI Foundry terpisah untuk setiap pola akses agen yang berbeda. Pemisahan ini memungkinkan Anda untuk menetapkan hanya izin minimum yang diperlukan untuk identitas terkelola setiap proyek, yang mengurangi risiko akses yang berlebihan atau tidak diinginkan.

Saat Anda membuat koneksi ke sumber daya eksternal dari dalam Azure AI Foundry, gunakan autentikasi berbasis ID Microsoft Entra jika tersedia. Pendekatan ini menghilangkan kebutuhan untuk mempertahankan rahasia yang telah dibagikan sebelumnya. Cakupan setiap koneksi sehingga hanya proyek pemilik yang dapat menggunakannya. Jika beberapa proyek memerlukan akses ke sumber daya yang sama, buat koneksi terpisah di setiap proyek daripada berbagi satu koneksi di seluruh proyek. Praktik ini memberlakukan batas akses yang ketat dan mencegah proyek di masa mendatang mewarisi akses yang tidak mereka butuhkan.

Hindari membuat koneksi di tingkat akun Azure AI Foundry. Koneksi ini berlaku untuk semua proyek saat ini dan yang akan datang di akun. Mereka secara tidak sengaja dapat memberikan akses luas ke sumber daya, melanggar prinsip hak istimewa paling sedikit, dan meningkatkan risiko paparan data yang tidak sah. Lebih suka koneksi tingkat proyek saja.

Jaringan

Selain akses berbasis identitas, arsitektur ini memerlukan kerahasiaan jaringan.

Desain jaringan mencakup perlindungan berikut:

Satu titik masuk yang aman untuk semua lalu lintas UI obrolan, yang meminimalkan permukaan serangan
Lalu lintas jaringan masuk dan keluar yang difilter dengan menggunakan kombinasi NSG, firewall aplikasi web, rute yang ditentukan pengguna (UDR), dan aturan Azure Firewall
Enkripsi data end-to-end saat transit dengan menggunakan TLS
Privasi jaringan dengan menggunakan Private Link untuk semua koneksi layanan Azure PaaS
Segmentasi logis dan isolasi sumber daya jaringan, dengan subnet khusus untuk setiap pengelompokan komponen utama untuk mendukung kebijakan keamanan terperinci

Alur jaringan

Arsitektur aplikasi web App Service garis besar menguraikan alur masuk dari pengguna ke UI obrolan dan alur dari App Service ke layanan Azure PaaS. Bagian ini berfokus pada interaksi agen.

Saat UI obrolan berkomunikasi dengan agen yang disebarkan di Azure AI Foundry, alur jaringan berikut terjadi:

UI obrolan yang dihosting App Service memulai permintaan HTTPS melalui titik akhir privat ke titik akhir API bidang data Azure AI Foundry.
Saat agen mengakses layanan Azure PaaS, seperti dependensi layanan, penyimpanan pengetahuan kustom, atau alat kustom, agen mengirim permintaan HTTPS dari subnet yang didelegasikan ke titik akhir privat layanan tersebut.
Saat agen mengakses sumber daya di luar jaringan virtual, termasuk API berbasis internet atau layanan eksternal, agen dipaksa untuk merutekan permintaan HTTPS tersebut dari subnet yang didelegasikan melalui Azure Firewall.

Titik akhir privat berfungsi sebagai kontrol keamanan penting dalam arsitektur ini dengan melengkapi keamanan berbasis identitas.

Masuk ke Azure AI Foundry

Arsitektur ini menonaktifkan akses publik ke bidang data Azure AI Foundry dengan hanya mengizinkan lalu lintas melalui tautan privat untuk Azure AI Foundry. Anda dapat mengakses banyak portal Azure AI Foundry melalui situs web portal, tetapi semua fungsionalitas tingkat proyek memerlukan akses jaringan. Portal bergantung pada API sarana data akun AI Foundry Anda, yang hanya dapat dijangkau melalui titik akhir privat. Akibatnya, pengembang dan ilmuwan data harus mengakses portal melalui jump box, jaringan virtual yang di-peering, atau koneksi ExpressRoute atau VPN situs-ke-situs.

Semua interaksi terprogram dengan bidang data agen, seperti dari aplikasi web atau dari kode orkestrasi eksternal saat memanggil inferensi model, juga harus menggunakan titik akhir privat ini. Titik akhir privat didefinisikan pada tingkat akun, bukan tingkat proyek. Oleh karena itu, semua proyek dalam akun berbagi set titik akhir yang sama. Anda tidak dapat mensegmentasi akses jaringan di tingkat proyek, dan semua proyek berbagi paparan jaringan yang sama.

Untuk mendukung konfigurasi ini, siapkan DNS untuk titik akhir Azure AI Foundry FQDN API berikut:

privatelink.services.ai.azure.com
privatelink.openai.azure.com
privatelink.cognitiveservices.azure.com

Diagram berikut menunjukkan bagaimana pengembang AI terhubung melalui Azure Bastion ke jump box komputer virtual (VM). Dari jump box tersebut, penulis dapat mengakses proyek di portal Azure AI Foundry melalui titik akhir privat di jaringan yang sama.

Mengontrol lalu lintas dari subnet agen Azure AI Foundry

Arsitektur ini merutekan semua lalu lintas jaringan keluar (keluar) dari kemampuan Foundry Agent Service melalui subnet yang didelegasikan dalam jaringan virtual Anda. Subnet ini berfungsi sebagai satu-satunya titik keluar untuk tiga dependensi layanan yang diperlukan agen dan sumber pengetahuan eksternal atau koneksi alat apa pun yang digunakan agen. Desain ini membantu mengurangi upaya penyelundupan data dari dalam logika orkestrasi.

Dengan memaksa jalur keluar ini, Anda mendapatkan kontrol penuh atas lalu lintas keluar. Anda dapat menerapkan aturan NSG terperinci, perutean kustom, dan kontrol DNS ke semua lalu lintas agen yang meninggalkan layanan.

Layanan agen menggunakan konfigurasi DNS jaringan virtual untuk menyelesaikan rekaman titik akhir privat dan FQDN eksternal yang diperlukan. Penyiapan ini memastikan bahwa permintaan agen menghasilkan log DNS, yang mendukung audit dan pemecahan masalah.

NSG yang melekat pada subnet keluar agen memblokir semua lalu lintas masuk karena tidak ada ingress yang sah yang harus terjadi. Aturan NSG keluar memungkinkan akses hanya ke subnet titik akhir privat dalam jaringan virtual dan port Protokol Kontrol Transmisi (TCP) 443 untuk lalu lintas yang terikat internet. NSG menolak semua lalu lintas lainnya.

Untuk lebih membatasi lalu lintas internet, arsitektur ini menerapkan UDR ke subnet, yang mengarahkan semua lalu lintas HTTPS melalui Azure Firewall. Firewall mengontrol FQDN mana yang dapat dijangkau agen melalui koneksi HTTPS. Misalnya, jika agen hanya perlu mengakses Grounding dengan API publik Bing , konfigurasikan Azure Firewall untuk memungkinkan lalu lintas ke api.bing.microsoft.com port 443 dari subnet ini. Semua tujuan keluar lainnya ditolak.

Segmentasi dan keamanan jaringan virtual

Arsitektur ini mengelompokkan jaringan virtual dengan menetapkan setiap grup komponen utama ke subnetnya sendiri. Setiap subnet memiliki NSG khusus yang membatasi lalu lintas masuk dan keluar hanya untuk apa yang dibutuhkan komponen.

Tabel berikut ini meringkas konfigurasi NSG dan firewall untuk setiap subnet.

Nama penggunaan atau subnet	Lalu lintas masuk (NSG)	Lalu lintas keluar (NSG)	UDR ke firewall	Aturan keluar firewall
Titik akhir pribadi `snet-privateEndpoints`	Jaringan virtual	Tidak ada lalu lintas yang diizinkan	Ya	Tidak ada lalu lintas yang diizinkan
Application Gateway `snet-appGateway`	Alamat IP sumber pengguna UI obrolan, seperti internet publik, dan sumber yang diperlukan untuk layanan	Subnet titik akhir privat dan item yang diperlukan untuk layanan	Tidak.	-
Layanan Aplikasi `snet-appServicePlan`	Tidak ada lalu lintas yang diizinkan	Titik akhir privat dan Azure Monitor	Ya	Ke Azure Monitor
Layanan Agen Pengecoran `snet-agentsEgress`	Tidak ada lalu lintas yang diizinkan	Titik akhir privat dan internet	Ya	Hanya FQDN publik yang Anda izinkan untuk digunakan agen Anda
Jump box VM `snet-jumpBoxes`	Subnet Bastion Azure	Titik akhir privat dan internet	Ya	Sesuai kebutuhan VM
Membangun agen `snet-buildAgents`	Subnet Bastion Azure	Titik akhir privat dan internet	Ya	Sesuai kebutuhan VM
Azure Bastion `AzureBastionSubnet`	Lihat Akses NSG dan Azure Bastion	Lihat Akses NSG dan Azure Bastion	Tidak.	-
Azure Firewall `AzureFirewallSubnet` `AzureFirewallManagementSubnet`	Tidak ada NSG	Tidak ada NSG	Tidak.	-

Desain ini secara eksplisit menolak semua lalu lintas lainnya, baik melalui aturan NSG atau secara default di Azure Firewall.

Saat Anda menerapkan segmentasi dan keamanan jaringan dalam arsitektur ini, ikuti rekomendasi berikut:

Sebarkan paket Azure DDoS Protection pada alamat IP publik Application Gateway untuk mengurangi serangan volumetrik.
Lampirkan NSG ke setiap subnet yang mendukungnya. Terapkan aturan ketat yang mungkin tanpa mengganggu fungsionalitas yang diperlukan.
Terapkan penerowongan paksa ke semua subnet yang didukung sehingga firewall keluar Anda dapat memeriksa semua lalu lintas keluar. Gunakan penerowongan paksa bahkan pada subnet di mana Anda tidak mengharapkan egress. Metode ini menambahkan ukuran pertahanan mendalam yang melindungi dari penyalahgunaan subnet yang disengaja atau tidak disengaja.

Tata kelola melalui kebijakan

Untuk menyelaraskan dengan garis besar keamanan beban kerja Anda, gunakan Azure Policy dan kebijakan jaringan untuk memastikan bahwa semua sumber daya beban kerja memenuhi kebutuhan Anda. Otomatisasi platform melalui kebijakan mengurangi risiko penyimpangan konfigurasi keamanan dan membantu mengurangi aktivitas validasi manual.

Pertimbangkan untuk menerapkan jenis kebijakan keamanan berikut untuk memperkuat arsitektur Anda:

Nonaktifkan metode autentikasi berbasis kunci atau lokal lainnya dalam layanan seperti layanan Azure AI dan Key Vault.
Memerlukan konfigurasi eksplisit aturan akses jaringan, titik akhir privat, dan NSG.
Memerlukan enkripsi, seperti kunci yang dikelola pelanggan.
Batasi pembuatan sumber daya, seperti membatasi wilayah atau jenis sumber daya.

Pengoptimalan Biaya

Pengoptimalan Biaya berfokus pada cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk optimalisasi biaya.

Perkiraan harga Azure ini memberikan contoh harga untuk arsitektur ini. Contoh ini hanya mencakup komponen dalam arsitektur ini, jadi sesuaikan agar sesuai dengan penggunaan Anda. Komponen termahal dalam skenario adalah Azure Cosmos DB, AI Search, dan DDoS Protection. Biaya penting lainnya termasuk komputasi UI obrolan dan Application Gateway. Optimalkan sumber daya tersebut untuk mengurangi biaya.

Layanan Agen Pengecoran

Saat menggunakan penyebaran standar, Anda harus menyediakan dan mengelola dependensi layanan di langganan Azure Anda sendiri.

Rekomendasi berikut menjelaskan cara mengoptimalkan biaya untuk layanan yang diperlukan ini:

Foundry Agent Service mengelola alokasi unit permintaan (RU) di Azure Cosmos DB. Untuk mengurangi biaya jangka panjang, beli kapasitas yang dipesan untuk Azure Cosmos DB. Selaraskan reservasi dengan durasi dan volume penggunaan yang diharapkan. Perlu diingat bahwa kapasitas yang dipesan memerlukan komitmen di muka dan tidak memiliki fleksibilitas jika pola penggunaan beban kerja Anda berubah secara signifikan.
Jika skenario obrolan Anda tidak memerlukan unggahan file, kecualikan fitur ini di aplikasi Anda. Dalam hal ini, terapkan perubahan konfigurasi berikut:
- Gunakan tingkat penyimpanan redundan lokal (LRS) untuk akun Penyimpanan.
- Konfigurasikan Pencarian AI dengan satu replika alih-alih tiga replika yang direkomendasikan.
Hapus agen yang tidak digunakan secara teratur dan utas terkait dengan menggunakan API SDK atau REST. Agen dan utas kedaluarsa terus menggunakan penyimpanan dan dapat meningkatkan biaya di Azure Cosmos DB, Storage, dan AI Search.
Nonaktifkan fitur pada sumber daya dependen yang tidak diperlukan beban kerja Anda, seperti fitur berikut:
- Ranker semantik dalam Pencarian AI
- Kemampuan penulisan gateway dan multi-wilayah di Azure Cosmos DB
Untuk menghindari biaya bandwidth lintas wilayah, sebarkan Azure Cosmos DB, Storage, dan AI Search di wilayah Azure yang sama dengan Foundry Agent Service.
Hindari mengkolokasikan data khusus beban kerja di sumber daya Azure Cosmos DB atau AI Search yang sama dengan yang digunakan Foundry Agent Service. Dalam beberapa kasus, Anda dapat berbagi sumber daya ini untuk mengurangi kapasitas yang tidak digunakan di RU atau unit pencarian, yang mengurangi biaya. Hanya pertimbangkan berbagi sumber daya setelah penilaian risiko menyeluruh untuk keandalan, keamanan, dan trade-off performa.

Pengetahuan dan alat agen

Foundry Agent Service menjalankan logika agen dengan cara yang tidakdeterministik. Ini mungkin memanggil penyimpanan pengetahuan, alat, atau agen lain yang terhubung untuk setiap permintaan, bahkan jika sumber daya tersebut tidak relevan dengan kueri pengguna. Perilaku ini dapat mengakibatkan panggilan yang tidak perlu ke API eksternal atau sumber data, meningkatkan biaya untuk setiap transaksi, dan memperkenalkan pola penggunaan yang tidak dapat diprediksi yang mempersulit prakiraan anggaran.

Untuk mengontrol biaya dan mempertahankan perilaku yang dapat diprediksi, terapkan strategi berikut:

Hubungkan hanya penyimpanan pengetahuan, alat, atau agen yang kemungkinan akan digunakan dengan sebagian besar pemanggilan agen. Hindari menyambungkan sumber daya yang jarang diperlukan atau yang dikenakan biaya tinggi untuk setiap panggilan kecuali mereka penting.
Desain dan perbaiki permintaan sistem dengan hati-hati untuk menginstruksikan agen untuk meminimalkan panggilan eksternal yang tidak perlu atau berlebihan. Prompt sistem harus memandu agen untuk hanya menggunakan koneksi yang paling relevan untuk setiap permintaan.
Gunakan telemetri Azure AI Foundry untuk memantau API eksternal, penyimpanan pengetahuan, atau alat yang diakses agen, seberapa sering mengaksesnya, dan biaya terkait. Tinjau telemetri ini secara teratur untuk mengidentifikasi pola penggunaan atau lonjakan biaya yang tidak terduga, dan sesuaikan permintaan sistem Anda sesuai kebutuhan.
Ketahuilah bahwa pemanggilan nondeterministik dapat menyulitkan prakiraan biaya, terutama ketika berintrasi dengan API terukur. Jika Anda memerlukan biaya yang dapat diprediksi, pertimbangkan untuk menghost sendiri orkestrator dengan menggunakan kode deterministik.

Azure OpenAI Model

Penyebaran model di Azure AI Foundry menggunakan pendekatan MaaS. Biaya terutama tergantung pada penggunaan atau alokasi yang telah disediakan sebelumnya.

Untuk mengontrol biaya model konsumsi dalam arsitektur ini, gunakan kombinasi pendekatan berikut:

Mengontrol klien. Permintaan klien mendorong sebagian besar biaya dalam model konsumsi, sehingga perilaku agen pengontrol sangat penting.

Untuk mengurangi penggunaan yang tidak perlu, lakukan tindakan berikut:
- Menyetujui semua konsumen model. Jangan mengekspos model dengan cara yang memungkinkan akses tidak terbatas.
- Menerapkan batasan pembatasan token seperti max_tokens dan max_completions melalui logika agen. Kontrol ini hanya tersedia dalam orkestrasi yang dihost sendiri. Foundry Agent Service tidak mendukung fungsionalitas ini.
- Optimalkan input prompt dan panjang respons. Permintaan yang lebih panjang mengonsumsi lebih banyak token, yang meningkatkan biaya. Perintah yang tidak memiliki konteks yang memadai mengurangi efektivitas model. Buat perintah ringkas yang memberikan konteks yang cukup untuk memungkinkan model menghasilkan respons yang berguna. Pastikan Anda mengoptimalkan batas panjang respons.
  
  Tingkat kontrol ini hanya tersedia dalam orkestrasi yang dihost sendiri. Foundry Agent Service tidak menyediakan konfigurasi yang cukup untuk mendukung fungsionalitas ini.
Pilih model yang tepat untuk agen. Pilih model paling murah yang memenuhi persyaratan agen Anda. Hindari menggunakan model biaya yang lebih tinggi kecuali model tersebut penting. Misalnya, implementasi referensi menggunakan GPT-4o alih-alih model yang lebih mahal dan mencapai hasil yang memadai.
Memantau dan mengelola penggunaan. Gunakan Microsoft Cost Management dan telemetri model untuk melacak penggunaan token, menetapkan anggaran, dan membuat pemberitahuan untuk anomali. Tinjau pola penggunaan secara teratur dan sesuaikan kuota atau akses klien sesuai kebutuhan. Untuk informasi selengkapnya, lihat Merencanakan dan mengelola biaya untuk Azure AI Foundry.
Gunakan jenis penyebaran yang tepat. Gunakan harga bayar sesuai pemakaian untuk beban kerja yang tidak dapat diprediksi, dan beralihlah ke throughput yang disediakan saat penggunaan stabil dan dapat diprediksi. Gabungkan kedua opsi saat Anda membuat garis besar yang andal.
Batasi penggunaan playground. Untuk mencegah biaya produksi yang tidak diencana, batasi penggunaan taman bermain Azure AI Foundry hanya untuk lingkungan praproduksi.
Rencanakan penyempurnaan dan pembuatan gambar dengan hati-hati. Fitur-fitur ini memiliki model penagihan yang berbeda. Mereka ditagih per jam atau per batch. Jadwalkan penggunaan agar selaras dengan interval penagihan dan hindari limbah.

Sumber daya keamanan jaringan

Arsitektur ini memerlukan Azure Firewall sebagai titik kontrol keluar. Untuk mengoptimalkan biaya, gunakan tingkat Dasar Azure Firewall kecuali komponen beban kerja Anda lainnya memerlukan fitur lanjutan. Tingkat yang lebih tinggi menambahkan biaya, jadi hanya gunakan jika Anda membutuhkan kemampuannya.

Jika organisasi Anda menggunakan zona pendaratan Azure, pertimbangkan untuk menggunakan firewall bersama dan sumber daya penolakan layanan terdistribusi (DDoS) untuk menunggak atau mengurangi biaya. Beban kerja yang memiliki persyaratan keamanan dan performa serupa dapat memperoleh manfaat dari sumber daya bersama. Pastikan sumber daya bersama tidak menimbulkan risiko keamanan atau operasional. Arsitektur ini, yang disebarkan di zona pendaratan Azure, menggunakan sumber daya bersama.

Keunggulan Operasi

Keunggulan Operasional mencakup proses operasi yang menyebarkan aplikasi dan membuatnya tetap berjalan dalam produksi. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Keunggulan Operasional.

Panduan keunggulan operasional berikut tidak menyertakan elemen aplikasi front-end, yang tetap sama dengan garis besar arsitektur aplikasi web redundan zona yang sangat tersedia.

Saat merencanakan lingkungan eksperimen, pengujian, dan produksi Anda, bangun sumber daya AI Foundry yang berbeda dan terisolasi, termasuk dependensi.

Komputasi agen

Microsoft sepenuhnya mengelola platform komputasi tanpa server untuk REST API Agen Azure AI dan logika implementasi orkestrasi. Orkestrasi yang dihost sendiri memberikan kontrol lebih besar atas karakteristik dan kapasitas runtime, tetapi Anda harus langsung mengelola operasi hari ke-2 untuk platform tersebut. Evaluasi batasan dan tanggung jawab pendekatan Anda untuk memahami operasi hari ke-2 mana yang harus Anda terapkan untuk mendukung lapisan orkestrasi Anda.

Dalam kedua pendekatan, Anda harus mengelola penyimpanan status, seperti riwayat obrolan dan konfigurasi agen untuk durabilitas, pencadangan, dan pemulihan.

Pemantauan

Mirip dengan arsitektur dasar, data diagnostik dari semua layanan dikonfigurasi untuk dikirim ke ruang kerja Log Analytics beban kerja Anda. Semua layanan kecuali App Service mengambil semua log. Dalam produksi, Anda mungkin tidak perlu mengambil semua log. Misalnya, aplikasi UI obrolan mungkin hanya memerlukan AppServiceHTTPLogs, , AppServiceConsoleLogs, AppServiceAppLogsAppServicePlatformLogs, dan AppServiceAuthenticationLogs. Menyetel aliran log ke kebutuhan operasional Anda.

Evaluasi pemberitahuan kustom, seperti pemberitahuan kustom di pemberitahuan garis besar Azure Monitor, untuk sumber daya dalam arsitektur ini. Pertimbangkan pemberitahuan berikut:

Pantau penggunaan token terhadap penyebaran model Anda. Dalam arsitektur ini, Azure AI Foundry melacak penggunaan token melalui integrasinya dengan Application Insights.

Jump box dan VM agen build Anda berada di lokasi yang sangat istimewa, yang memberi VM tersebut garis pandang jaringan ke bidang data semua komponen dalam arsitektur Anda. Pastikan bahwa VM tersebut memancarkan log yang cukup untuk dipahami saat digunakan, siapa yang menggunakannya, dan tindakan apa yang mereka lakukan.

Penerapan versi dan siklus hidup agen

Perlakukan setiap agen sebagai unit yang dapat disebarkan secara independen dalam beban kerja obrolan Anda, kecuali Anda secara khusus merancang aplikasi Anda untuk membuat dan menghapus agen secara dinamis saat runtime. Agen ini memiliki persyaratan manajemen siklus hidup yang mirip dengan layanan mikro lainnya dalam beban kerja Anda.

Untuk mencegah gangguan layanan, pastikan penyebaran agen yang aman dan terkontrol dengan menerapkan pendekatan berikut:

Tentukan agen sebagai kode. Selalu simpan definisi agen, koneksi, permintaan sistem, dan parameter konfigurasi dalam kontrol sumber. Praktik ini memastikan keterlacakan dan reproduksi. Hindari perubahan yang tidak terlampir melalui portal Azure AI Foundry.
Mengotomatiskan penyebaran agen. Gunakan alur integrasi berkelanjutan dan penyebaran berkelanjutan (CI/CD) beban kerja Anda. Gunakan Azure AI Agent SDK untuk membangun, menguji, dan menyebarkan perubahan agen dari agen build yang terhubung dengan jaringan Anda.

Pilih alur agen yang dapat Anda sebarkan secara independen untuk perubahan kecil dan bertahap. Tetapi pastikan bahwa alur memberikan fleksibilitas yang cukup untuk menyebarkannya bersama kode aplikasi Anda saat Anda memerlukan pembaruan terkoordinasi. Untuk mendukung metode ini, pasangankan kode UI obrolan dan agen obrolan Anda secara longgar sehingga perubahan pada satu komponen tidak memerlukan perubahan simultan ke komponen lainnya.
Uji sebelum produksi. Memvalidasi perilaku, permintaan, dan koneksi agen di lingkungan praproduksi. Gunakan kombinasi pengujian otomatis dan manual untuk menangkap regresi, masalah keamanan, dan perubahan perilaku agen yang tidak diinginkan.

Agen yang ditentukan dalam Foundry Agent Service berulah secara nondeterministik, jadi Anda harus menentukan cara mengukur dan mempertahankan tingkat kualitas yang Anda inginkan. Buat dan jalankan rangkaian pengujian yang memeriksa respons ideal terhadap pertanyaan dan skenario pengguna yang realistis.
Versi dan lacak agen. Tetapkan pengidentifikasi versi yang jelas untuk setiap agen. Pertahankan rekaman versi agen mana yang aktif, bersama dengan dependensinya seperti model, sumber data, dan alat. Lebih suka menyebarkan versi agen baru bersama yang sudah ada untuk mengaktifkan peluncuran progresif, pembatalan, dan migrasi pengguna atau sesi yang dikontrol.
Rencanakan untuk failback. Azure AI Foundry tidak menyediakan dukungan bawaan untuk penyebaran agen biru-hijau atau kenari. Jika Anda memerlukan pola penyebaran ini, terapkan lapisan perutean, seperti gateway API atau router kustom, di depan API agen. Lapisan perutean ini memungkinkan Anda untuk menggeser lalu lintas secara bertahap di antara versi agen, memantau dampak, dan melakukan pengalihan penuh saat siap.
Penghapusan agen koordinat. Saat Anda menghapus agen, koordinasikan proses dengan manajemen status aplikasi dan persyaratan pengalaman pengguna Anda. Tangani sesi obrolan aktif dengan tepat. Bergantung pada persyaratan fungsional beban kerja, Anda dapat memigrasikan sesi, menyematkan pengguna ke versi agen lama, atau mengharuskan pengguna untuk memulai sesi baru.

Efisiensi Performa

Efisiensi Performa mengacu pada kemampuan beban kerja Anda untuk menskalakan untuk memenuhi tuntutan pengguna secara efisien. Untuk informasi selengkapnya, lihat Daftar periksa tinjauan desain untuk Efisiensi Kinerja.

Bagian ini membahas efisiensi performa untuk Pencarian AI, penyebaran model, dan Azure AI Foundry.

Efisiensi Performa dalam Pencarian AI

Di Foundry Agent Service, Anda tidak mengontrol kueri tertentu yang dikirim ke indeks Anda karena agen tidak berkode. Untuk mengoptimalkan performa, fokus pada apa yang dapat Anda kontrol dalam indeks. Amati bagaimana agen Anda biasanya mengkueri indeks, dan terapkan panduan untuk menganalisis dan mengoptimalkan performa di Pencarian AI.

Jika penyetelan server indeks saja tidak menyelesaikan semua hambatan, pertimbangkan opsi berikut:

Ganti koneksi langsung ke Pencarian AI dengan koneksi ke API yang Anda miliki. API ini dapat menerapkan kode yang dioptimalkan untuk pola pengambilan agen Anda.
Desain ulang lapisan orkestrasi untuk menggunakan alternatif yang dihost sendiri sehingga Anda dapat menentukan dan mengoptimalkan kueri dalam kode orkestrator Anda sendiri.

Efisiensi Performa dalam penyebaran model

Tentukan apakah aplikasi Anda memerlukan throughput yang disediakan atau dapat menggunakan model bersama (konsumsi). Throughput yang disediakan menyediakan kapasitas yang dipesan dan latensi yang dapat diprediksi, yang penting untuk beban kerja produksi yang memiliki tujuan tingkat layanan yang ketat. Model konsumsi menyediakan layanan upaya terbaik dan mungkin menderita efek tetangga yang berisik.
Pantau penggunaan yang dikelola provisi untuk menghindari provisi berlebih atau kurang provisi.
Pilih model percakapan yang memenuhi persyaratan latensi inferensi Anda.
Sebarkan model di wilayah data yang sama dengan agen Anda untuk meminimalkan latensi jaringan.

Performa agen Azure AI

Agen Azure AI berjalan di back end komputasi tanpa server yang tidak mendukung penyetelan performa kustom. Namun, Anda masih dapat meningkatkan performa melalui desain agen:

Minimalkan jumlah penyimpanan pengetahuan dan alat yang terhubung ke agen obrolan Anda. Setiap koneksi tambahan berpotensi meningkatkan total runtime untuk panggilan agen karena agen mungkin memanggil semua sumber daya yang dikonfigurasi untuk setiap permintaan.
Gunakan Azure Monitor dan Application Insights untuk melacak waktu pemanggilan agen, alat, dan latensi penyimpanan pengetahuan, dan tingkat kesalahan. Tinjau telemetri ini secara teratur untuk mengidentifikasi pengetahuan lambat atau koneksi alat.
Mendesain permintaan sistem yang memandu agen untuk menggunakan koneksi secara efisien. Misalnya, instruksikan agen untuk mengkueri penyimpanan pengetahuan eksternal hanya jika diperlukan, atau untuk menghindari pemanggilan alat yang berlebihan.
Pantau batas layanan atau kuota yang mungkin memengaruhi performa selama penggunaan puncak. Perhatikan indikator pembatasan seperti respons HTTP 429 atau 503, meskipun komputasi tanpa server diskalakan secara otomatis.

Menyebarkan skenario ini

Untuk menyebarkan dan menjalankan implementasi referensi ini, ikuti panduan penyebaran dalam implementasi referensi dasar obrolan Foundry Agent Service.

Kontributor

Microsoft mempertahankan artikel ini. Kontributor berikut menulis artikel ini.

Penulis utama:

Rob Bagby | Pengembang Konten Utama - Pola & Praktik Azure
Chad Kittel | Insinyur Perangkat Lunak Utama - Pola & Praktik Azure

Kontributor lain:

Raouf Aliouat | Insinyur Perangkat Lunak Senior
Freddy Ayala | Arsitek Solusi Cloud
Prabal Deb | Insinyur Perangkat Lunak Utama
Ritesh Modi | Insinyur Perangkat Lunak Utama
Ryan Pfalz | Manajer Program Teknis Senior

Untuk melihat profil LinkedIn nonpublik, masuk ke LinkedIn.

Langkah selanjutnya

Arsitektur obrolan Dasar Azure AI Foundry di zona pendaratan Azure

Perspektif Azure Well-Architected Framework pada beban kerja AI di Azure
Azure OpenAI
Model Azure OpenAI
Pemfilteran konten