PartialOrderEval: как детализация промпта влияет на качество кода от LLM

ИСТОЧНИК: HumanEval (164 задачи Python) + ParEval (120 задач C++/OpenMP)
↓
ДЛЯ КАЖДОЙ ЗАДАЧИ:
 1. Создать ptop (максимально детальный промпт) → pass@1 ≥ 0.8
 2. Сгенерировать 39 промптов убывающей детализации:
 - LLM Summarization (7 вариантов): 200→150→100→75→50→25→10 слов
 - Paragraph Sampling (16 вариантов): удалить 20%/40%/60%/80% параграфов
 - Sentence Block Masking (16 вариантов): вырезать блоки предложений
 3. pbot (минимальный промпт) — только сигнатура
↓
ОЦЕНКА: 8 моделей (Qwen2.5-Coder 1.5B→14B, Llama-3.x 1B→70B)
МЕТРИКА: pass@1 для каждого уровня детализации
↓
РЕЗУЛЬТАТ: Графики "детализация → pass@1" для каждой модели и бенчмарка

Задача из ParEval-Serial:

// Оригинальный промпт (краткий):
// Напишите функцию prefix_sum, которая вычисляет префиксную сумму массива.

// Максимально детальный промпт (ptop):
// Напишите функцию prefix_sum для вычисления префиксной суммы.
// 
// ВХОД:
// - arr: массив целых чисел длиной n (1 ≤ n ≤ 10^6)
// - n: размер массива
// 
// ВЫХОД:
// - Массив той же длины, где result[i] = sum(arr[0]...arr[i])
// 
// EDGE CASES:
// - Если n = 1, вернуть копию arr
// - Если arr пустой (n = 0), вернуть пустой массив
// - Обработать переполнение при sum > INT_MAX
// 
// АЛГОРИТМ:
// 1. Создать result[n]
// 2. result[0] = arr[0]
// 3. Для i от 1 до n-1: result[i] = result[i-1] + arr[i]
// 4. Вернуть result
// 
// ПРИМЕР:
// arr = [1, 2, 3, 4], n = 4 → [1, 3, 6, 10]
// arr = [-1, 1], n = 2 → [-1, 0]

Результат:

• Оригинальный промпт: Qwen2.5-14B — 66.7% pass@1
• Детальный промпт (ptop): Qwen2.5-14B — 96.7% pass@1
• Прирост: +30%

Слабость LLM: Модели обучены на коде из GitHub, где функции окружены контекстом — импорты, другие функции, комментарии, примеры использования. В бенчмарках этого контекста нет. Модель видит только сигнатуру prefix_sum(arr, n) и должна угадать все детали реализации. На простых задачах (HumanEval: "перевернуть строку") контекста не нужно — паттерн однозначен. На сложных (ParEval: параллельная prefix sum с OpenMP) — модель теряется в вариантах.

Сильная сторона LLM: Модели отлично следуют структурированным инструкциям, если они explicit. Когда промпт содержит спецификацию I/O, edge cases, пошаговый алгоритм — модель не угадывает, а следует протоколу. Это снижает вариативность и повышает корректность. Особенно это работает на задачах, где один неучтённый edge case ломает все тесты (например, пустой массив или переполнение).

Рычаги управления детализацией:

• Длина промпта — короткий (10-50 слов) vs развёрнутый (150-200 слов). На HumanEval плато при 100 словах, на ParEval — нужно 200+.
• Тип деталей — I/O спецификация даёт больший прирост, чем абстрактное описание алгоритма.
• Структура — пошаговая декомпозиция (1. проверь input, 2. примени алгоритм) работает лучше, чем общее описание.

Diminishing returns: На HumanEval добавление деталей после 100 слов снижает pass@1 (с 92.1% при 200 словах до 86% при ptop). Избыточная информация создаёт когнитивную перегрузку — модель теряет фокус среди лишних деталей.

Исследователи проанализировали 284 промпта и выделили 23 типа деталей, разбитых на 4 категории. Вот топ-10 по влиянию на pass@1:

Высокий рост с детализацией (критичные):

• 1.3 Input Specification — типы, структуры, ограничения входных данных
• 1.4 Output Specification — формат возвращаемого значения
• 1.5 Core Behavior — что именно должна делать функция
• 2.3 Edge Case Handling — обработка пустых массивов, max значений
• 3.4 Implementation Sketch — пошаговая декомпозиция или псевдокод

Умеренный рост (полезные):

• 1.1 Task Goal — одно предложение о цели (есть в 100% промптов)
• 3.1 Algorithmic Strategy — общая стратегия (сортировка, рекурсия)
• 3.2 Data Structure — какие структуры использовать (array, hash map)
• 3.5 Implementation Patterns — типовые паттерны (two-pointer, prefix sum)

Практический вывод: Приоритет — explicit I/O, edge cases, пошаговая инструкция. Абстрактные описания алгоритмов дают меньший эффект — модель и так понимает стратегию.

⚠️ Лёгкие задачи: На HumanEval (простые алгоритмы) детализация даёт +6% pass@1, плато при 100 словах.

⚠️ Избыточная детализация: Промпты длиннее 200 слов могут снизить pass@1 на 3-6% из-за когнитивной перегрузки.

⚠️ Модели-малыши: Llama-3.2-1B не догоняет Qwen2.5-14B даже с максимально детальным промптом. Размер модели важнее промпта.

Команда взяла два бенчмарка: HumanEval (164 задачи Python, простые алгоритмы) и ParEval (120 задач C++/OpenMP, научное и параллельное программирование). Для каждой задачи сгенерировали максимально детальный промпт через GPT-4.1 так, чтобы Qwen2.5-14B выдавал pass@1 ≥ 0.8. Затем автоматически создали 39 промптов убывающей детализации через три стратегии: суммаризация LLM (от 200 до 10 слов), случайное удаление параграфов (20-80%), вырезание блоков предложений (20-80%).

Протестировали 8 моделей (Qwen2.5-Coder 1.5B→14B, Llama-3.x 1B→70B) на всех 284 задачах × 41 промпт = 11,644 оценки. Построили графики "детализация → pass@1" для каждой модели. Результаты показали, что:

• На ParEval кривые растут медленно и не достигают потолка даже при максимальной детализации.
• На HumanEval кривые быстро выходят на плато (при 100 словах) и иногда падают при избыточной детализации.
• Разница между большими и малыми моделями на ParEval достигает 34% pass@1 (Qwen2.5-14B vs 1.5B при детализации 80%).

Удивительно: с максимально детальными промптами (ptop) модели достигают 98.3% на ParEval-Serial и 96.7% на ParEval-OMP — это выше HumanEval (86%), который считался "лёгким". Значит, ParEval не сложнее HumanEval по природе задач — просто оригинальные промпты ParEval недостаточно детальные.

Качественный анализ провели через таксономию 23 типов деталей, созданную с помощью o3 и применённую Claude Sonnet 4 ко всем 284 промптам. Это позволило увидеть, какие детали появляются чаще при росте pass@1.

More Than a Score: Probing the Impact of Prompt Specificity on LLM Code Generation

Yangtian Zi (Northeastern University), Harshitha Menon (Lawrence Livermore National Laboratory), Arjun Guha (Northeastern University)