Model Cards for Model Reporting

Abstract

Trained machine learning models are increasingly used to perform high-impact tasks in areas such as law enforcement, medicine, education, and employment. In order to clarify the intended use cases of machine learning models and minimize their usage in contexts for which they are not well suited, we recommend that released models be accompanied by documentation detailing their performance characteristics. In this paper, we propose a framework that we call model cards, to encourage such transparent model reporting. Model cards are short documents accompanying trained machine learning models that provide benchmarked evaluation in a variety of conditions, such as across different cultural, demographic, or phenotypic groups (e.g., race, geographic location, sex, Fitzpatrick skin type [15]) and intersectional groups (e.g., age and race, or sex and Fitzpatrick skin type) that are relevant to the intended application domains. Model cards also disclose the context in which models are intended to be used, details of the performance evaluation procedures, and other relevant information. While we focus primarily on human-centered machine learning models in the application fields of computer vision and natural language processing, this framework can be used to document any trained machine learning model. To solidify the concept, we provide cards for two supervised models: One trained to detect smiling faces in images, and one trained to detect toxic comments in text. We propose model cards as a step towards the responsible democratization of machine learning and related artificial intelligence technology, increasing transparency into how well artificial intelligence technology works. We hope this work encourages those releasing trained machine learning models to accompany model releases with similar detailed evaluation numbers and other relevant documentation.

Saving Face

“…Had we focused solely on the performance of these APIs on CelebSET, we would have missed this label selection bias and remained with an incomplete understanding of the design flaws that influence the APIs' performance. While comprehensive auditing frameworks examining model development and deployment processes are yet to be developed, documentation proposals such as datasheets [20], model cards [34] and factsheets [24] can encourage designers to carefully think about these processes if they are required elements of such an audit.…”

Losing Confidence in Quality: Unspoken Evolution of Computer Vision Services

“…Recent attempts to document attributes and characteristics on ML models have been proposed. Model cards were introduced by Mitchell et al [36] to describe how particular models were trained and benchmarked, thereby assisting users to reason if the model is right for their purposes and if it can achieve its stated outcomes. Gebru et al [37] also proposed datasheets, a standardised documentation format to describe the need for a particular data set, the information contained within it and what scenarios it should be used for, including legal or ethical concerns.…”

“…3) Improve Metadata in Response: Much of the information in these services is reduced to a single confidence value within the response object, and the details about training data and the internal AI architecture remains unknown; little metadata is provided back to developers that encompass such detail. Early work into model cards and datasheets [36,37] suggests more can be done to document attributes about ML systems, however at a minimum from our work, we recommend including a reference point via the form of an additional identifier. This identifier must also permit the developers to submit the identifier to another API endpoint should the developer wish to find further characteristics about the AI empowering the intelligent service, reinforcing the need for those presented in model cards and datasheets.…”

A conceptual architecture for contractual data sharing in a decentralised environment

“…An assembly can also contain artifacts, which is the term applied to any pertinent software components, ML models, and documentation such as licenses, policy documentation, Declarations of Conformity, 19 datasheets for data 20 or model specifications. 21 By attaching artifacts to assemblies in the BoM definition we can ensure that each BoL retains a full record of its heritage and dependencies.…”