User Tools

Site Tools


add-rebuttal

This is an old revision of the document!


Understanding Gaps in ML Fairness Tool Design: An Experience Report

Venue: VL/HCC '26
Authors: Anonymous

Short Summary

The authors conducted a semi-structured interview of professionals who use two common ML fairness tools (IBM AIF360 and Microsoft Fairlearn), and reported on several areas in which these tools fail to aid practitioners in understanding and mitigating fairness concerns.

The Review

This paper contributes by recording areas in which ML fairness tools fall short of expectations. It is clear to me that this contribution is worth sharing with the broader community as we decide how to make ML-assisted decision-making more fair.

Furthermore, I think that the specific findings are useful information for practitioners and tool designers alike, and expose an interesting deficiency in fairness tool design, namely, limited flexibility and actionability.

My primary concern with the paper is the discussion of related work. Though I am not an expert in the area of ML fairness, I still feel that a little more specific discussion of the related work is warranted. It seems that the work by Deng. et al. (2022) is most related. I wish that the authors would explain more specifically how this work relates to that one, since they do seem quite similar in motivation.

Some of the related work mentioned in the introduction also seems only loosely related to this paper. For example, Citation 8 (Lipsitz, 2006) does indeed discuss biased loan applications, but (based on my cursory scan) in the context of the 1980s, not in terms of machine learning as implied by the surrounding text.

As another example, I expected citation 17 (Quy et al., 2022) to provide evidence that IBM AIF360 and Microsoft Fairlearn were widely adopted in practice, but the paper doesn't seem to mention these tools at all, and is instead a survey of fairness datasets.

I cannot understand the context of the very next citation (19, Johnson et al., 2013) either. The authors I think need to give more context as to why this paper is relevant (it is about static analysis).

At a high-level, I think that the authors should be careful to only cite truly related work, and for this most related work, help situate it in the corpus. As a reader, I would much prefer fewer citations but a thorough discussion of each, rather than a smattering of only vaguely related works. I've recommended weak accept because I think that the main contribution of the paper, being the interview and its findings, is of value to the community. However, I think that the discussion of related work needs to be reconsidered.

Below I have written some minor local “nitpicks” which don't factor into my decision:

  • First paragraph of the introduction: “effectively support human capabilities” is a little vague. Which capabilities are you referring to precisely?
  • AIF 360 and Fairlearn are, as far as I can tell, not cited directly, but they probably should be.
  • It would be nice if Figure 2 could come sooner in the text, probably on the previous page.
  • “These divergent accounts illustrate that the community support, where it exists, is personal and informal rather than systemic.” Is the last word supposed to be “systematic”?
  • In the following paragraph, there seems to be some fragment of a language model response: “Yes, it sounds formal, but 'may reflect' is a bit weak and hedged…”
  • “not because they lacked technical competence, but …” We have evidence of the participants' education, but I don't view that as evidence for technical competence. Furthermore, I'm not sure technical competence is well enough defined to say it would help in the fairness task.
  • “…without guidance and to maintain tools that were never designed to last.” This seems a little bit harsh, not knowing the intent of the tool authors.

Notes

Method

  • Semi-structured interviews of 10 participants
  • Each interview is around 30 minutes, centered on professional's experience using ML fairness tools.

Results

  • Authors identified four areas in which current tools are lacking:
    1. Lack of Diverse Metrics
      • The authors reported that both of the tools have many metrics, but they seem to encode largely the same information
      • It is difficult to characterize the interactions between multiple attributes. I.e., the tool only allows one explicitly-mentioned attribute to be analyzed at a time. Extra analysis must be performed “out of band.”
    2. Lack of Data Ingestion Support
      • Participants noted that the data inputs must be highly structured.
        • For systems which are largely text/natural language based, this poses a challenge, since the data is expected to be tabular.
        • Makes the existing tools not practical for contemporary AI uses
    3. Output Actionability
      • Tool outputs are not actionable, and it's not clear to the practitioner what the correct mitigation is, even when the tool indicates that bias takes place.
      • Tools outputs are mainly statistical parameters.
        • Question to self: What are the mitigations that have been proposed? (Track down related work)
    4. Inadequate Tool Maintenance
      • The tools are “conference ware” and are supported either not at all or somewhat informally.

Rebuttal

We thank the reviewers for their comments and address their questions and concerns below. 1.Comparison to the most closely related prior work (e.g., Deng et al. 2022), and ensuring only truly related citations are included(R1): Deng et al. study the usability of fairness tools in a controlled onboarding setting, whereas our work investigates long-term design shortcomings reported by experienced practitioners in real-world workflows. Thus, the two studies address different stages of fairness tool adoption and provide complementary insights. We appreciate the reviewer for bringing the citation inconsistencies to our attention. We revised the paper and ensured that the appropriate citations for references 8 and 17 are properly included in the updated version of the paper which will be reflected in the camera ready version. 2.ML systems and data types participants were evaluating(R2): The participants were primarily discussing supervised predictive machine learning models, mostly tabular datasets used for decision-making tasks. We clarified this in the updated version of our paper in the methodology section which will be reflected in the camera ready version. 3.Reframing tool maintenance gap as support-system failure and dependency-management tool role(R2): We thank the reviewer for this helpful comment. We agree that issues such as installation failures and deprecated dependencies are more related to tool maintenance and ecosystem support than tool design. We have revised the narratives accordingly. While dependency management tools can help resolve dependency issues, our participants also reported outdated documentation, limited community support, and unresolved issues, which these tools cannot address. All these updates will be reflected in the camera-ready version of our paper. 4.Comparing and contrasting findings with prior usability studies (R1, R2): We included more discussion at the end of the related work section, noting the novelty of the first-ever experience report for ML fairness tools, which will be reflected in the camera-ready version of the paper. 5.Circularity concern in recommending AI-generated explanations for an AI fairness-evaluation tool (R2): We agree that LLM-generated explanations can also contain errors or biases. They are intended only to support users in interpreting fairness results, not to replace fairness metrics or human judgment. We will make this clearer in the camera-ready version of the paper. 6.Reference or evidence for unsupported claims (e.g., that fairness-tool adoption is “strikingly low”) (R3): We stated this claim based on the work [18], “An investigation into fairness tool sustainability” where they showed lower adoption of fairness tools through GitHub repository analysis. 7. Report participant demographics (R3): We added the participant gender and age group in the participant table, which will be reflected in the camera-ready version of our work.

add-rebuttal.1782830075.txt.gz · Last modified: by sam