TL;DR
Если просишь LLM найти важное среди списка задач, писем или сообщений — не давай ей только важное. Исследование показало: когда в промпт кроме нужных пунктов подмешаны неважные пункты того же типа, модель точнее оценивает, что действительно важно. Механика простая: модель без примеров «неважного» не знает, где проходит граница, и начинает завышать оценку важности всему подряд.
Боль знакома всем, кто просил LLM разобрать переписку или список задач: модель то помечает важным всё, то путается, что действительно требует внимания. Причина — у модели нет внутреннего эталона, что считать «неважным», если ей показали только избранное. Она как человек, которому дали только пятёрки на проверку и попросили сказать, какая из них самая сильная — сравнивать не с чем.
Метод — relevance-contrast context: держи фиксированный размер контекста (например, 10 пунктов), но замени часть высокорелевантных пунктов на низкорелевантные пункты того же домена (те же письма, но неважные, а не случайный текст откуда угодно). Модель получает контраст — и её оценка релевантности целевых пунктов становится точнее.
Схема метода
ШАГ 1: Собери пункты для анализа (письма, задачи, сообщения) → список
ШАГ 2: Не фильтруй жёстко только на «важное» → оставь 30-50% явно неважных пунктов того же типа
ШАГ 3: Подай весь смешанный список в один промпт с просьбой оценить важность каждого → модель точнее калибрует шкалу
Все шаги — в одном запросе к LLM, без API и кода.
Пример применения
Задача: Ты фаундер небольшого стартапа, у тебя за день накопилось 40 сообщений в общем чате команды (Telegram/Slack), и ты просишь LLM выделить, что требует твоего решения сегодня.
Промпт:
Вот 40 сообщений из рабочего чата команды за сегодня.
Некоторые из них важные (решения, блокеры, дедлайны),
некоторые — обычная рабочая болтовня без действий.
Не удаляй и не игнорируй "неважные" сообщения —
покажи их в списке тоже, отметив как неважные.
Это поможет тебе точнее откалибровать, что действительно критично.
Оцени каждое сообщение по шкале:
0 — не относится к работе
1 — упомянуто, но без решения/действия
2 — важный статус, стоит знать
3 — требует решения/действия сегодня
Сообщения:
{вставить все 40 сообщений подряд, включая рутинные}
Выведи только пункты с оценкой 2-3, отсортированные по важности.
Результат: Модель выдаст список приоритетных сообщений с оценками. Если сравнить с промптом, куда заранее вручную отобрать только «похожие на важные» сообщения — точность распознавания реально критичных пунктов будет ниже. Смешанный список с «шумом» того же домена даёт модели ориентир, где проходит граница важности.
Почему это работает
LLM не имеет фиксированной шкалы важности «в голове» — она оценивает относительно того, что видит в этом самом промпте. Если показать ей только избранное, она теряет точку отсчёта и начинает раздувать оценки — «всё кажется важным, если вокруг нет ничего неважного».
Модель хорошо умеет улавливать относительные контрасты: сравнивать один пункт с другим внутри одного контекста. Метод использует эту способность — специально подсовывает «эталон неважности», чтобы модель откалибровала шкалу, а не гадала на глазах у пустоты.
Рычаг управления: соотношение сигнал/шум. Исследование показало, что оптимум — широкое плато от 30% до 50% действительно важных пунктов в списке (то есть 50-70% «мусора» того же типа). Если у тебя мало неважных примеров — добавь искусственно (старые задачи, закрытые вопросы) просто чтобы дать модели контраст.
Шаблон промпта
Вот список {тип_контента} за {период}.
Среди них есть важные пункты ({критерий_важности})
и неважные — обычная рутина без действий.
НЕ фильтруй список заранее. Покажи мне все пункты, включая неважные —
это поможет тебе точнее понять, где граница важности.
Оцени каждый пункт по шкале:
0 — не относится к делу
1 — упомянуто, но без решения
2 — стоит знать, но не критично
3 — требует действия/решения
Список:
{вставить все пункты подряд без предварительной чистки}
Выведи финально только пункты с оценкой 2-3.
Подставь: {тип_контента} — письма/задачи/сообщения/отзывы, {период} — день/неделя, {критерий_важности} — что для тебя считается важным.
🚀 Быстрый старт — вставь в чат:
Вот шаблон relevance-contrast context. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой тип контента ты анализируешь и по какому критерию считать пункт важным — потому что без этого не сможет подобрать правильную шкалу оценки.
Ограничения
⚠️ Эффект неравномерен по типам контента: в исследовании выигрыш был заметен для писем (где важного мало и легко потеряться), но почти нулевой для встреч и чатов, где доля важного изначально высокая. Проверяй эффект на своём типе данных перед тем как полагаться на него.
⚠️ Позиция важнее только на длинных контекстах: на коротких списках (до ~10-15 пунктов) порядок пунктов почти не влияет на точность. На больших объёмах (30+ пунктов) важное может «затеряться» в середине — тогда выноси критичное в начало или конец.
⚠️ Эффект слабеет у моделей с расширенным рассуждением: для одной из моделей (Claude с включённым глубоким рассуждением) эффект контраста практически исчезал — модель сама выводила границу важности без подсказок. Для моделей без reasoning-режима метод работает надёжнее.
⚠️ Не любой шум работает: метод требует шума того же домена (неважные письма среди писем), а не случайного нерелевантного текста — иначе эффект может не проявиться или навредить.
Как исследовали
Исследователи взяли 661 реальное рабочее сообщение (письма, чаты, транскрипты встреч) одного специалиста за неделю, вручную разметили каждое по шкале важности 0-3, и прогнали 2420 тестов через 11 разных настроек моделей (включая GPT и Claude с разными уровнями рассуждения). Сравнивали, как точно модель оценивает важность целевых пунктов, когда в промпте только важное — против промптов, где часть важного заменена на неважное того же типа.
Результат оказался противоречащим интуиции: логика подсказывает, что «чем чище контекст — тем лучше», но на практике смешанный список с 50% неважных пунктов дал заметно более точную оценку важности, чем список из одних важных пунктов. Эффект подтвердился почти во всех моделях и устоял после проверки на дублирующихся данных и разных статистических срезах.
Отдельно проверили гипотезу про «умное объединение» — когда модель пять раз извлекает данные из одного текста, а потом LLM пытается слить пять версий в одну. Оказалось, что простое механическое объединение уникальных найденных пунктов работает не хуже (а часто лучше), чем попытка LLM «умно» синтезировать результат — умный синтез иногда терял редкие находки, которые попались только в одном из пяти прогонов.