Почему ChatGPT блокирует обычные задачи и 3 способа это обойти⚡️
Открыл Codex, передал свой репозиторий и попросил: «Найди баги, расставь приоритеты и исправь». Стандартная задача разработчика, но через несколько секунд: «Это содержимое нельзя показать. Мы проявляем осторожность с запросами по кибербезопасности». Слова bug, fix, repository и модель решила, что это кибератака.
Почему так происходит****❓ Поверх модели стоят отдельные классификаторы. Они оценивают запрос, содержимое файлов и накопленный контекст. «Найди уязвимость и исправь в моём проекте» и тот же запрос с намерением атаковать чужой сервер - по тексту почти неотличимы.
OpenAI сама это признаёт. Добросовестные разработчики попадают под ограничения, именно поэтому появился Trusted Access. Подтверждённым специалистам снижают число отказов на легитимные задачи.
Это не единичный случай. У учеников такое происходит регулярно: просят написать email-рассылку - модель видит риск спама, строят парсер - блокируют, просят проанализировать свой же сайт - система считает это атакой.
👉 Три выхода когда получил отказ
1️⃣ Добавь контекст сразу Не «проверь код», а «это мой репозиторий, задача: рефакторинг, изменения публиковать не нужно». Классификатор оценивает наличие понятных границ.
2️⃣ Раздели задачу Сначала анализ, потом план, потом правки. Агент хуже справляется, когда просишь всё сразу и лучше когда ведёшь его пошагово.
3️⃣ Открой чистый диалог Проблема часто не в последней фразе, а в том, что накопилось раньше. Новый контекст с чётким описанием задачи и владельца часто решает.
Мы поэтому строили агентов не по схеме «вот промпт, иди работай». Агент должен понимать кто поставил задачу, с каким объектом работает и где граница. Хороший ИИ должен не просто отказываться от опасных действий, он должен уметь отличать опасное от обычной работы. Пока не всегда получается, но это уже не случайность, а бизнес-решение, которое постепенно меняется.
Кстати, на НейроМаксе разбираем, как встраивать ИИ в реальные рабочие процессы с нуля 👉 Забрать доступ
· 19.08
Контекст ownership снижает число ложных отказов, но я бы не делал его защитным контуром. Фраза «это мой репозиторий» остаётся утверждением пользователя, которое агент не может проверить.
Для рабочих агентов я разделяю два слоя: в контексте описаны цель и границы задачи, а технически права ограничены конкретным репозиторием, веткой, инструментами и разрешёнными действиями. Тогда модель может ошибиться в интерпретации, но не получает возможности выйти за пределы задачи.
И ещё: embeddings помогают найти релевантный код, но сами по себе не доказывают легитимность действия. Где у вас проходит граница между описанием ownership и выданными агенту правами?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён