Algorithm Engineering, AI Applications and Governance

Introduction and Context

Data structures and algorithms are often taught as abstract mechanisms for solving computational problems. In professional systems, however, an algorithm is not successful merely because it is correct or asymptotically efficient. It must also perform well on realistic hardware, handle changing workloads, integrate with libraries and services, remain understandable to other engineers, and comply with legal, ethical, and organizational requirements.

This broader activity is algorithm engineering: the systematic design, implementation, measurement, evaluation, and maintenance of algorithms in real environments. It connects theoretical analysis with software engineering and operational decision-making. Algorithm engineering is particularly important in artificial intelligence and machine learning (AI/ML), where pipelines process large datasets, train computationally expensive models, serve predictions to users, and influence decisions about people.

A data structure selected for a textbook exercise may be inappropriate in production because of memory overhead, cache behavior, concurrency, security exposure, or maintenance cost. Conversely, an algorithm with a less favorable asymptotic bound may be faster for the actual input sizes because it has lower constants or better locality. Professional practice therefore requires both theoretical reasoning and empirical evidence.

This chapter examines how to profile, test, optimize, and govern algorithmic systems. It also considers standard libraries, scalability, maintainability, reproducibility, fairness, privacy, security, energy use, and emerging hardware-aware and learned data structures.

Learning Objectives

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

1. Distinguish correctness, complexity, performance, scalability, and maintainability.

2. Design meaningful benchmarks and interpret profiling results.

3. Select standard-library data structures responsibly.

4. Apply optimization methods without sacrificing correctness or clarity.

5. Evaluate algorithms in AI/ML pipelines and digital platforms.

6. Explain how privacy, security, fairness, energy consumption, and reproducibility affect algorithmic design.

7. Assess hardware-aware and learned data structures, including their limitations.

8. Make evidence-based engineering recommendations.

1. From Algorithm Analysis to Algorithm Engineering

1.1 Correctness is necessary but not sufficient

An algorithm is correct when it produces an acceptable output for every input within its specified domain. Correctness includes functional requirements, boundary cases, error handling, and—in concurrent or distributed systems—appropriate consistency and synchronization properties.

A correct implementation may still be unsuitable because it is too slow, consumes excessive memory, leaks private information, fails under adversarial input, or cannot be reproduced. Engineering evaluation therefore considers several dimensions:

• Time performance: How long operations take under defined conditions.
• Space performance: How much memory is required, including temporary and structural overhead.
• Scalability: How resource use and service quality change as data volume, users, model size, or request rate increases.
• Robustness: Whether performance and correctness remain acceptable under unusual, noisy, or adversarial inputs.
• Maintainability: How easily the implementation can be understood, tested, modified, and operated.
• Resource efficiency: Use of CPU, memory, storage, network bandwidth, accelerators, and energy.
• Governance quality: Whether the system meets requirements for fairness, privacy, security, accountability, and auditability.

1.2 Asymptotic and practical cost

Big-O notation describes how resource requirements grow with input size. It suppresses constant factors and lower-order terms, so it is valuable for comparing growth but does not predict exact running time. For example, a hash-table lookup is commonly described as expected O(1), but this assumes a suitable hash function, controlled load factor, and an appropriate collision strategy. In the worst case, lookup can become O(n).

A simple performance model is:

\[

T(n) = c_1 f_1(n) + c_2 f_2(n) + \cdots + c_k f_k(n),

\]

where T(n) is execution time, the functions f_i describe operation counts, and c_i represent implementation- and hardware-dependent costs. The model is useful only when the workload, machine, compiler, and implementation assumptions are stated. Two algorithms with the same asymptotic complexity can differ substantially because of memory allocation, branch prediction, cache misses, interpretation overhead, or data movement.

A related engineering principle is to optimize the dominant cost. If a pipeline spends 80 percent of its time loading and transforming data, optimizing a model inference kernel that consumes 5 percent may produce little overall improvement. Amdahl's law expresses this limitation. If a fraction p of execution time is improved by a factor s, the total speedup is

\[

S = \frac{1}{(1-p)+p/s}.

\]

Here, 0 ≤ p ≤ 1, s ≥ 1, and the unchanged portion is assumed not to benefit from the optimization. If p = 0.8 and s = 4, then S = 1/(0.2 + 0.8/4) = 1/0.4 = 2.5. Thus a fourfold optimization of one component yields only a 2.5-fold end-to-end improvement.

2. Testing, Benchmarking, and Profiling

2.1 Testing for correctness and quality

Testing should precede performance optimization. Common layers include:

• Unit tests: Verify individual functions and data structures.
• Property-based tests: Generate many inputs and check general properties, such as that sorting preserves the multiset of elements.
• Integration tests: Verify interactions among data loading, feature construction, models, storage, and APIs.
• Regression tests: Ensure that changes do not reintroduce previous defects.
• Load and stress tests: Examine behavior at expected and excessive request rates.
• Security tests: Explore injection, denial-of-service, unauthorized access, and data leakage.

Tests should include empty inputs, singleton inputs, duplicate values, extreme values, malformed records, missing data, and unusually large inputs. Randomized testing is useful, but a fixed seed and recorded configuration are needed when results must be reproduced.

2.2 Designing a valid benchmark

A benchmark is an experiment, not simply a timer around a function. A defensible benchmark specifies:

1. The question being investigated.

2. Representative input distributions and sizes.

3. Hardware, operating-system, compiler, interpreter, and library versions.

4. Warm-up behavior, especially for just-in-time compilation and caches.

5. Number of repetitions and treatment of outliers.

6. Metrics, such as median latency, tail latency, throughput, memory, and energy.

7. Whether input generation and output validation are included.

For interactive systems, average latency is insufficient. The 95th or 99th percentile may matter more because a small number of very slow requests can damage user experience. Throughput measures completed operations per unit time, whereas latency measures time per operation; optimizing one can sometimes harm the other.

Benchmarks must avoid common errors. Timing the first call may include startup and compilation. Reusing identical data may accidentally exploit a cache. Comparing an optimized implementation with validation disabled is unfair. A benchmark that uses unrealistically clean data can conceal expensive error paths in production.

2.3 Profiling

Profiling identifies where resources are consumed. A CPU profiler may use sampling, which periodically records the active call stack, or instrumentation, which records selected events. Sampling generally has lower overhead; instrumentation can provide more detailed counts but may perturb execution.

Useful profiling perspectives include:

• Function-level profiling: Which functions consume CPU time?
• Call-graph analysis: Which callers lead to expensive operations?
• Memory profiling: Which objects are allocated, retained, or copied?
• I/O profiling: Is the bottleneck storage or network access?
• Concurrency profiling: Are threads blocked, contending, or idle?
• Hardware-counter analysis: Are cache misses, branch mispredictions, or vector instructions limiting performance?

Profiling should use production-like workloads and be repeated after changes. A profile is evidence about a particular execution, not a universal property of the algorithm.

3. Responsible Use of Standard Libraries

Standard libraries provide tested implementations of sorting, hashing, queues, maps, numerical operations, serialization, and concurrency primitives. Reusing them usually improves reliability and reduces development time. It also allows engineers to benefit from expert optimization and security maintenance.

However, library use is not automatically correct. Engineers must understand:

• Time and space complexity and worst-case behavior.
• Ordering guarantees and stability of sorting.
• Mutability, aliasing, and thread-safety properties.
• Handling of null, missing, invalid, or extreme values.
• Serialization and deserialization risks.
• Version compatibility and licensing.
• Whether defaults are appropriate for sensitive or high-scale workloads.

For example, a dictionary or hash map is convenient for feature lookup, but it may expose denial-of-service risks if attackers can construct many colliding keys. A priority queue supports efficient access to the smallest or largest element, but it does not provide efficient membership testing. A list may outperform a tree for small collections because of contiguous storage and low overhead. The choice should follow operations and workload rather than habit.

Implementing a data structure from scratch is justified when educational learning is the objective, when a specialized representation is required, or when a library cannot meet a verified requirement. It is rarely justified merely because the standard implementation appears simple.

4. Optimization Without Losing Quality

Optimization should follow a disciplined sequence:

1. Define functional and non-functional requirements.

2. Establish a correct baseline.

3. Measure representative workloads.

4. Identify the dominant bottleneck.

5. Form a specific optimization hypothesis.

6. Change one important factor where possible.

7. Re-test correctness, security, and performance.

8. Compare against the baseline and document the result.

9. Retain the change only if its benefit justifies its complexity.

Typical optimization opportunities include choosing a better algorithm, reducing repeated work, improving data locality, batching operations, avoiding unnecessary copying, using appropriate indexes, and parallelizing independent work. Memoization can reduce repeated computation but increases memory use and requires correct invalidation. Compression can reduce network transfer but consumes CPU and may increase latency.

Premature optimization is harmful when it complicates code before a bottleneck is demonstrated. Yet “optimize later” does not mean ignoring architecture. Choosing an O(n²) method for a component expected to process millions of records is a design error even if its current benchmark is acceptable.

Worked example: indexing a feature lookup

Suppose a batch pipeline repeatedly searches a collection of n records for a matching identifier. A linear scan costs O(n) per lookup. For q independent lookups, the total search work is O(qn). If a hash index is built once, construction is expected O(n), and q lookups are expected O(q), giving expected total O(n + q), subject to hashing assumptions.

For n = 1,000,000 and q = 100,000, the scan-based operation count is proportional to 100,000,000,000 comparisons in the worst case. The indexed approach performs work proportional to approximately 1,100,000 table insertions and lookups, excluding collision and memory effects. The index consumes additional memory and must be rebuilt or updated when records change. The engineering decision is favorable when many lookups justify construction and memory costs; it may not be favorable for a single lookup or a rapidly changing dataset.

5. Algorithms in AI/ML Pipelines and Digital Platforms

AI/ML systems are pipelines rather than isolated models. A typical sequence is data ingestion, validation, cleaning, feature construction, splitting, training, evaluation, deployment, monitoring, and retraining. Data structures and algorithms affect every stage.

Examples include:

• Hash maps for categorical encoding and feature dictionaries.
• Graphs for recommendation, fraud analysis, and knowledge representation.
• Heaps and priority queues for top-k retrieval.
• Inverted indexes for search.
• Approximate nearest-neighbor indexes for vector retrieval.
• Queues and streams for event processing.
• Trees and sorted arrays for range queries.
• Bloom filters for space-efficient membership screening, with possible false positives.
• Distributed partitioning and aggregation for large datasets.

In retrieval systems, a top-k operation can use a heap of size k rather than fully sorting all n candidates. This commonly reduces selection work from O(n log n) for complete sorting to O(n log k), when k is substantially smaller than n. The precise cost depends on implementation and whether the data is already ordered.

In training, data-loader algorithms determine whether accelerators remain busy. Poor shuffling, excessive copying, or serial preprocessing can dominate model execution. In online platforms, caches and indexes reduce latency but create consistency, invalidation, and privacy challenges.

Evaluation must include more than predictive accuracy. Relevant measures may include calibration, false-positive and false-negative rates across groups, latency, availability, cost per prediction, data freshness, and the consequences of errors. A technically fast model can be operationally unacceptable if it produces discriminatory outcomes or cannot explain its use of sensitive data.

6. Governance: Fairness, Privacy, Security, and Accountability

6.1 Fairness and bias

Bias can enter through historical labels, under-represented data, measurement choices, feature definitions, sampling, model objectives, and deployment feedback loops. Algorithmic fairness is not a single universal metric. Possible assessments include comparing error rates or selection rates across relevant groups, but metrics can conflict, especially when base rates differ. The appropriate evaluation depends on the decision context, legal obligations, harms, and stakeholder perspectives.

Engineers should document data provenance, inspect subgroup performance, test plausible distribution shifts, and involve domain experts and affected communities. Removing a protected attribute does not remove bias if proxy variables remain. Fairness checks should occur before deployment and continuously afterward.

6.2 Privacy

Data structures can create privacy risks through logs, caches, backups, indexes, and retained intermediate data. Privacy-preserving practices include data minimization, purpose limitation, access control, encryption, retention limits, and de-identification with careful re-identification testing. Differential privacy provides a formal framework for limiting the effect of one individual's data on a released result, but it introduces a privacy–utility trade-off and requires careful management of the privacy budget. It should not be represented as a guarantee that all other security controls are unnecessary.

6.3 Security

Algorithmic security includes protecting data and preventing manipulation of computational behavior. Threats include adversarial inputs, poisoned training data, model extraction, membership inference, unsafe deserialization, hash flooding, resource exhaustion, and unauthorized access to feature stores.

Defensive measures include input validation, bounded resource use, safe parsers, authentication and authorization, dependency updates, secrets management, rate limiting, audit logs, threat modeling, and incident response. Complexity itself can be a security concern: an operation that is usually fast but has an exploitable worst case can enable denial of service.

6.4 Accountability and regulation

Governance requires clear responsibility for data collection, model development, deployment, monitoring, and retirement. Documentation should record intended use, limitations, data sources, evaluation conditions, known failure modes, version identifiers, and approval decisions. Depending on jurisdiction and application, privacy, anti-discrimination, consumer-protection, safety, and AI-specific regulations may apply. Legal compliance is a minimum requirement, not a substitute for ethical judgment.

7. Reproducibility, Operations, and Energy

Reproducibility means that another person can recreate a result or, at minimum, understand why exact reproduction is impossible. Good practice includes version-controlled code, pinned dependencies, dataset and schema versions, configuration files, random seeds where relevant, documented hardware, deterministic settings when feasible, experiment tracking, and stored evaluation artifacts.

Exact bit-level reproducibility may be difficult because of parallel reductions, nondeterministic scheduling, floating-point differences, changing libraries, and hardware-specific kernels. Therefore, reports should distinguish exact reproducibility from approximate reproducibility, such as obtaining results within a stated tolerance.

Energy use matters because training and serving can consume substantial electricity, and hardware production also has environmental costs. Efficiency measures include smaller models, reuse of pretrained models, batching, quantization where accuracy remains acceptable, efficient data movement, caching, workload scheduling, and selecting hardware appropriate to the workload. Energy comparisons should define the system boundary and workload; a single energy-per-operation number is not meaningful without these assumptions. Reducing energy must not quietly increase unfairness, privacy risk, or error rates.

8. Hardware-Aware and Learned Data Structures

8.1 Hardware-aware design

Modern performance depends on more than arithmetic complexity. CPUs exploit caches, vector instructions, speculative execution, and multiple cores. GPUs favor highly parallel workloads and regular memory access. Specialized accelerators may offer high throughput for particular tensor operations but be inefficient for irregular control flow.

Data-oriented design often stores records in layouts that improve locality and vectorization. A structure-of-arrays layout can be advantageous when processing one field across many records; an array-of-structures layout can be convenient when processing complete records. Neither is universally superior. Measurements on target hardware are required.

External-memory and distributed algorithms must account for transfers between storage levels or machines. An algorithm that minimizes comparisons but causes many random memory accesses may be slower than one doing more comparisons sequentially.

8.2 Learned indexes and learned data structures

A learned index uses a model to predict the position of a key in a sorted or structured dataset. If keys have a predictable distribution, the prediction can narrow a search range and reduce memory or improve speed. A correction search is still required because predictions are not guaranteed to be exact, and changing data may require retraining or additional structures.

Learned structures are promising but introduce assumptions and operational complexity: distribution shift, update handling, model validation, fallback behavior, training cost, and explainability. They should be compared with strong conventional baselines such as B-trees, hash tables, or binary search. They are not a universal replacement for classical data structures.

9. Illustrative Case: A Fair and Scalable Benefits-Eligibility Platform

Background

Consider a fictional public-service platform that helps caseworkers prioritize applications for a benefits program. The system receives applications, validates documents, retrieves relevant records, and presents a risk or urgency score. This is an illustrative case, not a report of a real deployment.

Problem

The initial implementation scans all historical records for each application and performs several repeated feature transformations. Average response time is acceptable during testing but becomes excessive at peak demand. Audits also reveal that one demographic group experiences a higher false-negative rate. Logs contain more personal information than is necessary, and developers cannot reproduce an earlier model evaluation because dependency versions were not recorded.

Analysis

Profiling shows that record lookup and document parsing consume most CPU time; model inference is a smaller component. Load testing reveals severe tail-latency growth when concurrent requests increase. Data analysis identifies different error rates across groups, while legal and domain review shows that some features act as proxies for protected characteristics. Security review finds unbounded document sizes and excessive retention in debug logs.

Approach and Solution

The engineering team creates a correct baseline and a versioned benchmark suite. It builds an appropriate index for stable identifiers, uses bounded parsing and streaming for documents, and caches only non-sensitive derived data with explicit expiration. It replaces full sorting with a bounded top-k structure for the caseworker interface. The team measures both median and 99th-percentile latency and verifies that indexing does not change results.

For governance, the team removes unjustified proxy features, evaluates subgroup error rates, conducts domain review, and introduces a human-review path for uncertain or high-impact cases. The system records reason codes and model version information, but avoids storing unnecessary personal content. Access is role-based, data retention is limited, and all external input is validated.

A reproducible experiment environment records code commits, data snapshots, dependency versions, random seeds, hardware, and evaluation configurations. Monitoring tracks drift, latency, error rates, subgroup outcomes, and incidents. A rollback procedure is tested before release.

Outcome

The platform reduces lookup work and improves peak responsiveness, although the index increases memory use and requires an update policy. Tail latency improves because document processing is bounded. The fairness review identifies a trade-off: a change that reduces one group’s false-negative rate increases manual review volume. Stakeholders select the policy after considering the consequences rather than relying on a single accuracy measure.

Learning Points

The case illustrates that optimization begins with profiling, not intuition. It also shows that performance, privacy, security, fairness, and reproducibility are connected engineering requirements. A faster system is not a better system if it increases harm or cannot be audited.

10. Professional Decision Framework and Best Practices

A practical review can ask the following questions:

• What is the required behavior, and how is correctness tested?
• Which workload, input distribution, and scale are expected?
• What does profiling demonstrate about the dominant bottleneck?
• What are average and tail latency, throughput, memory, and energy requirements?
• What happens in the worst case and under adversarial input?
• Can a maintained standard-library component meet the requirement?
• What data is collected, retained, exposed, or inferred?
• Are outcomes and errors evaluated across relevant groups?
• Can the result be reproduced, explained, monitored, and rolled back?
• Is added complexity justified by measured benefit?

Employable algorithm engineers communicate these trade-offs clearly. They write benchmark reports, document assumptions, conduct code reviews, create tests, use version control, automate deployment checks, and collaborate with security, legal, product, and domain specialists. They recognize that algorithmic decisions are socio-technical decisions: technical design affects people through institutions and interfaces.

Contemporary Developments and Limitations

Current systems increasingly combine vector search, streaming algorithms, heterogeneous accelerators, privacy-preserving computation, federated learning, and automated optimization. These developments offer efficiency and new capabilities but also create new failure modes. Approximate methods may sacrifice recall; federated systems may suffer from heterogeneous data and communication costs; automated optimizers may exploit metrics in unintended ways; and hardware specialization can reduce portability.

No benchmark captures every production condition, and no fairness metric resolves every ethical question. Learned data structures may degrade under distribution shift. Energy measurements can omit embodied hardware impacts. Governance documents can become obsolete unless ownership and review schedules are explicit. Consequently, algorithm engineering is an ongoing lifecycle practice rather than a one-time design phase.

Chapter Summary

Algorithm engineering extends algorithm analysis into the real world. It combines correctness, complexity, benchmarking, profiling, testing, optimization, software maintenance, and operational monitoring. Asymptotic analysis explains growth, while empirical measurement reveals constants, memory behavior, hardware effects, and workload-specific performance. Amdahl’s law shows why end-to-end optimization must target dominant costs.

Standard libraries usually improve reliability, but their guarantees, complexity, security properties, and licensing must be understood. AI/ML pipelines depend on indexes, queues, graphs, heaps, caches, streaming algorithms, and distributed processing, and must be evaluated using operational as well as predictive metrics.

Responsible systems address fairness, privacy, security, reproducibility, accountability, and energy use. Hardware-aware and learned data structures can improve efficiency under suitable assumptions, but require strong baselines, fallback behavior, and monitoring. The central professional principle is evidence-based trade-off analysis: optimize what matters, preserve correctness, document assumptions, and govern consequences throughout the system lifecycle.

Key Terms

Algorithm engineering: The design, implementation, measurement, and maintenance of algorithms in real systems.

Asymptotic analysis: Study of resource growth as input size increases.

Amdahl’s law: A relationship limiting total speedup when only part of a system is optimized.

Benchmark: A controlled experiment used to compare performance.

Profiling: Measuring where time, memory, or other resources are consumed.

Tail latency: A high-percentile response time, such as the 95th or 99th percentile.

Throughput: Completed operations or requests per unit time.

Scalability: The ability to maintain acceptable behavior as workload or resources change.

Maintainability: Ease of understanding, testing, modifying, and operating software.

Hash index: A structure providing expected fast key lookup under suitable assumptions.

Top-k selection: Finding the k best elements without necessarily sorting all elements.

Bloom filter: A compact probabilistic membership structure that may produce false positives.

Data provenance: Information about the origin, transformation, and ownership of data.

Differential privacy: A formal approach limiting the influence of one individual’s data on a released result.

Data drift: Change in the distribution or properties of data over time.

Reproducibility: Ability to recreate or explain computational results under documented conditions.

Hardware-aware design: Adapting algorithms and layouts to processor, memory, storage, or accelerator behavior.

Learned index: An index using a predictive model to estimate data positions.

Tail risk: The possibility of severe outcomes in rare cases, including worst-case computational or social effects.

Governance: Processes assigning responsibility and controlling lawful, ethical, secure system use.

Review Questions

Short Answer Questions

1. Why is asymptotic complexity insufficient for selecting a production algorithm?

2. Distinguish latency from throughput.

3. What is the purpose of profiling?

4. Give two reasons for using standard-library data structures.

5. Why should subgroup performance be evaluated in an AI system?

Long Answer Questions

1. Explain how to design a reliable benchmark for an AI/ML data pipeline.

2. Discuss the optimization lifecycle from baseline creation through deployment monitoring.

3. Compare the benefits and risks of hash indexes, sorted indexes, and learned indexes.

4. Explain how privacy, security, and reproducibility requirements affect data-structure choices.

5. Discuss why energy efficiency should be evaluated together with accuracy, fairness, and system performance.

Analytical / Application Questions

1. A service spends 70 percent of its time in preprocessing. An optimization makes preprocessing five times faster. Use Amdahl’s law to calculate the maximum overall speedup under the stated assumptions, and interpret the result.

2. A retrieval system must return the best 20 items from ten million candidates. Explain why a bounded top-k method may be preferable to complete sorting, and identify conditions that could change the decision.

3. Design an evaluation and governance plan for a benefits-eligibility model that includes performance, subgroup fairness, privacy, security, reproducibility, and rollback criteria.

Multiple Choice Questions with Answers

Question 1

Which activity should normally occur before performance optimization?

A. Disabling output validation

B. Establishing a correct baseline

C. Replacing all library code

D. Increasing hardware capacity

Correct Answer: B. Establishing a correct baseline

Question 2

What does profiling primarily help an engineer identify?

A. The legal owner of a dataset

B. The functions or resources consuming most execution time

C. The protected attributes in a dataset

D. The exact future workload

Correct Answer: B. The functions or resources consuming most execution time

Question 3

If 80% of execution time is improved by a factor of 4, what is the total speedup according to Amdahl’s law?

A. 1.25

B. 2.0

C. 2.5

D. 4.8

Correct Answer: C. 2.5

Question 4

For q lookups in n records, what is the expected total search complexity when a hash index is built once?

A. O(qn)

B. O(n + q)

C. O(log n)

D. O(q log q)

Correct Answer: B. O(n + q)

Question 5

Why can the 99th-percentile latency be important in a user-facing service?

A. It measures only memory usage

B. It reveals the experience of unusually slow requests

C. It always equals average latency

D. It eliminates the need for throughput measurement

Correct Answer: B. It reveals the experience of unusually slow requests

Question 6

Which statement about a Bloom filter is correct?

A. It guarantees no false positives

B. It supports exact ordering of all keys

C. It can use compact space but may produce false positives

D. It always stores the complete original records

Correct Answer: C. It can use compact space but may produce false positives

Question 7

Which practice most directly supports reproducible experiments?

A. Changing dependencies between runs

B. Recording code, data, configuration, and dependency versions

C. Removing random seeds from documentation

D. Reporting only the best result

Correct Answer: B. Recording code, data, configuration, and dependency versions

Question 8

What is a key risk of a learned index?

A. It cannot perform any lookup

B. It may degrade when the key distribution changes

C. It always uses more memory than a full database

D. It eliminates the need for fallback search

Correct Answer: B. It may degrade when the key distribution changes

Question 9

Which is an example of a security concern related to algorithmic complexity?

A. A well-documented variable name

B. An exploitable worst-case hash-table behavior causing resource exhaustion

C. A deterministic unit test

D. A compressed model with lower latency

Correct Answer: B. An exploitable worst-case hash-table behavior causing resource exhaustion

Question 10

Why is predictive accuracy alone insufficient for evaluating a deployed AI system?

A. Accuracy cannot be calculated for any model

B. Operational, fairness, privacy, security, and consequence measures may also matter

C. Accuracy is always unrelated to outcomes

D. Accuracy measures energy consumption directly

Correct Answer: B. Operational, fairness, privacy, security, and consequence measures may also matter