SageMaker Model Cards
Model card mencatat tujuan, keterbatasan, data, dan evaluasi sebuah model dalam bentuk yang bisa diaudit. Exam guide menyebutnya sebagai alat kepatuhan.
Intisari
- Dokumentasi terstruktur: maksud pemakaian, keterbatasan, metrik evaluasi, dan penanggung jawab.
- Berversi dan punya status — dari draft sampai approved.
- Bisa dibuat lewat API, jadi bisa diisi otomatis dari pipeline evaluasi.
- Untuk aplikasi berbasis Bedrock, yang kamu dokumentasikan adalah sistemmu, bukan model dasarnya.
- Disebut di exam guide sebagai cara mendokumentasikan keterbatasan FM dan mendukung kesiapan audit.
Kenapa ini relevan padahal kamu tidak melatih model
Kamu memang tidak melatih foundation model. Tapi kamu membangun sistem yang memakainya, dan sistem itu punya maksud pemakaian, keterbatasan, dan perilaku yang perlu didokumentasikan. Saat regulator atau auditor internal bertanya "bagaimana keputusan ini dihasilkan dan apa batasnya", model card adalah bentuk jawabannya.
Isi yang berarti
| Bagian | Untuk aplikasi Bedrock, isinya |
|---|---|
| Maksud pemakaian | "Menjawab pertanyaan karyawan tentang kebijakan HR internal" |
| Di luar cakupan | "Bukan untuk nasihat hukum, medis, atau keputusan kepegawaian" |
| Model dasar | Model ID dan versinya, serta region |
| Data | Sumber knowledge base, kapan terakhir disegarkan |
| Evaluasi | Skor pada dataset uji, tanggal pengukuran |
| Keterbatasan | Tingkat halusinasi yang diketahui, topik yang lemah, bahasa yang didukung |
| Pengaman | Guardrail versi berapa, filter apa yang aktif |
| Penanggung jawab | Tim dan orang yang bisa dihubungi |
Membuatnya dari kode
import json
import boto3
sm = boto3.client("sagemaker")
sm.create_model_card(
ModelCardName="asisten-hr-internal",
Content=json.dumps({
"model_overview": {
"model_description": "Asisten tanya jawab kebijakan HR berbasis RAG",
"model_creator": "Tim Platform",
},
"intended_uses": {
"purpose_of_model": "Menjawab pertanyaan karyawan tentang kebijakan internal",
"intended_uses": "Portal internal karyawan",
"factors_affecting_model_efficiency": (
"Kualitas jawaban bergantung pada kesegaran knowledge base "
"dan cakupan dokumen sumber"
),
"risk_rating": "Medium",
},
"evaluation_details": [{
"name": "evaluasi-rilis-2026-08",
"metric_groups": [{
"name": "kualitas",
"metric_data": [
{"name": "grounding", "type": "number", "value": 0.91},
{"name": "relevansi", "type": "number", "value": 0.88},
],
}],
}],
}),
ModelCardStatus="Draft",
)Nilai sesungguhnya muncul saat ini diotomatiskan. Model card yang diisi tangan sekali lalu
ditinggalkan tidak berguna — ia jadi dokumen yang lebih menyesatkan daripada tidak ada. Isi bagian
evaluation_details dari stage evaluasi di pipeline (Fase 2), sehingga setiap rilis memperbarui
angkanya sendiri.
Status dan versi
| Status | Artinya |
|---|---|
Draft | Masih disusun |
PendingReview | Menunggu tinjauan |
Approved | Disetujui untuk produksi |
Archived | Tidak dipakai lagi |
Setiap perubahan membuat versi baru, sehingga kamu bisa menjawab "apa yang kami ketahui tentang sistem ini pada bulan Maret" — pertanyaan yang selalu muncul setelah insiden.
Tempatnya dalam tata kelola
| Pertanyaan tata kelola | Dijawab oleh |
|---|---|
| Sistem ini untuk apa dan apa batasnya? | Model card |
| Siapa memanggil apa? | CloudTrail |
| Apa yang ditanyakan dan dijawab? | Model invocation logging |
| Data ini dari mana asalnya? | Sitasi knowledge base, tag metadata, Glue Data Catalog |
| Kualitasnya membaik atau memburuk? | Evaluasi berkala (Fase 7) |
Latihan: tulis model card untuk aplikasi RAG yang kamu bangun sepanjang roadmap ini. Isi bagian "di luar cakupan" dan "keterbatasan" dengan jujur berdasarkan yang kamu amati di latihan-latihan sebelumnya — bagian itu yang paling sering kosong, dan justru yang paling dibaca auditor.
Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.