A first, simple picture before we open the details.

Machine learning, often shortened to ML, is a way of teaching computers by showing them examples instead of writing step-by-step rules. If you show a program thousands of photos labelled “cat” or “not cat,” it can learn to recognise cats in new photos. The learned result is called a model. Creating the model is called training, and using it on new data to get an answer is called a prediction or inference.

Traditionally, building a good model means many skilled decisions: how to clean the data, which learning method to use, how to set it up, how to test it. AutoML automates much of that decision making. In Google Cloud, AutoML lives inside Vertex AI, the platform where Google brings together data preparation, training, evaluation, deployment and monitoring for machine learning. You choose a type of problem, point to your data, and press train. The service explores options for you and returns a model that you can test and deploy.

A short history

Google introduced a family of “Cloud AutoML” products around 2018, such as AutoML Vision for images, AutoML Natural Language for text, AutoML Video Intelligence, AutoML Translation and AutoML Tables for spreadsheets of data. Later, Google gathered these under Vertex AI, which launched in 2021, so that data, training and serving share one set of tools. Over time, some separate legacy products were retired or merged, and the emphasis has moved toward Vertex AI features and newer foundation models. Because the lineup changes, treat the product list in this guide as a map of ideas and confirm the current list in the official documentation.

Why so many organisations want machine learning, and why so few get there.

Talent is scarce

Experienced machine learning engineers and data scientists are in high demand and hard to hire. A medium-sized company may have excellent software developers and analysts, yet nobody who has trained a neural network. Good ideas then wait in a queue for months.

Experimentation is slow

Even for experts, finding a good model involves trial and error: trying different algorithms, different settings, different ways of preparing columns. Each trial takes time and computing power. Doing this by hand across dozens of possibilities is tiring and easy to get wrong.

Results must be dependable

A model that works on a laptop demo is not the same as a model that serves real customers every day. Teams need version control, testing, scalable serving and monitoring. A platform that handles these chores lets smaller teams ship real products.

What people typically want to predict

The few ideas you need before anything else makes sense.

Features and labels

Imagine a spreadsheet about houses. Each row is one house. The columns that describe a house, such as size, number of rooms and neighbourhood, are called features. The column you want to predict, such as the price, is called the label or target. Training teaches the model how features relate to the label.

Supervised learning

When training examples come with the right answers attached, the method is called supervised learning. Almost all AutoML works this way. It is like studying with an answer key: the model guesses, compares with the key, and improves.

Classification, regression and forecasting

Training, validation and test data

We never judge a student only on questions they already saw. In machine learning we split the data into three groups. The training set is what the model learns from. The validation set is used while training to tune choices. The test set is kept hidden until the end and used for an honest final score. AutoML can split the data automatically, or you can control the split.

Overfitting and underfitting

Overfitting happens when a model memorises the training examples, including their accidents and noise, so it does well on old data but badly on new data. Underfitting is the opposite: the model is too simple to learn the real pattern. Good training finds the middle ground.

Hyperparameters and architecture

Models have settings chosen before training starts, such as how fast to learn or how many layers a neural network has. These are called hyperparameters. The overall design of the model is its architecture. Choosing these well is a big part of what makes ML hard, and it is exactly the part AutoML searches through for you.

A look at the chores the service takes off your plate.

flowchart LR
  D["Your labelled data"] --> P["Automatic data preparation"]
  P --> F["Feature handling"]
  F --> S["Search for model design and settings"]
  S --> T["Train many candidates"]
  T --> E["Evaluate on held-out data"]
  E --> B["Select best model"]
  B --> M["Your trained model"]
    

Reading the diagram

On the left is your data. The service first prepares it, for example by converting text-like columns into numbers and filling in gaps. Next it handles features, for instance by creating combinations or scaling values. Then it searches through possible designs and settings, trains a number of candidates, tests them on data they did not train on, and keeps the best. The result on the right is a model you can inspect and deploy.

The main jobs automated

• Data preparation: detecting column types, handling missing values and splitting data.
• Feature engineering: transforming raw columns into forms models learn from more easily.
• Model selection: trying different families of models, such as decision trees and neural networks.
• Hyperparameter tuning: trying many settings to find a good combination.
• Architecture search: for some data types, exploring neural network designs.
• Ensembling: combining several good models into one stronger answer.
• Evaluation: computing standard scores so you can judge quality.

Techniques you may hear about

Transfer learning starts from a model that has already learned general skills on huge public datasets, such as recognising edges, shapes and common objects, and then adjusts it to your small dataset. This is why image AutoML can work with hundreds of pictures rather than millions. Neural architecture search uses automated experiments to find a good network design. Google has published research on both ideas, and they underpin parts of its AutoML offerings. Exactly which methods run under the hood is not something you configure, and it can change as the service improves.

How AutoML fits among the other ways of building models on Google Cloud.

Vertex AI offers several routes to a working model. They differ mainly in how much you control and how much the platform does for you.

flowchart TD
  G["Need an AI capability"] --> Q1{"Is a ready-made API enough?"}
  Q1 -->|"Yes"| API["Pre-trained APIs: vision, speech, language, translation"]
  Q1 -->|"No"| Q2{"Do you have your own labelled data?"}
  Q2 -->|"Yes, little ML skill"| AML["AutoML"]
  Q2 -->|"Yes, need full control"| CT["Custom training with your own code"]
  Q2 -->|"Language or content task"| FM["Foundation models: prompt, tune, ground"]
  AML --> VA["Vertex AI: register, deploy, monitor"]
  CT --> VA
  FM --> VA
    

The four routes explained

What Vertex AI adds around AutoML

• Datasets: managed collections of your data, with labels and statistics.
• Training pipelines: tracked jobs that run the automated search.
• Model Registry: a catalogue where trained models are stored with versions.
• Endpoints: hosted addresses for real-time predictions.
• Batch prediction: scoring large files without a live server.
• Explainable AI: showing which inputs influenced a prediction.
• Model Monitoring: watching live data and predictions for trouble.

The most common business use: learning from spreadsheet-like data.

Tabular data means rows and columns, like a spreadsheet or a database table. Customer records, sales transactions, sensor readings and loan applications are all tabular. It is the data type most companies hold in the largest amounts, and AutoML for tabular data is often the quickest route to real value.

What you can predict

• Classification: choose a category column as the target, such as “churned: yes or no” or “product tier.”
• Regression: choose a number column, such as order value or time to deliver.
• Forecasting: predict values across time, covered in its own chapter.

Where the data comes from

You can supply data from BigQuery, Google’s data warehouse, or from CSV files in Cloud Storage, Google’s file storage service. Each row is an example, each column a feature, and one column is the target. Having a few thousand rows is a common minimum, and more is better, though exact minimum requirements are listed in the documentation and can change.

What the service does for you

Feature importance

After training, you can see which columns influenced the model most. If “number of support complaints” is far more important than “customer age,” that is a business insight in itself. It also helps you spot suspicious columns, for example a column that secretly contains the answer.

Teaching a model to see what matters in your pictures.

AutoML for images lets you train a model on your own photos for tasks the general vision APIs do not cover well. Typical tasks are:

• Image classification: assign a label to a whole picture, such as “healthy leaf” or “diseased leaf.” It can be single-label, where each image has one answer, or multi-label, where an image can have several.
• Object detection: find objects and draw a box around each, with a label, such as every pallet on a warehouse shelf.
• Image segmentation: mark exactly which pixels belong to each object. Availability of this task in AutoML has varied, so check the current list.

How much data is needed

Thanks to transfer learning, image models can learn from surprisingly few examples, often in the hundreds per label, though more varied examples give better results. Guidance in the documentation suggests minimum numbers per label; read the current numbers before starting.

Good photos make good models

Cloud models and edge models

Image models can sometimes be trained in a form that is small enough to run on a phone, a camera or an industrial device, without a network connection. This is called an edge model, because it runs at the “edge” of the network, close to where data is created. Edge models respond instantly and keep images private on the device, but are usually a little less accurate than larger cloud-hosted models. The exported formats and supported devices vary, so verify them in the documentation.

Teaching a model to read your words, and where newer tools now compete.

Text AutoML was designed for tasks such as:

• Text classification: assign topics or categories to documents, such as routing support tickets to the right team.
• Sentiment analysis: judge whether text is positive, negative or neutral.
• Entity extraction: find and label items in text, such as people, products, dates or medical terms.

You prepare a collection of example texts with their correct labels, or with highlighted spans for entities. AutoML then learns from them. It works best when your categories are specific to your business and the general language APIs would not know them.

A changing landscape

Large language models, such as Gemini, can now classify, summarise and extract information from text using only instructions and a few examples, often with no training at all. For many text tasks, prompting a foundation model is faster to start than collecting a large labelled dataset. Google has also adjusted which dedicated text AutoML features it emphasises. When you face a new text problem, compare the options:

Understanding moving pictures with your own examples.

Video adds time to images. AutoML for video has supported tasks such as:

• Video classification: label an entire clip or segments of it, for example “goal scored” or “safety violation.”
• Object tracking: follow an object across frames, such as a forklift moving through a warehouse.
• Action recognition: identify activities, like “person falls” or “package handed over.”

Video datasets are heavy: the files are large, labelling takes much time, and training costs more than for still images. The reward is understanding events that a single photograph cannot show.

Practical advice

• Cut long recordings into short, well-defined clips before labelling.
• Label the moments that matter, not every second.
• Collect examples across different cameras, lighting and times of day.
• Consider whether sampling still frames and using image models may be enough and far cheaper.
• Check current availability, since video-related offerings have changed over time, and Google also offers other video intelligence tools.

Time-based predictions for demand, traffic, energy and more.

A time series is a set of values recorded over time, such as daily sales or hourly electricity use. Forecasting predicts future values. It is harder than ordinary prediction because time order matters: you must never let the model peek at the future while learning about the past.

The ingredients

Two settings that matter

The context window says how much past history the model may look at for each prediction. The forecast horizon says how far into the future to predict. Longer horizons are less certain, just as a weather forecast for next week is less reliable than for tomorrow.

Time-aware testing

Evaluation must hold out the most recent period for testing, never random rows. Otherwise the model learns from the future and its scores will be unrealistically good. Forecast quality is typically measured with errors such as average absolute error or percentage error, and sometimes with ranges that express uncertainty.

Models are only as good as the examples they learn from.

flowchart LR
  A["Define the question"] --> B["Collect data"]
  B --> C["Clean and check"]
  C --> D["Label"]
  D --> E["Split into train, validate, test"]
  E --> F["Import into a Vertex AI dataset"]
  F --> G{"Statistics look sensible?"}
  G -->|"No"| C
  G -->|"Yes"| H["Ready to train"]
    

Start with the question

Write one clear sentence: “Predict whether a customer will cancel within 30 days of the invoice date, using information known at invoice time.” A precise question tells you which rows and columns belong and which would be cheating.

Cleaning checklist

• Remove duplicates so the same example is not counted many times.
• Fix obvious errors such as impossible ages or dates in the future.
• Handle missing values thoughtfully. Sometimes blank itself is informative.
• Check for leakage by questioning every column: would this be known at prediction time?
• Watch for bias in who is represented in the data and who is left out.
• Keep a record of where the data came from and when it was extracted.

How much is enough?

There is no universal number. Simple patterns need less data, and subtle patterns need more. Rare events need special attention: if only one transaction in a thousand is fraud, a dataset of ten thousand rows contains only about ten fraud examples. In that case collect more fraud cases or use techniques such as weighting to give them importance.

Choosing a split

How the answer key is created for images, text and video.

For tabular data the label is usually already in a column. For images, text and video, someone must mark the correct answer on each example. This is labelling or annotation, and it is often the biggest cost of a project.

Ways to label

• Folder or file names: put cat photos in a cat folder and prepare an import file listing paths and labels.
• Import files: prepare a structured file, commonly in CSV or a line-based JSON format, mapping each item to its labels.
• Console labelling tools: label items by hand in the Google Cloud console, such as drawing boxes on images.
• Labelling services: Google has offered human labelling services where specialists label data against your instructions. Check whether these remain available.
• Your own team or partners: subject experts for medical or legal data.

Labelling instructions

Write clear instructions with examples of each label, including borderline cases. Decide in advance what to do with unclear items. Measure agreement by having two people label the same sample; if they often disagree, the instructions are unclear, or the task is genuinely ambiguous.

What actually happens from clicking Train to receiving a model.

sequenceDiagram
  participant U as You
  participant V as Vertex AI
  participant S as Data Source
  participant W as AutoML Workers
  U->>V: Create dataset and choose data type
  V->>S: Read and profile data
  S-->>V: Rows, files and labels
  U->>V: Start training with target, budget and options
  V->>W: Launch automated search and training
  W-->>V: Candidate models and scores
  V-->>U: Best model with evaluation results
    

The steps

Budget advice

• Run a small, cheap first experiment to confirm the data is usable.
• Increase the budget only if the first results show promise and the data is solid.
• Use early stopping where offered to avoid paying for training that no longer improves.
• Keep notes on each run: data version, settings, budget and results.

Scores and pictures that tell you how far to trust the model.

Classification measures

For classification, start with a confusion matrix, a small table that shows how often the model mixed up each pair of classes. Then consider these ideas:

The threshold

A classifier usually gives a confidence score between zero and one. You decide the threshold above which you treat the answer as “yes.” Lowering it finds more real cases but also raises false alarms; raising it does the opposite. Vertex AI shows how precision and recall change as the threshold moves, so you can choose a value matched to the business cost.

Regression and forecasting measures

Beyond one number

• Look at slices: check performance for different customer groups, regions or image types. An average can hide a group the model treats badly.
• Compare with a simple baseline: if “always predict the average” is nearly as good, the model adds little.
• Read the mistakes: view the wrongly classified examples. They often reveal label errors.
• Test with fresh data: try recent, real examples that played no part in training.

Understanding why the model answers as it does, and using it fairly.

A model that cannot explain itself is hard to trust. Explainable AI features in Vertex AI show which inputs most influenced a prediction. For tabular models, you can see overall feature importance and also the contribution of each feature to an individual prediction. For image models, highlight maps (sometimes called saliency maps) show which regions of the picture mattered.

Why it matters

• Debugging: an image model that focuses on a watermark rather than the object has learned a shortcut.
• Trust: users and regulators often require reasons for decisions.
• Fairness checks: reveals whether a sensitive attribute, or a stand-in for it, drives results.
• Learning: guides data collection and business improvements.

Responsible use

Models inherit patterns in the data, including past unfairness. A hiring model trained on past hiring decisions may repeat past bias. Good practice includes reviewing data for balance, testing results across groups, keeping a human in the loop for important decisions, documenting what the model is for and not for, and giving people a way to appeal automated decisions. Google publishes AI principles and tooling guidance; read them and involve legal and ethics colleagues for sensitive uses.

Turning a trained model into something your application can use.

flowchart TD
  M["Trained model in Model Registry"] --> Q{"How are predictions needed?"}
  Q -->|"Instantly, one at a time"| EP["Deploy to an endpoint: online prediction"]
  Q -->|"Large files, not urgent"| BP["Batch prediction job"]
  Q -->|"On a device without network"| ED["Export edge model if supported"]
  EP --> APP["Application sends request, gets answer"]
  BP --> OUT["Results written to Cloud Storage or BigQuery"]
  ED --> DEV["Phone, camera or gateway"]
    

Online prediction

You deploy the model to an endpoint, which is a stable address backed by computing machines that keep the model loaded and ready. Your application sends the input and receives the prediction in milliseconds to seconds. You choose the machine size and minimum and maximum number of machines, and the service can add machines when traffic grows. Because machines run continuously, online endpoints incur charges while deployed, even during quiet hours.

Batch prediction

For a nightly list of customers to score, or a folder of photos to classify, batch prediction is better. You give the service a file or table and an output location. It starts machines, processes everything, saves the results and shuts down. You pay for the work, not for idle waiting.

Choosing machine settings

• Start small and measure response time under realistic traffic.
• Set minimum machines to one only if you can tolerate slower first responses after quiet periods; otherwise keep warm capacity.
• Set a maximum to protect against surprise bills during traffic spikes or attacks.
• Use traffic splitting to send a small share of requests to a new model version before switching fully.

Model versions and safe rollout

Keep every trained model in the Model Registry with notes. When a new version is ready, deploy it beside the old one, send ten percent of traffic, compare results and then increase the share. If problems appear, move traffic back instantly. This is called a canary rollout, named after the canary once used to detect danger in mines.

Where models fit into data and application workflows.

BigQuery ML in a sentence

BigQuery ML lets people who know SQL create and use models without leaving the data warehouse. It offers many model types, and for some it can call AutoML-based training behind the scenes. This is attractive when your data already lives in BigQuery and your team is strong in SQL. Check the current list of supported model types and their billing.

flowchart LR
  BQ["BigQuery tables"] --> DS["Vertex AI dataset"]
  DS --> TR["AutoML training"]
  TR --> MR["Model Registry"]
  MR --> EP["Endpoint"]
  MR --> BJ["Batch prediction"]
  EP --> APP["Business application"]
  BJ --> BQ2["Results back in BigQuery"]
  BQ2 --> DASH["Dashboards"]
    

Training data is often sensitive, so treat the whole pipeline with care.

Access control

IAM, Google Cloud’s identity and access management, decides who can create datasets, run training, view models or call endpoints. Give people and service accounts (identities for programs) only the roles they need. Separate duties: the person who labels data need not be able to deploy models.

Protecting data

• Encryption: data in transit and at rest is encrypted by default; customer-managed keys are available for many resources if your policy requires them.
• Location: choose the region where datasets, training and endpoints live, to meet residency rules. Some features exist only in certain regions.
• Network controls: private connectivity and perimeter controls such as VPC Service Controls can keep traffic inside defined boundaries. Confirm current support for each feature.
• Sensitive columns: remove or mask personal data that the model does not need, using data loss prevention tools where suitable.
• Training data use: read Google’s terms about how your data is handled for training and whether it is used to improve products.

Governance habits

• Lineage: record which data produced which model version.
• Approval steps: require review before a model serves real customers.
• Audit logs: review who trained, deployed or called models.
• Retention: delete training data and models you no longer need, in line with policy.
• Endpoint protection: prediction endpoints should require authentication and be shielded from direct public exposure where possible.

A model is a living thing: the world changes and models must keep up.

After deployment, the real world does not stand still. Customers change habits, cameras are replaced, prices shift, and a pandemic or new competitor can upset every pattern. When the live data no longer resembles the training data, predictions quietly get worse. This is called drift.

flowchart LR
  L["Live traffic to endpoint"] --> MON["Model Monitoring compares to training data"]
  MON --> A{"Drift above threshold?"}
  A -->|"No"| OK["Keep serving"]
  A -->|"Yes"| AL["Alert the team"]
  AL --> RT["Collect fresh labelled data and retrain"]
  RT --> EV["Evaluate against current model"]
  EV --> DP["Canary rollout of new version"]
  DP --> L
    

What to track

• Technical health: request counts, errors and response time in Cloud Monitoring.
• Data health: distribution of inputs compared with training data.
• Prediction health: distribution of outputs and confidence.
• Business outcomes: when true results arrive later, compare them with predictions to compute real accuracy.
• Costs: machine hours and prediction counts.

Retraining rhythm

Some models need monthly retraining; others hold for a year. Choose between a calendar schedule, such as every month, and an event trigger, such as when drift alerts fire. Automate the pipeline so retraining is routine, but always evaluate a candidate against the current model before replacing it.

Where the money goes, and how to keep it under control.

The exact rates vary by data type, region and feature, and they change, so use the official pricing page and calculator for numbers. What stays constant are the habits that keep bills sensible.

When automatic is wise, and when you should take the wheel.

flowchart TD
  S["New prediction problem"] --> A{"Data mostly rows and columns?"}
  A -->|"Yes"| B{"Data already in BigQuery and team knows SQL?"}
  B -->|"Yes"| BQ["BigQuery ML, possibly AutoML-based"]
  B -->|"No"| TAB["Vertex AI tabular AutoML"]
  A -->|"No"| C{"Language or generation task?"}
  C -->|"Yes"| FM["Try a foundation model first"]
  C -->|"No"| D{"Need a special design or research control?"}
  D -->|"Yes"| CT["Custom training"]
  D -->|"No"| IMG["AutoML for images or video, or a pre-trained API"]
    

Choose AutoML when

• You have labelled data but few ML specialists.
• You need a working model quickly, to prove value.
• The problem fits a standard type such as classification, regression or detection.
• A solid baseline is more important than squeezing out the last fraction of accuracy.

Choose custom training when

• You need a particular architecture, loss function or training trick.
• You must own and move the model anywhere, with exact reproducibility.
• The data type or objective is unusual and not supported.
• Your team has the skill and wants the last bit of performance.

Following a made-up subscription company through a whole AutoML project.

“StreamNest” is an imaginary video subscription service. Management wants to know which customers are likely to cancel next month so the retention team can offer help or discounts. They have a BigQuery table with two years of customer history. Here is how the project unfolds.

An honest balance sheet before you commit.

Key trade-offs

Habits that help, and habits that hurt.

Helpful patterns

Anti-patterns to avoid

A checklist for your first project.

Best practices

• Define the business question and success measure before touching data.
• Invest more time in data quality than in tuning settings.
• Keep a clean, untouched test set and use it only for the final judgement.
• Use time-based splits for anything involving time.
• Look at errors and slices, not only the headline score.
• Start with small budgets, scale up only when results justify it.
• Use batch prediction unless you truly need instant answers.
• Document each model with a short card, owner and version.
• Monitor from the first day, and plan retraining.
• Confirm limits, supported features and prices in current documentation.

Common mistakes

• Expecting AutoML to fix poor or tiny datasets.
• Using different feature preparation for training and serving.
• Splitting related rows randomly so near-duplicates sit in both train and test.
• Forgetting that labels may be wrong, outdated or inconsistent.
• Chasing tiny score gains while ignoring business impact.
• Skipping a pilot and going straight to full rollout.

Troubleshooting guide

Illustrative scenarios showing how organisations typically use AutoML.

The practical boundaries every real project meets.

Every cloud service has limits, and AutoML is no exception. A quota is a cap on how much of a resource your project may use in a given period, such as the number of training jobs running at once, the number of prediction requests per minute, or the total size of a dataset. Quotas protect the shared platform and also protect you from runaway bills. Many can be raised by request, but approvals take time, so ask before a launch rather than on launch day.

Limits to check before you start

• Dataset size and format: maximum rows, columns, file sizes and image dimensions for each data type.
• Minimum examples: smallest number of examples overall and per label.
• Training time: maximum budget and run duration.
• Prediction limits: request size, requests per minute and maximum rows in a batch.
• Regional availability: which regions support each training and serving feature.

Building a reliable prediction service

A gentle plan for a team that is new to all of this.

Questions to ask before you begin

• What decision will change because of this prediction, and who will act on it?
• What does a wrong prediction cost, in each direction?
• Is the data available at the moment of prediction, and is it legal and ethical to use?
• How will we know, months later, whether the model is still working?
• Who will look after it when the original builders move on?

Quick definitions of the words used in this guide.

Not to train a model. You can work in the console. Programming helps for automation, pipelines and calling the model from applications.

It depends on the problem. Tables usually want thousands of rows; image models can start with hundreds of examples per label. Check the documented minimums, then test whether more data improves results.

Often it matches a competent hand-built baseline quickly, but a skilled expert with time and domain insight can usually improve on it. Many teams use both: AutoML for the baseline, experts for the hard problems.

For some types, such as certain image models, export options exist. For others, the model is usable only through Vertex AI. Verify the current options for your type.

For tabular prediction and many vision problems, yes. For text tasks, try a foundation model first because it may need no training data. Often the two are combined in one system.

Small tables can finish within an hour or so; image and video jobs can take many hours. The budget you set and the data size drive the time.

Evaluate results for different groups, review the data for gaps, use explainability tools, document limits and keep human oversight for important decisions.

AutoML in Vertex AI is a managed training service with its own console and pipeline. BigQuery ML lets you build models with SQL inside the warehouse, and can use automated options for some model types. Choose by where your data and skills are.

When monitoring shows drift or accuracy falling, or on a schedule that suits how fast your world changes, such as monthly or quarterly.

You pay for training compute, for deployed endpoints or batch jobs, and for storage. Use the official pricing page and calculator for current numbers.

Read Google Cloud’s current data processing terms for your service. In general, customer data stays under your control, but confirm the exact commitments for your contract and feature.

The whole guide in one short page.

AutoML in Google Cloud lets people with data and domain knowledge, but without deep machine learning expertise, build useful models. You supply good, labelled examples and a clear question; the service searches for the best model, reports how good it is and helps you deploy it, explain it and monitor it. The real work shifts to defining the problem, preparing honest data, judging results with the right measures, and caring for the model after launch.