14.7: Detailed Figure Captions - Chapter 14

Machine Learning for Analytics and Future Trends — Figure Specifications

Overview

• Chapter: 14 — Machine Learning for Analytics and Future Trends

• Total Figures Proposed: 8

• Figure Types Used: Comparison Table, Flowchart, Architecture Diagram, Conceptual Illustration, Network Diagram, Infographic

---

Figure 14.1.1

Title: Traditional vs. Advanced ML Methods Comparison

Detailed Caption: A five-row, three-column matrix anchors the figure, its header row in navy carrying the column labels "Dimension," "Traditional Methods," and "Advanced ML Methods," with alternating teal-highlighted rows aiding horizontal scanning. Each row isolates one trade-off dimension: Model Complexity contrasts "simple, interpretable" classics such as logistic regression against "complex, often opaque" deep neural networks; Data Requirements notes that traditional models work with smaller datasets while advanced ML demands large datasets and greater compute; Accuracy marks traditional methods as adequate for simpler tasks and advanced methods as superior on nonlinear problems; Maintenance frames simpler models as easier to update versus the extensive GPU infrastructure that large ensembles require; and Interpretability distinguishes transparent reasoning from the black-box outputs that require dedicated XAI tooling. Small icons — a single decision tree for the traditional column, a layered neural-network glyph for the advanced column — provide rapid visual anchors at the top of each column. By consolidating four dimensions of comparison that the surrounding prose discusses in sequence, the table lets students pause, re-read, and cross-reference trade-offs without holding them in working memory simultaneously, making the core argument of Section 14.1 — that the right model depends on the specific constraints of each deployment context — visible at a glance.

---

Figure 14.1.2

Title: Ensemble Methods Overview — Bagging, Boosting, and Stacking

Detailed Caption: Three vertically bordered panels sit side by side under the shared heading "Ensemble Methods," each depicting a distinct strategy for combining learner outputs. The left "Bagging" panel shows a single dataset splitting into three bootstrapped subsets, each flowing into an independent model box, with all three outputs converging at a warm-gold "Average / Majority Vote" terminal — emphasizing that the models train in parallel and contribute equally. The center "Boosting" panel shows a sequential chain of three model boxes linked by forward arrows, each accompanied by a "Focus on errors" feedback label, with the chain terminating in a "Weighted Sum" box — making visible the key distinction that each boosting iteration deliberately corrects its predecessor. The right "Stacking" panel shows three structurally different model types — labeled "Tree," "SVM," and "Neural Net" — each producing outputs that feed upward into a "Meta-Learner" box that issues the final prediction, illustrating that stacking exploits model diversity rather than repetition. By mapping the three strategies onto a common left-to-right slot that shows inputs, combination mechanism, and output terminal, the figure prevents the frequent student confusion of treating bagging and boosting as interchangeable names for "using multiple models," and instead makes the structural difference in how and when models interact the central visual message.

---

Figure 14.2.1

Title: AutoML End-to-End Workflow

Detailed Caption: A left-to-right horizontal pipeline carries seven labeled stage boxes connected by teal arrows: "Raw Data" (cylinder icon) flows into "Data Preprocessing," then "Feature Engineering," then "Algorithm Selection" (with small icons for Random Forest, GBM, Neural Net, and Linear Model), then "Hyperparameter Tuning," then "Model Evaluation" (leaderboard icon), and finally "Best Model" (star icon). A large dashed rounded rectangle labeled "Automated by AutoML" encompasses stages two through six, visually demarcating the boundary between human action and machine orchestration. Outside that boundary on the left, a human-figure icon labeled "User: Provides data + target column" marks the entry point; on the right, a second human-figure icon labeled "User: Reviews results + deploys" marks the exit. By making the automation boundary an explicit visual container rather than a prose claim, the figure resolves the most common conceptual confusion about AutoML — that it eliminates the analyst entirely — and instead shows precisely which labor is automated (preprocessing through evaluation) and which judgment remains human (scoping the problem and validating the output before deployment).

---

Figure 14.3.1

Title: Augmented Intelligence — Human-AI Collaboration Model

Detailed Caption: A circular feedback loop dominates the figure, connecting two rounded-rectangle entities. The left "AI System" entity contains three stacked sub-boxes — "Pattern Detection," "Predictive Models," and "Anomaly Alerts" — representing the machine's contribution. The right "Human Analyst" entity contains three corresponding sub-boxes — "Interpret Insights," "Apply Domain Knowledge," and "Make Decisions" — representing the human's contribution. Two large curved arrows form the loop: the upper arrow, labeled "Surfaces insights, predictions, recommendations," flows from AI to Human, and the lower arrow, labeled "Provides feedback, adjusts parameters, validates results," flows from Human back to AI, making explicit that information travels in both directions. Three warm-gold example-application boxes beneath the loop — "Credit Decisions," "Customer Service Triage," and "Sales Forecasting" — ground the abstract loop in concrete enterprise contexts. By rendering the human as an equal node in the cycle rather than a downstream recipient of AI output, the figure makes the chapter's definitional distinction between automation and augmented intelligence structurally visible: the human is not replaced but is instead the entity that closes the loop, and the quality of final decisions depends on both nodes functioning correctly.

---

Figure 14.4.1

Title: Edge Computing vs. Cloud Analytics Architecture

Detailed Caption: The figure splits vertically into two labeled tiers. The upper "Traditional Cloud Analytics" tier shows multiple IoT device icons — a factory sensor, a camera, and a vehicle — each sending individual arrows upward to a single large cloud icon labeled "Central Cloud — All Processing Here," with an annotation marking "High latency, high bandwidth." The lower "Edge Computing Analytics" tier shows the same device icons, but each now connects first to a nearby small box labeled "Edge Node" where a sub-label reads "Local filtering, real-time alerts, anomaly detection"; from the edge nodes, thinner arrows continue upward to a cloud icon now relabeled "Cloud — Aggregation and deep analysis only," annotated "Low latency, reduced bandwidth." Three use-case icons at the base of the figure — "Predictive Maintenance" (gear), "Smart Retail" (camera), and "Connected Vehicles" (car) — connect the architecture to the industrial applications discussed in the surrounding text. The side-by-side tier layout makes the latency argument visible without requiring arithmetic: the same data traverses one hop in the edge tier versus crossing the full network distance in the cloud tier, and the thinner arrows in the edge tier visually encode the reduction in bandwidth that results from local pre-filtering before cloud transmission.

---

Figure 14.4.2

Title: Explainable AI — SHAP and LIME Interpretation Methods

Detailed Caption: Two panels sit side by side, each illustrating one explainability technique using the same loan-approval context. The left "SHAP" panel opens with a black "Complex Model" box receiving a "Loan Application" input arrow, then presents a waterfall-style horizontal bar chart listing five features vertically: "Income" and "Credit Score" carry long teal bars extending rightward toward "Approve," while "Debt-to-Income Ratio" and "Loan Amount" carry warm-gold bars extending leftward toward "Reject," and "Employment Years" adds a short positive bar; a dashed vertical line marks the base value, making each feature's additive contribution legible as a signed magnitude. The right "LIME" panel shows a 2-D scatter plot with a complex curved navy decision boundary representing the black-box model, then overlays a zoomed circle around a single highlighted point labeled "This prediction," fills that region with perturbed sample points, and fits a simple straight line labeled "Local linear approximation" through them; below the plot, a plain-text summary reads "Local explanation: Income (+), Credit Score (+), High Debt (−)." By using a single shared example across both panels, the figure enables direct comparison of the two approaches: SHAP decomposes the global model's output into per-feature contributions via Shapley values, while LIME sidesteps the global model entirely and builds a fresh interpretable surrogate only in the neighborhood of the prediction being explained.

---

Figure 14.4.3

Title: Data Mesh Architecture — Domain-Oriented Decentralized Data Ownership

Detailed Caption: A three-layer vertical hierarchy structures the figure. At the top, a full-width navy bar labeled "Federated Governance Layer" carries three sub-labels — "Standards," "Security Policies," and "Quality Rules" — representing the organization-wide rules that apply to all domains. Beneath it, a teal rounded rectangle labeled "Central Data Catalog & Self-Serve Platform" acts as the shared infrastructure through which domain teams discover and access each other's data products. Below that, four domain boxes sit in a horizontal row — "Sales," "Marketing," "Operations," and "Finance" — each subdivided into two labeled data products (e.g., "Customer Data Product" and "Revenue Data Product" within Sales), with bidirectional arrows connecting each domain box upward to the central catalog. Lighter warm-gold cross-domain arrows between adjacent domain boxes, labeled "Cross-domain analytics," show that teams query peer domains directly once they find the data through the catalog. Four principle labels at the bottom of the figure — "1. Domain Ownership," "2. Data as a Product," "3. Self-Serve Platform," "4. Federated Governance" — anchor each structural element to the data mesh principle it embodies. By mapping the four principles onto distinct visual layers, the figure prevents the common misconception that data mesh is simply a renamed data lake, instead showing that the architecture's defining feature is distributed ownership coordinated through shared infrastructure rather than centralized custody.

---

Figure 14.4.4

Title: Federated Learning Process

Detailed Caption: A central "Aggregation Server" rounded rectangle sits in the middle of the figure, surrounded in a circular arrangement by four device nodes — "Hospital A," "Hospital B," "Mobile Device 1," and "Mobile Device 2" — each carrying a sub-label that reads "data stays local." Four numbered steps are rendered as labeled arrows tracing a clockwise cycle: Step 1 arrows flow outward from the server to all devices, labeled "Distribute global model"; Step 2 is rendered as a label inside each device box reading "Train locally on private data"; Step 3 arrows flow inward from all devices back to the server, labeled "Send model updates only (gradients/weights)"; and Step 4 is a label inside the server box reading "Aggregate updates into improved global model." A prominent crossed-out red arrow between a device and the server, labeled "Raw data NEVER transferred," interrupts the visual flow to mark the privacy guarantee explicitly. A key-insight box at the bottom reads "Privacy preserved: only model parameters travel, not sensitive data." By assigning each step a number and a direction within the same circular layout, the figure makes the counter-intuitive core of federated learning — that a shared model improves without any participant ever surrendering their data — legible as a concrete mechanical cycle rather than an abstract claim.