TL;DR
PromptPack — техника, которая позволяет закинуть в LLM сразу пачку однотипных задач (теги, категории, разметка) без того, чтобы модель путала данные разных элементов между собой. Суть в том, что каждый элемент оборачивается в XML-тег с уникальным номером, а модель обязана вернуть этот номер обратно в ответе — так сохраняется чёткая привязка «какой ответ к какому элементу».
Проблема, которую решает метод: когда просишь LLM обработать список из 10-20 похожих объектов (заголовки, отзывы, товары) простым текстовым списком, признаки соседних элементов начинают «просачиваться» друг в друга. Модель, например, приписывает тег «финансы» объявлению про доставку еды, потому что рядом в списке было объявление банка — она путает контекст, особенно если элементы похожи по теме. Авторы называют это context bleeding — «смешивание контекста».
Решение — обернуть каждый элемент в явный
Схема метода
ШАГ 1 (один раз в начале промпта): Задать общие правила разметки —
формат ответа, шкала уверенности с примерами, словарь тегов → текстовая инструкция
ШАГ 2 (в том же промпте): Обернуть каждый элемент батча:
- текст элемента 1
- текст элемента 2
...
ШАГ 3 (в том же промпте): Попросить вернуть JSON-массив,
где каждая запись содержит id элемента и присвоенные теги
ШАГ 4 (опционально, отдельный запрос): Если для какого-то id ответа
не пришло или он битый — переспросить его отдельно, поштучно
Все шаги 1-3 выполняются в одном запросе. Шаг 4 — отдельный запрос-«починка», только для проблемных элементов.
Пример применения
Задача: Маркетолог ведёт 40 объявлений на Авито и хочет быстро протегировать их по теме, тону и стилю текста, чтобы понять, какие заголовки «продающие», а какие «нейтральные», перед тем как переписывать слабые.
Промпт:
Ты — система разметки текстов. Для каждого объявления определи:
- тема (одна-две штуки): электроника, мебель, авто, услуги, недвижимость...
- тон: продающий, нейтральный, срочный, эмоциональный
- стиль: разговорный, деловой, кричащий (капс/восклицания), лаконичный
Шкала уверенности: 0.9 = однозначно виден признак в тексте,
0.5 = признак вероятен, но не явный, 0.2 = слабый намёк.
Формат ответа — JSON-массив, каждая запись содержит поле "id"
(скопируй из тега item), и теги с уверенностью через точку с запятой.
- Диван угловой, срочно, самовывоз, торг
- iPhone 13 128GB — идеальное состояние, чехол в подарок
- РЕМОНТ КВАРТИР ПОД КЛЮЧ!!! ЗВОНИ СЕЙЧАС!!!
... (до 40 объявлений)
Результат: Модель вернёт единый JSON-массив из 40 объектов, где у каждого — свой id и набор тегов с уверенностью (например: {"id": 3, "тема": "услуги;0.9", "тон": "срочный;0.85", "стиль": "кричащий;0.9"}). Один запрос вместо 40 отдельных — экономия времени и лимитов сообщений, при этом теги не «перетекают» между объявлениями благодаря явным границам
Почему это работает
Когда в один промпт закидываешь список из десятков похожих объектов простым текстом (просто через запятую или нумерованный список), модель обрабатывает всё как единый поток слов. Границы между объектами размыты, и внимание модели «расплывается» — признаки одного элемента цепляются к соседнему, особенно если они похожи по теме.
Зато LLM отлично считывает XML — она видела миллионы XML/HTML-документов при обучении и хорошо понимает, что тег открылся, а тег закрылся — значит, это отдельный, изолированный кусок. Это её сильная сторона: чёткая разметка структуры.
Метод берёт эту сильную сторону и заставляет модель держать привязку данных к элементу через id — модель обязана скопировать номер в ответ, а не просто «угадать порядок». Это как бирки на чемоданах: даже если чемоданы похожи, бирка с номером не даст их перепутать.
Рычаги управления: - Размер батча — для простых задач (короткие однотипные тексты) можно брать 20-30 элементов, для сложных и разнородных — держать 5-10, иначе точность падает. - Шкала уверенности с примерами («0.9 значит вот что конкретно, 0.5 — вот что») — без конкретных якорей модель начинает ставить одинаковые цифры почти всем тегам. - Не требуй строгий JSON-режим (function calling/structured output) — исследование показало, что жёсткая схема душит качество разметки. Лучше дать один живой пример в промпте («вот как выглядит правильный ответ») и потом почистить руками или попросить модель исправить формат отдельным запросом.
Шаблон промпта
Ты — система разметки {тип контента}. Для каждого элемента определи
следующие признаки: {список признаков, например: тема, тон, стиль}.
Шкала уверенности:
0.9 = признак явно виден в тексте
0.5 = признак вероятен, но не выражен прямо
0.2 = слабый намёк на признак
Формат ответа — JSON-массив. Каждая запись содержит поле "id"
(скопируй значение из атрибута item id) и теги с уверенностью
через точку с запятой (например: "тема": "спорт;0.8").
Вот пример правильного ответа для одного элемента:
{пример входа и ожидаемого JSON-выхода}
- {элемент 1}
- {элемент 2}
...
- {элемент N}
Подставь: тип контента (отзывы, заголовки, комментарии), список нужных признаков, пример хорошего ответа, сами элементы для разметки.
🚀 Быстрый старт — вставь в чат:
Вот шаблон PromptPack для пакетной разметки текстов. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие признаки размечать и сколько элементов в батче — потому что от этого зависит, насколько подробной должна быть шкала уверенности и не переполнится ли контекст.
Ограничения
⚠️ Модель может «терять» id при большом батче: если элементов слишком много (особенно на слабых моделях), модель может не вернуть ответ для части id или перепутать порядок — нужна проверка совпадения количества входов и выходов и повторный запрос для потерянных элементов.
⚠️ Работает для разметки/тегирования, не для глубокого анализа: метод проверен на задаче извлечения простых тегов из коротких текстов. Для задач, где каждый элемент требует долгого рассуждения (анализ договора, разбор кода), пакетная обработка размывает внимание модели — лучше обрабатывать по одному.
⚠️ Разнородные элементы в одном батче снижают точность: если элементы сильно различаются по теме или длине, границы XML не спасают полностью — модель всё равно может путать редкие/нетипичные элементы с окружением.
Как исследовали
Команда взяла 10 000 реальных рекламных заголовков из продакшена и проверяла, как разные способы упаковки промпта влияют на качество итоговых тегов. Тестировали 4 модели (gpt-4.1-nano, gpt-4o-mini, claude-haiku-4.5, gemini-2.5-flash) на размерах батча от 1 до 20 элементов, сравнивая XML-обёртку с обычным нумерованным списком и с методами из других статей (симуляция параллельных запросов, ансамблирование через перемешивание порядка элементов).
Качество мерили через то, насколько хорошо итоговые теги помогают простой модели предсказывать клики по рекламе (ROC-AUC) — то есть не абстрактную «правильность» тегов, а их реальную полезность. Дополнительно ввели свою метрику VWAL, которая показывает, сколько «сигнала» несут теги отдельно от итоговой точности — это помогло понять, почему AUC ведёт себя так, а не просто зафиксировать факт.
Главный неожиданный результат: батч из 20 элементов с XML-обёрткой не потерял в точности почти нигде, а на одной из моделей даже дал лучший результат за весь эксперимент — потому что ансамблирование по нескольким прогонам с разным порядком элементов отфильтровало случайный шум мелкой модели. Это подтверждает: сама природа падения качества при батчинге — это путаница контекста, а не фундаментальный лимит модели, и явные границы её действительно лечат.