Головна / Статті / Практичні нотатки: Три рівні Google Cloud RAG – векторний пошук, двигун RAG та агентське отримання даних

Практичні нотатки: Три рівні Google Cloud RAG – векторний пошук, двигун RAG та агентське отримання даних

Покрокове пояснення до практичних нотаток: Три рівні Google Cloud RAG – векторний пошук, двигун RAG та агентське отримання даних: контракти, перевірки та слоти для вставки коду.

3958 слів

Використовуйте цей документ як оновлену версію ідей з тексту „Три рівні Google Cloud RAG: векторний пошук, двигун RAG та механізм отримання даних від агента“ для спеціалістів: чіткі етапи, впорядковані блоки коду та примітки щодо відновлення, які залишаються при передачі обов’язків. Огляд ефективніше всього функціонує, якщо його розглядати як вимірювану структуру. Запишіть один ідеальний запис, один випадок збою та примітки щодо скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям коду перед складними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій.

Архітектурні та абстракційні шари

Для архітектурних та абстракційних шарів необхідно визначити вхідні дані, відповідальну особу за кожен крок та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цю стадію як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового завершення роботи. Наводьте конкретні уривки, які лежать в основі відповіді. Без посилань оператори не зможуть відрізнити галюцинації від проблем із індексуванням.

1. Vertex AI Vector Search (Рівень 1: Інфраструктура високої продуктивності)

Для 1. Vertex AI Vector Search (Рівень 1: Інфраструктура високої продуктивності) необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовища до спільних середовищ. Наводьте уривки тексту, які фактично лягли в основу відповіді. Без посилань оператори не зможуть відрізнити галюцинації від проблем із індексуванням.

Основна архітектура та механізми

Щодо основної архітектури та механік, необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь код. Наводьте уривки тексту, які фактично лежать в основі відповіді. Без посилань оператори не зможуть відрізнити галюцинацію від проблем із індексуванням. Щодо основної архітектури та механік, необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру обробки даних.

e.

Триетапний механізм пошуку ScaNN

Під час роботи з триетапним механізмом пошуку ScaNN спочатку сформулюйте контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність у подальших змінах коду. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Дайте назви елементам, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань. Вимірюйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням підказок. Часта зміна підказок рідко вирішує проблеми слабкого механізму пошуку.

Розподілена інфраструктура: інновації двигуна зіставлення Vertex

Під час роботи над проектом «Розподілена інфраструктура: інновації двигуна зіставлення вершин» спочатку запишіть контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової несправності. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли процес переходить від демо-версії до спільних середовищ. Вимірюйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням підказок. Часта зміна підказок рідко допомагає покращити ефективність пошуку.

Сценарії використання Google Vector Search у продакшні

Під час роботи над кейсами використання у продакшені для Google Vector Search спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Вимірюйте рівень відтворення результатів на фіксованому наборі запитань перед налаштуванням формулювань запитів. Часта зміна формулювань рідко виправляє проблеми з пошуком. Під час роботи над кейсами використання у продакшені для Google Vector Search спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли якась крок виконання зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій.

1. Багатомодальний електронний комерційний сервіс у реальному часі та пошук у візуальному каталозі

  1. Багатомодальний електронний комерційний сервіс у реальному часі та пошук у візуальному каталозі працює найкраще, коли його розглядають як вимірювану систему. Зафіксуйте один ідеальний приклад роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу завдань. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Розділіть політику розбиття на частини та політику пошуку. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.

2. Генерація мільярдів кандидатів для систем рекомендацій

  1. Генерація кандидатів у масштабах мільярдів для систем рекомендацій працює найкраще, коли її розглядають як вимірювану поверхню. Зафіксуйте один ідеальний приклад роботи, один випадок невдачі та примітки щодо скасування змін перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Візуалізація витрат на ранньому етапі запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ. Розділяйте політику часткової обробки даних та політику їх пошуку; зміна однієї не повинна змушувати переписувати іншу при зміні показників якості.

3. Кластерування фінансових шахрайств та кібераномалій у реальному часі

  1. Кластерування фінансових шахрайств у реальному часі та кібераномалій працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь граф. Розділяйте політику часткової обробки даних та політику їх отримання. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості.
  2. Кластерування фінансових шахрайств у реальному часі та кібераномалій працює найкраще, коли його розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Віддавайте перевагу малим, тестованим одиницям перед величезними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій.

Код: створення індексу, потокове введення даних та запити

Для модулю «Код: створення індексу, потокове введення даних та запити» необхідно визначити вхідні дані, відповідального за виконання кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити цей крок з відомої точки контролю, не намагаючись визначити прихований стан. Розглядайте цю стадію як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте мовчазного часткового завершення роботи. Наводьте конкретні уривки тексту, які лягли в основу відповіді. Без посилань оператори не зможуть відрізнити галюцинації від проблем із індексуванням.

package main

import (
 "context"
 "fmt"
 "log"

 aiplatform "cloud.google.com/go/aiplatform/apiv1"
 aiplatformpb "cloud.google.com/go/aiplatform/apiv1/aiplatformpb"
 "google.golang.org/api/option"
)

func main() {
 ctx := context.Background()
 projectID := "my-enterprise-gcp-project"
 location := "us-central1"

 // 1. Initialize Vertex AI Match Client (Vector Search Query Service)
 matchClient, err := aiplatform.NewMatchClient(ctx)
 if err != nil {
  log.Fatalf("failed to create vertex match client: %v", err)
 }
 defer matchClient.Close()

 indexEndpointPath := fmt.Sprintf(
  "projects/%s/locations/%s/indexEndpoints/product_catalog_endpoint_id",
  projectID, location,
 )
 deployedIndexID := "product_catalog_deployed_v1"

 // 2. Construct 768-dimensional Query Embedding Vector
 queryVector := make([]float32, 768)
 queryVector[0] = 0.032
 queryVector[1] = -0.108
 queryVector[2] = 0.449

 // 3. Build Nearest Neighbor Request with Boolean & Numeric Restricts
 req := &aiplatformpb.FindNeighborsRequest{
  IndexEndpoint:   indexEndpointPath,
  DeployedIndexId: deployedIndexID,
  Queries: []*aiplatformpb.FindNeighborsRequest_Query{
   {
    Datapoint: &aiplatformpb.IndexDatapoint{
     DatapointId:   "query_req_001",
     FeatureVector: queryVector,
     Restricts: []*aiplatformpb.IndexDatapoint_Restriction{
      {
       Namespace: "category",
       AllowList: []string{"electronics", "audio"},
      },
      {
       Namespace: "brand",
       AllowList: []string{"sony", "bose"},
      },
     },
     NumericRestricts: []*aiplatformpb.IndexDatapoint_NumericRestriction{
      {
       Namespace: "price",
       Value: &aiplatformpb.IndexDatapoint_NumericRestriction_ValueFloat{
        ValueFloat: 350.0,
       },
       Op: aiplatformpb.IndexDatapoint_NumericRestriction_LESS_EQUAL,
      },
      {
       Namespace: "in_stock",
       Value: &aiplatformpb.IndexDatapoint_NumericRestriction_ValueInt{
        ValueInt: 1,
       },
       Op: aiplatformpb.IndexDatapoint_NumericRestriction_EQUAL,
      },
     },
    },
    NeighborCount: 5,
   },
  },
  ReturnFullDatapoint: false,
 }

 // 4. Execute Sub-Millisecond Vector Similarity Search
 resp, err := matchClient.FindNeighbors(ctx, req)
 if err != nil {
  log.Fatalf("failed to execute find neighbors: %v", err)
 }

 if len(resp.NearestNeighbors) > 0 {
  fmt.Printf("Retrieved %d nearest neighbors:\n", len(resp.NearestNeighbors[0].Neighbors))
  for _, neighbor := range resp.NearestNeighbors[0].Neighbors {
   fmt.Printf("Datapoint ID: %s | Distance: %.4f\n", neighbor.Datapoint.DatapointId, neighbor.Distance)
  }
 }
}

2. Vertex AI RAG Engine (Рівень 2: керований проміжний шар)

Для рівня 2. Vertex AI RAG Engine (рівень 2: керований проміжний шар) необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись визначити прихований стан. Записуйте час виконання та витрати на токени або запити поруч із функціональними результатами. Візуалізація витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовища до спільних середовищ. Наводьте уривки тексту, які фактично лягли в основу відповіді. Без посилань оператори не зможуть відрізнити галюцинації від проблем з індексуванням.

Основна архітектура та механізми

Щодо основної архітектури та механік, необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь код. Наводьте уривки тексту, які фактично лежать в основі відповіді. Без посилань оператори не зможуть відрізнити галюцинацію від проблем із індексуванням. Щодо основної архітектури та механік, необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану структуру обробки даних.

e.

Ще одна архітектурна перевага: підключувані бекенди векторних баз даних

Під час роботи над ще однією архітектурною перевагою — підключуваними бекендами векторних баз даних — спочатку сформулюйте контракт: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте елементи коду, визначте критерії успіху та не допускайте беззвучного часткового виконання завдань. Вимірюйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням запрошень до виконання завдань. Часті зміни запрошень рідко допомагають покращити якість пошуку.

Чому ця роз’єднана архітектура є проривною

Під час вивчення матеріалу «Чому ця архітектура з роз’єднанням є проривною» спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли система переходить від демо-режиму до спільних середовищ. Перевірте ефективність пошуку на фіксованому наборі запитань перед налаштуванням формулювань запитів. Часта зміна формулювань рідко допомагає покращити якість пошуку.

Кейс використання у продакшені: Асистент з політикою HR та дотриманням регуляцій у корпораціях

Під час роботи над випадком використання у продакшені: Assistant для політики HR та дотримання регуляцій у корпораціях, спочатку запишіть умови використання: необхідні дані вхіду, сигнал успіху та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність подальших змін у коді. Зберігайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Вимірюйте рівень точності на фіксованому наборі запитань перед налаштуванням підказок. Зміна підказок рідко вирішує проблеми слабкого пошуку інформації. Під час роботи над випадком використання у продакшені: Assistant для політики HR та дотримання регуляцій у корпораціях, спочатку запишіть умови використання: необхідні дані вхіду, сигнал успіху та те, що відбувається при частковій невдачі. Цей перелік допомагає зберігати чесність подальших змін у коді. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли якийсь крок зазнає невдачі, ця проблема має вказувати на конкретну причину.

можливість, а не заплутана система обробки.

Код: Grounded Generation з Vertex RAG Store

Код: Grounded Generation з Vertex RAG Store працює найкраще, якщо його розглядати як вимірювану поверхню. Запишіть один ідеальний приклад роботи, один випадок збою та примітки щодо скасування змін перед розширенням обсягу завдань. Розглядайте цей етап як угоду між вхідними даними та перевіреними результатами. Придумайте назви для кожного елемента, визначте критерії успіху та не допускайте мовчазного часткового виконання завдань. Розділіть політику розбиття на частини та політику пошуку даних. Зміна однієї з них не повинна змушувати переписувати іншу, коли змінюються показники якості.

package main

import (
 "context"
 "fmt"
 "log"

 "google.golang.org/genai"
)

func main() {
 ctx := context.Background()
 projectID := "my-enterprise-gcp-project"
 location := "us-central1"

 // 1. Initialize Google GenAI Client with Vertex AI Backend
 client, err := genai.NewClient(ctx, &genai.ClientConfig{
  Project:  projectID,
  Location: location,
  Backend:  genai.BackendVertexAI,
 })
 if err != nil {
  log.Fatalf("failed to initialize genai client: %v", err)
 }

 // 2. Reference the Managed RAG Corpus Resource
 // (Corpus can be backed by RagManagedDb, Vertex Vector Search, Weaviate, or Pinecone)
 ragCorpusResource := fmt.Sprintf(
  "projects/%s/locations/%s/ragCorpora/enterprise_hr_policies_corpus",
  projectID, location,
 )

 // 3. Configure Grounding Tool with Vertex RAG Store and Semantic Reranking
 config := &genai.GenerateContentConfig{
  Tools: []*genai.Tool{
   {
    Retrieval: &genai.Retrieval{
     VertexRagStore: &genai.VertexRagStore{
      RagResources: []*genai.VertexRagStoreRagResource{
       {RagCorpus: ragCorpusResource},
      },
      SimilarityTopK:          genai.Ptr(int64(3)),
      VectorDistanceThreshold: genai.Ptr(0.5),
     },
    },
   },
  },
 }

 // 4. Generate Grounded Response with Gemini 3.5 Flash
 prompt := "Summarize our international meal reimbursement policy and specify receipt requirements."
 result, err := client.Models.GenerateContent(ctx, "gemini-3.5-flash", genai.Text(prompt), config)
 if err != nil {
  log.Fatalf("failed to generate grounded content: %v", err)
 }

 // 5. Output Synthesized Text and Inspect Verifiable Grounding Supports
 fmt.Println("--- Grounded Answer from Gemini ---")
 fmt.Println(result.Text())

 if len(result.Candidates) > 0 && result.Candidates[0].GroundingMetadata != nil {
  meta := result.Candidates[0].GroundingMetadata
  fmt.Printf("\nGrounding supports detected: %d\n", len(meta.GroundingSupports))
  for _, support := range meta.GroundingSupports {
   if support.Segment != nil {
    fmt.Printf("Segment: %q (Grounded by chunks: %v)\n", support.Segment.Text, support.GroundingChunkIndices)
   }
  }
 }
}

3. Vertex AI Agent Retrieval (Рівень 3: Автономне міркування)

  1. Vertex AI Agent Retrieval (рівень 3: автономне міркування) працює найкраще, коли його розглядають як вимірювану систему. Збережіть один ідеальний запис, один випадок збою та примітку про скасування дій перед розширенням обсягу роботи. Записуйте час виконання та витрати на токени чи запити поруч із функціональними результатами. Відомість витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-версії до спільних середовищ. Встановіть ліміти на кількість токенів за хід та за сеанс. Інструменти типу агентів активно розширюють контекст; жорсткі обмеження не дозволяють демо-версіям перетворюватися на несподівані рахунки.

Основна архітектура та ключові характеристики

Core Architecture and Key Attributes функціонують найкраще, коли їх розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Розділяйте політику часткової обробки даних та політику їх отримання. Зміна однієї з них не повинна змушувати переписувати іншу при зміні показників якості. Core Architecture and Key Attributes функціонують найкраще, коли їх розглядають як вимірювану поверхню. Збережіть один ідеальний запис, один випадок збою та примітку про скасування змін перед розширенням обсягу роботи. Віддавайте перевагу невеликим, тестованим одиницям перед величезними скриптами. Коли якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на складну послідовність операцій.

Ключові характеристики системи отримання даних Vertex AI Agent

Для ключових атрибутів функції отримання даних у Vertex AI Agent необхідно визначити вхідні дані, власника кроку та критерії завершення перед зміною коду. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Розглядайте цю стадію як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте беззвучного часткового завершення роботи. Наводьте конкретні уривки тексту, які лягли в основу відповіді. Без посилань оператори не зможуть відрізнити галюцинації від проблем із індексуванням.

Сценарій використання у продакшні: Автономний агент для вирішення інцидентів у SRE DevOps

Для сценарію виробничого використання: Автономний агент для вирішення інцидентів у рамках практик SRE та DevOps. Перед зміною коду необхідно визначити вхідні дані, відповідальну особу за кожен крок та критерії завершення. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись визначити прихований стан системи. Необхідно фіксувати час виконання та витрати на токени чи запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам під час переходу від демо-середовищ до спільних. Слід посилатися на конкретні уривки тексту, які лежать в основі відповіді. Без посилань оператори не зможуть відрізнити галюцинації від проблем з індексуванням.

Код: Створення автономного агента за допомогою Google ADK

Для коду: створення автономного агента за допомогою Google ADK — перед зміною коду необхідно визначити вхідні дані, власника кроку та критерії завершення. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Конфігурацію слід тримати окремо від коду додатку. Файли середовища, сховища конфіденційних даних та флаги функцій мають знаходитися в одному місці, яке оператори можуть перевірити, не читаючи весь код. Наводьте уривки тексту, які фактично лежать в основі відповіді. Без посилань оператори не зможуть відрізнити галюцинацію від проблем із індексуванням. Для коду: створення автономного агента за допомогою Google ADK — перед зміною коду необхідно визначити вхідні дані, власника кроку та критерії завершення. Оператори повинні мати можливість перезапустити крок з відомої точки контролю, не намагаючись вгадати прихований стан. Віддавайте перевагу невеликим, тестованим одиницям коду перед об’ємними скриптами. Коли крок зазнає невдачі, причина має вказувати на конкретне рішення.

можливість використання, а не заплутану систему обробки.

package main

import (
 "context"
 "fmt"
 "log"

 "google.golang.org/adk/agent"
 "google.golang.org/adk/model"
 "google.golang.org/adk/runner"
 "google.golang.org/adk/tool"
 "google.golang.org/adk/tool/vertexsearch"
)

// TelemetryQueryParams defines input arguments for the structured telemetry tool.
type TelemetryQueryParams struct {
 ServiceName       string `json:"service_name" jsonschema:"description=The target microservice name (e.g. payment-gateway)"`
 TimeWindowMinutes int    `json:"time_window_minutes" jsonschema:"description=The lookback window in minutes"`
}

// TelemetryReport defines the structured metrics returned to the agent.
type TelemetryReport struct {
 Service          string  `json:"service"`
 TimeWindow       string  `json:"time_window"`
 ErrorRate        float64 `json:"error_rate_percentage"`
 DominantStatus   string  `json:"dominant_http_status"`
 RootDependency   string  `json:"root_downstream_dependency"`
 ActiveRestarts   int     `json:"active_pod_restarts"`
 Region           string  `json:"region"`
}

// QuerySystemTelemetry is a custom tool function registered with the ADK agent.
func QuerySystemTelemetry(ctx context.Context, params TelemetryQueryParams) (TelemetryReport, error) {
 // Simulated query against Cloud Spanner and BigQuery live telemetry
 return TelemetryReport{
  Service:        params.ServiceName,
  TimeWindow:     fmt.Sprintf("%dm", params.TimeWindowMinutes),
  ErrorRate:      14.8,
  DominantStatus: "504 Gateway Timeout",
  RootDependency: "auth-token-validator-v2",
  ActiveRestarts: 12,
  Region:         "us-central1",
 }, nil
}

func main() {
 ctx := context.Background()
 projectID := "my-enterprise-gcp-project"

 // 1. Create Structured Telemetry Function Tool using Google ADK
 telemetryTool, err := tool.NewFunction(
  "query_system_telemetry",
  "Queries Cloud Spanner and BigQuery for live microservice error rates and container health.",
  QuerySystemTelemetry,
 )
 if err != nil {
  log.Fatalf("failed to create telemetry tool: %v", err)
 }

 // 2. Configure Vertex AI Search Datastore Retrieval Tool in Google ADK
 datastoreResource := fmt.Sprintf(
  "projects/%s/locations/global/collections/default_collection/dataStores/sre-runbooks-datastore",
  projectID,
 )
 runbookTool, err := vertexsearch.NewDatastoreTool(vertexsearch.DatastoreConfig{
  Name:        "sre_runbook_search",
  Description: "Searches authoritative SRE incident runbooks, architecture specs, and standard operating procedures (SOPs).",
  DatastoreID: datastoreResource,
 })
 if err != nil {
  log.Fatalf("failed to create vertex search tool: %v", err)
 }

 // 3. Define Autonomous SRE Agent using Google ADK
 systemInstruction := `You are an expert Autonomous Site Reliability Engineering (SRE) Incident Agent.
When investigating production alerts:
1. Use query_system_telemetry to inspect live metrics and isolate the failing component.
2. Formulate a targeted search query with sre_runbook_search to find the exact recovery SOP.
3. Synthesize a comprehensive Incident Diagnosis Report containing:
   - Root cause analysis with telemetry evidence
   - Step-by-step remediation commands cited directly from the runbook
   - Actionable rollback or mitigation steps.`

 sreIncidentAgent, err := agent.New(agent.Config{
  Name:        "sre_incident_investigator",
  Model:       model.Gemini("gemini-3.5-flash"),
  Description: "Autonomous SRE agent that investigates telemetry, retrieves runbooks, and drafts mitigation plans.",
  Instruction: systemInstruction,
  Tools:       []tool.Tool{telemetryTool, runbookTool},
 })
 if err != nil {
  log.Fatalf("failed to initialize ADK agent: %v", err)
 }

 // 4. Execute Multi-Turn Autonomous Workflow with Google ADK Runner
 r := runner.NewInMemoryRunner(sreIncidentAgent)

 userIncidentPrompt := "CRITICAL ALERT: Payment service checkout latency spiked to 4500ms in us-central1. " +
  "Investigate the payment-gateway service, locate the relevant runbook, and recommend immediate remediation."

 response, err := r.Run(ctx, userIncidentPrompt)
 if err != nil {
  log.Fatalf("agent execution failed: %v", err)
 }

 fmt.Println("--- Agentic Incident Resolution Plan ---")
 fmt.Println(response.Text())
}

4. Чергова структура прийняття рішень: вибір правильного сервісу Google RAG

Під час роботи над розділом 4. Чергова структура прийняття рішень: вибір правильного сервісу Google RAG спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Цей перелік допомагає зберігати чесність пізніших змін у коді. Розглядайте цей етап як контракт між вхідними даними та перевіреними результатами. Позначте всі елементи, визначте критерії успіху та не допускайте безпроблемного часткового виконання завдань. Вимірюйте рівень відтворення інформації на фіксованому наборі запитань перед налаштуванням підказок. Часта зміна підказок рідко допомагає покращити якість пошуку інформації.

Матриця порівняння

Під час роботи з матрицею порівняння спочатку запишіть умови контракту: необхідні вхідні дані, сигнал про успіх та те, що відбувається у разі часткової невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Запишіть час виконання та витрати на токени або запити поруч із функціональними результатами. Чітке бачення витрат заздалегідь запобігає несподіваним рахункам, коли система переходить від демо-режиму до спільних середовищ. Вимірюйте рівень відтворення інформації за фіксованим набором запитань перед налаштуванням підказок. Часта зміна підказок рідко допомагає покращити ефективність пошуку.

5. Підсумок та архітектурні висновки

Під час роботи над розділом 5. «Узагальнення та архітектурні висновки» спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Тримайте конфігурацію окремо від коду додатку. Файли середовища, сховища секретних даних та флаги функцій мають знаходитися в одному місці, де оператори можуть їх перевіряти, не читаючи весь код. Перед налаштуванням запитів вимірюйте рівень відтворення інформації на фіксованому наборі запитань. Часта зміна формулювань запитів рідко вирішує проблеми слабкого пошуку даних. Під час роботи над розділом 5. «Узагальнення та архітектурні висновки» спочатку запишіть умови взаємодії: необхідні вхідні дані, сигнал про успіх та те, що відбувається при частковій невдачі. Такий перелік допомагає зберігати чесність пізніших змін у коді. Віддавайте перевагу малим, тестованим одиницям коду перед величезними скриптами. Якщо якийсь крок зазнає невдачі, причина має вказувати на конкретну відповідальність, а не на заплутану послідовність операцій.

Чек-лист для експлуатації

Під час роботи з контрольним списком операцій спочатку запишіть умови контракту: необхідні вхідні дані, сигнал успіху та те, що відбувається при частковій невдачі. Цей контрольний список допомагає зберігати чесність пізніших змін у коді.

Документуйте як шлях успішної роботи, так і шлях відновлення одночасно. Повторні спроби, людський контроль та обробка некоректних повідомлень є частиною продукту, а не етапом подальшої оптимізації.

Вимірюйте ефективність пошуку за фіксованим набором запитань перед налаштуванням підказок. Зміна підказок рідко допомагає вирішити проблеми слабкого пошуку.

Зберігайте стан графа у простому та типованому вигляді. Вкладені структури приховують інформацію про те, який вузол заповнив яке поле, і ускладнюють продовження роботи після перерв.

Оцінюйте відповіді за один крок та послідовності дій у кілька кроків окремо. Агрегація оцінок чату приховує проблеми з циклами в роботі інструменту.

Напишіть короткий посібник: як змінювати ключі, як спорожнювати чергу, як скасовувати останнє завантаження даних.

Перш ніж запускати стек у продакшн, заморозьте версії, створіть «золотий» запис для критичного шляху та підтвердьте кроки відкату. У спільних середовищах необхідні обмеження на частоту використання, перевірки прав доступу та чіткий власник для зміни секретів. Віддавайте перевагу надійності перед креативними одноразовими демонстраціями.

Примітка для 331adf7ac401: не зберігайте ключі постачальника у репозиторії, встановіть ліміт токенів на сеанс та зберігайте записи поруч із фікстурами для оцінки, щоб подальша заміна моделей залишалася порівнянною.