Back to Details

google-cloud-solution-rag-enterprise-search-gke-sqldb

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

RAG for enterprise search using GKE and AlloyDB

使用GKE和AlloyDB实现面向企业搜索的RAG

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.
本技能提供一套工作流，用于设计并实现一个安全、低延迟、高精度的支持RAG的对话式搜索解决方案，以处理私有企业内容。方案采用AlloyDB数据库、Cloud Storage，以及Google Kubernetes Engine（GKE）集群托管所有应用组件，包括开源模型和开源推理框架。

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).
该工作流包含以下阶段：
  • 阶段1：需求挖掘。收集与用户需要协助的云工作负载或用例相关的详细需求。
  • 阶段2：解决方案架构。利用阶段1收集的需求，为云工作负载或用例生成详细的解决方案架构。
  • 阶段3：解决方案验证。创建验证生成方案的计划，生成验证说明和脚本，并执行验证。
  • 阶段4：解决方案打包与呈现。整合生成的内容并呈现解决方案。
工作流重要说明：
  • 严格的阶段分离：在阶段1（需求挖掘）中，当您向用户询问澄清问题时，请勿推荐、提议或概述任何架构设计、技术分解、云服务或组件映射。
  • 何时可跳过特定阶段：如果用户的提示表明本工作流中的某个特定阶段或任务已完成或获批（例如：“需求挖掘阶段已完成”、“产品选择已获批”或“架构已确认”），请勿重复该阶段或任务。直接跳转到用户请求的任务（如生成技术分解、推荐产品或编制解决方案指南）。

Phase 1: Requirements discovery

阶段1：需求挖掘

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 user to describe the architecture of the current deployment.
    • If the user's answer is "no", then proceed to the next step.
  4. Ask the user to describe dependencies, if any, on other workloads, products, or tools (e.g., identity providers, external sources, CRM/ERP database integrations).
  5. Review the input that the user has provided so far, and check whether there are any ambiguities or contradictions.
    If you identify any ambiguities or contradictions in the requirements that the user has provided, then do the following for each ambiguity or contradiction that you identify:
    • Describe the ambiguity or contradiction.
    • Ask the user how they wish to resolve the ambiguity or contradiction.
      • If the user delegates the choice to you (e.g., the user replies with "do what you think is best" or "you decide"), then provide a clear suggestion to resolve the ambiguity or contradiction, explain your reasoning, and ask the user to approve your suggestion.
    Critical: Until all the ambiguities and contradictions that you identify are resolved according to the preceding guidance, you must NOT recommend or generate any architecture design, technical decomposition, or Google Cloud product recommendations.
  6. Important: DON'T start this step if there are unresolved contradictions or ambiguities from Step 5.
    Generate a technical decomposition of the components of the workload. The technical decomposition must break down the solution into logical components, as follows:
    • Data ingestion: Blob storage for raw corporate documents.
    • Data processing and chunking: Containerized pipeline to extract data, clean it, and chunk it.
    • Embedding vectors generation: Containerized service to convert data chunks to embedding vectors.
    • Storing and indexing the embedding vectors: Vector-enabled SQL database for storing embedding vectors.
    • Handling non-vector data: Preparing non-vector data, like tables, views, and aggregations for data retrieval. Analyzing whether any indexing, partitioning, or other performance techniques can be applied on the original data schema.
    • Query and retrieval: Accepting client queries, identifying intent, and routing to a retrieval workflow, which might include conversion of the request to an embedding for semantic search, extracting and applying filters for filtered search or supplying all to the hybrid search.
    • Prompt augmentation: Augmenting the prompts with the retrieved context.
    • Response generation: Requesting and generating responses from the model.
    • Response sanity checks: Evaluating responses using an AI model and performing procedural checks according to defined criteria.
  7. Ask the user to approve the generated technical decomposition.
    Critical: You MUST stop execution immediately, call no more tools (such as file editors, searches, or code tools), and wait for the user to respond with their feedback or approval in the chat. Do NOT compile the architecture, recommend products, construct maps, or write any files/drafts for Phase 2 until the user's explicit approval is received.
  8. If the user requests changes, then generate an updated technical decomposition.
  9. Repeat steps 5 through 8 until the user approves the generated technical decomposition.
  10. Only after the user has explicitly approved the technical decomposition, proceed to Phase 2.
    Important: You are strictly prohibited from recommending product choices, generating the architecture diagram, or drafting design recommendations until the technical decomposition is approved.
在本阶段，您必须收集与用户希望在Google Cloud中设计和部署的RAG工作负载相关的详细需求。
严格按照指定顺序完成以下步骤：
  1. 请用户描述工作负载的功能需求，包括数据类型（结构化、非结构化）、摄入频率，以及对话功能（如多轮对话、引用要求）。
  2. 请用户描述以下非功能需求：
    • 安全、隐私与合规：例如网络隔离、私有端点、数据驻留以及合规要求。
    • 可靠性：例如扩容、高可用性、应对区域或可用区故障的韧性、灾难恢复的RTO和RPO目标。
    • 成本：例如计算、存储和数据库资源的成本。
    • 运维卓越性：例如监控、告警和日志记录。
    • 性能：例如数据上传速度、生成嵌入向量的性能预期，以及模型响应和数据检索查询（包括向量搜索和混合搜索）的延迟要求。
    • 可持续性：例如碳足迹、低碳区域。
  3. 询问用户该工作负载当前是否运行在其他云提供商或本地环境中。
    • 如果用户回答“是”，则请用户描述当前部署的架构。
    • 如果用户回答“否”，则进入下一步。
  4. 询问用户是否存在对其他工作负载、产品或工具的依赖（如身份提供商、外部数据源、CRM/ERP数据库集成）。
  5. 回顾用户目前提供的输入，检查是否存在任何歧义或矛盾。
    如果您在用户提供的需求中发现任何歧义或矛盾，请针对每个识别出的歧义或矛盾执行以下操作：
    • 描述该歧义或矛盾。
    • 询问用户希望如何解决该歧义或矛盾。
      • 如果用户将选择权委托给您（例如用户回复“按你认为最好的方式做”或“你来决定”），则提供清晰的解决方案建议，解释您的推理，并请用户批准您的建议。
    关键要求：在所有识别出的歧义或矛盾按照上述指导解决之前，您不得推荐或生成任何架构设计、技术分解或Google Cloud产品建议。
  6. 重要提示：如果步骤5中存在未解决的矛盾或歧义，请不要开始此步骤。
    生成工作负载组件的技术分解。技术分解必须将解决方案拆分为以下逻辑组件：
    • 数据摄入：用于存储原始企业文档的Blob存储。
    • 数据处理与分块：容器化流水线，用于提取、清洗数据并进行分块。
    • 嵌入向量生成：容器化服务，用于将数据块转换为嵌入向量。
    • 嵌入向量存储与索引：支持向量的SQL数据库，用于存储嵌入向量。
    • 非向量数据处理：准备非向量数据（如表、视图和聚合）以用于数据检索。分析是否可以对原始数据架构应用索引、分区或其他性能优化技术。
    • 查询与检索：接收客户端查询、识别意图并路由到检索工作流，这可能包括将请求转换为嵌入向量以进行语义搜索、提取并应用筛选条件进行过滤搜索，或提供所有内容进行混合搜索。
    • 提示词增强：用检索到的上下文增强提示词。
    • 响应生成：请求模型并生成响应。
    • 响应合理性检查：使用AI模型评估响应，并根据定义的标准执行流程检查。
  7. 请用户批准生成的技术分解。
    关键要求：您必须立即停止执行，不再调用任何工具（如文件编辑器、搜索或代码工具），等待用户在聊天中反馈或批准。在收到用户明确批准之前，请勿编制架构、推荐产品、构建映射或为阶段2编写任何文件/草稿。
  8. 如果用户要求修改，则生成更新后的技术分解。
  9. 重复步骤5至8，直到用户批准生成的技术分解。
  10. 只有在用户明确批准技术分解后，才能进入阶段2。
    重要提示：在技术分解获批之前，严禁推荐产品选择、生成架构图或起草设计建议。

Phase 2: Solution architecture

阶段2：解决方案架构

Ground all generated content

锚定所有生成内容

For each task in this phase, to ensure that the generated content aligns with the latest and official Google Cloud guidance, you must ground the generated content by using the following resources:
For each item in the generated guidance, you must include citations to the relevant official Google Cloud documentation pages.
对于本阶段的每个任务，为确保生成内容符合最新的官方Google Cloud指导，您必须使用以下资源锚定生成内容：
对于生成指南中的每个条目，您必须包含相关官方Google Cloud文档页面的引用。

Task 2.1: Identify Google Cloud products and features required for the workload.

任务2.1：识别工作负载所需的Google Cloud产品和功能

  1. Recommend the products and features that are appropriate for each component of the user's workload.
    Important: The Google Cloud products and features that you recommend MUST be consistent with the guidance in 
    references/product-selection-recommendations.md
    .
  2. Present the generated product recommendations and ask the user to approve the recommendations.
  3. If the user requests changes, then make the required changes.
  4. Repeat steps 2 and 3 until the user approves the product recommendations.
  5. After the user approves the product recommendations, proceed to Task 2.2.
  1. 为用户工作负载的每个组件推荐合适的产品和功能。
    重要提示：您推荐的Google Cloud产品和功能必须与
    references/product-selection-recommendations.md
    中的指导一致。
  2. 呈现生成的产品建议，并请用户批准该建议。
  3. 如果用户要求修改，则进行必要的调整。
  4. 重复步骤2和3，直到用户批准产品建议。
  5. 用户批准产品建议后，进入任务2.2。

Task 2.2: Generate an architecture diagram.

任务2.2：生成架构图

  1. Generate an architecture diagram in the Mermaid format: https://github.com/mermaid-js/mermaid.
    The diagram must show the data flows and request flows across the components of the architecture, based on the technical composition that you generated.
    The following is an example of the data flows and request flows that the architecture diagram should show:
    • Embedding pipeline (batch/streaming): Data source -> Cloud Storage -> Cloud Storage FUSE -> GKE Ray Worker (Chunking) --> Embedding generation using GemmaEmbedding -> AlloyDB.
    • Serving pipeline (real-time): User client -> GKE Frontend (LangChain Orchestration) -> Database Query (semantic or hybrid search on the vector store) -> Retrieve matching data -> Augment prompt -> Gemma vLLM endpoint API -> Output (Responsible AI filtering) -> User client.
  2. Present the generated diagram to the user and ask the user to approve the architecture diagram.
  3. If the user requests changes, then make the required changes.
  4. Repeat steps 2 and 3 until the user approves the architecture diagram.
  5. After the user approves the architecture diagram, proceed to Task 2.3.
  1. 使用Mermaid格式生成架构图： https://github.com/mermaid-js/mermaid.
    该图必须基于您生成的技术组成，展示架构各组件之间的数据流和请求流。
    以下是架构图应展示的示例数据流和请求流：
    • 嵌入流水线（批量/流式）：数据源 -> Cloud Storage -> Cloud Storage FUSE -> GKE Ray Worker（分块） --> 使用GemmaEmbedding生成嵌入向量 -> AlloyDB。
    • 服务流水线（实时）：用户客户端 -> GKE前端（LangChain编排） -> 数据库查询（向量存储上的语义或混合搜索） -> 检索匹配数据 -> 增强提示词 -> Gemma vLLM端点API -> 输出（负责任AI过滤） -> 用户客户端。
  2. 向用户呈现生成的图，并请用户批准该架构图。
  3. 如果用户要求修改，则进行必要的调整。
  4. 重复步骤2和3，直到用户批准架构图。
  5. 用户批准架构图后，进入任务2.3。

Task 2.3: Generate an architecture description.

任务2.3：生成架构描述

  1. Generate a description that explains the purpose of each component, the relationships between the components, and the task flow or data flow.
  2. Present the generated architecture description to the user and ask the user to approve the description.
  3. If the user requests any changes, then make the required changes.
  4. Repeat steps 2 and 3 until the user approves the architecture description.
  5. After the user approves the architecture description, proceed to Task 2.4.
  1. 生成描述，解释每个组件的用途、组件之间的关系以及任务流或数据流。
  2. 向用户呈现生成的架构描述，并请用户批准该描述。
  3. 如果用户要求修改，则进行必要的调整。
  4. 重复步骤2和3，直到用户批准架构描述。
  5. 用户批准架构描述后，进入任务2.4。

Task 2.4: Generate design recommendations.

任务2.4：生成设计建议

  1. Generate design recommendations and best practices to optimally configure each component in the architecture based on the workload's requirements.
    Important: The design recommendations and best practices that you generate MUST be consistent with the guidance in the resources that are listed in the following files:
    • references/related-documentation.md
    • references/design-recommendations.md
  2. Present the generated recommendations to the user and ask whether the user needs any changes.
  3. If the user needs changes, then make the required changes.
  4. Repeat steps 2 and 3 until the user confirms that the generated design recommendations meet their requirements.
  5. Proceed to Task 2.5.
  1. 根据工作负载的需求，生成架构中每个组件的最优配置设计建议和最佳实践。
    重要提示：您生成的设计建议和最佳实践必须与以下文件中列出的资源指导一致：
    • references/related-documentation.md
    • references/design-recommendations.md
  2. 向用户呈现生成的建议，并询问用户是否需要修改。
  3. 如果用户需要修改，则进行必要的调整。
  4. 重复步骤2和3，直到用户确认生成的设计建议符合其需求。
  5. 进入任务2.5。

Task 2.5: Generate deployment guidance.

任务2.5：生成部署指南

  1. Generate guidance to deploy the solution, including the following:
    • Terraform code to create the required infrastructure resources.
    • Steps or scripts to deploy workloads, such as Ray-on-GKE (KubeRay coordinator and worker nodes) and the LangChain frontend deployment.
    Important: The deployment guidance that you generate MUST be consistent with the guidance in the resources that are listed in the following resources:
  2. Present the generated deployment guidance to the user and ask whether the user needs any changes.
  3. If the user requests changes, then make the required changes.
  4. Repeat steps 2 and 3 until the user confirms that the generated deployment guidance meets their requirements.
  5. Proceed to Phase 3.
  1. 生成解决方案的部署指南，包括：
    • 创建所需基础设施资源的Terraform代码。
    • 部署工作负载的步骤或脚本，例如Ray-on-GKE（KubeRay协调器和工作节点）和LangChain前端部署。
    重要提示：您生成的部署指南必须与以下资源中列出的指导一致：
  2. 向用户呈现生成的部署指南，并询问用户是否需要修改。
  3. 如果用户要求修改，则进行必要的调整。
  4. 重复步骤2和3，直到用户确认生成的部署指南符合其需求。
  5. 进入阶段3。

Phase 3: Solution validation

阶段3：解决方案验证

  1. Create a plan to validate the generated solution. The plan must outline the steps that are necessary to verify that the generated solution meets the workload's requirements. The following are examples of validation steps:
    • Deployment dry-run: Run commands like 
      terraform plan
      to preview the infrastructure resources that will be provisioned.
    • Connectivity and routing: Verify network paths, load balancer routing, and service endpoints.
    • Vector index: Verify that vector indexes are correctly created and populated in the AlloyDB database. This can involve querying the database to check index status and content.
    • Embedding pipeline: Test the end-to-end embedding pipeline from data ingestion to vector storage, ensuring documents are chunked, embedded, and stored correctly.
    • Retrieval latency: Measure the latency of vector and hybrid search queries against the AlloyDB vector store to ensure performance meets requirements.
    • Retrieval accuracy: Perform sample queries and evaluate the relevance of retrieved documents or chunks.
    • Security policies: Verify restricted access, firewall rules, and IAM enforcement.
  2. Present the validation plan to the user and request feedback or approval.
  3. If the user requests changes, update the plan as required.
  4. Repeat steps 2 and 3 until the user approves the validation plan.
  5. Generate scripts or commands using tools like 
    curl
    or 
    gcloud
    to perform the steps in the approved validation plan.
  6. Request permission from the user to perform the validation checks.
  7. If the user gives permission, run the validation checks and troubleshoot any deployment issues.
  8. When all the validation checks pass, proceed to Phase 4.
  1. 创建验证生成方案的计划。该计划必须概述验证生成方案是否满足工作负载需求所需的步骤。以下是验证步骤的示例：
    • 部署预演：运行
      terraform plan
      等命令，预览将配置的基础设施资源。
    • 连通性与路由：验证网络路径、负载均衡器路由和服务端点。
    • 向量索引：验证AlloyDB数据库中是否正确创建并填充了向量索引。这可以通过查询数据库检查索引状态和内容来实现。
    • 嵌入流水线：测试从数据摄入到向量存储的端到端嵌入流水线，确保文档被正确分块、嵌入并存储。
    • 检索延迟：测量针对AlloyDB向量存储的向量搜索和混合搜索查询的延迟，确保性能符合要求。
    • 检索准确性：执行示例查询并评估检索到的文档或数据块的相关性。
    • 安全策略：验证受限访问、防火墙规则和IAM实施情况。
  2. 向用户呈现验证计划并请求反馈或批准。
  3. 如果用户要求修改，则按需更新计划。
  4. 重复步骤2和3，直到用户批准验证计划。
  5. 使用
    curl
    或
    gcloud
    等工具生成执行已批准验证计划中步骤的脚本或命令。
  6. 请求用户允许执行验证检查。
  7. 如果用户允许，执行验证检查并排查任何部署问题。
  8. 所有验证检查通过后，进入阶段4。

Phase 4: Solution packaging and presentation

阶段4：解决方案打包与呈现

  1. Consolidate the final text artifacts that were generated in Phase 2 into a single Markdown file named 
    solution-architecture-guide.md
    , based on the template in 
    assets/output-template.md
    .
  2. Request the user's permission to write the code files in the user's workspace.
  3. After the user gives permission, write the final code files in the user's workspace.
  1. 将阶段2中生成的最终文本工件整合到一个名为
    solution-architecture-guide.md
    的Markdown文件中，基于
    assets/output-template.md
    中的模板。
  2. 请求用户允许在用户工作区中写入代码文件。
  3. 用户允许后，在用户工作区中写入最终代码文件。

Supporting references

支持参考资料

  • references/product-selection-recommendations.md
  • references/design-recommendations.md
  • references/related-documentation.md
  • references/product-selection-recommendations.md
  • references/design-recommendations.md
  • references/related-documentation.md