Exam Room · AI Practitioner

Flash Card: Choosing a Foundation Model

· 1 min read

AI Fundamentals · part of The Exam Room

Scenarios rarely hand you one job. They hand you three features in one release, and the filters disagree about which model each one wants, which is worked through at length in the business-side weighing and again, at design time, in the per-feature selection. This card is the list itself, in the order that throws candidates out fastest. It starts after the prior question has already been answered: whether a generative model suits the job at all is settled in the read on where generative AI helps and where it hurts.

Flash card

Choosing a foundation model: a short list of filters run per feature rather than per product, where model types, constraints and compliance rule candidates out, and capabilities, context window, latency and cost rank what survives.

  1. Model types split the catalogue before anything else does. A text-generation model, an embedding model that turns text into vectors for search, an image-generation model and a model with multimodality (one that reads an image or audio and answers in text) are different products. Pick the wrong type and you have a model that cannot do the job at all, which no amount of prompting fixes.
  2. Capabilities and performance requirements are two questions. Capabilities ask whether the model can do this task; performance requirements ask how well it has to do it before the feature ships. Output a person reviews before it is sent has a lower bar than output that goes straight to a subscriber, and the lower bar is often what lets a smaller, cheaper model through.
  3. The context window is the total amount of text a model holds in one call, the prompt and the response together, counted in tokens. A job that feeds a two-hundred-page contract in one go needs a large window; a chat turn carrying a short instruction block does not, and a window you never fill is capability you are paying for and not using.
  4. Latency and cost usually move together with model complexity, so the larger model answers more slowly and costs more per token. That decides a live assistant with somebody watching a spinner and barely matters for an overnight batch, which is why two features in the same release often land on two different models.
  5. Constraints and compliance rule options out before any of the ranking happens: which regions the model is offered in, where the data is allowed to be processed, what the licence permits you to do with generated content, and which languages the model handles well. A multilingual product needs evidence of quality in every language it sells in, not just English.

Pick it when

Run these filters per feature, not once per product, and run the eliminating ones first: model types and modality, then constraints and compliance, then context window, then capabilities against the performance requirements, then latency and cost. Two of them settle what is possible; the rest sort what is left into an order.

It's the wrong answer when

This list does not settle whether generative AI suits the job at all, which is the prior question, and it does not settle how the chosen model is customised: prompting, retrieval over your own documents and fine-tuning are decisions taken after the shortlist exists. It also says nothing about a numeric prediction over your own tabular data, where a traditional machine-learning model is usually the better answer.

These posts are LLM-aided. Backbone, original writing, and structure by Craig. Research and editing by Craig + LLM. Proof-reading by Craig.