Робот получает команду «принеси стакан воды». С точки зрения языковой модели, запрос полностью безопасен — никаких запрещённых слов, никакого вредоносного контента. Но в физическом мире это может означать: перехватить стакан у ребёнка, пройти через хрупкую конструкцию, или переместить объект, который удерживает что-то другое. Текст безопасен. Действие — нет.

Именно эту проблему исследует новая работа «When Words Are Safe But Actions Kill», представленная 16 июля 2026 года. Исследователи показали, что языковые модели обрабатывают физическую опасность как отдельный класс рисков, не сводимый к обычной text-level безопасности.

Что такое physical danger в LLM?

Большинство современных подходов к безопасности LLM фокусируются на content danger (CD) — предотвращении генерации вредоносного текста: инструкций по созданию оружия, токсичных высказываний, дезинформации. Эти методы хорошо работают: модели проходят red-teaming, проходят бенчмарки, получают сертификаты безопасности.

Но когда LLM становится планировщиком для робота или автономной системы, возникает новый класс рисков. Physical danger (PD) — это ситуации, когда лингвистически безобидная инструкция приводит к опасным действиям в физическом мире. Команда «открой дверь» безопасна в чате, но может означать «войди в горящее здание» для робота-спасателя.

Ключевой вопрос исследования: это та же самая проблема безопасности, только в другой домене, или качественно новая задача?

Методология: как обнаруживают невидимые риски

Чтобы понять, почему это открытие важно, нужно разобраться в методологии. Традиционный safety-анализ смотрит на выходные токены: модель генерирует текст, фильтры проверяют его на токсичность, вредоносность, предвзятость. Это работает для текстовых рисков, потому что опасность проявляется в самом тексте.

Но физическая опасность — это не свойство текста. Это свойство взаимодействия между текстом и физическим миром. Команда «включи нагреватель» безопасна в чате, но может означать «перегрей реактор» в химической лаборатории. Чтобы обнаружить эту опасность, нужно анализировать не выход модели, а её внутренние представления.

Hidden-state direction analysis работает так: исследователи берут pairs инструкций — семантически похожих, но различающихся по типу опасности. Например, «объясни, как работает взрывчатка» (CD) и «взорви эту стену» (PD). Оба запроса связаны с опасностью, но первый — текстовый риск, второй — физический. Затем они прогоняют оба запроса через модель и анализируют векторные представления в промежуточных слоях.

Результат: направления активаций для CD и PD формируют отдельные кластеры в пространстве скрытых состояний. Это означает, что модель «понимает» разницу между текстовой и физической опасностью на уровне механизмов, даже если на уровне выхода оба запроса могут быть отклонены одинаково.

Random-split null tests использовались для проверки статистической значимости. Исследователи случайным образом перемешивали метки CD/PD и проверяли, сохраняется ли разделение. Результат: при случайной разметке разделение исчезало, что подтверждает — эффект реальный, а не артефакт выборки.

Почему это важно для embodied AI

Представьте автономного робота-курьера. Он получает команду «оставь посылку у двери». Текст безопасен. Но если дверь принадлежит клинике, «оставить у двери» может означать «положить на землю перед входом в реанимацию». Языковая модель, обученная избегать токсичного контента, не видит здесь проблемы — потому что проблема не в тексте.

Это означает, что традиционные методы safety alignment (RLHF, DPO, constitutional AI) недостаточны для embodied AI. Эти методы оптимизированы для текстового вывода. Они могут сделать модель менее токсичной в чате, но не научат её понимать физический контекст действий.

Исследователи подчёркивают: разделимость сигналов означает, что нужны отдельные механизмы обнаружения и смягчения. Нельзя просто добавить больше примеров физических опасностей в training data и надеяться, что модель обобщит. Нужны архитектурные решения или отдельные модули безопасности.

Практические последствия для разработчиков

Если вы работаете с LLM в контексте, где модель принимает решения, влияющие на физический мир, это исследование даёт несколько практических выводов.

Первое: стандартные safety-бенчмарки (ToxiGen, TruthfulQA, BBQ) не измеряют физическую безопасность. Модель может проходить все текстовые тесты и при этом быть опасной в embodied-сценариях. Нужны отдельные бенчмарки, тестирующие PD.

Второе: RLHF-обучение на текстовых данных не переносится автоматически на физическую безопасность. Если вы fine-tune'ите модель для робототехники, автономных транспортных средств или промышленных систем, вам нужны датасеты с явной разметкой физических рисков.

Третье: мониторинг выходных токенов недостаточен. Традиционный safety-filter смотрит на текст и блокирует «плохие» слова. Но если инструкция безопасна лингвистически, фильтр пропустит её — даже если действие опасно физически. Нужен анализ скрытых состояний или отдельные планировщики с физическим моделированием.

Связь с другими направлениями безопасности

Это исследование перекликается с несколькими активными направлениями в AI safety.

Interpretability research (Anthropic, DeepMind) показывает, что модели кодируют концепции в виде направлений в пространстве активаций. Работа «When Words Are Safe» подтверждает: разные классы рисков действительно имеют разные нейронные подписи. Это открывает возможность создавать специализированные детекторы для каждого класса.

Mechanistic safety — направление, изучающее, как модели принимают решения на уровне механизмов (а не только на уровне выходов). Разделимость CD и PD сигналов поддерживает гипотезу, что safety — это не одно свойство, а набор независимых механизмов.

Embodied AI safety — растущая область на стыке робототехники и AI safety. Пока большинство работ фокусируется на формальной верификации (доказать, что робот не столкнётся с объектом), это исследование показывает: проблема глубже. Даже на уровне планирования, до исполнения, модель может не видеть физического риска.

Конкретные сценарии физических опасностей. Чтобы понять масштаб проблемы, рассмотрим несколько реальных сценариев, где текстовая безопасность не помогает. Медицинский робот получает команду «удали опухоль». Текст безопасен, но если опухоль расположена рядом с критическим сосудом, действие может привести к кровотечению. Языковая модель, обученная на медицинских текстах, может не знать анатомических ограничений — она видит слова, а не физическую структуру.

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

Промышленный манипулятор получает команду «перемести деталь». Текст безопасен. Но если деталь удерживает другой компонент под напряжением, действие может привести к короткому замыканию. Текстовый safety-filter пропустит команду — потому что в ней нет запрещённых слов.

Эти примеры показывают: physical danger — это не редкая edge case. Это системная проблема, возникающая каждый раз, когда языковая модель становится планировщиком для физического мира. Проблема не в том, что модель генерирует опасный текст. Проблема в том, что она не понимает физический контекст действий, которые планирует.

FAQ: физическая безопасность LLM

Вопрос: Разве RLHF не должен автоматически научить модель избегать физических опасностей?

Нет, RLHF оптимизирован для текстовых предпочтений. Аннотаторы оценивают выходные токены модели — toxicity, helpfulness, truthfulness. Они не оценивают физическую безопасность планируемых действий, потому что в текстовом диалоге физических действий нет. Модель может быть идеально безопасной в чате и при этом не понимать, что «открой клапан» в контексте химического реактора — это физический риск.

Вопрос: Почему нельзя просто добавить больше примеров физических опасностей в training data?

Потому что разделимость сигналов в скрытых состояниях означает: модель уже «видит» разницу между CD и PD на уровне механизмов. Проблема не в недостатке данных — проблема в том, что механизмы обработки физических рисков не связаны с механизмами генерации действий. Добавление данных не создаст эту связь. Нужны архитектурные решения: отдельные модули безопасности, физическое моделирование, или гибридные подходы, где LLM планирует, а отдельная система проверяет физическую корректность.

Вопрос: Как это влияет на коммерческие продукты — роботов-курьеров, умные дома, автономные автомобили?

Если вы интегрируете LLM как планировщик в физическую систему, стандартные safety-сертификаты не покрывают физические риски. Вам нужен отдельный слой проверки: либо внешний модуль, анализирующий скрытые состояния модели, либо физический симулятор, проверяющий предлагаемые действия перед исполнением. Это не просто best practice — это необходимое условие для безопасного развёртывания.

Почему это исследование появляется именно сейчас

Рост embodied AI в 2025–2026 годах — не случайность. Физические LLM-агенты перестали быть исследовательской концепцией и становятся коммерческими продуктами: роботы-курьеры, автономные транспортные средства, умные дома с голосовым управлением, промышленные манипуляторы с языковым интерфейсом. Каждая из этих систем принимает решения, влияющие на физический мир, на основе текстовых инструкций.

Но индустрия безопасности отстала. Большинство фреймворков AI safety (NIST AI Risk Management Framework, EU AI Act) фокусируются на текстовых рисках: дезинформация, предвзятость, приватность. Физическая безопасность embodied AI остаётся в серой зоне — недостаточно урегулированной, недостаточно изученной, недостаточно понимаемой.

Исследование «When Words Are Safe» появляется в критический момент. Оно показывает: нельзя просто перенести существующие методы текстовой безопасности на физические системы. Нужны новые подходы, новые бенчмарки, новые архитектурные решения. И нужны они сейчас, пока embodied AI не масштабируется ещё больше.

Что дальше?

Исследование оставляет открытым несколько вопросов. Во-первых, насколько универсально разделение CD/PD для разных архитектур? Qwen2.5 — это трансформер с decoder-only архитектурой. Сохранится ли эффект для encoder-decoder моделей, Mamba, или мультимодальных архитектур?

Во-вторых, можно ли создать universal physical danger detector — модуль, который анализирует скрытые состояния и предсказывает PD-риск независимо от конкретной задачи? Или для каждого домена (медицина, строительство, транспорт) нужен свой детектор?

В-третьих, как интегрировать PD-обнаружение в planning loop? Если модель-планировщик генерирует действия, а отдельный модуль проверяет их на физическую безопасность, как избежать ложных срабатываний и при этом гарантировать надёжность?

Итог

Работа «When Words Are Safe But Actions Kill» показывает: безопасность LLM — это не монолит. Text-level safety и physical danger — это разные задачи с разными нейронными механизмами. Для embodied AI это означает, что недостаточно сделать модель «безопасной в чате» — нужны отдельные механизмы для понимания физического контекста.

Это не просто академическое наблюдение. Когда автономные системы начинают действовать в реальном мире, ставки меняются. Текст можно откатить. Физическое действие — нет.

Если вы работаете с LLM в робототехнике, автономных системах, или любых сценариях, где модель влияет на физический мир — не полагайтесь на текстовые safety-бенчмарки. Они измеряют не то, что вам нужно.