Bagikan melalui

LLM dan Azure OpenAI dalam pola Retrieval Augmented Generation (RAG) (pratinjau)

  • Artikel

Penting

Ini adalah fitur pratinjau. Informasi ini berkaitan dengan fitur prarilis yang mungkin dimodifikasi secara substansial sebelum dirilis. Microsoft tidak memberikan jaminan, tersurat maupun tersirat, sehubungan dengan informasi yang diberikan di sini.

Artikel ini menawarkan contoh ilustratif penggunaan Model Bahasa Besar (LLM) dan Azure OpenAI dalam konteks pola Retrieval Augmented Generation (RAG). Secara khusus, ini mengeksplorasi bagaimana Anda dapat menerapkan teknologi ini di dalam Zona Pendaratan Berdaulat, sambil mempertimbangkan pagar pembatas yang penting.

Skenario

Skenario umum adalah menggunakan LLM untuk terlibat dalam percakapan menggunakan data Anda sendiri melalui pola Retrieval Augmented Generation (RAG). Pola ini memungkinkan Anda menggunakan kemampuan penalaran LLM untuk menghasilkan respons berdasarkan data spesifik Anda tanpa menyempurnakan model. Ini memfasilitasi integrasi LLM yang mulus ke dalam proses atau solusi bisnis Anda yang ada.

Cloud untuk Kedaulatan - Arsitektur Referensi AI dan LLM

Microsoft Cloud for Sovereignty menyediakan arsitektur referensi yang menggambarkan arsitektur Retrieval Augmented Generation (RAG) khas dalam Sovereign Landing Zone (SLZ). Ini memberikan gambaran umum tentang pilihan teknologi implementasi umum dan yang direkomendasikan, terminologi, prinsip teknologi, lingkungan konfigurasi umum, dan komposisi layanan yang berlaku.

Arsitektur referensi konfigurasi Sovereign AI dan LLM.

Unduh PDF yang dapat dicetak dari diagram arsitektur referensi ini.

Tahapan/aliran data utama adalah sebagai berikut:

Zona pendaratan aplikasi

Dalam hierarki grup manajemen, layanan ini ditempatkan dalam langganan dalam grup manajemen nonrahasia.

Sumber data dan alur transformasi

Sumber data dan jalur transformasi sering ada dalam suatu organisasi untuk lini operasi bisnis. Ketika Anda mengintegrasikan aplikasi LLM, seperti implementasi RAG, dengan data yang ada, mereka menjadi beban kerja baru.

Untuk memastikan kontrol aliran data, arsitektur referensi merekomendasikan zona pendaratan data yang selaras dengan domain data untuk sumber data dan menempatkan pipa transformasi data dekat dengan sumber tersebut untuk membuat produk data yang digunakan oleh aplikasi LLM. Pendekatan ini memastikan manajemen data yang tepat yang disediakan untuk solusi berbasis LLM, yang dihosting secara terpisah.

Komponen transformasi data memanfaatkan teknologi dan layanan yang berbeda untuk mengubah data menjadi format yang dapat dicari dan digunakan oleh aplikasi berbasis LLM melalui pencarian semantik atau vektor untuk tujuan grounding. Alur ini dapat bekerja sendiri atau mungkin menggunakan layanan AI, seperti layanan Azure AI atau OpenAI, untuk mengubah data untuk dimasukkan ke dalam pencarian vektor atau database pencarian semantik.

Saat menggunakan layanan AI, peering jaringan selalu membuatnya tersedia (melalui hub atau langsung) melalui titik akhir privat mereka. Untuk alasan tata kelola, keamanan, dan kepatuhan, komponen transformasi data memiliki wewenang untuk menentukan data apa dan dalam format apa yang disediakan ke database pencarian untuk beban kerja LLM.

Komponen transformasi data dapat menggunakan berbagai jenis sumber data untuk menawarkan data dengan hasil optimal ke database pencarian yang diandalkan beban kerja LLM. Sumber data ini dapat berupa database SQL, danau data, atau bahkan komputer virtual yang menghosting solusi data kustom, tergantung pada lingkungan pelanggan.

Sumber data tidak boleh diakses langsung oleh aplikasi Orchestrator, tetapi sumber daya ini hanya boleh tersedia dari dalam batas privat jaringan virtual. Ini memberlakukan integrasi Microsoft Azure langsung Virtual Network (misalnya, seperti halnya VM), layanan Private Link, atau titik akhir layanan Virtual Network (hanya jika Private Link atau integrasi Virtual Network langsung tidak tersedia).

Komponen terkait AI dan LLM harus dihosting sebagai beban kerja dalam langganan mereka sendiri di bawah grup manajemen Corp atau Online (tergantung pada apakah akses publik diperlukan atau tidak). Komponen-komponen ini adalah:

Azure OpenAI Service merangkum operasi LLM seperti GPT dan Text Embeddings seperti Ada, membuatnya dapat diakses melalui API standar yang disediakan oleh OpenAI aplikasi Orchestrator.

Aplikasi Orchestrator bertindak sebagai front-end dengan antarmuka berbasis API atau UX, dan mengatur berbagai langkah yang diperlukan untuk membangun pengalaman berbasis RAG. Seringkali, ini adalah aplikasi web atau API web. Langkah-langkah ini biasanya meliputi:

  • Menarik data dari mesin pencari semantik untuk landasan yang cepat
  • Menarik data dari sumber data untuk pembumian yang cepat
  • Dengan benar merangkai permintaan yang berbeda ke LLM

Aplikasi Orchestrator mempertahankan riwayat permintaan yang dikirim dan respons yang diterima untuk memastikan bahwa Layanan Azure OpenAI di-grounding berdasarkan interaksi sebelumnya. Misalnya, dalam pengalaman seperti obrolan seperti ChatGPT atau Bing Chat, aplikasi Orchestrator menyimpan atau menyimpan riwayat sesi percakapan dalam cache sehingga dipertimbangkan dalam alur percakapan oleh backend layanan LLM.

Dalam lingkungan Online , titik akhir aplikasi Orchestrator harus menjadi satu-satunya yang disediakan melalui titik akhir publik yang dilindungi oleh Firewall Aplikasi Web dan layanan perlindungan DDoS. Jika dihosting di lingkungan Corp , tanpa titik akhir publik, Orkestrator dihosting pada layanan yang terintegrasi langsung ke dalam Virtual Network, seperti Virtual Machines atau VM Scale Sets, atau menggunakan layanan yang mendukung titik akhir layanan Private Link atau Virtual Network seperti halnya untuk Azure App Services.

Layanan Pencarian menyediakan data dari berbagai sumber data dalam format yang dioptimalkan untuk penggunaan yang efisien untuk pembumian layanan LLM yang cepat. Microsoft mengusulkan kombinasi vektorisasi dan pencarian semantik untuk mencapai hasil terbaik untuk landasan cepat berdasarkan layanan pencarian, yang didukung oleh Azure AI Search. Menggunakan peringkat semantik secara terukur meningkatkan relevansi pencarian dengan menggunakan pemahaman bahasa untuk menentukan peringkat hasil pencarian. Ini meningkatkan pengalaman pengguna aplikasi RAG, karena landasan prompt menjadi lebih akurat melalui hasil pencarian yang lebih baik dari layanan pencarian sebelum mengirim permintaan ke LLM.

Kombinasi layanan AI dapat digunakan untuk menciptakan pengalaman yang disesuaikan bagi pengguna akhir melalui Orkestrator, atau untuk mengoptimalkan proses penyerapan data. Bayangkan menggunakan layanan pengenal formulir seperti Azure AI Document Intelligence untuk mengekstrak informasi terstruktur dari formulir dan memproses serta meringkas input pengguna secara efisien. Layanan ini kemudian dapat berkolaborasi dengan LLM untuk meringkas temuan kunci dari input formulir yang diakui tersebut. Skenario lain melibatkan penggunaan layanan pengenal dokumen untuk mengonversi dokumen dalam berbagai format seperti PDF atau dokumen kata menjadi teks. Selanjutnya, layanan penyematan teks LLM dapat memvektorisasi teks yang dikenali ini untuk analisis lebih lanjut.

Layanan Azure Private Link digunakan untuk semua komponen sehingga semua layanan hanya dapat diakses dalam lingkungan privat. Satu-satunya pengecualian mungkin adalah aplikasi Orchestrator, yang jika dihosting di zona arahan Online , mungkin ditawarkan secara publik di belakang Firewall Aplikasi Web atau layanan yang sebanding.

Komponen infrastruktur

Komponen infrastruktur dapat dihosting baik sebagai bagian dari beban kerja, atau secara terpusat di hub atau langganan identitas.

Komponen infrastruktur pusat dari implementasi Sovereign Landing Zone adalah Platform Connectivity Hub, yang merupakan jaringan virtual yang disediakan oleh setiap penyebaran Sovereign Landing Zone. Ini ditempatkan dalam langganan konektivitas dalam grup manajemen platform .

Komponen jaringan bersama ditempatkan di jaringan virtual hub. Komponen-komponen ini biasanya meliputi:

  • Sirkuit ExpressRoute atau gateway VPN untuk konektivitas ke jaringan perusahaan perusahaan, agensi, atau organisasi.

  • Firewall dapat diimplementasikan menggunakan appliance atau kombinasi penawaran Azure Firewall, termasuk Web Application Firewall. Solusi ini memungkinkan inspeksi lalu lintas, pemfilteran, dan perutean.

  • Komponen perlindungan DDoS untuk melindungi beban kerja dari serangan penolakan layanan terdistribusi.

  • Zona DNS Privat untuk semua jenis layanan yang digunakan di seluruh lanskap pusat data virtual yang diimplementasikan dengan zona pendaratan.

  • Virtual Network Peering untuk menghubungkan jaringan virtual dari berbagai beban kerja seperti sumber data, transformasi, dan komponen LLM melalui jaringan hub.

  • Kebijakan mengontrol arus lalu lintas melalui firewall hub jika diperlukan.

Pertimbangan

Diagram arsitektur referensi menunjukkan contoh arsitektur representatif yang melibatkan komponen khas beban kerja berbasis LLM RAG dalam konteks Zona Pendaratan Berdaulat. Ada beberapa pertimbangan yang perlu diingat yang tidak dibahas di bagian sebelumnya.

Penyelarasan dengan prinsip-prinsip dari Well-Architected Framework dan Cloud Adoption Framework

Pada bagian sebelumnya, beberapa aspek penyelarasan yang terkait dengan Well-Architected Framework (WAF) dan Cloud Adoption Framework (CAF) disebutkan secara singkat. Penting untuk dicatat bahwa semua keputusan arsitektur harus sepenuhnya selaras dengan prinsip-prinsip inti CAF dan Zona Pendaratan Azure, analitik skala cloud CAF, dan WAF, termasuk perspektif WAF di Azure OpenAI.

Sementara berurusan dengan pagar pembatas adalah prosedur standar di lingkungan zona pendaratan, pertimbangan lain harus dibuat di beberapa area untuk beban kerja LLM dan AI. Sebaiknya ikuti kepatuhan Garis Dasar Keamanan Azure dan standar inisiatif Kebijakan Garis Dasar Kedaulatan saat merancang dan menentukan infrastruktur untuk langganan beban kerja.

Pertimbangan utama untuk menyoroti aplikasi berbasis LLM RAG dari standar ini adalah:

Residensi data dan pemilihan wilayah

Kedaulatan memberlakukan persyaratan ketat pada residensi data, dan oleh karena itu mungkin membatasi penyebaran ke wilayah Azure tertentu dalam SLZ. Memilih wilayah untuk beban kerja LLM dibatasi oleh ketersediaan layanan yang diperlukan:

  • Verifikasi bahwa Azure OpenAI dan Azure AI Search keduanya tersedia di wilayah target tempat Anda menghosting data dan beban kerja Anda untuk alasan residensi dan/atau kedekatan data. Selain itu, layanan ini penting, dari perspektif kinerja, untuk pengalaman pengguna akhir aplikasi.

  • Kedua, ketika melihat Azure OpenAI, ketersediaan model LLM masing-masing penting karena tidak semua model tersedia secara merata di semua wilayah.

  • Jika sumber data atau layanan kognitif lainnya tidak tersedia di wilayah target yang ditentukan, Anda mungkin dapat menemukan dan mengoperasikannya di wilayah lain sesuai dengan persyaratan residensi data Anda. Namun, layanan Azure OpenAI dan Azure AI Search harus berada di wilayah yang sama dengan aplikasi Orchestrator karena alasan performa.

Jaringan

Titik akhir publik tidak diizinkan di lingkungan Corp . Oleh karena itu, semua layanan harus dienkapsulasi dalam Virtual Network. Bergantung pada layanannya, layanan ini mungkin menawarkan kemampuan enkapsulasi langsung seperti VM atau kluster AKS, Private Link, atau titik akhir layanan Virtual Network. Titik akhir layanan Virtual Network harus diganti dengan Private Link jika memungkinkan.

Selain enkapsulasi, akses publik harus dinonaktifkan untuk semua layanan. Terakhir, penegakan kebijakan menggunakan Azure Policy harus diaktifkan sehingga akses publik tidak akan pernah dapat diaktifkan secara tidak sengaja untuk layanan di mana kebijakan penolakan yang sesuai tidak dapat dibangun. Strategi pertahanan mendalam adalah untuk memungkinkan kemampuan audit yang sesuai untuk semua layanan.

Enkripsi saat istirahat dan saat transit

Sebagian besar layanan di Azure mendukung kemampuan enkripsi saat transit dan saat istirahat. Aktifkan enkripsi saat istirahat dan saat transit di semua layanan jika tersedia. Aktifkan versi TLS terbaru, saat ini TLS 1.2, untuk enkripsi transit.

Identitas terkelola

Gunakan identitas terkelola untuk semua layanan dan komunikasi layanan-ke-layanan untuk menghindari pengelolaan rahasia kredensial.

Rotasi kunci di Key Vault

Kapan pun aset keamanan seperti sertifikat diperlukan, aktifkan rotasi kunci untuk rahasia tersebut di Key Vault untuk menjaga kepatuhan.

Kelompok Keamanan Jaringan dan Aplikasi

Dalam lingkungan yang berdaulat dan aman, penggunaan Kelompok Keamanan Jaringan (NSG) dan Kelompok Keamanan Aplikasi (ASG) diberlakukan. Grup keamanan yang hilang menyebabkan penyebaran yang tidak sesuai. Port SSL biasa berguna untuk sebagian besar layanan yang diandalkan beban kerja LLM/RAG karena didasarkan pada HTTPS. Port khusus diperlukan untuk penyerapan data dari sumber ke database pencarian dan vektor. IP publik tidak diizinkan di zona pendaratan Corp . Semua layanan harus dapat diakses di Virtual Network saja, yang memerlukan penggunaan titik akhir layanan Private Link atau Virtual Network untuk layanan PaaS.

Lebih banyak pagar pembatas keamanan dan kedaulatan

Pagar pembatas yang paling penting dan jelas yang tercakup di bagian sebelumnya untuk infrastruktur dan desain aplikasi Anda dapat digunakan kembali bahkan di luar Sovereign atau Azure Landing Zones. Kebijakan global lainnya terkait dengan sumber daya yang dikelola secara terpusat seperti ruang kerja Log Analytics atau penyebaran Microsoft Azure Sentinel di zona pendaratan skala perusahaan. Selama proses desain infrastruktur dan aplikasi Anda, penting untuk mempertimbangkan sumber daya yang dikelola secara terpusat ini. Mengabaikan untuk melakukannya dapat mengakibatkan upaya tambahan dan waktu pasca-penyebaran. Untungnya, fitur kepatuhan kebijakan Azure dapat mengidentifikasi sumber daya yang tidak sesuai setelah penyebaran. Selain itu, Sovereign dan Azure Landing Zones menyediakan kebijakan DeployIfNotExists untuk berbagai sumber daya, yang selanjutnya menyederhanakan proses.

Beberapa contoh pagar pembatas tersebut adalah:

  • Aktivasi masuk ke Ruang Kerja Log Analytics yang dikelola secara terpusat.

  • Integrasi dengan Azure Security Center atau Pertahanan Microsoft untuk Cloud.

  • Integrasi dengan informasi keamanan dan rangkaian manajemen acara (SIEM) seperti Microsoft Azure Sentinel.

  • Integrasi dengan firewall yang dikelola secara terpusat, Firewall Aplikasi Web, atau perlindungan DDoS.

Ini hanya beberapa pagar pembatas yang mungkin Anda identifikasi sebagai persyaratan setelah penerapan awal Anda. Kami menyarankan Anda menguji penyebaran Anda di zona pendaratan pengujian dan secara iteratif mengintegrasikan pemenuhan pagar pembatas tersebut ke dalam infrastruktur dan basis kode aplikasi Anda. Jika itu tidak sepenuhnya mungkin, banyak dari pagar pembatas ini dapat diatasi pasca penyebaran dengan kebijakan DeployIfNotExists .

Menyebarkan skenario ini

Untuk memanfaatkan Model Bahasa Besar (LLM) dan Azure OpenAI berdasarkan pola Retrieval Augmented Generation (RAG) dalam Zona Pendaratan Berdaulat, Anda harus terlebih dahulu menyebarkan dan mengonfigurasi Zona Pendaratan Berdaulat (SLZ) dan menerapkan inisiatif kebijakan Garis Besar Kedaulatan. Untuk gambaran terperinci tentang SLZ dan semua kemampuannya, lihat dokumentasi Sovereign Landing Zone di GitHub.

SLZ menyediakan lingkungan yang menawarkan pagar pembatas melalui kebijakan dan rangkaian kebijakan, penegakan keamanan, dan infrastruktur dasar yang konsisten untuk menyebarkan beban kerja dan aplikasi. SLZ didasarkan pada Azure Landing Zones dan memperluasnya dengan pagar pembatas dan kontrol keamanan khusus untuk persyaratan kedaulatan.

Untuk membantu mempercepat waktu-ke-nilai pelanggan sambil membantu mereka dalam memenuhi tujuan kepatuhan mereka, Microsoft Cloud for Sovereignty termasuk templat beban kerja siap pakai yang dapat diterapkan dan dioperasikan secara konsisten dengan cara yang berulang. Templat beban kerja selaras dengan inisiatif kebijakan Garis Besar Kedaulatan, portofolio kebijakan Cloud for Sovereignty, dan kebijakan default Zona Pendaratan Azure.

Akselerator Asisten Informasi

Asisten Informasi adalah akselerator solusi yang menyediakan titik awal bagi organisasi untuk membangun kemampuan AI generatif kustom mereka sendiri untuk memperluas kekuatan Azure OpenAI kepada pengguna organisasi dan data domain pribadi mereka. Anda dapat menyebarkannya di dalam Cloud for Sovereignty dan menyelaraskannya dengan arsitektur referensi dan panduan yang disediakan dalam artikel ini. Kami menyarankan Anda menyebarkan akselerator dalam zona pendaratan Corp untuk beban kerja internal dan ikuti panduan untuk mengamankan penyebaran ke zona pendaratan Online untuk akses publik.

Akselerator adalah kombinasi kode, dokumentasi, dan sumber daya pendidikan yang disediakan tanpa biaya kepada pelanggan dan mitra yang dapat membantu mempercepat waktu untuk menilai.

Untuk informasi selengkapnya tentang cara menyebarkan dan mengonfigurasi akselerator Asisten Informasi, lihat dokumentasi Asisten Informasi di GitHub. Untuk kasus penggunaan yang dapat Anda capai dengan akselerator ini, lihat Video Asisten Informasi.