实验 2：数据分析和多模态分析洞见

1. 简介

在之前的实验中，您汇总了零散的运输日志，并追踪了前往纽约的货物应答器。不过，到达记录显示，该集装箱立即被重新安排路线，以避开关税检测。现在，您追踪到了里约热内卢港，这是一个拥有数千个集装箱的庞大港口。在数千个集装箱中找到正确的集装箱是一项艰巨的任务。

在本实验中，您将使用 BigQuery 的内置 AI 功能“读取”非结构化港口安全图像，并检测传感器数据中的热异常，所有操作均使用标准 SQL。然后，您将向量嵌入导出到 AlloyDB 并运行向量搜索，以将碎片化的遥测信号与缺失的容器相匹配。

您将执行的操作

• 使用 BigQuery AI 扫描港口安全图像，以识别被盗的集装箱
• 使用 BigQuery AI 检测到热异常，确认集装箱是被盗，而不是放错位置
• 生成向量嵌入并将其加载到 AlloyDB 中以进行实时搜索
• 使用 Vector Search 匹配碎片化的遥测信标信号，以定位被盗的集装箱
• 使用对话分析以自然语言探索调查数据

所需条件

• 网络浏览器，例如 Chrome
• 启用了结算功能的 Google Cloud 项目
• 基本熟悉 SQL 和 Google Cloud 控制台

本 Codelab 适合中级开发者。

本 Codelab 中创建的资源费用应低于 5 美元。

2. 准备工作

启动 Cloud Shell

您将使用 Google Cloud Shell 下载代码、运行设置脚本并部署应用。

1. 在新浏览器标签页中，打开 Cloud Shell：shell.cloud.google.com
2. 连接成功后，设置项目 ID 并确认环境：

gcloud config set project <<YOUR_PROJECT_ID>>
export PROJECT_ID=$(gcloud config get-value project)
export REGION=us-central1

您应会看到如下所示的消息：

Your active configuration is: [cloudshell-####]
Updated property [core/project]

克隆代码库

将 Codelab 代码库克隆到 Cloud Shell 环境：

cd ~/
git clone --filter=blob:none --no-checkout https://github.com/GoogleCloudPlatform/devrel-demos.git
cd ~/devrel-demos
git sparse-checkout init --cone
git sparse-checkout set codelabs/bigquery-alloydb-insights
git checkout main
cd codelabs/bigquery-alloydb-insights/

启用 API

在 Cloud Shell 中运行以下命令，以启用本实验所需的所有 API：

gcloud services enable \
  aiplatform.googleapis.com \
  bigquery.googleapis.com \
  bigqueryconnection.googleapis.com \
  alloydb.googleapis.com

成功执行后，您应该会看到类似如下内容的消息：

Operation "operations/..." finished successfully.

3. 设置环境

在分析图片和遥测数据之前，您需要为此实验设置基础架构。您将运行两个脚本：一个在后台启动 AlloyDB 配置，另一个创建您需要的所有 BigQuery 资源。

第 1 步：开始 AlloyDB 部署（后台）

AlloyDB 集群预配大约需要 10 分钟，因此您需要先启动它，让它在后台运行，同时您继续完成 BigQuery 部分的操作。该脚本会自动将您的有效项目设置记录到本地 .env 文件中，这样即使 Cloud Shell 终端关闭或重启，您的配置也会保存。

chmod +x scripts/setup_alloydb.sh
nohup ./scripts/setup_alloydb.sh > /dev/null 2>&1 &
echo "AlloyDB deployment started in background (PID: $!)"

第 2 步：运行设置脚本

此脚本会创建 BigQuery 数据集、Cloud 资源连接、IAM 授权、GCS 存储分区，并加载您将在本实验中分析的所有传感器数据。它还会读取并验证保存在 .env 文件中的环境变量。

chmod +x scripts/setup_lab.sh
./scripts/setup_lab.sh

该脚本大约需要一分钟才能运行完毕。运行完毕后，您会看到它创建的所有内容的摘要。

📝 有关环境重置的注意事项：如果您在此实验期间的任何时间点遇到 Cloud Shell 会话超时或重启的情况，都可以通过运行以下命令立即恢复终端变量：

source scripts/setenv.sh

第 3 步：启动 Cloud Shell 编辑器

您目前一直在使用 Cloud Shell 终端。现在，切换到完整的 Cloud Shell 编辑器，它提供了一个类似 VS Code 的工作区，并集成了 BigQuery 支持。

1. 在屏幕底部的 Cloud Shell 终端窗格中，点击打开编辑器按钮，启动 Cloud Shell 编辑器工作区。

第 4 步：安装 Data Agent Kit 扩展程序

Google Cloud Data Agent Kit 扩展程序可直接在编辑器中与 Google Cloud 数据服务深度集成，让您无需切换上下文即可与 BigQuery、AlloyDB、Cloud Storage 等服务进行交互。

1. 在 Cloud Shell 编辑器中，点击屏幕最左侧活动栏中的扩展程序图标（看起来像四个正方形）。
2. 在“扩展程序”窗格顶部的搜索栏中，输入 googlecloudtools.datacloud。
3. 找到由 Google Cloud 发布的名为 Google Cloud Data Agent Kit 的扩展程序。
4. 点击 Install 按钮。
5. 系统会显示提示，询问“您是否信任发布者 ‘googlecloudtools’ 及其扩展程序？”。点击信任发布者并安装以继续。

第 5 步：进行身份验证并配置扩展程序

安装完成后，将扩展程序连接到您的 Google Cloud 项目。

1. 系统应会自动打开一个名为“Google Cloud Data Agent Kit Onboarding”（Google Cloud Data Agent Kit 初始配置）的初始配置页面。点击登录 Google Cloud。按照浏览器提示操作，以允许访问。
2. 系统会显示“设置正在进行中”的模态框。扩展程序会自动检查所需的依赖项，例如 Google Cloud CLI。
3. 在配置摘要部分中，找到项目字段。点击下拉菜单，然后选择您的 Google Cloud 项目。将您的区域设置为 us-central1。
4. 等待设置检查完成。看到“设置完成！”后，点击配置 MCP 服务器。

5. 在“MCP 配置”下选择 BigQuery 和 AlloyDB，然后点击开始。

第 6 步：探索配置选项

设置完成后，您会进入“Google Cloud Data Agent Kit 使用入门”信息中心。

1. 在“设置和配置”下，点击开始。
2. 系统随即会打开数据代理配置面板。浏览以下标签页：
   • 项目和区域：验证所选的项目 ID，并检查是否已启用必需的 API（Cloud Storage API、BigQuery API、Catalog API 和 AlloyDB API）。
   • BigQuery：配置 BigQuery 查询的默认位置。使用 us-central1 区域。
   • 配置 MCP 服务器：查看已启用的 MCP 服务器（BigQuery、Notebooks、AlloyDB 等），这些服务器可让 AI 智能体安全地与您的数据互动。
   • 技能：探索预构建技能，这些技能可为智能体提供专门的功能来处理复杂的数据任务。

第 7 步：使用 BigQuery 进行验证

通过针对公共数据集运行快速查询来确认一切正常。

1. 在左侧的“Data Agent Kit”窗格中，展开 BigQuery 部分，然后点击新查询以打开新的查询编辑器标签页。
2. 按 Ctrl+S (Windows/Linux) 或 Cmd+S (macOS) 保存文件，并将其命名为 bigquery。此标签页将用于所有 BigQuery 操作。
3. 在 bigquery.sql 标签页处于活动状态时，点击查询设置，选择 BigQuery 作为数据源，然后点击保存。

标签页专用设置：Data Agent Kit 扩展程序会按标签页保存连接配置。这意味着，您可以同时打开 bigquery.sql 和其他 SQL 标签页，并且在它们之间切换时会自动切换活跃的数据库连接。

3. 针对公共数据集运行以下查询：

SELECT
  term,
  MIN(rank) AS peak_rank,
  ROUND(AVG(score)) AS avg_score
FROM `bigquery-public-data.google_trends.top_terms`
WHERE refresh_date = DATE_SUB(CURRENT_DATE(), INTERVAL 2 DAY)
GROUP BY term
ORDER BY peak_rank ASC
LIMIT 10;

4. 您应该会看到过去几天内 Google 搜索中排名前 10 的热门搜索字词。如果显示结果，则表示扩展程序已连接并可正常使用。

现在，尝试针对设置脚本刚刚创建的实验数据运行查询。将现有查询替换为以下查询：

SELECT * FROM `lost_cargo_dataset.telemetry_data` LIMIT 5;

您应该会看到包含 shipment_id 和 telemetry_string 列的遥测日志条目。这是您将在整个实验过程中分析的数据。

运行查询。在本实验中，您将把 SQL 粘贴到 .sql 编辑器标签页中。如果您突出显示某个特定语句并点击运行查询，则系统只会执行该语句。如果没有突出显示任何内容，则点击“运行”会执行文件中的所有内容。简单的工作流程：每次到达新的查询步骤时，请将之前的内容替换为新的 SQL，以便文件仅包含您要运行的查询。

本部分总结：您在后台启动了 AlloyDB 部署，运行了设置脚本，并使用 Data Agent Kit 扩展程序配置了 Cloud Shell 编辑器。

4. 扫描监控录像

调查团队已从里约热内卢港口恢复了安全监控录像，其中显示了多排集装箱。从实验 1 中，您知道目标集装箱是红色的。现在，您需要准确识别出哪个红色集装箱是目标集装箱。

您将创建一个对象表，让 BigQuery 能够“看到”Cloud Storage 中的安全图片，然后使用 AI.GENERATE 函数提示 Gemini 从每张图片中提取结构化数据。

继续使用编辑器！请务必继续使用 Data Agent Kit 扩展程序直接在 Cloud Shell 编辑器工作区中运行本实验中的所有 SQL 查询。

第 1 步：创建对象表

对象表是一种特殊的 BigQuery 表，可充当 Cloud Storage 中存储的非结构化文件（图片、PDF、音频）的索引。它不会将文件复制到 BigQuery 中，而是创建一个可查询的引用，以便 AI 函数能够“看到”这些文件。

在编辑器中的 bigquery.sql 标签页中，运行以下语句以创建指向项目存储分区中端口安全图片的 Object Table：

SET @@location = 'us-central1';

EXECUTE IMMEDIATE CONCAT("""
  CREATE OR REPLACE EXTERNAL TABLE `lost_cargo_dataset.port_security_images`
  WITH CONNECTION `us-central1.lost_cargo_conn`
  OPTIONS (
    object_metadata = 'SIMPLE',
    uris = ['gs://""", @@project_id, """-lab2/images/*']
  );
""");

快速了解 BigQuery 现在可以识别哪些内容：

SELECT uri, content_type FROM `lost_cargo_dataset.port_security_images` LIMIT 5;

每行代表 Cloud Storage 中的一个图片文件。现在，BigQuery 可以直接将这些图片传递给 AI 模型。

第 2 步：分析安全图片

现在，使用 BigQuery 的 AI.GENERATE 函数来分析每张安全图像。以下单个 SQL 查询会提示 Gemini 检查每张图像并返回结构化数据：

SELECT
  uri,
  AI.GENERATE(
    (
      'Examine this port security image. Identify any shipping container IDs visible on the container and provide a one-word color of the container.',
      ref
    ),
    output_schema => 'detected_container_id STRING, color STRING'
  ).* EXCEPT (full_response, status)
FROM `lost_cargo_dataset.port_security_images`;

SQL 中的结构化输出：请注意 output_schema => 'detected_container_id STRING, color STRING' 参数。这会告知 Gemini 模型返回 BigQuery 可原生转换为类型化列的结构化 JSON，这意味着无需进行后处理。

第 3 步：确定目标容器

检查结果。找到 color 列显示为红色（或某种红色变体）的行。记下 detected_container_id。这就是您的目标：MV-CAPYBARA-003。

🔍 容器线索已解锁：Gemini 模型已成功分析安全图片并提取容器的元数据。您已解锁目标 ID：MV-CAPYBARA-003。请妥善保管此 ID，以便我们搜索其路线！

第 4 步：验证视觉匹配

如需在不离开编辑器的情况下查看经过分析的实际图片，请执行以下操作：

1. 点击左侧“Data Agent Kit”窗格中的 Cloud Storage。
2. 展开相应存储分区 (YOUR_PROJECT_ID-lab2/images/)，然后点击与红色容器对应的图片文件，以便直接在编辑器中查看该文件。

本部分总结：您创建了一个对象表，以便让 BigQuery 访问港口安全图片，然后使用 AI.GENERATE 从每张图片中提取结构化容器数据。红色容器已被识别为 MV-CAPYBARA-003。

5. 确认盗窃

您已确定丢失的集装箱为 MV-CAPYBARA-003，但它是被盗还是只是放错了地方？清单日志显示，此特定集装箱停放在环境传感器 SENS-99 旁边。如果窃贼在搬走集装箱之前故意停用了其自带的制冷装置，SENS-99 可能会记录到突然的热排气峰值。

我们来使用异常检测来证明容器已被篡改。

1. 首先，探索历史基准。以下是 SENS-99 在过去几小时内的正常读数：

SELECT * FROM `lost_cargo_dataset.thermal_history`
ORDER BY reading_time DESC
LIMIT 50;

请注意，温度在 75-78°F 左右的小范围内波动。这是正常情况。

2. 现在，我们来看看同一传感器当前批次的读数：

SELECT * FROM `lost_cargo_dataset.thermal_current`
ORDER BY thermal_reading DESC
LIMIT 50;

看到顶部附近的 148.4°F 读数了吗？其他一切看起来正常。这种峰值可能表明冷藏设备出现故障或有人故意篡改。让我们来一探究竟。

3. 运行异常检测。BigQuery 的 AI.DETECT_ANOMALIES 使用预训练的 TimesFM 基础模型来分析时间序列模式并自动标记离群值，无需进行模型训练：

SELECT *
FROM AI.DETECT_ANOMALIES(
  TABLE `lost_cargo_dataset.thermal_history`,
  TABLE `lost_cargo_dataset.thermal_current`,
  data_col => 'thermal_reading',
  timestamp_col => 'reading_time',
  id_cols => ['sensor_id']
)
WHERE is_anomaly = TRUE;

4. 检查结果。148.4°F 的读数应标记为异常值，且异常概率较高，这表明容器区域附近发生了异常情况。

🔍 篡改迹象已解锁：TimesFM 模型将 148.4°F 的温度飙升标记为高度异常的读数，证实了集装箱的制冷装置已被停用。在设置搜索后端时，请务必留意此主动篡改指示器！

本部分总结：您使用了 BigQuery 的 AI.DETECT_ANOMALIES 函数来利用预训练的 TimesFM 模型。只需运行一个 SQL 查询，您就可以自动识别出离群值并隔离异常篡改事件，而无需编写任何复杂的机器学习代码或从头开始训练模型。

6. 准备跟踪系统

该集装箱已被证实被盗，目前已不在里约热内卢。车队中的每个集装箱都会广播遥测信标信号：传感器读数、GPS 片段和状态日志。如果被盗容器的信标仍在传输，您可以将其与已知签名进行匹配，以找到该容器。

BigQuery 非常擅长您目前所做的分析工作，但实时定位集装箱需要低延迟的运营查询。AlloyDB 是一种与 PostgreSQL 兼容的全托管式数据库，正是为此而构建的：矢量搜索查询速度足够快，可用于实时跟踪系统。您将把遥测嵌入内容加载到 AlloyDB 中，并使用它来匹配信标信号。

您之前在后台启动的 AlloyDB 集群现在应该已准备就绪。让我们直接在编辑器中进行配置。

第 1 步：从编辑器连接到 AlloyDB

您无需切换到 Cloud 控制台，而是可以直接使用 Data Agent Kit 扩展程序连接到 AlloyDB。

1. 在左侧的“Data Agent Kit”窗格中的 BigQuery 部分下，点击新查询以打开新的查询编辑器标签页。
2. 按 Ctrl+S (Windows/Linux) 或 Cmd+S (macOS) 保存文件，并将其命名为 alloydb。此标签页将用于所有 AlloyDB 查询。
3. 点击齿轮图标，打开查询设置模态。

4. 在查询设置模态框中，选择数据源下的数据库。
5. 在数据库下，选择 AlloyDB。
6. 填写资源选择详细信息：
   • 项目 ID：输入您的 Google Cloud 项目 ID。
   • 集群：选择 lost-cargo-cluster。
   • 实例：选择 lost-cargo-instance。
   • 数据库：选择 postgres。
7. 点击保存。

开发者提示：您现在打开了两个查询标签页：bigquery.sql（用于 BigQuery 查询）和 alloydb.sql（用于 AlloyDB 查询）。每个标签页都会保留自己的数据源配置，方便您在它们之间轻松切换。

第 2 步：启用向量扩展程序并创建表

现在您已连接到 AlloyDB，接下来需要启用必要的 AI 扩展程序，并创建将接收嵌入式遥测数据的表。

1. 在活跃的 .sql 标签页中，粘贴以下命令以启用所需的扩展程序：

CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS google_ml_integration CASCADE;

2. 突出显示文本，然后点击编辑器右上角的运行查询按钮（播放图标）。
3. 查看屏幕底部的查询结果终端面板。该面板应显示 Statement executed successfully。

4. 接下来，将编辑器中的文本替换为以下语句，以创建遥测数据表：

CREATE TABLE IF NOT EXISTS vessel_telemetry (
    entry_id SERIAL PRIMARY KEY,
    shipment_id VARCHAR(50),
    telemetry_string TEXT,
    embedding_vector vector(768)
);

5. 运行此查询，就像运行上一个查询一样。确认它在底部面板中成功执行。

vector(768) 类型来自您刚刚启用的 pgvector 扩展程序。768 维与 Google 的 text-embedding-005 模型的输出相匹配，您将在 BigQuery 中使用该模型生成嵌入。

本部分总结：您已直接从 Cloud Shell 编辑器连接到 AlloyDB，启用了 pgvector 和 google_ml_integration 扩展程序，并创建了目标表。AlloyDB 现已准备好作为实时遥测匹配的运营后端。

7. 构建搜索索引

现在，您需要将遥测数据导入 AlloyDB，以便支持实时信标匹配。原始遥测日志杂乱无章且长度不一，不适合进行相似性搜索。您将使用 BigQuery 的 AI 函数通过 Gemini 总结每个日志，并将每个摘要转换为 768 维向量嵌入。然后，您会将丰富的数据导出到 Cloud Storage 并将其导入 AlloyDB。

什么是反向 ETL？传统 ETL 会将原始数据提取到数据仓库中以进行分析。反向 ETL 则相反：它会将经过处理和丰富的数据推送到仓库之外并推送到运营系统中。在此示例中，BigQuery 会生成嵌入内容（分析工作负载），然后您将其导出到 Cloud Storage 并导入到 AlloyDB 中（低延迟矢量搜索的运营工作负载）。

第 1 步：在 BigQuery 中生成嵌入

将编辑器标签页切换回 bigquery.sql（该标签页仍连接到 BigQuery）。

现在，运行以下查询，使用 Gemini 总结每个遥测日志并生成向量嵌入：

CREATE OR REPLACE TABLE `lost_cargo_dataset.telemetry_embeddings_export` AS
WITH summarized_telemetry AS (
  SELECT
    shipment_id,
    telemetry_string,
    AI.GENERATE(
      CONCAT('Summarize this telemetry log for vector search: ', telemetry_string)
    ).result AS summary
  FROM `lost_cargo_dataset.telemetry_data`
),
telemetry_embeddings AS (
  SELECT
    shipment_id,
    telemetry_string,
    AI.EMBED(summary, endpoint => 'text-embedding-005').result AS embedding
  FROM summarized_telemetry
)
SELECT
  shipment_id,
  telemetry_string,
  TO_JSON_STRING(embedding) AS embedding_vector
FROM telemetry_embeddings;

什么是 AI.EMBED？AI.EMBED 函数会将文本转换为高维向量嵌入。在语义上相似的文本会生成在数学上彼此接近的向量。

语义相似性：关键字搜索会查找完全匹配的字词（例如，“冷却”只会匹配“冷却”）。语义相似性会理解字词背后的含义。例如，“冷却装置离线”和“制冷系统故障”这两个短语没有一个相同的字词，但表示的却是完全相同的概念。这样一来，即使碎片化的信标信号与存储的遥测日志使用了不同的措辞，我们也能将它们匹配起来。

第 2 步：预览丰富的数据

在导出之前，请先查看您创建的内容。此查询显示了货件 ID 以及每个摘要和嵌入的前 80 个字符：

SELECT
  shipment_id,
  SUBSTR(telemetry_string, 1, 80) AS telemetry_preview,
  SUBSTR(embedding_vector, 1, 80) AS embedding_preview
FROM `lost_cargo_dataset.telemetry_embeddings_export`
LIMIT 5;

现在，每行都包含一个货件 ID、原始遥测日志和一个 768 维嵌入向量。这是您将推送到 AlloyDB 中的数据。

第 3 步：将嵌入内容导出到 Cloud Storage

使用 BigQuery 的 EXPORT DATA 语句将嵌入表以 CSV 文件形式写入实验的 GCS 存储分区。

EXECUTE IMMEDIATE CONCAT("""
  EXPORT DATA OPTIONS (
    uri = 'gs://""", @@project_id, """-lab2/data/embeddings_export/*.csv',
    format = 'CSV',
    overwrite = true,
    header = false
  ) AS
  SELECT
    shipment_id,
    telemetry_string,
    embedding_vector
  FROM `lost_cargo_dataset.telemetry_embeddings_export`;
""");

第 4 步：从 Cloud Storage 导入到 AlloyDB

1. 在 Cloud Shell 编辑器中，点击屏幕底部的终端标签页，以打开终端会话。
2. 运行以下命令，加载您的环境并将 CSV 文件直接导入到 AlloyDB 中的 vessel_telemetry 表中：

source devrel-demos/codelabs/bigquery-alloydb-insights/scripts/setenv.sh

gcloud alloydb clusters import lost-cargo-cluster \
  --region=$REGION \
  --gcs-uri="gs://${PROJECT_ID}-lab2/data/embeddings_export/000000000000.csv" \
  --database=postgres \
  --user=postgres \
  --table=vessel_telemetry \
  --columns=shipment_id,telemetry_string,embedding_vector \
  --csv

部分总结：您使用 BigQuery 的 AI 函数来总结和嵌入遥测数据，将结果导出到 Cloud Storage 作为 CSV，然后使用 gcloud 将其导入到 AlloyDB 中。现在，运营跟踪数据库已加载完毕，可以开始使用了。

8. 匹配 Beacon 信号

悉尼附近的一支现场团队截获了一个碎片化的遥测信标信号。部分日志内容如下：

“制冷装置已离线。手动替换。”

如果这是从被盗容器中获取的信号，即使信号不完整，AlloyDB 的向量搜索也应该能够匹配。这正是 AlloyDB 旨在处理的实时运营查询。

第 1 步：验证导入的数据

将编辑器标签页切换回 alloydb.sql（仍连接到 AlloyDB）。

运行以下命令，确认遥测数据已成功加载：

SELECT shipment_id, LEFT(telemetry_string, 80) AS telemetry_preview
FROM vessel_telemetry
LIMIT 10;

您应该会看到包含 shipment_id 值和遥测文本的行。这些是车队的遥测签名，现在已准备好进行实时匹配。

第 2 步：搜索丢失的容器

现在，使用 AlloyDB 的 google_ml_integration 扩展程序，通过截获的信号片段搜索匹配项：

SELECT
    shipment_id,
    telemetry_string,
    1 - (embedding_vector <=> embedding('text-embedding-005', 'Refrigeration unit offline. Manual override.')::vector) AS search_relevance_score
FROM vessel_telemetry
ORDER BY embedding_vector <=> embedding('text-embedding-005', 'Refrigeration unit offline. Manual override.')::vector
LIMIT 5;

AlloyDB 的 google_ml_integration 扩展程序提供的 embedding() 函数可直接从 SQL 调用 Agent Platform，以生成内嵌的向量嵌入。<=> 运算符用于计算两个向量之间的余弦距离（越接近 0，两个向量就越相同）。我们从 1 中减去该值，以将结果表示为相关性得分，得分越高越好。

同一模型，两个数据库。请注意，AlloyDB 的 embedding() 函数使用与 BigQuery 的 AI.EMBED 用于生成存储向量的相同 text-embedding-005 模型。由于两者都调用相同的底层 Agent Platform 嵌入模型，因此嵌入向量可以直接比较，这意味着在 AlloyDB 中生成的搜索向量在数学上与在 BigQuery 中生成的向量兼容。

第 3 步：确认匹配

检查结果。排名靠前的结果应为 MV-CAPYBARA-003，且相关性得分最高。

这与您在整个调查过程中一直跟踪的容器相同：

• 📷 监控录像显示，它在夜间离开了里约热内卢港。
• 🌡️ 热异常检测确认其制冷装置被故意停用。
• 📡 信标信号匹配刚刚在悉尼附近精确定位了其遥测签名。

三条独立的证据线索。三种不同的 Google Cloud AI 功能。一个被盗的容器。

🎯 结案：MV-CAPYBARA-003 已在悉尼附近找到！

🔍 位置线索已解锁：AlloyDB 向量搜索以高置信度解析了碎片化的信标信号。您已解锁集装箱的位置：它位于悉尼附近的码头！

本部分总结：您使用了 AlloyDB 的内置 AI 集成功能，通过单个 SQL 查询生成了搜索嵌入，并执行了余弦相似度搜索。信标匹配确认了被盗集装箱的位置，调查结束。

9. 探索证据

现在，您已通过多模态图片分析和向量搜索确定了容器，接下来可以直接在编辑器中使用对话式分析，通过自然语言探索调查数据，而无需编写任何 SQL。

第 1 步：在 Knowledge Catalog 中找到数据

数据代理套件包含通用搜索功能，可让您在整个 Google Cloud 环境中查找和探索数据资产。

1. 在左侧的“Data Agent Kit”面板中，展开 Catalog 部分。
2. 点击通用搜索。
3. 在搜索栏中，输入 telemetry_data。
4. 在搜索结果中，点击 lost_cargo_dataset 下方的 telemetry_data 表格。

第 2 步：启动 Conversational Analytics

点击搜索结果会打开一个数据查看器标签页，您可以在其中预览原始数据、查看架构和检查数据质量。

1. 左侧窗格中会显示您的 BigQuery 数据集和表。点击聊天按钮，打开新的聊天窗口。

第 3 步：使用自然语言提问

系统会打开一个新的“欢迎使用对话式分析！”聊天标签页。该代理已了解您表格的架构和内容。

1. 在聊天窗口中，输入：“Show me the telemetry status and log for the Capybara shipment.”
2. 按 Enter 键。

该代理会将您的问题转换为 BigQuery SQL，执行查询，并返回结果，包括数据表和总结结果的数据洞见。您可以根据问题的复杂程度，在思考（更深入的分析，速度较慢）模式和快速（更快地回答）模式之间切换。由于这些回答是由 AI 生成的，因此您的结果可能与下面的屏幕截图略有不同。

第 4 步：提出后续问题

智能体可以记住对话的上下文。尝试提出后续问题：

• “遥测数据中有多少个唯一货件？”
• “舰队中有多少其他货件目前处于‘严重’状态？”

什么是对话式分析？对话式分析会将自然语言转换为可执行的 SQL 并总结结果，让调查人员和分析师（而不仅仅是 SQL 专家）也能进行数据分析。

本部分总结：您使用了 Knowledge Catalog 的通用搜索功能来查找数据集，并启动了对话式分析功能，以便使用自然语言查询调查数据。AI 智能体将您的问题翻译成 SQL，并提供了与您的发现相符的分析洞见。

10. 清理

为避免系统向您的 Google Cloud 账号持续收取费用，请删除您在本实验中创建的资源。您可以在 Cloud Shell 编辑器（您一直在使用 Data Agent Kit）内的集成式终端中运行以下命令来清理您的环境。

首先，加载环境变量：

source scripts/setenv.sh

1. 删除 BigQuery 资源（仅当您不继续学习实验 3 时）：

如果您计划继续学习实验 3，请跳过此步骤！实验 3 使用相同的 BigQuery 数据集和连接进行属性图分析。

如需删除 BigQuery 数据集和连接，请执行以下操作：

# Drop the dataset
bq rm -r -f $PROJECT_ID:lost_cargo_dataset

# Delete the connections
bq rm --connection --location=us-central1 $PROJECT_ID.us-central1.lost_cargo_conn
bq rm --connection --location=us-central1 $PROJECT_ID.us-central1.lost_cargo_alloydb_conn

2. 删除 Cloud Storage 存储分区：

gcloud storage rm --recursive gs://${PROJECT_ID}-lab2

3. 删除 AlloyDB 实例和集群：

实验 3 中未使用 AlloyDB，因此现在可以安全地将其拆除。

gcloud alloydb instances delete lost-cargo-instance \
  --region=$REGION \
  --cluster=lost-cargo-cluster \
  --quiet

gcloud alloydb clusters delete lost-cargo-cluster \
  --region=$REGION \
  --force \
  --quiet

4. 删除本地环境设置：

最后，从工作区中清理本地环境设置文件：

rm -f .env

11. 恭喜！

您已成功完成实验 2：数据分析和多模态数据洞见！您从一个装满数千个集装箱的港口开始追踪，最终确认了盗窃行为并确定了确切位置。

您的成就

1. 扫描了视频片段：您使用 BigQuery 的 AI.GENERATE 分析了港口安全图像，并识别出深红色的集装箱 MV-CAPYBARA-003。
2. 确认盗窃行为：您探索了热传感器数据，发现了一个可疑的 148.4°F 峰值，并使用 AI.DETECT_ANOMALIES 证明这是蓄意篡改。
3. 准备了跟踪系统：您已配置 AlloyDB，并使用 pgvector 和 google_ml_integration 实现实时信标匹配。
4. 构建了搜索索引：您在 BigQuery 中使用 AI.GENERATE 和 AI.EMBED 创建了嵌入，然后将其导出到 Cloud Storage 并导入到 AlloyDB 中。
5. 匹配了信标信号：您使用 AlloyDB 的向量搜索功能匹配了碎片化的遥测信号，从而在悉尼附近找到了被盗的集装箱。
6. 探索证据：您直接在编辑器中使用对话式分析，通过自然语言查询调查数据。

后续步骤

您已经找到了容器的位置。现在，您需要找出容器的幕后人员。

在实验 3：数据使用和 Agentic Workflows中，您将构建物流网络的属性图，以映射壳公司之间的关系；使用 Conversational Analytics 与该图进行对话；并搜索 Knowledge Catalog，以找到恢复容器所需的安全清关代码。