# Plantilla de tarjeta de modelo anotada > [!TIP] > ¿Listo para publicar? Consulta la [Model Release Checklist](./model-release-checklist) para conocer los pasos esenciales de una publicación de modelo concisa, informativa y fácil de usar. ## Plantilla archivo [modelcard_template.md](https://github.com/huggingface/huggingface_hub/blob/main/src/huggingface_hub/templates/modelcard_template.md) ## Instrucciones Rellenar por completo una tarjeta de modelo requiere la aportación de varios roles diferentes. (Una misma persona puede tener más de un rol.) Nos referiremos a estos roles como el **desarrollador**, quien escribe el código y ejecuta el entrenamiento; el **especialista sociotécnico**, que domina el análisis de la interacción a largo plazo entre la tecnología y la sociedad (esto incluye a abogados, éticos, sociólogos o defensores de derechos); y el **organizador del proyecto**, que comprende el alcance y la repercusión general del modelo, puede rellenar aproximadamente cada parte de la tarjeta y actúa como persona de contacto para las actualizaciones de la tarjeta del modelo. * El **developer** es necesario para completar [Training Procedure](#training-procedure-optional) y [Technical Specifications](#technical-specifications-optional). También resulta especialmente útil para la sección “Limitations” de [Bias, Risks, and Limitations](#bias-risks-and-limitations). Es responsable de proporcionar [Results](#results) para la Evaluación, e idealmente trabaja con los demás roles para definir el resto de la Evaluación: [Testing Data, Factors & Metrics](#testing-data-factors--metrics). * El **sociotécnico** es necesario para completar “Bias” y “Risks” dentro de [Bias, Risks, and Limitations](#bias-risks-and-limitations), y resulta especialmente útil para “Out of Scope Use” dentro de [Uses](#uses). * El **organizador del proyecto** es necesario para completar [Detalles del modelo](#model-details) y [Usos](#uses). También podrían completar [Datos de entrenamiento](#training-data). Los organizadores del proyecto también podrían encargarse de [Cita](#citation-optional), [Glosario](#glossary-optional), [Contacto de la tarjeta del modelo](#model-card-contact), [Autores de la tarjeta del modelo](#model-card-authors-optional) y [Más información](#more-information-optional). _Las instrucciones se proporcionan a continuación, en cursiva._ Los nombres de variables de plantilla aparecen en `monospace`. --- # Nombre del modelo **Resumen de la sección:** Proporcione el nombre del modelo y un resumen de 1 a 2 oraciones sobre lo que es el modelo. `model_id` `model_summary` # Índice **Resumen de la sección:** Proporcione esto con enlaces a cada sección para permitir a las personas saltar fácilmente entre ellas, usar el archivo en otras ubicaciones con el índice conservado, imprimir el contenido, etc. # Detalles del modelo **Resumen de la sección:** Esta sección proporciona información básica sobre qué es el modelo, su estado actual y su origen. Debe ser útil para cualquier persona que desee hacer referencia al modelo. ## Descripción del modelo `model_description` _Proporciona detalles básicos sobre el modelo. Esto incluye la arquitectura, la versión, si fue presentado en un artículo, si está disponible una implementación original y los creadores. Cualquier derecho de autor debe atribuirse aquí. También se puede mencionar información general sobre los procedimientos de entrenamiento, los parámetros y los avisos importantes en esta sección._ * **Desarrollado por:** `developers` _List (y, idealmente, enlazar con) las personas que construyeron el modelo._ * **Financiado por:** `funded_by` _List (y, idealmente, enlazar a) las fuentes de financiación que respaldaron o hicieron posible este modelo, ya sea financieramente, computacionalmente o de otra manera. * **Compartido por [opcional]:** `shared_by` _List (y, idealmente, enlazar con) las personas/organización que ponen el modelo a disposición en línea._ * **Tipo de modelo:** `model_type` _Puedes nombrar el “type” como:_ _1. Método de supervisión/aprendizaje_ _2. Tipo de aprendizaje automático_ _3. Modalidad_ * **Idioma(s)** [NLP]: `language` _Utilice este campo cuando el sistema utilice o procese lenguaje natural (humano)._ * **Licencia:** `license` _Nombre y enlace a la licencia utilizada._ * **Modelo de origen del ajuste fino [opcional]:** `base_model` _Si este modelo tiene otro modelo como base, enlázalo aquí._ ## Fuentes de modelos [opcional] * **Repositorio:** `repo` * **Artículo [opcional]:** `paper` * **Demo [opcional]:** `demo` _Proporciona fuentes para que el usuario pueda ver directamente el modelo y sus detalles. Otros tipos de recursos, como registros de entrenamiento, lecciones aprendidas, etc., deben ir en la sección [Más información](#more-information-optional). Si incluyes un elemento para esta sección, enlaza al repositorio._ # Usos **Resumen de la sección:** Esta sección aborda las preguntas sobre cómo se pretende utilizar el modelo en diferentes contextos aplicados, discute a los usuarios previsibles del modelo (incluidos aquellos afectados por él) y describe los usos que se consideran fuera de su alcance o un mal uso del modelo. Tenga en cuenta que esta sección no está destinada a incluir los detalles de uso de la licencia. Para ello, enlaza directamente con la licencia. ## Uso directo `direct_use` _Explique cómo se puede utilizar el modelo sin ajuste fino, posprocesamiento o integración en un pipeline. Se recomienda incluir un fragmento de código de ejemplo._ ## Uso aguas abajo [opcional] `downstream_use` _Explique cómo se puede utilizar este modelo cuando se ajusta para una tarea o cuando se integra en un ecosistema o aplicación más grande. Se recomienda incluir un fragmento de código de ejemplo._ ## Uso fuera de alcance `out_of_scope_use` _Enumere las formas en que el modelo podría ser utilizado de manera incorrecta (usos para los que no está diseñado) y especifique qué no deben hacer los usuarios con el modelo._ # Sesgos, riesgos y limitaciones **Resumen de la sección:** Esta sección identifica daños previsibles, malentendidos y limitaciones técnicas y sociotécnicas. También proporciona información sobre advertencias y posibles mitigaciones. El sesgo, los riesgos y las limitaciones a veces son inseparables o se refieren a los mismos problemas. En general, el sesgo y los riesgos son sociotécnicos, mientras que las limitaciones son técnicas: - Un **bias** es un estereotipo o un rendimiento desproporcionado (sesgo) para algunas subpoblaciones. - Un **riesgo** es un problema de relevancia social que el modelo podría causar. - Una **limitación** es un modo de fallo probable que puede abordarse siguiendo las recomendaciones enumeradas. `bias_risks_limitations` _¿Cuáles son los problemas conocidos o previsibles derivados de este modelo?_ ## Recomendaciones `bias_recommendations` _¿Cuáles son las recomendaciones con respecto a los problemas previsibles? Esto puede incluir desde “reducir la resolución de tu imagen” hasta filtrar contenido explícito._ # Detalles del entrenamiento **Resumen de la sección:** Esta sección proporciona información para describir y replicar el entrenamiento, incluidos los datos de entrenamiento, la velocidad y el tamaño de los elementos de entrenamiento y el impacto ambiental del entrenamiento. También se relaciona en gran medida con las [Especificaciones técnicas](#technical-specifications-optional), y el contenido de aquí debe enlazar con esa sección cuando sea relevante para el procedimiento de entrenamiento. Es útil para las personas que desean aprender más sobre las entradas del modelo y la huella de entrenamiento. Es relevante para cualquiera que desee conocer los fundamentos de lo que el modelo está aprendiendo. ## Datos de entrenamiento `training_data` _Escriba 1 o 2 oraciones sobre los datos de entrenamiento. Idealmente, esto debe enlazar a una tarjeta de conjunto de datos para obtener más información. Los enlaces a documentación relacionada con el preprocesamiento de datos o el filtrado adicional también pueden ir aquí, así como en [Más información](#more-information-optional)._ ## Procedimiento de entrenamiento [opcional] ### Preprocesamiento `preprocessing` _Detallar la tokenización, el redimensionado/reescritura (según la modalidad), etc._ ### Velocidades, tamaños, tiempos `speeds_sizes_times` _Detalles del rendimiento, hora de inicio/fin, tamaños de los puntos de control, etc._ # Evaluación **Resumen de la sección:** Esta sección describe los protocolos de evaluación, qué se mide en la evaluación y proporciona los resultados. La evaluación idealmente tiene al menos dos partes, una que analiza la medición cuantitativa del rendimiento general ([Datos de prueba, factores y métricas](#testing-data-factors--metrics)), como puede hacerse con el benchmarking; y otra que analiza el rendimiento con respecto a problemas específicos de seguridad social ([Evaluación del impacto social](#societal-impact-assessment-optional)), como puede hacerse con el red-teaming. También puede especificar los resultados de evaluación de su modelo de una manera estructurada en los metadatos de la tarjeta del modelo. Los resultados son analizados por el Hub y se muestran en un widget en la página del modelo. Consulte https://huggingface.co/docs/hub/model-cards#evaluation-results. ## Datos de prueba, factores y métricas _La evaluación es idealmente **desagregada** con respecto a diferentes factores, como la tarea, el dominio y el subgrupo de población; y se calcula con las métricas más significativas para los contextos de uso predecibles. Se dice que el rendimiento de evaluación es "justo" entre los diferentes subgrupos cuando es igual en todos ellos; las métricas de justicia objetivo deben decidirse en función de qué errores son más problemáticos a la luz del uso del modelo. Sin embargo, esta sección se utiliza con mayor frecuencia para informar sobre el rendimiento de evaluación agregado en diferentes conjuntos de referencia de tareas._ ### Datos de prueba `testing_data` _Describe los datos de prueba o enlaza a su Dataset Card._ ### Factores `testing_factors` _¿Cuáles son las características previsibles que influirán en el comportamiento del modelo? Lo ideal es que la evaluación se desagregue en función de estos factores para revelar disparidades en el rendimiento._ ### Métricas `testing_metrics` _¿Qué métricas se utilizarán para la evaluación?_ ## Resultados `results` _Los resultados deben basarse en los Factores y Métricas definidos anteriormente._ ### Resumen `results_summary` _¿Qué dicen los resultados? Esto puede funcionar como un resumen para audiencias generales._ ## Evaluación del impacto social [opcional] _Utilice esta sección de texto libre para explicar cómo se ha evaluado este modelo en cuanto al riesgo de daño social, como la seguridad infantil, el NCII, la privacidad y la violencia. Esto podría adoptar la forma de respuestas a las siguientes preguntas:_ - _¿Es seguro este modelo para que lo usen niños? ¿Por qué sí o por qué no?_ - _¿Se ha probado este modelo para evaluar los riesgos relacionados con imágenes íntimas no consensuadas (incluido el CSEM)?_ - _¿Se ha probado este modelo para evaluar riesgos relacionados con actividades violentas o representaciones de violencia? ¿Cuáles fueron los resultados?_ _También se pueden proporcionar cifras cuantitativas sobre cada problema._ # Examen del modelo [opcional] **Resumen de la sección:** Esta es una sección experimental que algunos desarrolladores están empezando a añadir, donde puede incluirse el trabajo sobre explicabilidad/interpretabilidad. `model_examination` # Impacto ambiental **Resumen de la sección:** Resume la información necesaria para calcular impactos ambientales, como el consumo de electricidad y las emisiones de carbono. * **Tipo de hardware:** `hardware_type` * **Horas usadas:** `hours_used` * **Proveedor de la nube:** `cloud_provider` * **Región de cálculo:** `cloud_region` * **Emisiones de carbono:** `co2_emitted` _Las emisiones de carbono pueden estimarse utilizando la [calculadora de impacto del aprendizaje automático](https://mlco2.github.io/impact#compute) presentada en [Lacoste et al. (2019)](https://arxiv.org/abs/1910.09700)._ # Especificaciones técnicas [opcional] **Resumen de la sección:** Esta sección incluye detalles sobre el objetivo y la arquitectura del modelo, así como la infraestructura de cómputo. Es útil para las personas interesadas en el desarrollo de modelos. La redacción de esta sección suele requerir la participación directa del desarrollador del modelo. ## Arquitectura del modelo y objetivo `model_specs` ## Infraestructura de cómputo `compute_infrastructure` ### Hardware `hardware_requirements` _¿Cuáles son los requisitos mínimos de hardware, por ejemplo, de procesamiento, almacenamiento y memoria?_ ### Software `software` # Cita [opcional] **Resumen de la sección:** La cita preferida por los desarrolladores para este modelo. A menudo se trata de un artículo. ### BibTeX `citation_bibtex` ### APA `citation_apa` # Glosario [opcional] **Resumen de la sección:** Esta sección define los términos comunes y cómo se calculan las métricas. `glossary` _Defina claramente los términos para que sean accesibles para todos los públicos._ # Más información [opcional] **Resumen de la sección:** Esta sección ofrece enlaces a escritos sobre la creación de conjuntos de datos, especificaciones técnicas, lecciones aprendidas y resultados iniciales. `more_information` # Autores de la tarjeta del modelo [opcional] **Resumen de la sección:** Esta sección enumera a las personas que crean la tarjeta del modelo, otorgando reconocimiento y responsabilidad por el trabajo detallado que implica su construcción. `model_card_authors` # Contacto de la tarjeta del modelo **Resumen de la sección:** Ofrece una forma para que las personas que tengan actualizaciones de la Model Card, sugerencias o preguntas, puedan contactar a los autores de la Model Card `model_card_contact` # Cómo empezar con el modelo **Resumen de la sección:** Proporciona un fragmento de código para mostrar cómo usar el modelo. `get_started_code` --- **Cítelo como:** Ozoani, Ezi and Gerchick, Marissa and Mitchell, Margaret. Model Card Guidebook. Hugging Face, 2022. https://huggingface.co/docs/hub/en/model-card-guidebook