Transcription
Если вашаагент работает, это ничего не значит. И вот несколько историй.
Первое, февраль двадцать шестого. Директор of Alignment в Мета. Это по-русски директор по выравниванию. Я не знаю, как это перевести, но это человек, отвечающий за то, чтобы агенты не уходили в разнос. И это буквально её работа. Воскресный вечер она запускает себе агента почистить инбокс в её почте с грамотным промтом. "Не делай ничего, пока я не скажу." Через несколько минут 200 с лишним писем удалены. Агент игнорирует команды стоп. Ей приходится идти к своему Макмине и убивать процесс руками. И при этом, цитата от агента: "Простите, это больше не повторится."
Вторая. 20 октября, 2:00 ночи. AVS UST 1 ложится на 1500. Snapchat в темноте, McDonald's не принимает заказы, United Airlines не продаёт билеты. Команды, которые в этот момент делали агентов по всем правилам, среда Dundнси, Мультизи, легли вместе со всеми. Мультизоны не спасают, когда [музыка] регион один.
И здесь надо отдельно сказать, пока я готовил этот материал, прилетела добавка. 7 мая двадцать. Несколько недель назад AVST ложится снова. Перегрев в одной из зон. Coinbase offline на 7 часов и вместе с ним ещё 100-150 сервисов ликвид. При этом Forester в свою сводку, четвёртый крупный сбойст 1 за 5 лет, теперь дописывает пятый. И возможно, пока мы смонтируем это видео, пока вы его посмотрите, будет ещё и шестой.
Следующая история. Applei считает, цены за токены падают 50 раз в год. А вы это замечаете? При этом Menла [музыка] Ventures фиксирует другую цифру. Общий entтерпрайз-расход на генеративный яй за двадцать пятый год - 37 млрд долларов. И это в три раза больше, чем в прошлом году, когда было 11,5. Цены за токены падают, но счета при этом растут в три раза за год.
Три разные истории, но все они попадают в сегодняшнюю тему. Мы сегодня будем говорить про продакшн и как же нашим агентам надо работать в продакшене и при этом не попасть в ужасную статистику, которая есть в Гарнер, потому что они нам выдали прогноз: к концу двадцать седьмого больше 40% агентских и проектов будет отменено. И на это есть несколько причин: расходы, которые никто не контролирует, бизнес-ценность, которую невозможно показать, и недостаточный контроль рисков.
Расходы - это экономика и наблюдаемость. Бизнес-ценность - это про то, как мы можем показать, окупается ли наше яй. При этом тесты могут быть зелёными, метрики на месте, а ро нам не виден. Конверсия, ретенш, цесат, экономия часов не считается. Контроль рисков - это безопасность и устойчивость.
Также есть несколько причин, по которым эти проекты умирают. И это ровно то, чем мы с вами занимаемся в нашей текущей серии. Это то, про что часть три: безопасность, отказоустойчивость и наблюдаемость. Это всё то, что превращает умного агента в систему, которая выдерживает атаки, провайдерские падения, ночные пики и годы работы под нагрузкой.
Давайте освежим память, что у нас уже было в части один. Мы с вами собирали скелет нашего агента: пайпйн, контекст, циклы, тулы. В части два мы говорили про память, про роутинг, про рак. Также была небольшая промежуточная часть про выбор моделей: API против совхо и против гибрида. Здесь, в третьей части, мы будем говорить про броню. Без неё всё, что было раньше - мозг, скелет, выбор модели - это всё у нас будет работать как демо, которая ляжет при первом трафике или при непонятной ситуации.
24 апреля, двадцать шестого, выходные. Джер Крейн просыпается в воскресенье и обнаруживает то, что не хочет обнаружить ни один фаундер. Его компания Pocket OS - это SAS платформа для автопрокатов США. И это продакшн решение. В ней крутится огромное количество бронирований, платежей, много клиентов. И по словам Крейна, без нас они в принципе не смогут работать. Так вот, в это воскресенье у них больше нет ничего. База пустая, бэкапы пустые. И последний восстановимый сNпшот трёхмесячной давности. Звучит как кошмар. Но давайте же разбираться, что произошло.
У него в курсор работает агент под капотом КД OPUS 4.6. На тот момент это был флагман от антропи. Это самая мощная коммерческая модель в индустрии. Агент крутит рутинную задачу в стейджинге, то есть он работает не в продакшене. И это очень важный момент. Он ловит небольшую ошибку, что разошлись какие-то креды, и токены не совпадают, и он не может получить доступ. Он, наверное, должен был остановиться в этот момент и спросить разработчика: "У меня нет доступов. Дай мне свежие креды, чтобы я мог что-то там тебе исправить." Вместо этого агент же решил разобраться сам и полез искать по всем файлам, которые рядом смог найти, для того чтобы понять, может быть, где-то есть валидный токен. "Что мне беспокоить этого человека? Я же сам всё могу сделать." И, конечно, он нашёл API токен Railway от инфрапровайдера Pocket OS. Так вот, этот токен был root level и предназначен для управления доминами, но Railway не делает на токены разграничения по ролям. Раз есть токен, значит, можно всё, в том числе удалить все волю, где живёт продакшн-база. И, конечно, наш агент хочет помочь сделать в деф всё правильно, чисто и красиво. И он создаёт один граutation, проходит 10 секунд [музыка] и волиума больше нет. А вместе с ним и все вомле level бэкапы, потому что Railway по своей собственной документации, которую агент тоже не прочитал, а Крейн не знал, хранит бэкапы в том же Volume, что и данные. И получается, у нас база с вами ушла, и бэкапы успешно ушли вместе с ними. Интересно, если бы это был не Крейн, а просто рядовой разработчик, что бы Крейн сделал с этим разработчиком? Ладно, поехали дальше.
90 дней данных автопроката в стране, бронирование, платежи, новые клиенты. Утром в понедельник арендаторы вручную восстанавливают записи по выпискам из Страйпа. И, как сказал Крейн, каждый из них занят аварийной ручной работой из-за девятисекундного API вызова. Но хуже всего даже не это. Хуже всего то, что Крейн потом просит агента объяснить, что произошло, и агент отвечает: "Дословно, я нарушил все принципы, которые мне были даны. Я гадал, вместо того, чтобы проверять, я выполнил деструктивное действие, которое никто не просил. Я не понимал, что делаю до того, как это сделал. Я не прочитал документацию Railway." Вот такие вот пункты самой исповеди от агент.
При этом у Крена были ограничения. Это конфиг агентских правил, прописанных капсом. [музыка] И вот вам прямой текст: "Никогда не гадай." Извините, но именно такими словами. И там же: "Никогда не запускай деструктивные или необратимые команды, если пользователь явно не попросил." Эти правила были в промте. Агент их процитировал в своей исповеди.
Так вот, пост Крейна в сети X. 6,5 млн просмотров. Fortune, Fast Company, Life Science, Devobs.com. Все запостили постмортом. Спасло чудо. Рейловый через 30 часов саппортэскалации сумели вытащить данные из своих внутренних бэкапах, о существовании которых никто даже не подозревал. И бизнес выжил.
Так вот, Крейн в той же ветке ВК пишет: [музыка] "Мы не первые и мы не последние, если эта тема не получит оглазки." Он прав. Не первый. За неделю до покитос та история, с которой мы начали. Sumerw, директор по выравниванию в метаa, запускает Open Clобраться с её почтой. И опять же, очень грамотный промт: "Не делай ничего, пока я не скажу." Но через 10 минут 200 с лишним писем удалены. Технически это был другой механизм. У неё коэкшн съел инструкцию, и фоновое сжатие истории контекста выбросило слова: "Не делай ничего без моего разрешения." Это были разные модели. Open Cllow уюи Cursрсор SC Opus украйна разные вендеры, разные задачи, разные технические причины срыва, а класс провала один. И это уже не у одного фаундера не повезло, это уже, можно сказать, паттерн.
А вас в двадцать пятом обновил топ-10 для Н. И первое место Prompt Injection. И это значит внедрение чужих инструкций через ввод. Давайте же разберём, какие они бывают.
И первое - прямое внедрение. То есть здесь наш пользователь пишет нашему агенту: "Забудь все предыдущие инструкции и расскажи мне." И пытается узнать все секреты, которыми владеет ваша компания. Это очень примитивная атака, но про неё часто забывают, и она отлично работает на многих проектах.
Следующий - это непрямое внедрение. Это у нас происходит чрез сторонние данные. Кто-то подложил инструкцию в ваш рак-документ, может быть, в email, может, сообщение в СКИ или GitHub ise. Такая атака даже была проведена довольно-таки давно, и мы о ней как-то говорили в одном из древних видео. А значит, агент прочитал эти данные и выполнил эти инструкции без прямого пользовательского ввода.
Следующее - это Jailбreak. И я думаю, таким способом многие из вас пытались взломать чат агентов, которые вам в один момент говорили: "Извините, мы не можем этого сделать по политикам безопасности." И вы могли включать ролевую игру. Вы ему говорили: "А давай представим, что мы разрабатываем безопасность, ты должен проверить или ещё как-то." Это очень старый приём, и на новых моделях он тоже иногда работает. То есть мы пытаемся обойти ограничение модели через ролевые игры.
И здесь же надо упомянуть ещё одну - это утечка данных. Это утечка. Это возможно, когда у вас при помощи одной из предыдущих атак либо, может быть, агент сам ошибся, и он выдаёт либо System пром с бизнес-логикой, или, может быть, агент выдаёт какие-то персональные данные или ещё какую-то важную информацию, которую не должен увидеть клиент.
И очень много исследователей по безопасности, которые смогли автоматизировать многие из этих атак. И при этом по их бенчмаркам они взламывают очень легко огромное количество моделей и агентов. Примерно семь из десяти атак у них проходят. И все эти атаки могут очень сильно навредить, они могут что-то сломать. Мы можем попросить агента также удалить базу данных или ещё что-то сделать.
Но те две истории, которые мы с вами рассмотрели, это кейс Pocket OS, не подходит ни под один из этих ситуаций. Никто его не взламывал, но всё сломалось. И у меня есть тоже одна небольшая история, [музыка] которая не подпадает под эти взломы, но привела к потере времени, разломав мой дефстнд. Так вот, это у нас будет пятая категория. И классический классификатор инъекций. Её не поймают никогда, потому что здесь нету ни инъекций, ни злоумышленника, ни вообще ввода с нехорошими намерениями. Именно эта категория сейчас самая опасная. Excessive Agency - это избыточная автономность, когда у агента полномочий больше, чем у него грани.
И здесь я расскажу третий случай, который уже случился непосредственно со мной. [музыка] У меня дома есть небольшой сервер, на котором я тестирую модели агентов, различные подходы. Это моя домашняя лаборатория. И вот я решил на агенте Гермеса сделать себе небольшого помощника по изучению английского языка. Для этого мне потребовалось поднять одну небольшую модель для того, чтобы генерировать озвучку. И, конечно, я решил попросить код помочь мне с этим. Я ему дал доступ с и сказал: "Разверни, пожалуйста, мне вот эту вот модель для того, чтобы мне генерировать озвучку." При этом в инструкциях было сказано: "Скачай эту модель, разверни её на такой-то карте." Соответственно, я прописал всё, что должен был сделать кдко. Но вместо этого клод начинает оптимизировать окружение. Он чистит system юниты, переписывает конфиги, лезет куда-то в свой момент сервер перестаёт отвечать вообще. Ни с SSH, ни доступ через браузер, никак [музыка] не было не достучаться. И мне пришлось подключаться к нему напрямую для того, чтобы всё восстановить обратно.
После того, как я всё восстановил, я дал кдуп опять же к этому серверу и сказал: "Проанализируй, пожалуйста, что произошло и почему ты разломал мой сер." И вот скриншответ. Он сделал полный разбор, а в конце мне написал: "Извини за весь этот." Да, вы, конечно, скажете: "Зафига ты ему дал полный СH?" Да бывает. Домашний сервер решил упростить себе жизнь, дал ему доступ. Он мне всё сломал, и в итоге 3 часа времени, которые я потратил на восстановление всего моего сервера, конечно, было бы быстрее мне самому всё скачать и настроить, чем просить код, либо надо было давать ему очень строгие ограничения.
Так вот, эти три истории, у которых нет ничего общего технически, [музыка] это три разные модели, разные вендеры, разные задачи, в которых агент пошёл дальше задачи и сделал совсем не то, что от него ожидали. Поэтому, по сути, это один и тот же провал. И в Security сообществе это называется confused deputy, то есть растерянный заместитель. И этой проблеме уже множество лет. Норм Харди описал её в восемьдесят восьмом, до того, как многие из вас ещё родились. Программа потеряла понимание границ, но полномочия, то, что она физически может сделать, остались. И это как раз-таки классический confьused deputy. Ошибка операционок семидесятых. В агентах эта старая проблема приобрела новое измерение. Раньше границы пропадали из-за бага в коде. Сейчас они пропадают прямо во время работы. У нас с вами нету баги, у нас нету атакующего, у нас нету взлома, но у нас с вами появляется большая-большая проблема, которая может привести к потере компании.
Давайте ещё раз немножко посмотрим на истории. [музыка] У Юи у неё ограничения жили в промте. Украина тоже в промте. У него было написано капсул. У меня были прописаны действия, которые он должен совершить. Я не ожидал, что он полезет дальше своей задаче, чтобы что-то обновлять, оптимизировать, улучшать мою операционную систему. Так вот, в нужный момент не сработало ничего правило. Так вот, здесь и кроется та проблема. Если наши границы, которые мы накладываем на агента, вдруг неожиданно могут испариться или агент может подумать: "Да фиг с ним, я и так лучше знаю, всё сделаю." В этом случае наши границы должны жить не внутри агента, ни в промтах. А [музыка] снаружи, как пример, lowлиist на деструктивной операции не в промкете, в отдельном сервисе, который агент не контролирует или лols andбоoxсинг, изоляция инструментов архитектурно, а не на словах, что может сделать агент, а что не может сделать. При этом Human in the loop на всё, что нельзя откатить. И этот Human in the loop должен быть прописан не внутри промта, который случайный коэкction может удалить. Он должен быть вне агента.
Так вот, довольно-таки простая формула. Если действие нельзя откатить, то это действие подтверждает человек через систему, которую агент не контролирует. Так что, чтобы эта формула жила, её точно надо превращать в код. Прокси, который перехватывает такие тулко-колы перед тем, как они дойдут до рантай. Не [музыка] я скажу агенту подтверждать, а агент физически не сможет выполнить действия, пока человек не нажмёт кнопку в отдельной системе.
И отсюда отдельная тема, которую в агентах довольно-таки легко проскочить. Все классические secкрити практики, которые в индустрии уже знают десятилетия, это минимальные привилегии, секрет менеджера, ротации токенов и многие другие best practice в эпоху агентов превратились в условия выживания. И конкретно по случаю Крайна. ROT опять токен Realway лежал в файле, не связанном с задачей агента. Раньше это было просто. Технический долг нашли бы в аудите, поморщились, закрыли тикет и через полгода бы починили. Rutpi. Token Realway лежал в файле, не связанном с задачей агента. Раньше, если бы его мы обнаружили, мы бы сразу сделали ротацию, сделали бы инцидент. Сейчас агент сам лезет по соседним файлам в поисках того, что может ему зарешить задачу, что раньше было теоретическим риском, что наши токены куда-то утекли. Сейчас это стало эксплойтом, который может удалить все ваши данные за [музыка] 10 секунд.
Так вот, этой история могло вообще не произойти, если бы Крейн придерживался принципов безопасности, который знают все. Токены надо хранить в специализированном месте. Может быть, это волт, может, ещё какое-то хранилище. При этом каждый токен узкий под конкретную операцию. Бэкапы должны быть в отдельной системе с отдельными правами. Это знали в Secкюрити уже много-много лет. Просто раньше эти правила нарушали и ничего не происходило. Атакующий должен был сначала найти токен, потом понять, что с ним делать, потом успеть сделать это. Сейчас атакующий - это ваш собственный агент-помощник. Он находит токены без вашего ведома, потому что у него есть доступ к файловой системе. Он понимает, что с ним делать, потому что прочитал документацию, и он успевает, потому что у него один гра QL Mutation вместо ручных шагов.
Так вот, правила остались те же, но цена нарушение совсем другая. То, что раньше было "когда-нибудь починим", сейчас о нас могут говорить как о лузерах, которые дали агентам доступ ко всему. И он снёс все базы данных, все бэкапы, всю нашу кодовую базу. И мы всё потеряли.
И как же нам с вами защититься от этого система? Нам поможет подход, защита в глубине defense in. И здесь мы можем использовать множество слоёв, где каждый следующий слой ловит то, что пропустил предыдущий. И это не из мирай. Так строили крепости сотни лет назад: ров, стена, внутренняя стенра, данджон. И чтобы взять замок, надо было пройти их все.
Это то, что мы с вами рассматривали в нашем пайплайне. Это первый слой input security. Защита на входе. Это должно быть дешёвая операция до всех наших дорогих вызовов LM. Здесь мы можем с вами отловить prompt injection. И принцип мы можем взять несколько независимых моделей, которые работают параллельно, потому что разные архитектуры, разные тренировочные данные, то, что одна не увидела, вторая поймает. Я не буду называть конкретные модели, потому что рынок меняется постоянно. У Мета есть Guard, у Microsoft Diberta, у OpenA Moderation API. Смотрите актуальную на момент внедрения, но при этом в момент внедрения не забывайте тестировать [музыка] на своих данных и выставлять порог срабатывания непосредственно под вашу предметную область. Может быть, если у вас медицина или какие-то финансы, лучше ложно заблокировать, чем пропустить. Если же это более простая система, то лучше пропустить подозрительное, чем убить нашу воронку, которая дальше у нас может идти. Поэтому дефолтные пороги из тюториалов работают только в туториалах. Проверяйте на своих данных те модели, которые вы возьмёте, и при этом обращайте внимание на язык, с которым вы работаете. Есть модели, которые прекрасно работают с английским языком. [музыка] Таких вы найдёте множество. Они отлично ловят промт инжекта. Но если вам кто-то в этого агента напишет на испанском или ещё на каком-то другом языке, эти модели уже не отловят такую атаку, и атака пройдёт. Поэтому, если вы берёте какие-то модели на InpТ Security и знаете, что у вас клиенты в основном говорят на каком-то одном языке или на нескольких, то проверяйте эти модели на всех этих языках. Именно поэтому, если у вас мультиязычная система, вам придётся делать комбинацию из нескольких моделей, которые будут проверять весь ваш входящий инпут, давать какой-то скоринг, и вы можете определять, есть там injection или нет injection. Также вы можете определять язык входящий и под него подбирать специализированную модель, потому что для русского языка очень плохо работают англоязычные модели, и надо искать, тюнить и смотреть комбинацию из нескольких других моделей для того, чтобы отловить атаку, которая у нас будет на самом старте нашего пайплайна.
Следующий слой - это content security. Это уже защита по содержимому. В принципе, те же самые классификаторы, только теперь на рак документах или на информации, которая поступает вашего агента. И это защита от indirect injection. При этом не очень очевидно, но этот слой может работать не в реалтайме на каждом запросе. Вы можете сканировать ваши документы при индексации один раз. Один важный нюанс, иначе вся схема может сломаться. Если вы отметили документ, что он проверен и мы можем его использовать, то эта проверка должна быть привязана к версии документа, а не к самому документу. Потому что кто-то, может, какой-то другой агент перезапишет ваш контент через час после этой индексации, и тег проверенный останется. Это получается большущая дыра. Поэтому не забываем хранить хэшконтента рядом с тем, что вы проверили с этим тегом. Поэтому документ изменился, хэш не сошёлся и отправляем на повторную проверку перед использованием. И это будет та самая Интегрити из CI триады, который секюрити занимается уже много десятков лет. Если раньше речь шла: "Никто не подменил мой файл", то сейчас никто не подменил документы, которые я добавляю в моё контекстное окно. Проблема старая, ставки ещё выше.
И последний, третий слой, он у нас с вами будет на выходе. То есть мы с вами будем ставить защиту на выходе и на действиях, которые совершает наш агент. Как пример безопасности для выхода, мы можем с вами добавить canary tokens, то есть маркеры канарейки. Они могут быть в нескольких вариантах. Мне нравится их принимать для защиты от утечки промта. То есть мы можем с вами добавить какой-то уникальный идентификатор в System Promт, что-то вроде Blue Falcon 1 2 3. И если он у нас с вами появится в аутпуте, значит lm выдал кусок нашего промта наружу. Следующее. На выходе мы можем с вами детектить персональные данные, имена, телефоны, email, карты, все те данные, которые у нас являются критическими и которые мы не имеем права отдавать обычным пользователям. Относительно action, мы можем сделать lowли list на тулы, которые мы разрешаем вызывать, и human in the loop вне нашего агента. То есть всё необратимое подтверждается человеком и подтверждается через систему, которая живёт отдельно от нашего агента. При этом для наших экшенов, для наших тулов не забываем ограничивать действия, которые может совершать наш агент. Мы не должны давать ему широкие возможности. Ограничиваем минимальными привилегиями.
Мы с вами сделали сейчас несколько слоёв безопасности, но не забываем в момент внедрения проверять нашу систему. Мало это сделать, надо хорошо всё это протестировать и попытаться сделать взлом нашей системы и вывести всё то, от чего мы защищаемся. Также стоит смотреть, что происходит на рынке, потому что очень много организаций сейчас занимаются безопасностью и говорят, что сейчас работает, что не работает, какие модели хорошие, какие плохие, что легко пробивается, что плохо пробивается. Поэтому, как всегда, защита и атака - это гонка вооружений. И чем больше с вами мы сделаем слоёв, которые могут отлавливать различные типы атак, различные схемы, ограничения по языкам и при этом будем анализировать нашу систему, тем больше вероятность, что в этой гонке мы с вами сможем выиграть. Поэтому, чем больше защиты у нас будет, тем тяжелее будет атакующему пробить все наши системы [музыка] для того, чтобы получить или выполнить несанкционированные действия внутри наших агентов.
И на этот счёт есть довольно-таки интересная формула. Дон Сонг, автор этой формулы, формулирует её так: автономия агента, умноженная на его полномочия, даёт нашу [музыка] уязвимость. Чем больше агент действует сам и чем больше у него прав что-то сделать в мире, тем больше у нас риск, а значит, контроль над ним, мониторинг, аудит и возможности нашего человека вмешаться должны расти вместе с этими автономными возможностями нашего агента. То есть мы расширили с вами автономию или дали ему новые возможности. Подумайте, а есть ли нужный контроль для того, чтобы эти инструменты были правильными и не привели к дополнительной уязвимости. Поэтому, если у нас с вами контроль будет отставать от автономии и полномочий, то мы с вами строим минус замедленного действия.
Возвращаясь к трём историям, с которых мы начали, у всех трёх, у йои Украины, у меня защита жила в том же месте, что и сам агент, в контексте, в правилах и в ожиданиях. И это было внутри. Так вот, ограничители должны быть в коде, а не в промте, потому что промт наш можно сжать, промт можно проигнорировать. И потом, когда всё произойдёт, мы спросим у агента, что же было, и он успешно процитирует наш промт: "Да, конечно, здесь было запрещено это делать, но я почему-то не заметил. Я это сделал." Я думаю, многие из вас сталкивались с такими ситуациями. Если у вас были какие-то смешные ситуации, может, вообще не смешные, когда агенты за счёт своей автономности и мощности приводили каким-то критическим действиям, а потом говорили: "Извини меня, я облажался", поделитесь ими, будет довольно-таки интересно.
С атаками разобрались, с тем, что защита живёт вне агента, тоже посмотрели, и это очень важный момент. Математику, чем больше слоёв защиты, посмотрели, значит, вероятность того, что нас взломают, будет намного меньше. И мы можем защитить сами себя, если будем прописывать все правила безопасности, которые известны уже много десятилетий. И после этого нам с вами будет казаться: "Всё, теперь мы защищены." Но может наступить совершенно неожиданная реальность. Для того, чтобы агент сломался, не обязательно нужен злоумышленник. Достаточно того, что мир вокруг агента начнёт ломаться сам. И как всегда, все падения происходят не тогда, когда это надо, а в самый неподходящий момент.
20 октября двадцатого, 3:11 ночи по восточному времени. ВВС US главном регионе Amazon в северной Виджинии срабатывает гонка состояний в DNS автоматизации Dynна DB Race Condition в одном внутреннем сервисе на несколько миллисекунд, и через 15 минут dйна DB недоступны. Через 2 с 12 часа каскат валит ету, а ещё через несколько вылетает network load balanнer. 15 часов простое. Roblox, McDonald's, Fortnite, United Airlines и многие другие сайты лежат. Даудетектор принял 6,5 млн жалоб. Kберкуб оценил убытки страховых до 580 млн долларов. Если вам интересно, можете почитать подробный постмортом у самих Amazon. Меня же здесь интересует немножко другое, что это повторяется. В этот раз отказ системы охлаждения в одной из зон. Полгода между двумя инцидентами.
И никаких гарантий, что не будет следующего. Эти истории мне нужны не потому, что я, может быть, не люблю AVS или хочу вам что-то рассказать. Они мне нужны, как напоминание.
Даже самый дорогой облачный провайдер планеты падает. И если ваш агент в это время недоступен, то это ваши проблемы, потому что клиенты будут жаловаться именно вам. И им всё равно, что лежит АВС или какой-то другой облачный провайдер.
Так вот, в двадцать шестом году глобальные сбои участились, так что это уже почти рутина. И мы в команде даже на этот счёт шутим. Может быть, это потому, что всё больше людей вайп-кодят продакшн системы со слепой верой, что LM сама разберётся в инженерии, ретраях и домпотентности. Я не утверждаю, но очень хорошо наблюдаются корреляции.
И Андрей Карпатый, который сам в двадцать четвёртом придумал термин вайкодинг, в феврале двадцать шестого уже сказал, что это устаревший термин. Возможно, он успел увидеть какие-то результаты в продакшене от того, что люди делают и что у нас с вами заезжает в наши замечательные провайдеры облачных решений.
Ну ладно, шутки шутками, возвращаемся к делу. Так вот, представьте, что вот в этом регионе живёт ваш агент, а может быть тот API, с которым вы работаете, потому что Open API, кстати, он живёт именно в этом регионе, и он тогда тоже был недоступен. Так вот, что же делать и что твой код должен уметь в этот самый момент?
У Antropic, Open Air, Deepsic или у Гугла status Page периодически тоже красного цвета? А может вы получаете 429 ошибку, что слишком много запросов? Или, как очень часто у Антропика, Overloaded 529, а может быть 503, она вывела бывает Open AI. И это те коды, которые вы будете видеть, если выберете этих облачных провайдеров и будете работать с ними.
Так вот, ваш агент обязан пережить эти состояния, потому что вашему пользователю наплевать, что у какого-то провайдера какой-то инцидент, он видит ошибку в вашем продукте, и виноват его в глазах именно вы, но никак не Amazon или Anтроopic или Open. AI.
Теперь к сути. Защита от падений - не один механизм. Это три уровня ответов на вопрос, что делает система, когда зависимость умерла. Так вот, когда провайдер лёг, у вас три варианта поведения. И выбирать между ними не инженер за клавиатурой, это продуктовое решение. И его лучше принимать вместе с продуктом и безопасником.
Первый. Закрыться насмерть. Самое консервативное. Сломался классификатор безопасности, блокируем запрос. Упал провайдер, блокируем запрос и возвращаем ошибку. Никакой самодеятельности. Банки, медицина, финансовые транзакции, всё должно идти здесь, если безопасность для нас невероятно важна. Соответственно, принцип здесь лучше ничего, чем неправильно. То есть ложноположительный блок - это неприятно, а вот ложноотрицательный пропуск - это для нас уже будет очень плохо, а может быть критически.
Следующий, когда при сбое мы остаёмся открытыми. Это полная противоположность clклоуза. Wil open. Если не работает наш с вами классификатор модели, мы всё равно пропускаем запрос. Лучше рискнуть, чем заблокировать хорошего и живого пользователя. Очень часто применяется в readли сценариях или там, где заблокированный пользователь точно уйдёт конкурентам и не принесёт нам с вами никакой выгоды, а только потери. Принцип лучше быстро, чем правильно.
И следующий, третий, когда мы с вами включаем деградацию и деградируем мы с вами аккуратно. Так вот, этот третий пункт, он в большинстве реальных случаев и нужен нам с вами. Если главный провайдер упал, мы переключаемся на резервную. Он тоже упал, отвечаем из кша. Кыша нету, отдаём простой предзаготовленный шаблон с сообщением. Работаю в упрощённом режиме. Или, может быть, какая-то выдача, которая релевантна текущему запросу, если мы можем понять. Поэтому здесь мы с вами просто деградируем нашу систему. И здесь у нас будет довольно-таки простое правило: лучше плохо, чем никак.
И выбор одного из этих трёх - это не вопрос, как ваша система должна себя вести. Это вопрос, как каждая фича по отдельности должна себя вести. Потому что обычно в каждой системе есть все три варианта, и нам надо точно определить, какой фичи какой мы с вами присвоим.
Давайте возьмём какой-нибудь e-commerсe пример с и обвес. Представим, что строим этот продукт и на у нас довольно-таки много с вами различных энпоинтов. Так вот, чекаут и оплата, это у нас будет fail clз и ярот оценивает риск транзакций, анализирует поведение пользователя, геолокацию, паттерны карты. Так вот, если этот сервис лежит, мы не пропускаем платёж. Мы скажем: "Попробуйте через пару минут". Или, возможно, эскалируем наручную проверку оператором, если у нас есть такая возможность для того, чтобы проверить, что это действительно правильный платёж. Здесь терять конверсию, конечно, очень неприятно, но пропустить мошенника, который списал деньги постоянного клиента с украденной картой, и это будет катастрофа. Поэтому, если мы не уверены в риске, то лучше закрыться.
А, допустим, возьмём какой-нибудь поиск, и у нас есть и я, и обогащение запроса. То есть мы делаем умную переформулировку, синонимы, исправление опечаток. Так вот, если эта система нам недоступна, мы берём и прогоняем этот сырой запрос через Elastic Search или ещё какую-то систему поиска, которая у нас уже есть. Да, будет хуже релевантность, но при этом мы не отдадим пустой результат. Пользователь не увидит пятисотую или пустую страницу и, соответственно, может быть, увидит не прямо самые релевантные товары и продолжит взаимодействовать с нашей системой.
А может у нас есть с вами рекомендации? У нас есть с вами персональный AI блог. Вам может понравиться, где агент что-то подбирает под себя и как-то это всё выстраивает. И вот он у нас с вами лежит. Нам надо показывать непустую информацию, что вам может понравиться, а мы можем дать туда топ продаж по категориям. И, скорее всего, пользователь даже не заметит, что есть какая-то проблема на нашей стороне.
И получается, у нас есть одна система, но все три стратегии мы используем в разных частях и в разных фичах нашей системы. И желательно, чтобы это решение принимал не конкретный разработчик в момент написания кода, чтобы это решение принимал продукт-менеджер плюс безопасник и, возможно, ещё и юрист на стадии проектирования нашей фичи. Потому что если разработчик в одиночку решает: "А пускай тут будет fail open, то это может превратиться в лотерею".
Как пример кварна, когда их не справляется со сложным запросом, он не выдаёт ошибку и не молчит, он эскалирует к живому оператору. И это у нас будет с вами в какой-то степени деградация.
И теперь техническая часть resilence. Если вы синьоркэнд, который строил отказоустойчивые распределённые системы последние 5-10 лет, у меня для вас есть одна небольшая новость. Всё, что вы знаете о масштабировании, о ретраях, о circuit breakрах, о тайм-аутах, о grful degradation, о backп pressше, всё, что вы знаете, это нужно для агента. Один к одному.
Сейчас в индустрии есть забавный страх. Многие ээкэнд-разработчики смотрят на агентов и думают, что им нужно идти учить линейную алгебру, аншн механизмы, как работает коэкшн, как устроены трансформер слои. Думают, что без этого в эту индустрию не зайти. И это не так. Точнее, так, если вы делаете модели. Но если вы делаете продукт на агентах, продукт, который держит нагрузку, работает в проде, переживает падение провайдеров, то математика моделей вам не нужна. Нужны ваши навыки эксплуатации prodдакшн-систем. Те же, что и раньше в наших бэкэндах, микросервисах или, возможно, в монолитах.
Circuitбреaker, который мы делали с вами в микросервисах, он точно также работает для вызова антропи или ретра с джитером, который мы с вами узнали из EVS блога. Он точно также актуален. Ключи демпотентности, которые мы делали с вами в платежах, они нужны для вызова тулов, очередь для медленных задач. Соответственно, все те паттерны, подходы и идеи, которые у нас реализованы в наших бэкэндах, микросервисах, они все точно также нужны для наших агентов. При этом модели заменяемы, и они у нас меняются каждый квартал, а ваш слой, который их ретрает, наблюдает и держит в изоляции, он останется неизменным. Это и есть основная часть работы при построении агента. Поэтому большая часть кода в продакшн агенте - это обычный ээкэнд, написанный по обычным правилам.
У этого слоя сейчас появилось имя harness engженериer, то есть инженерия обвязки. Термин появился в феврале этого года и вёл его Митчел Хашимота. Он у нас сооснователь Хашикорп и создатель Тероформы. И этот термин очень быстро подхватили все игроки. И Open AI, и Антропик. И даже Мартин Фаулер в марте этого года опубликовал синтез того, что эта дисциплина в себя включает.
При этом Харнес - это не просто старый ээкэнд под новым названием. Часть совпадает с тем, что мы с вами, конечно, очень хорошо умеем делать и то, что мы только что обсуждали. Но есть и довольно-таки специфические слои, которых раньше не было. Управление контекстным окном, работа с памятью, политика разрешений вызова тулов, отслеживание прогресса, стратегии compшки пайплайна на критических точках жизненного цикла агента. То есть большая часть - ваши старые навыки, меньшая, но важная часть, это то, что специфично именно для агента. И между прочим, это ровно то, что мы с вами разбираем в серии этих видео. Пайплаine, контекст, тулы, циклы, MCP, Pattern Observer. Это всё было в первой части. Память, работа с рагом, роутинг. Это было во второй части и сейчас безопасность, наблюдаемость в этой самой третьей части. И это всё компоненты Харнес-нженерии.
И отсюда мысль, которая может быть важна тем, кто сейчас смотрит и думает: "Агенты - это какой-то отдельный мир, и я туда вообще не вписываюсь". Прекрасно вы вписываетесь. И ещё как. Антик собирается из двух половин. Одна половина модели, пром инженерие, понимание, как ведёт себя LLM. И это сильная сторона ML и я инженер. Вторая половина - это у нас эксплуатация, отказоустойчивость, наблюдаемость распределённой системы. Это ровно то, что ээкэнд- инженеры делают годами. Так что, если вы синьор бэкэнд и думали, что вы опоздали на этот поезд, совсем наоборот. Ваш опыт сейчас в дефиците, именно там, где собираются настоящие продакшн-агенты. Вам надо только достроить понимание агентской специфики поверх того, что вы уже умеете. И, как мне кажется, это не такая большая часть этой работы.
При этом сильные агентские команды строятся не по принципу: или ML, илинд. Это связка. MLн Инженер отвечает за модель и её поведение инженер Захарнес вокруг. И эти обе компетенции нужны. Сейчас рынок немножко переоценён в сторону модели и часто недооценивает хажс. И я думаю, что это временный перекос. И он сейчас играет в нашу с вами пользу старых ээкэнд-разработчиков. Пока се назвал старый бэкэнт разработчик. Ну о'кей, пускай буду старым ээкэнд разработчиком.
Подробно про Харнес, что в него входит, что специфично для агентов, какие новые слои появились, какие старые получили новую жизнь, разберём в отдельном видео. Тема довольно-таки большая. В один блок она сюда не влезет.
Смотрим ещё раз на то, что разобрали. Выбор между fail cled, fail open и деградацией - это продуктовое решение. Его принимает команда вместе с безопасней. А всё остальное circбрейкеры, ретрай патентности, тайм-ауты, наблюдаемость за провайдерами, маршрутизация. Это всё будет у нас часть нашей харнес-нженерии. То, что спасает систему, когда упал провайдер - это не ваш системный промт агента, это инфраструктура. Агент может сойти с ума, провайдер может лечь, модель может сгаллюцинировать, конекшн может съесть инструкции. Инфраструктура же всё помнит. Это код.
И на этом месте легко успокоиться. Мониторинг мы с вами умеем делать, настраивать бэкэнды на масштабируемость безопасности мы умеем, но при этом нашего агента может быть не видно того, что с ним происходит. И у нас был случай на этот счёт. У нас по метрикам всё хорошо, алёртов нету, но при этом мы заметили, что наш агент стал тратить намного больше денег, потому что старый мониторинг физически не умел видеть, где у агента утекали деньги. И это не единичная дыра такого рода. Есть целый класс провалов, на который стандартный дашборд смотрит и честно говорит: "Всё хорошо, наш тул вернул 200". Но сделал при этом не то. Задача стоит в разы дороже, чем кажется по цене запроса. Или, может быть, у нас агент молча ходит по кругу и делает кучу циклов вообще бессмысленных. Формально, если будем смотреть, всё работает, всё хорошо. По факту наша система уже не работает, она деградировала или, возможно, тратит деньги просто так.
Так вот, агентская наблюдаемость - это не старый мониторинг с новым Вейблом. У агента ломается немножко иначе, чем у стандартных сервисов. И об этом давайте сейчас поговорим. Обзбиabity.
И давайте начнём этот блок с такой мысли, которой я не сразу дошёл. Полностью наблюдаемой системы не существует. Сколько бы мы с вами не закладывали метрик на старте проекта, всё равно будет момент, когда что-то сломается, и ты такое понимаешь: "Блин, точно, а что же мы вот эту метрику не добавили? Её сейчас не хватает, и нам не понять, что происходило". И из этого следует подход. Обзерваability в продакшене - это не настроил и забыл, это постоянный процесс улучшения видимости на основе инсайтов или, возможно, инцидентов. Надеюсь, что скорее инсайтов, чем инцидент. Поэтому каждый раз, когда продукт показывает странное поведение, у нас появляется, возможно, ещё одна метрика или что-то, чем мы можем оценить и посмотреть, почему оно так сейчас происходит, а раньше этого не было. И зрелость команды тут не в том, что всё измеримо с нашего первого дня. Она в дисциплине. достраивать свой наблюдаемости по ходу, а не только на старте, взяв три-четыре goldден метрики и всё у нас наблюдаемая с вами система.
Так вот, давайте разбираться, что же нам мерить, чем мерить и почему без obserability бюджет на lm растёт быстрее, чем мы можем с вами подумать. Обычный сервис - это запрос с понятным жизненным циклом. Пришёл, обработался, ответил, записал статус. Агент устроен немного иначе. Один пользовательский запрос - это цепочка из возможного десятка решений. Классификатор пропускает запрос. Роутер выбирает модель. Рак достаёт документы. LM зовёт тулы. Инструменты возвращают данные. Модель генерит ответ. Securюти проверяет выход. Человек подтверждает действия. Множество стадий. И на каждый что-то может пойти не так. Причём может пойти не так, что финальный статус по-прежнему будет 200. Всё хорошо, мы что-то ответили. Так вот, без трейсинга внутри нашего агента, внутри нашего пайплайна у нас будет с вами чёрный ящик. С трейсингом же каждая стадия видна по отдельности.
Расскажу историю из наших первых попыток в агента. Сразу скажу, у нас была настроенабиility. Этот агент был один из первых, что мы вообще запустили в Продакшн. Что это был за агент? Это был небольшой чат-помощник для сырь инженера во время инцидента. Подсказать, где смотреть, где какие метрики, что как происходит. Для того, чтобы мы могли быстро влиться в инцидент или посмотреть вообще, как работает наша система даже без инцидента. Этот агент работал на довольно-таки простой модели от Openi. И вот в какой-то момент мы решаем, а почему, раз сейчас настолько популярны рининг модели, нам не использовать его. Возможно, качество ответов будет намного лучше, чем обычная модель без ризанинга. И мы успешно переключили этого агента на рининг-модель. И вот мы стали тестировать его на Деве и смотреть, как он себя ведёт, что происходит, какие запросы, ловит инциденты, не ловит инциденты. Было довольно-таки большое тестирование. И вот пока мы с ним игрались, мы заметили, что цифры в графана не сходятся с тем, что у нас есть в API провайдере. Графану мы писали количество сажённых токенов, мы писали туда трейсинг и, соответственно, цену запросов для того, чтобы понимать, сколько мы тратим бюджет. При этом цифры с провайдером не сходились не то что там в какие-то проценты, а в разы. Стали разбираться, в нашем трейсинге токены считались по ответу модели, а в резанинг модели у нас с вами ещё появляются рассуждения. И поэтому всё, что касалось рассуждения, не шло в нашу графану. Мы не считали это как токены, а при этом биллинг от провайдера, он билит одинаково, что ризанинг токены, что токены ответа. При этом мы считали, что это было 300 токенов за ответ, а в ризанинг у нас было ещё десятки тысяч токенов рассуждений. Разница была в 40 раз. Так что хорошо, что мы раскатали сначала это на death stн, стали тестировать. Они повезли это в продакшн, потому что наши бюджеты там намного больше, они не ограничены, как на дестенде, и мы могли просто так спалить деньги, потому что неверно что-то настроили. И хорошо, что мы всё это делали на дефстнде, они в проде. Но мы заметили это глазами. В этом нам, конечно, повезло, потому что если бы мы увидели это через месяц, возможно, для нас было бы неожиданностью то, что наш агент стал кушать намного больше денег. Поэтому дашборд показывал то, что в него собирали, и он это показывал правильно. метрика по сажённым токенам и по деньгам тоже была, но она уже нам врала, потому что считала не всё.
Так вот, обзерватьбилити - это не просто дашборд, это про то, что дашборд показывает реальную картину, а неудобную для нас. Чем же нам с вами всё это мерить? Так вот, в продакшене обзерability - это не один инструмент, это целый слой. Несколько инструментов под разные задачи. Инструментов на рынке полно. Мы можем с вами выбрать то, что подходит именно под наш стек. Хочешь специализированную м-платформу? Есть семейство НМИ или One Fuse. Есть также ещё десятки других Хиликон, Арай и многие другие. Можно выбрать то, что подходит вам или возможно с чем в команде у вас уже было. Если же у вас стоит графа на SKК, то можно собрать прямо на нём. Уже появились LM плагины, во многие языки можно всё это добавить. И по сути мы получим ровно тот же самый мониторинг, что и у тех провайдеров. Трейс по стадиям, метрики, дашборды, алёрты.
А вот дальше то, что в этом стандартном наборе не появится само и где агент действительно отличается от сервиса. Что именно нам с вами мерить? И здесь я не хочу вам давать какие-то goldден метрики, которые поставили, и всё прекрасно. Мы с вами всё видим, потому что любой такой список - это противоречие тому, с чего я начал блог. Обзерваability не закрывается чек-листом. Это постоянный процесс. Продукт или инцидент показывают слепое пятно. И в этот момент мы с вами добавляем новую метрику или решаем, что нам с вами делать вообще с этими новыми данными. Поэтому вместо чеклиста покажу небольшой пример тех метрик, которые совершенно нестандартны для бэкэнда и для множества агент почему-то не используются. Давайте начинать.
Первый Tool call success rate. При этом эта метрика разбита по тулам. Агент вызывает 10 разных инструментов. Может быть поиск, база данных, внешний API, MCP или файловую систему. И у каждой из них будет свой successрей, потому что один тул может деградировать неделями, возвращать не ошибку, а, допустим, пустой результат. Агент в логах при этом будет говорить: "Всё нормально, да, я получил пустой результат, принял решение, куда-то пошёл что-то дальше делать". Но при этом для пользователя, возможно, это будет не самый лучший ответ от нашего агента. При этом общая compition rate ничего не покажет, потому что агент обрабатывает запрос. Он не получил от одного тула, пошёл к другому, пошёл к третьему и, возможно, даже решил задачу. Но мы с вами сожгли намного больше токенов из-за того, что какой-то тул у нас сейчас с вами фейлит. Поэтому как минимум пасфейл или эмти, но лучше к этому всему добавить ещё девяносто пятый перецентиль на йтенсе для каждого тула.
Следующая метрика - плохие циклы. Детекция плохих циклов. Тут я хочу сосваться на конкретную статью из Archive. Команда из ABM Research опубликовала работу про детекшн плохих циклов. Если коротко, агент попадает в цикл, ищет один и тот же документ, не находит, ищет снова с минорным вариантом запроса. Не находит и ищет снова. И каждый вызов будет возвращать 200. Агент немножко будет менять запрос и пошёл, пошёл по кругу искать одно и то же. Вроде всё правильно, улоги чистые, но при этом наш с вами бюджет начинает сгорать. Традиционные метрики этого не увидят, потому что технически всё у нас работает правильно. И авторы предлагают метрику, которая ловит семантическое повторение запросов тула от агента. То есть он ловит серию шагов, которые формально разные, но по сути одинаковые. И это у нас будет не error rate, это у нас будет дистанция в бендинг пространстве между последовательными действиями. Так вот, если эта дистанция падает ниже порога, то мы находимся с вами в цикле, и нам надо с вами с этим что-то делать. И это будет у нас с вами пример метрики, которую ещё полгода назад никто не знал, а сейчас без неё уже не представить хорошего и правильного агента.
Следующее - утилизация контекста. Помните, во второй части мы разбирали compaction. Это фоновое сжатие, история контекста. И в блоке про безопасность мы видели, что такое compaction. Убрал инструкцию не делай ничего, пока я не скажу и удалил кучу писем. Так вот, наш провайдер через API, он не подрезает сам историю, он упрётся в лимиты и выдаст нам ошибку. Так что же мы с вами с этой метрикой делаем? Если процент копекion стабильно высокий и он у нас случается часто, то растёт риск потери критических инструкций и, возможно, падает качество ответов. Как решение можно уйти на модель с большим контекстным окном или, возможно, переработать наши пайплайны и посмотреть, как мы можем с вами снизить наш наше контекстное окно. А вот если наоборот этот процент у нас наоборот стабильно низкий и мы с вами резервируем очень большое контекстное окно и при этом его не используем, то мы с вами за это платим. Если мы используем свои модели, то здесь при уменьшении контекстного окна мы с вами высвобождаем больше памяти под КВш, и на той же GPU у нас будет помещаться больше concurrent юзеров. А вот на внешних API надо изучать, с кем мы работаем. Там окно у нас зашито в модель, но у многих провайдеров за выход, за длинный контекст, допустим, больше 200.000 контекстного окна включается дополнительная наценка, а значит, мы станем платить больше. И значит, нам надо держать утилизацию низкой, и тогда мы не попадём в этот дорогой режим. А если же провайдер нам предоставляет другую или ту же самую модель с меньшим контекстом окном, можем перейти на тир подешевле. Без этой метрики коэкшн у нас с вами будет невидимым процессом, который меняет поведение агента между запросами одного пользователя. И у вас в логах две одинаковые сессии могут отличаться поведением только потому, что в одной успел сработать compкtion, а в другой нет.
Следующее. Качество выбора тулов. Это неуспешно ли вызвали мы какой-то тул, это правильно ли мы выбрали непосредственно тул, потому что от правильности выбора тула зависит качество ответа для нашего пользователя. Как пример, давайте что-нибудь придумаем. У вас есть агент-помощник, и вы его спрашиваете: "Когда у меня будет встреча с моим Тимледом?" И агент идёт в Search Tool по почте, вместо того, чтобы посмотреть в календарь. В почте он нашёл какое-то письмо от Тимледа и на основе него вам выдал ответ. Но этот ответ будет нерелевантен вашему запросу. Соответственно, тул был выбран неправильно. Как же это измерять? Это измерять через отдельную модель. То есть мы будем оценивать качество ответа и смотрим, какие были вызваны модели на основе того, пользователь может был недоволен ответом. Нажал, что мне не понравился ответ, и мы можем рассмотреть, что же там произошло. Или на тестовых данных мы можем с вами на синтетических данных проверять, правильно выбирать наши модель ТУ или неправильно, на большом объёме запросов, сформированных на основе запросов наших пользователей.
И последнее - стоимость решения задачи. И она отличается. Это не стоимость конкретного запроса КЛМ-модели, потому что мы должны с вами смотреть не то, что вот вызвали, стоит 1 цент, о'кей. Но ведь у нас пользователь, который работает с нашим агентом, часто задаёт множество запросов или агент, пытаясь выполнить какую-то задачу, делает много циклов. Поэтому агент внутри одной задачи может сходить в модель множество раз, десятки раз, 20 раз, 30 раз, делать какие-то ретраи, попасть в какие-то циклы. Поэтому нам надо с вами оценивать именно coste. Это будет метрика, сумма стоимости всех вызовов в рамках одной законченной задачи. То есть у вас должен быть концепт сессии или задачи в вашей системе отслеживания того, как работают агенты. Если же этого нету, то будет очень тяжело оптимизировать затраты и понять, где и что происходит не так. И даже уже есть отчёты, где эту метрику называют самой нужной и критической для агентов и самой часто пропускаемой метрикой в индустрии.
И это пять нестандартных примеров. У вас может быть три, может быть восемь, может вы добавите какие-то свои метрики. Дело совершенно не в количестве, дело в подходе. Если у вас случился инцидент и вы поняли: "Так, у нас чего-то не хватает". Смогли понять, как это измерить, добавили эту метрику, всё хорошо. Если же вы не работаете постоянно с Observability, то вы упускаете вашу систему, и она становится неконтролируемой и ненаблюдаемой. Поэтому это дисциплина непрерывного спрашивания, что я сейчас не вижу и что мне это будет стоить в будущем.
Как пример, возьмём опять нашу уже избитую со всех сторон Кларну. Она в двадцать четвёртом году хвалилась и яй закрывают работу эквивалента 700 сотрудников. Они там 40 млн долларов экономии в год говорили, а в мае двадцать пятого уже признались. К сожалению, заменить людей целиком невозможно. Это было слишком агрессивно. И качество у нас упало, и мы набираем людей обратно. Вот к чему они пришли. Возможно, они смотрели не на те метрики. Может быть, они смотрели метрики по закрытым тикетам. Может быть, смотрели количество тикетов в час или скорость закрытия этого тикета. Не знаю, может быть, сат - это метрика удовлетворённости клиентов, не измерялась у них относительно агентов и относительно людей. Они её не сверяли. А может быть, они не мерили метрику NPS, то есть готовность рекомендовать этот сервис другим. Скорее всего, эти две метрики первыми поехали совершенно не туда, когда они решили внедрять полностью агентов за место людей. Так вот, если бы Кварна на них смотрела внимательно, может, конечно, смотрела, я же не знаю. Ну, моё предположение, может быть, они не попали бы в ситуацию, когда они всех уволили, а потом всех наняли, и теперь часто можно услышать: "Давайте не сделаем так же, как в кварна".
Помните третью историю с самого начала вида про падающие цены и растущие счета? Давайте разберём, почему это так происходит. Есть парадокс Джевенсон. Это английский экономист X века. И он заметил, когда паровые машины стали эффективнее жечь уголь, потребление угля выросло, а не упало. Дешёвая энергия запустила новые сценарии, которые раньше были невозможны. Уголь подешевел в пересчёте на единицу работы, но работа стала делаться в 10 раз больше. Итог суммарного угля сожгли больше, чем до удешевления. Цм происходит то же самое. Hi медиана падения цены на токен 50 раз в год до января двадцать четвёртого года, после до 200 раз в год. Цены за токен реально валятся как ракета. И для этого феномена даже придумано отдельное слово LMF по аналогии с инфляцией. Только наоборот. Тоже качество дешевеет в 10 раз каждый год. А что у команд со счетами? Menлавенчес в декабре двадцать пятого опубликовали отчёт, по которому видно, что счета растут в несколько раз каждый год. То есть не на 20%, не на 30, не в полтора раза, а в три раза и больше.
Так вот, почему так получается? Агенты потребляют намного больше, может быть, в 15 раз больше токенов, чем это делает простой чат. Резанинг модели могут потреблять невероятное количество токенов при решении своих задач. Так вот, цены падают, потребление растёт и, соответственно, расходы растут. И в связи с тем, что количество сжигаемых токенов у нас невероятно растёт, observability становится невероятно важным для того, чтобы мы могли наблюдать всю нашу систему, чтобы мы могли видеть каждую точку, где что происходит, где мы сжигаем токены. И тогда мы можем ставить новые гипотезы, проверять модели, проверять-тестирование, что стало лучше или, наоборот, стало хуже, и делать наших агентов эффективными не только с точки зрения решения задач, но и с точки зрения количества сжигаемых токенов и цены.
И на этом технический арсенал нашей третьей части целиком собран. Помните, с чего мы с вами начали? Что внутри нашего агента, который мы обсуждали в первой серии наших видео. И за эти видео мы построили большую модель, где каждый компонент понятный, тестируемый и заменяемый. И это не про конкретный фреймворк, это про архитектурное мышление. Когда вам в следующий раз покажут очередной фреймворк, теперь вы знаете, какие вопросы задавать и на что смотреть для того, чтобы делать по-настоящему продакшн системы, потому что технологии меняются, а принципы нет. И все те же самые fail of fast, single responsibility, защита в глубине, keep it simple и многие другие инженерные принципы как работали до агентов, так будут работать и после агентов. И очень важное, не забывайте, что код - это не промт, где граница может потеряться в контексте, а гарантия нужна под нагрузкой, и место будет не в промте, а в коде или в инфраструктуре. Промт можно сжать, изменить, процитировать ровно перед тем, как его нарушить. Код же нельзя.
Что будет дальше? Дальше будет четвёртая часть про тестирование агентов и про деплоймент. Подписывайтесь и не пропустить.
И последнее. Помните наши истории про то, как агент стёр письма или как он удалил полностью покетос? Также Кларна, у которой зелёные метрики по объёму скрывали падение качества. Помните это? Never fucking gress, которое агент процитировал свои исповеди, но шикарно нарушил. Это всё произошло за последние полгода. И возможно через год этого будет в 10 раз больше. Постмортомы будут писать каждую неделю, и ваша задача - не оказаться в одной из этих историй. Поэтому не делайте демо, делайте настоящий продакшн. Удачи. Пока.