Иерархическая классификация через промпты: три стратегии для многоуровневой категоризации

ПРОМПТ: Список всех конечных меток (без структуры) → Выбери одну
ОТВЕТ: Конечная метка

Один запрос. Модель не видит иерархию.

ПРОМПТ: Все пути в формате "уровень1 > уровень2 > уровень3" → Выбери путь
ОТВЕТ: Полный путь через ">"

Один запрос. Модель видит полную структуру.

ШАГ 1: Метки верхнего уровня → Выбери категорию
ШАГ 2: Дочерние метки выбранной категории → Выбери подкатегорию
ШАГ N: Продолжай до конечного уровня

Несколько запросов. На каждом шаге — только релевантные метки.

⚠️ Ограничения метода: DH лучше работает на глубоких иерархиях (3+ уровня). Для простых двухуровневых структур достаточно DL. TMH оптимален, когда нужно экономить токены или когда список всех путей слишком длинный для одного промпта.

Задача: Ты ведёшь проект по автоматизации клиентской поддержки. Входящие обращения нужно распределять по отделам → типам → конкретным темам. Структура: (1) Продажи / Техподдержка / Бухгалтерия, (2) Вопрос / Проблема / Запрос, (3) 20+ конкретных тем. Вручную сортировать 200 обращений в день — убийство времени.

Промпт (стратегия DH с 3-shot):

Классифицируй обращение по структуре: Отдел > Тип > Тема

Примеры:
1. "Не пришёл счёт за ноябрь" → Бухгалтерия > Проблема > Выставление счетов
2. "Как подключить API к CRM?" → Техподдержка > Вопрос > Интеграции
3. "Хочу увеличить лимит по договору" → Продажи > Запрос > Условия договора

Доступные пути:
- Продажи > Вопрос > Тарифы и цены
- Продажи > Вопрос > Условия договора
- Продажи > Запрос > Увеличение лимита
- Техподдержка > Проблема > Ошибки в системе
- Техподдержка > Вопрос > Интеграции
- Бухгалтерия > Проблема > Выставление счетов
[...остальные 15 путей]

Обращение: "{текст обращения}"

Ответ (только путь):

Результат: Модель выдаст точный путь в формате "Отдел > Тип > Тема". Структура в промпте показывает модели связи между уровнями — она понимает, что "Выставление счетов" относится к "Бухгалтерии", а не к "Продажам". Few-shot примеры калибруют понимание: модель видит, как формулировки клиентов (разговорный стиль) соотносятся с формальными метками.

Слабость LLM: При классификации по плоскому списку меток модель не видит контекст верхних уровней. "Счета", "Договоры", "Тарифы" — всё звучит про деньги. Без структуры модель путает похожие темы из разных отделов. Добавь сюда синонимы и разговорные формулировки — точность падает.

Сильная сторона LLM: Модель отлично понимает структуру и следует паттернам, если их явно показать. Формат "Категория > Подкатегория > Тема" создаёт иерархическую привязку — модель видит, что "Выставление счетов" существует только внутри ветки "Бухгалтерия > Проблема". Few-shot примеры работают как семантическая калибровка — модель учится соотносить стиль текста с уровнем формальности меток.

Как метод использует силу: DH-стратегия показывает модели все связи одновременно — она видит полную карту и выбирает путь, а не блуждает по уровням. TMH работает как фильтр с сужением — на каждом шаге модель выбирает из меньшего числа релевантных вариантов, что снижает вероятность ошибки. Few-shot даёт модели якорные примеры — она схватывает паттерн "как люди формулируют → как это переводится в метки".

Глубина few-shot (0 / 3 / 5 / 10 примеров):

• 0 примеров → быстро, но неточно на сложных структурах
• 3-5 примеров → золотая середина — точность растёт, стоимость терпима
• 10+ примеров → точность почти не растёт, токены дорожают

Формат вывода:

• "Только путь" → модель выдаёт "Бухгалтерия > Проблема > Счета"
• "С объяснением" → модель пишет "Выбрал Бухгалтерию, потому что..." (дороже, но видно логику)

Выбор стратегии:

• Глубокая иерархия (3+ уровня) → DH (модель видит все связи)
• Мелкая иерархия (2 уровня) → DL или TMH (проще, дешевле)
• Огромный список меток → TMH (не влезет весь список в один промпт)

Классифицируй текст по иерархии: {уровень_1} > {уровень_2} > {уровень_3}

{few_shot_примеры}

Доступные пути:
{список_всех_путей}

Текст: "{текст}"

Ответ (только путь через ">"):

Что подставлять:

• {уровень_1/2/3} — названия уровней ("Отдел", "Тип", "Тема")
• {few_shot_примеры} — 3-5 примеров в формате "Текст" → Путь
• {список_всех_путей} — все возможные пути, каждый с новой строки
• {текст} — текст для классификации

Шаг 1 (верхний уровень):

Выбери категорию для текста.

Категории: {категории_уровня_1}

Текст: "{текст}"

Ответ (только название категории):

Шаг 2 (следующий уровень):

Выбери подкатегорию внутри "{выбранная_категория}".

Подкатегории: {дочерние_метки}

Текст: "{текст}"

Ответ (только название подкатегории):

Повторяй до конечного уровня.

🚀 Быстрый старт — вставь в чат:

Вот шаблон для иерархической классификации текста. Адаптируй под мою задачу: {твоя задача}. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит про структуру твоей иерархии (сколько уровней, какие метки на каждом) и примеры текстов для few-shot. Она возьмёт паттерн из шаблона и адаптирует формат под твои метки — сгенерирует промпт, который ты сможешь использовать для классификации.

⚠️ Стоимость растёт с глубиной: На иерархиях с 3+ уровнями стратегия DH требует показать все пути в промпте. Если у тебя 300+ путей — промпт раздувается до 5000+ токенов. TMH экономит токены, но требует нескольких запросов (по одному на каждый уровень) — итоговая стоимость может быть сравнима.

⚠️ Качество меток важно: Если метки неоднозначные ("Разное", "Прочее", "Другое") или перекрываются семантически — модель путается даже с few-shot. Чёткие, различимые названия критичны.

⚠️ Не для простых классификаций: Если у тебя 2 уровня и 10 меток — достаточно обычного списка без структуры. Иерархические промпты — это overkill для простых задач. Используй DL или вообще обычный "выбери категорию из списка".

⚠️ Zero-shot хуже на 15-20%: Без примеров модель делает больше ошибок, особенно на схожих метках. Few-shot (3-5 примеров) существенно поднимает точность — экономия на промпте выйдет дороже через ошибки классификации.

Исследователи взяли GPT-4o-mini и проверили три стратегии промптинга на двух датасетах: Web of Science (научные статьи, 2 уровня: область → ключевое слово) и Amazon Product Reviews (отзывы на товары, 3 уровня: категория → подкатегория → товар). Тестировали в zero-shot (без примеров) и few-shot (1, 3, 5, 10, 20 примеров). Сравнивали с традиционной ML-моделью HPT (Hierarchy-aware Prompt Tuning), которая требует обучения на данных.

Измеряли точность на каждом уровне и условную вероятность — насколько часто модель правильно предсказывает дочернюю метку, если родительская угадана верно. Это важно: ошибка на верхнем уровне убивает точность на всех нижних. Также считали стоимость в токенах — сколько prompt tokens (входных) и completion tokens (выходных) съедает каждая стратегия.

Главная находка: На датасете WOS (2 уровня, мелкая иерархия) традиционная ML-модель выигрывает — HPT даёт 82.6% на первом уровне vs 71.3% у лучшей LLM-стратегии. Но на APR (3 уровня, глубокая иерархия) картина меняется: DH с 5-shot даёт 86.8% на первом уровне vs 82.3% у HPT. На третьем уровне DH с 20-shot выдаёт 53.2% vs 37.7% у HPT — разгром в пользу LLM!

Почему так? HPT обучена на фиксированных данных — она хорошо работает на неглубоких структурах, где можно натренировать модель на всех связях. Но на глубоких иерархиях с редкими метками HPT страдает от нехватки данных для обучения. LLM с few-shot не требует обучения — она схватывает паттерн из примеров и обобщает на новые тексты. DH-стратегия явно показывает модели структуру — это критично для глубоких иерархий.

Стоимость: Zero-shot на WOS съедает ~833 prompt tokens для DL, ~1249 для DH. Few-shot раздувает промпт — 20-shot на DH требует уже 6822 токена. На APR ещё хуже: DH с 20-shot — 5575 токенов. TMH стартует дёшево (511 токенов), но при 20-shot взрывается до 6473 токенов из-за того, что на каждом шаге нужно переотправлять контекст. Completion tokens стабильны (3-12 токенов) — основная стоимость в промптах.

Инсайт для практики: Если у тебя глубокая иерархия (3+ уровня) и мало данных для обучения ML-модели — LLM с few-shot выгоднее традиционного ML. Но если иерархия мелкая (2 уровня) и есть много размеченных данных — классическая ML-модель всё ещё лучше по точности и стоимости.

Контекст: Исследователи использовали этот промпт для стратегии DH на датасете Web of Science.

### Instructions
Q. What area does this passage relate to?

### Candidates
Computer Science > Data Structure
Computer Science > Machine Learning
Computer Science > Operating Systems
Medical Science > Asthma
Medical Science > Cancer
[...full list of hierarchical paths]

### Passage
{input data}

### Answer

Для TMH (пошаговая стратегия) промпт на первом уровне выглядел так:

### Instructions
Q. What is area this passage related to?

### Candidates
Medical Sciences
Computer Science
Electrical Engineering
[...list of top-level categories]

### Passage
{input data}

### Answer

На следующем шаге показывали только дочерние метки выбранной категории.

В оригинале классифицировали научные статьи и товары. Принцип работает для любой многоуровневой категоризации. Вот адаптация для IT-компании:

Задача: Распределять баги из GitHub Issues по: Модуль > Тип проблемы > Приоритет

Классифицируй баг по структуре: Модуль > Тип > Приоритет

Примеры:
1. "API падает при отправке больших файлов" → Backend > Performance > High
2. "Кнопка 'Сохранить' не меняет цвет при наведении" → Frontend > UI/UX > Low
3. "База данных не откатывает транзакцию при ошибке" → Database > Logic Error > Critical

Доступные пути:
- Backend > Performance > High
- Backend > Logic Error > Critical
- Frontend > UI/UX > Low
- Frontend > Functionality > Medium
- Database > Performance > Medium
- Database > Logic Error > Critical
[...остальные комбинации]

Баг: "{текст issue}"

Ответ (только путь через ">"):

Почему это работает здесь: Модуль определяется по ключевым словам (API, база, кнопка). Тип проблемы — по описанию симптома (падает = Performance, не работает логика = Logic Error). Приоритет — по бизнес-критичности формулировки. Структура в промпте помогает модели не путать "Performance в Backend" и "Performance в Database" — это разные вещи.

Проблема: Не все тексты требуют классификации до самого нижнего уровня. Например, обращение "У вас есть техподдержка?" — это вопрос о компании, не конкретная проблема. Классифицировать до "Техподдержка > Вопрос > Доступность услуги" — overkill.

Решение: Добавь в промпт опцию "не определено" на каждом уровне:

Классифицируй обращение. Если уровень не применим — пиши "N/A".

Примеры:
"У вас есть техподдержка?" → Общая информация > N/A > N/A
"Не работает оплата картой" → Техподдержка > Проблема > Платёжная система

Структура: Отдел > Тип > Конкретная тема

Обращение: "{текст}"

Ответ:

Эффект: Модель сама решает, нужна ли глубокая классификация. Это экономит токены (не нужно показывать все пути для простых запросов) и повышает точность (не форсирует модель придумывать несуществующие подкатегории).

Проблема: Иногда текст действительно неоднозначен. "Не могу войти в систему" — это техподдержка или бухгалтерия (не вижу счета)? Модель выберет категорию, но может ошибиться.

Решение: Попроси модель оценить уверенность:

Классифицируй обращение и оцени уверенность (Low/Medium/High).

Структура: Отдел > Тип > Тема | Уверенность

Обращение: "{текст}"

Ответ:

Пример вывода:

Техподдержка > Проблема > Доступ к системе | Medium

Эффект: Обращения с Low confidence можно отправлять на ручную проверку — это снижает количество неправильно распределённых задач. Вместо 100% автоматизации с 20% ошибок получаешь 80% автоматизации с 5% ошибок + 20% на ручной триаж.

Hierarchical Text Classification Using Black Box Large Language Models Kosuke Yoshimura, Hisashi Kashima (Kyoto University, 2024)

Упомянутые исследования:

• HPT (Hierarchy-aware Prompt Tuning) — Wang et al., 2022
• HierVerb — Ji et al., 2023
• TELEClass — Zhang et al., 2024

Датасеты:

• Web of Science (WOS) — 46,985 научных статей, 2 уровня иерархии
• Amazon Product Reviews (APR) — отзывы на товары, 3 уровня иерархии

Методы проверки контаминации:

• ChatGPT-Cheat? — Sainz et al., 2023
• Time-Travel-in-LLMs — Golchin & Surdeanu, 2024