Menerapkan pemantauan tingkat lanjut untuk Azure OpenAI melalui gateway

Layanan Azure AI

Azure OpenAI Service

Azure API Management

Microsoft Entra ID

Azure Monitor

Memantau beban kerja yang menyertakan Azure OpenAI Service dapat semudah mengaktifkan diagnostik untuk Azure OpenAI dan menggunakan dasbor yang telah dikonfigurasi sebelumnya. Namun, strategi ini tidak memenuhi beberapa persyaratan pemantauan organisasi yang umum dan lebih kompleks untuk beban kerja AI generatif, seperti:

• Melacak penggunaan berdasarkan klien dan model untuk mengelola kuota dan menerapkan solusi tolak bayar.

• Mencatat input model dan output model untuk berbagai kasus penggunaan audit dan memantau kinerja model.

• Melakukan pemantauan hampir real-time.

Nota

Untuk informasi selengkapnya tentang cara memantau Azure OpenAI secara langsung, lihat Memantau Azure OpenAI.

Diagram berikut menggambarkan pemantauan instans Azure OpenAI tanpa gateway. Gateway tidak diperlukan untuk topologi ini. Keputusan Anda untuk menyertakan gateway bergantung pada apakah skenario pemantauan yang diuraikan adalah bagian dari persyaratan Anda. Artikel ini membahas tantangan yang ditangani setiap skenario pemantauan, bersama dengan manfaat dan biaya menggabungkan gateway untuk setiap skenario.

Diagram yang menunjukkan dua klien berlabel A dan B yang berinteraksi langsung dengan penyebaran model dalam dua instans Azure OpenAI. Klien A secara langsung mengakses penyebaran gpt-35-turbo dan penyebaran gpt-4-o di instans Azure OpenAI yang sama. Klien B mengakses penyebaran gpt-4o di instans Azure OpenAI pertama dan mengakses penyebaran gpt-4 di instans Azure OpenAI kedua. Klien B juga menunjukkan garis putus-putus yang terhubung ke instans gpt-4o dalam penyebaran Azure OpenAI kedua. Kedua instans Azure OpenAI meneruskan metrik dan log Azure OpenAI ke Azure Monitor.

Lacak penggunaan model

Banyak beban kerja atau organisasi perlu melacak penggunaan model Azure OpenAI oleh klien dan model di semua instans Azure OpenAI. Mereka menggunakan informasi ini untuk:

• Terapkan sistem tolak bayar di mana mereka mengalokasikan biaya penggunaan ke organisasi atau pemilik aplikasi yang sesuai.

• Anggaran dan perkiraan untuk penggunaan di masa mendatang.

• Ikat biaya modal dan penggunaan dengan performa model.

Anda dapat menggunakan fungsionalitas pemantauan Azure OpenAI asli untuk melacak telemetri layanan, tetapi ada tantangan.

• Untuk model penagihan balik, Anda harus dapat mengaitkan metrik penggunaan token Azure OpenAI dengan aplikasi atau unit bisnis. Telemetri Azure OpenAI menyertakan alamat IP panggilan dengan oktet terakhir yang ditutupi. Penyamaran ini mungkin membuat pembentukan asosiasi ini ke aplikasi atau unit bisnis menjadi tantangan.

• Instans Azure OpenAI di berbagai wilayah kemungkinan merekam log ke instans Azure Monitor dalam wilayah lokal masing-masing. Proses ini mengharuskan Anda untuk menggabungkan log dari instans Azure Monitor yang berbeda untuk melacak penggunaan di semua instans Azure OpenAI.

Memperkenalkan gateway untuk melacak penggunaan model

Diagram yang memperlihatkan dua klien berlabel A dan B langsung berinteraksi dengan gateway. Gateway memiliki dua panah yang mengarah ke titik akhir privat. Titik akhir privat pertama memiliki dua panah solid yang menunjuk ke penyebaran gpt-35-turbo dan penyebaran gpt-4o dalam penyebaran Azure OpenAI. Titik akhir privat kedua memiliki panah solid yang menunjuk ke penyebaran gpt-4 dan garis putus-putus yang menunjuk ke penyebaran gpt-4o di instans Azure OpenAI kedua. Kedua instans Azure OpenAI meneruskan metrik dan log Azure OpenAI ke Azure Monitor. Gateway memiliki panah yang menunjuk ke Azure Monitor yang menunjukkannya meneruskan metrik penggunaan, termasuk alamat IP klien, model, dan data token.

Perkenalkan gateway ke dalam topologi ini untuk menangkap alamat IP klien lengkap, ID Microsoft Entra (atau identitas alternatif) klien, atau pengidentifikasi kustom untuk unit bisnis, penyewa, atau aplikasi di satu tempat. Anda kemudian dapat menggunakan data ini untuk menerapkan solusi tolak bayar untuk penganggaran dan perkiraan serta untuk melakukan analisis biaya-manfaat model.

Contoh berikut menunjukkan kueri penggunaan yang dimungkinkan saat Anda menggunakan Azure API Management sebagai gateway.

Contoh kueri untuk pemantauan penggunaan

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend modelkey = substring(parse_json(BackendResponseBody)['model'], 0, indexof(parse_json(BackendResponseBody)['model'], '-', 0, -1, 2))
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend completiontokens = parse_json(parse_json(BackendResponseBody)['usage'])['completion_tokens']
| extend totaltokens = parse_json(parse_json(BackendResponseBody)['usage'])['total_tokens']
| extend ip = CallerIpAddress
| summarize
    sum(todecimal(prompttokens)),
    sum(todecimal(completiontokens)),
    sum(todecimal(totaltokens)),
    avg(todecimal(totaltokens))
    by ip, model

Keluaran:

Tangkapan layar yang menunjukkan output pemantauan penggunaan. Ini menunjukkan tabel yang memiliki lima kolom dan lima baris. Kolom mewakili alamat IP, model, dan tiga jenis token. Token ini adalah jumlah total token yang digunakan dalam prompt input, jumlah total token yang dihasilkan oleh model sebagai respons terhadap prompt, dan total gabungan token prompt dan token penyelesaian.

Contoh kueri untuk pemantauan penggunaan perintah

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend prompttext = substring(parse_json(parse_json(BackendResponseBody)['choices'])[0], 0, 100)

Keluaran:

Tangkapan layar yang menunjukkan output pemantauan penggunaan. Ini menunjukkan tabel yang memiliki empat kolom dan tujuh baris. Kolom mewakili waktu yang dihasilkan di UTC, model, token prompt, dan teks prompt.

Input dan output model audit

Persyaratan audit terpusat untuk beban kerja AI generatif adalah memantau input dan output model. Anda mungkin perlu mengetahui apakah respons berasal dari model atau bersumber dari cache. Ada beberapa kasus penggunaan untuk memantau input dan output model. Dalam sebagian besar skenario, aturan audit harus diterapkan secara seragam di semua model untuk input dan output.

Kasus penggunaan berikut adalah untuk memantau input ke model.

• Deteksi ancaman: Analisis input untuk mengidentifikasi dan mengurangi potensi risiko keamanan.

• Deteksi pelanggaran pedoman penggunaan: Analisis input untuk bahasa ofensif atau standar penggunaan lainnya untuk memastikan bahwa sistem profesional, aman, dan tidak bias.

• Kinerja model: Gabungkan dengan output model untuk mengevaluasi performa pada metrik seperti groundedness dan relevansi. Anda dapat menggunakan informasi ini untuk mengatasi masalah performa dengan model atau perintah.

Berikut ini adalah beberapa kasus penggunaan untuk memantau output ke model.

• Deteksi eksfiltrasi data: Analisis output untuk melindungi dari transfer informasi sensitif yang tidak sah.

• Kepatuhan stateful: Pantau output melalui beberapa interaksi dalam percakapan yang sama untuk mendeteksi kebocoran informasi sensitif secara diam-diam.

• Kepatuhan: Pastikan bahwa output mematuhi pedoman perusahaan dan persyaratan peraturan. Dua contohnya adalah model tidak memberikan nasihat hukum atau membuat janji keuangan.

• Kinerja model: Gabungkan dengan input model untuk mengevaluasi performa pada metrik seperti groundedness dan relevansi. Anda dapat menggunakan informasi ini untuk mengatasi masalah performa dengan model atau perintah.

Tantangan untuk mengaudit input dan output model langsung dari model

• Kendala pengelogan model: Beberapa layanan seperti Azure OpenAI tidak mencatat input dan output model.

• Tembolok: Arsitektur yang lebih kompleks mungkin menyajikan respons dari cache. Dalam skenario tersebut, model tidak dipanggil dan tidak mencatat input atau output.

• Percakapan stateful: Status percakapan multi-interaksi mungkin disimpan di luar model. Model tidak tahu interaksi mana yang harus dikorelasikan sebagai percakapan.

• Arsitektur multi-model: Lapisan orkestrasi mungkin secara dinamis memanggil beberapa model untuk menghasilkan respons akhir.

Memperkenalkan gateway untuk mengaudit input dan output model

Diagram yang memperlihatkan dua klien berlabel A dan B langsung berinteraksi dengan gateway. Gateway memiliki dua panah yang mengarah ke titik akhir privat. Titik akhir privat pertama memiliki dua panah solid yang menunjuk ke penyebaran gpt-35-turbo dan penyebaran gpt-4o dalam penyebaran Azure OpenAI. Titik akhir privat kedua memiliki panah solid yang menunjuk ke penyebaran gpt-4 dan garis putus-putus yang menunjuk ke penyebaran gpt-4o di instans Azure OpenAI kedua. Kedua instans Azure OpenAI ditampilkan meneruskan metrik dan log Azure OpenAI ke Azure Monitor. Gateway memiliki panah yang menunjuk ke Azure Monitor yang menunjukkan bahwa ia meneruskan input dan output.

Perkenalkan gateway ke dalam topologi ini untuk menangkap input asli langsung dari klien dan output akhir yang kembali ke klien. Karena gateway adalah abstraksi antara klien dan model dan langsung menerima permintaan dari klien, gateway berada dalam posisi untuk mencatat permintaan mentah dan tidak diproscesikan tersebut. Demikian juga, karena gateway adalah sumber daya yang mengembalikan respons akhir ke klien, gateway juga dapat mencatat respons tersebut.

Gateway memiliki kemampuan unik untuk mencatat permintaan klien dan respons akhir yang diterimanya. Fitur ini berlaku apakah respons berasal langsung dari model, dikumpulkan dari beberapa model, atau diambil dari cache. Selanjutnya, jika klien meneruskan pengidentifikasi percakapan, gateway dapat mencatat pengidentifikasi tersebut dengan input dan output. Anda dapat menggunakan implementasi ini untuk menghubungkan beberapa interaksi percakapan.

Memantau input dan output di gateway memungkinkan Anda menerapkan aturan audit secara seragam di semua model.

Pemantauan hampir real-time

Azure Monitor tidak dioptimalkan untuk pemrosesan mendekati real-time karena latensi yang melekat dalam penyerapan data log. Jika solusi Anda memerlukan pemrosesan lalu lintas yang hampir real-time, Anda dapat mempertimbangkan desain tempat Anda menerbitkan log langsung ke bus pesan dan menggunakan teknologi pemrosesan aliran, seperti Azure Stream Analytics, untuk melakukan operasi berjendela.

Diagram yang memperlihatkan dua klien berlabel A dan B langsung berinteraksi dengan gateway. Gateway memiliki dua panah yang mengarah ke titik akhir privat. Titik akhir privat pertama memiliki dua panah solid yang menunjuk ke penyebaran gpt-35-turbo dan penyebaran gpt-4o dalam penyebaran Azure OpenAI. Titik akhir privat kedua memiliki panah solid yang menunjuk ke penyebaran gpt-4 dan garis putus-putus yang menunjuk ke penyebaran gpt-4o di instans Azure OpenAI kedua. Kedua instans Azure OpenAI ditampilkan meneruskan metrik dan log Azure OpenAI ke Azure Monitor. Gateway memiliki panah yang menunjuk ke Azure Monitor yang menunjukkan bahwa ia meneruskan input dan output. Gateway memiliki panah lain yang mengarah ke bus pesan. Bus pesan memiliki panah yang mengarah ke penyimpanan blob dan ke prosesor aliran.

Pertimbangan saat memperkenalkan gateway untuk pemantauan

• Latency: Memperkenalkan gateway ke dalam arsitektur Anda menambahkan latensi pada respons Anda. Anda perlu memastikan bahwa manfaat observabilitas lebih besar daripada implikasi kinerja.

• Keamanan dan privasi: Pastikan bahwa data pemantauan yang dikumpulkan dengan menggunakan gateway terus mematuhi ekspektasi privasi pelanggan. Data observabilitas harus mematuhi ekspektasi keamanan dan privasi yang ditetapkan dari beban kerja dan tidak melanggar standar privasi pelanggan apa pun. Terus memperlakukan data sensitif apa pun yang diambil melalui pemantauan sebagai data sensitif.

• Keandalan: Tentukan apakah fungsi pemantauan sangat penting untuk fungsionalitas beban kerja. Jika ya, seluruh aplikasi akan mati saat sistem pemantauan tidak tersedia. Jika tidak penting, aplikasi harus terus bekerja dalam keadaan tidak terpantau jika sistem pemantauan tidak aktif. Pahami risiko menambahkan satu titik kegagalan baru, baik melalui kesalahan layanan atau masalah konfigurasi yang disebabkan oleh manusia di gateway.

• Pelaksanaan: Implementasi Anda dapat memanfaatkan gateway siap pakai seperti API Management, termasuk semua konfigurasi yang diperlukan. Pendekatan umum lainnya adalah mengimplementasikan lapisan orkestrasi melalui kode.

Alasan untuk menghindari pengenalan gateway untuk pemantauan

Jika satu aplikasi mengakses satu model, kompleksitas tambahan dalam memperkenalkan gateway kemungkinan besar lebih besar daripada manfaat pemantauan. Klien dapat menangani tanggung jawab pencatatan input dan output. Dan Anda dapat memanfaatkan kemampuan pengelogan asli dari model atau layanan yang Anda gunakan. Gateway menjadi bermanfaat ketika Anda memiliki beberapa klien atau beberapa model yang perlu Anda pantau.

Langkah selanjutnya

Implementasi gateway untuk beban kerja Anda memberikan manfaat di luar manfaat perutean back-end beberapa taktis yang dijelaskan dalam artikel ini. Untuk informasi selengkapnya, lihat Mengakses Azure OpenAI dan model bahasa lainnya melalui gateway.

Sumber daya terkait

• Merancang beban kerja AI yang dirancang dengan baik
• API gateway di API Management

Memantau beban kerja yang menyertakan Azure OpenAI Service dapat semudah mengaktifkan diagnostik untuk Azure OpenAI dan menggunakan dasbor yang telah dikonfigurasi sebelumnya. Namun, strategi ini tidak memenuhi beberapa persyaratan pemantauan organisasi yang umum dan lebih kompleks untuk beban kerja AI generatif, seperti:

• Melacak penggunaan berdasarkan klien dan model untuk mengelola kuota dan menerapkan solusi tolak bayar.

• Mencatat input model dan output model untuk berbagai kasus penggunaan audit dan memantau kinerja model.

• Melakukan pemantauan hampir real-time.

Nota

Untuk informasi selengkapnya tentang cara memantau Azure OpenAI secara langsung, lihat Memantau Azure OpenAI.

Diagram berikut menggambarkan pemantauan instans Azure OpenAI tanpa gateway. Gateway tidak diperlukan untuk topologi ini. Keputusan Anda untuk menyertakan gateway bergantung pada apakah skenario pemantauan yang diuraikan adalah bagian dari persyaratan Anda. Artikel ini membahas tantangan yang ditangani setiap skenario pemantauan, bersama dengan manfaat dan biaya menggabungkan gateway untuk setiap skenario.

Diagram yang menunjukkan dua klien berlabel A dan B yang berinteraksi langsung dengan penyebaran model dalam dua instans Azure OpenAI. Klien A secara langsung mengakses penyebaran gpt-35-turbo dan penyebaran gpt-4-o di instans Azure OpenAI yang sama. Klien B mengakses penyebaran gpt-4o di instans Azure OpenAI pertama dan mengakses penyebaran gpt-4 di instans Azure OpenAI kedua. Klien B juga menunjukkan garis putus-putus yang terhubung ke instans gpt-4o dalam penyebaran Azure OpenAI kedua. Kedua instans Azure OpenAI meneruskan metrik dan log Azure OpenAI ke Azure Monitor.

Lacak penggunaan model

Banyak beban kerja atau organisasi perlu melacak penggunaan model Azure OpenAI oleh klien dan model di semua instans Azure OpenAI. Mereka menggunakan informasi ini untuk:

• Terapkan sistem tolak bayar di mana mereka mengalokasikan biaya penggunaan ke organisasi atau pemilik aplikasi yang sesuai.

• Anggaran dan perkiraan untuk penggunaan di masa mendatang.

• Ikat biaya modal dan penggunaan dengan performa model.

Anda dapat menggunakan fungsionalitas pemantauan Azure OpenAI asli untuk melacak telemetri layanan, tetapi ada tantangan.

• Untuk model penagihan balik, Anda harus dapat mengaitkan metrik penggunaan token Azure OpenAI dengan aplikasi atau unit bisnis. Telemetri Azure OpenAI menyertakan alamat IP panggilan dengan oktet terakhir yang ditutupi. Penyamaran ini mungkin membuat pembentukan asosiasi ini ke aplikasi atau unit bisnis menjadi tantangan.

• Instans Azure OpenAI di berbagai wilayah kemungkinan merekam log ke instans Azure Monitor dalam wilayah lokal masing-masing. Proses ini mengharuskan Anda untuk menggabungkan log dari instans Azure Monitor yang berbeda untuk melacak penggunaan di semua instans Azure OpenAI.

Memperkenalkan gateway untuk melacak penggunaan model

Diagram yang memperlihatkan dua klien berlabel A dan B langsung berinteraksi dengan gateway. Gateway memiliki dua panah yang mengarah ke titik akhir privat. Titik akhir privat pertama memiliki dua panah solid yang menunjuk ke penyebaran gpt-35-turbo dan penyebaran gpt-4o dalam penyebaran Azure OpenAI. Titik akhir privat kedua memiliki panah solid yang menunjuk ke penyebaran gpt-4 dan garis putus-putus yang menunjuk ke penyebaran gpt-4o di instans Azure OpenAI kedua. Kedua instans Azure OpenAI meneruskan metrik dan log Azure OpenAI ke Azure Monitor. Gateway memiliki panah yang menunjuk ke Azure Monitor yang menunjukkannya meneruskan metrik penggunaan, termasuk alamat IP klien, model, dan data token.

Perkenalkan gateway ke dalam topologi ini untuk menangkap alamat IP klien lengkap, ID Microsoft Entra (atau identitas alternatif) klien, atau pengidentifikasi kustom untuk unit bisnis, penyewa, atau aplikasi di satu tempat. Anda kemudian dapat menggunakan data ini untuk menerapkan solusi tolak bayar untuk penganggaran dan perkiraan serta untuk melakukan analisis biaya-manfaat model.

Contoh berikut menunjukkan kueri penggunaan yang dimungkinkan saat Anda menggunakan Azure API Management sebagai gateway.

Contoh kueri untuk pemantauan penggunaan

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend modelkey = substring(parse_json(BackendResponseBody)['model'], 0, indexof(parse_json(BackendResponseBody)['model'], '-', 0, -1, 2))
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend completiontokens = parse_json(parse_json(BackendResponseBody)['usage'])['completion_tokens']
| extend totaltokens = parse_json(parse_json(BackendResponseBody)['usage'])['total_tokens']
| extend ip = CallerIpAddress
| summarize
    sum(todecimal(prompttokens)),
    sum(todecimal(completiontokens)),
    sum(todecimal(totaltokens)),
    avg(todecimal(totaltokens))
    by ip, model

Keluaran:

Tangkapan layar yang menunjukkan output pemantauan penggunaan. Ini menunjukkan tabel yang memiliki lima kolom dan lima baris. Kolom mewakili alamat IP, model, dan tiga jenis token. Token ini adalah jumlah total token yang digunakan dalam prompt input, jumlah total token yang dihasilkan oleh model sebagai respons terhadap prompt, dan total gabungan token prompt dan token penyelesaian.

Contoh kueri untuk pemantauan penggunaan perintah

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend prompttext = substring(parse_json(parse_json(BackendResponseBody)['choices'])[0], 0, 100)

Keluaran:

Tangkapan layar yang menunjukkan output pemantauan penggunaan. Ini menunjukkan tabel yang memiliki empat kolom dan tujuh baris. Kolom mewakili waktu yang dihasilkan di UTC, model, token prompt, dan teks prompt.

Input dan output model audit

Persyaratan audit terpusat untuk beban kerja AI generatif adalah memantau input dan output model. Anda mungkin perlu mengetahui apakah respons berasal dari model atau bersumber dari cache. Ada beberapa kasus penggunaan untuk memantau input dan output model. Dalam sebagian besar skenario, aturan audit harus diterapkan secara seragam di semua model untuk input dan output.

Kasus penggunaan berikut adalah untuk memantau input ke model.

• Deteksi ancaman: Analisis input untuk mengidentifikasi dan mengurangi potensi risiko keamanan.

• Deteksi pelanggaran pedoman penggunaan: Analisis input untuk bahasa ofensif atau standar penggunaan lainnya untuk memastikan bahwa sistem profesional, aman, dan tidak bias.

• Kinerja model: Gabungkan dengan output model untuk mengevaluasi performa pada metrik seperti groundedness dan relevansi. Anda dapat menggunakan informasi ini untuk mengatasi masalah performa dengan model atau perintah.

Berikut ini adalah beberapa kasus penggunaan untuk memantau output ke model.

• Deteksi eksfiltrasi data: Analisis output untuk melindungi dari transfer informasi sensitif yang tidak sah.

• Kepatuhan stateful: Pantau output melalui beberapa interaksi dalam percakapan yang sama untuk mendeteksi kebocoran informasi sensitif secara diam-diam.

• Kepatuhan: Pastikan bahwa output mematuhi pedoman perusahaan dan persyaratan peraturan. Dua contohnya adalah model tidak memberikan nasihat hukum atau membuat janji keuangan.

• Kinerja model: Gabungkan dengan input model untuk mengevaluasi performa pada metrik seperti groundedness dan relevansi. Anda dapat menggunakan informasi ini untuk mengatasi masalah performa dengan model atau perintah.

Tantangan untuk mengaudit input dan output model langsung dari model

• Kendala pengelogan model: Beberapa layanan seperti Azure OpenAI tidak mencatat input dan output model.

• Tembolok: Arsitektur yang lebih kompleks mungkin menyajikan respons dari cache. Dalam skenario tersebut, model tidak dipanggil dan tidak mencatat input atau output.

• Percakapan stateful: Status percakapan multi-interaksi mungkin disimpan di luar model. Model tidak tahu interaksi mana yang harus dikorelasikan sebagai percakapan.

• Arsitektur multi-model: Lapisan orkestrasi mungkin secara dinamis memanggil beberapa model untuk menghasilkan respons akhir.

Memperkenalkan gateway untuk mengaudit input dan output model

Diagram yang memperlihatkan dua klien berlabel A dan B langsung berinteraksi dengan gateway. Gateway memiliki dua panah yang mengarah ke titik akhir privat. Titik akhir privat pertama memiliki dua panah solid yang menunjuk ke penyebaran gpt-35-turbo dan penyebaran gpt-4o dalam penyebaran Azure OpenAI. Titik akhir privat kedua memiliki panah solid yang menunjuk ke penyebaran gpt-4 dan garis putus-putus yang menunjuk ke penyebaran gpt-4o di instans Azure OpenAI kedua. Kedua instans Azure OpenAI ditampilkan meneruskan metrik dan log Azure OpenAI ke Azure Monitor. Gateway memiliki panah yang menunjuk ke Azure Monitor yang menunjukkan bahwa ia meneruskan input dan output.

Perkenalkan gateway ke dalam topologi ini untuk menangkap input asli langsung dari klien dan output akhir yang kembali ke klien. Karena gateway adalah abstraksi antara klien dan model dan langsung menerima permintaan dari klien, gateway berada dalam posisi untuk mencatat permintaan mentah dan tidak diproscesikan tersebut. Demikian juga, karena gateway adalah sumber daya yang mengembalikan respons akhir ke klien, gateway juga dapat mencatat respons tersebut.

Gateway memiliki kemampuan unik untuk mencatat permintaan klien dan respons akhir yang diterimanya. Fitur ini berlaku apakah respons berasal langsung dari model, dikumpulkan dari beberapa model, atau diambil dari cache. Selanjutnya, jika klien meneruskan pengidentifikasi percakapan, gateway dapat mencatat pengidentifikasi tersebut dengan input dan output. Anda dapat menggunakan implementasi ini untuk menghubungkan beberapa interaksi percakapan.

Memantau input dan output di gateway memungkinkan Anda menerapkan aturan audit secara seragam di semua model.

Pemantauan hampir real-time

Azure Monitor tidak dioptimalkan untuk pemrosesan mendekati real-time karena latensi yang melekat dalam penyerapan data log. Jika solusi Anda memerlukan pemrosesan lalu lintas yang hampir real-time, Anda dapat mempertimbangkan desain tempat Anda menerbitkan log langsung ke bus pesan dan menggunakan teknologi pemrosesan aliran, seperti Azure Stream Analytics, untuk melakukan operasi berjendela.

Diagram yang memperlihatkan dua klien berlabel A dan B langsung berinteraksi dengan gateway. Gateway memiliki dua panah yang mengarah ke titik akhir privat. Titik akhir privat pertama memiliki dua panah solid yang menunjuk ke penyebaran gpt-35-turbo dan penyebaran gpt-4o dalam penyebaran Azure OpenAI. Titik akhir privat kedua memiliki panah solid yang menunjuk ke penyebaran gpt-4 dan garis putus-putus yang menunjuk ke penyebaran gpt-4o di instans Azure OpenAI kedua. Kedua instans Azure OpenAI ditampilkan meneruskan metrik dan log Azure OpenAI ke Azure Monitor. Gateway memiliki panah yang menunjuk ke Azure Monitor yang menunjukkan bahwa ia meneruskan input dan output. Gateway memiliki panah lain yang mengarah ke bus pesan. Bus pesan memiliki panah yang mengarah ke penyimpanan blob dan ke prosesor aliran.

Pertimbangan saat memperkenalkan gateway untuk pemantauan

• Latency: Memperkenalkan gateway ke dalam arsitektur Anda menambahkan latensi pada respons Anda. Anda perlu memastikan bahwa manfaat observabilitas lebih besar daripada implikasi kinerja.

• Keamanan dan privasi: Pastikan bahwa data pemantauan yang dikumpulkan dengan menggunakan gateway terus mematuhi ekspektasi privasi pelanggan. Data observabilitas harus mematuhi ekspektasi keamanan dan privasi yang ditetapkan dari beban kerja dan tidak melanggar standar privasi pelanggan apa pun. Terus memperlakukan data sensitif apa pun yang diambil melalui pemantauan sebagai data sensitif.

• Keandalan: Tentukan apakah fungsi pemantauan sangat penting untuk fungsionalitas beban kerja. Jika ya, seluruh aplikasi akan mati saat sistem pemantauan tidak tersedia. Jika tidak penting, aplikasi harus terus bekerja dalam keadaan tidak terpantau jika sistem pemantauan tidak aktif. Pahami risiko menambahkan satu titik kegagalan baru, baik melalui kesalahan layanan atau masalah konfigurasi yang disebabkan oleh manusia di gateway.

• Pelaksanaan: Implementasi Anda dapat memanfaatkan gateway siap pakai seperti API Management, termasuk semua konfigurasi yang diperlukan. Pendekatan umum lainnya adalah mengimplementasikan lapisan orkestrasi melalui kode.

Alasan untuk menghindari pengenalan gateway untuk pemantauan

Jika satu aplikasi mengakses satu model, kompleksitas tambahan dalam memperkenalkan gateway kemungkinan besar lebih besar daripada manfaat pemantauan. Klien dapat menangani tanggung jawab pencatatan input dan output. Dan Anda dapat memanfaatkan kemampuan pengelogan asli dari model atau layanan yang Anda gunakan. Gateway menjadi bermanfaat ketika Anda memiliki beberapa klien atau beberapa model yang perlu Anda pantau.

Langkah selanjutnya

Implementasi gateway untuk beban kerja Anda memberikan manfaat di luar manfaat perutean back-end beberapa taktis yang dijelaskan dalam artikel ini. Untuk informasi selengkapnya, lihat Mengakses Azure OpenAI dan model bahasa lainnya melalui gateway.

Sumber daya terkait

• Merancang beban kerja AI yang dirancang dengan baik
• API gateway di API Management