在 Google Cloud 上用 GKE 与…

当需要为私有企业内容构建基于向量 SQL 数据库、开源模型与 Kubernetes 的 RAG 企业搜索系统时，按四阶段工作流逐步产出并确认架构与部署方案。

适用场景

解决思路

1. 阶段一需求发现：先让用户描述功能需求，包括数据类型（结构化/非结构化）、数据摄取频率，以及对话特性（如多轮对话、引用要求）。
2. 继续收集非功能需求：安全/隐私/合规（网络隔离、私有端点、数据驻留、合规要求）、可靠性（扩缩容、高可用、跨可用区或区域故障恢复、RTO/RPO）、成本（计算/存储/数据库）、运维卓越（监控、告警、日志）、性能（上传速度、向量生成性能、模型响应与检索查询含向量与混合搜索的延迟）、可持续性（碳足迹、低碳区域）。
3. 询问工作负载当前是否运行在其他云或本地；若是，让用户描述现有部署架构；若否，进入下一步。
4. 询问是否存在对其他工作负载、产品或工具的依赖（如身份提供商、外部数据源、CRM/ERP 数据库集成）。
5. 审查已收集的需求，找出歧义或矛盾：逐条描述歧义/矛盾并询问用户如何解决；若用户授权你决定，则给出明确建议、解释理由并请用户批准。在所有歧义与矛盾解决前，不得推荐或生成任何架构设计、技术分解或 GCP 产品建议。
6. 在无未解决矛盾的前提下，生成技术分解，拆分为：数据摄取（原始文档的 Blob 存储）、数据处理与分块（容器化流水线做抽取、清洗、分块）、嵌入向量生成（容器化服务将分块转为向量）、向量存储与索引（支持向量的 SQL 数据库）、非向量数据处理（表/视图/聚合的准备，并分析索引、分区等性能优化）、查询与检索（接收查询、识别意图、路由到检索流程，含语义搜索的向量化、过滤搜索的过滤条件提取或混合搜索）、提示增强（用检索到的上下文增强提示）、响应生成（请求模型生成回答）、响应合理性检查（用 AI 模型评估并按既定标准做程序化检查）。
7. 请用户批准技术分解；必须立即停止执行、不再调用任何工具，等待用户在对话中反馈或批准；在获得明确批准前不得编写架构、推荐产品、构建映射或写任何文件/草稿。
8. 若用户要求修改，则生成更新后的技术分解，并重复审查歧义与请批准步骤，直到用户批准；只有明确批准后才进入阶段二。
9. 阶段二需为生成内容做依据支撑：使用 Google Developer Knowledge MCP 服务器（https://developerknowledge.googleapis.com/mcp，工具 search_documents、get_documents、answer_query）、https://github.com/google/skills 的相关技能，以及官方文档（主架构参考 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）；每条建议都要附官方文档引用。
10. 任务 2.1：为工作负载各组件推荐合适的产品与功能，必须与 product-selection-recommendations.md 一致；展示推荐并请用户批准，按反馈修改，直到批准后进入任务 2.2。
11. 任务 2.2：用 Mermaid 格式生成架构图，展示各组件间的数据流与请求流，例如嵌入流水线：数据源 -> Cloud Storage -> Cloud Storage FUSE -> GKE Ray Worker（分块）-> 用 GemmaEmbedding 生成嵌入 -> AlloyDB；服务流水线：用户客户端 -> GKE 前端（LangChain 编排）-> 数据库查询（向量存储上的语义或混合搜索）-> 检索匹配数据 -> 增强提示 -> Gemma vLLM 端点 API -> 输出（Responsible AI 过滤）-> 用户客户端；展示并请用户批准，按反馈修改直到批准后进入任务 2.3。
12. 任务 2.3：生成架构描述，说明每个组件用途、组件间关系以及任务流或数据流；展示并请用户批准，按反馈修改直到批准后进入任务 2.4。
13. 任务 2.4：基于工作负载需求生成各组件的设计建议与最佳实践，必须与 related-documentation.md 和 design-recommendations.md 一致；展示并询问是否需要修改，按反馈修改直到用户确认满足需求后进入任务 2.5。
14. 任务 2.5：生成部署指导，包括创建所需基础设施资源的 Terraform 代码，以及部署工作负载的步骤或脚本（如 Ray-on-GKE 的 KubeRay 协调器与工作节点、LangChain 前端部署）；必须与 related-documentation.md、design-recommendations.md 及 https://github.com/google/skills/tree/main/skills/cloud 相关技能一致；展示并询问是否需要修改，按反馈修改直到用户确认后进入阶段三。
15. 阶段三：制定验证计划，列出验证方案满足需求的步骤，例如部署试运行（如 terraform plan 预览将创建的资源）、连通性与路由（验证网络路径、负载均衡路由、服务端点）、向量索引（验证 AlloyDB 中向量索引正确创建并填充，可查询数据库检查索引状态与内容）、嵌入流水线（端到端测试从摄取到向量存储，确保文档正确分块、嵌入与存储）、检索延迟（测量 AlloyDB 向量存储上向量与混合搜索查询延迟）、检索准确性（抽样查询并评估检索文档或分块的相关性）、安全策略（验证访问限制、防火墙规则与 IAM 执行）。
16. 展示验证计划并请求反馈或批准，按反馈修改直到批准；然后用 curl 或 gcloud 等工具生成执行验证步骤的脚本或命令；请求用户许可后运行验证并排查部署问题；所有验证通过后进入阶段四。
17. 阶段四：按 assets/output-template.md 模板，将阶段二生成的最终文本产物整合为单个 Markdown 文件 solution-architecture-guide.md；请求用户许可后，将最终代码文件写入用户工作区。

适用边界 · 注意事项

• 不适用于全托管的 RAG 方案或 SaaS 搜索服务。
• 不适用于需要使用非 SQL 向量数据库的场景。