TL;DR
Когда просишь LLM найти проблемы в тексте — техзадании, договоре, плане, требованиях — модель обнаружит в среднем меньше половины реальных проблем. Зато она почти никогда не паникует и не находит проблемы там, где их нет: ложных тревог всего около 11%. Это asymmetric error profile (перекошенный профиль ошибок) — модель ведёт себя как чересчур доверчивый редактор, который скорее пропустит ошибку, чем придумает несуществующую.
Хуже всего LLM справляется там, где нужно не просто прочитать текст, а прикинуть, соответствует ли он реальности. Например: "а нужен ли этот пункт вообще?" или "а точно ли это утверждение верное по факту?" Такие смысловые проверки модель почти всегда пропускает — она ловит опечатки, двусмысленные формулировки, повторы, но не "залезает под капот" содержания.
Дополнительная неприятность: новая версия модели не гарантирует улучшения этого паттерна. GPT-5 не обязательно лучше проверяет требования, чем GPT-4 — прогресс тут не линейный. И температура (степень случайности ответа) почти не влияет на этот паттерн ошибок — значит, дело не в "рулетке", а в системной слабости самой модели.
Схема паттерна ошибок
ЗАПРОС: "Проверь текст на соответствие критериям качества"
ЧТО МОДЕЛЬ ЛОВИТ ХОРОШО:
→ Двусмысленные формулировки
→ Нарушение формата/стиля
→ Явные противоречия в тексте
ЧТО МОДЕЛЬ ПРОПУСКАЕТ:
→ "А нужен ли этот пункт вообще?" (необходимость)
→ "А это точно соответствует фактам?" (корректность)
→ Смысловые пробелы, которые не видны без контекста
РЕЗУЛЬТАТ: мало ложных тревог, но много пропущенных реальных проблем
Пример применения
Задача: Ты — руководитель проекта, готовишь техзадание для подрядчика (дизайн-студии, разработчика, агентства) и просишь ChatGPT проверить его перед отправкой.
Промпт (наивный, который НЕ спасёт от слепых зон):
Проверь это техническое задание на ошибки и неточности:
[текст ТЗ]
Что произойдёт: модель поправит формулировки, найдёт повторы, может придраться к структуре. Но с высокой вероятностью пропустит то, что какой-то пункт вообще не нужен проекту, или что описанное решение технически не соответствует заявленной цели. Именно эти вещи требуют не анализа текста, а понимания предметной области — а это и есть слабое место LLM.
Промпт (с учётом слабости):
Проверь это техническое задание по трём отдельным вопросам,
по очереди, не смешивая их:
1. Формулировки: есть ли двусмысленные, непонятные или
противоречивые пункты?
2. Необходимость: для каждого пункта ответь — а точно ли
он нужен для цели проекта, описанной здесь: [цель проекта]?
Отметь пункты, которые кажутся лишними или неочевидными.
3. Соответствие фактам: сверь пункты с реальными
ограничениями проекта: [бюджет, сроки, технические рамки].
Есть ли пункты, которые физически/технически невыполнимы
или противоречат этим рамкам?
Текст ТЗ:
[текст]
Результат: модель пройдёт по трём блокам отдельно. По формулировкам — сработает хорошо, как обычно. По необходимости и соответствию фактам — результат будет менее полным, но сам факт, что ты явно попросил проверить именно эти пункты, повышает шанс, что модель хоть что-то заметит там, где иначе пропустила бы всё.
Почему это работает
LLM генерирует текст на основе паттернов языка, а не проводит инженерную экспертизу. Она отлично видит поверхностные сигналы проблемы — странную формулировку, повтор, разрыв логики внутри одного предложения. Но чтобы понять "а нужен ли этот пункт" или "а правда ли это", модели нужно сопоставить утверждение с внешним контекстом — с целью проекта, с законами физики, с реальными ограничениями. Это требует не чтения, а рассуждения о мире за пределами текста — а именно тут модель слабее всего.
Заодно у модели есть встроенная склонность к "согласию" — она обучена не выдумывать проблем, которых нет, чтобы не выглядеть придирчивой или неточной. Отсюда низкий процент ложных тревог: модель скорее промолчит, чем ошибочно раскритикует нормальный пункт.
Рычаг управления: если явно разделить проверку на "формулировки" отдельно от "необходимость и соответствие фактам" — ты заставляешь модель потратить внимание именно на слабые зоны, а не проскочить их мимоходом в общей проверке "найди все проблемы".
Шаблон промпта
Проверь {документ} по трём отдельным блокам, не смешивая их:
БЛОК 1 — Формулировки:
Есть ли двусмысленные, непонятные, избыточные или
противоречивые формулировки?
БЛОК 2 — Необходимость каждого пункта:
Цель документа: {цель}.
Для каждого пункта ответь: точно ли он нужен для этой цели?
Отметь пункты, которые кажутся лишними, дублирующими или
не связанными с целью.
БЛОК 3 — Соответствие реальным ограничениям:
Реальные рамки: {бюджет / сроки / технические ограничения / факты}.
Есть ли пункты, которые противоречат этим рамкам или технически
не выполнимы?
Документ:
{текст}
Подставь: {документ} — что проверяешь (ТЗ, договор, план, бриф), {цель} — зачем этот документ существует, {бюджет/сроки/ограничения} — реальные рамки проекта, {текст} — сам документ.
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки документа по трём блокам. Адаптируй под мою задачу:
{твоя задача}. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про цель документа и реальные ограничения проекта — потому что именно контекст, а не сам текст, помогает ей заметить смысловые проблемы, которые она иначе пропустит.
Ограничения
⚠️ Не жди полноты: даже с разбивкой на блоки модель всё равно пропустит значительную часть смысловых проблем. Это снижает риск, но не устраняет его — финальную проверку по смыслу и фактам должен сделать человек.
⚠️ Не складывай проверки в цепочку агентов без человека: если один LLM-агент проверяет текст, а второй агент принимает решение на основе его вывода — пропущенная проблема первого агента "утечёт" дальше и её никто не поймает. Автоматизация проверки требований несколькими AI-агентами подряд рискует не исправить слабость, а размножить её.
⚠️ Новее не значит лучше: не выбирай модель просто по номеру версии, ожидая, что она автоматически лучше ловит проблемы — прогресс здесь непредсказуемый.
Как исследовали
Исследователи взяли два набора требований к инженерным системам: один — от опытных разработчиков (заявка на конкурс NASA по роботу-манипулятору), другой — от студентов без инженерной подготовки (учебное упражнение с системой выдачи книг). Три эксперта вручную разметили каждое требование по девяти критериям качества из стандарта INCOSE — получилась "эталонная истина".
Дальше десять моделей (пять поколений OpenAI и пять поколений Anthropic) прогнали через сто независимых попыток оценки каждого требования, при пяти разных уровнях температуры (степени случайности ответа). Это позволило не просто посмотреть на один ответ модели, а увидеть разброс её ошибок при повторных попытках.
Результат подтвердил не случайность, а системность: лучшая модель Anthropic находила медианно только 47% реальных проблем, при этом ложно отмечая лишь 11% нормальных пунктов как проблемные. Особенно плохо давались критерии "необходимость" и "корректность" — именно те, что требуют инженерного суждения, а не анализа текста. И что удивило исследователей — смена температуры почти не меняла картину, а смена поколения модели иногда даже ухудшала результат. Это и привело к главному выводу: слабость системная, не случайная, и лечится она только человеком в контуре проверки, не более новой моделью.
Ресурсы
Two Truths and A Lie? Benchmarking off-the-shelf LLMs for Requirements Quality Assessment — Performance, False Alarms, and Misses Jannatul Shefa, Taylan G. Topcu (Virginia Tech); Alejandro Salado, Paul Wach (University of Arizona) Стандарт качества требований: INCOSE Systems Engineering Handbook (2023)