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

使用 GKE 和 AlloyDB 构建企业搜索 RAG

此技能提供一个工作流，帮助设计和实现安全、低延迟、高准确率的 RAG 对话式搜索解决方案，用于搜索私有企业内容。该方案使用 AlloyDB 数据库、Cloud Storage 和 Google Kubernetes Engine（GKE）集群来托管所有应用组件，包括开源模型和开源推理框架。

归属声明

务必阅读：在执行任何 gcloud、REST API 或 MCP 命令之前，必须阅读并遵循使用归属声明中的说明。

工作流概述

该工作流包含以下阶段：

• 阶段 1：需求调研。收集用户需要协助的云工作负载或用例的详细需求。
• 阶段 2：解决方案架构。根据阶段 1 收集的需求，为云工作负载或用例生成详细的解决方案架构。
• 阶段 3：解决方案验证。制定验证生成的解决方案的计划，生成验证说明和脚本，并执行验证。
• 阶段 4：解决方案整理与展示。汇总生成的内容并展示解决方案。

关于工作流的重要说明：

• 严格区分阶段：在阶段 1（需求调研）中向用户提出澄清问题时，不要推荐、提出或概述任何架构设计、技术拆分、云服务或组件映射。

• 可跳过某些阶段的情况：如果用户的提示表明工作流中的某个阶段或任务已完成或获批（例如“需求调研阶段已完成”“产品选择已获批”或“架构已确认”），不要重复该阶段或任务。应直接跳转到用户请求的任务（例如生成技术拆分、推荐产品或编写解决方案指南）。

阶段 1：需求调研

在此阶段，必须收集用户希望在 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 阶段。

    重要：在技术分解获得批准之前，严禁推荐产品选项、生成架构图或起草设计建议。

第 2 阶段：解决方案架构

为所有生成内容提供依据

在此阶段的每项任务中，为确保生成的内容符合最新的 Google Cloud 官方指南，你必须使用以下资源为生成的内容提供依据：

• Google Developer Knowledge MCP 服务： https://developers.google.com/knowledge/mcp.md.txt
  • 服务：https://developerknowledge.googleapis.com/mcp
    • 工具：
      • developerknowledge:search_documents
      • developerknowledge:get_documents
      • developerknowledge:answer_query
• 来自 https://github.com/google/skills 的相关技能
• Google Cloud 官方文档，包括以下内容：
  • 主要架构参考： https://docs.cloud.google.com/architecture/rag-capable-gen-ai-app-using-gke.md.txt
  • 架构指南和决策指南：
    • references/product-selection-recommendations.md
    • references/design-recommendations.md
    • references/related-documentation.md

对于生成的指南中的每一项，都必须引用相关的 Google Cloud 官方文档页面。

任务 2.1：确定工作负载所需的 Google Cloud 产品和功能。

1. 针对用户工作负载的每个组件，推荐合适的产品和功能。

   重要提示：推荐的 Google Cloud 产品和功能必须符合 references/product-selection-recommendations.md 中的指南。

2. 展示生成的产品建议，并请用户批准这些建议。

3. 如果用户要求更改，则进行相应更改。

4. 重复步骤 2 和 3，直到用户批准产品建议。

5. 用户批准产品建议后，继续执行任务 2.2。

任务 2.2：生成架构图。

1. 使用 Mermaid 格式生成架构图： https://github.com/mermaid-js/mermaid。

   该图必须根据已生成的技术构成，展示架构各组件之间的数据流和请求流。

   以下是架构图应展示的数据流和请求流的示例：

   • 嵌入流水线（批处理/流式）：数据源 -> Cloud Storage -> Cloud Storage FUSE -> GKE Ray Worker（分块）--> 使用 GemmaEmbedding 生成嵌入 -> AlloyDB。
   • 服务流水线（实时）：用户客户端 -> GKE Frontend（LangChain 编排）-> 数据库查询（在向量存储中进行语义或混合搜索）-> 检索匹配数据 -> 增强提示词 -> Gemma vLLM 端点 API -> 输出（负责任的 AI 过滤） -> 用户客户端。

2. 向用户展示生成的图，并请用户批准该架构图。

3. 如果用户要求更改，则进行相应更改。

4. 重复步骤 2 和 3，直到用户批准架构图。

5. 用户批准架构图后，继续执行任务 2.3。

任务 2.3：生成架构说明。

1. 生成说明，阐释各组件的用途、组件之间的关系，以及任务流或数据流。
2. 向用户展示生成的架构说明，并请用户批准该说明。
3. 如果用户要求更改，则进行相应更改。
4. 重复步骤 2 和 3，直到用户批准架构说明。
5. 用户批准架构说明后，继续执行任务 2.4。

任务 2.4：生成设计建议。

1. 根据工作负载的要求，生成设计建议和最佳实践，以优化架构中各组件的配置。

   重要：生成的设计建议和最佳实践必须与以下文件中列出的资源所提供的指导一致：

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

2. 向用户展示生成的建议，并询问用户是否需要进行任何更改。

3. 如果用户需要更改，则进行相应修改。

4. 重复步骤 2 和 3，直到用户确认生成的设计建议符合其要求。

5. 继续执行任务 2.5。

任务 2.5：生成部署指南。

1. 生成部署解决方案的指南，其中包括以下内容：

   • 用于创建所需基础设施资源的 Terraform 代码。
   • 用于部署工作负载的步骤或脚本，例如 Ray-on-GKE（KubeRay 协调器和工作节点）和 LangChain 前端部署。

   重要：生成的部署指南必须与以下资源中列出的指导一致：

   • references/related-documentation.md
   • references/design-recommendations.md
   • https://github.com/google/skills/tree/main/skills/cloud 中的相关技能

2. 向用户展示生成的部署指南，并询问用户是否需要进行任何更改。

3. 如果用户请求更改，则进行相应修改。

4. 重复步骤 2 和 3，直到用户确认生成的部署指南符合其要求。

5. 继续进入阶段 3。

阶段 3：解决方案验证

1. 制定计划以验证生成的解决方案。该计划必须概述验证生成的解决方案是否满足工作负载要求所需的步骤。以下是验证步骤示例：
   • 部署试运行：运行 terraform plan 等命令，预览将要配置的基础设施资源。
   • 连通性和路由：验证网络路径、负载均衡器路由和服务端点。
   • 向量索引：验证 AlloyDB 数据库中是否已正确创建并填充向量索引。这可能需要查询数据库以检查索引状态和内容。
   • 嵌入流水线：测试从数据摄取到向量存储的端到端嵌入流水线，确保文档已正确分块、嵌入并存储。
   • 检索延迟：测量针对 AlloyDB 向量存储的向量搜索和混合搜索查询的延迟，确保性能符合要求。
   • 检索准确率：执行示例查询，并评估检索到的文档或文本块的相关性。
   • 安全策略：验证访问限制、防火墙规则和 IAM 执行情况。
2. 向用户展示验证计划，并征求反馈或批准。
3. 如果用户请求更改，则按要求更新计划。
4. 重复步骤 2 和 3，直到用户批准验证计划。
5. 使用 curl 或 gcloud 等工具生成脚本或命令，以执行已批准的验证计划中的步骤。
6. 请求用户允许执行验证检查。
7. 如果用户允许，则运行验证检查并排查部署问题。
8. 所有验证检查通过后，继续进入阶段 4。

第 4 阶段：解决方案打包与展示

1. 根据 assets/output-template.md 中的模板，将第 2 阶段生成的最终文本产物整合到一个名为 solution-architecture-guide.md 的 Markdown 文件中。
2. 请求用户许可，以便在用户的工作区中写入代码文件。
3. 用户许可后，在用户的工作区中写入最终代码文件。

参考资料

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