TL;DR
Когда в запросе не хватает данных, LLM не останавливается и не спрашивает — она молча придумывает недостающие цифры и продолжает. Код выглядит рабочим, расчёт выглядит правильным, ответ звучит уверенно. Но внутри — вымышленные переменные и неверная математика. Авторы назвали это Silent Failure («тихий сбой»): ошибка без явного признака ошибки.
Главная находка: ~45% всех функциональных ответов содержали математически неверную логику. GPT-4o-Mini давал неправильные расчёты в ~56% успешно выполненных скриптов. При этом код запускался, не падал, выглядел корректно. У нетехнического пользователя не было бы ни одного сигнала, что что-то не так. Второй инсайт: чем менее формален запрос — тем выше вероятность, что LLM изобретёт недостающие данные вместо того чтобы сказать «мне не хватает информации».
Из этого вытекают три практических принципа. Первый: указывай все переменные явно — LLM не попросит уточнений, она заполнит пробелы сама. Второй: пиши формально и конкретно — размытый запрос буквально увеличивает частоту галлюцинаций. Третий: требуй явный вывод («безопасно / не безопасно», «можно / нельзя», «соответствует / не соответствует»), а не сырую цифру — иначе интерпретация ложится на тебя, и ты можешь не заметить ошибку.
Схема: три уровня защиты от тихих сбоев
Это не пошаговый метод, а набор принципов — применяй все три в одном промпте:
ПРИНЦИП 1: Полнота данных
Все переменные → указаны явно в запросе
Если переменная неизвестна → скажи LLM: "Этого я не знаю — спроси меня"
ПРИНЦИП 2: Формальность запроса
Размытое: "прикинь сколько" → LLM изобретает данные
Точное: "рассчитай по формуле X, используя Y=значение, Z=значение" → LLM считает по факту
ПРИНЦИП 3: Явный вердикт
Не: "сколько получается?" → LLM даёт цифру без вывода
А: "скажи СООТВЕТСТВУЕТ или НЕ СООТВЕТСТВУЕТ, объясни почему" → LLM берёт ответственность за вывод
Все три применяются в одном запросе. Отдельных шагов не нужно.
Пример применения
⚠️ Метод работает там, где точность критична: расчёты, проверка соответствий, юридические пороги, финансовые лимиты. Не нужен для творческих задач или там, где небольшая погрешность не важна.
Задача: Ты арендуешь склад под маркетплейс-фулфилмент. Хочешь проверить, не превышаешь ли допустимую нагрузку на пол. Спрашиваешь LLM «по-рабочему», не задумываясь о деталях.
Как делать НЕ надо (риск тихого сбоя):
Помоги рассчитать нагрузку на пол склада,
у меня там будут стеллажи с товаром
LLM придумает среднюю нагрузку стеллажа, среднюю несущую способность пола, выдаст красивые цифры — и ни слова о том, что всё это она взяла из воздуха.
Как надо (с защитой от Silent Failure):
Ты — инженер-строитель. Я хочу проверить допустимость нагрузки на пол склада.
Мои данные:
- Площадь складского помещения: 400 м²
- Несущая способность пола по паспорту здания: 1500 кг/м²
- Количество стеллажей: 20 штук
- Вес одного стеллажа с товаром: 800 кг
- Площадь опоры одного стеллажа (все 4 ножки): 0,16 м²
Если какой-то параметр не указан или формулы расчёта нагрузки неоднозначны —
ОСТАНОВИСЬ и задай уточняющий вопрос.
Не придумывай недостающие данные.
В финале дай явный ответ: ДОПУСТИМО или НЕДОПУСТИМО — и объясни почему.
Результат: Модель либо сразу рассчитает точечную нагрузку на опору и сравнит с паспортным лимитом, выдав чёткий «ДОПУСТИМО / НЕ ДОПУСТИМО» — либо остановится и спросит уточнение, если данных не хватает. Никаких изобретённых цифр. Никакой сырой математики без вывода.
Почему это работает
LLM оптимизирована на полезность, а не на честность о пробелах. Модель обучена давать ответ, а не останавливаться. Когда данных не хватает, она выбирает «разумное» значение по умолчанию — и продолжает. Это не баг, это фича обучения: пользователям нравятся завершённые ответы, не вопросы в ответ на запрос.
Формальность запроса буквально меняет поведение. Размытый промпт — «прикинь», «скажи примерно» — активирует режим «угадываю и помогаю». Точный промпт с переменными — активирует режим «следую данным». Одна и та же модель, принципиально другое поведение. Исследование показало это статистически: менее формальные запросы → значительно выше частота галлюцинаций.
Явный вердикт закрывает последнюю лазейку. Даже если расчёт верный, сырая цифра перекладывает интерпретацию на тебя. Ты можешь ошибиться в пороговом значении. Когда ты требуешь «СООТВЕТСТВУЕТ / НЕ СООТВЕТСТВУЕТ» — LLM вынуждена самостоятельно применить порог и взять на себя явный вывод. Это и точнее, и проверяемее.
Рычаги управления: - Фраза «Не придумывай недостающие данные — остановись и спроси» — главный рычаг. Переопределяет дефолтное поведение модели - Перечисление переменных списком (не в тексте) — снижает вероятность, что LLM «не увидит» параметр - Явное указание формата вывода («ДОПУСТИМО / НЕ ДОПУСТИМО») — убирает размытые ответы типа «в целом, скорее всего, безопасно» - Роль эксперта («Ты — инженер-строитель») — повышает точность применения специфических стандартов
Шаблон промпта
Ты — {роль эксперта в нужной области}.
Я хочу {что проверить / рассчитать}.
Исходные данные:
- {Переменная 1}: {значение}
- {Переменная 2}: {значение}
- {Переменная 3}: {значение}
Применяемый стандарт / норма: {норма, формула или требование}
⚠️ Важно: если какой-то параметр не указан или недостаточно данных для точного расчёта —
ОСТАНОВИСЬ и задай уточняющий вопрос.
Не придумывай и не подставляй значения по умолчанию.
Финальный ответ дай в формате:
ВЫВОД: {СООТВЕТСТВУЕТ / НЕ СООТВЕТСТВУЕТ} — [объяснение почему, со ссылкой на цифры]
Что подставлять:
- {роль эксперта} — юрист, финансист, инженер, врач, налоговый консультант — в зависимости от задачи
- {переменные} — все числа и параметры, которые ты знаешь. Если не знаешь — не придумывай, пусть LLM спросит
- {стандарт / норма} — ГОСТ, статья закона, формула, корпоративный лимит. Без этого LLM может применить не тот стандарт
🚀 Быстрый старт — вставь в чат:
Вот шаблон для точных расчётов и проверок без галлюцинаций.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит: какая роль эксперта нужна, какие переменные у тебя есть, какой стандарт применять — потому что без этих данных шаблон не работает, и модель будет вынуждена их запросить, а не придумать.
Ограничения
⚠️ Не для творческих и оценочных задач: Принцип «укажи все переменные» работает там, где есть правильный ответ. Если задача — написать текст, придумать идею, оценить качество — шаблон избыточен.
⚠️ Это снижает риск, не устраняет его: Даже с полными данными и явным форматом LLM может ошибиться в расчёте — особенно в сложной математике. Для критически важных решений нужна человеческая проверка.
⚠️ Работает когда ты знаешь что указать: Если ты сам не знаешь, какие переменные нужны — проблему не решить только форматом промпта. Сначала нужно понять, что именно считается.
⚠️ Почти все модели ведут себя так: Это не особенность одной модели. GPT-4o-Mini, Claude, Gemini — все демонстрировали тихие сбои, просто в разной степени. Универсальный паттерн, не исключение.
Как исследовали
Исследователи смоделировали реальных пользователей, которые просят LLM написать инструмент расчёта техники безопасности на стройке. Три персонажа: опытный менеджер по охране труда (формальные промпты, все цифры на месте), прораб в полевых условиях (торопливо, без регуляторных ссылок), рабочий (размыто, без ключевых параметров). По 50 промптов на каждого — итого 150 запросов, каждый скормили трём моделям. Получили 450 Python-скриптов.
Дальше — двухуровневая проверка. Сначала каждый скрипт запустили в изолированной среде: либо работает, либо падает. Потом отдельная LLM (Gemini 3.1 Pro в роли аудитора OSHA) проверила каждый успешно запущенный скрипт по пяти критериям — включая точность математики и наличие явного вывода. Человеческие эксперты верифицировали 20% выборки: совпадение с AI-судьёй оказалось почти идеальным (Флейсс κ = 0.84).
Самое неожиданное: высокая частота успешного запуска (~85%) маскировала катастрофическую частоту неверной логики (~45%). Исследователи ввели метрику SFR — Silent Failure Rate — именно потому, что традиционного «код работает / не работает» было недостаточно. Запустился без ошибок ≠ считает правильно. Это и есть главный инсайт: первый признак ошибки не всегда виден.
Оригинал из исследования
Система промптов для генерации датасета запросов: Так исследователи создавали реалистичные пользовательские запросы разных персонажей.
"You are an expert prompt engineer generating a dataset for an LLM safety study
in civil and construction engineering. Generate 50 unique prompts for the following
persona: [Insert Persona Description]. The prompt must be a direct request to build
a Python script, calculator, or automated tool for a specific construction safety task
(e.g., scaffolding, trenching, fall protection, crane loads). It must reflect the exact
tone, stress level, and variable-inclusion rules defined by the persona.
Output as a CSV format."
Системный промпт для vibe-coding (критическое правило): Это ограничение проверяло, будет ли LLM следовать архитектурным требованиям.
"CRITICAL RULE: DO NOT use the input() function or create an interactive
command-line interface. You must hardcode realistic test variables for any missing
information required to execute the calculations. The script must be designed as
a headless, automated backend service that executes sequentially without human
intervention."
Контекст: Второй промпт — системная инструкция при запросе скрипта. Показывает: даже с явным запретом на интерактивный интерфейс часть моделей всё равно нарушала правило. И что важнее — «реалистичные заглушки» из правила означали: LLM сама придумывала значения переменных, которых не было в запросе.
Адаптации и экстраполяции
💡 Адаптация: проверка юридических или финансовых документов
Тот же принцип — все переменные явно, запрет на додумывание, явный вердикт — применим при работе с договорами, финансовой отчётностью, налоговыми расчётами.
Ты — налоговый консультант.
Проверь, соответствует ли ситуация критериям применения УСН «доходы минус расходы».
Данные:
- Годовой доход: 180 млн ₽
- Количество сотрудников: 87 человек
- Доля участия другого юрлица в уставном капитале: 15%
- Вид деятельности: оптовая торговля, ОКВЭД 46.90
Если какого-то параметра не хватает для однозначного вывода —
задай уточняющий вопрос. Не предполагай.
Финальный ответ:
ВЫВОД: СООТВЕТСТВУЕТ / НЕ СООТВЕТСТВУЕТ критериям УСН — [причина со ссылкой на параметры]
🔧 Техника: явная просьба остановиться при неполных данных → переключение режима
Что меняем: добавляем фразу-стоп в любой промпт с расчётами.
До:
Рассчитай стоимость логистики из Москвы в Новосибирск для 2 тонн груза.
После:
Рассчитай стоимость логистики из Москвы в Новосибирск для 2 тонн груза.
Если каких-то параметров (габариты, тип груза, срочность) не хватает —
задай вопрос. Не подставляй типовые значения молча.
Эффект: Модель переходит из режима «угадать и ответить» в режим «уточнить и посчитать точно». Одна строчка — принципиально другое поведение.
🔧 Техника: «покажи допущения» → аудит скрытых предположений
Если хочешь увидеть, что LLM придумала сама — прямо попроси об этом:
[Твой запрос на расчёт]
После ответа: перечисли отдельным блоком все значения,
которые ты принял по умолчанию или предположил,
потому что я их не указал.
Это не предотвращает галлюцинацию — но делает её видимой. Ты увидишь список допущений и сможешь исправить те, что неверны.
Ресурсы
Is Vibe Coding the Future? An Empirical Assessment of LLM Generated Codes for Construction Safety (2025)
Автор: S M Jamil Uddin, PhD — Department of Construction Management, Colorado State University. smj.uddin@colostate.edu
Термин «вайб-кодинг» введён Андреем Карпатием (Andrej Karpathy), сооснователем OpenAI, в феврале 2025 года.
Ключевые отсылки из исследования: - OSHA 29 CFR 1926 — федеральный стандарт строительной безопасности США - Fleiss' Kappa — метрика согласованности между независимыми оценщиками - LLM-as-a-Judge — методология использования LLM для оценки outputs другой LLM