TL;DR
SLKR — схема классификации текстов по заранее заданным категориям, где работа делится между двумя моделями. Сильная модель один раз пишет для каждой категории определение и граничные правила для пар похожих категорий («чем „возврат денег" отличается от „возврата товара"»). Затем дешёвая модель классифицирует каждый входящий текст, видя только определения нескольких подходящих категорий и пару релевантных правил.
Главная находка: голые названия категорий в промпте — слабая опора. Дешёвая модель путает соседние категории: «не пришёл заказ» и «заказ потерян», «изменить карту» и «заблокировать карту». Определения помогают, но не решают спор между близкими классами. Граничные правила решают его точечнее. Важно подать только нужные правила. Пять случайных правил работают хуже пяти подобранных под текст. Лишний контекст не помогает, а на разнородных текстах даже вредит.
Метод в два этапа. Офлайн (один раз): сильная модель генерирует определения, ключевые слова для поиска и граничные правила. Онлайн (на каждый текст): поиск оставляет около 15 кандидатов-категорий, затем 5 самых уместных правил между ними, и дешёвая модель делает один вызов с определениями и правилами. Затраты сильной модели зависят от числа категорий, а не от числа текстов.
Схема метода
ОФЛАЙН (один раз, сильная модель, три независимых запроса):
ШАГ 1: Список категорий + описание задачи → определение каждой категории
ШАГ 2: Список категорий + описание задачи → ключевые слова для поиска
ШАГ 3: Список категорий + описание задачи → граничные правила для путаемых пар
ОНЛАЙН (на каждый текст):
ШАГ 4: Гибридный поиск (смысловой + по словам) → топ-15 категорий-кандидатов
ШАГ 5: Берём только правила между кандидатами → топ-5 самых уместных тексту
ШАГ 6: Дешёвая модель, один вызов: текст + определения кандидатов + 5 правил → одна категория
Шаги 1–3 — отдельные запросы, друг про друга они не знают. Шаги 4–5 требуют кода (эмбеддинги, ранжирование). Шаг 6 — обычный промпт.
Пример применения
Задача: Команда поддержки маркетплейса в стиле Ozon или Wildberries каждый день получает десятки тысяч обращений. Их нужно раскладывать по 40 категориям: «Возврат денег», «Возврат товара», «Не пришёл заказ», «Заказ потерян на складе», «Брак при получении», «Не тот товар» и так далее. Размеченных примеров нет, а гонять каждое обращение через флагманскую модель дорого. Сначала нужны определения и правила — их делает сильная модель.
Промпт (офлайн, шаг «граничные правила», сильная модель):
Ты проектируешь классификатор обращений в поддержку маркетплейса.
Задача: отнести обращение клиента ровно к одной категории.
Список категорий:
1. Возврат денег
2. Возврат товара
3. Не пришёл заказ
4. Заказ потерян на складе
5. Брак при получении
6. Не тот товар в посылке
... {остальные категории до 40}
Найди пары категорий, которые легко перепутать: по смыслу, по ситуации клиента,
по тому, какое действие ему нужно. Для каждой пары напиши короткое правило:
по каким признакам в тексте обращения различать эти две категории.
Формат:
Категория А ↔ Категория Б: правило в 1-2 предложениях.
Не используй другие определения или ключевые слова — работай только со списком
категорий и описанием задачи.
Результат: Модель выдаст список пар похожих категорий. Для каждой пары будет короткое правило различения, например по тому, ждёт клиент деньги или замену. Этот список сохраняется. Для определений и ключевых слов запускаются отдельные запросы с тем же списком категорий. Затем на каждое обращение вы подаёте дешёвой модели текст, определения нескольких подходящих категорий и 3–5 правил для их пар. Модель вернёт одну категорию.
Почему это работает
Слабость. Дешёвая модель мало знает о том, как именно в вашей задаче различаются соседние категории. Название «Возврат денег» не говорит, чем оно отличается от «Возврата товара». Если же сунуть ей все описания и все правила, контекст раздувается, а нужная подсказка тонет среди лишних.
Сильная сторона. Сильная модель хорошо рассуждает о смысле категорий. Её главный плюс — один раз потратить усилия на осмысление списка и записать это текстом. А дешёвая модель хорошо следует короткой прямой инструкции: «если в тексте X — это А, если Y — это Б».
Как метод связывает одно с другим. Дорогое «понимание» категорий выносится в отдельный заранее подготовленный справочник. Поиск оставляет в промпте только подходящий кусок. Дешёвая модель не думает над списком из 40 пунктов, а смотрит на 15 определений и 5 правил.
Рычаги управления: - Число кандидатов K (в статье 15) → уменьши, если категорий мало; увеличь, если правильная категория часто выпадает из списка. - Число правил M (в статье 5) → меньше для коротких текстов и экономии токенов; больше, если категории сильно пересекаются. - Определения → проси определение + область применения + типичные темы: так оно полезнее, чем одна фраза. - Ключевые слова → нужны только для поиска, в финальный промпт их не клади. - Три независимых запроса → не показывай модели результаты соседних запросов, пусть каждый строится только от списка категорий и описания задачи.
Шаблон промпта
Офлайн, три независимых запроса сильной модели. В статье точные тексты промптов в доступной части не приведены. Ниже реконструкция по описанию метода.
### Запрос 1 — определения
Ты помогаешь построить классификатор для задачи: {описание_задачи}.
Список категорий: {список_категорий}.
Для каждой категории напиши краткое определение: что входит в её охват
и какие типичные темы или ситуации к ней относятся.
Формат: Категория — определение (2-3 предложения).
### Запрос 2 — ключевые слова
Задача: {описание_задачи}. Список категорий: {список_категорий}.
Для каждой категории дай 8-15 слов и выражений, по которым её можно
узнать в тексте (включая синонимы и разговорные формулировки).
Формат: Категория — слово1, слово2, ...
### Запрос 3 — граничные правила
Задача: {описание_задачи}. Список категорий: {список_категорий}.
Найди пары категорий, которые легко перепутать (по смыслу, области,
функции или применению). Для каждой пары напиши правило различения.
Формат: Категория А ↔ Категория Б: правило.
Онлайн, финальный запрос дешёвой модели:
Задача: {описание_задачи}.
Текст для классификации:
{текст}
Возможные категории и их определения:
{определения_категорий-кандидатов}
Правила различения похожих категорий:
{3-5_подходящих_правил}
Выбери ровно одну категорию из списка выше. Ответ — только название категории.
Что подставлять:
- {описание_задачи} — одна-две фразы: что классифицируем и зачем.
- {список_категорий} — полный список, названия должны быть осмысленными.
- {определения_категорий-кандидатов} — определения из Запроса 1 только для отобранных кандидатов.
- {3-5_подходящих_правил} — правила из Запроса 3 только для пар среди кандидатов.
🚀 Быстрый старт — вставь в чат:
Вот шаблон SLKR для классификации текстов по категориям. Адаптируй под мою задачу: {твоя_задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что вы классифицируете, какие у вас категории и какие из них чаще всего путаются. Это нужно, чтобы три запроса получили полный список и правила писались под ваши реальные пересечения, а не абстрактные.
Ограничения
⚠️ Полный метод — это код: Поиск кандидатов и правил (эмбеддинги, слияние двух рейтингов) нужно собирать скриптом или автоматизацией. В обычном чате воспроизводится только офлайн-часть и финальный запрос.
⚠️ Нужен закрытый список категорий: Метод для случая, когда набор классов фиксирован и названия осмысленные. Для кодов, номеров, абстрактных меток он не годится.
⚠️ Проверено только на малых моделях: Дешёвыми читателями были модели на 3–4 млрд параметров. У слабой модели выигрыш большой, у более сильной — заметно скромнее. Для фронтирных моделей эффект не проверялся.
⚠️ Выигрыш от граничных правил — небольшой: Относительно простых определений правила дают единицы пунктов. Основная польза в том, что сами определения помогают модели.
⚠️ Размеченные примеры иногда лучше: На одном из наборов с одной из моделей подача похожих размеченных примеров дала результат чуть выше. Если у вас есть размеченные данные, сравните.
⚠️ Правила не проверены людьми: Всё знание о категориях генерирует одна сильная модель. Ошибка в правиле повторится на каждом тексте. Прочитайте правила глазами, прежде чем запускать массовую разметку.
⚠️ Много категорий — много пар: Число возможных пар растёт быстро. При сотнях категорий офлайн-этап дорожает и требует разбиения.
⚠️ Метод избыточен для малых задач: Для 5–7 понятных категорий хватит обычного промпта с определениями.
Как исследовали
Идея была простой: не гонять дорогую модель на каждом тексте, а заранее вытащить из неё знание о категориях. Исследователи взяли четыре набора данных: три публичных (научные статьи на 143 класса, банковские обращения на 77 классов, намерения пользователей на 150 классов) и реальную промышленную коллекцию многоязычных книг по 38 дисциплинам. Знание о категориях писала сильная модель, а классифицировали две лёгкие модели из разных семейств. Сравнивали пять подходов: только названия категорий, названия плюс определения, по одному примеру на категорию, подбор похожих примеров, и сам SLKR. Эксперименты повторяли на трёх случайных запусках.
SLKR показал лучший результат на всех четырёх наборах с первой моделью и на трёх из четырёх со второй. Он обошёл даже подходы с размеченными примерами, хотя сам их не использовал. Контекст при этом короче: примерно 1,4 тыс. токенов против 4,7 тыс. у «одного примера на категорию». Для слабой модели выигрыш особенно велик: на научных статьях она подскочила с 29% только по названиям до 56%.
Самый интересный результат — абляция (отдельная проверка вклада граничных правил). Пять случайных правил стабильно проигрывали пяти отобранным под текст, то есть выигрыш даёт не количество текста, а его уместность. Подача всех правил стоит 2,5 тыс. токенов вместо 0,35 тыс. при схожем качестве на публичных наборах. На более разнородных книгах отбор работал заметно лучше, чем «все правила сразу».
Адаптации и экстраполяции
🔧 Техника: убрать поиск → ручной отбор правил для малого числа категорий
Если категорий до 15–20, не строй поиск: вставь все определения и все правила прямо в системный промпт дешёвой модели. В статье вариант «все правила» на публичных наборах работал почти как отобранные, но расходовал в разы больше токенов. Для разнородных текстов качество у него было хуже. Короткие тексты и малый список — зона, где это допустимо.
🔧 Техника: добавить проверку правил → меньше системных ошибок
Перед запуском попроси сильную модель сгенерировать правила, а вторую сессию — найти в них противоречия, пересекающиеся условия и пары категорий, у которых правила нет. Потом прочитай результат сам: ошибка в правиле тиражируется на все тексты.
Экстраполяция: тот же принцип в инструкции агента. Если агент выбирает один из нескольких инструментов или режимов, то же самое можно записать в системном промпте. Опиши каждый инструмент определением и добавь короткие правила «когда А, а не Б». Статья этого не проверяла, это мой перенос идеи.
Инструменты:
{определения_инструментов}
Правила выбора между похожими инструментами:
search_docs ↔ search_web: search_docs — если вопрос про наш продукт и внутренние правила; search_web — если про внешний мир и свежие события.
...
Если не уверен между двумя инструментами — выбери по правилу выше, а не угадывай.
Ресурсы
- Работа: «Label-Centric Knowledge Retrieval for Zero-Shot Text Classification» (препринт, на рецензии)
- Авторы: Daoping Wu, Dong Wang, Siyu Liu, Chen Liang, Jian Geng, Ziqi Li, Shuguang Xiong, Ying Zhang
- Организации: Zhejiang Lab; Harbin Institute of Technology; Shanghai Jiao Tong University
- Ближайший предшественник: Gen-Z (Kumar et al., 2024) — расширение меток описаниями
- Наборы данных: WOS-46985, BANKING77, CLINC150, Book-38 (промышленный, из статьи)