TL;DR
LLM способны классифицировать открытые текстовые ответы на уровне опытного человека-аналитика — если дать им не просто список категорий, а полноценный кодбук: каждая категория с определением, граничными случаями и инструкцией "сначала рассуждай, потом присваивай код". Это называется деductive coding — применение заранее заданных категорий к новым текстам.
Главная ловушка: если просто написать "классифицируй по темам: еда, медицина, безопасность" — модель будет работать хуже. Качество промпта напрямую определяет качество классификации. LLM, в отличие от человека, не может "додуматься" по контексту — ей нужно явно написать то, что опытный аналитик делает по умолчанию из профессиональной интуиции.
Исследование показывает: при структурированном кодбуке + включённом рассуждении несколько моделей достигают согласованности с экспертами уровня α = 0.8+ по Крippendorff (это профессиональный стандарт). Но точность сильно варьируется по категориям — модели особенно слабы там, где нужда выражена косвенно: намёками, через описание отказа в услуге, без прямого называния проблемы.
Схема метода
ШАГ 1: Составь кодбук → для каждой категории: название + определение + граничные случаи
(выполняется один раз, в начале промпта)
ШАГ 2: Дай инструкцию на рассуждение → "сначала проанализируй контекст, потом присвой код"
(часть системного промпта)
ШАГ 3: Передай текст на классификацию → одна или несколько единиц за раз
(основной рабочий запрос)
[Опционально] ШАГ 4: Повтори шаг 3 несколько раз с одними текстами → возьми
наиболее частый ответ для спорных случаев
Всё выполняется в одном чате. Шаги 1–2 — это системный промпт или первое сообщение. Шаг 3 — рабочие запросы с текстами.
Пример применения
Задача: HR-менеджер Яндекса анализирует 200 открытых ответов из ежегодного опроса сотрудников: "Что мешает тебе работать эффективнее?" Нужно разбить ответы по темам, чтобы передать приоритеты руководству.
Промпт:
Ты — аналитик HR. Твоя задача — кодировать открытые ответы сотрудников
по заранее заданным категориям (деductive coding).
КОДБУК:
1. ИНСТРУМЕНТЫ
Ответ говорит о нехватке или плохом качестве рабочих инструментов,
ПО, оборудования, доступов, инфраструктуры.
Граничный случай: жалоба на медленный VPN — сюда. Жалоба на
бюрократию при получении доступов — ПРОЦЕССЫ.
2. ПРОЦЕССЫ
Ответ говорит о неэффективных внутренних процессах: согласования,
бюрократия, ненужные встречи, непрозрачные процедуры.
Граничный случай: "слишком много митингов" — сюда. "Нет нормального
инструмента для планирования встреч" — ИНСТРУМЕНТЫ.
3. КОММУНИКАЦИЯ
Ответ говорит о проблемах с передачей информации: между командами,
с руководством, непонятные приоритеты, нет обратной связи.
4. НАГРУЗКА
Ответ говорит об объёме задач, приоритизации, перегрузке,
невозможности фокусироваться. Включает размытость зоны ответственности.
5. ДРУГОЕ
Ответ содержит проблему, которая не входит ни в одну из категорий выше.
6. НЕ ПО ТЕМЕ
Ответ не содержит конкретной проблемы или не отвечает на вопрос.
ИНСТРУКЦИЯ:
Для каждого ответа:
а) Сначала кратко опиши, что именно говорит сотрудник (1-2 предложения)
б) Укажи, какая категория подходит и почему
в) Присвой финальный код
Ответ сотрудника: "[вставить текст]"
Результат: Модель покажет явную цепочку рассуждений для каждого ответа: о чём говорит сотрудник → почему это та или иная категория → финальный код. Спорные случаи будут видны сразу — модель укажет, почему сложно выбрать. Для 200 ответов можно передавать по 10-20 за раз или оформить как таблицу.
Почему это работает
Проблема "в лоб": Когда просишь LLM "классифицируй по темам" без чёткого кодбука — модель опирается на статистические паттерны из обучения, а не на твою логику. Категории размываются, граничные случаи летят в разные стороны, результат непредсказуем.
Что LLM умеет хорошо: Следовать явным, недвусмысленным правилам. Если правило написано точно — модель соблюдает его стабильно. Это и есть сильная сторона: воспроизводимость при наличии структуры.
Как метод использует эту силу: Кодбук убирает двусмысленность. Модель не "интерпретирует" — она сопоставляет текст с конкретными определениями. Инструкция "сначала рассуждай" заставляет модель генерировать промежуточный текст о смысле ответа — и это снижает ошибки, потому что на этапе рассуждения часто обнаруживается то, что "в лоб" игнорировалось бы.
Рычаги управления: - Детальность кодбука → больше граничных случаев = меньше ошибок на краях, но длиннее промпт - Инструкция на рассуждение → убери её, если нужна скорость; оставь, если важна точность на спорных текстах - Повтор классификации → для критически важных решений прогони один и тот же текст 2-3 раза, возьми совпадающий ответ - Граничные случаи → самый мощный рычаг: напиши примеры именно из твоей области, где интуитивно непонятно куда отнести
Шаблон промпта
Ты — [роль аналитика]. Твоя задача — кодировать тексты по заранее
заданным категориям.
КОДБУК:
1. {КАТЕГОРИЯ_1}
Определение: {что именно сюда входит — конкретно и без размытых слов}
Граничный случай: {где заканчивается эта категория и начинается соседняя}
2. {КАТЕГОРИЯ_2}
Определение: {определение}
Граничный случай: {граничный случай}
[... все категории]
{ПОСЛЕДНЯЯ}: ДРУГОЕ
Текст содержит проблему, которая не входит ни в одну из категорий выше.
{ПРЕДПОСЛЕДНЯЯ}: НЕ ПО ТЕМЕ
Текст не содержит ответа на вопрос или нерелевантен задаче.
ИНСТРУКЦИЯ:
Для каждого текста:
а) Кратко опиши суть (1-2 предложения)
б) Объясни, почему подходит именно эта категория
в) Присвой финальный код
Текст: "{текст_для_классификации}"
Плейсхолдеры:
- {роль аналитика} — HR-аналитик, контент-модератор, исследователь обратной связи
- {КАТЕГОРИЯ_N} — твои конкретные темы (3-10 штук)
- {определение} — что конкретно входит в категорию, без абстракций
- {граничный случай} — где заканчивается одна категория и начинается соседняя
- {текст_для_классификации} — один ответ или несколько нумерованных
🚀 Быстрый старт — вставь в чат:
Вот шаблон для структурированной классификации текстов (qualitative coding).
Адаптируй под мою задачу: [опиши что нужно классифицировать и зачем].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: какие категории нужны, что считать граничным случаем, какие тексты будут типичными — потому что без этого кодбук будет размытым и даст нестабильный результат.
Ограничения
⚠️ Деductive only: Метод работает только если категории уже известны заранее. Если нужно найти темы из данных с нуля (inductive coding) — LLM справляется плохо: генерирует непоследовательные категории, которые не сходятся между запусками.
⚠️ Косвенное выражение: Модели плохо распознают нужду, выраженную намёком или через описание последствий. "Нас не пускали на общее собрание" как сигнал дискриминации — не "нас дискриминировали". В таких категориях ошибаются даже лучшие модели. Добавляй в кодбук примеры именно косвенных формулировок.
⚠️ Непредсказуемость по категориям: Общий хороший результат не гарантирует надёжность на конкретной теме. Модель может хорошо кодировать 8 из 9 тем и системно ошибаться на одной. Проверяй каждую категорию отдельно на небольшой выборке, прежде чем масштабировать.
⚠️ Синтетические данные: Исследование проводилось на искусственно созданных транскриптах. Реальные данные — с диалектами, опечатками, эмоциональной нагрузкой — могут давать другие результаты.
Как исследовали
Команда из KoboToolbox, McGill и Harvard взяла 150 синтетических транскриптов гуманитарных интервью — разговоры беженцев о своих нуждах. Сначала два опытных кодировщика независимо разметили все тексты по 9 темам (еда, медицина, безопасность, доход и т.д.), спорные случаи — 5,3% — разрешал третий эксперт. Получился "золотой стандарт" с уровнем согласованности α = 0.938.
Затем 46 моделей прогнали через те же 150 транскриптов — 48 300 итераций классификации — и сравнили с золотым стандартом. Интересно, что несколько моделей с включённым режимом рассуждения (reasoning-enabled) вышли на уровень α ≈ 0.8, что соответствует порогу надёжного человека-кодировщика. Без структурированного промпта и рассуждений — хуже.
Самое поучительное: агрегированный показатель лгал. Модели с высоким общим α систематически проваливались на категории "Инклюзивность" (дискриминация, выраженная косвенно) — именно там, где цена ошибки наибольшая. Это предупреждение: смотри не только на общую цифру, но на производительность по каждой теме отдельно.
Адаптации и экстраполяции
🔧 Техника: добавь примеры косвенных формулировок → меньше пропусков
В кодбуке после определения добавь:
Прямое выражение: "Нас дискриминируют по национальности" Косвенное выражение: "Врачи всегда заняты, когда приходим мы, но не когда приходят другие" Оба примера — категория ДИСКРИМИНАЦИЯLLM опирается на паттерны формулировок из кодбука. Дашь косвенные примеры — начнёт распознавать косвенное.
🔧 Техника: multi-run валидация для спорных кейсов
Если результат классификации влияет на важное решение — прогони один и тот же текст 3 раза в отдельных запросах (или в трёх чатах). Возьми код, который встретился минимум 2 раза из 3. Это снижает стохастический шум — LLM иногда "флипает" между двумя близкими вариантами, и повтор стабилизирует результат.
🔧 Экстраполяция: классификация обратной связи о продукте
Принцип кодбука универсален. Команда в Авито, которая разбирает жалобы продавцов, может использовать тот же подход: категории (проблемы с верификацией / технические баги / вопросы оплаты / политика площадки), определения под каждую, граничные случаи — и LLM кодирует поток обратной связи предсказуемо и воспроизводимо.
Ресурсы
Can Large Language Models Reliably Code Qualitative Humanitarian Data? A Benchmark Study Against Human Expert Adjudication Preprint, не прошёл рецензирование на момент публикации.
Авторы: Jerome Marston, Tino Kreutzer, Salomé Garnier (KoboToolbox / Kobo Inc), Ella Boone (McGill University), Phuong N. Pham, Patrick Vinck (Harvard University)
Контакт: tino.kreutzer@kobo.ngo
Платформа KoboToolbox: kobo.ngo — open-source инструмент для гуманитарных данных, в котором разрабатывается AI-функциональность для кодирования