Model Selection, Evaluation and GenAI Operations

Introduction

Generative artificial intelligence has moved from experimental technology to an operational capability used in customer service, marketing, software development, research, finance, and internal knowledge management. Yet selecting a model is not simply a matter of choosing the largest or newest system. A model must be appropriate for a defined business task, acceptable under legal and ethical requirements, affordable at expected scale, and manageable throughout its life cycle.

This chapter presents a practical framework for comparing proprietary, open-source, and small language models; evaluating model quality and operational performance; and managing applications through application programming interfaces (APIs), fine-tuning, monitoring, versioning, and LLMOps. LLMOps refers to the processes, tools, and governance used to develop, deploy, operate, and improve applications based on large language models (LLMs).

Learning Objectives

By the end of this chapter, students should be able to:

1. Distinguish proprietary, open-source, open-weight, and small language models.
2. Match model characteristics to business requirements.
3. Design an evaluation framework covering accuracy, relevance, robustness, bias, latency, and cost.
4. Explain APIs, retrieval-augmented generation, prompting, and fine-tuning.
5. Describe monitoring, version control, testing, security, and governance practices in LLMOps.
6. Recommend a model and operating approach for a realistic business application.

1. Model Families and Selection Criteria

Proprietary models

A proprietary model is controlled by a vendor that generally manages the model weights, training infrastructure, release process, and service interface. Customers commonly access it through a hosted API or an enterprise platform. Advantages can include strong general performance, multimodal capability, managed security features, rapid improvements, and technical support. Disadvantages may include usage fees, dependence on the vendor, limited transparency, data-residency constraints, and changes to model behavior or availability.

Proprietary access does not automatically mean that customer data are used for training. This depends on the provider’s contract and product configuration. An organization must verify retention, training-use, encryption, regional processing, and deletion policies rather than assume them.

Open-source and open-weight models

The terms open-source and open-weight are related but not identical. An open-weight model makes trained parameters available, often with code or documentation, but its license may restrict commercial use, redistribution, or modification. A genuinely open-source system normally provides more of the source code, documentation, and rights needed for inspection and modification, although definitions and licenses vary.

Open-weight models can be deployed in an organization’s own cloud or data center, enabling greater control over privacy, customization, and latency. However, the organization assumes responsibility for hardware, security, upgrades, evaluation, incident response, and compliance. A freely downloadable model can therefore have substantial total cost of ownership.

Small language models

Small language models (SLMs) have fewer parameters or are otherwise designed for lower computational requirements. They may be less capable in broad reasoning or multilingual generation, but can be highly effective for constrained tasks such as classification, extraction, summarization of short documents, routing, or structured customer-service responses. They may operate at the edge, support lower latency, and reduce cost and data exposure.

Model size is not the same as quality. A smaller model trained or fine-tuned for a specific domain may outperform a much larger general model on that task. Selection should therefore begin with the business task, not model prestige.

A decision framework

A practical selection process has six stages:

1. Define the task, users, decisions, and consequences of error.
2. Establish constraints involving privacy, geography, integration, response time, and budget.
3. Shortlist models with appropriate capabilities and licenses.
4. Test candidates on representative data, including difficult and adversarial cases.
5. Estimate total operating cost and implementation effort.
6. Approve, deploy, monitor, and periodically reassess the selected system.

2. How Language Models Are Used in Business Systems

An LLM application normally includes more than the model itself. A production system may contain a user interface, authentication, prompt templates, retrieval components, content filters, the model API, business rules, logging, monitoring, and a human-review process.

APIs

An application programming interface allows software to send a request to a model and receive a response through a defined protocol. A request may include system instructions, user content, retrieved context, model parameters, and output-format requirements. Important API concerns include authentication, rate limits, timeout handling, retries, streaming, structured output, and error codes.

A robust client should not retry every failure indiscriminately. Authentication errors, invalid requests, and policy refusals require correction or escalation. Temporary network failures or rate-limit responses may support bounded retries with exponential backoff. Logs should record request identifiers, model version, latency, status, and cost-related information while avoiding unnecessary storage of sensitive prompt content.

Prompting and structured generation

Prompt engineering specifies the task, context, constraints, examples, and desired output. For business use, structured outputs are often preferable to unconstrained prose. For example, an invoice-extraction system may require fields such as supplier, invoice date, currency, and total amount. The application must still validate the output because a format-valid response can be factually wrong.

Retrieval-augmented generation

Retrieval-augmented generation (RAG) supplies relevant organizational information to the model at request time. Documents are divided into passages, converted into vector representations, indexed, and retrieved using semantic or hybrid search. The selected passages are included in the prompt, and the model generates an answer based on them.

RAG is useful when information changes frequently or must be traceable. It does not eliminate hallucination: retrieval may return irrelevant passages, documents may be outdated, and the model may misinterpret evidence. Source citations, access controls, document freshness checks, and answer abstention are therefore important.

Fine-tuning

Fine-tuning updates model parameters using examples from a specific task or style. It can improve consistent classification, formatting, terminology, or response behavior. It is less suitable for frequently changing factual knowledge, which is usually better supplied through retrieval.

Fine-tuning requires high-quality, representative, permissioned data. Poor examples can encode errors, bias, or undesirable behavior. Evaluation must compare the fine-tuned model with a strong baseline and test whether improvements on the training task create regressions elsewhere.

3. Evaluation: From Demonstration to Evidence

A model demonstration is not a reliable evaluation. Professional evaluation uses a test set that reflects real inputs, expected outputs, user diversity, edge cases, and consequences of failure. The test data should be separated from training and prompt-development data to reduce leakage.

Accuracy and task metrics

Accuracy has different meanings by task. For binary classification:

Here, TP is true positives, TN true negatives, FP false positives, and FN false negatives. Accuracy can be misleading when classes are imbalanced. Precision and recall are often more informative:

Precision measures the proportion of predicted positives that are correct; recall measures the proportion of actual positives that are found. These formulas assume a binary classification setting and nonzero denominators. For high-risk screening, the relative cost of false positives and false negatives should guide threshold selection.

For generation, exact-match, citation accuracy, groundedness, semantic similarity, human ratings, and task-specific success rates may be used. No single metric captures quality. Automated judges can assist at scale but may share biases with the model being evaluated and should be calibrated against human assessment.

Relevance and groundedness

Relevance asks whether the answer addresses the user’s question. Groundedness asks whether claims are supported by supplied evidence or verified sources. A fluent answer can be relevant in topic but ungrounded in fact. Evaluation should therefore label unsupported claims, missing evidence, incorrect citations, and inappropriate certainty.

Robustness

Robustness is performance stability under variation. Test cases may include spelling errors, paraphrases, long inputs, conflicting instructions, missing information, prompt injection, multilingual requests, and unusual but legitimate user groups. A robust system should fail safely, for example by requesting clarification or declining to answer rather than inventing information.

Bias and fairness

Bias evaluation examines whether performance or treatment differs across relevant groups, languages, dialects, names, or demographic contexts. A simple group difference in a rate can be expressed as:

where Rate_A and Rate_B are the measured rates for two defined groups. This is a descriptive comparison, not proof of discrimination or causation. Groups, labels, sampling methods, and legitimate task differences must be carefully defined. Fairness analysis should include qualitative review because harmful stereotypes may not appear in aggregate rates.

Latency and throughput

Latency is the time from request submission to usable response. It may be divided into network time, queue time, time to first token, and time to completion. Streaming can improve perceived responsiveness without reducing total generation time. Throughput concerns how many requests or tokens can be processed in a period under stated hardware and concurrency conditions.

Cost

A simple variable-cost estimate is:

where N_i and N_o are input and output tokens, p_i and p_o are the respective prices per token, and C_fixed includes infrastructure, storage, monitoring, engineering, and support costs. Prices must be expressed in consistent units, such as dollars per million tokens. This estimate excludes unexpected retries and should be supplemented with a sensitivity analysis.

Worked example. Suppose a service processes 200,000 requests. Each request averages 800 input tokens and 300 output tokens. Input pricing is $2 per million tokens and output pricing is $8 per million tokens. Input tokens equal 160 million, costing $320. Output tokens equal 60 million, costing $480. Variable model cost is therefore $800, before fixed costs. If monitoring and infrastructure add $250, estimated total cost is $1,050. Actual cost may differ if tokenization, retries, caching, or provider billing rules differ.

Evaluation scorecards

A scorecard should report disaggregated results rather than a single attractive number. It can include task success, groundedness, safety, subgroup performance, p95 latency, refusal quality, cost per successful task, and human-review rate. Weighting metrics into one score may support decisions, but the weights must be explicit because they encode business values.

4. LLMOps: Operating the Model Lifecycle

LLMOps extends familiar software and machine-learning operations practices to systems whose outputs are probabilistic, language-based, and sensitive to prompts and context.

Development and release stages

A disciplined lifecycle includes:

1. Design: define use case, owner, risk classification, users, and success criteria.
2. Build: implement prompts, retrieval, tools, policies, and integrations.
3. Test: run functional, quality, security, bias, and load tests.
4. Evaluate: compare candidates and versions on fixed and newly sampled datasets.
5. Release: deploy with approval, rollback capability, and documented configuration.
6. Operate: monitor quality, safety, latency, cost, and incidents.
7. Improve or retire: update data and prompts, fine-tune, migrate, or decommission.

Versioning and reproducibility

A production record should identify the model name and version, provider or weight source, system prompt, user prompt template, retrieval index version, embedding model, safety settings, tools, code commit, evaluation-set version, and deployment date. Changing any of these can change behavior. Configuration should be stored as code where possible, and releases should be reproducible enough to support audit and rollback.

A model alias such as “current” is convenient but insufficient for audit. Organizations should pin a tested version in production and deliberately approve upgrades. Canary releases and A/B tests can expose regressions before full deployment, while rollback protects continuity.

Monitoring

Operational monitoring includes:

• availability, error rates, timeouts, and rate-limit events;
• time to first token, total latency, and throughput;
• token usage and cost by team or use case;
• refusal, escalation, and human-correction rates;
• retrieval hit quality and citation coverage;
• user feedback and sampled output quality;
• prompt injection, data leakage, and policy incidents.

Monitoring quality is difficult because there may be no immediate ground-truth label. Organizations can use sampled human review, delayed business outcomes, user corrections, reference answers, and automated detectors. Monitoring must respect privacy and access controls; collecting every prompt forever is neither necessary nor always lawful.

Security and governance

Threats include prompt injection, insecure tool use, sensitive-data leakage, model supply-chain risks, malicious documents in retrieval stores, and unauthorized access to logs. Controls include least-privilege tool permissions, input and output filtering, data loss prevention, sandboxing, document-level access control, secrets management, red-team testing, and incident response.

Governance should assign an accountable owner and define acceptable uses, prohibited uses, escalation procedures, retention periods, and documentation requirements. High-impact decisions involving employment, credit, health, or essential services may require additional human oversight, explainability, impact assessment, and compliance review. A model should not be treated as an autonomous decision-maker merely because it produces confident language.

5. Illustrative Case: Choosing a Customer-Service Assistant

Background

A regional telecommunications company receives 40,000 monthly support requests. It wants an assistant to answer questions about plans, billing procedures, device setup, and service outages. Incorrect billing advice could create financial and regulatory risk.

Problem

The company is considering a hosted proprietary model, a self-hosted open-weight model, and a small model deployed for intent classification and routing. Management wants low cost but also requires answers grounded in current policy documents, response time below four seconds for ordinary requests, and escalation when confidence is inadequate.

Analysis

The team defines a test set of 1,200 anonymized historical questions, 200 newly written edge cases, and multilingual examples. Each response is evaluated for policy correctness, relevance, citation or document support, refusal quality, and escalation appropriateness. The team also measures p95 latency, estimated cost per conversation, subgroup performance, and resistance to prompt injection contained in uploaded documents.

The hosted model performs best on complex explanations but has higher variable cost and less control over regional processing. The open-weight model allows local deployment but requires expensive GPU infrastructure and more engineering. The small model performs well for intent classification and routing but is insufficient as the sole generator. The final design is a hybrid: the small model routes and detects common intents; a hosted model generates answers using RAG for complex requests; high-risk billing changes require an authenticated workflow and human approval.

Solution and controls

The company versions policy documents and applies access control to retrieval. Answers cite the relevant policy title and date. The assistant is instructed to state when information is missing and escalate rather than speculate. A monthly evaluation sample and continuous incident monitoring are established. A fixed model version is initially deployed to a small percentage of users, followed by a controlled expansion.

Outcome

In this illustrative case, the hybrid design reduces unnecessary use of the larger model, improves routing speed, and preserves human control over sensitive actions. Its success is not measured only by conversational fluency but by correct resolution, safe escalation, controlled cost, and traceable evidence.

Learning points

1. Different models can serve different stages of one workflow.
2. RAG is valuable for changing policy information but requires document governance.
3. Cost should be measured per successful task, not merely per token.
4. Versioning and rollback are operational requirements, not optional documentation.
5. Human oversight is essential where errors have material consequences.

6. Challenges and Contemporary Developments

Model behavior can change because of provider updates, altered safety policies, tokenizer changes, retrieval drift, or user behavior. Benchmark scores may not predict performance on an organization’s domain. Synthetic evaluation data can be useful for coverage but may fail to represent real users. Open models improve portability but create supply-chain and maintenance obligations. Small models and quantization reduce infrastructure requirements, but compression may affect accuracy, multilingual performance, or safety.

Emerging practices include model routing, where requests are sent to different models according to complexity; semantic caching for repeated queries; multimodal systems that process text, images, audio, or documents; and agentic workflows that call tools and execute multiple steps. These developments increase capability but also expand the attack surface and make evaluation harder. The more autonomy a system has, the stronger its authorization, verification, logging, and human-approval controls must be.

Best-Practice Checklist

• Start with the business task and error consequences.
• Compare at least one strong baseline with specialized or smaller alternatives.
• Use representative, held-out, and adversarial evaluation data.
• Report quality, fairness, latency, cost, and safety together.
• Separate changing knowledge from behavior that genuinely requires fine-tuning.
• Pin model, prompt, retrieval, code, and configuration versions.
• Monitor both technical signals and real business outcomes.
• Protect prompts, documents, outputs, and logs as potentially sensitive data.
• Design abstention, escalation, rollback, and incident response before launch.
• Review licenses, contracts, regulatory duties, and supplier dependencies.

Chapter Summary

Model selection is a multi-criteria business and technical decision. Proprietary models offer managed capability, open-weight models offer control and customization, and small models can provide efficient performance for focused tasks. No category is universally superior.

Evaluation must go beyond fluency and benchmark results. Accuracy, relevance, groundedness, robustness, bias, latency, cost, and safety should be tested on representative data and reported transparently. APIs connect applications to models, while RAG supplies changing knowledge and fine-tuning shapes task behavior. LLMOps provides the lifecycle discipline needed for versioning, deployment, monitoring, governance, security, and continuous improvement. Reliable GenAI is therefore an organizational system, not merely a model endpoint.

Key Terms

Proprietary model: A model controlled and typically hosted by a vendor.

Open-source model: A model distributed with source materials and rights defined by an open license.

Open-weight model: A model whose trained parameters are made available under specified terms.

Small language model: A language model optimized for lower computational requirements or focused tasks.

API: A defined software interface for sending requests to and receiving responses from a service.

RAG: Retrieval-augmented generation using retrieved evidence in model prompts.

Fine-tuning: Updating model parameters with task- or domain-specific examples.

Prompt injection: An attempt to manipulate instructions through user input or retrieved content.

Groundedness: The extent to which an answer is supported by available evidence.

Robustness: Stability of performance under input, context, or environmental variation.

Precision: The proportion of predicted positive cases that are correct.

Recall: The proportion of actual positive cases that are identified.

Latency: Time required to produce a response or usable first output.

Throughput: Volume of requests or tokens processed in a period.

LLMOps: Practices for developing, deploying, monitoring, and governing LLM applications.

Canary release: Limited deployment used to detect problems before broad release.

Model drift: Change in effective performance caused by data, behavior, or environment changes.

Human-in-the-loop: Human review or intervention within an automated workflow.

Review Questions

Short Answer Questions

1. What is the principal difference between a proprietary and an open-weight model?
2. Why might a small language model be preferred for a business task?
3. Define groundedness in generative AI evaluation.
4. What information should be recorded to version an LLM application?
5. Why is a held-out evaluation set important?

Long Answer Questions

1. Compare proprietary, open-source, open-weight, and small language models across control, cost, privacy, and capability.
2. Explain why accuracy alone is inadequate for evaluating a generative AI application.
3. Describe how RAG and fine-tuning solve different business problems.
4. Explain the main components of an LLMOps lifecycle.
5. Discuss governance and security controls for an assistant that can call business tools.

Analytical / Application Questions

1. A company must process sensitive documents locally but has limited AI engineering expertise. Recommend a model strategy and justify the trade-offs.
2. Design an evaluation scorecard for an AI system that screens customer complaints for escalation.
3. A model upgrade improves benchmark performance but increases p95 latency and doubles cost. Explain what evidence management should review before approving the upgrade.

Multiple Choice Questions with Answers

Question 1

Which characteristic most strongly distinguishes a small language model from a large general-purpose model?

A. It must always be open-source

B. It is designed for lower computational requirements or focused tasks

C. It cannot generate text

D. It never requires evaluation

Correct Answer: B. It is designed for lower computational requirements or focused tasks

Question 2

Which approach is generally most appropriate for frequently changing company policy information?

A. RAG with governed document retrieval

B. Deleting the policy documents

C. Fine-tuning once and never updating the model

D. Increasing temperature only

Correct Answer: A. RAG with governed document retrieval

Question 3

If TP = 80, TN = 90, FP = 10, and FN = 20, what is classification accuracy?

A. 70%

B. 80%

C. 85%

D. 90%

Correct Answer: C. 85%

Question 4

What does recall measure in binary classification?

A. The proportion of predicted positives that are correct

B. The proportion of actual positives that are identified

C. The proportion of all predictions that are correct

D. The time required to generate a response

Correct Answer: B. The proportion of actual positives that are identified

Question 5

Which item is most important for reproducing a production LLM result?

A. The office location of the development team

B. The model version, prompt configuration, retrieval version, and code version

C. The screen size used by the user

D. The number of employees in the company

Correct Answer: B. The model version, prompt configuration, retrieval version, and code version

Question 6

A system receives 100 million input tokens at $2 per million and 20 million output tokens at $8 per million. What is the variable model cost?

A. $240

B. $260

C. $360

D. $400

Correct Answer: C. $360

Question 7

Which is an example of robustness testing?

A. Testing only the most common clean input

B. Testing paraphrases, spelling errors, long inputs, and prompt injection

C. Measuring office electricity consumption only

D. Removing all edge cases from the test set

Correct Answer: B. Testing paraphrases, spelling errors, long inputs, and prompt injection

Question 8

Why should an organization avoid treating a fluent model response as proof of correctness?

A. Fluency guarantees excessive latency

B. Fluent language can still be irrelevant, biased, or unsupported by evidence

C. Fluent models cannot use APIs

D. Fluency prevents structured output

Correct Answer: B. Fluent language can still be irrelevant, biased, or unsupported by evidence

Question 9

What is the main purpose of a canary release?

A. To expose a new version to a limited group before wider deployment

B. To permanently disable monitoring

C. To eliminate the need for testing

D. To guarantee zero hallucinations

Correct Answer: A. To expose a new version to a limited group before wider deployment

Question 10

Which control most directly limits the damage caused by an LLM tool-calling mistake?

A. Giving the model unrestricted administrator privileges

B. Using least-privilege permissions and human approval for high-risk actions

C. Removing all logs

D. Increasing response length

Correct Answer: B. Using least-privilege permissions and human approval for high-risk actions