Dokumen ini memberikan arsitektur referensi yang dapat Anda gunakan untuk mendesain infrastruktur guna menjalankan aplikasi kecerdasan buatan (AI) generatif dengan retrieval-augmented generation (RAG). Audiens yang dituju untuk dokumen ini mencakup developer dan administrator aplikasi AI generatif serta arsitek cloud. Dokumen ini mengasumsikan pemahaman dasar tentang konsep AI, machine learning (ML), dan model bahasa besar (LLM). Dokumen ini tidak memberikan panduan tentang cara mendesain dan mengembangkan aplikasi AI generatif.
Arsitektur
Diagram berikut menunjukkan tampilan tingkat tinggi arsitektur untuk aplikasi AI generatif berkemampuan RAG di Google Cloud:
Arsitektur ini berisi komponen yang saling terhubung berikut:
| Komponen | Tujuan | Interactions |
|---|---|---|
| Subsistem penyerapan data | Siapkan dan proses data eksternal yang digunakan untuk mengaktifkan kemampuan RAG. | Subsistem penyerapan data berinteraksi dengan subsistem lain dalam arsitektur melalui lapisan database. |
| Subsistem inferensi | Menangani alur permintaan-respons antara aplikasi AI generatif dan penggunanya. | Subsistem penayangan berinteraksi dengan subsistem penyerapan data melalui lapisan database. |
| Subsistem evaluasi kualitas | Mengevaluasi kualitas respons yang dihasilkan oleh subsistem inferensi. | Subsistem evaluasi kualitas berinteraksi dengan subsistem inferensi secara langsung dan dengan subsistem penyerapan data melalui lapisan database. |
| Database | Menyimpan data berikut:
|
Semua subsistem dalam arsitektur berinteraksi dengan database. |
Diagram berikut menunjukkan tampilan mendetail arsitektur:
Bagian berikut memberikan deskripsi mendetail terkait komponen dan aliran data dalam tiap subsistem arsitektur.
Subsistem penyerapan data
Subsistem penyerapan data menyerap data dari sumber eksternal seperti file, database, dan layanan streaming. Data yang diupload mencakup perintah untuk evaluasi kualitas. Subsistem penyerapan data memberikan kemampuan RAG dalam arsitektur. Diagram berikut menunjukkan detail subsistem penyerapan data dalam arsitektur:
Berikut adalah langkah-langkah dalam alur penyerapan data:
- Data diupload ke bucket Cloud Storage. Sumber data dapat berupa aplikasi, database, atau layanan streaming.
- Saat data diupload ke Cloud Storage, pesan akan dipublikasikan ke topik Pub/Sub.
- Pub/Sub memicu fungsi Cloud Run untuk memproses data yang diupload.
- Fungsi ini dimulai menggunakan data konfigurasi yang disimpan dalam database AlloyDB untuk PostgreSQL.
- Fungsi ini mengurai data mentah, memformatnya sesuai kebutuhan, lalu membaginya menjadi beberapa bagian.
Fungsi ini menggunakan model embedding yang sesuai di Vertex AI untuk membuat embedding vektor dari data yang diserap.
Fungsi ini menyimpan embedding dalam database AlloyDB untuk PostgreSQL yang mengaktifkan ekstensi
pgvector. Seperti yang dijelaskan di bagian berikut, saat memproses permintaan pengguna, subsistem inferensi akan menggunakan embedding dalam database vektor untuk mengambil data spesifik domain yang relevan.
Subsistem inferensi
Subsistem inferensi menangani alur permintaan-respons antara aplikasi AI generatif dan penggunanya. Diagram berikut menunjukkan detail subsistem penayangan dalam arsitektur:
Berikut adalah langkah-langkah dalam alur permintaan-respons di subsistem penayangan:
- Pengguna mengirimkan permintaan ke aplikasi AI generatif melalui frontend (misalnya, chatbot atau aplikasi seluler).
Aplikasi AI generatif mengonversi permintaan bahasa alami menjadi embedding.
Aplikasi ini menyelesaikan bagian pengambilan pendekatan RAG:
- Aplikasi ini melakukan penelusuran semantik untuk embedding dalam penyimpanan vektor AlloyDB untuk PostgreSQL yang dikelola subsistem penyerapan data. Penelusuran semantik membantu menemukan embedding berdasarkan intent perintah, bukan konten tekstualnya.
- Aplikasi ini menggabungkan permintaan asli dengan data mentah yang diambil berdasarkan embedding yang cocok untuk membuat perintah kontekstual.
Aplikasi ini mengirimkan perintah kontekstual ke stack inferensi LLM yang berjalan di Vertex AI.
Stack inferensi LLM menggunakan LLM AI generatif, yang dapat berupa LLM dasar atau LLM kustom, dan menghasilkan respons yang dibatasi pada konteks yang disediakan.
- Aplikasi ini dapat menyimpan log aktivitas permintaan-respons di Cloud Logging. Anda dapat melihat dan menggunakan log untuk pemantauan menggunakan Cloud Monitoring. Google tidak mengakses atau menggunakan data log.
- Aplikasi memuat respons ke BigQuery untuk analisis offline.
Aplikasi ini menyaring respons menggunakan filter responsible AI.
Aplikasi ini mengirimkan respons yang disaring kepada pengguna melalui frontend.
Subsistem evaluasi kualitas
Diagram berikut menunjukkan detail subsistem evaluasi kualitas dalam arsitektur:
Saat menerima permintaan, subsistem evaluasi kualitas akan melakukan hal berikut:
- Pub/Sub memicu fungsi Cloud Run.
- Fungsi ini dimulai menggunakan data konfigurasi yang disimpan dalam database AlloyDB untuk PostgreSQL.
- Fungsi ini menarik perintah evaluasi dari database AlloyDB untuk PostgreSQL. Perintah tersebut sebelumnya diupload ke database oleh subsistem penyerapan data.
Fungsi ini menggunakan perintah evaluasi untuk menilai kualitas respons yang dihasilkan oleh subsistem inferensi.
Output evaluasi ini terdiri dari skor evaluasi untuk metrik seperti akurasi dan relevansi faktual.
Fungsi ini memuat skor evaluasi dan perintah serta respons yang dievaluasi ke BigQuery untuk analisis di masa mendatang.
Produk yang digunakan
Berikut adalah ringkasan semua produk Google Cloud yang digunakan oleh arsitektur sebelumnya:
- Vertex AI: Platform ML yang memungkinkan Anda melatih dan men-deploy model ML dan aplikasi AI, serta menyesuaikan LLM untuk digunakan dalam aplikasi yang didukung AI.
- Fungsi Cloud Run: Platform komputasi serverless yang memungkinkan Anda menjalankan fungsi tujuan tunggal secara langsung di Google Cloud.
- BigQuery: Data warehouse perusahaan yang membantu Anda mengelola dan menganalisis data dengan fitur bawaan seperti machine learning, analisis geospasial, dan business intelligence.
- Cloud Storage: Penyimpanan objek berbiaya rendah dan tanpa batas untuk beragam jenis data. Data dapat diakses dari dalam dan luar Google Cloud, serta direplikasi di berbagai lokasi untuk redundansi.
- AlloyDB untuk PostgreSQL: Layanan database yang kompatibel dengan PostgreSQL dan terkelola sepenuhnya yang didesain untuk workload dengan tuntutan tinggi, termasuk pemrosesan transaksional dan analisis hybrid.
- Pub/Sub: Layanan pesan asinkron dan skalabel yang memisahkan layanan yang menghasilkan pesan dari layanan yang memproses pesan tersebut.
- Cloud Logging: Sistem pengelolaan log real-time dengan penyimpanan, penelusuran, analisis, dan pemberitahuan.
- Cloud Monitoring: Layanan yang memberikan visibilitas terkait performa, ketersediaan, dan kondisi aplikasi serta infrastruktur Anda.
Kasus penggunaan
RAG adalah teknik efektif untuk meningkatkan kualitas output yang dihasilkan dari LLM. Bagian ini memberikan contoh kasus penggunaan yang dapat Anda gunakan untuk aplikasi AI generatif berkemampuan RAG.
Rekomendasi produk yang dipersonalisasi
Situs belanja online dapat menggunakan chatbot yang didukung LLM untuk membantu pelanggan menemukan produk atau mendapatkan bantuan terkait belanja. Pertanyaan dari pengguna dapat dilengkapi dengan menggunakan data historis tentang perilaku pembelian dan pola interaksi situs pengguna. Data tersebut dapat mencakup ulasan dan masukan pengguna yang disimpan di penyimpanan data tidak terstruktur atau metrik terkait penelusuran yang disimpan di data warehouse analisis web. Pertanyaan yang telah diubah tersebut kemudian dapat diproses oleh LLM untuk menghasilkan respons yang dipersonalisasi yang mungkin lebih menarik dan memikat bagi pengguna.
Sistem bantuan klinis
Dokter di rumah sakit perlu menganalisis dan mendiagnosis kondisi kesehatan pasien dengan cepat untuk membuat keputusan tentang perawatan dan pengobatan yang tepat. Aplikasi AI generatif yang menggunakan LLM medis seperti Med-PaLM dapat digunakan untuk membantu dokter dalam proses diagnosis klinis mereka. Respons yang dihasilkan aplikasi dapat didasarkan pada catatan pasien historis dengan mengontekstualisasikan perintah dokter dengan data dari database catatan kesehatan elektronik (EHR) rumah sakit atau dari pusat informasi eksternal seperti PubMed.
Riset hukum yang efisien
Penelitian hukum yang didukung teknologi AI generatif memungkinkan pengacara dengan cepat mengkueri sejumlah besar hukum dan hukum kasus untuk mengidentifikasi preseden hukum yang relevan atau meringkas konsep hukum yang kompleks. Hasil riset tersebut dapat ditingkatkan dengan melengkapi perintah pengacara menggunakan data yang diambil dari korpus kontrak eksklusif firma hukum, komunikasi hukum sebelumnya, dan catatan kasus internal. Pendekatan desain ini memastikan bahwa respons yang dihasilkan relevan dengan bidang hukum yang dikuasai pengacara.
Alternatif desain
Bagian ini menyajikan pendekatan desain alternatif yang dapat Anda pertimbangkan untuk aplikasi AI generatif berkemampuan RAG di Google Cloud.
Penelusuran vektor yang terkelola sepenuhnya
Jika Anda memerlukan arsitektur yang menggunakan produk penelusuran vektor yang dikelola sepenuhnya, Anda dapat menggunakan Vertex AI dan Vector Search, yang menyediakan infrastruktur penayangan yang dioptimalkan untuk penelusuran vektor berskala sangat besar. Untuk mengetahui informasi selengkapnya, lihat Infrastruktur RAG untuk AI generatif menggunakan Vertex AI dan Vector Search.
Alat dan model open source
Jika Anda ingin membangun dan men-deploy aplikasi AI generatif berkemampuan RAG dengan cepat menggunakan alat dan model open source Ray, Hugging Face, dan LangChain, lihat Infrastruktur RAG untuk AI generatif menggunakan GKE dan Cloud SQL.
Arsitektur RAG lainnya
Untuk mengetahui informasi tentang opsi arsitektur tambahan untuk workload RAG, lihat AI Generatif dengan RAG.
Pertimbangan desain
Bagian ini memberikan panduan untuk membantu Anda mengembangkan arsitektur AI generatif yang mendukung RAG di Google Cloud yang memenuhi persyaratan spesifik Anda untuk keamanan dan kepatuhan, keandalan, biaya, dan performa. Panduan di bagian ini tidak lengkap. Bergantung pada persyaratan spesifik aplikasi AI generatif Anda serta produk dan fitur yang Anda gunakan, Anda mungkin perlu mempertimbangkan faktor desain dan kompromi tambahan. Google Cloud
Keamanan dan kepatuhan
Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan saat mendesain dan membangun aplikasi AI generatif berkemampuan RAG di Google Cloud yang memenuhi persyaratan keamanan dan kepatuhan Anda.
| Produk | Pertimbangan desain |
|---|---|
| Vertex AI | Vertex AI mendukung Google Cloud kontrol keamanan yang dapat Anda gunakan untuk memenuhi persyaratan Anda terkait residensi data, enkripsi data, keamanan jaringan, dan transparansi akses. Untuk mengetahui informasi selengkapnya, lihat Kontrol keamanan untuk Vertex AI dan Kontrol keamanan untuk AI Generatif. |
| Cloud Run Functions | Untuk melindungi data Anda dengan menggunakan kunci yang Anda kontrol, Anda dapat menggunakan kunci enkripsi yang dikelola pelanggan (CMEK). Untuk mengetahui informasi selengkapnya, lihat Menggunakan kunci enkripsi yang dikelola pelanggan. |
| AlloyDB untuk PostgreSQL |
Secara default, data yang disimpan di AlloyDB untuk PostgreSQL dienkripsi menggunakan Google-owned and Google-managed encryption keys. Jika perlu menggunakan kunci enkripsi yang Anda kontrol dan kelola, Anda dapat menggunakan CMEK. Untuk mengetahui informasi selengkapnya, lihat Tentang CMEK. Untuk mengurangi risiko pemindahan data yang tidak sah dari database AlloyDB untuk PostgreSQL, Anda dapat membuat perimeter layanan menggunakan Kontrol Layanan VPC. Secara default, instance AlloyDB untuk PostgreSQL hanya menerima koneksi yang menggunakan SSL. Untuk lebih mengamankan koneksi ke database AlloyDB untuk PostgreSQL, Anda dapat menggunakan konektor Proxy Auth AlloyDB untuk PostgreSQL. Konektor Proxy Auth menyediakan otorisasi koneksi berbasis Identity and Access Management (IAM) dan menggunakan koneksi TLS 1.3 dengan cipher AES 256-bit untuk memverifikasi identitas klien dan server serta mengenkripsi traffic data. Untuk mengetahui informasi selengkapnya, lihat Tentang Proxy Auth untuk AlloyDB for PostgreSQL. Untuk koneksi yang dibuat menggunakan Java, Python, atau Go, gunakan Konektor Bahasa yang sesuai dan bukan konektor Proxy Auth. AlloyDB untuk PostgreSQL membantu Anda memenuhi persyaratan residensi data. Data disimpan atau direplikasi dalam region yang Anda tentukan. |
| BigQuery |
BigQuery menyediakan banyak fitur yang dapat Anda gunakan untuk mengontrol akses ke data, melindungi data sensitif, dan memastikan akurasi dan konsistensi data. Untuk mengetahui informasi selengkapnya, lihat Pengantar tata kelola data di BigQuery. BigQuery membantu Anda memenuhi persyaratan residensi data. Data disimpan dalam region yang Anda tentukan. |
| Cloud Storage |
Secara default, data yang disimpan di Cloud Storage dienkripsi menggunakan Google-owned and Google-managed encryption keys. Jika diperlukan, Anda dapat menggunakan CMEK atau kunci Anda sendiri yang Anda kelola dengan menggunakan metode pengelolaan eksternal seperti kunci enkripsi yang disediakan pelanggan (CSEK). Untuk informasi selengkapnya, lihat Opsi enkripsi data. Cloud Storage mendukung dua metode untuk memberi pengguna akses ke bucket dan objek Anda: IAM dan daftar kontrol akses (ACL). Dalam sebagian besar kasus, sebaiknya gunakan IAM, yang memungkinkan Anda memberikan izin di tingkat bucket dan project. Untuk mengetahui informasi selengkapnya, lihat Ringkasan kontrol akses. Data yang Anda muat ke subsistem penyerapan data melalui Cloud Storage mungkin mencakup data sensitif. Untuk melindungi data tersebut, Anda dapat menggunakan Sensitive Data Protection untuk menemukan, mengklasifikasikan, dan melakukan de-identifikasi data. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Sensitive Data Protection dengan Cloud Storage. Cloud Storage membantu Anda memenuhi persyaratan residensi data. Data disimpan atau direplikasi dalam region yang Anda tentukan. |
| Pub/Sub |
Secara default, Pub/Sub mengenkripsi semua pesan, baik dalam penyimpanan maupun dalam pengiriman, dengan menggunakan Google-owned and Google-managed encryption keys. Pub/Sub mendukung penggunaan CMEK untuk enkripsi pesan di lapisan aplikasi. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi enkripsi pesan. Jika Anda memiliki persyaratan residensi data, untuk memastikan data pesan disimpan di lokasi tertentu, Anda dapat mengonfigurasi kebijakan penyimpanan pesan. |
| Cloud Logging |
Log audit Aktivitas Admin diaktifkan secara default untuk semua layanan Google Cloud yang digunakan dalam arsitektur referensi ini. Log ini mencatat panggilan API atau tindakan lain yang mengubah konfigurasi atau metadata Google Cloud resource. Log audit Akses Data diaktifkan secara default untuk BigQuery. Untuk layanan lain yang digunakan dalam arsitektur ini, Anda dapat mengaktifkan log audit Akses Data. Log ini memungkinkan Anda melacak panggilan API yang membaca konfigurasi atau metadata resource atau permintaan pengguna untuk membuat, mengubah, atau membaca data resource yang disediakan pengguna. Untuk membantu memenuhi persyaratan residensi data, Anda dapat mengonfigurasi Cloud Logging untuk menyimpan data log di region yang Anda tentukan. Untuk mengetahui informasi selengkapnya, lihat Melokalkan log. |
Untuk mengetahui prinsip dan rekomendasi keamanan yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Keamanan dalam Framework yang Dirancang dengan Baik.
Keandalan
Bagian ini menjelaskan faktor desain yang harus Anda pertimbangkan untuk membangun dan mengoperasikan infrastruktur yang andal untuk aplikasi AI generatif berkemampuan RAG di Google Cloud.
| Produk | Pertimbangan desain |
|---|---|
| AlloyDB untuk PostgreSQL |
Secara default, cluster AlloyDB untuk PostgreSQL menyediakan ketersediaan tinggi (HA) dengan failover otomatis. Instance utama memiliki node redundan yang terletak di dua zona berbeda dalam suatu region. Redundansi ini memastikan bahwa cluster tangguh terhadap pemadaman zona. Untuk merencanakan pemulihan dari pemadaman layanan region, Anda dapat menggunakan replikasi lintas region. |
| BigQuery |
Data yang Anda muat ke BigQuery disimpan secara serentak di dua zona dalam region yang Anda tentukan. Redundansi ini membantu memastikan data Anda tidak hilang saat terjadi gangguan zona. Untuk mengetahui informasi selengkapnya tentang fitur keandalan di BigQuery, lihat Memahami keandalan. |
| Cloud Storage | Anda dapat membuat bucket Cloud Storage di salah satu dari tiga jenis lokasi: regional, dual-region, atau multi-region. Data yang disimpan di bucket regional direplikasi secara sinkron di beberapa zona dalam satu region. Untuk ketersediaan yang lebih tinggi, Anda dapat menggunakan bucket dual-region atau multi-region, tempat data direplikasi secara asinkron di seluruh region. |
| Pub/Sub |
Untuk mengelola lonjakan sementara dalam traffic pesan, Anda dapat mengonfigurasi kontrol alur di setelan penayang. Untuk menangani publikasi yang gagal, sesuaikan variabel permintaan percobaan ulang sesuai kebutuhan. Untuk mengetahui informasi selengkapnya, lihat Mengirim ulang permintaan. |
Untuk prinsip dan rekomendasi keandalan yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Keandalan dalam Well-Architected Framework.
Pengoptimalan biaya
Bagian ini berisi panduan untuk membantu Anda mengoptimalkan biaya penyiapan dan pengoperasian aplikasi AI generatif yang kompatibel dengan RAG di Google Cloud.
| Produk | Pertimbangan desain |
|---|---|
| AlloyDB untuk PostgreSQL |
Secara default, instance utama cluster AlloyDB untuk PostgreSQL sangat tersedia (HA). Instance memiliki node aktif dan node standby. Jika node aktif gagal, AlloyDB untuk PostgreSQL akan otomatis melakukan failover ke node standby. Jika Anda tidak memerlukan HA untuk database, Anda dapat mengurangi biaya dengan menjadikan instance utama cluster sebagai instance dasar. Instance dasar tidak kuat terhadap pemadaman zona dan memiliki periode nonaktif yang lebih lama selama operasi pemeliharaan. Untuk informasi selengkapnya, lihat Mengurangi biaya menggunakan instance dasar. Jika dapat memprediksi persyaratan CPU dan memori instance AlloyDB untuk PostgreSQL, Anda dapat menghemat uang dengan mendapatkan diskon untuk penggunaan yang di-commit. Untuk mengetahui informasi selengkapnya, lihat Diskon penggunaan berkelanjutan AlloyDB untuk PostgreSQL. |
| BigQuery | BigQuery memungkinkan Anda memperkirakan biaya kueri sebelum menjalankannya. Untuk mengoptimalkan biaya kueri, Anda perlu mengoptimalkan penyimpanan dan komputasi kueri. Untuk mengetahui informasi selengkapnya, lihat Memperkirakan dan mengontrol biaya. |
| Cloud Storage | Untuk bucket Cloud Storage yang Anda gunakan untuk memuat data ke dalam subsistem penyerapan data, pilih kelas penyimpanan yang sesuai berdasarkan persyaratan retensi data dan frekuensi akses workload Anda. Misalnya, Anda dapat memilih kelas penyimpanan Standard, dan menggunakan Object Lifecycle Management untuk mengontrol biaya penyimpanan dengan secara otomatis mendowngrade objek ke kelas penyimpanan yang lebih murah atau menghapus objek berdasarkan kondisi yang Anda tetapkan. |
| Cloud Logging |
Untuk mengontrol biaya penyimpanan log, Anda dapat melakukan hal berikut:
|
Untuk prinsip dan rekomendasi pengoptimalan biaya yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Pengoptimalan biaya dalam Well-Architected Framework.
Performa
Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan saat mendesain dan membangun aplikasi AI generatif berkemampuan RAG di Google Cloud yang memenuhi persyaratan performa Anda.
| Produk | Pertimbangan desain |
|---|---|
| AlloyDB untuk PostgreSQL |
Untuk membantu Anda menganalisis dan meningkatkan performa kueri database, AlloyDB untuk PostgreSQL menyediakan alat Insight Kueri. Anda dapat menggunakan alat ini untuk memantau performa dan melacak sumber kueri yang bermasalah. Untuk mengetahui informasi selengkapnya, lihat Ringkasan Insight Kueri. Untuk mendapatkan ringkasan status dan performa database Anda serta melihat metrik mendetail seperti koneksi puncak dan jeda replikasi maksimum, Anda dapat menggunakan dasbor Insight Sistem. Untuk mengetahui informasi selengkapnya, lihat Memantau instance menggunakan dasbor Insight Sistem AlloyDB untuk PostgreSQL. Untuk mengurangi beban pada instance AlloyDB for PostgreSQL utama dan menskalakan kapasitas untuk menangani permintaan baca, Anda dapat menambahkan instance kumpulan baca ke cluster. Untuk mengetahui informasi selengkapnya, lihat Node dan instance AlloyDB untuk PostgreSQL. |
| BigQuery |
BigQuery menyediakan grafik eksekusi kueri yang dapat Anda gunakan untuk menganalisis performa kueri dan mendapatkan insight performa untuk masalah seperti pertentangan slot dan kuota shuffle yang tidak memadai. Untuk mengetahui informasi selengkapnya, lihat Mendapatkan insight performa kueri. Setelah mengatasi masalah yang Anda identifikasi melalui insight performa kueri, Anda dapat mengoptimalkan kueri lebih lanjut dengan menggunakan teknik seperti mengurangi volume data input dan output. Untuk informasi selengkapnya, lihat Mengoptimalkan komputasi kueri. |
| Cloud Storage | Untuk mengupload file besar, Anda dapat menggunakan metode yang disebut upload komposit paralel. Dengan strategi ini, file besar dibagi menjadi beberapa bagian. Potongan diupload ke Cloud Storage secara paralel, lalu data disusun ulang di cloud. Upload komposit paralel dapat lebih cepat daripada operasi upload reguler jika bandwidth jaringan dan kecepatan disk tidak menjadi faktor yang membatasi. Namun, strategi ini memiliki beberapa keterbatasan dan implikasi biaya. Untuk mengetahui informasi selengkapnya, lihat Upload komposit paralel. |
Untuk prinsip dan rekomendasi pengoptimalan performa yang khusus untuk workload AI dan ML, lihat Perspektif AI dan ML: Pengoptimalan performa dalam Well-Architected Framework.
Deployment
Untuk mulai dan bereksperimen dengan membangun infrastruktur di Google Cloud untuk aplikasi AI generatif berkemampuan RAG, Anda dapat menggunakan Solusi Mulai Cepat: RAG AI Generatif dengan Cloud SQL. Solusi ini men-deploy aplikasi chat berbasis Python di Cloud Run dan menggunakan database Cloud SQL yang terkelola sepenuhnya untuk penelusuran vektor. Kode contoh untuk solusi ini tersedia di GitHub.
Langkah berikutnya
- Memilih model dan infrastruktur untuk aplikasi AI generatif Anda
- Membangun aplikasi chat berbasis LLM dan RAG menggunakan AlloyDB untuk PostgreSQL dan LangChain
- Infrastruktur RAG untuk AI generatif menggunakan Vertex AI dan Penelusuran Vektor
- Infrastruktur RAG untuk AI generatif menggunakan GKE dan Cloud SQL
- Infrastruktur RAG untuk AI generatif menggunakan Gemini Enterprise dan Vertex AI
- Infrastruktur GraphRAG untuk AI generatif menggunakan Vertex AI dan Spanner Graph
- Untuk mengetahui ringkasan prinsip dan rekomendasi arsitektur khusus untuk workload AI dan ML di Google Cloud, lihat perspektif AI dan ML dalam Well-Architected Framework.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
Kontributor
Penulis: Kumar Dhanagopal | Cross-Product Solution Developer
Kontributor lainnya:
- Andrew Brook | Engineering Director
- Anna Berenberg | Engineering Fellow
- Assaf Namer | Principal Cloud Security Architect
- Balachandar Krishnamoorthy | Principal Software Engineer
- Daniel Lees | Cloud Security Architect
- Derek Downey | Developer Relations Engineer
- Eran Lewis | Senior Product Manager
- Geoffrey Anderson | Product Manager
- Gleb Otochkin | Cloud Advocate, Database
- Hamsa Buvaraghan | AI Product Manager
- Irina Sigler | Product Manager
- Jack Wotherspoon | Developer Advocate
- Jason Davenport | Developer Advocate
- Jordan Totten | Customer Engineer
- Julia Wiesinger | Product Manager
- Kara Greenfield | Customer Engineer
- Kurtis Van Gent | Staff Software Engineer
- Per Jacobsson | Software Engineer
- Pranav Nambiar | Director
- Richard Hendricks | Staf Architecture Center
- Safiuddin Khaja | Cloud Engineer
- Sandy Ghai | Group Product Manager
- Vladimir Vuskovic | Product Management Director
- Steren Giannini | Group Product Manager
- Wietse Venema | Developer Relations Engineer