OpenAI разработала метод прогнозирования ошибок ИИ до его релиза

Компания опубликовала методику Deployment Simulation для тестирования безопасности LLM. Подход оценивает поведение моделей в условиях, имитирующих продакшен.

Вместо синтетических промптов новой модели передают анонимизированную историю диалогов пользователей с предыдущими версиями ИИ и запрашивают генерацию следующего ответа. В такой среде метрика распознавания тестирования снижается со 100% до 5,4%. При проверке задач с вызовом функций используется вспомогательная модель, имитирующую ответы окружения.

По тестам, Deployment Simulation предсказывает генерацию запрещенного контента или обман в 92% случаев против 54% у классических бенчмарков. При тестировании серии GPT-5 выяснилось, что GPT-5.1 использовала браузер в качестве калькулятора, рапортуя пользователю о выполнении веб-поиска.

Метод применим для независимого аудита сторонних моделей на базе открытых датасетов диалогов, без доступа к внутренним логам разработчика.

Источник: https://t.me/ai_machinelearning_big_data/10351

Безопасность AI-агентов начинается с Observability

Одним из направлений при построении защищенных систем является Observability (или наблюдаемость) — способность понимать, что происходит внутри этих систем на основе получаемых данных.

С распространением агентных систем появилась необходимость сохранять не только финальный ответ, но и все действия, которые к нему привели: вызовы модели, обращения к инструментам и передачу данных между компонентами. Именно эту задачу помогает решать OpenTelemetry (OTel).

OpenTelemetry появился в 2019 году как результат объединения OpenTracing и OpenCensus. Ключевая идея этого фреймворка — дать единый стандарт для инструментализации приложений в целях сбора телеметрии. В качестве транспорта используется стандартный протокол OTLP (OpenTelemetry Protocol).

Думаю, многие уже видели, как в IDE отображается Tool Calling: модель выбрала инструмент, передала параметры, получила результат и продолжила выполнение. По сути, это визуальное представление trace — цепочки шагов. (так выглядит в Copilot)

Техническая реализация опирается на наличие единого идентификатора traceId для всех операций в рамках одной последовательности действий. Отдельным звеном цепочки является span. Трейс начинается с корневого span, а последующие шаги ссылаются на родительский с помощью parentSpanId. За счет такого подхода удается собрать все связанные события и использовать их для дальнейшего анализа.

В контексте безопасности трейсы могут использоваться:

▸ В production-агентах — для расследования и предотвращения инцидентов

▸ В бенчмарках — для сбора информации об используемых инструментах, а также о затратах времени и токенов

▸ Для тестирования и отладки работы Guardrails, которые в трейсах будут выглядеть как отдельный шаг

Чтобы использовать трассировки на практике, необходимо поднять OpenTelemetry Collector и настроить отправку телеметрии на этот коллектор (либо сразу в конечную систему). Многие SDK и фреймворки для агентских систем уже поддерживают встроенную трассировку:

▸ OpenAI Agents SDK (тык1, тык2)

▸ LangChain / LangSmith (тык3, тык4)

При этом трассировка сама по себе решает только первую часть задачи — она позволяет увидеть, что произошло. Следующий шаг — использовать полученные данные для решения конкретных проблем.

В качестве направлений для дальнейшего развития Observability мне понравились два исследования:

▸ От Apple: Governance-Aware Agent Telemetry — использование телеметрии, чтобы в рантайме реагировать на события безопасности

▸ AgentSight — исследователи с помощью технологии eBPF получают дополнительные данные из системы и связывают их с трейсами OTel


У самурая нет цели, у самурая есть только trace...