> ## Documentation Index > Fetch the complete documentation index at: https://avala.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Taxonomía de etiquetas y ontología > Diseñe taxonomías de etiquetas efectivas con clases, atributos y jerarquías Una taxonomía de etiquetas bien diseñada es la base de cualquier proyecto de anotación. Esta página cubre cómo estructurar sus clases de objetos, configurar atributos y construir jerarquías que produzcan datos de entrenamiento consistentes y de alta calidad. ## ¿Qué es una ontología? En el contexto de la anotación de datos, una **ontología** (o taxonomía de etiquetas) es el esquema completo de clases, atributos y relaciones que los anotadores usan para etiquetar datos. Define: * **Qué** objetos etiquetar (clases de objetos) * **Cómo** describirlos (atributos y propiedades) * **Cómo** se relacionan las clases entre sí (jerarquía y agrupación) Una ontología clara reduce la confusión del anotador, mejora el acuerdo entre anotadores y produce datos de entrenamiento más limpios para sus modelos. ## Clases de objetos Las clases de objetos son los bloques de construcción fundamentales de su taxonomía. Cada clase representa una categoría de objeto que los anotadores identificarán y etiquetarán en los datos. ### Definición de clases Al crear un proyecto en Avala, define su configuración de etiquetas como una lista de clases: ```json theme={null} { "labels": [ { "name": "car", "color": "#FF0000" }, { "name": "pedestrian", "color": "#00FF00" }, { "name": "cyclist", "color": "#0000FF" }, { "name": "truck", "color": "#FFA500" }, { "name": "bus", "color": "#800080" } ] } ``` Cada clase tiene un nombre único y un color de visualización usado en el editor de anotación. Elija colores que sean visualmente distintos entre sí y de los colores de fondo comunes en sus datos. ### Mejores prácticas para nombrar clases | Práctica | Ejemplo | Razón | | ------------------------------------------------------ | --------------------------------------------------- | ------------------------------------------------------- | | Use nombres en minúscula y específicos | `sedan`, `pickup_truck` | Reduce la ambigüedad | | Evite definiciones superpuestas | No tenga `car` y `vehicle` al mismo nivel | Evita confusión del anotador | | Sea consistente con los separadores | `traffic_light` no `traffic-light` o `trafficLight` | Parsing consistente en pipelines de entrenamiento | | Incluya clases negativas/de fondo solo si es necesario | `unknown`, `ignore_region` | Algunos modelos requieren etiquetas de fondo explícitas | ## Atributos Los atributos añaden metadatos estructurados a cada anotación más allá de la clase de objeto. Permiten a los anotadores describir propiedades como visibilidad, pose o condición. ### Tipos de atributos Avala soporta varios tipos de atributos que puede adjuntar a cualquier clase de objeto: | Tipo | Descripción | Cuándo usar | Ejemplo | | ---------------- | ---------------------------------------- | -------------------------------------- | -------------------------------------------------- | | **Dropdown** | Selección única de una lista predefinida | Opciones mutuamente excluyentes | Oclusión: `none`, `partial`, `heavy` | | **Checkbox** | Alternador booleano | Indicadores simples sí/no | `is_parked: true/false` | | **Text** | Entrada de texto libre | Identificadores únicos o descripciones | Número de placa | | **Number** | Valor numérico | Medidas o conteos | Distancia estimada en metros | | **Multi-select** | Múltiples selecciones de una lista | Estados concurrentes no excluyentes | Visible: `headlights`, `taillights`, `turn_signal` | Comparación de tipos de atributos Comparación de tipos de atributos ### Configuración de atributos Los atributos se definen en la configuración de clasificación del proyecto junto con la configuración de etiquetas: ```json theme={null} { "labels": [ { "name": "car", "color": "#FF0000" } ], "classification": { "attributes": [ { "name": "occlusion", "type": "dropdown", "options": ["none", "partial", "heavy"], "required": true, "applies_to": ["car", "pedestrian", "cyclist"] }, { "name": "is_parked", "type": "checkbox", "required": false, "applies_to": ["car", "truck", "bus"] }, { "name": "truncation", "type": "dropdown", "options": ["none", "partial", "heavy"], "required": true, "applies_to": ["car", "pedestrian", "cyclist"] } ] } } ``` ### Atributos condicionales Use el campo `applies_to` para mostrar atributos solo para clases relevantes. Esto mantiene la interfaz del anotador limpia — un `pedestrian` no necesita un atributo `is_parked`, y un `traffic_light` no necesita `truncation`. Marque los atributos como `required` para propiedades de las que depende su pipeline de entrenamiento de modelo. Deje los atributos opcionales para metadatos complementarios que son útiles pero no críticos. ## Taxonomías jerárquicas Para dominios complejos, las listas planas de clases se vuelven difíciles de manejar. Las taxonomías jerárquicas agrupan clases relacionadas bajo categorías padre. ### Ejemplo: Taxonomía de vehículos ``` Vehicle ├── Car │ ├── Sedan │ ├── SUV │ └── Hatchback ├── Truck │ ├── Pickup │ └── Semi ├── Bus │ ├── City Bus │ └── School Bus └── Motorcycle ``` ### Cuándo usar jerarquías | Escenario | Recomendación | | ------------------------------ | ---------------------------------------------------- | | Menos de 15 clases | Una lista plana es más simple y rápida | | 15-50 clases | Agrupar en 3-5 categorías de nivel superior | | 50+ clases | Usar jerarquía multi-nivel con búsqueda | | Las clases comparten atributos | Agrupar bajo padre para que los atributos se hereden | ### Diseño de jerarquías 1. **Comience amplio, luego refine.** Empiece con categorías de nivel superior (`vehicle`, `pedestrian`, `infrastructure`) y añada especificidad solo donde su modelo lo necesite. 2. **Cada clase hoja debe ser inequívoca.** Si los anotadores no pueden distinguir de manera confiable entre dos subclases, fusiónelas. 3. **Equilibre profundidad y amplitud.** Las jerarquías profundas (4+ niveles) ralentizan a los anotadores. Prefiera árboles más anchos con 2-3 niveles. ## Clasificación de etiqueta única vs multi-etiqueta Avala soporta ambos modos de clasificación según las necesidades de su proyecto. ### Etiqueta única Cada objeto o escena recibe exactamente una etiqueta de clase. Este es el valor por defecto para la mayoría de los tipos de anotación. * Detección de objetos: Cada bounding box recibe una clase * Clasificación de escena: Cada imagen recibe una categoría ### Multi-etiqueta Un objeto o escena puede recibir múltiples etiquetas simultáneamente. Use esto cuando las categorías no son mutuamente excluyentes. * Una imagen puede ser tanto `rainy` como `nighttime` * Un vehículo puede estar tanto `damaged` como `parked` Configure la clasificación multi-etiqueta en la configuración de clasificación de su proyecto estableciendo el tipo de clasificación a nivel de tarea: ```json theme={null} { "classification": { "type": "multi-label", "categories": [ { "name": "weather", "options": ["clear", "rainy", "foggy", "snowy"] }, { "name": "time_of_day", "options": ["daytime", "nighttime", "dawn", "dusk"] }, { "name": "road_condition", "options": ["dry", "wet", "icy"] } ] } } ``` ## Lista de verificación para diseño de ontología Antes de iniciar su proyecto de anotación, verifique su ontología contra esta lista: | Verificación | Pregunta | | ----------------------------- | ---------------------------------------------------------------------------------------- | | **Completitud** | ¿Cada objeto que su modelo necesita detectar tiene una clase? | | **Exclusividad mutua** | ¿Puede un anotador siempre asignar exactamente una clase sin ambigüedad? | | **Cobertura de atributos** | ¿Todas las propiedades necesarias para el entrenamiento están capturadas como atributos? | | **Granularidad consistente** | ¿Las clases del mismo nivel son igualmente específicas? | | **Claridad para el anotador** | ¿Puede un nuevo anotador entender cada clase solo por su nombre? | | **Alineación con el modelo** | ¿La taxonomía coincide con lo que su arquitectura de modelo espera? | | **Escalabilidad** | ¿Puede añadir nuevas clases después sin reestructurar? | ## Errores comunes ### Sobre-especificación de clases Crear demasiadas clases de grano fino lleva a bajo acuerdo entre anotadores y datos de entrenamiento escasos por clase. **Problema:** 50 subclases de vehículos donde la mayoría tiene menos de 100 ejemplos cada una. **Solución:** Comience con 5-10 clases amplias. Añada subclases solo cuando tenga suficientes datos y su modelo se beneficie de la distinción. ### Límites ambiguos Cuando dos clases se superponen conceptualmente, los anotadores no estarán de acuerdo en cuál usar. **Problema:** Existen tanto `van` como `minivan`, pero los anotadores no pueden distinguirlos de manera confiable. **Solución:** Fusione en una sola clase o proporcione guías visuales explícitas con imágenes de referencia que muestren el límite. ### Casos límite faltantes Los datos del mundo real contienen objetos que no encajan perfectamente en su taxonomía. **Problema:** Un anotador encuentra un carrito de golf pero la taxonomía solo tiene `car`, `truck` y `motorcycle`. **Solución:** Incluya una clase general como `other_vehicle` y revise periódicamente los elementos etiquetados con ella para identificar clases que necesita añadir. ## Próximos pasos Revise los bloques de construcción fundamentales de la plataforma Avala. Configure flujos de revisión para validar la calidad de la anotación. Vea los formatos JSON para bounding boxes, polígonos, cuboides y más. Suba datos y cree su primer proyecto de anotación.