Skip to main content
LLM-оценкаГаллюцинацииAI-архитектура

Bullshit-benchmark: как измерять “красивую” галлюцинацию LLM

На GitHub появился bullshit-benchmark — простой тест, который ловит не фактические ошибки, а “красиво звучащую бессмыслицу” в ответах LLM. Это критично для бизнеса: такие галлюцинации незаметно портят аналитику, регламенты и автоматизацию, создавая огромный риск принятия ошибочных решений на совершенно выдуманных основаниях.

Технический контекст

Я посмотрел на репозиторий petergpt/bullshit-benchmark и мне понравилась сама постановка задачи: тестировать не «неправильный факт», а склонность модели уверенно продолжать разговор, когда запрос содержит внутреннюю бессмыслицу. Это другой класс риска, чем типичные hallucination-бенчмарки для RAG, где можно сверить ответ с источником.

Механика понятная: в датасете есть вопрос и явно отмеченный «нелепый элемент» (например, “эластичность соотношения сторон оргчарта”). По сути, модель должна сделать одно из двух: либо прямо сказать, что часть запроса некорректна и запросить уточнение, либо аккуратно переформулировать задачу в осмысленный вид. Провал — когда модель начинает строить псевдо-аналитику на несуществующих сущностях.

Мне отдельно импонирует, что такой тест невозможно «выиграть» одной лишь эрудицией. Тут проверяется дисциплина ответа: умение остановиться, признать неопределённость и не генерировать убедительный мусор.

В исходных данных, которые мне дали, есть утверждение, что Gemini 3 Flash на этом тесте «показательно фейлится», а Anthropic и Qwen выглядят лучше. Я не могу подтвердить это цифрами без воспроизводимого прогона и зафиксированных логов, но как инженер по AI-архитектуре я вижу, почему такая разница вообще возможна: разные политики отказа, разные настройки safety/quality, разные штрафы за «смелые» утверждения.

Влияние на бизнес и автоматизацию

Для бизнеса «красиво звучащая бессмыслица» опаснее обычной ошибки факта. Факт можно поймать верификацией или RAG-цитатами, а вот бессмысленный фрейм запроса может пройти в документ, презентацию, техзадание и запустить цепочку дорогих решений.

В проектах по внедрению ИИ я чаще вижу эту проблему не в чатах, а в автоматизированных пайплайнах: генерация KPI-дерева, нормализация требований, авто-описание процессов, классификация обращений. Если модель не умеет «останавливаться», она будет уверенно придумывать определения, метрики и причинно-следственные связи — и ваша ИИ автоматизация начнёт масштабировать ошибку.

Кто выигрывает от подобных бенчмарков? Команды, которые строят LLM как компонент системы, а не как «говорящую голову». Проигрывают те, кто выбирает модель только по цене токена и скорости, а затем удивляется, почему отчёты «умные», но неоперациональные.

В моём подходе в Nahornyi AI Lab это напрямую влияет на архитектурные решения: я закладываю обязательный слой “nonsense detection” до критических действий, политика отказа/эскалации и тестовый контур с такими вопросами в CI. Модель — не источник истины; она компонент, который должен уметь сказать «нет».

Стратегическое видение и глубокий разбор

Мой прогноз: в 2026 году рынок начнёт разделять «LLM для генерации» и «LLM для управления процессом». Вторые будут выигрывать не от максимальной разговорчивости, а от предсказуемости: корректно задавать уточняющие вопросы, маркировать невалидные предпосылки, избегать ложной строгости.

Я уже видел паттерн: чем ближе модель к операционным решениям (планирование закупок, маршрутизация заявок, комплаенс-ответы), тем дороже обходится не галлюцинация факта, а галлюцинация структуры. Нелепая сущность в вопросе порождает нелепую таблицу, затем нелепой дашборд, потом — реальные действия людей.

Поэтому в архитектуре ИИ-решений, которую я проектирую, я не ограничиваюсь «выбором модели». Я проектирую контуры контроля: (1) валидатор входных предпосылок, (2) ограничение стиля ответа (короче, меньше «воды»), (3) проверки на самосогласованность и повторный запрос к пользователю при обнаружении бессмыслицы, (4) наблюдаемость — логирование причин отказа и классов ошибок.

Если вы сейчас сравниваете модели для внедрения, я бы добавил bullshit-benchmark (или аналогичный набор) в ваш shortlist-тест. Это дешёвый способ заранее увидеть, как поведёт себя агент в ситуации, где большинство промптов в реальном бизнесе и живёт: в полуформальных, противоречивых и плохо определённых запросах.

Что я предлагаю сделать в вашей компании

Этот разбор подготовил Вадим Нагорный — ведущий практик Nahornyi AI Lab по AI-автоматизации и построению AI-архитектуры в реальном секторе. Я не продаю “чат-ботов ради чат-ботов”: я собираю системы, которые измеримо снижают риск и стоимость ошибок.

Если вы планируете внедрение LLM в процессы (служба поддержки, продажи, аналитика, документооборот, планирование), напишите мне в Nahornyi AI Lab. Я проведу быстрый аудит сценариев, соберу тестовый контур (включая анти-бессмыслицу) и предложу архитектуру внедрения с понятными SLA, метриками качества и контуром контроля.

Share this article