> ## 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. # Таксономия меток и онтология > Проектирование эффективных таксономий меток с классами, атрибутами и иерархиями Хорошо спроектированная таксономия меток — это основа любого проекта аннотации. На этой странице рассматривается, как структурировать классы объектов, настраивать атрибуты и строить иерархии, которые обеспечивают согласованные и качественные обучающие данные. ## Что такое онтология? В контексте аннотации данных **онтология** (или таксономия меток) — это полная схема классов, атрибутов и связей, которые аннотаторы используют для разметки данных. Она определяет: * **Что** размечать (классы объектов) * **Как** описывать объекты (атрибуты и свойства) * **Как** классы связаны друг с другом (иерархия и группировка) Чёткая онтология снижает путаницу аннотаторов, улучшает согласие между ними и обеспечивает более чистые обучающие данные для ваших моделей. ## Классы объектов Классы объектов — это основные строительные блоки вашей таксономии. Каждый класс представляет категорию объектов, которые аннотаторы будут идентифицировать и размечать в данных. ### Определение классов При создании проекта в Avala вы определяете конфигурацию меток как список классов: ```json theme={null} { "labels": [ { "name": "car", "color": "#FF0000" }, { "name": "pedestrian", "color": "#00FF00" }, { "name": "cyclist", "color": "#0000FF" }, { "name": "truck", "color": "#FFA500" }, { "name": "bus", "color": "#800080" } ] } ``` Каждый класс имеет уникальное имя и цвет отображения, используемый в редакторе аннотаций. Выбирайте цвета, которые визуально отличаются друг от друга и от типичных цветов фона в ваших данных. ### Лучшие практики именования классов | Практика | Пример | Зачем | | ------------------------------------------------------------ | -------------------------------------------------------- | -------------------------------------------- | | Используйте строчные, конкретные имена | `sedan`, `pickup_truck` | Уменьшает неоднозначность | | Избегайте пересекающихся определений | Не имейте одновременно `car` и `vehicle` на одном уровне | Предотвращает путаницу аннотаторов | | Будьте последовательны с разделителями | `traffic_light`, а не `traffic-light` или `trafficLight` | Единообразный парсинг в пайплайнах обучения | | Включайте негативные/фоновые классы только при необходимости | `unknown`, `ignore_region` | Некоторые модели требуют явных фоновых меток | ## Атрибуты Атрибуты добавляют структурированные метаданные к каждой аннотации помимо класса объекта. Они позволяют аннотаторам описывать такие свойства, как видимость, поза или состояние. ### Типы атрибутов Avala поддерживает несколько типов атрибутов, которые можно прикрепить к любому классу объекта: | Тип | Описание | Когда использовать | Пример | | ----------------------- | ------------------------------------------- | -------------------------------------------- | ----------------------------------------------------------- | | **Выпадающий список** | Одиночный выбор из предопределённого списка | Взаимоисключающие варианты | Перекрытие: `none`, `partial`, `heavy` | | **Чекбокс** | Булевый переключатель | Простые флаги да/нет | `is_parked: true/false` | | **Текст** | Произвольный строковый ввод | Уникальные идентификаторы или описания | Номерной знак | | **Число** | Числовое значение | Измерения или подсчёты | Расчётное расстояние в метрах | | **Множественный выбор** | Несколько вариантов из списка | Одновременные, невзаимоисключающие состояния | Видимые элементы: `headlights`, `taillights`, `turn_signal` | Сравнение типов атрибутов Сравнение типов атрибутов ### Настройка атрибутов Атрибуты определяются в конфигурации классификации проекта вместе с конфигурацией меток: ```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"] } ] } } ``` ### Условные атрибуты Используйте поле `applies_to`, чтобы показывать атрибуты только для соответствующих классов. Это сохраняет интерфейс аннотатора чистым — объекту `pedestrian` не нужен атрибут `is_parked`, а объекту `traffic_light` не нужен `truncation`. Отмечайте атрибуты как `required` для свойств, от которых зависит ваш пайплайн обучения модели. Оставляйте необязательными атрибуты для дополнительных метаданных, которые полезны, но не критичны. ## Иерархические таксономии Для сложных предметных областей плоские списки классов становятся неудобными. Иерархические таксономии группируют связанные классы под родительскими категориями. ### Пример: таксономия транспортных средств ``` Vehicle ├── Car │ ├── Sedan │ ├── SUV │ └── Hatchback ├── Truck │ ├── Pickup │ └── Semi ├── Bus │ ├── City Bus │ └── School Bus └── Motorcycle ``` ### Когда использовать иерархии | Сценарий | Рекомендация | | ------------------------- | ---------------------------------------------------- | | Менее 15 классов | Плоский список проще и быстрее | | 15-50 классов | Группируйте в 3-5 категорий верхнего уровня | | 50+ классов | Используйте многоуровневую иерархию с поиском | | Классы разделяют атрибуты | Группируйте под родителем для наследования атрибутов | ### Проектирование иерархий 1. **Начинайте широко, затем уточняйте.** Начните с категорий верхнего уровня (`vehicle`, `pedestrian`, `infrastructure`) и добавляйте детализацию только там, где это нужно вашей модели. 2. **Каждый листовой класс должен быть однозначным.** Если аннотаторы не могут надёжно отличить два подкласса, объедините их. 3. **Балансируйте глубину и ширину.** Глубокие иерархии (4+ уровня) замедляют аннотаторов. Предпочитайте более широкие деревья с 2-3 уровнями. ## Одиночная и множественная классификация Avala поддерживает оба режима классификации в зависимости от потребностей вашего проекта. ### Одиночная метка Каждый объект или сцена получает ровно одну метку класса. Это режим по умолчанию для большинства типов аннотаций. * Обнаружение объектов: каждая ограничивающая рамка получает один класс * Классификация сцены: каждое изображение получает одну категорию ### Множественные метки Объект или сцена может получить несколько меток одновременно. Используйте это, когда категории не являются взаимоисключающими. * Изображение может быть одновременно `rainy` и `nighttime` * Транспортное средство может быть одновременно `damaged` и `parked` Настройте множественную классификацию в конфигурации классификации проекта, указав тип классификации на уровне задачи: ```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"] } ] } } ``` ## Чек-лист проектирования онтологии Перед началом проекта аннотации проверьте вашу онтологию по этому чек-листу: | Проверка | Вопрос | | ----------------------------- | ---------------------------------------------------------------------------- | | **Полнота** | Имеет ли каждый объект, который ваша модель должна обнаруживать, свой класс? | | **Взаимоисключаемость** | Может ли аннотатор всегда назначить ровно один класс без неоднозначности? | | **Покрытие атрибутов** | Все ли свойства, необходимые для обучения, охвачены атрибутами? | | **Согласованная детализация** | Классы одного уровня одинаково специфичны? | | **Ясность для аннотатора** | Может ли новый аннотатор понять каждый класс только по его имени? | | **Соответствие модели** | Соответствует ли таксономия ожиданиям архитектуры вашей модели? | | **Масштабируемость** | Можно ли добавить новые классы позже без реструктуризации? | ## Типичные ошибки ### Избыточная детализация классов Создание слишком большого количества детализированных классов приводит к низкому согласию между аннотаторами и малому количеству обучающих данных на класс. **Проблема:** 50 подклассов транспортных средств, большинство из которых имеют менее 100 примеров. **Решение:** Начните с 5-10 широких классов. Добавляйте подклассы только когда у вас достаточно данных и ваша модель выигрывает от такого различия. ### Неоднозначные границы Когда два класса концептуально пересекаются, аннотаторы не могут договориться, какой использовать. **Проблема:** Существуют и `van`, и `minivan`, но аннотаторы не могут надёжно их различить. **Решение:** Либо объедините их в один класс, либо предоставьте явные визуальные руководства с примерами изображений, показывающими границу. ### Пропуск граничных случаев Реальные данные содержат объекты, которые не вписываются аккуратно в вашу таксономию. **Проблема:** Аннотатор встречает гольф-кар, но в таксономии есть только `car`, `truck` и `motorcycle`. **Решение:** Включите универсальный класс вроде `other_vehicle` и периодически просматривайте элементы, размеченные им, чтобы выявить классы, которые нужно добавить. ## Следующие шаги Обзор фундаментальных строительных блоков платформы Avala. Настройте рабочие процессы рецензирования для валидации качества аннотаций. Форматы JSON для ограничивающих рамок, полигонов, кубоидов и других типов. Загрузите данные и создайте свой первый проект аннотации.