Dokumen ini menyediakan arsitektur referensi yang dapat Anda gunakan untuk mendesain infrastruktur Anda untuk menjalankan aplikasi kecerdasan buatan (AI) generatif dengan retrieval-augmented Generation (RAG). Audiens yang diinginkan untuk dokumen ini mencakup developer dan administrator aplikasi AI generatif dan arsitek cloud. Dokumen ini mengasumsikan bahwa pemahaman tentang AI, machine learning (ML), dan model bahasa besar (LLM) konsep. Dokumen ini tidak memberikan panduan tentang cara mendesain dan mengembangkan aplikasi AI generatif.
Arsitektur
Diagram berikut menunjukkan tampilan tingkat tinggi dari suatu arsitektur untuk Aplikasi AI generatif berkemampuan RAG di Google Cloud:
Arsitekturnya berisi komponen yang saling terhubung berikut ini:
Komponen | Tujuan | Interaksi |
---|---|---|
Subsistem penyerapan data | Menyiapkan dan memproses data eksternal yang digunakan untuk mengaktifkan RAG kemampuan IT mereka. | Subsistem penyerapan data berinteraksi dengan subsistem lain di arsitektur melalui lapisan database. |
Subsistem penayangan | Menangani alur permintaan-respons antara AI generatif aplikasi dan penggunanya. | Subsistem penayangan berinteraksi dengan subsistem penyerapan data melalui lapisan {i>database<i}. |
Subsistem evaluasi kualitas | Mengevaluasi kualitas respons yang dilakukan oleh subsistem penayangan yang dihasilkan. | Subsistem evaluasi kualitas berinteraksi dengan subsistem penayangan secara langsung dan dengan subsistem penyerapan data melalui database, feedforward. |
Database | Simpan data berikut:
|
Semua subsistem dalam arsitektur berinteraksi dengan {i>database<i}. |
Diagram berikut menunjukkan tampilan arsitektur yang mendetail:
Bagian berikut memberikan deskripsi terperinci tentang komponen dan data dalam setiap subsistem arsitektur.
Subsistem penyerapan data
Subsistem penyerapan data menyerap data dari sumber eksternal seperti file, {i>database<i}, dan layanan {i>streaming<i}. Data yang diupload mencakup perintah untuk evaluasi kualitas. Subsistem penyerapan data memberikan kemampuan RAG dalam arsitektur ini. Diagram berikut menunjukkan detail penyerapan data subsistem dalam arsitektur:
Berikut adalah langkah-langkah dalam alur penyerapan data:
- Data diupload ke bucket Cloud Storage. Sumber datanya mungkin pengguna aplikasi yang melakukan upload, penyerapan database, atau streaming layanan otomatis dan data skalabel.
- 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 menggunakan data konfigurasi yang disimpan dalam database AlloyDB untuk PostgreSQL.
- Tugas Cloud Run menggunakan Document AI untuk mempersiapkan data untuk diproses lebih lanjut. Misalnya, persiapannya dapat mencakup menguraikan data, mengonversi data ke format yang diperlukan, dan membagi data menjadi potongan-potongan.
Tugas Cloud Run menggunakan Vertex AI Embedding untuk model Teks yang akan dibuat penyematan vektor dari data yang diserap.
Cloud Run menyimpan embeddings dalam AlloyDB untuk database PostgreSQL yang memiliki
pgvector
ekstensi diaktifkan. Seperti yang dijelaskan di bagian berikut, saat penayangan subsistem memproses permintaan pengguna, ia menggunakan embedding di dalam vektor {i>database<i} untuk mengambil data khusus domain yang relevan.
Subsistem penayangan
Subsistem penayangan menangani alur permintaan-respons antara AI generatif dan penggunanya. Diagram berikut menunjukkan detail penayangan subsistem dalam arsitektur:
Berikut adalah langkah-langkah dalam alur permintaan-respons dalam penayangan subsistem:
- Pengguna mengirimkan permintaan ke aplikasi AI generatif melalui frontend (misalnya, chatbot atau aplikasi seluler).
Aplikasi AI generatif mengonversi permintaan natural-language menjadi sematan.
Aplikasi menyelesaikan bagian pengambilan dari pendekatan RAG:
- Aplikasi melakukan penelusuran semantik untuk embedding dalam Penyimpanan vektor AlloyDB untuk PostgreSQL yang dikelola oleh data subsistem penyerapan. Penelusuran semantik membantu menemukan embedding berdasarkan tujuan prompt, bukan konten tekstual.
- Aplikasi ini menggabungkan permintaan asli dengan data mentah yang yang diambil berdasarkan penyematan yang cocok, untuk membuat .
Aplikasi ini mengirimkan prompt yang kontekstual ke inferensi LLM yang berjalan di Vertex AI.
Stack inferensi LLM menggunakan LLM AI generatif, yang dapat berupa LLM fondasi atau LLM khusus, serta menghasilkan respons yang dibatasi pada konteks tambahan.
- Aplikasi dapat menyimpan log aktivitas permintaan-respons di Cloud Logging. Anda dapat melihat dan menggunakan log untuk memantau menggunakan dan konfigurasi di Cloud Monitoring. Google tidak mengakses atau menggunakan data log.
- Aplikasi memuat respons ke BigQuery untuk analisis offline.
Aplikasi menyaring respons dengan menggunakan filter responsible AI.
Aplikasi mengirimkan respons yang disaring kepada pengguna melalui frontend.
Subsistem evaluasi kualitas
Diagram berikut menunjukkan detail subsistem evaluasi kualitas di arsitektur:
Saat menerima permintaan, subsistem evaluasi kualitas akan melakukan hal berikut:
- Pub/Sub memicu tugas Cloud Run.
- Cloud Run memulai tugas dengan menggunakan data konfigurasi yang disimpan dalam database AlloyDB untuk PostgreSQL.
- Tugas Cloud Run mengambil prompt evaluasi dari AlloyDB untuk database PostgreSQL. Perintah telah diupload ke di subsistem penyerapan data.
Tugas Cloud Run menggunakan perintah evaluasi untuk menilai tentang kualitas respons yang dihasilkan oleh subsistem penayangan.
Output evaluasi ini terdiri dari skor evaluasi untuk metrik seperti akurasi faktual dan relevansi.
Cloud Run memuat skor evaluasi dan perintah dan respons yang dievaluasi terhadap BigQuery untuk masa mendatang analisis data.
Produk yang digunakan
Berikut adalah ringkasan dari semua produk Google Cloud yang penggunaan arsitektur sebelumnya:
- Vertex AI: Platform ML yang dapat Anda gunakan untuk melatih dan men-deploy model ML AI generatif, dan 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 Anda dengan fitur bawaan seperti geospasial machine learning analisis, dan business intelligence.
- Cloud Storage: Penyimpanan objek tanpa batas berbiaya rendah untuk beragam jenis data. Data dapat diakses dari dalam dan luar Google Cloud, dan direplikasi di seluruh lokasi untuk redundansi.
- AlloyDB untuk PostgreSQL: Layanan database yang kompatibel dengan PostgreSQL dan terkelola sepenuhnya yang dirancang untuk workload Anda yang paling menuntut, termasuk hybrid proses transaksional dan analitis.
- Document AI: Platform pemrosesan dokumen yang menangani data tidak terstruktur dari dokumen dan mentransformasinya menjadi data terstruktur.
- Pub/Sub: Layanan pesan asinkron dan skalabel yang memisahkan layanan yang menghasilkan pesan dari layanan yang memprosesnya membuat pesan teks.
- Cloud Logging: Sistem pengelolaan log real-time dengan penyimpanan, penelusuran, analisis, dan peringatan.
- Cloud Monitoring: Layanan yang memberikan visibilitas ke performa, ketersediaan, dan kondisi aplikasi serta infrastruktur Anda.
Kasus penggunaan
RAG adalah teknik efektif untuk meningkatkan kualitas {i>output<i} yang yang dihasilkan dari LLM. Bagian ini memberikan contoh kasus penggunaan yang dapat Anda dapat menggunakan aplikasi AI generatif yang berkemampuan RAG.
Rekomendasi produk yang dipersonalisasi
Situs belanja {i>online<i} mungkin menggunakan {i> chatbot<i} yang didukung LLM untuk membantu pelanggan untuk menemukan produk atau mendapatkan bantuan terkait belanja. Pertanyaan dari pengguna dapat ditingkatkan dengan menggunakan data historis tentang perilaku pembelian pengguna dan pola interaksi situs web. Data tersebut dapat mencakup ulasan pengguna dan masukan yang disimpan di datastore tidak terstruktur atau metrik terkait penelusuran yang tersimpan di data warehouse analisis web. Pertanyaan yang ditambahkan dapat diproses oleh LLM untuk menghasilkan respons yang dipersonalisasi yang mungkin terasa lebih menarik dan memikat.
Sistem bantuan klinis
Dokter di rumah sakit perlu menganalisis dan mendiagnosis kesehatan pasien dengan cepat kondisi untuk membuat keputusan tentang perawatan dan pengobatan yang tepat. Model aplikasi AI yang menggunakan LLM medis seperti Med-PaLM dapat digunakan untuk membantu dokter dalam proses diagnosis klinis. Respons yang dihasilkan aplikasi dapat didasarkan pada riwayat catatan pasien dengan kontekstual bagi para dokter prompt dengan data dari perangkat elektronik rumah sakit {i>database<i} catatan kesehatan (EHR) atau dari pusat informasi eksternal seperti PubMed.
Riset hukum yang efisien
Riset hukum yang didukung AI generatif memungkinkan pengacara melakukan kueri dalam jumlah besar dengan cepat undang-undang dan hukum kasus untuk mengidentifikasi preseden hukum yang relevan atau meringkas konsep hukum yang kompleks. Output dari penelitian tersebut dapat ditingkatkan dengan melengkapi perintah pengacara dengan data yang diambil dari korpus kontrak eksklusif, komunikasi hukum sebelumnya, dan kasus internal {i>record<i}. Pendekatan desain ini memastikan bahwa respons yang dihasilkan relevan domain hukum yang menjadi spesialisasi pengacara.
Alternatif desain
Untuk komponen penyimpanan vektor dan penelusuran semantik dalam arsitektur, Anda bisa pakai Vertex AI Vector Search. Vector Search adalah layanan terkelola sepenuhnya yang memberikan infrastruktur layanan untuk penelusuran vektor berskala sangat besar. Data mentah (teks dapat disimpan di penyimpanan objek seperti Cloud Storage atau di penyimpanan nilai kunci seperti Filestore. Dalam kedua kasus tersebut, vektor representasi dari setiap potongan teks mentah disimpan di Vector Search.
Ketika data diserap, ID unik ditetapkan ke setiap potongan teks mentah, dan ini ID digunakan sebagai nama file objek di Cloud Storage. ID yang sama adalah digunakan sebagai ID vektor di Vector Search.
Pada waktu inferensi, kueri teks yang masuk dikonversi menjadi vektor embedding. Vector Search melakukan penelusuran kemiripan untuk menghasilkan vektor yang mirip secara semantik. ID vektor kemudian digunakan untuk mencari potongan teks asli. Secara kolektif, potongan teks ini memberikan konteks yang diperlukan LLM untuk menyelesaikan tugas yang diberikan.
Untuk informasi tentang cara membuat, menerapkan, dan membuat kueri indeks penelusuran vektor, lihat Panduan memulai Vector Search.
Pertimbangan desain
Bagian ini memberikan panduan untuk membantu Anda mengembangkan AI generatif yang mendukung RAG arsitektur di Google Cloud yang memenuhi persyaratan spesifik Anda untuk keamanan dan kepatuhan, keandalan, biaya, dan performa. Panduan dalam bagian ini tidaklah lengkap. Tergantung pada persyaratan spesifik dari aplikasi AI generatif serta produk dan fitur Google Cloud yang digunakan, Anda mungkin perlu mempertimbangkan faktor desain tambahan dan {i>trade-off<i}.
Keamanan dan kepatuhan
Bagian ini menjelaskan faktor-faktor yang harus dipertimbangkan saat Anda 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 kontrol keamanan Google Cloud yang dapat Anda gunakan untuk memenuhi persyaratan residensi data, enkripsi, keamanan jaringan, dan transparansi akses. Untuk selengkapnya informasi, 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 Anda dengan menggunakan kunci yang Anda kontrol, Anda dapat menggunakan kunci enkripsi yang (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 berjalan di dalam region yang Anda pilih. |
AlloyDB untuk PostgreSQL |
Secara default, data yang disimpan di AlloyDB untuk PostgreSQL dienkripsi menggunakan kunci yang dimiliki Google dan dikelola Google. Jika Anda perlu menggunakan enkripsi kunci yang Anda kontrol dan kelola, Anda dapat menggunakan CMEK. Untuk selengkapnya informasi, lihat Tentang CMEK. Untuk mengurangi risiko pemindahan data yang tidak sah dari 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 mengamankan koneksi lebih lanjut ke AlloyDB untuk database PostgreSQL, Anda dapat menggunakan AlloyDB untuk konektor Proxy Auth PostgreSQL. Konektor Proxy Auth memberikan otorisasi koneksi berbasis Identity and Access Management (IAM) dan menggunakan koneksi TLS 1.3 dengan penyandian AES 256-bit untuk memverifikasi klien dan identitas server dan mengenkripsi lalu lintas data. Untuk informasi selengkapnya, lihat Tentang Proxy Auth PostgreSQL untuk AlloyDB untuk PostgreSQL. Untuk koneksi dibuat dengan menggunakan Java, Python, atau Go, gunakan Konektor Bahasa alih-alih konektor Auth Proxy. AlloyDB untuk PostgreSQL membantu Anda memenuhi persyaratan residensi data. Data disimpan atau direplikasi di dalam region tempat Anda tentukan. |
BigQuery |
BigQuery menyediakan banyak fitur yang dapat Anda gunakan untuk mengontrol akses ke data, melindungi data sensitif, dan memastikan data akurasi dan konsistensi. 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 kunci yang dikelola Google. Jika diperlukan, Anda dapat menggunakan CMEK atau kunci Anda sendiri yang Anda kelola dengan menggunakan kunci seperti kunci enkripsi yang disediakan pelanggan (CSEK). Sebagai 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 dapat memberikan izin pada level bucket dan project. Untuk selengkapnya informasi, lihat Ringkasan kontrol akses. Data yang Anda muat ke subsistem penyerapan data melalui Cloud Storage mungkin mencakup data sensitif. Untuk melindungi data, Anda dapat menggunakan Sensitive Data Protection untuk menemukan, mengklasifikasi, dan melakukan de-identifikasi data. Untuk 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 tempat Anda tentukan. |
Pub/Sub |
Secara default, Pub/Sub mengenkripsi semua pesan, baik dalam penyimpanan dan saat transit, menggunakan kunci milik Google dan kunci yang dikelola Google. Pub/Sub mendukung penggunaan CMEK untuk pesan enkripsi di lapisan aplikasi. Untuk informasi selengkapnya, lihat Mengonfigurasi enkripsi pesan. Jika Anda memiliki persyaratan residensi data, untuk memastikan bahwa data pesan disimpan di lokasi tertentu, Anda dapat mengonfigurasi kebijakan penyimpanan pesan. |
Document AI | Secara default, data dalam penyimpanan dienkripsi menggunakan enkripsi yang dikelola Google tombol. Jika Anda perlu menggunakan kunci enkripsi yang Anda kontrol dan kelola, Anda dapat menggunakan CMEK. Untuk informasi selengkapnya, lihat Keamanan &Document AI Kepatuhan. |
Cloud Logging |
Log audit Aktivitas Admin diaktifkan secara default untuk semua Layanan Google Cloud yang digunakan dalam referensi ini tentang arsitektur 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 menggunakan BigQuery. Untuk layanan lain yang digunakan dalam Anda dapat mengaktifkan log audit Akses Data. Log 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 informasi selengkapnya, lihat Regionalisasi log. |
Untuk mendapatkan panduan umum tentang prinsip keamanan yang perlu dipertimbangkan dalam penerapan AI, lihat Memperkenalkan Framework Keamanan AI Google.
Keandalan
Bagian ini menjelaskan faktor-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 |
---|---|
Cloud Run |
Cloud Run adalah layanan regional. Data disimpan secara sinkron di beberapa zona dalam satu region. Lalu lintas adalah di-load balanced secara otomatis di seluruh zona. Jika pemadaman layanan zona terjadi, tugas Cloud Run terus berjalan dan data tidak turun. Jika terjadi pemadaman layanan region, tugas Cloud Run berhenti berjalan hingga Google menyelesaikan pemadaman layanan. Masing-masing tugas atau tugas Cloud Run mungkin gagal. Kepada untuk menangani kegagalan tersebut, Anda dapat menggunakan percobaan ulang tugas dan checkpoint. Untuk informasi selengkapnya, lihat Praktik terbaik percobaan ulang dan checkpoint tugas. |
AlloyDB untuk PostgreSQL |
Secara default, cluster AlloyDB untuk PostgreSQL menyediakan ketersediaan tinggi (HA) dengan failover otomatis. Instance utama memiliki redundansi {i>node<i} yang berada di dua zona berbeda dalam sebuah region. Ini redundansi memastikan bahwa cluster kuat terhadap zona pemadaman layanan. Untuk merencanakan pemulihan dari pemadaman layanan 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 informasi selengkapnya tentang fitur keandalan dalam BigQuery, lihat Memahami keandalan. |
Cloud Storage | Anda dapat membuat bucket Cloud Storage di salah satu dari tiga jenis lokasi: regional, region ganda, atau multi-region. Data yang disimpan di bucket regional direplikasi secara sinkron di beberapa zona dalam wilayah. Untuk ketersediaan yang lebih tinggi, Anda dapat menggunakan dual-region atau multi-region bucket, tempat data direplikasi secara asinkron di berbagai region. |
Pub/Sub |
Untuk mengelola lonjakan sementara pada traffic pesan, Anda dapat mengonfigurasi kontrol alur di setelan penayang. Untuk menangani publikasi yang gagal, sesuaikan variabel permintaan percobaan ulang sebagai diperlukan. Untuk informasi selengkapnya, lihat Mencoba ulang permintaan. |
Document AI | Document AI adalah layanan regional. Data disimpan secara sinkron di beberapa zona dalam satu region. Lalu lintas adalah di-load balanced secara otomatis di seluruh zona. Jika pemadaman layanan zona terjadi, data tidak hilang. Jika terjadi pemadaman layanan region, Document AI tidak tersedia hingga Google menyelesaikan pemadaman layanan. |
Pengoptimalan biaya
Bagian ini memberikan panduan untuk membantu Anda mengoptimalkan biaya penyiapan dan mengoperasikan aplikasi AI generatif berkemampuan RAG di Google Cloud.
Produk | Pertimbangan desain |
---|---|
Cloud Run |
Saat membuat tugas Cloud Run, Anda menentukan jumlah dari memori dan CPU untuk dialokasikan ke instance container. Kepada mengontrol biaya, mulai dengan CPU dan memori default (minimum) alokasi. Untuk meningkatkan performa, Anda dapat meningkatkan alokasi dengan mengonfigurasi CPU limit dan batas memori. Jika Anda dapat memprediksi kebutuhan CPU dan memori tugas Cloud Run, Anda dapat menghemat uang dengan mendapatkan diskon untuk abonemen. Untuk informasi selengkapnya, lihat Diskon abonemen Cloud Run. |
AlloyDB untuk PostgreSQL |
Secara default, instance utama cluster AlloyDB untuk PostgreSQL sangat tersedia (HA). Instance ini memiliki satu node aktif dan standby. Jika node aktif gagal, AlloyDB untuk PostgreSQL akan gagal ke {i>node<i} standby secara otomatis. Jika Anda tidak memerlukan HA untuk database, Anda dapat mengurangi biaya dengan menjadikan cluster instance dasar. Instance dasar tidak andal terhadap zona pemadaman dan memiliki waktu istirahat yang lebih lama selama operasi pemeliharaan. Sebagai informasi selengkapnya, lihat Mengurangi biaya menggunakan instance dasar. Jika Anda dapat memprediksi kebutuhan CPU dan memori AlloyDB untuk instance PostgreSQL, dan Anda dapat menghemat uang dengan 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 selengkapnya, lihat Memperkirakan dan mengontrol biaya. |
Cloud Storage | Untuk bucket Cloud Storage yang digunakan untuk memuat data ke dalam subsistem penyerapan data, pilih metode kelas penyimpanan berdasarkan retensi data dan frekuensi akses persyaratan workload Anda. Misalnya, Anda dapat memilih kelas penyimpanan, dan menggunakan Object Lifecycle Management untuk mengontrol biaya penyimpanan secara 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 dipertimbangkan 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 mengalokasikan satu CPU dan 512 MiB memori. Bergantung pada persyaratan performa untuk tugas Cloud Run, Anda dapat mengonfigurasi CPU limit dan batas memori. |
AlloyDB untuk PostgreSQL |
Untuk membantu menganalisis dan meningkatkan kinerja kueri {i>database<i}, AlloyDB untuk PostgreSQL menyediakan alat Insight Kueri. Anda dapat menggunakan alat ini untuk memantau kinerja dan melacak sumber kueri yang bermasalah. Untuk informasi selengkapnya, lihat Ringkasan Insight Kueri. Untuk mendapatkan ringkasan tentang status dan performa database Anda dan untuk melihat metrik mendetail seperti koneksi puncak dan replikasi lambat, Anda dapat menggunakan dasbor {i>System Insights<i}. Untuk selengkapnya informasi, lihat Memantau instance menggunakan AlloyDB untuk Insight Sistem PostgreSQL dasbor. Untuk mengurangi beban pada instance AlloyDB utama untuk PostgreSQL dan untuk menskalakan kapasitas guna menangani permintaan baca, Anda dapat menambahkan membaca instance kumpulan ke cluster. Untuk informasi selengkapnya, lihat AlloyDB untuk node dan instance PostgreSQL. |
BigQuery |
BigQuery menyediakan grafik eksekusi kueri yang dapat Anda gunakan untuk menganalisis kinerja kueri dan mendapatkan wawasan kinerja untuk masalah seperti pertentangan slot dan kuota acak yang tidak memadai. Untuk selengkapnya informasi, lihat Dapatkan insight performa kueri. Setelah Anda mengatasi masalah yang Anda identifikasi melalui kueri insight performa, Anda dapat lebih mengoptimalkan kueri dengan menggunakan teknik seperti mengurangi volume data {i>input<i} dan {i>output<i}. Sebagai informasi selengkapnya, lihat Optimalkan komputasi kueri. |
Cloud Storage | Untuk mengupload file besar, Anda dapat menggunakan metode yang disebut paralel upload gabungan. Dengan strategi ini, file berukuran besar akan dibagi menjadi potongan-potongan. Potongan diupload ke Cloud Storage di paralel, lalu datanya dikomposisi ulang di cloud. Paralel upload gabungan bisa lebih cepat daripada operasi upload reguler {i>bandwidth<i} jaringan dan kecepatan {i>disk<i} tidak membatasi. Namun, strategi ini memiliki beberapa batasan dan implikasi biaya. Untuk selengkapnya informasi, lihat Upload gabungan paralel. |
Deployment
Untuk memulai dan bereksperimen dengan membangun infrastruktur di Google Cloud untuk aplikasi AI generatif berkemampuan RAG, Anda dapat menggunakan Solusi Jump Start: RAG AI Generatif dengan Cloud SQL. Solusi ini men-deploy aplikasi {i>chat<i} berbasis Python pada 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 Bangun aplikasi AI generatif perusahaan dengan database Google Cloud.
- Pelajari caranya Aplikasi Pengambilan Database GenAI Baru membantu meningkatkan jawaban LLM.
- Coba Codelab untuk Bangun aplikasi chat berbasis LLM dan RAG menggunakan AlloyDB untuk PostgreSQL AI dan LangChain.
- Coba Peringkasan dokumen AI generatif.
- Baca tentang Pembuatan Augmented Pengambilan untuk Tugas NLP yang Intensif Pengetahuan.
- Baca tentang 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
- Nama Assaf | Principal Cloud Security Architect
- Balachandar Krishnamoorthy | Principal Software Engineer
- Daniel Lees | Arsitek Keamanan Cloud
- Derek Downey | Engineer Hubungan Developer
- Eran Lewis | Product Manager Senior
- Geoffrey Anderson | Manajer Produk
- Gleb Otochkin | Cloud Advocate, Database
- Hamsa Buvaraghan | Product Manager AI
- Irina Sigler | Manajer Produk
- Jack Wotherspoon | Insinyur Perangkat Lunak
- Jason Davenport | Advokat Developer
- Yordania Totten | Teknisi Pelanggan
- Julia Wiesinger | Manajer Produk
- Pelanggan Baru Kara | Teknisi Pelanggan
- Kurtis Van Gent | Staf Insinyur Perangkat Lunak
- Menurut Jacobsson | Insinyur Perangkat Lunak
- Pranav Nambiar | Sutradara
- Richard Hendricks | Staf Pusat Arsitektur
- Safiuddin Khaja | Engineer Cloud
- Sandy Ghai | Product Manager Grup
- Vladimir Vuskovic | Direktur Manajemen Produk
- Giannini Steren | Product Manager Grup
- Wietse Venema | Engineer Hubungan Developer