A tradeoff is a design compromise: improving one property requires accepting a cost or reduction in another. ML systems rarely optimize accuracy, effort, interpretability, latency, throughput, cost, reliability, flexibility, and security simultaneously. The practical task is to decide which properties matter most for the system’s business context. section 15.2 section 15.6
Use tradeoffs to make concrete design choices:
- Compare baseline options by accuracy, development effort, interpretability, and computation time; start simply unless added complexity produces meaningful gains. section 8.7
- Prefer a small set of strong, diverse features over many redundant features, while balancing predictive performance against interpretability and maintenance effort. section 11.1.1
- Prioritize production requirements instead of optimizing every serving characteristic; research flexibility and production performance may require an interframework medium. section 15.6
- Use goals and antigoals to identify important properties and explicitly discard concerns that do not support the system’s main objective. section 4.2
Choosing what not to optimize
A boutique recommendation system serving fewer than 1,000 goods and low traffic does not need extreme scalability. Treating scalability as an antigoal keeps attention on the properties that support the actual business goal. Similarly, an internal reporting system may treat processing time as an antigoal when reports only need to be ready by morning. section 4.2
Figure 4.1 A shop with <1,000 goods for sale and low traffic should not aim for scalability when building a recommendation system, as almost any tech solution can handle its load these days.
Use the figure to compare a boutique store’s modest catalog and traffic with the unnecessary scalability target. section 4.2
