awesomechecklists
llms.txtGitHub ↗
/

05 — AI Model Selection and Benchmarking Checklist#

Choose AI models against the actual application workload, operating constraints, safety requirements, and measurable outcomes. Public leaderboards help identify candidates but do not prove suitability, compliance, or reliability for a particular deployment.

Scope: AI-specific. This file is one part of the 05_AI_Model_Selection_and_Benchmarking.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

  • Project / product:
  • Release / version / environment:
  • Scope and applicable jurisdictions / markets:
  • Intended task / affected users / impact level:
  • Candidate models, providers, and exact versions:
  • Benchmark datasets, scoring framework, and review owner:
  • Cost, latency, privacy, safety, and quality budgets:
  • Reviewer / owner:
  • Review date:
  • Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

  1. Copy the shared template to project-specific evaluation records; keep all repository checkboxes unchecked.
  2. Establish requirements, disqualifying risks, and acceptance thresholds before comparing model scores. Mark [x] only when verified through model documentation, reproducible benchmark results, human evaluation, provider review, or representative application tests.
  3. Record evidence, failures, candidate exclusions, accepted risks, and justified N/A outside this shared template, keyed by MODELS ID. Do not add evidence tables or real customer data to the repository.
  4. Compare candidates under equivalent workloads and document version, benchmark data, prompts, sampling, scoring, hosting, and resource settings. Adjust for measurable differences in real API/application behavior.
  5. Complete ## API Checks and ## Frontend Checks where those interfaces exist. For non-interactive, offline, or non-API deployments, document what does not apply in project records.
  6. Route deeper prompt, RAG, agent, red-team, fine-tuning, monitoring, model-card, and inference reviews to the dedicated AI files. Re-run selection when models, tasks, providers, risk profiles, prices, or serving conditions materially change.

Use-case fit and constraints#

  • MODELS-001 Define the exact model-supported task, target users, expected outcomes, and whether AI adds measurable value over a deterministic approach.
  • MODELS-002 Identify critical workflows where incorrect, delayed, biased, or missing model output could materially harm users.
  • MODELS-003 Specify supported languages, scripts, regions, modalities, input formats, and output formats required by the product.
  • MODELS-004 Describe task-specific quality criteria such as factuality, instruction following, extraction accuracy, recall, or answer usefulness.
  • MODELS-005 Document unacceptable failures and safe abstention, escalation, or fallback conditions before choosing candidates.
  • MODELS-006 Define model input context requirements, typical and worst-case prompt sizes, and output length limits.
  • MODELS-007 Measure representative input/output size distributions rather than selecting a model based only on its advertised context window.
  • MODELS-008 Identify tool calling, constrained output, streaming, multimodal, batch, and structured response capabilities required for the integration.
  • MODELS-009 Record target throughput, concurrency, p95/p99 latency, time-to-first-output, and completion-time budgets as applicable.
  • MODELS-010 Specify per-request and monthly cost constraints, including input/output tokens, provider charges, infrastructure, and storage.
  • MODELS-011 Define uptime, data residency, processing location, privacy, retention, and network dependency requirements.
  • MODELS-012 Review candidate licensing, redistribution, usage restrictions, and relevant commercial terms before evaluation.
  • MODELS-013 Evaluate whether hosted APIs, self-hosting, or hybrid deployment fit the team's security, reliability, and operational capacity.
  • MODELS-014 Check hardware compatibility, available accelerator memory, model size, quantization support, and inference runtime constraints.
  • MODELS-015 Identify training-data or model provenance gaps that could affect legally permitted use or output reliability.
  • MODELS-016 Assess the allowed uses of supplied personal, confidential, copyrighted, or regulated content for each candidate provider.
  • MODELS-017 Specify observability, version pinning, audit requirements, and ability to reproduce or investigate model behavior.
  • MODELS-018 Document what happens if the candidate is deprecated, replaced, unavailable, or materially changed by its provider.
  • MODELS-019 Include human review and non-AI escalation requirements for consequential decisions or autonomous external actions.
  • MODELS-020 Assign accountable product, engineering, risk, and evaluation owners to the selection criteria.
  • MODELS-021 Record the initial acceptance thresholds and mandatory exclusions before reviewing benchmark rankings.
  • MODELS-022 Revisit requirements when audience, task, input distribution, external integrations, or market obligations change.

Candidate comparison and baseline#

  • MODELS-023 Create a shortlist with exact model name, provider, model/checkpoint revision, license, deployment location, and evaluation date.
  • MODELS-024 Include the existing production model and a simpler or non-model baseline where practical.
  • MODELS-025 Choose candidates based on mandatory capabilities before optimizing for public leaderboard placement.
  • MODELS-026 Read candidate model cards and system documentation for intended uses, limitations, safety notes, and provenance.
  • MODELS-027 Check vendor claims against test conditions, workload distribution, and evidence supplied with each benchmark.
  • MODELS-028 Compare variants with the same task definition and equivalent retrieval, tools, and workflow context wherever possible.
  • MODELS-029 Use the same evaluation examples and scoring logic for all candidates; document any justified exceptions.
  • MODELS-030 Control prompt templates, message roles, system policies, few-shot examples, and tool access during baseline comparisons.
  • MODELS-031 Record decoding settings such as temperature, top-p, seed support, maximum outputs, and stop conditions for every run.
  • MODELS-032 Differentiate base, instruction-tuned, fine-tuned, quantized, distilled, and reasoning-oriented model variants.
  • MODELS-033 Check candidate context-window behavior on representative long and short inputs, not only advertised maximum limits.
  • MODELS-034 Test refusal, abstention, and uncertainty behavior on ambiguous or unsupported questions.
  • MODELS-035 Assess hallucination or unsupported assertion rates in tasks expecting evidence-grounded factual outputs.
  • MODELS-036 Measure task-relevant robustness to typos, formatting changes, distractors, and long-tail inputs.
  • MODELS-037 Run safety and policy probes proportionate to the product's foreseeable risk rather than relying on general safety claims.
  • MODELS-038 Compare subgroup and language-specific outcomes when those groups and characteristics are justified by the deployment context.
  • MODELS-039 Compare output-schema adherence, tool-call argument validity, and retry needs if structured outputs or tools are required.
  • MODELS-040 Measure time-to-first-token, completion latency, throughput, and errors at representative concurrency.
  • MODELS-041 Calculate normalized cost per successful task, not solely advertised price per token or per inference.
  • MODELS-042 Record output lengths and reasoning-token or other hidden billable usage when the provider exposes those values.
  • MODELS-043 Assess response variability and repeatability across multiple samples for non-deterministic tasks.
  • MODELS-044 Check how each candidate handles provider rate limits, regional restrictions, and transient unavailable states.
  • MODELS-045 Document functional features that do not work for a candidate rather than treating them as zero-cost alternatives.
  • MODELS-046 Compare quality, safety, latency, availability, operating effort, and cost as a multi-criteria decision, not a single composite score without rationale.

Benchmark datasets and methodology#

  • MODELS-047 Define the evaluation population and usage scenarios from real product tasks, authorized research, or representative synthetic examples.
  • MODELS-048 Split development/tuning examples from a final held-out selection set and restrict access to the held-out set.
  • MODELS-049 Document each benchmark dataset's origin, version, license, sensitivity, allowed use, and known representativeness limits.
  • MODELS-050 Check for train/test overlap, answer leakage, duplicate examples, and exposure of hidden answers during prompt iteration.
  • MODELS-051 Include typical, edge-case, high-risk, low-resource-language, and adverse inputs in proportions suited to deployment risk.
  • MODELS-052 Define correct or acceptable outcomes and rationale before running candidate comparisons.
  • MODELS-053 Choose task-appropriate metrics with known failure modes rather than relying on an arbitrary aggregate accuracy number.
  • MODELS-054 Measure false positives and false negatives separately where their real-world consequences differ.
  • MODELS-055 Use reference-free or human assessment where a single exact answer is inappropriate for creative or open-ended tasks.
  • MODELS-056 Write clear human-grading rubrics for factual support, completeness, helpfulness, safety, and formatting where relevant.
  • MODELS-057 Train or calibrate human reviewers and check disagreement/adjudication on a representative subset.
  • MODELS-058 Blind evaluators to candidate identity and randomize answer presentation where feasible to reduce preference bias.
  • MODELS-059 Validate model-based judges against qualified human ratings before trusting automated scores.
  • MODELS-060 Assess evaluator or judge position bias, verbosity bias, leakage, and self-preference where applicable.
  • MODELS-061 Specify score aggregation, weighting, treatment of missing results, and category-level reporting before reviewing outcomes.
  • MODELS-062 Report sample size, confidence intervals or other uncertainty estimates, and the frequency of severe failures where appropriate.
  • MODELS-063 Repeat stochastic benchmarks enough times to describe variability and distinguish small differences from noise.
  • MODELS-064 Record model revisions, evaluation-harness version, benchmark configurations, prompt formats, and seeds or supported reproducibility controls.
  • MODELS-065 Preserve input IDs, sanitized outputs, scoring artifacts, and error cases under the project's data-retention and access policy.
  • MODELS-066 Verify evaluation scripts and prompt/answer extraction on small known-correct fixtures before scaling runs.
  • MODELS-067 Track benchmark cost and rate limits and exclude unauthorized or sensitive data from third-party evaluation endpoints.
  • MODELS-068 Compare benchmark run settings against real production settings, including context management, retrieval, guardrails, and tool access.
  • MODELS-069 Run offline task tests and end-to-end application tests separately so model quality is not confused with system quality.
  • MODELS-070 Include workload-specific adversarial and harmful-output checks with severity-weighted acceptance criteria.
  • MODELS-071 Measure latency, time-to-first-output, throughput, and resource usage using representative concurrent load.
  • MODELS-072 Test quality changes from quantization, caching, model routing, streaming, or inference optimizations where used.
  • MODELS-073 Flag invalid benchmark runs caused by truncation, provider errors, judge failures, incorrect answer parsing, or timeouts.
  • MODELS-074 Publish enough methodology, limitations, and reproducible configuration for an independent reviewer to interpret candidate differences.

Selection and decision records#

  • MODELS-075 Summarize each candidate's scores by critical task and risk category alongside benchmark uncertainty and sample sizes.
  • MODELS-076 Preserve raw task-level results and severe failure examples in approved restricted review records.
  • MODELS-077 Document disqualifying safety, accuracy, policy, license, data processing, or availability failures separately from averaged scores.
  • MODELS-078 Use agreed decision criteria and show the trade-offs between quality, latency, cost, privacy, reliability, and operational burden.
  • MODELS-079 Check that no hidden metric weighting or selective benchmark subset reverses the documented decision without explanation.
  • MODELS-080 Identify contexts where the selected model underperforms and define fallback, abstention, or human-review behavior.
  • MODELS-081 Record permitted model uses, unsupported scenarios, and the conditions under which performance claims cease to apply.
  • MODELS-082 Define the production model identifier and how the exact artifact or provider revision will be pinned or detected.
  • MODELS-083 Document required provider approvals, contracts, data-processing decisions, and audit/documentation dependencies.
  • MODELS-084 Estimate ongoing cost for expected and higher-load scenarios, including token distribution, batching, hosting, and failures.
  • MODELS-085 Plan cold starts, scaling, concurrency limits, throttling, provider quotas, and operational monitoring for the chosen deployment mode.
  • MODELS-086 Agree a staged rollout with measurable task-quality, latency, error, safety, and business guardrails.
  • MODELS-087 Define what observed failures trigger automatic downgrade, manual rollback, provider switch, or feature disablement.
  • MODELS-088 Test a fallback model or non-model experience for compatibility with the same interface and safety requirements where required.
  • MODELS-089 Define a reevaluation schedule and triggers for vendor model updates, drift, major user changes, or changed regulations.
  • MODELS-090 Create a versioned decision record with approvers, risk acceptances, model and dataset versions, and review date.
  • MODELS-091 Ensure stakeholders can inspect the selection evidence without accessing restricted personal data or proprietary test cases.
  • MODELS-092 Link the model-selection decision to AI governance, evaluation/regression, model-card, serving, and monitoring owners.
  • MODELS-093 Record where public leaderboards are inapplicable because their tasks, versions, hardware, or prompts differ from deployment.
  • MODELS-094 Require fresh approval when switching model families, vendors, training data policy, modalities, or external action capabilities.

Release gate#

  • Intended use, stakeholder impact, mandatory capabilities, and measurable quality/safety, latency, cost, and data-handling requirements are approved.
  • A relevant baseline and candidate shortlist were tested on representative and held-out workloads using documented, reproducible evaluation settings.
  • Task quality, severe failure rates, robustness, relevant group/language performance, and uncertainty meet predeclared acceptance rules or have approved mitigations.
  • Realistic serving measurements show acceptable latency, throughput, availability, resource use, and cost per successful user task.
  • Provider terms, model licenses, data residency/retention, model-version controls, and safety/authorization constraints are reviewed for intended use.
  • API and frontend application behavior is verified where applicable, including schema adherence, refusals, fallbacks, error states, and user-facing comprehension.
  • Decision makers have reviewed limitations, disqualifying risks, supporting evidence, alternatives, and a rollback/re-evaluation plan.
  • A named approver has accepted the exact model/provider/configuration decision and recorded any residual risks, owners, and trigger for renewed assessment.

Domain-specific approval rule: Block model selection when a critical task or safety threshold is missed, validation data is compromised, material license or data-handling constraints are unresolved, or latency/cost at required capacity is not viable without accepted mitigation. A high public benchmark ranking alone cannot override an unsafe or unfit result.

Trusted references and scope#

These primary framework, benchmark, and tool-maintainer sources inform the review questions. They are not proof that any specific model is suitable or that the product is certified by a standards body.

Applicability: NIST AI RMF material is voluntary guidance and the framework was under revision at the source review. HELM entered maintenance mode in June 2026. MLPerf measures defined hardware/software inference scenarios, not arbitrary end-user task quality. Benchmark harnesses and model/dataset cards require independent review of actual model versions, prompt templates, evaluation rights, and workload relevance. The listed proprietary platform documentation applies only when using those platforms; model/provider pricing and capabilities may change without advance notice.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

  • Test focus: candidate models with identical datasets, metrics, latency, and safety thresholds; include model and dataset behaviors where applicable.
  • Cross-stack: lm-evaluation-harness + MLPerf.
  • Python: Hugging Face Evaluate + pytest; for pytest-based suites, run python -m pytest -q.
  • TypeScript: promptfoo + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
  • JavaScript: promptfoo + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
  • Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

  • eval-harness-first — Verify benchmark design before selection (wshobson/agents, 42,437 repo stars).
  • llm-evaluation — Compare held-out and safety evaluation criteria (wshobson/agents, 42,437 repo stars).
  • agentic-eval — Review repeatability, baselines, and regression gating (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the AI-specific scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.

Reference, not a certification. Check applicability, verify important claims against current primary sources, and seek expert review where necessary. Suggest an improvement.