Dokumen ini menyediakan arsitektur referensi yang dapat Anda gunakan untuk mendesain infrastruktur guna menjalankan aplikasi kecerdasan buatan (AI) generatif dengan retrieval-augmented generation (RAG). Audiens yang ditargetkan 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 arsitektur tingkat tinggi untuk aplikasi AI generatif berkemampuan RAG di Google Cloud:
Arsitekturnya berisi komponen yang saling terhubung berikut ini:
| Komponen | Tujuan | Interaksi |
|---|---|---|
| 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 penayangan | Tangani alur permintaan-respons antara aplikasi AI generatif dan penggunanya. | Subsistem penayangan berinteraksi dengan subsistem penyerapan data melalui lapisan database. |
| Subsistem evaluasi kualitas | Evaluasi kualitas respons yang dihasilkan subsistem penayangan. | Subsistem evaluasi kualitas berinteraksi dengan subsistem penayangan secara langsung dan dengan subsistem penyerapan data melalui lapisan database. |
| Database | Simpan data berikut:
|
Semua subsistem dalam arsitektur berinteraksi dengan {i>database<i}. |
Diagram berikut menunjukkan tampilan arsitektur yang mendetail:
Bagian berikut memberikan deskripsi mendetail tentang komponen dan aliran data dalam setiap subsistem arsitektur.
Subsistem penyerapan data
Subsistem penyerapan data menyerap data dari sumber eksternal seperti file, database, dan layanan streaming. Data yang diupload mencakup perintah evaluasi kualitas. Subsistem penyerapan data menyediakan 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 pengguna aplikasi yang melakukan upload, penyerapan database, atau data streaming.
- Saat data diupload, notifikasi akan dikirim ke topik Pub/Sub.
- Pub/Sub memicu tugas Cloud Run untuk memproses data yang diupload.
- Cloud Run memulai tugas dengan data konfigurasi yang tersimpan di database AlloyDB untuk PostgreSQL.
- Tugas Cloud Run menggunakan Document AI untuk menyiapkan data untuk diproses lebih lanjut. Misalnya, persiapan tersebut dapat mencakup menguraikan data, mengonversi data ke format yang diperlukan, dan membagi data menjadi beberapa bagian.
Tugas Cloud Run menggunakan model Vertex AI Embeddings untuk Teks guna membuat penyematan vektor dari data yang diserap.
Cloud Run menyimpan penyematan dalam database AlloyDB untuk PostgreSQL yang mengaktifkan ekstensi
pgvector. Seperti yang dijelaskan di bagian berikut, saat subsistem penayangan memproses permintaan pengguna, subsistem ini akan menggunakan embedding di database vektor untuk mengambil data khusus domain yang relevan.
Subsistem penayangan
Subsistem penayangan 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 natural-language menjadi embeddings.
Aplikasi menyelesaikan bagian pengambilan dari pendekatan RAG:
- Aplikasi melakukan penelusuran semantik untuk penyematan di penyimpanan vektor AlloyDB untuk PostgreSQL yang dikelola oleh subsistem penyerapan data. Penelusuran semantik membantu menemukan penyematan berdasarkan intent sebuah perintah, bukan konten tekstualnya.
- Aplikasi ini menggabungkan permintaan asli dengan data mentah yang diambil berdasarkan penyematan yang cocok untuk membuat prompt kontekstual.
Aplikasi akan mengirimkan perintah yang dikontekstualisasikan 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 berdasarkan 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 akan memuat respons terhadap BigQuery untuk analisis offline.
Aplikasi menyaring respons menggunakan filter responsible AI.
Aplikasi 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 tugas Cloud Run.
- Cloud Run memulai tugas dengan data konfigurasi yang tersimpan di database AlloyDB untuk PostgreSQL.
- Tugas Cloud Run mengambil perintah evaluasi dari database AlloyDB untuk PostgreSQL. Perintah sebelumnya diupload ke database oleh subsistem penyerapan data.
Tugas Cloud Run menggunakan perintah evaluasi untuk menilai kualitas respons yang dihasilkan subsistem penayangan.
Output evaluasi ini terdiri dari skor evaluasi untuk metrik seperti akurasi dan relevansi yang faktual.
Cloud Run memuat skor evaluasi, perintah, dan respons yang dievaluasi ke BigQuery untuk analisis pada masa mendatang.
Produk yang digunakan
Berikut adalah ringkasan semua produk Google Cloud yang digunakan oleh arsitektur sebelumnya:
- Vertex AI: Platform ML yang dapat Anda gunakan untuk melatih dan men-deploy model ML dan aplikasi AI, serta menyesuaikan LLM untuk digunakan dalam aplikasi yang didukung teknologi AI.
- Cloud Run: Platform komputasi serverless yang dapat digunakan untuk menjalankan container secara langsung di atas infrastruktur Google yang skalabel.
- BigQuery: Data warehouse perusahaan yang membantu Anda mengelola dan menganalisis data dengan fitur bawaan seperti analisis geospasial machine learning dan business intelligence.
- Cloud Storage: Penyimpanan objek tanpa batas dan berbiaya rendah untuk beragam jenis data. Data dapat diakses dari dalam dan luar Google Cloud, dan direplikasi di berbagai lokasi untuk redundansi.
- AlloyDB untuk PostgreSQL: Layanan database yang kompatibel dengan PostgreSQL dan terkelola sepenuhnya yang dirancang untuk workload Anda yang memiliki tuntutan tinggi, termasuk pemrosesan transaksi dan analisis hybrid.
- Document AI: Platform pemrosesan dokumen yang mengambil data tidak terstruktur dari dokumen dan mengubahnya menjadi data terstruktur.
- 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 memungkinkan Anda menggunakan aplikasi AI generatif yang mendukung RAG.
Rekomendasi produk yang dipersonalisasi
Situs belanja online mungkin menggunakan chatbot yang didukung LLM untuk membantu pelanggan menemukan produk atau mendapatkan bantuan terkait belanja. Pertanyaan dari pengguna dapat ditambahkan menggunakan data historis tentang perilaku pembelian dan pola interaksi situs pengguna. Data tersebut dapat mencakup ulasan pengguna dan masukan yang disimpan di datastore tidak terstruktur atau metrik terkait penelusuran yang disimpan di data warehouse analisis web. Pertanyaan yang ditingkatkan kemudian dapat diproses oleh LLM untuk menghasilkan respons yang dipersonalisasi yang mungkin dianggap lebih menarik dan memikat oleh 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. Respons yang dihasilkan aplikasi ini dapat didasarkan pada data pasien historis dengan kontekstual terhadap perintah dokter dengan data dari database catatan kesehatan elektronik (EHR) rumah sakit atau dari pusat informasi eksternal seperti PubMed.
Riset hukum yang efisien
Riset hukum yang didukung AI generatif memungkinkan pengacara dengan cepat membuat kueri terkait undang-undang dan hukum kasus dalam jumlah besar untuk mengidentifikasi preseden hukum yang relevan atau meringkas konsep hukum yang kompleks. Output dari penelitian tersebut dapat ditingkatkan dengan menambahkan perintah pengacara dengan data yang diambil dari korpus kontrak milik firma hukum, komunikasi hukum sebelumnya, dan catatan kasus internal. Pendekatan desain ini memastikan bahwa respons yang dihasilkan relevan dengan domain hukum yang menjadi spesialisasi pengacara.
Alternatif desain
Untuk komponen penyimpanan vektor dan penelusuran semantik dalam arsitektur, Anda dapat menggunakan Vertex AI Vector Search. Vector Search adalah layanan terkelola sepenuhnya yang menyediakan infrastruktur penayangan yang dioptimalkan untuk penelusuran vektor berskala sangat besar. Data mentah (bagian teks) dapat disimpan di penyimpanan objek seperti Cloud Storage atau di penyimpanan nilai kunci seperti Filestore. Dalam kedua kasus tersebut, representasi vektor dari setiap potongan teks mentah disimpan di Vector Search.
Saat data diserap, ID unik ditetapkan ke setiap potongan teks mentah, dan ID ini digunakan sebagai nama file objek di Cloud Storage. ID yang sama digunakan sebagai ID vektor di Vector Search.
Pada waktu inferensi, kueri teks yang masuk dikonversi menjadi vektor embedding. Vector Search melakukan penelusuran kemiripan untuk menampilkan vektor yang paling mirip secara semantik. ID vektor kemudian digunakan untuk mencari potongan teks asli. Secara kolektif, potongan teks ini menyediakan konteks relevan yang diperlukan LLM untuk menyelesaikan tugas tertentu.
Untuk informasi tentang cara membuat, men-deploy, dan membuat kueri indeks penelusuran vektor, lihat panduan memulai Vector Search.
Pertimbangan desain
Bagian ini memberikan panduan untuk membantu Anda mengembangkan arsitektur AI generatif berkemampuan RAG di Google Cloud yang memenuhi persyaratan khusus Anda untuk keamanan dan kepatuhan, keandalan, biaya, serta performa. Panduan di bagian ini tidak lengkap. Bergantung pada persyaratan spesifik aplikasi AI generatif Anda serta produk dan fitur Google Cloud yang Anda gunakan, Anda mungkin perlu mempertimbangkan faktor desain dan kompromi tambahan.
Keamanan dan kepatuhan
Bagian ini menjelaskan faktor-faktor yang harus Anda pertimbangkan saat merancang 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 kontrol keamanan Google Cloud yang dapat Anda gunakan untuk memenuhi persyaratan 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 |
Secara default, Cloud Run mengenkripsi data menggunakan kunci yang dimiliki Google dan dikelola Google. Untuk melindungi container menggunakan kunci yang Anda kontrol, Anda dapat menggunakan kunci enkripsi yang dikelola pelanggan (CMEK). Untuk informasi selengkapnya, lihat Menggunakan kunci enkripsi yang dikelola pelanggan. Untuk memastikan bahwa hanya image container resmi yang di-deploy ke tugas Cloud Run, Anda dapat menggunakan Otorisasi Biner. Cloud Run membantu Anda memenuhi persyaratan residensi data. Instance container Cloud Run dijalankan di dalam region yang Anda pilih. |
| AlloyDB untuk PostgreSQL |
Secara default, data yang disimpan di AlloyDB untuk PostgreSQL dienkripsi menggunakan kunci milik Google dan yang dikelola Google. 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 AlloyDB untuk database 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 AlloyDB untuk konektor Proxy Auth PostgreSQL. Konektor Auth Proxy memberikan 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 AlloyDB untuk Proxy Auth PostgreSQL. Untuk koneksi yang dibuat menggunakan Java, Python, atau Go, gunakan Konektor Bahasa yang sesuai, bukan konektor Proxy Auth. AlloyDB untuk PostgreSQL membantu Anda memenuhi persyaratan residensi data. Data disimpan atau direplikasi di dalam region yang Anda tentukan. |
| BigQuery |
BigQuery menyediakan banyak fitur yang dapat Anda gunakan untuk mengontrol akses ke data, melindungi data sensitif, serta memastikan akurasi dan konsistensi data. Untuk informasi selengkapnya, lihat Pengantar tata kelola data di BigQuery. BigQuery membantu Anda memenuhi persyaratan residensi data. Data disimpan di dalam region yang Anda tentukan. |
| Cloud Storage |
Secara default, data yang disimpan di Cloud Storage dienkripsi menggunakan kunci milik Google dan yang dikelola Google. Jika diperlukan, Anda dapat menggunakan CMEK atau kunci Anda sendiri yang dikelola dengan menggunakan metode pengelolaan eksternal seperti kunci enkripsi yang disediakan pelanggan (CSEK). Untuk mengetahui 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, kami merekomendasikan penggunaan IAM, yang memungkinkan Anda memberikan izin pada level bucket dan project. Untuk informasi selengkapnya, lihat Ringkasan kontrol akses. Data yang Anda muat ke subsistem penyerapan data melalui Cloud Storage dapat mencakup data sensitif. Untuk melindungi data tersebut, Anda dapat menggunakan Sensitive Data Protection untuk menemukan, mengklasifikasikan, dan melakukan de-identifikasi data tersebut. Untuk mengetahui informasi selengkapnya, lihat Menggunakan Sensitive Data Protection dengan Cloud Storage. Cloud Storage membantu Anda memenuhi persyaratan residensi data. Data disimpan atau direplikasi di dalam region yang Anda tentukan. |
| Pub/Sub |
Secara default, Pub/Sub mengenkripsi semua pesan, baik saat dalam penyimpanan maupun dalam pengiriman, menggunakan kunci milik Google dan yang dikelola Google. Pub/Sub mendukung penggunaan CMEK untuk enkripsi pesan di lapisan aplikasi. Untuk informasi selengkapnya, lihat Mengonfigurasi enkripsi pesan. Jika memiliki persyaratan residensi data, untuk memastikan data pesan disimpan di lokasi tertentu, Anda dapat mengonfigurasi kebijakan penyimpanan pesan. |
| Document AI | Secara default, data dalam penyimpanan dienkripsi menggunakan kunci enkripsi yang dikelola Google. Jika perlu menggunakan kunci enkripsi yang Anda kontrol dan kelola, Anda dapat menggunakan CMEK. Untuk informasi selengkapnya, lihat Keamanan & Kepatuhan Document AI. |
| Cloud Logging |
Log audit Aktivitas Admin diaktifkan secara default untuk semua layanan Google Cloud yang digunakan dalam arsitektur referensi ini. Log ini merekam panggilan API atau tindakan lain yang mengubah konfigurasi atau metadata resource Google Cloud. 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 Melakukan regionalisasi log. |
Untuk panduan umum tentang prinsip keamanan yang perlu dipertimbangkan untuk aplikasi AI, lihat Memperkenalkan Framework AI Aman Google.
Keandalan
Bagian ini menjelaskan faktor-faktor desain yang perlu dipertimbangkan untuk membangun dan mengoperasikan infrastruktur yang andal untuk aplikasi AI generatif berkemampuan RAG di Google Cloud.
| Produk | Pertimbangan desain |
|---|---|
| Cloud Run |
Cloud Run adalah layanan regional. Data disimpan secara sinkron di beberapa zona dalam satu region. Traffic otomatis diseimbangkan di seluruh zona. Jika terjadi pemadaman layanan zona, tugas Cloud Run akan terus berjalan dan data tidak hilang. Jika terjadi pemadaman layanan region, tugas Cloud Run akan berhenti berjalan hingga Google menyelesaikan pemadaman tersebut. Masing-masing tugas atau tugas Cloud Run mungkin gagal. Untuk menangani kegagalan tersebut, Anda dapat menggunakan percobaan ulang tugas dan checkpoint. Untuk mengetahui informasi selengkapnya, lihat Mencoba ulang tugas dan praktik terbaik checkpoint. |
| AlloyDB untuk PostgreSQL |
Secara default, cluster AlloyDB untuk PostgreSQL menyediakan ketersediaan tinggi (HA) dengan failover otomatis. Instance utama memiliki node redundan yang berada di dua zona berbeda dalam satu region. Redundansi ini memastikan bahwa cluster andal terhadap gangguan zona. Untuk merencanakan pemulihan dari gangguan region, Anda dapat menggunakan replikasi lintas region. |
| BigQuery |
Data yang Anda muat ke BigQuery disimpan secara sinkron di dua zona dalam region yang Anda tentukan. Redundansi ini membantu memastikan bahwa data Anda tidak hilang saat terjadi pemadaman 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 berbagai region. |
| Pub/Sub |
Untuk mengelola lonjakan traffic pesan sementara, 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 Mencoba ulang permintaan. |
| Document AI | Document AI adalah layanan regional. Data disimpan secara sinkron di beberapa zona dalam satu region. Traffic otomatis diseimbangkan di seluruh zona. Jika terjadi pemadaman layanan zona, data tidak hilang. Jika terjadi pemadaman layanan region, Document AI tidak akan tersedia hingga Google menyelesaikan pemadaman tersebut. |
Pengoptimalan biaya
Bagian ini memberikan panduan untuk membantu Anda mengoptimalkan biaya penyiapan dan pengoperasian aplikasi AI generatif berkemampuan RAG di Google Cloud.
| Produk | Pertimbangan desain |
|---|---|
| Cloud Run |
Saat membuat tugas Cloud Run, Anda menentukan jumlah memori dan CPU yang akan dialokasikan ke instance container. Untuk mengontrol biaya, mulailah dengan alokasi CPU dan memori default (minimum). Untuk meningkatkan performa, Anda dapat meningkatkan alokasi dengan mengonfigurasi batas CPU dan batas memori. Jika Anda dapat memprediksi kebutuhan CPU dan memori untuk tugas Cloud Run, Anda dapat menghemat uang dengan mendapatkan diskon untuk abonemen. Untuk mengetahui informasi selengkapnya, lihat Diskon abonemen Cloud Run. |
| AlloyDB untuk PostgreSQL |
Secara default, instance utama dari cluster AlloyDB untuk PostgreSQL sangat tersedia (HA). Instance memiliki node aktif dan node standby. Jika node aktif gagal, AlloyDB untuk PostgreSQL akan otomatis beralih ke node standby. Jika tidak memerlukan HA untuk database, Anda dapat mengurangi biaya dengan menjadikan instance utama cluster sebagai instance dasar. Instance dasar tidak andal terhadap gangguan zona dan memiliki periode nonaktif yang lebih lama selama operasi pemeliharaan. Untuk mengetahui informasi selengkapnya, lihat Mengurangi biaya menggunakan instance dasar. Jika Anda dapat memprediksi persyaratan CPU dan memori instance AlloyDB untuk PostgreSQL, Anda dapat menghemat uang dengan mendapatkan diskon untuk abonemen. Untuk informasi selengkapnya, lihat Diskon abonemen AlloyDB untuk PostgreSQL. |
| BigQuery | BigQuery memungkinkan Anda memperkirakan biaya kueri sebelum menjalankannya. Untuk mengoptimalkan biaya kueri, Anda perlu mengoptimalkan penyimpanan dan komputasi kueri. Untuk informasi lebih lanjut, 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 Standar, dan menggunakan Object Lifecycle Management untuk mengontrol biaya penyimpanan dengan otomatis mendowngrade objek ke kelas penyimpanan berbiaya lebih rendah atau menghapus objek berdasarkan kondisi yang Anda tetapkan. |
| Cloud Logging |
Untuk mengontrol biaya penyimpanan log, Anda dapat melakukan hal berikut:
|
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 |
|---|---|
| Cloud Run | Secara default, setiap instance container Cloud Run dialokasikan satu CPU dan memori 512 MiB. Bergantung pada persyaratan performa untuk tugas Cloud Run, Anda dapat mengonfigurasi batas CPU dan batas memori. |
| 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 serta melihat metrik mendetail seperti koneksi puncak dan jeda replikasi maksimum, Anda dapat menggunakan dasbor System Insights. Untuk mengetahui informasi selengkapnya, lihat Memantau instance menggunakan dasbor Insight Sistem AlloyDB untuk PostgreSQL. Guna mengurangi beban pada instance AlloyDB untuk PostgreSQL utama dan menyebarkan skala kapasitas untuk menangani permintaan baca, Anda dapat menambahkan instance kumpulan baca ke cluster. Untuk mengetahui informasi selengkapnya, lihat AlloyDB untuk node dan instance 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 acak yang tidak mencukupi. Untuk mengetahui informasi selengkapnya, lihat Mendapatkan insight performa kueri. Setelah mengatasi masalah yang Anda identifikasi melalui insight performa kueri, Anda dapat lebih mengoptimalkan kueri 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 akan dibagi menjadi beberapa bagian. Potongan data diupload ke Cloud Storage secara paralel, lalu data dikomposisi ulang di cloud. Upload gabungan paralel dapat lebih cepat daripada operasi upload reguler jika bandwidth jaringan dan kecepatan disk tidak membatasi faktor. Namun, strategi ini memiliki beberapa batasan dan implikasi biaya. Untuk mengetahui informasi selengkapnya, lihat Upload gabungan paralel. |
Deployment
Untuk memulai dan bereksperimen dengan membangun infrastruktur di Google Cloud untuk aplikasi AI generatif yang mendukung RAG, Anda dapat menggunakan Solusi Jump Start: 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 selanjutnya
- Pelajari cara Membangun aplikasi AI Generatif dengan Vertex AI PaLM API dan LangChain.
- Pelajari cara Membangun aplikasi AI generatif perusahaan dengan database Google Cloud.
- Pelajari cara Aplikasi Pengambilan Database GenAI Baru membantu meningkatkan jawaban LLM.
- Coba Codelab untuk Membangun aplikasi chat berbasis LLM dan RAG menggunakan AlloyDB untuk PostgreSQL AI dan LangChain.
- Coba peringkasan dokumen AI Generatif.
- Baca tentang Pembuatan Augmented Reality untuk Tugas NLP yang Intensif Pengetahuan.
- Baca Pembuatan Augmented Reality untuk Model Bahasa Besar.
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
Kontributor
Penulis: Kumar Dhanagopal | Developer Solusi Lintas Produk
Kontributor lainnya:
- Andrew Brook | Direktur Teknik
- Anna Berenberg | Rekan Teknik
- Assaf Namer | Principal Cloud Security Architect
- Balachandar Krishnamoorthy | Principal Software Engineer
- Daniel Lees | Arsitek Keamanan Cloud
- Derek Downey | Engineer Hubungan Developer
- Eran Lewis | Senior Product Manager
- Geoffrey Anderson | Product Manager
- Gleb Otochkin | Advokat Cloud, Database
- Hamsa Buvaraghan | Product Manager AI
- Irina Sigler | Product Manager
- Jack Wotherspoon | Software Engineer
- Jason Davenport | Advokat Developer
- Jordan Totten | Customer Engineer
- Julia Wiesinger | Manajer Produk
- Kara Baru | Customer Engineer
- Kurtis Van Gent | Staf Software Engineer
- Per Jacobsson | Software Engineer
- Pranav Nambiar | Direktur
- Richard Hendricks | Staf Pusat Arsitektur
- Safiuddin Khaja | Cloud Engineer
- Sandy Ghai | Group Product Manager
- Vladimir Vuskovic | Direktur Pengelolaan Produk
- Steren Giannini | Group Product Manager
- Wietse Venema | Engineer Hubungan Developer