google-cloud-solution-rag-enterprise-search-gke-sqldb
>- Discovers requirements, and generates architectural, design, and deployment guidance for a retrieval-augmented generation (RAG)-capable enterprise search system in Google Cloud. Use when users need a vector-enabled SQL database as the store and index for the embedding vectors, an open model and open-source inferencing framework, and Kubernetes containers to host all the application components. DON'T use this skill for fully-managed RAG, or SaaS search services, or when a non-SQL vector database is required.
Why we recommend it: Generates architectural, design, and deployment guidance for a RAG enterprise search system on GKE and AlloyDB, including solution architecture phases.
Inspect before use
Read the source instructions and check the requirements before you install this skill.
SKILL.md
The saved excerpt is a snapshot from when this skill was listed. The external source remains the complete and most current version.
---
name: google-cloud-solution-rag-enterprise-search-gke-sqldb
metadata:
category: MultiProductSolutions
description: >-
Discovers requirements, and generates architectural, design, and deployment
guidance for a retrieval-augmented generation (RAG)-capable enterprise search
system in Google Cloud. Use when users need a vector-enabled SQL database as
the store and index for the embedding vectors, an open model and open-source
inferencing framework, and Kubernetes containers to host all the application
components. DON'T use this skill for fully-managed RAG, or SaaS search
services, or when a non-SQL vector database is required.
---
# RAG for enterprise search using GKE and AlloyDB
This skill provides a workflow to design and implement a secure, low-latency,
and high-accuracy RAG-enabled conversational search solution for private
enterprise content by using an AlloyDB database, Cloud Storage, and a Google
Kubernetes Engine (GKE) cluster to host all the application components,
including an open model and an open-source inference framework.
## Overview of the workflow
The workflow consists of the following phases:
* **Phase 1: Requirements discovery**. Gather detailed requirements related to
the cloud workload or use case that the user needs assistance for.
* **Phase 2: Solution architecture**. Use the requirements that were gathered
in Phase 1 to generate a detailed solution architecture for the cloud
workload or use case.
* **Phase 3: Solution validation**. Create a plan to validate the generated
solution, generate validation instructions and scripts, and run the
validation.
* **Phase 4: Solution packing and presentation**. Consolidate the generated
content and present the solution.
**Important notes about the workflow**:
* **Strict phase separation**: During Phase 1 (Requirements discovery), when
you ask the user clarifying questions, DON'T recommend, propose, or outline
any architectural designs, technical decompositions, cloud services, or
component mappings.
* **When you can skip certain phases**: If the user's prompt indicates that a
specific phase or task in this workflow is already completed or approved
(e.g., "requirements discovery stage is completed", "product selection is
approved", or "architecture is confirmed"), DON'T repeat that phase or task.
Instead, skip directly to the requested task (such as generating the
technical decomposition, recommending products, or compiling the solution
guide).
## Phase 1: Requirements discovery
In this phase, you must gather detailed requirements related to the RAG workload
that the user wants to design and deploy in Google Cloud.
Complete the following steps strictly in the specified order:
1. Ask the user to describe the functional requirements of the workload,
including data types (structured, unstructured), ingestion frequency, and
conversational features (e.g., multi-turn chat, citation requirements).
2. Ask the user to describe the following non-functional requirements:
* **Security, privacy, and compliance**: E.g., network isolation, private
endpoints, data residency, and requirements for compliance.
* **Reliability**: E.g., scaling, high availability, resilience against
zone or regional outages, disaster recovery goals for RTO and RPO.
* **Cost**: E.g., cost of compute, storage, and database resources.
* **Operational excellence**: E.g., monitoring, alerts, and logging.
* **Performance**: E.g., data upload speed, performance expectations for
generating embedding vectors, and latency requirements for model
responses and data retrieval queries (including vector and hybrid
search).
* **Sustainability**: E.g., carbon footprint, low-carbon regions.
3. Ask the user whether the workload currently runs on other cloud providers or
on-premises.
* If the user's answer is "yes", then ask the useRead the full source on GitHub (opens external page)