Task 4.2: Preparing data for AI and ML.

• ARegister the model in Agent Platform and serve it from an online endpoint

  Incorrect

  Serving from an endpoint changes where predictions run, but callers would still have to send already engineered features.

• BSave the feature SELECT as a view and ask callers to predict from it

  Incorrect

  A view helps only if every caller remembers to use it; the logic is still outside the model.

• CStore the engineered features in a table that callers must join to

  Incorrect

  A feature table covers rows that already exist, not new raw rows, and still depends on callers doing the right join.

• DMove the feature logic into the TRANSFORM clause of CREATE MODEL

  Correct

  Preprocessing in TRANSFORM is stored with the model and applied automatically by ML.EVALUATE and ML.PREDICT, so callers pass raw columns.

The TRANSFORM clause makes feature preprocessing part of the model. The same transformations then run automatically at evaluation and prediction time, which removes the gap between how features were built for training and how they are built when the model is used.

• AOne text embedding for each whole PDF, without splitting the text

  Incorrect

  Embedding models have input token limits, and one vector per manual cannot point retrieval at the relevant passage.

• BThe Document AI layout parser with its layout-aware chunking

  Correct

  The layout parser recognizes headings, tables and lists and produces chunks that carry their ancestor headings, which is what search and RAG pipelines need.

• CSensitive Data Protection to inspect and redact each PDF first

  Incorrect

  Redaction protects sensitive data but does nothing for the chunk structure that is failing here.

• DAn object table with AI.GENERATE_TEXT to summarize each PDF

  Incorrect

  Summaries throw away the detail that answers need, and do not fix how the content is chunked.

Retrieval quality depends on chunks that make sense on their own. The Document AI layout parser, built on OCR and Gemini, extracts document structure and produces semantically coherent chunks augmented with their headings, so a retrieved chunk still says which section and table it came from.

• ACreate a search index on the description column for SEARCH queries

  Incorrect

  Search indexes speed up token matching with SEARCH, which is keyword lookup rather than similarity of meaning.

• BGenerate embeddings for the descriptions with AI.GENERATE_EMBEDDING

  Correct

  AI.GENERATE_EMBEDDING calls an embedding model from SQL and stores a vector per description that captures its meaning.

• CCluster the table on the product category column

  Incorrect

  Clustering prunes by category value; it does not find descriptions with similar meaning.

• DCreate a vector index and query it with VECTOR_SEARCH

  Correct

  A vector index lets VECTOR_SEARCH find nearest neighbours approximately and quickly over millions of embeddings.

• EUse APPROX_TOP_COUNT over the description words for each product

  Incorrect

  Counting frequent words is still keyword statistics, not semantic similarity.

Semantic search in BigQuery has two parts: embeddings, generated in SQL with AI.GENERATE_EMBEDDING from a text embedding model, and vector search, where VECTOR_SEARCH finds the closest vectors and a vector index makes that fast at large scale.

• AA load job of the PDF files into a BYTES column of a native table

  Incorrect

  Loading the files as bytes stores them but extracts nothing from them.

• BA BigLake table over the bucket with a PDF file format option

  Incorrect

  BigLake tables read structured formats such as Parquet or CSV; scanned PDFs are unstructured data.

• CAn object table over the PDFs and ML.PROCESS_DOCUMENT with a Document AI processor

  Correct

  An object table exposes the files to SQL, and ML.PROCESS_DOCUMENT sends them through a Document AI processor via a remote model, returning the parsed fields.

• DSensitive Data Protection inspection jobs that list the forms' fields

  Incorrect

  Inspection finds sensitive information types; it does not extract a form's business fields into a table.

BigQuery can work on unstructured data: object tables describe the files in a bucket, and ML.PROCESS_DOCUMENT runs a Document AI processor over them through a remote model, returning structured results that SQL can use like any other column.

• ARegister the model in Model Registry and deploy it to an endpoint

  Correct

  Registered BigQuery ML models can be deployed from Model Registry to an Agent Platform endpoint for online prediction, with no serving container to build.

• BCall ML.PREDICT through the BigQuery API for each application

  Incorrect

  A BigQuery query per request carries job overhead and is not meant as a low-latency online serving path.

• CPrecompute scores for each possible applicant in a nightly batch

  Incorrect

  New applications are not known in advance, so their scores cannot be precomputed.

• DRetrain the model each hour so that it stays close to new data

  Incorrect

  Retraining frequency affects freshness, not how quickly a single prediction is returned.

BigQuery ML is strong for training and batch scoring next to the data. For online serving, a model registered in Model Registry, either at creation with the MODEL_REGISTRY option or later, can be deployed to an endpoint in Agent Platform and called with low latency.

• AA BigQuery table of documents queried with the SEARCH function

  Incorrect

  Keyword search returns matching rows but provides none of the RAG steps the team wants managed.

• BA fine-tuned Gemini model trained on the policy documents

  Incorrect

  Fine-tuning changes model behaviour; it does not ground answers in the current documents or cite them, and needs retraining as they change.

• CA Dataflow pipeline that embeds the files into Bigtable

  Incorrect

  This is the custom pipeline the team wants to avoid, and Bigtable would still need a retrieval layer on top.

• DRAG Engine on Agent Platform with a corpus built from both sources

  Correct

  RAG Engine ingests from Cloud Storage and Google Drive, parses, chunks, embeds and indexes the content into a corpus, and retrieves it to ground the model's answers.

RAG Engine is the managed path for retrieval-augmented generation: it handles ingestion, parsing, chunking, embedding, indexing into a corpus with a choice of vector stores, and retrieval for grounded generation.