Conclusion

Keith VanderLinden
Calvin University

• C. Huyen acknowledges “human” issues by addressing:
  • Stakeholders in DMLS 1-2.
  • The rest as an heterogeneous bundle at the end of the book: UX; Project management; Responsible AI.

User Experience

ML Systems behave differently than traditional software systems.

• They are probabilistic, potentially:
  • Inconsistent
  • Incorrect
• They can be slow.

These all affect the User eXperience (UX).

• In earlier modules, C. Huyen noted the difference between ML systems and traditional software systems and discussed how that affected system design, development, and deployment. Here, she focuses on implications for HCI (aka, UI/UX).
• They are probabilistic, potentially:
  • Inconsistent
    • Consistency is a key principle of UX. Using UX patterns is good, even if there might be a better, new pattern.
    • E.g., my appreciation of the file menu on the original mac.)
  • Incorrect
    • Human-in-the-loop solutions tend to provide multiple answers, allowing the user to choose the best one.
    • E.g., B. Abernethy’s tech interview question - “Discuss which of these 4 co-pilot results is the one you’d drop/keep, and why?”.
• They can be slow.
  • The best can be the enemy of the good here. A fast/good answer can be better than a slow/perfect one.
  • E.g., the value of simpler models that are “good enough” and also much smaller and faster. The value of this rests, in part, on the acknowledgment that the ML system isn’t expected to give the final, perfect answer, and perhaps also that there is no perfect answer to be found.
• Solutions to these issues are work-in-progress.

Development Team Structure

ML projects tend to follow one of two approaches to team structure:

• Specialization
• Generalization

Regardless of the approach taken, subject-matter experts are always required, throughout the process.

• We included some basic project management material in module 3; here, Huyen addresses team structure.
• Specialization
  • Huyen focuses on separating Ops from DS.
  • The idea is for teams to be built of specialists.
  • This follows in the line of F.P. Brooks’s surgical team analogy.
    • The surgical team was decided hierarchical, with one central prodigious individual, and a cast of support staff.
    • Modern specialized teams have perhaps less need of the central figure and the (largely clerical) support staff. The availability of (clerical) support tools makes teams more egalitarian.
• Generalization
  • There’s too much stuff for any one person to know. Building powerful, appropriate levels of abstraction (i.e., good tools) is key.
    • Cf. C. Huyen’s followup (retraction?) of Figure 11-2.
• At some level, ML systems are black boxes that take numbers and produce numbers. Domain expertise is needed to understand the data in the context of the problem. Cf. agile programming’s insistence on involving customers.

References

• C. Huyen’s posting that led to chapter 11.

Responsible AI

ML developers/deployers are responsible to understand/address:

• Sources of bias.
• Limits of ML/AI systems.
• Key tradeoffs.
• Value of integrating ethics.

If we can do this well, we might approach DeMarco’s definition of quality software: software that makes the world a better place.

• Responsible AI is the practice of designing, developing, and deploying AI systems with good intention and sufficient awareness to empower users, to engender trust, and to ensure fair and positive impact to society.
  • C. Huyen (p. 340)
• Huyen gives two case studies; review them to get through the preparation quiz.
• Framework - Understand our “responsibility” to understand/address the:
  • Sources of bias. These are everywhere. Establish process to deal with them (e.g., team reviews).
    • Cf. Postman’s idea #2 (Benefits unevenly distributed).
    • SLO tweets are skewed toward people with access to social media.
  • Limits of ML/AI systems. Data can only take you so far; use domain experts.
    • Cf. Postman’s idea #1 (Giveth and taketh away).
    • SLO needed experts to step to dig deeper.
  • Key tradeoffs. Mostly, these are about fairness and accuracy for under-represented groups.
    • Cf. Postman’s idea #1 (Giveth and taketh away).
    • SLO never really addressed privacy issues of using social media data.
  • Value of integrating ethical considerations throughout the process.
    • Cf. our approach of considering Postman’s ideas throughout.
    • SLO never really addressed the problems with using social media data in general.
• Notes
  • These considerations are complementary to Postman’s ideas, which address the deployment of new technologies in general.
  • We should acknowledge that as a fast-moving, technological field, AI/ML has tended to leave ethical considerations behind.
• Cf. DeMarco’s definition of quality software - that which makes the world a better place.