TL;DR
Исследование сравнило пять промпт-стратегий (zero-shot, few-shot, chain-of-thought, constraint-based, role-based) на трёх RE-задачах: классификация отзывов по типу запроса (feature request / bug report), классификация по типу нефункционального требования (NFR), и генерация требований-спецификаций. Тестировали на легковесных open-source LLMs (Llama, Mistral, Gemma, Phi-3) с датасетами app reviews.
Главные находки по эффективности промптинга: Few-shot промптинг показал лучшие результаты для классификации явных запросов (F1≈0.68-0.74), опережая zero-shot на 15%. Chain-of-thought слегка помогает при классификации неявных качеств вроде NFR (F1≈0.51 vs 0.47), но эффект скромный. Constraint-based промпты почти не улучшают качество генерации требований. Проблема: LLM плохо определяют неявные качества типа usability, reliability (NFR classification F1≈0.47-0.55) — модели не улавливают контекстно-зависимые выражения и им не хватает экспозиции к RE-терминологии.
Генерация требований: LLM создают читаемые и связные тексты (Clarity=4-5/5, Completeness=4/5), но часто многословны, не следуют структуре (Structure=2.6/5), и галлюцинируют факты — добавляют требования, которых не было в исходном фидбеке (Fidelity=3/5). Модели хороши как черновик, но требуют ручной проверки.
Промпт-стратегии
Исследование сравнило 5 промпт-стратегий:
Zero-shot — базовая инструкция без примеров Few-shot — инструкция + 2-3 размеченных примера Chain-of-thought (CoT) — требование рассуждать пошагово перед ответом Constraint-based — явные правила вывода (формат, ограничения) Role-based — назначение роли (например, "ты — аналитик требований")
Производительность по задачам:
Классификация запросов (feature request / bug report):
- Few-shot: F1=0.68 (лучший)
- Zero-shot: F1=0.59
- Chain-of-thought: F1=0.64
Классификация NFR:
- Chain-of-thought: F1=0.51 (лучший)
- Few-shot: F1=0.49
- Zero-shot: F1=0.47
Генерация требований (оценка 1-5):
- Few-shot & CoT: 3.6/5 (лучшие)
- Остальные: 3.0-3.4/5
Примеры применения
Задача 1: Классификация отзывов на продукт по типу запроса
Задача: У вас куча отзывов на Авито после редизайна. Нужно понять сколько там багов, а сколько просьб о фичах, чтобы приоритизировать работу команды.
Промпт (Few-shot):
Классифицируй отзывы пользователей на три типа: feature request (просьба о новой функции), bug report (сообщение об ошибке), other (всё остальное).
Примеры:
"Добавьте тёмную тему" → feature request
"Приложение вылетает при открытии чата" → bug report
"Хороший сервис, пользуюсь каждый день" → other
Теперь классифицируй эти отзывы:
{список из 50-100 отзывов}Результат: Модель выдаст каждому отзыву метку. Точность ~70% (F1=0.68-0.74 по исследованию). Явные баги и запросы фичей определяет хорошо. Неявные жалобы на UX или производительность может пропустить или отнести в "other".
Задача 2: Определение проблем с качеством (NFR) в отзывах
Задача: Продуктовая команда Яндекс.Маркета хочет узнать на какие качества жалуются пользователи: скорость, удобство, безопасность. Нужно разобрать отзывы по категориям NFR (performance, usability, security и т.д.).
Промпт (Chain-of-thought):
Ты — аналитик требований. Классифицируй отзывы пользователей по типу упомянутого нефункционального требования: performance (производительность), usability (удобство), security (безопасность), reliability (надёжность), other.
Рассуждай пошагово:
1. Определи о каком качестве говорит отзыв
2. Проверь есть ли явные указатели (медленно, непонятно, ненадёжно)
3. Дай финальную категорию
Отзывы:
{список отзывов}Результат: Модель покажет промежуточные рассуждения ("отзыв упоминает 'тормозит' → это про скорость → performance") и финальные метки. Точность ~50% (F1=0.47-0.55). Слабое место: неявные качества вроде "запутанный интерфейс" (usability) или "иногда зависает" (reliability) модель часто относит в "other" или путает категории.
Задача 3: Генерация требований из отзывов клиентов B2B-сервиса
Задача: В СберБизнес собрали 20 отзывов корпоративных клиентов. Нужно превратить их в документ с требованиями для следующей версии платформы.
Промпт (Constraint-based + Role-based):
Ты — бизнес-аналитик. На основе отзывов клиентов создай документ с требованиями в формате:
**Функциональные требования:**
- Требование должно быть тестируемым и однозначным
- Формат: "Система должна [действие]"
- Каждое требование уникально
**Нефункциональные требования:**
- Укажи качественные атрибуты (скорость, безопасность, удобство)
- Формат: "Система должна обеспечить [качество]"
Ограничения:
- Не добавляй требования, которых нет в отзывах
- Избегай детали реализации
- Будь кратким
Отзывы клиентов:
{20 отзывов}Результат: Модель создаст читаемый документ с разделами "Функциональные" и "Нефункциональные требования". Текст будет связным (Clarity≈4-5/5) и покрывающим отзывы (Completeness≈4/5). Проблемы: местами многословно (Conciseness≈2-3/5), может добавить 1-2 требования, которых не было в отзывах (Fidelity≈3/5), структура может сбиться (Structure≈2.6/5). Используйте как черновик для ручной доработки.
Почему это работает (и почему не работает)
Сильная сторона LLM: Распознавание явных паттернов. Когда пользователь пишет "добавьте функцию X" или "приложение крашится при Y" — модель легко сопоставляет с категориями feature request / bug report. Few-shot примеры усиливают это, показывая модели конкретные образцы похожих фраз.
Слабость LLM: Интерпретация контекстно-зависимых и неявных выражений. Фраза "запутанный дизайн кнопок" требует понимания, что это про usability. "Иногда подвисает" — про reliability или performance? Модель не различает нюансы, потому что ей не хватает экспозиции к RE-терминологии и контексту. Chain-of-thought помогает слегка (+4% F1), заставляя модель "рассуждать", но не решает проблему нехватки знаний.
Почему Few-shot эффективнее Zero-shot (+15% F1): Zero-shot полагается только на предобученные знания модели — она догадывается из общих паттернов. Few-shot даёт якорные примеры прямо в промпте — модель видит "вот так выглядит feature request, а вот bug report" и копирует паттерн. Это особенно полезно для task-specific терминологии.
Почему constraint-based не спасает генерацию: Ограничения типа "будь кратким" или "следуй структуре" — это мягкие инструкции, не жёсткие правила. LLM интерпретирует их как текстовые подсказки, но не гарантирует выполнение. Модель может галлюцинировать (добавить требования из "общих знаний", а не из фидбека), потому что не понимает разницу между "генерация текста" и "извлечение фактов". Constraint-based промпты НЕ компенсируют эту фундаментальную слабость.
Рычаги управления промптом:
- Количество примеров в Few-shot → больше примеров = лучше точность, но дороже токены. Для простых задач хватает 2-3, для сложных NFR — 5-7.
- Явность инструкций в CoT → замени "рассуждай пошагово" на "1. найди ключевые слова, 2. сопоставь с категорией, 3. дай ответ" — модель следует строже.
- Формат вывода → constraint "отвечай ТОЛЬКО категорией" vs "объясни почему выбрал категорию" — первое экономит токены, второе показывает логику для отладки.
Шаблоны промптов
Few-shot классификация запросов
Классифицируй отзывы пользователей на три типа:
- feature request (просьба о новой функции)
- bug report (сообщение об ошибке)
- other (всё остальное)
Примеры:
"{пример_feature_request}" → feature request
"{пример_bug_report}" → bug report
"{пример_other}" → other
Теперь классифицируй эти отзывы:
{список_отзывов}Что подставлять:
{пример_feature_request}— реальный отзыв с просьбой о фиче{пример_bug_report}— отзыв с описанием бага{пример_other}— нейтральный/неинформативный отзыв{список_отзывов}— отзывы для классификации (по одному на строку)
Chain-of-thought классификация NFR
Классифицируй отзывы по типу нефункционального требования:
- performance (производительность)
- usability (удобство)
- security (безопасность)
- reliability (надёжность)
- other
Для каждого отзыва:
1. Определи о каком качестве идёт речь
2. Найди ключевые слова (медленно, непонятно, ненадёжно, опасно)
3. Дай финальную категорию
Отзывы:
{список_отзывов}Constraint-based генерация требований
На основе отзывов пользователей создай документ с требованиями.
Структура:
**Функциональные требования:**
- Формат: "Система должна [действие]"
- Каждое требование тестируемо и однозначно
**Нефункциональные требования:**
- Формат: "Система должна обеспечить [качество]"
Правила:
- Не добавляй требования, которых нет в отзывах
- Избегай деталей реализации
- Будь кратким — одно требование на одно предложение
Отзывы:
{список_отзывов}Что подставлять:
{список_отзывов}— от 5 до 50 отзывов (больше = риск потери фокуса)
🚀 Быстрый старт — вставь в чат:
Вот шаблон для генерации требований из отзывов. Адаптируй под мою задачу: [опиши задачу — например, "отзывы на мобильное приложение банка"].
[вставить шаблон выше]LLM спросит какие отзывы обработать и какие разделы важны (только функциональные или все). Она возьмёт структуру из шаблона и адаптирует формулировки под твой контекст.
Ограничения
⚠️ Классификация NFR: LLM плохо определяют неявные качества — точность ~50% (F1=0.47-0.55). Фразы вроде "запутанный интерфейс" или "иногда зависает" часто попадают в категорию "other" или путаются между usability/reliability/performance.
⚠️ Галлюцинации в генерации: Модели добавляют требования, которых не было в отзывах (Fidelity≈3/5). Пример: отзыв "медленно грузится" → модель генерирует "Система должна загружаться за 2 секунды" (конкретная цифра — галлюцинация).
⚠️ Многословность: Сгенерированные требования часто избыточны (Conciseness≈2-3/5). Модель расписывает одно требование на 2-3 предложения вместо одного.
⚠️ Структурная непоследовательность: Модели не всегда следуют заданной структуре документа (Structure≈2.6/5). Могут пропустить секции или смешать функциональные и нефункциональные требования.
⚠️ Английский датасет: Исследование проводилось на английских app reviews. Эффективность на русском языке может отличаться.
Как исследовали
Команда взяла два датасета с размеченными отзывами: 2,912 отзывов для классификации запросов (feature/bug/other) и 4,000 для NFR (performance/usability/security/reliability). Протестировали 5 легковесных LLM (Llama 2/3, Mistral, Gemma, Phi-3) на 3 промпт-стратегиях для классификации (zero-shot, few-shot, CoT) и 5 стратегиях для генерации (+ constraint-based, role-based).
Сравнивали с ground truth: предсказания модели vs. ручные аннотации → считали Precision, Recall, F1-score. Для генерации требований взяли 90 случайных отзывов и попросили модели создать спецификации. Один автор оценил качество по 5 критериям (структура, полнота, точность, краткость, ясность) по шкале 1-5.
Почему Few-shot победил: Разница между zero-shot (F1=0.59) и few-shot (F1=0.68) статистически значима — +15% точности. Это работает потому что примеры в промпте дают модели конкретные якоря. Модель видит "вот так выглядит feature request в ЭТОМ домене" и применяет паттерн, а не догадывается из общих знаний.
Почему NFR classification провалилась: Модели показали F1=0.47-0.55 — чуть выше случайного. Главная причина: NFR-категории требуют интерпретации контекста ("запутанный интерфейс" = usability? "долго грузится" = performance или reliability?). LLM не хватает domain expertise в RE-терминологии. CoT помог слегка (+4% F1), заставляя рассуждать пошагово, но не компенсировал нехватку знаний.
Сюрприз: Constraint-based промпты НЕ улучшили качество генерации. Средний балл 3.0-3.2/5 для всех стратегий, кроме few-shot и CoT (3.6/5). Явные ограничения типа "будь кратким" не заставили модель писать короче — она всё равно была многословной (Conciseness≈2-3/5).
Ресурсы
Статья: From Online User Feedback to Requirements: Evaluating Large Language Models for Classification and Specification Tasks (2025)
Авторы: Manjeshwar Aniruddh Mallya, Alessio Ferrari, Mohammad Amin Zadenoori, Jacek Dąbrowski
Организации: University of Limerick (Lero), University College Dublin, University of Padova
Replication package: https://github.com/jsdabrowski/REFSQ-2026/
Датасеты: User Request Dataset (2,912 reviews), NFR Dataset Lu & Liang (4,000 reviews)
Модели: Llama 2 (7B), Llama 3 (8B), Mistral (7B), Gemma 2 (9B), Phi-3 Mini (3.8B)