TL;DR
Когда просишь LLM «найди проблемы» — она ищет всё сразу и находит меньше. Когда говоришь «найди конкретно вот это» — точность растёт. Исследователи из TU Berlin проверили на реальных уязвимостях WordPress-плагинов: узкий, сфокусированный промпт стабильно обходит широкий — даже если широкий формально «умнее» (подробная роль, пошаговый Chain-of-Thought).
Главная неочевидная находка: LLM непредсказуемо меняет ответ при повторных запросах. Один и тот же промпт к одному и тому же документу — результат другой. Часть моделей ведёт себя как подбрасывание монеты: найдёт / не найдёт 50/50 при повторах. Это не особенность одной модели — это общее свойство всех протестированных, включая топовые.
Следствие: одного запуска недостаточно для важного анализа. Хочешь надёжный результат — запроси 2–3 раза и сравни. И чем уже сформулирована задача — тем выше шанс попасть.
Схема метода
ШАГ 1: Сформулируй узкий запрос
→ укажи конкретный тип проблемы, а не «найди всё»
ШАГ 2: Запусти 2–3 раза с одним и тем же промптом
→ каждый запуск — отдельный запрос
ШАГ 3: Сравни ответы
→ доверяй тому, что повторяется; разовые находки — перепроверяй
Все шаги — в обычном чате, отдельными сообщениями. Никакого кода.
Пример применения
Задача: Есть договор с подрядчиком на 800 000 рублей. Хочешь проверить через Claude, нет ли там ловушек.
❌ Широкий промпт — работает хуже:
Проверь этот договор на риски и проблемы.
[текст договора]
✅ Узкий промпт — по принципу из исследования:
Ты юридический аналитик, защищающий интересы заказчика.
Задача: найди в этом договоре риски конкретно по условиям расторжения —
кто может расторгнуть, при каких условиях, какие штрафы и для кого.
Правила:
— анализируй только то, что написано в тексте
— не предполагай намерений, которых нет в документе
— если условие неоднозначно — прямо это укажи
Финал: список рисков с цитатами из текста.
[текст договора]
Результат: Модель выдаст список конкретных рисков по расторжению с прямыми цитатами. Потому что не распыляется по всему договору — сканирует одну зону. Повтори промпт 2–3 раза и сравни ответы: стабильные находки во всех трёх — доверяй, разовые — перепроверяй вручную.
Почему это работает
При широком запросе («найди все проблемы») LLM распыляет внимание — проходит поверхностно по всему и на каждую конкретную категорию тратит мало ресурса рассуждений. В результате — поверхностный анализ и много ложных находок. Любопытный факт из исследования: при широком промпте Claude выдал 48 находок в одном отчёте — большинство галлюцинации.
Узкий запрос сужает пространство поиска. Модель не думает о сотнях типов проблем — концентрируется на одном. Поэтому точность растёт, а мусора меньше.
Про непостоянство: LLM генерирует текст со встроенной случайностью. Для простых фактов это незаметно. Для сложного анализа — разница между запусками может быть огромной. Отсюда правило: несколько запусков → сравни → доверяй повторяющемуся.
Рычаги управления: - Сужай тип задачи — «условия расторжения» вместо «риски» → точнее результат - Запрет на предположения — «анализируй только текст» → меньше галлюцинаций - Формат вывода с цитатами → легче сравнивать результаты разных запусков - Число повторов — 2 запуска минимум, 3 для критичных решений
Шаблон промпта
Ты {роль: эксперт в области X}.
Задача: найди в этом {тип документа} конкретно {узкая категория проблем}.
Правила:
— анализируй только то, что есть в тексте
— не предполагай намерений или контекст, которого нет в документе
— если что-то неоднозначно — прямо укажи это
Финал: {список / таблица / краткий вывод} с цитатами.
{текст}
Что подставлять:
- {роль} — юрист, редактор, ревизор, технический аналитик
- {тип документа} — договор, техзадание, питч, статья, инструкция
- {узкая категория} — конкретный тип проблемы: условия оплаты, фактические ошибки, риски субподряда, логические противоречия
- {формат вывода} — список с цитатами удобнее всего для сравнения между запусками
🚀 Быстрый старт — вставь в чат:
Вот шаблон для точного анализа документов. Адаптируй под мою задачу: {опиши задачу}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про тип документа и конкретную категорию проблем — потому что узкая фокусировка и есть суть метода. Она возьмёт паттерн из шаблона и настроит под твою задачу.
Ограничения
⚠️ Поверхностно «безопасное» — слепое пятно: LLM делает вывод по паттернам, а не по цепочке следствий. Если документ или код выглядит корректно на поверхности — модель скорее всего пропустит скрытую проблему внутри. В исследовании ни одна модель за 90 попыток не нашла уязвимость, спрятанную за «безопасным» на вид кодом.
⚠️ Один запуск ненадёжен: Даже лучшая модель меняет ответы при повторах. Для важных задач — минимум 2–3 запуска.
⚠️ Широкий промпт = много мусора: Без сужения модели выдают в разы больше ложных находок. Чем шире запрос — тем выше процент галлюцинаций.
⚠️ Потолок точности невысок: Даже лучшие модели с лучшими промптами пропускают треть и больше реальных проблем. Не полагайся только на LLM для критичного анализа.
Как исследовали
Команда из TU Berlin и Freie Universität Berlin взяла 4 реальных WordPress-плагина с официально задокументированными уязвимостями — SQL-инъекция, XSS, путевой обход, удалённое выполнение кода. Прогнала через них 6 топовых моделей (Claude, GPT-5, Gemini, MiniMax, два Qwen) с 5 разными промптами — каждую комбинацию три раза. Итого: 360 отчётов и 1600+ находок. Два автора вручную проверяли каждый отчёт.
Дизайн промптов был намеренно ступенчатым: «ленивый» (буквально «найди уязвимость»), два «общих» (с ролью и задачей — простой и с CoT), два «конкретных» (те же, но с указанием типа уязвимости). Разница между простым конкретным и сложным CoT-общим — в пользу простого конкретного. Это прямо противоречит интуиции: казалось бы, детальный Chain-of-Thought должен побеждать. Нет — что искать важнее, чем как думать.
Самый показательный результат: ни одна из 6 моделей ни разу за 90 попыток не нашла уязвимость в плагине Responsive Lightbox. Там был XSS, спрятанный за regex-манипуляцией над уже экранированным входом — все модели видели esc_attr() и решали «вход защищён, XSS невозможен». Никто не проследил, что regex дальше ломает эту защиту. Вывод: LLM останавливается на первом «безопасном» сигнале и не идёт дальше по цепочке.
Адаптации и экстраполяции
🔧 Техника: повторный запуск + консолидация → фильтрация надёжных находок
Прогони один и тот же промпт трижды. Потом попроси LLM сравнить и отфильтровать:
Вот три версии анализа одного и того же документа.
Выдели только те находки, которые присутствуют минимум в двух из трёх версий.
Остальное отметь как «требует ручной проверки».
Версия 1: [ответ первого запуска]
Версия 2: [ответ второго запуска]
Версия 3: [ответ третьего запуска]
Это превращает случайность модели в сигнал надёжности: стабильные находки = высокая уверенность, разовые = перепроверь вручную. Принцип работает за пределами анализа кода — для проверки договоров, фактчекинга, поиска логических дыр в аргументации.
Ресурсы
Evaluating LLMs for Real-World Web Vulnerability Detection Sebastian Neef, Luca Jungnickel, Antonio Benjamin Buchholz, Valene Spence, Vicente Birke Gonzalez Technische Universität Berlin / Freie Universität Berlin WPScan vulnerability database: wpscan.com — публичная база 70 000+ уязвимостей WordPress