Study Guide3,723 words

Unit 3.3 study guide — Building and using Google Cloud AI and ML solutions

Cloud Digital Leader › Unit 3 › Topic 3

Building and using Google Cloud AI and ML solutions

Study guide for Cloud Digital Leader, Unit 3 · Topic 3. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks. Explain how Google Cloud’s pre-trained API, AutoML, and custom AI/ML products can create business value.

Objectives, quoted from the exam guide:

  1. Discuss how BigQuery ML lets users create and execute machine learning models in BigQuery by using standard SQL queries.
  2. Select which Google Cloud pre-trained API best applies to different business use cases, including: Natural Language API, Vision API, Cloud Translation API, Speech-to-Text API, and Text-to-Speech API.
  3. Explain how an organization can create business value by using their own data to train custom ML models with AutoML.
  4. Discuss how building custom models by using Google Cloud’s Vertex AI can create opportunities for business differentiation.
  5. Recognize TensorFlow as an end-to-end open source set of tools for building and training machine learning models and that Cloud Tensor Processing Unit (TPU) is Google’s proprietary hardware optimized for TensorFlow and ML performance.

Building and using Google Cloud AI and ML solutions

Four ways to get a model, and the hardware under the last one

Use a model Google already trained (the pre-trained APIs). Train one where the data already sits (BigQuery ML). Train one on your own data without code (AutoML). Build exactly the model you need (custom training). Then: what TensorFlow is, and what a TPU is.

This topic is about getting a machine learning model into the business, and the guide's summary names the menu: pre-trained APIs, AutoML, and custom artificial intelligence and machine learning products. Read the five objectives together and they form a ladder of four options, each asking more of the organization and giving it more in return. At the bottom, a pre-trained application programming interface, or API: Google has already trained the model, and you call it. Next, BigQuery ML, which trains a model with SQL — structured query language — where the data already lives. Then AutoML, which trains a model on your own data with almost no code. At the top, custom training on Google's machine learning platform, where you write the training code and control everything. The last objective steps down a layer, to the software library and the hardware those custom models run on: TensorFlow, and the tensor processing unit. Most exam items in this topic describe a business and ask which rung it belongs on — so we will keep asking what each option demands of the team.

BigQuery ML: machine learning in SQL

Bring the model to the data, in the language analysts already use

  • Create and run models with GoogleSQL queries or the console
  • Models live in BigQuery datasets, like tables and views
  • Analysts who know the data but not Python can build models
  • No moving or reformatting data for a Python framework

Worked example (synthetic). A subscription business's analysts know churn better than anyone but write no Python. With a CREATE MODEL statement over the customer table they already query, they train a churn model and score every account in the same warehouse.

BigQuery ML is the objective most easily reduced to a slogan, so hold on to what it actually changes. Google's definition is that BigQuery ML lets you create and run machine learning models by using either GoogleSQL queries or the Google Cloud console, and the models are stored in BigQuery datasets, similar to tables and views. The problem it solves is a staffing problem. Google says traditional machine learning requirements restrict solution development to a very small set of people, and exclude data analysts who understand the data but have limited machine learning knowledge and programming expertise. With BigQuery ML, SQL practitioners — people who write structured query language — use existing SQL tools and skills to build and evaluate models, and you don't need to program the solution in Python or Java. The second change is speed. BigQuery ML removes the need to move data out of the data warehouse, which Google says increases the speed of model development, and brings a faster path to production because moving and formatting large amounts of data for Python-based frameworks isn't required. And the default settings let you create and use models even without much machine learning knowledge.

Two paths from a table to a prediction

What BigQuery ML removes is the trip out of the warehouse

Loading Diagram...
Figure 1 — Mermaid diagram

Figure: Two paths from data in BigQuery to predictions. The upper path exports and reformats the data for a Python framework and trains in Python, which requires programming. The lower path runs CREATE MODEL in SQL, stores the model in a BigQuery dataset, and gets batch inferences in SQL without leaving the warehouse.

Worked example (synthetic). An exam item says a team's model work stalls for weeks while data is exported and reshaped. The graded answer is BigQuery ML, because the delay it names is exactly the step the lower path removes.

Drawn side by side, the benefit is where the arrows are not. The query language here is SQL, structured query language. On the upper path, the data leaves the warehouse, is reshaped for a Python framework, and someone who programs trains the model. On the lower path, a CREATE MODEL statement in SQL trains the model where the data already sits; the model is stored in a BigQuery dataset like any table; and Google says that using SQL commands you can quickly create a model and use it to get batch inferences. Google names both halves of the gain: removing the need to move data from the data warehouse increases the speed of model development, and not having to move and format large amounts of data for Python-based machine learning frameworks shortens the road to production. When an exam item describes data exports, reshaping, or a shortage of Python skills as the obstacle, it is describing the upper path.

The five pre-trained APIs

Each one takes one kind of input and returns one kind of answer

APITakesGives back
Natural LanguageTextSentiment (positive, negative, neutral), entities, a content category
VisionImagesText by optical character recognition, labels, landmarks, explicit-content ratings
Cloud TranslationText in one languageThe same text in another, with glossary support
Speech-to-TextAudioA transcript — including live, from a microphone
Text-to-SpeechTextNatural-sounding synthetic speech as playable audio

Worked example (synthetic). A hotel chain receives reviews in eleven languages. Translation turns them into one language; Natural Language then scores each one positive, negative or neutral. Two APIs, chained, and no model trained by the hotel.

The second objective is a matching exercise, and the fastest way to win it is to know what goes in and what comes out of each application programming interface, or API. The Natural Language API takes text. Its sentiment analysis identifies the prevailing emotional opinion, especially to determine a writer's attitude as positive, negative or neutral; its entity analysis finds known entities in the text; and content classification returns a content category. The Vision API takes images: optical character recognition, which is text recognition and conversion to machine-coded text; generalized labels for an image; landmarks; and likelihood ratings for explicit content categories. Cloud Translation takes text in one language: Google says its translation offerings enable websites and applications to translate text with state-of-the-art translation models, and the Advanced edition adds glossary support. Speech-to-Text takes audio: it integrates Google's speech recognition into applications, and its streaming requests are designed for real-time recognition, such as live audio from a microphone. And Text-to-Speech goes the other way, creating natural-sounding synthetic human speech as playable audio. None of these requires the customer to train anything. That is the point of the word pre-trained.

Which API answers which business case

Find the input in the scenario, and the API follows

Figure. Six business requests paired with the pre-trained API that answers each: Natural Language for angry support tickets, Vision for text on scanned receipts and for unsafe photos, Cloud Translation for a multilingual help center, Speech-to-Text for live captions, and Text-to-Speech for reading order updates aloud.

Worked example (synthetic). Asked which API reads the text printed on a photographed receipt, many candidates pick Natural Language because the output is text. The input is an image, so the graded answer is Vision.

Exam items give you the business request, never the name of the application programming interface, or API, so rehearse from the request. Work out what the input is, and the API follows. Angry support tickets are text, and the question is attitude, so it is Natural Language's sentiment analysis. Totals on scanned receipts are text inside an image; the input is an image, so it is Vision's optical character recognition — a common trap, because the output is text and candidates reach for Natural Language. Unsafe photos in uploads are images again, answered by Vision's explicit content ratings. A help center in nine languages is text to text, which is Cloud Translation. Live captions for a meeting are audio arriving in real time, which is what Speech-to-Text's streaming requests are designed for. And reading order updates aloud is the reverse direction — text to audio — which Google describes as ideal for any application that plays audio of human speech to users: Text-to-Speech. Two of the six cards are Vision, and that is deliberate: it is the API with the widest range of outputs.

AutoML: a model trained on your own data

The pre-trained API knows the world; AutoML learns your business

  • Create and train a model with minimal technical effort — AutoML is codeless
  • You supply the data: a managed dataset is required for AutoML
  • Tabular data predicts new cases; labeled images teach what you care about
  • Trade-off: predefined objectives, and tuning you can't modify

Worked example (synthetic). A regional insurer wants to flag claims likely to need an adjuster. No pre-trained API knows its claims. It exports five years of labeled claims as a table, trains an AutoML model, and gets a predictor built on its own history — without a data science team.

The third objective turns on a distinction the exam loves: a pre-trained application programming interface, or API, knows the world, but it does not know your business. AutoML is how an organization gets a model trained on its own data without writing a training program. Google's description is that with AutoML you create and train a model with minimal technical effort, and its comparison table puts it bluntly — AutoML is codeless. What the organization brings is the data. Managed datasets provide the source data for training models, and Google says they are required for AutoML. The data can be tabular — Google's platform uses tabular, structured data to train a model to make inferences on new data — or images, where supervised learning trains a model to recognize the patterns and content that you care about. That phrase is the business value: the patterns YOU care about, learned from YOUR examples. Google's own advice on when to use it is to quickly prototype models and explore new datasets before investing in development. And the trade-off is stated just as plainly: you must target one of AutoML's predefined objectives, and AutoML performs some automated tuning, but you can't modify the values.

The AutoML journey, as Google lays it out

Most of the work is before training and after it

Loading Diagram...
Figure 2 — Mermaid diagram

Figure: A flow from establishing the use case, to gathering your own data, to a managed dataset required for AutoML, to training with AutoML without code, to evaluating model metrics. If the model is not ready the flow returns to gathering data; if satisfied, the model is used on new data.

Worked example (synthetic). An item asks what an organization must supply for AutoML to create value. Not code and not a model architecture — labeled data of its own, in a managed dataset.

Google's beginner's guide to AutoML walks a sequence, and drawing it shows where the organization's effort actually goes. It begins with the use case: after you've established your use case, you'll need to gather data to train your model. The data becomes a managed dataset, which AutoML requires. Training itself is the codeless step. Then comes evaluation, and Google is explicit that evaluating your model metrics is primarily how you determine whether your model is ready to deploy — you can also test it with new data. The loop back matters: a model that is not ready sends you back to the data, not to the code. Only when you are satisfied with your model's performance is it time to use the model. So the business value of AutoML is not that nothing is required. It is that what is required — knowing the use case and having good data — is something the business already has, rather than a machine learning engineering team.

Custom models on Google's platform

The guide says Vertex AI; Google now says Gemini Enterprise Agent Platform

  • Google describes the platform as an evolution of Vertex AI
  • Custom training: any objective, any algorithm, your own loss functions
  • Full control of hyperparameter values, in your own training code
  • Differentiation: a model competitors cannot buy off the shelf

Worked example (synthetic). A streaming service's recommendations ARE its product. A predefined objective would give it what every competitor can also train, so it writes its own training code, with its own loss function, on the platform's managed infrastructure.

The fourth objective names Vertex AI, and here the guide and Google's current documentation part ways on the name. Every Vertex AI documentation page now redirects to Gemini Enterprise Agent Platform, which Google calls a unified platform to build, deploy, govern and optimize enterprise-grade artificial intelligence, or AI, agents and model-based solutions, and describes as an evolution of Vertex AI. Answer to either name on the exam; they are the same lineage. What the objective is really about is differentiation, and that comes from custom training. Google says that with custom training you create a training application optimized for your targeted outcome — namely, you can target any objective, use any algorithm, develop your own loss functions or metrics, or do any other customization — and you provide the training code, giving you full control over hyperparameter values. Compare that with AutoML's predefined objectives and fixed tuning. A model built from predefined objectives is a model any competitor with similar data can also build. A model with your own objective and your own loss function encodes a judgement nobody else has made. Google's summary covers both routes: whether you use AutoML for a fast path to high-quality models or create custom models with frameworks like TensorFlow and PyTorch, the platform operationalizes the entire machine learning lifecycle — and if AutoML doesn't address your needs, you provide your own training code and run it on managed infrastructure. Once trained, the model is managed in the Model Registry, which Google says lets you track model versions, evaluate model quality, and deploy models for serving inferences.

Three ways to train, side by side

What each one asks of the team, and what it gives back

AspectAutoMLBigQuery MLCustom training
ProgrammingNone — codelessSQLYour own training code
ObjectivesPredefined onlyLimited setAny objective, any algorithm
TuningAutomatic; values not modifiableHyperparameter tuning supportedFull control of hyperparameters
Best whenPrototyping on your own dataThe data is already in BigQueryThe model itself is the differentiator

Worked example (synthetic). Three teams, one question each: a marketing team with a spreadsheet and no coders (AutoML), analysts living in the warehouse (BigQuery ML), and a research team whose loss function is a trade secret (custom training).

Google publishes a comparison of its machine learning training methods, and it reduces to four rows. On programming: AutoML is codeless, BigQuery ML uses SQL — structured query language — and custom training needs your own training code. On objectives: AutoML must target one of its predefined objectives; custom training can target any objective and use any algorithm. On tuning: AutoML performs some automated tuning but you can't modify the values; custom training gives you full control over hyperparameter values. And on when each fits: AutoML to quickly prototype on new datasets, BigQuery ML when the data already sits in BigQuery and SQL is the team's language, and custom training when the model is itself the differentiator. Google frames the whole choice as depending on your team's expertise, the level of control you need, and your infrastructure preference — which is exactly how exam items are written: they describe the team, and the right column follows.

TensorFlow and Cloud TPU

One is software you write with; the other is hardware you run on

Figure. Two cards and a band. TensorFlow is software: a free, open source library for machine learning focused on deep neural networks. Cloud TPU is hardware: Google's custom-developed chips for large matrix operations. The band explains that the XLA compiler turns a framework's graph into TPU machine code.

Worked example (synthetic). An item offers "TensorFlow is Google's proprietary chip". That swaps the two: TensorFlow is the open source library, and the TPU is the proprietary hardware.

The fifth objective is recognition, and the trap is swapping the two things it names. TensorFlow is software. Google describes it as a free, open source software library for machine learning and artificial intelligence, usable across a range of tasks but with a particular focus on training and inference of deep neural networks. The tensor processing unit, or TPU, is hardware: Google's custom-developed application-specific integrated circuits, or ASICs, used to accelerate machine learning workloads. Google explains why the design helps — TPUs efficiently train models by using hardware designed for performing the large matrix operations often found in machine learning algorithms. The guide calls the TPU optimized for TensorFlow, and that was the original pairing. Google's current TPU page is framework-neutral: code that runs on TPUs is compiled by the accelerated linear algebra compiler, XLA, a just-in-time compiler that takes the graph emitted by a machine learning framework application and compiles it into TPU machine code. So remember both: the guide's answer is that the TPU is Google's proprietary hardware optimized for TensorFlow, and the current reality is that it accelerates machine learning frameworks through XLA.

When a TPU is the right chip, and when it is not

Google says TPUs are optimized for specific workloads

WorkloadGoogle's guidance
Models dominated by matrix computationsTPU
Models that train for weeks or monthsTPU
Quick prototyping that requires maximum flexibilityCPU
Workloads that require high-precision arithmeticNot suited to TPU

Worked example (synthetic). A scientific team's simulation needs high-precision arithmetic. However famous TPUs are for machine learning, Google lists this among the workloads TPUs are not suited to.

Recognizing the TPU also means recognizing where it does not belong, because Google says plainly that Cloud TPUs are optimized for specific workloads. Its guidance lists models dominated by matrix computations, and models that train for weeks or months, as TPU workloads. For quick prototyping that requires maximum flexibility, the same page points to central processing units, or CPUs. And it lists workloads that require high-precision arithmetic among those TPUs are not suited to at all. The exam uses this in a simple way: an item that describes very large, long-running machine learning training points at a tensor processing unit, and an item that describes a small experiment or a precision-sensitive calculation is testing whether you will reach for the TPU anyway.

What this topic actually tests

Read the team, then pick the rung

Does the business need its own model? No → a pre-trained API, chosen by input. Is the data in BigQuery and the team fluent in SQL? → BigQuery ML. Own data, no coders? → AutoML. Is the model the differentiator? → custom training. And TensorFlow is software; the TPU is hardware.

Close the topic with the ladder, because nearly every item here is a question about which rung a business belongs on. If the business does not need a model of its own, a pre-trained application programming interface answers it, and you pick the API by its input — text, images, audio, or text to be spoken or translated. If the data is already in BigQuery and the team speaks SQL, structured query language, BigQuery ML trains the model in place. If the business has its own data but no programmers, AutoML trains a model on that data with minimal technical effort, inside predefined objectives. If the model itself is the competitive advantage, custom training on Google's machine learning platform — the evolution of Vertex AI, Google's artificial intelligence platform — lets the team target any objective with any algorithm. And beneath all of it, keep the two recognition facts straight: TensorFlow is the open source software library, and the tensor processing unit is Google's custom hardware for machine learning.

Official sources for this topic

Ready to study Cloud Digital Leader (GCP-CDL)?

Practice tests, flashcards, and all study notes — free, no sign-up needed.

Start Studying — Free