Target 如何借助 Spanner Graph 将数据库维护成本降低 50% 并提升零售发现体验

通向职场人工智能的前门

在当今的零售环境中，购物者期望获得高度个性化的产品发现体验，以及感觉真实、自然且真正有帮助的对话式辅助。如今，成功的产品发现不仅仅关乎关键词和基本浏览，而是理解语义意义以及产品、类别和顾客意图之间丰富且相互关联的关系。

在 Target，这项工作由我们的顾客产品信心平台团队负责。他们负责构建能够建立信任并引导购买决策的功能，例如评分、评论和由人工智能驱动的数字购物助手。其中一个令人兴奋的例子是我们的礼物搜索聊天代理：https://www.target.com/gift-finder，我们在 2025 年的假日季节在网上和 Target 应用中推出，帮助购物者通过友好、对话式的互动发现完美的商品。

为了在全球范围内提供实时个性化和语义丰富的响应，我们确定了一个关键的架构需求，即从碎片化的数据生态系统转向统一的数据平台。我们需要一个能够同时支持高吞吐量事务型工作负载、高度关联的图形关系、向量相似性搜索和全文关键词搜索的解决方案。

在本文中，我们将探讨如何通过 Spanner 实现这四项功能。

以前，Target 的发现数据生态系统依赖于 Elasticsearch 集群进行搜索和倒排索引，同时为我们的事务数据使用独立的 NoSQL 数据存储。虽然功能可用，但这种碎片化架构带来了显著的运营和技术挑战。

上下文断开：保持独立的搜索、向量和事务数据库完全同步是一项持续的挑战。信息孤立导致上下文缺失、属性关系不连贯以及查询结果不一致。

高运营开销：管理独立集群、调优搜索索引，以及处理复杂的自定义同步和聚合逻辑，需要工程团队进行大量手动干预。

扩展瓶颈：扩展我们的零售数据域需要添加新的数据库集合、维护复杂的连接，并在我们的发现系统和核心事务系统之间应对弱事务保证。

孤立的智能：我们缺乏在单一事务中查询图关系、向量相似性和关键字搜索索引的能力。

为了构建下一代以 AI 驱动的客户体验，我们需要在一个平台上实现整合。

我们评估了多种专业技术，包括独立的向量数据库和小众图数据库。然而，增加更多单一用途的数据库只会加剧我们的运营复杂性和数据同步管道的问题。

我们最终选择了 Spanner Graph：https://docs.cloud.google.com/spanner/docs/graph/overview 来构建我们的企业本体，这是一个“图中之图”的范式，使我们能够构建一个庞大、由生成式 AI 驱动的购物图。

通过统一我们的数据，我们将语义数据、图关系、向量嵌入和运营事务整合到一个平台。这确立了 Spanner 作为我们事务状态和语义智能的唯一权威数据源。

我们现在的高层架构由三个核心支柱组成：

1. 企业增强层：这一层捕获我们的企业零售目录，从多个后端来源聚合相关元数据，并利用生成式 AI 进行智能数据增强，从而显著提高我们获取的产品数据的质量和深度。

2. 统一的图、向量和搜索存储：Spanner Graph 将我们的实体节点、关系边和向量嵌入存储在同一数据库引擎中，而无需在多个数据库之间移动数据。Spanner Graph 原生支持多跳图遍历、语义向量相似性以及对关系表的全文关键字查询。由于这种多模型协同是原生的，我们在分布式工作负载中可以获得严格的 ACID 事务保证，确保绝对正确性，而无需依赖脆弱的外部同步管道。

3. 编排和人工智能层 这一层为我们的对话式客户界面提供支持，利用直接从 Spanner Graph 提供的丰富结构化上下文来为我们的 LLM 提供基础。它提取高度特定的产品关系，以支持如礼物查找器（https://www.target.com/gift-finder）等工具，同时管理负责任的人工智能流程并评估生成的输出。

过渡数百万客户依赖的关键搜索和发现基础设施需要谨慎的零停机方法。我们以四个结构化阶段执行了这一迁移。

模式和本体映射：我们定义了特定的零售实体，如产品、类别、品牌和客户偏好，以及它们在 Spanner Graph 模式中的相应关系。

数据集成和平行重放：我们在平行管道中构建了基于变更的数据集成。这允许我们持续重放实时交易更新，应用模式转换，生成嵌入，并实时将其直接写入 Spanner Graph。

金丝雀部署：我们逐步将实时读取流量转移到新的 Spanner Graph 支持平台，验证查询性能、语义准确性以及真实零售工作负载下的数据库稳定性。

切换和清理：一旦性能经过彻底验证，我们完全将所有搜索和发现流量迁移到 Spanner，并废弃我们的遗留 Elasticsearch 堆栈，彻底消除了这些集群的维护负担。

通过直接构建于 Spanner Graph，我们实现了可衡量的技术和业务成果：

终极 GraphRAG 基础：传统的 RAG 依赖于平面向量相似度，这常常忽略了产品之间的结构化关联，如匹配玩具及其兼容配件或适龄性。通过在统一的 GraphRAG 架构中结合深度图遍历与语义向量搜索，我们用高度精确的上下文为 LLM 提供基础。这直接提高了我们的推荐相关性，增强了客户满意度，并提升了我们的净推荐值（NPS）。

整合 SQL + GQL 互操作性：借助 Spanner Graph，我们的开发者可以使用标准 SQL 和 GQL（图查询语言）在单个查询中同时查询结构化关系型目录数据和连接的图关系。这消除了为了桥接这些范式而进行的数据复制、延迟或复杂 ETL 流程的需要。

无服务器可扩展性，无增长上限：在黑色星期五和网络星期一等零售高峰活动期间，Spanner 自动处理了大量不可预测的流量激增。Spanner 内置的自动扩展器能够在高强度的限时促销期间动态调整计算能力，以处理突发流量而不影响性能。

基础设施维护减少 50%：通过将我们的事务型 NoSQL 和搜索索引数据库整合到单一的托管 Google Cloud 服务中，我们消除了维护独立数据库集群的运营负担。我们的开发者现在在数据库管理和基础设施维护上节省了 50% 的时间，使我们能够更快地构建和部署面向客户的全新 AI 功能。

迁移到 Spanner Graph 加速了我们的生成式 AI 路线图，作为在正确的数据基础上构建可能实现的最终证明：https://cloud.google.com/transform/shift-system-of-action-architecting-the-agentic-data-cloud-AI。

想要为您的 AI 应用注入强大动力吗？这从具备正确图功能、几乎无限扩展的数据库开始。了解 Spanner Graph 如何将数据转化为行动：https://cloud.google.com/products/spanner/graph，助力您的组织。

作者：Michael Menzel博士 • 阅读时间：4分钟

作者：Siddharth Dawara • 阅读时间：4分钟

The front door to AI in the workplace

In today’s retail environment, shoppers expect highly personalized product discovery experiences and conversational assistance that feels genuine, natural, and genuinely helpful. Today, successful product discovery is about understanding semantic meaning and the rich, connected relationships between products, categories, and guest intent. It is no longer just about keywords and basic browsing.

At Target, this work is handled by our Guest Product Confidence platform team. They are responsible for building the features that establish trust and guide purchasing decisions, such as ratings, reviews, and AI-driven digital shopping assistants. An exciting example of this is our Gift Finder chat agent ：https://www.target.com/gift-finder , which we launched during the 2025 holiday season online and in the Target app to help shoppers discover the perfect items through friendly, conversational dialogue.

To deliver real-time personalization and context-rich semantic responses like these at global scale, we identified a critical architectural need to move away from a fragmented data ecosystem toward a unified data platform. We needed a solution capable of supporting high-throughput transactional workloads, highly connected graph relationships, vector similarity search, and full-text keyword search all at once.

In this post, we’ll explore how we achieved all four with Spanner.

Previously, Target’s discovery data ecosystem relied on a combination of Elasticsearch clusters for search and inverted indexes, alongside separate NoSQL datastores for our transactional data. While functional, this fragmented architecture presented significant operational and technical challenges.

Disconnected context: Keeping separate search, vector, and transactional databases in perfect sync was a constant challenge. Siloed information led to missing context, disconnected attribute relationships, and inconsistent query results.

High operational overhead: Managing independent clusters, tuning search indexes, and handling complex, custom synchronization and aggregation logic required intensive manual intervention from our engineering teams.

Expansion bottlenecks: Expanding our retail data domains required adding new database collections, maintaining complex joins, and navigating weak transactional guarantees across our discovery and core transactional systems.

Siloed intelligence: We lacked the ability to query graph relationships, vector similarity, and keyword search indexes in a single transaction.

To build the next generation of AI-driven guest experiences, we needed to consolidate on one platform.

We evaluated multiple specialized technologies, including standalone vector databases and niche graph databases. However, adding more single-purpose databases would have only worsened our operational complexity and data synchronization pipelines.

We ultimately chose Spanner Graph ：https://docs.cloud.google.com/spanner/docs/graph/overview to build our enterprise ontology, which is a "graph-of-graphs" paradigm that allows us to construct a massive, generative AI-powered shopping graph.

By unifying our data, we bring semantic data, graph relationships, vector embeddings, and operational transactions under one roof. This establishes Spanner as our single authoritative source of truth for both transactional state and semantic intelligence.

Our high-level architecture now consists of three core pillars:

1. Enterprise augmentation This layer captures our enterprise retail catalog, aggregates relevant metadata from multiple backend sources, and utilizes generative AI for agentic data enrichment to dramatically improve the quality and depth of the product data we ingest.

2. Unified graph, vector, and search store Instead of shifting data across multiple databases, Spanner Graph stores our entity nodes, relationship edges, and vector embeddings in the same database engine. Spanner Graph natively supports multi-hop graph traversals, semantic vector similarity, and full-text keyword queries over our relational tables. Because this multi-model synergy is native, we get strict ACID transactions for absolute correctness across distributed workloads without the need for fragile external sync pipelines.

3. Orchestration and AI layer This layer powers our conversational guest interfaces, utilizing rich, structured context fed directly from Spanner Graph to ground our LLMs. It extracts highly specific product relationships to power tools like the Gift Finder ：https://www.target.com/gift-finder while governing responsible AI processes and evaluating generated outputs.

Transitioning critical search and discovery infrastructure that millions of guests rely on required a cautious, zero-downtime approach. We executed this migration in four structured phases.

Schema and ontology mapping: We defined the specific retail entities, such as products, categories, brands, and guest preferences, and their corresponding relationships within the Spanner Graph schema.

Data integration and parallel replay: We built mutation-based data integrations in a parallel pipeline. This allowed us to continuously replay live transactional updates, apply schema transformations, generate embeddings, and write them directly into Spanner Graph in real-time.

Canary deployment: We gradually shifted live read traffic to the new Spanner Graph-backed platform, validating query performance, semantic accuracy, and database stability under real retail workloads.

Cutover and cleanup: Once performance was thoroughly verified, we fully transitioned all search and discovery traffic to Spanner and deprecated our legacy Elasticsearch stack, entirely removing the maintenance burden of those clusters.

By building directly on Spanner Graph, we unlocked measurable technical and business outcomes:

The ultimate GraphRAG foundation: Traditional RAG relies on flat vector similarity, which often misses the structured associations between products, such as matching a toy with its compatible accessories or age-appropriateness. By combining deep graph traversals with semantic vector search in a unified GraphRAG architecture, we grounded our LLMs with highly precise context. This directly improved our recommendation relevancy, enhanced guest satisfaction, and boosted our Net Promoter Score.

Consolidated SQL + GQL interoperability: With Spanner Graph, our developers query structured relational catalog data and connected graph relationships in a single query using standard SQL and GQL (Graph Query Language). This eliminates the need for data duplication, latency, or complex ETL pipelines to bridge these paradigms.

Serverless scalability with zero growth ceiling: Spanner automatically handled massive, unpredictable traffic spikes during peak retail events like Black Friday and Cyber Monday. Spanner's built-in autoscaler dynamically adjusted computing capacity to handle burst traffic during high-intensity, limited-time promotional offers without sacrificing performance.

50% reduction in infrastructure maintenance: By consolidating our transactional NoSQL and search index databases into a single managed Google Cloud service, we eliminated the operational burden of maintaining separate database clusters. Our developers now spend 50% less time on database administration and infrastructure upkeep, allowing us to build and deploy new, customer-facing AI features much faster.

Migrating to Spanner Graph has accelerated our generative AI roadmap, serving as the ultimate proof of what is possible when you build on the right data foundation ：https://cloud.google.com/transform/shift-system-of-action-architecting-the-agentic-data-cloud-AI .

Want to supercharge your AI apps? It starts with databases with the right graph capabilities at virtually unlimited scale. Discover how Spanner Graph can turn data into action ：https://cloud.google.com/products/spanner/graph for your organization.

By Dr. Michael Menzel • 4-minute read

By Siddharth Dawara • 4-minute read