Skill detail

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.

MatchPossibleRecommended for Architecture Diagram
Sourcegoogle/​skillsExternal source
Reported installsNot reportedPopularity signal only

Inspect before use

Read the source instructions and check the requirements before you install this skill.

Saved source preview

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 use
Read the full source on GitHub (opens external page)
Context

Related work