NästaNästa guide
Finjustera inbäddningsmodeller för hämtning
Tekniskt
Teknisk GUIDE
A model card is a short, structured document that explains what an AI model is for, how it was evaluated, how well it performs for different groups and conditions, and where it should not be used.
A datasheet for datasets does the same for training data: why the data was collected, what it contains, how it was gathered and labeled, and how it should be maintained. These documents matter because they let buyers, users, auditors and regulators judge whether a system is fit for purpose, and laws such as the EU AI Act now require similar documentation.
Model cards were proposed by Margaret Mitchell and colleagues in the paper "Model Cards for Model Reporting", presented at the ACM FAT* conference in 2019. The suggested sections are model details, intended use, factors (such as demographic or environmental conditions), metrics, evaluation data, training data, quantitative analyses, ethical considerations, and caveats and recommendations. The key idea is disaggregated evaluation: reporting performance separately for relevant subgroups rather than as one average score that can hide failures. Datasheets for Datasets, by Timnit Gebru and colleagues, first circulated in 2018 and was later published in Communications of the ACM. It borrows from electronics datasheets. Dataset creators answer questions about motivation, composition, collection process, preprocessing and labeling, uses, distribution and maintenance. Related formats include data statements for language datasets and data cards. System cards, used by Meta and OpenAI since 2022 and prominently for GPT-4 in 2023, document a whole deployed system, including safety testing and mitigations, rather than only the model. Regulation has turned much of this practice into a requirement. The EU AI Act requires technical documentation for high-risk AI systems, set out in Annex IV. Providers of general-purpose AI models must keep technical documentation, give information to downstream providers, and publish a summary of training content using a Commission template. A common misconception is that a model card proves a model is safe. It is a disclosure, not a certification, and a card can be incomplete, outdated or written like marketing. Its value depends on honest limitations and evaluations that someone else can reproduce.
Arkitekturbeslut driver prestanda och driftskostnader i flera år.
Teknisk utbildning hjälper team att välja rätt stack, inte bara den nyaste.
Bättre tekniska val minskar tillförlitlighetsincidenter i produktionen.
Documentation is moving from voluntary best practice toward a compliance requirement. The EU AI Act, procurement rules and standards such as ISO/IEC 42001 all expect structured records of how a system was built and tested. Machine-readable formats and automated generation will likely become more common, so that cards can be checked and compared. The ongoing challenges are keeping documents accurate as models are updated, disclosing enough about training data without exposing trade secrets or personal information, and making sure readers actually use the documents when deciding.
A hospital evaluating a skin-lesion classifier reads its model card and finds accuracy was reported separately by skin tone. It then decides to run its own local validation before use.
A Hugging Face model repository shows a model card with YAML metadata listing its license, training datasets, languages and benchmark results, and people can filter search results by those fields.
A research team publishes a speech dataset with a datasheet that records speakers' consent, recording conditions and the accents that are under-represented.
An AI lab releases a system card for a chatbot describing red-teaming results, safety mitigations and the risks that remain, beyond what a basic model card covers.
Att optimera ett riktmärke kan dölja bredare systemsvagheter.
Infrastruktur- och underhållskostnader underskattas ofta.
Säkerhets- och observerbarhetsluckor kan växa i takt med att systemen blir mer komplexa.
Definiera latens-, kvalitet- och kostnadsmål före implementering.
Benchmark under realistiska belastnings- och dataförhållanden.
Instrumentövervakning för fel, drift och användarpåverkan.
Förbered återställnings- och incidentsvarsvägar innan skalning.
Free newsletter
Three verified AI stories every weekday morning, written in plain English. Free forever, no ads.
One email each weekday. Unsubscribe in one click. We never sell or share your address.
Test yourself
Instant feedback on every answer, and a shareable certificate with a verifiable ID once you pass a course.
Support free AI education. AI Understanding is a 501(c)(3) nonprofit — no ads, no paywall, ever. Make a donation
A model card is a short, structured document that explains what an AI model is for, how it was evaluated, how well it performs for different groups and conditions, and where it should not be used. A datasheet for datasets does the same for training data: why the data was collected, what it contains, how it was gathered and labeled, and how it should be maintained. These documents matter because they let buyers, users, auditors and regulators judge whether a system is fit for purpose, and laws such as the EU AI Act now require similar documentation.
A model card gives readers what they need to judge whether a model fits a particular use, including where it performs poorly.
Margaret Mitchell and colleagues presented "Model Cards for Model Reporting" at ACM FAT* in 2019.
Splitting results by subgroup exposes failures that an overall average would hide.
Electronic components come with datasheets that describe their characteristics. Gebru and colleagues applied that idea to datasets.
System cards, such as OpenAI's for GPT-4, describe a deployed product's risks, red-teaming and safeguards.
Fortsätt lära dig
Fler guider har valts för detta ämne
NästaNästa guide
Finjustera inbäddningsmodeller för hämtning
Tekniskt