Как я вручную разметил 1001 жалобу, чтобы оценка LLM не врала мне
Инженер данных строит систему оценки (eval harness) для детекции сигналов оттока клиентов в текстах жалоб. Главная проблема — не код метрик, а создание надёжной разметки: автор вручную проверил 1001 жалобу из базы CFPB, отказавшись от искушения разметить данные через большую LLM. Результат: LLM (llama3.2:3b) находит в 3 раза больше сигналов, чем старый TF-IDF, но стоит в 14 844 раза дороже.
Практический кейс для ML-инженеров и data scientists: показывает реальную трудоёмкость создания ground truth для NLP-задач и объясняет, почему LLM-разметка — плохая идея для оценки других LLM. Полезно тем, кто внедряет LLM в продакшн и сталкивается с задачами классификации текста.
Это аннотация к авторской статье. Мы не публикуем и не пересказываем чужие тексты целиком — полная версия у автора.
О чём статья
- Разметка данных через LLM создаёт циркулярность: модели оцениваются на согласие с разметчиком, а не на реальную точность
- На редких событиях (4.8% позитивов) одна train/test split даёт ненадёжные метрики — нужна стратифицированная кросс-валидация
- Краевые случаи при разметке (закрытие счёта банком vs клиентом, исторические упоминания, смена продукта внутри банка) требуют явной спецификации задачи
- В категории debt collection оказалось 0 сигналов оттока из 167 записей — сама концепция churn там неприменима, т.к. клиенты не выбирают коллекторов
Комментарии