TL;DR
Промпт, который исправил ошибки на маленькой проверочной выборке, может неожиданно испортить результат при полном прогоне на всех данных — это главная находка исследования о том, когда LLM реально выгоднее обычных правил для проверки качества данных. Исследователи сравнили GPT-4o-mini с классическими алгоритмами на двух задачах: поиск задвоенных товаров в каталоге и определение перепутанного бренда в карточке товара.
Когда задача сводится к сравнению текста «слово в слово» (совпадают названия товаров или нет), LLM не даёт прибавки — простое правило (пересечение слов) справляется так же хорошо. Но стоило исследователям «улучшить» промпт, добавив инструкцию про приоритет кода товара, и проверить это на 117 отобранных примерах — результат выглядел отлично. При запуске на всех 2194 парах точность упала: модель стала слишком сильно цепляться за код товара и начала пропускать реальные совпадения без него.
Зато там, где нужны фоновые знания о мире — например, понять, что «Zone Labs» и есть производитель бренда «ZoneAlarm» — LLM ощутимо выигрывает у простого правила, потому что правило ищет буквальное совпадение текста, а модель знает связи между брендами. И ещё вывод: на простых да/нет-вопросах модель почти не путается в своих ответах сама с собой (согласие 99,7% случаев), так что гонять запрос пять раз и голосовать по большинству — трата денег без реальной выгоды.
Схема метода (принципы, не пошаговая техника)
ШАГ 1: Определи тип задачи → текстовое совпадение или нужны знания о мире?
ШАГ 2: Если текстовое совпадение (дубли по названию, точные строки) → простое правило не хуже LLM и дешевле
ШАГ 3: Если нужны знания о связях (бренд-производитель, сокращения, синонимы) → тут LLM выигрывает заметно
ШАГ 4: Если меняешь промпт под конкретные ошибки → проверяй правку на БОЛЬШОЙ выборке, а не на 20-100 примерах
ШАГ 5: Для простых бинарных задач → одного запроса достаточно, голосование по нескольким прогонам не окупается
Пример применения
Задача: Ты ведёшь каталог товаров на Ozon или Wildberries и хочешь проверить карточки на ошибки в поле «бренд» — например, вместо «Samsung» стоит «Samsung Electronics», или вместо полного названия — сокращение типа тикера на бирже.
Промпт:
Вот список товаров с указанным производителем в карточке:
{список товаров с полями "название" и "производитель"}
Для каждого товара определи, правильно ли указан производитель.
Используй свои знания о брендах, дочерних компаниях, сокращениях
и альтернативных названиях — не проверяй буквальное совпадение текста
в названии и поле производителя.
Ответь для каждой строки: "верно" или "ошибка", без объяснений.
Результат: Модель пройдёт по списку и для каждого товара выдаст короткий вердикт. Она поймает случаи, где название бренда в карточке — это сокращение, старое название или дочерняя компания реального производителя, даже если простой поиск по тексту не нашёл бы совпадения. Не ожидай 100% точности — модель может принять непонятные нишевые названия за правдоподобные без проверки.
Почему это работает
LLM плохо справляется, когда задача — это чистое текстовое сопоставление: у неё нет преимущества перед алгоритмом, который просто считает совпадающие слова, а иногда модель даже хуже, потому что не так строго держится за точные коды и артикулы.
Сильная сторона модели — она несёт в себе общие знания о мире: какие компании кому принадлежат, как называются бренды в разных вариантах. Там, где нужно это знание, а не сравнение строк, LLM выигрывает ощутимо.
Из этого следует практический рычаг: не берись улучшать промпт по 20-50 примерам и не считай результат окончательным. Модель может «переобучиться» на паттерне из маленькой выборки (в исследовании — начала слишком доверять коду товара) и хуже работать в целом. Проверяй правки на бóльшем количестве случаев, прежде чем доверять им.
Шаблон промпта (принцип валидации правок)
Я хочу проверить, помогает ли изменение в промпте {описание изменения,
например "добавить приоритет кода товара как признак совпадения"}.
Вот {N} примеров, где старый промпт ошибался, и {M} примеров,
где старый промпт был прав (контрольная группа):
{примеры}
Прогони новый промпт на этих примерах и сравни с результатом старого.
Но перед тем как я буду считать это улучшением, напомни мне:
результат на маленькой выборке может не подтвердиться на всех данных —
нужно перепроверить хотя бы на 5-10 раз большем количестве случаев.
🚀 Быстрый старт — вставь в чат:
Я дорабатываю промпт для задачи: {твоя задача классификации/разметки}.
Помоги мне спроектировать честную проверку правки промпта —
на скольких примерах нужно тестировать, чтобы не обмануться результатом
на маленькой выборке, и как разделить примеры на "проблемные" и "контрольные".
[вставить шаблон выше]
LLM спросит про размер твоей исходной выборки данных и характер ошибок, которые ты пытаешься исправить — потому что от этого зависит, сколько примеров нужно для надёжной проверки.
Ограничения
⚠️ Узкая задача: Выводы про стабильность ответов (99,7% согласия) получены на простой бинарной задаче. На более сложных или субъективных вопросах модель может путаться в своих ответах гораздо сильнее.
⚠️ Один тип ошибок: Синтетические ошибки в бренде были грубыми (явная подмена производителя на случайный другой). Реальные ошибки в данных обычно тоньше, и там разрыв между LLM и простым правилом может быть другим.
⚠️ Один язык модели: Проверяли только GPT-4o-mini. Другие модели могут вести себя иначе — как по точности, так и по стабильности повторных ответов.
⚠️ Ловушка маленькой выборки касается тебя тоже: если ты дорабатываешь промпт и тестируешь на 10-20 примерах, у тебя может быть та же проблема, что в исследовании — правка выглядит отлично локально и портит результат в целом.
Как исследовали
Исследователь взял два открытых датасета: Abt-Buy (2194 пары товаров из двух каталогов, где вручную размечено, какие пары — это один и тот же товар) и подмножество товаров Amazon (500 карточек, где половине искусственно подменили производителя). На первом сравнивали простой алгоритм пересечения слов с GPT-4o-mini в zero-shot и few-shot режимах, на втором — простую проверку «есть ли имя производителя в тексте названия» против той же модели.
Самое интересное — попытка «улучшить» промпт для entity matching: добавили правило приоритета кода товара, проверили на 117 отобранных примерах (67 ошибок + 50 контроль), увидели явное улучшение — и тут же получили просадку на всём датасете из 2194 пар. Это конкретно показывает, почему маленькая проверка обманывает: локальный паттерн не масштабируется.
Для проверки стабильности модель гоняли 5 раз на 200 парах при температуре 0.7 (не нулевой, чтобы был реальный разброс) — и она совпала сама с собой в 99% случаев. Отсюда вывод: голосование по нескольким прогонам почти не улучшает результат, а стоит в 5 раз дороже.