BigQuery Graph ile Yapay Zeka Aracısı Kararlarını İzleme

1. Giriş

BigQuery Graph, BigQuery Etkileşimli Analytics ve BigQuery Agent Analytics SDK şu anda Google Cloud'da önizleme aşamasındadır. BigQuery Agent Analytics eklentisi genel kullanıma sunuldu. Bu codelab'deki örneklerde sentetik veriler kullanılır.

Özerk yapay zeka aracıları daha fazla operasyonel sorumluluk üstlendikçe (kredi başvurularını değerlendirme, pazarlama bütçelerini yönetme, erişim isteklerini onaylama) kuruluşlar kararlarını denetleyebilmeli ve açıklayabilmelidir. Bir ajanın kararının tam bağlamını, dikkate alınan alternatifleri ve nihai gerekçesini yeniden oluşturmak; uyumluluk, risk yönetimi ve operasyonel güven için önemlidir.

Bu codelab'de, harici bir grafik veritabanı veya ETL işlem hattı olmadan, ham aracı etkinlik günlüklerini planlı olarak Aracı Bağlam Grafiği'ne (BigQuery Graph'te sorgulanabilir bir aracı kararları grafiği) dönüştürmek için BigQuery Agent Analytics SDK'sı kullanılır.

Anahtar terimler

  • Agent Decision Trace (Temsilci Karar İzleme): Temsilcinin kendi çalıştırmalarından alınan karar düzeyindeki kanıtlar (değerlendirdiği seçenekler, dokunduğu veriler ve sonuç).
  • Temsilci Context Graph: Bu izlerin somutlaştırıldığı BigQuery Graph'taki yazılmış, sorgulanabilir grafik. Bu, sektör bağlam grafiği kavramının (hem üretilen hem de tüketilen, zamanla bağlantılı, kalıcı karar bağlamı katmanı) aracı kapsamlı örneğidir. "Aracı" niteleyicisi, kapsamını kuruluş genelinde bir bağlam katmanı yerine kendi aracınızın çalıştırmalarıyla sınırlar.

Bu codelab'de bqaa context-graph, agent_events öğenizden aracının karar izlerini ayıklar ve bunları GQL ile sorgulayabileceğiniz bir Aracı Bağlam Grafiği olarak oluşturur. Bu işlem, bağlam grafiklerinin karar izlerinden oluşturulduğu sektördeki kalıba uygundur.

Ajan Bağlam Grafiği iş akışı: Bir ADK aracısının etkinlikleri, BigQuery Agent Analytics eklentisi aracılığıyla agent_events tablosuna akar. bqaa context-graph, aracının karar izlerini yapılandırılmış bir Ajan Bağlam Grafiği'ne çıkarır ve siz de bunu GQL ve Conversational Analytics ile sorgularsınız.

Ne oluşturacaksınız?

  • Genel bir aracı karar akışını modelleyen bir Aracı Bağlam Grafiği (BigQuery Graph ile): Bir istek gelir, aracı seçenekleri değerlendirir ve bir sonuç belirlenir.
  • Sentetik etkinlik korpusu içeren doldurulmuş bir agent_events tablosu.
  • Bu etkinliklerden grafiği dolduran çalışan bir bqaa context-graph çalıştırması.
  • Tek bir kararı uçtan uca izleyen, denetim tarzında bir GQL sorgusu.

Neler öğreneceksiniz?

  • BigQuery Agent Analytics eklentisinin agent_events yazma şekli.
  • Bağlam grafiğinin yalnızca iki bildirimsel öğe (tablo DDL'si ve CREATE PROPERTY GRAPH şeması) ile nasıl tanımlandığı.
  • BigQuery grafiğine karşı bqaa context-graph nasıl çalıştırılır?
  • GQL kullanarak grafiği sorgulama
  • SDK'nın kurumsal dağıtımlar için desteklediği üretim düzeyindeki özellikler.

İhtiyacınız olanlar

  • Faturalandırmanın etkin olduğu bir Google Cloud projesi.
  • İlgili projede Sahip veya Düzenleyici rolüne sahip olmanız gerekir. BigQuery veri kümesi oluşturup IAM izni vereceksiniz.
  • gcloud KSA'nın yüklü ve kimliği doğrulanmış olması veya Cloud Shell'e erişim.
  • Python 3.10 veya sonraki sürümler.
  • BigQuery SQL hakkında bilgi sahibi olmak GQL bilgisi gerekmez.

Bu kod laboratuvarı, BigQuery Graph'ı yeni kullanmaya başlayanlar da dahil olmak üzere her seviyeden geliştiriciye yöneliktir.

Bu codelab'de oluşturulan kaynakların maliyeti çok düşüktür ve son adımda her şey kaldırılır. Böylece boşta kalan bir veri kümesi için faturalandırılmazsınız.

Tahmini süre: Bu codelab'in tamamlanması yaklaşık 35 dakika sürer.

2. Başlamadan önce

Proje ve bölge seçin

Cloud Shell'i veya yerel bir terminali açın:

export PROJECT_ID="your-project-id"
export REGION="us-central1"
export DATASET="agent_analytics_demo"
gcloud config set project "$PROJECT_ID"

Tek DATASET değişkeni hem ham agent_events tablosunu hem de oluşturulmuş grafik tablolarını içerir. Tek bir veri kümesi kullanmak codelab'i basit tutar. Üretim dağıtımlarında genellikle etkinlikler ve grafikler ayrı veri kümelerine bölünür. Böylece IAM, veri kümesi bazında dar kapsamlı olarak verilebilir.

Gerekli API'leri etkinleştirme

Bu codelab'in kullandığı API'leri etkinleştirmek için aşağıdaki komutu çalıştırın:

gcloud services enable \
    bigquery.googleapis.com \
    aiplatform.googleapis.com \
    --project="$PROJECT_ID"

SDK'nın varsayılan ayıklama yolu, BigQuery'nin AI.GENERATE işlevini çağırdığı için aiplatform.googleapis.com API'si gereklidir. Daha sonra --extraction-mode=compiled-only ile deterministik ayıklamaya geçerseniz bu API artık gerekli değildir.

BigQuery veri kümesini oluşturma

Hem ham agent_events tablosunu hem de somutlaştırılmış grafik tablolarını barındıracak veri kümesini oluşturun:

bq --location=US mk --dataset "$PROJECT_ID:$DATASET"

İşlemin başarılı olduğunu belirten bir mesaj görmeniz gerekir:

Dataset 'your-project-id:agent_analytics_demo' successfully created.

Veri kümesi zaten varsa komut hatasız bir şekilde hata verir. Yerinde bırakın.

3. SDK'yı yükleme

Python sanal ortamı oluşturun ve PyPI'den SDK'yı yükleyin:

python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install bigquery-agent-analytics

bigquery-agent-analytics paketi, BigQuery istemci kitaplığını getirir. Bu nedenle, tüm kod laboratuvarı için yapmanız gereken tek yükleme işlemidir.

Yüklemeyi doğrulayın:

bqaa context-graph --help | head -8

CLI banner'ını görürsünüz.

Kimliği doğrula

İş istasyonunda çalışıyorsanız:

gcloud auth login
gcloud auth application-default login

Cloud Shell kullanıcıları bu adımı atlayabilir. Kimlik bilgileri zaten yapılandırılmıştır.

4. Codelab çıktılarını alma

Codelab için kullanıma hazır yalnızca iki öğe gerekir: tablo DDL'si (fiziksel grafik tabloları) ve özellik grafiği şeması (CREATE PROPERTY GRAPH). Bunları kendiniz oluşturmazsınız. Codelab'de bu öğeler olduğu gibi kullanılır ve öğeler klasöründeki README dosyasında, bu öğelerin kendi karar alanınıza nasıl uyarlanacağı açıklanır.

Mülk grafiği şeması, grafiğin neleri içerdiğiyle ilgili tek doğruluk kaynağıdır. Bu sözleşmeyi BigQuery'ye bir kez uygularsınız. Bundan sonra dağıtılan grafiğin kendisi sözleşme olur. Gerçekleştirme yaptığınızda bqaa context-graph, çıkarılacak öğeleri ve ilişkileri belirlemek ve bunları nereye yazacağını bulmak için grafiğin tanımını BigQuery'nin INFORMATION_SCHEMA.PROPERTY_GRAPHS'sinden (başvurduğu tabloların şemalarıyla birlikte) geri okur. Bu nedenle, gerçekleştiriciye hiçbir zaman SQL dosyası iletilmez.

Bu codelab bağımsızdır. Bu nedenle indirmeniz gereken bir şey yoktur. Aşağıdaki komut, bağlam grafiği DDL'sini bir çalışma dizinine yazar. İçeriği, examples/context_graph/codelab/ içinde gönderilen yapılarla aynıdır.

Çalışma dizinini oluşturun:

mkdir -p ~/context-graph-codelab
cd ~/context-graph-codelab

Bağlam grafiği DDL'sini yazın (context_graph_ddl.sql). ${PROJECT_ID} / ${DATASET} işaretçileri, dosyayı sonraki adımda uyguladığınızda doldurulur.

cat > context_graph_ddl.sql <<'SQL'

-- Node and edge table DDL for the context-graph codelab.
--
-- `bqaa context-graph` writes into these tables on every run.
-- `session_id` and `extracted_at` are SDK metadata columns that
-- `bqaa context-graph` fills automatically; they are required on
-- every table behind the graph.
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.decision_request` (
  request_id STRING, request_text STRING, requested_at TIMESTAMP,
  session_id STRING, extracted_at TIMESTAMP
);
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.decision_option` (
  option_id STRING, option_label STRING, confidence FLOAT64,
  session_id STRING, extracted_at TIMESTAMP
);
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.decision_outcome` (
  outcome_id STRING, status STRING, rationale STRING, decided_at TIMESTAMP,
  session_id STRING, extracted_at TIMESTAMP
);
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.evaluates_option` (
  request_id STRING, option_id STRING,
  session_id STRING, extracted_at TIMESTAMP
);
CREATE TABLE IF NOT EXISTS `${PROJECT_ID}.${DATASET}.resulted_in` (
  request_id STRING, outcome_id STRING,
  session_id STRING, extracted_at TIMESTAMP
);

-- Graph DDL for the context-graph codelab.
--
-- Models a generic agent decision flow:
--   DecisionRequest -> evaluatesOption -> DecisionOption
--   DecisionRequest -> resultedIn       -> DecisionOutcome
CREATE OR REPLACE PROPERTY GRAPH `${PROJECT_ID}.${DATASET}.agent_decisions_graph`
  NODE TABLES (
    `${PROJECT_ID}.${DATASET}.decision_request` AS decision_request
      KEY (request_id)
      LABEL DecisionRequest PROPERTIES (request_id, request_text, requested_at),
    `${PROJECT_ID}.${DATASET}.decision_option` AS decision_option
      KEY (option_id)
      LABEL DecisionOption PROPERTIES (option_id, option_label, confidence),
    `${PROJECT_ID}.${DATASET}.decision_outcome` AS decision_outcome
      KEY (outcome_id)
      LABEL DecisionOutcome PROPERTIES (outcome_id, status, rationale, decided_at)
  )
  EDGE TABLES (
    `${PROJECT_ID}.${DATASET}.evaluates_option` AS evaluates_option
      KEY (request_id, option_id)
      SOURCE KEY (request_id) REFERENCES decision_request (request_id)
      DESTINATION KEY (option_id) REFERENCES decision_option (option_id)
      LABEL evaluatesOption,
    `${PROJECT_ID}.${DATASET}.resulted_in` AS resulted_in
      KEY (request_id, outcome_id)
      SOURCE KEY (request_id) REFERENCES decision_request (request_id)
      DESTINATION KEY (outcome_id) REFERENCES decision_outcome (outcome_id)
      LABEL resultedIn
  );
SQL

Dosyanın yerinde olduğunu doğrulayın:

ls

Bir dosya görmeniz gerekir:

context_graph_ddl.sql

Açıkladıkları karar akışında üç düğüm türü ve iki heterojen kenar vardır:

Codelab&#39;in grafik şeması: Bir DecisionRequest düğümü, değerlendirdiği DecisionOption düğümlerine evaluatesOption kenarlarıyla, kesinleşmiş DecisionOutcome&#39;a ise resultedIn kenarıyla bağlanır.

DecisionRequest, aracının aldığı sorudur. DecisionOption, aracının değerlendirdiği bir alternatiftir. DecisionOutcome, taahhüt edilen seçimi ve gerekçeyi kaydeder.

5. Özellik grafiği şemasını uygulama

bqaa context-graph, BigQuery tablolarına yazar. Bu nedenle, ilk çalıştırmadan önce tabloların mevcut olması gerekir. context_graph_ddl.sql önce beş tabloyu, ardından bunlara referans veren özellik grafiğini oluşturur (BigQuery, henüz mevcut olmayan tablolara işaret eden bir CREATE PROPERTY GRAPH'ı reddeder). Bu nedenle, tek bir uygulama ile her şey ayarlanır:

envsubst < context_graph_ddl.sql | bq query --use_legacy_sql=false

Beş CREATE TABLE sonucu ve bir CREATE PROPERTY GRAPH sonucu görmeniz gerekir. DDL, idempotent'tir. Güvenli bir şekilde yeniden çalıştırabilirsiniz.

Bu, yaptığınız tek şema çalışmasıdır ve bu SQL dosyalarının kullanıldığı tek zamandır. BigQuery artık grafiğinizin tanımını kaydeder ve bqaa context-graph, INFORMATION_SCHEMA.PROPERTY_GRAPHS'den ada göre okur. Materyalize ediciye iletilecek ayrı bir dosya yoktur ve GQL ile sorguladığınız ile materyalize edilen hiçbir zaman birbirinden farklı olamaz: Bunlar aynı dağıtılmış grafiktir.

6. Örnek temsilci etkinlikleri oluşturma

Üretim ortamında, BigQuery Agent Analytics eklentisi, ADK aracınız çalışırken etkinlikleri otomatik olarak yakalar. Bu snippet yalnızca referans amaçlıdır. Bu codelab'de çalıştırmazsınız:

from google.adk.plugins import BigQueryAgentAnalyticsPlugin

plugin = BigQueryAgentAnalyticsPlugin(
    project_id="your-project-id",
    dataset_id="agent_analytics_demo",
)
runner = Runner(agent=root_agent, plugins=[plugin])

Bu codelab'de, satırları doğrudan agent_events'ya aynı şekilde yazan küçük bir sentetik etkinlik oluşturucu kullanacaksınız. Uygulayın:

bqaa seed-events \
    --project-id "$PROJECT_ID" \
    --dataset-id "$DATASET" \
    --sessions 5

Komut, bir JSON raporu yazdırır. 5 oturum için "events_generated": 30, "events_inserted": 30 ve "ok": true değerlerini görmeniz gerekir.

Bir satırda, derlemeyi bir bakışta önizleyin (kaç oturum, kaç etkinlik ve kapsadıkları zaman aralığı):

bq query --use_legacy_sql=false \
    "SELECT COUNT(DISTINCT session_id) AS sessions, COUNT(*) AS events, MIN(timestamp) AS earliest_event, MAX(timestamp) AS latest_event FROM \`$PROJECT_ID.$DATASET.agent_events\`"

Varsayılan 5 oturum için bu raporda birkaç dakika süren 5 oturum ve 30 etkinlik gösterilir. (Aşağıdaki gerçekçi senaryoyu başlatın. Aynı sorgu, yaklaşık üç gün içinde 100 oturum bildirir.)

Etkinliklerin gerçekleştiğini doğrulayın:

bq query --use_legacy_sql=false \
    "SELECT event_type, COUNT(*) AS n FROM \`$PROJECT_ID.$DATASET.agent_events\` GROUP BY event_type ORDER BY n DESC"

25 TOOL_COMPLETED satırı ve 5 AGENT_COMPLETED satırı görmeniz gerekir (her oturumda bir submit_request, üç evaluate_option, bir commit_outcome ve bir kapatma AGENT_COMPLETED olmak üzere beş araç etkinliği ve oturum başına bir aracı sonlandırıcı gönderilir). AGENT_COMPLETED satırları, terminal etkinlik algılama için bqaa context-graph anahtarlarının kullanıldığı oturum sonlandırıcılarıdır.

İsteğe bağlı: Gerçekçi ölçekli veriler

Yukarıdaki 5 oturumluk gövde, ilk çalıştırmanın hızlı ve ucuz olması için kasıtlı olarak çok küçüktür. Üretim şeklindeki verileri (birkaç güne yayılmış birden fazla aracı ve kullanıcı, başarısız, üst öğesi olmayan ve kesilmiş oturumlar) istediğinizde decision-realistic senaryosunu kullanın. Varsayılan olarak 72 saatlik bir süre içinde 100 oturum olarak ayarlanır. Yukarıdaki ilk çalıştırma yolu değişmez.

bqaa seed-events \
    --project-id "$PROJECT_ID" \
    --dataset-id "$DATASET" \
    --scenario decision-realistic \
    --sessions 100 \
    --seed 42

JSON raporundaki session_outcome_counts, karışımı gösterir (yaklaşık {"success": 70, "failed": 10, "orphaned": 10, "truncated": 10}).

Her oturumu satırlarından sınıflandırarak sonuç dağılımını onaylayın (üst öğesi olmayan = AGENT_COMPLETED yok; başarısız = status = 'error' ile AGENT_COMPLETED; kesilmiş = is_truncated = true içeren herhangi bir satır; aksi takdirde başarılı). İlk geçişte her oturum sınıflandırılır, ikinci geçişte ise sonuçlara göre toplama yapılır:

bq query --use_legacy_sql=false \
    "WITH per_session AS (SELECT session_id, CASE WHEN COUNTIF(event_type = 'AGENT_COMPLETED') = 0 THEN 'orphaned' WHEN COUNTIF(event_type = 'AGENT_COMPLETED' AND status = 'error') > 0 THEN 'failed' WHEN COUNTIF(is_truncated) > 0 THEN 'truncated' ELSE 'success' END AS outcome FROM \`$PROJECT_ID.$DATASET.agent_events\` GROUP BY session_id) SELECT outcome, COUNT(*) AS sessions FROM per_session GROUP BY outcome ORDER BY outcome"

Yaklaşık 70 başarılı, 10 başarısız, 10 bağımsız ve 10 kesilmiş oturum görmeniz gerekir (Ayrıca, aynı veri kümesinde daha önce doldurduysanız ilk çalıştırma gövdesinden 5 başarılı oturum).

10 üstsüz oturum hiçbir zaman AGENT_COMPLETED yayınlamadı. Bu nedenle, varsayılan bqaa context-graph çalıştırması bu oturumları atlar (yalnızca terminal-event-closed oturumlarını gerçekleştirir). Sonsuza kadar sessizce yeniden denemek yerine bunları session_orphaned olarak göstermek için çalıştırırken --max-session-age-hours ekleyin. Üretime alma bölümündeki --max-session-age-hours konusuna bakın.

7. Bağlam grafiğini somutlaştırın

bqaa context-graph, ham agent_events değerini okur, ardından çıkarılacak öğeleri doğrudan dağıtılan grafiğinizden türetir: CREATE PROPERTY GRAPH tanımını Mülk grafiği şemasını uygulama bölümünde uyguladığınız şekilde BigQuery'nin INFORMATION_SCHEMA.PROPERTY_GRAPHS değerinden okur, referans verdiği tabloların şemalarıyla birleştirir, varlıkları, ilişkileri ve sütun türlerini belirler ve grafik tablolarını doldurur. --graph agent_decisions_graph ile dağıtılan grafiği adıyla işaretlersiniz. Aktarılacak bir SQL dosyası yoktur.

Koşu

bqaa context-graph yerel olarak:

bqaa context-graph \
    --project-id "$PROJECT_ID" \
    --dataset-id "$DATASET" \
    --graph agent_decisions_graph \
    --lookback-hours 24 \
    --format json

Yapılandırılmış bir JSON raporu görmeniz gerekir:

{
  "run_id": "...",
  "sessions_discovered": 5,
  "sessions_materialized": 5,
  "sessions_failed": 0,
  "rows_materialized": {
    "DecisionRequest": 5,
    "DecisionOption": 15,
    "DecisionOutcome": 5
  },
  "ok": true
}

ok: true, bqaa context-graph'in beş tamamlanmış oturum bulduğunu, her birinden AI.GENERATE aracılığıyla karar akışını çıkardığını ve ilgili satırları grafik tablolarına yazdığını gösterir. Belirleyici çıkarma (--extraction-mode=compiled-only, aşağıda açıklanmıştır) aynı rapor şeklini (aynı alanlar, aynı ok: true) döndürür. Yalnızca AI.GENERATE çağrıları atlanır.

Sorun giderme: Boş ayıklama

ok: false ile error_code = "empty_extraction" simgesini görüyorsanız bunun en yaygın nedeni aiplatform.googleapis.com API'nin henüz yaygınlaşmamış olması veya hesabınızda roles/aiplatform.user eksik olmasıdır. Bir dakika bekleyip tekrar deneyin veya rolü verin:

USER_EMAIL=$(gcloud auth list --filter=status:ACTIVE --format="value(account)")
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
    --member="user:$USER_EMAIL" --role="roles/aiplatform.user"

Ardından yukarıdaki bqaa context-graph komutunu yeniden çalıştırın.

Grafiğin satır içerdiğini doğrulayın:

bq query --use_legacy_sql=false \
    "SELECT COUNT(*) AS n FROM \`$PROJECT_ID.$DATASET.decision_request\`"

Beş satır görmeniz gerekir. Beş oturumda toplam 25 grafik düğümü (5 DecisionRequest, 15 DecisionOption ve 5 DecisionOutcome) bulunur. Bunlar 15 evaluatesOption kenarı ve 5 resultedIn kenarı (oturum başına bir karar ağı) ile birleştirilir.

Etkinliklerden kararları ayıklamanın iki yolu

bqaa context-graph iki ayıklama yolu sunar. İş yükünüze uygun olanı seçin:

  • Varsayılan ayıklama En kolay yol. Etkinlik içeriğini okumak ve varlıklar ile ilişkileri tahmin etmek için BigQuery'nin AI.GENERATE özelliğini kullanır. Ek kod olmadan tüm etkinlik şekillerine karşı çalışır. Bu, codelab'in kullandığı yöntemdir.
  • Deterministik ayıklama (--extraction-mode=compiled-only). Daha düşük maliyetli ve denetime uygun yöntemdir. Alanınız için bir kez yazdığınız küçük bir Python referans ayıklayıcı kullanır. Vertex AI çağrısı yok, jeton başına ücret yok, tamamen yeniden üretilebilir çıkış. Üretim dağıtımları, maliyetin tahmin edilebilirliği veya sıkı tekrarlanabilirlik önemli olduğunda bu seçeneği tercih eder.

IAM ayrıntıları ve referans ayıklayıcı oluşturma da dahil olmak üzere her iki yol için referans olarak bağlam grafiği dağıtım kılavuzu kullanılır.

8. Karar izlemesini sorgulama

Grafik doldurulduktan sonra denetleme sorusunu doğrudan yanıtlayabilirsiniz. Somut bir örnek verelim: "Her istek için hangi seçenekleri değerlendirdi ve nasıl çözüme ulaştı?" GQL'de bu, istek, seçenekleri ve sonucu boyunca tek bir geçiştir.

Sorguyu bir dosyaya yazın (traversal.sql). ${DATASET} işaretçisi, bir sonraki adımda sorguyu çalıştırdığınızda doldurulur:

cat > traversal.sql <<'SQL'
SELECT *
FROM GRAPH_TABLE (
  ${DATASET}.agent_decisions_graph
  MATCH
    (req:DecisionRequest) -[eo:evaluatesOption]-> (opt:DecisionOption),
    (req)                 -[ri:resultedIn]->      (out:DecisionOutcome)
  COLUMNS (
    req.request_id   AS request,
    req.request_text AS question,
    opt.option_label AS considered,
    opt.confidence   AS score,
    out.status       AS outcome,
    out.rationale    AS rationale
  )
);
SQL

Uygulayın:

envsubst < traversal.sql | bq query --use_legacy_sql=false --max_rows=20

On beş satır görmeniz gerekir: istek başına üç seçenek, beş istek. Her satırda istek, temsilcinin değerlendirdiği seçenek, güven puanı, nihai sonuç ve gerekçe gösterilir.

Tek bir kararın tüm ayrıntılarını görmek için request_id ile filtreleyerek denetim ekibinin ihtiyaç duyduğu satır kümesini (gelen soru, değerlendirilen seçenekler (puanlarla birlikte) ve kaydedilen gerekçe) elde edin.

Grafiği BigQuery Studio'da görselleştirme

BigQuery Studio, grafiği görsel olarak da oluşturabilir. BigQuery konsolunda BigQuery Studio'yu açın, aşağıdaki yol sorgusunu çalıştırın, ardından karar ağını görmek için sonuçlar bölmesini Grafik sekmesine geçirin. Gerçekçi ölçekli gövde sayesinde isteklerin, seçeneklerin ve sonuçların görsel bir haritasını elde edersiniz:

GRAPH agent_analytics_demo.agent_decisions_graph
MATCH p = (a)-[e]->(b)
RETURN TO_JSON(p) AS path_json

BigQuery Studio&#39;nun Grafik görünümünde, GQL yol sorgusundan oluşturulan gerçekleştirilmiş bağlam grafiği

Aynı soruyu yalın bir İngilizceyle sorun.

Her denetim okuyucusu GQL yazmaz. BigQuery Conversational Analytics (önizleme) ile uyumluluk ekibiniz aynı türde soruları doğal dilde sorabilir ve yapılandırılmış bir yanıt kartı alabilir. Sorgu söz dizimi veya birleştirme öğrenmeye gerek yoktur.

agent_decisions_graph (agent_events ve karar tablolarıyla birlikte) öğesini Etkileşimli Analytics veri kaynağı olarak kaydedin, ardından denetim sorusunu doğrudan sorun:

Denetleme sorusu (basit İngilizce): "Which requests never reached a committed outcome?" ("Hangi istekler hiçbir zaman taahhüt edilen sonuca ulaşmadı?")

Etkileşimli Analytics, grafiği gerekçelendirir, sizin için SQL yazar ve destekleyici bir tabloyla birlikte düz İngilizce olarak yanıt verir. Burada, kaydedilen her isteğin taahhüt edilen sonucu elde ettiği gösteriliyor:

Etkileşimli Analytics, bağlam grafiği üzerinden &quot;Hangi istekler hiçbir zaman taahhüt edilen sonuca ulaşmadı?&quot; sorusunu yanıtlıyor: Kaydedilen her istek taahhüt edilen sonuca ulaştı (üst öğesi olmayan oturumlar grafik düğümleri olarak oluşturulmaz).

Yukarıdaki yanıt, isteğe bağlı gerçek ölçekli veriler adımındaki gerçek ölçekli gövdeyi (90 somutlaştırılmış istek, tümü gönderilmiş) yansıtmaktadır. Tam sayılar, hangi gövdeyi kullandığınıza bağlıdır ve varsayılan 5 oturumlu çalıştırmada beş gösterilir.

Kurulum için Etkileşimli Analytics belgelerine bakın.

9. Üretime geçme

Yukarıdaki yerel çalıştırma, gerçek dağıtımların temellerini zaten kapsayan varsayılan davranışı kullanır: Her çalıştırma bir denetim izi bırakır (yapılandırılmış Cloud Logging'in yanı sıra veri kümenizdeki bir durum tablosunda çalıştırma başına bir satır), geçici hatalar otomatik olarak yeniden denenir ve ilerleme yalnızca tamamen başarılı olan oturumlarda gerçekleşir. Bu nedenle, iki kez sayım yapılmaz.

Üretim kontrolleri (belirleyici çıkarma --extraction-mode=compiled-only, takılı oturum algılama --max-session-age-hours, geçmiş bir pencerenin tek seferlik tekrarı --backfill --from / --to (normal yenilemeden ayrı olarak izlenir, bu nedenle canlı yayın programını etkilemez) ve çalıştırma başına toplu sınırlama --max-sessions), ihtiyacınız olduğunda kullanabileceğiniz isteğe bağlı işaretlerdir. Bağlam grafiği dağıtım kılavuzunda her biri tam IAM matrisi ve önerilen programlarla birlikte belgelenmiştir.

10. Temizleme

Boşta kalan bir veri kümesi için faturalandırılmamak üzere oluşturduğunuz öğeleri kaldırın:

bq rm -r -f --dataset "$PROJECT_ID:$DATASET"

Bu tek komut, veri kümesini, aracı etkinliklerini, grafik tablolarını ve durum tablosunu birlikte kaldırır.

11. Tebrikler

Tebrikler! Harici grafik veritabanı veya ETL işlem hattı olmadan, ham aracı etkinlik günlüklerini sorgulanabilir bir Aracı Bağlam Grafiği'ne dönüştürdünüz ve tek bir kararı uçtan uca izlediniz.

Aynı durum, bir temsilcinin önemli kararlar verdiği her yerde geçerlidir: kredi sigortası, ön onay, pazarlama bütçesi hareketleri, satın alma, müşteri hizmetleri ve dahili BT. Kendi Agent Context Graph'ınızı oluşturmak için başlangıç noktası olarak codelab yapılarını kopyalayın, iki bildirimsel dosyayı (tablo DDL'si + CREATE PROPERTY GRAPH şeması) alanınıza uyarlayın ve bunları BigQuery'ye uygulayın. bqaa context-graph --graph, dağıtılan grafiği INFORMATION_SCHEMA'den geri okur ve geri kalanını türetir.

Öğrendikleriniz

  • BigQuery veri kümesi oluşturma ve bir aracı karar alanını açıklayan özellik grafiği şeması uygulama
  • agent_events alanını yapay etkinlik korpusuyla doldurma
  • bqaa context-graph komutunu çalıştırarak aracının karar izlerini bu etkinliklerden bir aracı bağlam grafiğine çıkarma ve grafiğin tanımını INFORMATION_SCHEMA komutundan geri okuma.
  • GQL'de sonuç grafiğini sorgulama ve denetleme tarzındaki yanıtı okuma

Referans belgeleri