Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 15
Что-то ваша архитектура не справилась с вычиткой
Вы бы свою модель еще и запятые правильно ставить научили. Кровь из глаз ведь.
«Мы попросили модель не выдумывать», не механизм. Про что это? Тут имеется в виду
"«Мы попросили модель не выдумывать» - это не механизм" или что-то другое?
Как закрыть: citations плюс механическая проверка
в итоге весь смысл статьи свелся к одной простой истине - перепроверять вручную, ибо даже из достоверной цитаты модель всегда может сформировать вывод-чушь. Пример - Perplexity, который подкрепляет сказанное ссылками на внешние источники, вот только источники иногда нерелевантные.
А еще расскажите пожалуйста, какое у вас образование? Упрощенно llm - это машина вероятностей (выбирает один из нескольких путей с определенной долей вероятности). Т.е. ваша архитектура каким-то образом должна абсолютно произвольные вероятности превращать в 100%. Даже без познаний математики думая чисто логически - как вы себе это представляете?
Образование мехмат МГУ, так что с вероятностями всё в порядке. И как раз поэтому скажу: никто не пытается превратить вероятность в единицу, задача другая.
Про Perplexity вы абсолютно правы, это отличный пример. Проверить, что цитата существует, и проверить, что вывод из неё корректен, это два разных контроля, и второй не автоматизируется.
Но часть проверок всё же чисто детерминированная, там вероятности нет вообще. Сравнить цитату с исходным текстом это сравнение строк. Ключ с правами read only не отменит подписку ни при каком настроении модели. А для оставшихся, действительно вероятностных ошибок обвязка ограничивает уже не вероятность, а масштаб: circuit breaker не делает агента умнее, он превращает «отменил все подписки» в «отменил три и остановился». Примерно как TCP поверх ненадёжного IP.
И маленькое уточнение: это не моя архитектура, а набор паттернов, которые рекомендует сам вендор. Ручная проверка один из них, но не единственный, и хорошая обвязка как раз сокращает объём того, что приходится перепроверять руками.
Спасибо за вдумчивый комментарий, такие вопросы полезнее похвалы.
НА все 100% согласен - «контроль должен жить в коде, а не в промпте». У меня в проекте весь код пишут агенты, и я на этом уже обжёгся. Что бы я ни писал в инструкциях — через час работы сессия про них благополучно забывает. А хук не забывает. Так что всё важное постепенно переехало из промптов в pre-commit и CI.
Кстати, ваш кейс с Deloitte у меня повторился один в один, только в CI. Гейты проверяли описание PR — на месте ли обязательные секции. А в шаблоне PR заголовки этих секций уже были. В итоге пустое описание, которое автор вообще не трогал, проходило четыре проверки разом. Всё зелёное — а не проверилось ничего. Теперь проверяю не «есть ли секция», а «писал ли её человек или она приехала из шаблона».
Статья про архитектуру с principle of least priviledge, и в ней ни слова про sandboxing, интересно.
разработчик Мэтт Шумер написал, что та же модель в агентном режиме случайно удалила почти все файлы на его Mac
Это самый главный кейс для sandboxing: мало ограничивать агентов, их нужно изолировать, чтобы они физически не могли ничего плохого сделать.
При tool use Claude не выполняет операции сам: он возвращает запрос на вызов, а вызывает ваш код. Именно здесь живут предохранители
Никаким описанным механизмам в Claude нельзя доверять, потому что правила для него хорошие написать задача нетривиальная, так еще правила агентами игнорируются и обходятся. Это очень легко ищется в поисковике по запросу “claude ignores permissions”, первый попавшийся пример: https://github.com/anthropics/claude-code/issues/26980
У Антропика вообще богатая история провалов в безопасности. Пример: https://adversa.ai/blog/critical-claude-code-vulnerability-deny-rules-silently-bypassed-because-security-checks-cost-too-many-tokens/
Опять же, Claude это или что угодно другое, агентов надо изолировать, чтобы они ничего плохого не могли сделать. Давать им внутри их песочницы можно только подготовленные для них инструменты, про которые десять раз проверили, что агенты ими ничего деструктивного не сделают. Им даже ключи давать нельзя, они должны пользоваться тулзами через шлюз, в котором скрыты ключи. Иначе будьте уверены, что агенты в какой-то момент отошлют эти ключи куда-нибудь.
Deloitte Australia готовила для правительства официальный отчёт и использовала при этом ИИ.
В кейсе про отчет Deloitte провал не в том, что не был использован Claude Citations API, а в том, что отчеты вообще генерируются ИИ. Тем более для провительства.
Здесь сразу несколько проблем наслаиваются. Citations API не защищает от галлюцинаций, об этом даже в хэлпе пишут: https://claudeapi.com/en/blog/dev-guides/claude-citations-api-guide/#section-6
Pitfall 5: Citations ≠ hallucination-proof. The model can still misinterpret document semantics. Citations only guarantee that “the cited position actually exists in the source” — not that “the interpretation of the citation is correct.” In production, consider a secondary validation step: run a semantic consistency check between cited_text and the model’s answer.
Там почему-то не пишут, что Citations API также не защищает от плохих в любом смысле источников. В статье подсвечиваются цитаты без источника, но цитаты с источником не проверяются, и в итоге в отчет просто может попасть чушь, на основании которой опять же будет генерироваться отчет для правительства, на чтение которого Deloitte так же забьет. Будьте уверены, будут атаки с зараженными источниками, чтобы манипулировать отчетами для правительства.
Еще цитаты могут изменить смысл радикально. Например, возьмем цитату Черчиля: “Democracy is the worst form of Government except all those other forms that have been tried from time to time”. Давайте процитируем только первую часть ее: “Democracy is the worst form of Government”. Я надеюсь, не нужно дальше объяснять, как подобное может повлиять на генерацию отчетов для правительства.
Этих людей нужно не учить использовать едва где полезный Citations API, а как минимум уволить, а еще лучше судить.
Статья про архитектуру с principle of least privilege, и в ней ни слова про sandboxing, интересно.
Изоляция подразумевалась как базовый уровень, но кейс у меня чуть другой, и песочницей он не решается. Допустим агенту по условию задачи нужно уметь отменить подписку, это его прямая работа. Нельзя ему только одно: отменить их все разом. И пеосчницей такое не решается.
С кейсом Шумера согласен полностью, там отказал именно периметр, агенту отдали машину целиком. Изоляция это лучший первый рубеж, и тема тянет на отдельную статью, в эту честно не влезла.
Citations API не защищает от галлюцинаций
Соглашусь, и сформулирую точнее, чем в статье. Citations проверяет не истинность, а атрибуцию: закрывает ровно один класс ошибок, выдуманные ссылки и цитаты, которых в источнике нет. Именно он и утопил Deloitte, там были несуществующие работы и приписанная судье фраза.
Остальные классы требуют других контролей. Неверная интерпретация верной цитаты ловится семантической сверкой и ревью человеком, обрезанная цитата (ваш Черчилль эталонный пример) проверкой контекста вокруг фрагмента, а заражённые источники это вообще про доверие к корпусу, тут нужен whitelist. Ни один механизм не закрывает всё сразу, они набираются послойно. Беда Deloitte не в неправильном выборе инструмента, а в том, что не было ни одного.
провал не в том, что не был использован Citations API, а в том, что отчеты вообще генерируются ИИ
А вот здесь не соглашусь. Вопрос не в том, участвует ли модель, а в том, как устроен процесс вокруг неё.
Deloitte утонула не потому, что применила ИИ, а потому, что применила его без единого контроля и без ответственного, который прочитал бы результат. Сноски никто не открыл, семантику никто не сверил, а подпись под документом всё равно стояла. Замените модель на подрядчика-джуна, которому никто не сделал ревью, и получите ровно тот же скандал, только медленнее.
Мой тезис как раз в том, что при правильно выстроенной обвязке и с человеком в контуре такие отчёты делать можно и нужно. Обвязка не отменяет человека, она сокращает объём того, что ему приходится перепроверять руками: вместо сплошной вычитки двухсот страниц остаётся десяток непроверенных утверждений и итоговые выводы.
Спасибо за разбор, Черчилля заберу себе как пример.
Нельзя ему только одно: отменить их все разом. И пеосчницей такое не решается.
Вполне себе решается. В статье предлагается спрашивать человека про необратимые операции. Я написал, что Claude любит игнорировать permissions, он бы и это правило мог проигнорировать тоже. Если он в песочнице с ограниченным набором доступных инструментов, то не смог бы. В этом весь смысл первой части моего комментария.
Теперь понял точнее, и по сути вы правы. Одна техническая деталь: подтверждение в моём примере это не permission-правило, которое интерпретирует модель. Claude возвращает запрос на вызов, а решение принимает мой код, и request_human_approval живёт внутри него. Проигнорировать его модель не может, она его просто не видит. Но дальше именно то, о чём вы говорите. Работает это только если мой execute_tool единственный путь к возможности. Есть шелл, ключ или сеть, и агент не обходит approval, а идёт мимо. В кейсе BridgeMind так и вышло: агент написал крон, дёргающий Stripe напрямую полным ключом. Подтверждение никто не игнорировал, его на том маршруте просто не было. Отсюда песочница сводит число маршрутов к одному, а обвязка на этом маршруте добавляет гранулярность, которую периметр не выражает: одну отмену можно, все сразу нельзя. Так что согласен, изоляция должна была идти нулевым слоем, а не подразумеваться. Спасибо, что дожали.
Я веду ML продукт с 2015, llM Проекты с ноября 25го. Чёт мне ни один клиент не прислал ссылки может ли такое случиться. То ли они мне доверяют, то ли затравка для статьи так себе - ситуация с deloitte была в ноябре прошлого года. Журналиста ловили в апреле. На свежие инциденты никак не тянет.
А так по теме - guardrails никто не отменял, если их не отменить. Фактчеки - аналогично. Потому, что иначе - одна ошибка... И ты ошибся. © И ошибся именно тот, кто внедрял а не Llm и не агент. И это постоянно забывают указать в таких статья пугалках.
Работающий и безопасный продукт получается тогда, когда вокруг ядра выстроена правильная архитектура: валидация на границах, детерминированные гарантии вместо пожеланий в промпте, продуманные права и пороги под цену ошибки. Разбор чужих инцидентов, вроде трёх в этой статье, самый дешёвый способ этому научиться.
Про "безопасный" - слишком оптимистично сказано. Вернее, "относительно безопасный". В статье приводятся три архитектурных "костыля" по результатам "разбора чужих инцидентов", но нет гарантии, что следующий инцидент для "научиться", который пока не учтён нигде в архитектуре, не случится именно у вас.
Это LLM, устранить все потенциальные проблемы невозможно принципиально. Но об этом часто забывают, а ряд людей, как кажется, даже верит, что обвязка окажется абсолютной защитой.
Про «относительно безопасный» соглашусь, так честнее.
И вообще соглашусь по-крупному: отрасль совсем молодая, полного каталога способов сломаться сейчас нет ни у кого. Три слоя не закрывают неизвестное, они лишь ограничивают цену того, что мы ещё не видели.
Гарантий тут никто не даёт, и обещать их было бы враньём. Но мне как раз этим и интересно. Мы сейчас нащупываем практики примерно как индустрия в своё время нащупывала тесты и канареечные выкаты, и хорошо, что не в одиночку: вендоры выкатывают инструменты для этого довольно быстро, от structured outputs до ограничения прав агентов.
Через пару лет всё это будет выглядеть очевидным, а пока каждый инцидент правда учит. Про веру в абсолютную защиту согласен полностью, она сама по себе фактор риска.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Модель не виновата: разбираем 3 громких ИИ-инцидента, которые случились из-за отсутствия архитектуры