Google Cloud’s AI and ML solutions

Study guide for Cloud Digital Leader, Unit 3 · Topic 2. 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. Discuss the range of Google Cloud AI and ML solutions and products available, and how to select the most appropriate solution for different business use cases.

Objectives, quoted from the exam guide:

Explain which decisions and tradeoffs organizations need to consider when selecting Google Cloud AI/ML solutions and products, including: speed; effort; differentiation; required expertise.
Discuss which Google Cloud AI and ML solutions and products might apply given different business use cases, including: pre-trained APIs; AutoML; build custom models.

Google Cloud's AI and ML solutions

Three ways to get a model, and four things the choice costs

Use a model Google already trained (pre-trained APIs), train one on your data without code (AutoML), or build your own (custom training). What separates them is speed, effort, differentiation and required expertise — and every exam item in this topic is one of those four trade-offs.

This topic is short on objectives and long on consequence: two objectives, and they are one decision seen from two sides. The decision is how an organization gets an artificial intelligence (AI) or machine learning (ML) model that does what it needs. There are three answers, and the exam guide names them: pre-trained application programming interfaces (APIs), AutoML, and building custom models. The first objective asks what the choice trades — the guide lists speed, effort, differentiation and required expertise. The second asks which answer fits which business use case. Google's own documentation frames the same choice in almost the same words: your choice depends on your team's expertise, the level of control you need, and your infrastructure preference. One naming note before we start. Google's machine learning documentation now calls its unified platform Gemini Enterprise Agent Platform. Some Google pages, and most study material written before the change, still call it Vertex AI. They are the same platform; this deck uses the current name.

Four trade-offs, three approaches

What each approach buys, and what it costs

Trade-off	Pre-trained API	AutoML	Custom model
Speed	Fastest — a model that is ready to use	Fast — less data preparation, no development	Slowest — code development for each job
Effort	Call the API	Minimal technical effort; codeless	Write and run a training application
Differentiation	Least — the same general model everyone calls	Some — trained on your data, toward a predefined objective	Most — any objective, any algorithm, your own metrics
Required expertise	Developers who can call an API	No data science expertise needed	Data scientists and programmers

Worked example (synthetic). Three teams at one retailer each want "AI". One needs product photos tagged by next week, one wants to predict churn from its own sales table, one wants a pricing model no competitor has. Each sits in a different column.

The first objective asks which decisions and trade-offs matter when selecting a Google Cloud artificial intelligence (AI) or machine learning (ML) solution, and names four: speed, effort, differentiation and required expertise. Read the table across each row and a pattern appears. On speed, the pre-trained end wins: Google's Model Garden describes most of its prebuilt, task-specific models as ready to use. AutoML is next — Google says less data preparation is required and no development is needed — while custom training involves code development and resource provisioning time for each job. On effort, Google says that with AutoML you create and train a model with minimal technical effort, and that AutoML is codeless. On required expertise, the same comparison says AutoML needs no data science expertise, while custom training needs it to develop the training application and handle data preparation. Differentiation runs the other way, and that is the whole trade. A pre-trained model is the same general model every customer calls. AutoML learns from your own data but must target one of its predefined objectives. Custom training lets you target any objective, use any algorithm, and develop your own loss functions or metrics. Every step toward differentiation is paid for in speed, effort and expertise.

The choice as three questions

Stop at the first question that says yes

Loading Diagram...

Figure 1 — Mermaid diagram

Figure: A decision flow. First question: does a ready-made model already do this task? If yes, use a pre-trained API. If no, second question: does one of AutoML's predefined objectives fit? If yes, use AutoML on your own data. If no, third question: do you have data scientists and programmers? If yes, use custom training; if not yet, revisit the problem or prototype with AutoML first.

Worked example (synthetic). A bank wants to read cheque amounts. A ready-made optical character recognition model already does that, so the flow stops at the first question — nobody trains anything.

The table shows the trade-offs; this figure shows the order in which to ask about them, and the order matters. Start at the cheapest end. Does a ready-made model already do this task? If it does, a pre-trained application programming interface (API) is the answer, because speed and effort both favour it and nothing about the task needs to be unique. If not, ask whether one of AutoML's predefined objectives fits, because Google is explicit that with AutoML you must target one of those objectives. If one fits, AutoML trains on your own data with minimal technical effort. Only if neither is true does custom training earn its cost — and it has a precondition, which is the last question: do you have the people? Google's machine learning overview says organizations often need programmers and data scientists to understand and utilize the training algorithms and their results. The fourth box is the honest one. Google also says AutoML can be used to quickly prototype models and explore new datasets before investing in development — so a team without the expertise yet is not stuck; it prototypes first.

Required expertise: who has to be in the room

The skill a team already has often decides the answer

Figure. Three columns naming who a team needs. Developers can call a pre-trained API such as Document AI without specialized machine learning expertise. SQL analysts can build and evaluate models with BigQuery ML using the SQL skills they already have. Custom training needs data scientists and programmers to develop the training application and prepare data.

Worked example (synthetic). A retailer's analytics team is fluent in SQL and its sales history already sits in BigQuery. The team it has is the argument for BigQuery ML over hiring for custom training.

Required expertise deserves its own figure, because in practice it is the trade-off that most often decides the answer. Google states the problem plainly on its BigQuery ML page: performing machine learning on large datasets usually requires extensive programming and knowledge of frameworks, and those requirements restrict solution development to a very small set of people within each company, excluding data analysts who understand the data but have limited machine learning knowledge. Google's products answer that at three levels. At the first, developers call a pre-trained service: Document AI, Google's artificial intelligence (AI) service for documents, for example, is built to create document processing applications without specialized machine learning expertise. At the second, analysts use what they already know: with BigQuery ML, structured query language (SQL) practitioners can use existing SQL tools and skills to build and evaluate models. At the third, custom training needs people who can develop the training application and handle data preparation. When an exam scenario tells you who is on the team, it is usually telling you the answer.

Matching the approach to the use case

Pre-trained for common tasks, AutoML for your data, custom for your edge

Pre-trained APIs: generalized image labels, sentiment, translation, documents
AutoML: your own labeled images or tables, toward a predefined objective
BigQuery ML: models from data already in BigQuery, in SQL
Custom training: an outcome no predefined objective or general model reaches

Worked example (synthetic). An insurer wants claim forms turned into database fields (pre-trained: Document AI), photos of damage sorted into its own severity grades (AutoML), and a fraud score built on its own loss metric (custom).

The second objective turns the trade-offs into use cases, and the product names in it carry four abbreviations worth expanding once: application programming interfaces (APIs), artificial intelligence (AI), machine learning (ML) and structured query language (SQL). Pre-trained APIs fit tasks many businesses share. The Vision API's label detection provides generalized labels for an image. The Natural Language API's sentiment analysis identifies the prevailing emotional opinion in text — whether a writer's attitude is positive, negative or neutral. Cloud Translation's Basic edition provides quick, plug-and-play access to a standard translation model. And Document AI takes unstructured data from documents and transforms it into structured data, specific fields suitable for a database. AutoML fits when the task is yours but its shape is standard. Google's own AutoML guide uses an architectural preservation board trying to identify neighbourhoods with a consistent architectural style from its own photographs — labels no general model knows — and a retailer predicting the behaviour of new customers, where traditional approaches don't do well with customers with little historical data. BigQuery ML fits when the data already lives in BigQuery: using SQL commands, you can quickly create a model and use it for batch inferences. Custom training fits the remaining case: an outcome no predefined objective reaches, where you need a training application optimized for your targeted outcome.

Seven use cases, and the approach each calls for

The words in the scenario point at the column

Use case	Approach	Why
Tag product photos with general labels	Pre-trained: Vision API	Generalized labels for an image
Gauge whether reviews are positive or negative	Pre-trained: Natural Language API	Sentiment analysis, ready to call
Turn scanned invoices into database fields	Pre-trained: Document AI	Unstructured documents to structured data
Sort your own photos into your own categories	AutoML	Your labels, a predefined objective, no code
Predict spend for customers with little history	AutoML	Learns from examples in your own table
Analysts want a model on data already in BigQuery	BigQuery ML	Built with SQL they already know
Optimize a metric of your own design	Custom training	Your own loss function or metric

Worked example (synthetic). An item says a museum wants its archive photos sorted by the curators' own period labels. "Its own labels" rules out the general Vision API model; AutoML is the graded answer.

Here is the mapping as the exam writes it, one use case per row — each a pre-trained application programming interface (API), an artificial intelligence (AI) service, AutoML, BigQuery machine learning (ML) using structured query language (SQL), or custom training. Tagging photos with general labels is the Vision API, which provides generalized labels for an image. Judging whether reviews are positive or negative is the Natural Language API's sentiment analysis. Turning scanned invoices into fields is Document AI — and the Vision API's own documentation points there, saying that if you are detecting text in scanned documents, you should try Document AI for optical character recognition, structured form parsing and entity extraction. The next two rows move to AutoML, and the word that moves them is own: your photos in your categories, or predictions from your own table, where you need a system that can learn from examples. The sixth row is BigQuery ML, because the data is already in BigQuery and the team speaks SQL. The last row is custom training, and the tell is a metric of your own design — Google says custom training lets you develop your own loss functions or metrics. Read the scenario for the word general, the word own, or the word unique, and the column follows.

Pre-trained is a starting point, not a ceiling

Each family has a customization rung before custom training

Figure. Three rungs from left to right. Use as-is: Cloud Translation Basic and ready-to-use prebuilt models. Customize: Cloud Translation Advanced customization and tunable foundation models. Build: custom training for tasks unique to your use case.

Worked example (synthetic). A legal publisher finds the standard translation model mistranslates its terminology. Customizing the translation model comes before building one from scratch.

One refinement keeps the second objective from being read too rigidly. Pre-trained does not mean frozen, and this is true across Google's machine learning (ML) products. Within one product family there is often a middle rung between using a model as-is and building your own. Cloud Translation shows the pattern. Its Basic edition provides quick, plug-and-play access to the standard translation model; its Advanced edition also supports customizations of its models. The same pattern holds for generative models: Google's Model Garden describes foundation models as pretrained multitask large models that can be tuned or customized for specific tasks, and the generative artificial intelligence (AI) guide gives the reason in one sentence — if you want a model to perform tasks that are unique to your use case, then you need to be able to customize the model. So when a scenario says the ready-made model is close but not quite right, the next answer is usually to customize it, not to jump straight to custom training. Model Garden itself is where that search starts: an AI and ML model library to discover, test, customize and deploy models from Google and Google partners.

What this topic actually tests

One trade, read in both directions

General task? pre-trained API. Your data, a standard objective, no coders? AutoML — or BigQuery ML if it is already in BigQuery. Your own objective or metric, and data scientists on hand? custom training. Speed and ease run one way; differentiation runs the other.

Close on the single trade this topic tests. Moving from pre-trained application programming interfaces (APIs) through AutoML to custom training buys differentiation and costs speed, effort and expertise; moving back the other way buys speed and ease and gives up differentiation. The exam asks it in both directions. Given a use case, find the cheapest approach that reaches it: a general task is a pre-trained API; your own data toward a standard objective, with no machine learning (ML) coders, is AutoML, or BigQuery ML if the data already sits in BigQuery; your own objective or metric, with data scientists on the team, is custom training. Given a team and a deadline, work backwards to what they can build. And remember the middle rung — a pre-trained model that is close can often be customized before anything is built. Topic three goes one step further, into how these solutions are built and used responsibly.

Unit 3.2 study guide — Google Cloud’s AI and ML solutions