Кстати, я думаю, что все заметили, что Apple не юзает базворды в своих презах и других продуктово-маркетинговых материалах, а также дает любой своей фиче отдельное название типа Retina Display, True Motion, Face ID и прочее, а не просто говорит дисплей с 120гц и камера с 100500 мегапикселей. Особенно, это бросается в глаза после последней Google I/O, где зашкаливал счетчик упоминания AI.

У Маркуса как раз вышел видос вчера про это. https://youtu.be/kvN5_GXlg2Y
Marketing 101, который среди гигантов мало кто применяет, кроме Apple.

Прочитал тут у Данилова пост. Не могу не прокомментировать.

Многие продакты не понимают, что MVP это не продукт вовсе, а, по сути, способ собрать максимум знаний за минимум усилий и времени и запустить фидбек луп. Тут даже не про продукт речь, а, скорее, про процесс. Я не очень понимаю, почему все считают, что MVP это какой-то сарайный и забагованный продукт. Видимо, как и в случае с Customer Development, надо книжки в оригинале читать.

В оригинале Эрик Рис в книжке Lean Startup пишет следующее:
«Once clear on these leap-of-faith assumptions, the first step is to enter the Build phase as quickly as possible with a minimum viable product (MVP). The MVP is that version of the product that enables a full turn of the Build-Measure-Learn loop with a minimum amount of effort and the least amount of development time. The minimum viable product lacks many features that may prove essential later on. However, in some ways, creating a MVP requires extra work: we must be able to measure its impact. For example, it is inadequate to build a prototype that is evaluated solely for internal quality by engineers and designers. We also need to get it in front of potential customers to gauge their reactions. We may even need to try selling them the prototype, as we’ll soon see.».

Никакой речи про баги и плохое качество. Речь про то, что нужно начать собирать данные, как можно раньше, за минимальные затраты, а для этого надо отказаться от функционала, а не качества, как многие думают.

Кажется, что всем должно быть очевидно, что запущенный фидбек луп, где основными полученными знаниями будут те, что говорят, что ничего не работает, особой ценности не представляют. Так и зачем такой фидбек луп?

Потыкал в Threads от Цукера. Посмотрел на цифры их запуска в США. Twitter, похоже, R.I.P. Будет уникальный случай, когда СЕО самодур угробил бизнес стоимостью в несколько десятков миллиардов баксов, защищенный 2-мя самыми сильными силами: network effects и брэнд.

Поясню за пост выше. Я не считаю, что Threads убьет Twitter, если не использовать гиперболы в речи. Прежде чем перейти к анализу запуска и формированию каких-то предсказаний, нужно понимать следующие предпосылки:
- Facebook теряет добавленную ценность из-за наличия и появления более узких решений. Это судьба любого большого решения: растешь в ширь, но в конкретной нише более узкие решения генерируют больше добавленной ценности. Это одна из причин, почему Цукерберг покупал WhatsApp и Instagram.
- TikTok очень сильно забрал аудиторию у Instagram, но Instagram это отвоевал и очень сильно вырос за счет рилсов.
- СЕО Instagram сказал, что они слишком сильно сфокусировались на рилсах, поэтому снова сместят фокус на фотографии.
- TikTok могут закрыть в США.
- Аудитория Meta сильно пересекается с твиттерской, и по сути люди потребляют/генерируют контент в твиттере, а могли бы в Facebook/Instagram.
- Facebook пытался когда-то обуздать нишу твиттера, но не очень удачно.
- У твиттера крайне хреновая монетизация и неэффективные механизмы рекламы, что приводило к тому, что большая часть рекламы в твиттере была брендовой, а отчеты показывали, что самих брендов там тусовалось немного, если сравнить с другими рекламными площадками. Думаю, что те, кто хоть раз закупался в твиттере, поймут, о чем я.
- У Facebook крайне мощные и эффективные рекламные механизмы, и с монетизацией все тоже отлично.
- У твиттера исторически проблемы с огромным количеством анонимов, ботов, плохой модерацией и токсичностью, что также влияет на рекламные бюджеты, так как никто не будет продавать что-то ботам и токсичным анонимам.
- У твиттера есть проблемы с инфлюенсерами, публичнымиличностями, зумерами и подобной аудиторией, как раз из-за проблемы выше.
- После прихода Маска у твиттера оттекает аудитория, либо не оттекает, но бурлит.
- После прихода Маска у твиттера проседают рекламные доходы из-за оттока брендов. Это одна из причин, почему они наняли новую СЕО Линду Яккарино из NBCU, чтобы вернуть бренды. А когда у тебя и так рекламодателей немного, то уход каждого наносит очень сильный удар.

И что делает Цукерберг? У меты сильные сетевые эффекты. Они сделали один аккаунт на все сервисы, взяли эту аудиторию и дали им продукт, который решает кокретную задачу: писать короткие публичные сообщения, как в твиттере, и обсуждать это со своей аудиторией. То есть эта аудитория уже тусила в Facebook, общалась в Facebook/WhatsApp, смотрела/снимала фотографии и видео в Instagram, а потреблять/генерировать контент типа твитов уходила в твиттер, либо пыталась для этого использовать не самый удобный для этой задачи Facebook или Instagram.

В первую очередь это продукт для уже существующей аудитории, чтобы увеличить их вовлеченность и время, проведенное на платформе, используя существующие сетевые эффекты. А уже потом переманивание активной аудитории твиттера, но не всей, а только той, что ложится в вижн тредов: никаких токсиков, ботов, анонимов, контента для взрослых и прочего.

Взлетит ли? Я не знаю, но могу сказать, что у цукера есть больше возможностей, чем у остальных, и в целом достаточно инструментов и возможностей, чтобы это получилось, плюс очень удачно подобранное время (скандалы, из которых не вылезает твиттер после прихода Маска). Плюс мне понравилось, как реализован и запущен продукт. Но есть и много причин, почему оно может не взлететь, но про них в другой раз.

ЧТД. Apple пилит свою LLM

https://www.bloomberg.com/news/articles/2023-07-19/apple-preps-ajax-generative-ai-apple-gpt-to-rival-openai-and-google?sref=l3J6d079

Захотел приобрести док станцию с thunderbolt и прочими портами, чтобы можно было на столе все втыкать в одну штука, а оттуда один кабель в макбук. Все ютюберы, которых видел, советуют, как один, вот эту штуку. Единственный вариант, который искал и подходит мне полностью. Но есть нюанс!

Человечество, конечно, сотворило много плохих вещей, но чем оно заслужило реальность, в которой гребаный хаб для шнуров стоит, как Plastation 5 или iPad Mini, на R&D которых потратили млрды долларов, мне не понятно.

P.S. Да, я в курсе, что консоли продаются с отрицательной маржой, и производители зарабатывают на отчислениях от продажи игр, но суть не в этом.

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

Tldr: теорема Эскобара.

https://twitter.com/esthercrawford/status/1684291048682684416?s=46

И снова LLM. 
 
После появления ChatGPT появляется много тулов на основе LLM, которые позволяют людям без технических навыков юзать соответствующие инструменты. Вектор развития логичен и очевиден. Часто это касается кодинга, SQL и подобных вещей. Идея прекрасная, конечно, и надеюсь, что увидим, когда большую часть технических навыков нам заменит AI, и будем тратить время на творчество, а не на утилитарное ремесленничество. Но есть нюансы!
 
У GPT сильный навык крайне уверенно нести полную ерунду, которая для человека без знания предметной области будет звучать весьма валидно. А теперь представьте, что вы не знаете SQL, и попросили условный «Analytics Copilot» посчитать какую-то метрику и построить графики. За этот Copilot, естественно, радостно заплатили условные 100 баксов в месяц, чтобы не нанимать аналитика за 3к баксов в месяц. SQL валидировать вы не сможете, так как не знаете его, LLM может легко сделать валидный и работающий запрос в базу, вы даже увидите метрики и они тоже могут не вызывать подозрений, графики будут выглядеть очень классно, примете на основе этих данных какие-то решения, заспичите начальству стратегические bets, соберёте бюджет, команду, whatever. А потом бац, и узнаете, что данные вообще неправильные, а, может, не узнаете вовсе.

Сингулярность продолжается.

Похоже, что придумали сплав, который при комнатной температуре (я так понял ~30 градусов Цельсия и <127) и обычном атмосферном давлении демонстрирует сверхпроводимость. Сначала об этом корейские ученные сказали, теперь, получается, лабы в Канаде и Китае смогли воспроизвести этот сплав и эффект. Сплав при этом банально свинец и медь.

https://twitter.com/Andercot/status/1686805961124855810?s=20

Вот здесь и здесь объясняется, почему это колоссальное открытие для всего человечества.

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

Если что, это не я

Я думаю, что все уже видели выступление Brian Chesky (CEO и основатель AirBnB), где он накидывал на продактов. Правда, много где его слова вообще неправильно интерпритировали, но суть не в этом.

Он озвучил один резонирующий тезис, мимо которого тяжело пройти — они сильно сократили количество A/B тестов и экспериментируют только, если у них есть гипотеза и четкое понимание, чем B лучше A. Кажется, что крайне простая и логичная вещь, зачем такая категоричность? К чему такой пафос? Но если задуматься, то можно в словах Брайна разглядеть боль, которая, вероятно, является следствием повально распространенной в индустрии заразы: куча продактов запускают рандомные эксперименты, не имея никакого вижна, стратегии, четкого плана, диагностики причино-следственных связей в препятствиях на пути к цели и т.д. Что будет делать человек, у которого стоит OKR/KPI, который хочет получить промо на ревью, но понятия не имеет, как достичь цели? Правильно, он начнет работать в режиме генератора случайных чисел в надежде, что парочка из десятка экспериментов сработают.

И тут я глянул недавний подкаст Lenny c глыбой A/B тестирования - Ronny Kohavi, где он рассказал, что в AirBnB Fail Rate экспериментов 92% и это с отрывом самый большой рейт, который доводилось ему видеть. Да и мне тоже. К примеру, у нас в Юду Win Rate давно перевалил за 50% и даже выше. Кажется, моя гипотеза подвердилась — у Брайна ПТСР.

С другой стороны, чаще всего у продактов/команд на местах не бывает четкой стратегии и понимания, что делать, когда этого понимания нет и у продукта/компании в целом, а ее наличие является фундаментом для успешных тактических действий на местах. Если посмотреть на последние release events AirBnB, то может показаться, что с этим у них как раз проблемы, и ребята запутались в собственных редизайнах.

Ну а как описывать правильные гипотезы и не наносить психологические травмы вашему руководству, я рассказывал ранее в рамках цикла постов про «Hypothesis Framework»: часть 1, часть 2, часть 3.

Спотифай анонсировал паблик релиз своей платформы для экспериментов — Confidence. У ребят очень развитая культура экспериментирования, и это не первый их внутренний продукт, который выкатывают в паблик (luigi, annoy, backstage и прочие), поэтому есть все шансы, что будет хорошая поддержка, как со стороны самого Spotify, так и плотная работа с коммьюнити.

Сам факт того, что выкатывается именно платформа для экспериментов очень примечателен, ибо обычно такие штуки крайне специфичны для внутренних потребностей и их тяжело вытаскивать в OS. Я припомню только Planout от Facebook, но это не платформа, а либа для описания экспериментов и стратегий сплита трафика.

У нас своя платформа для А/Б тестов — Хьюстон, но если так пойдет, то есть большой confidence, что скоро кораблями будут управлять в другом месте. К тому же, мы еще не реализовали Sequential тестирование, а у Spotify оно уже в проде. Надеюсь, что в OS версии платформы оно будет.

Пока можно записаться на private beta.
https://engineering.atspotify.com/2023/08/coming-soon-confidence-an-experimentation-platform-from-spotify/

Будет 3 версии:
- Managed service
- Плагин для Backstage (платформа от Spotify для построения developers portal)
- Сервис с API деплоящийся в вашу инфру

Еще у них клевый инженерный блог, если кто не видел, и, в частности, статьи про их культуру эксперементирования https://engineering.atspotify.com/tag/experimentation/

Один из важнеших принципов при проектировании фич — учет и обдумывание различных кейсов, а не проектирование под средний или идеальный сценарий использования. Обычное дело, когда дизайнер проектирует интерфейс на 5к IPS откалиброванном монитере и начинает с веб версии под максимальное разрешение, а большая часть юзеров открывает ваш сайт на андроиде с мелким экраном и 3g интернетом в метро. Продакт при этом всегда пользуется собственным продуктом на iPhone 14 Pro Max и макеты просит рисовать под него же.

Вот и ребята с Озон, наверняка, делали пуш рассылки для тех у кого много бонусов, но я оказался тем самым отщепенцем, который не вписался в идеальный случай.

Ваши A/B тесты недостаточно эффективны. Часть 1.
Предпосылки

Любой курс или статья про эксперименты учат, что нужно заранее рассчитать длительность теста и смотреть на итоговые метрики только по прошествии этого количества времени. Это попытка решить проблему подглядывания (peeking problem). Суть этого явления заключается в том, что если раскатывать тесты, как только словили статистически значимые изменения, то завышается ошибка первого рода.
 
С этой неоптимальностью мониторинга p-value индустрия предлагает бороться двумя способами:
- Fixed-horizon testing
- Sequential testing
 
Sequential тестирование подразумевает, что можно следить в near-real-time за ходом эксперимента и принимать решения, как только случаются прокрасы. Всё благодаря концепции "always valid p-value". Проблема подобного подхода в его сложности. Простые алгоритмы Sequential тестирования годятся для каких-то базовых метрик с биномиальным распределением, таких как конверсия. Более сложные метрики с непрерывным распределением или, например, ratio метрики, требуют более сложных подходов, таких как mSPRT, GST, GAVI и прочие. Для них необходимо детальное моделирование как самих метрик, так и подготовки и настройки алгоритмов с помощью симуляций, А/А тестов и прочих механизмов защиты от ошибок. А теперь представьте, что вы гоняете десятки и сотни экспериментов с десятком или сотней разных метрик.
 
Fixed-horizon testing - это как раз тот случай, когда мы заранее считаем длительность теста и не останавливаемся, пока не наберём нужную выборку. Этот подход пришел из медицины и подобных дисциплин, где нужно было расчитать количество необходимых участников исследования. В большинстве статей, которые я видел, говорится о длительности теста, когда на самом деле нужно считать размер необходимой выборки (формула расчета при использовании t-критерия в первом комментарии поста). Если вы считаете длительность теста по историческому DAU/WAU/MAU, то можете попасть в ловушку того, что во время эксперимента у вас изменятся показатели из-за сезонности, внешних изменений, включения/выключения маркетинга и по факту получите другой размер выборки за проведённые дни экспериментов. Может быть ситуация, когда у вас будет выборка больше, чем надо, а может быть и меньше. Последний кейс опасен, ибо с полной уверенностью избегания проблемы «подглядывания» в неё же и наступим.

Итого, нужно считать размер необходимой выборки, но с этим тоже есть проблема, ведь при расчёте размера выборки, используются как среднее метрики, так и дисперсия. За какой период надо их считать? Что делать с кумулятивными метриками типа ARPPU? На какой выборке? Ведь в эксперименте будет selection bias, ибо в эксперимент чаще всего попадает только часть вашей аудитории, а если, к примеру, делаете тест на мобильном устройстве, то там будет накладываться селекция релиза новой версии приложения и динамика обновления аудитории на него.
 
Но это детали, которые можно разрешить, а мякотка в другом – MDE. Чтобы посчитать размер необходимой выборки, нужно задать уровень допустимой ошибки первого рода, уровень мощности и MDE. И тут вопрос: какой MDE? Теоретически, можно прикинуть потенциал нашего изменения. Например, когда решили улучшить какую-то часть воронки, то во время исследований, поняли, что X% аудитории сталкиваются с каким-то неудобством, придумали решение, устраняющее его, поняли, насколько может улучшиться наша конверсия. Проблема в том, что решение может быть неидеальным, и эффект будет ниже потенциала. Насколько? Еще вспомним, что куча продактов и продуктовых команд проводят эксперименты несистемно, без последовательной стратегии и ресерча. Представим, что задали MDE 10%, рассчитали, что нужно 10к людей в эксперименте, а по факту наш эффект составил 9% на необходимой по размеру аудитории. Что делать?

Ваши A/B тесты недостаточно эффективны. Часть 2.
Продолжение предыдущего поста

Прежде чем перейти к каким то практикам, нужно понять от первых принципов фундаментальный источник проблем.

Вся суть "peeking problem" не в том, что мы подглядываем, ибо это не квантовая физика с ее эффектом наблюдателя, это не кот Шредингера и не какая-то магия, где от самого факта "подглядывания" может измениться объективная реальность. Проблема возникает именно тогда, когда мы принимаем решение, когда видим первый прокрас, который с большой вероятностью случаен.

Вы когда-нибудь запускали сломанные эксперименты, которые роняют ваши метрики? Согласитесь, никто не хочет узнать 2 недели спустя, что конверсия в оплату упала вдвое, или что код не триггерит нужное событие, которое необходимо для расчета метрики. Вы не узнали об этом раньше, потому что дядя с курса по А/Б-тестам или спикер с uber growth конференции сказали, что подглядывать нельзя. Только проблема в том, что ваши бизнес-потери он не компенсирует. С другой стороны, представьте, что метрика красится стабильно в течение 7 последних дней из 14, но для проведения теста требуется 18 дней. Какова вероятность того, что на 18-й день прокрас исчезнет? Это легко проверить симуляцией.

На мой взгляд, подобный пайплайн (считаем размер необходимой выборки, гоняем, пока не соберем её, смотрим на метрики и принимаем решение) далек от практической эффективности и, страхуя нас от рисков. создает кучу лишних проблем.

Как поступать проще? В следущем посте мои рекомендации.

Ваши A/B тесты недостаточно эффективны. Часть 3.

часть 1, часть 2

Рекомендации:
• Мы в юду держим тесты минимум 14 полных дней, чтобы учесть минимум 2 полных недельных цикла, так как продукт сильно подвержен недельной сезонности. Изменения в продукте часто имеют эффект новизны и могут на первой неделе давать спайк лифта как вниз, так и вверх. Так же минимальное ограничение по времени позволяет застраховать нас от флуктуаций метрик в первые дни теста на малых выборках.
• Длительность теста не должна превышать 4 полные недели, так как в таком случае мы слишком сильно забиваем квоту экспериментирования. Если изменение нельзя измерить за 4 недели и меньше, то, скорее всего, это что-то незначительное, и мы занимаемся чем-то не тем. Исключения могут быть, и на них нужно идти сознательно. В каждом продукте могут быть свои особенности, поэтому цифра может отличаться, но сам принцип сохранится.
• Проводить эксперименты нужно полными недельными циклами. Имеем 2, 3 или 4 полные недели в нашем случае.
• До эксперимента выбираем ключевые (target) и контр (guardrail) метрики, как описывал в постах про работу с гипотезами, а также статистические пороги значимости (не менее 95%) и мощности (не менее 80%). Также не забываем корректировать порог значимости при множественном сравнении.
• Так как длительность теста имеет фиксированный набор, то мы можем на исторических данных прикинуть, учитывая все особенности проведения эксперимента и точку exposure, сколько примерно может быть людей в эксперименте, и посчитать для выбранных метрик, какой MDE при какой длительности будет. Рассчитываем по той же формуле, что и размер выборки, но в уравнении неизвестным становится именно MDE. К примеру, мы делаем эксперимент на форме регистрации в мобильном приложении, поэтому мы должны рассчитать динамику адопшна новой версии апа и аудитории, которая попадает на эту форму. Понимаем, сколько примерно людей будет за 2, 3 или 4 недели, считаем MDE, и в итоге имеем линейку длительность-MDE.
• Задаемся вопросом: «Верим в достижимость такого uplift?». Или наоборот: «Достигаем ли мы необходимого результата за приемлемое время?». Вряд ли мы захотим держать тест 4 недели ради мизерного uplift и вряд ли поверим, что за это время наше небольшое изменение способно показать 25% uplift.
• Во время эксперимента трекаем кумулятивно p-value и смотрим на его динамику по дням (пример на первом изображении в комментах к посту).
• Следим за фактическим MDE (изображение 3 в комментах к посту, формула MDE для случаев групп разного размера и разной дисперсии при использовании t-критерия). Он более точный, чем рассчитанный MDE до эксперимента, так как на вход подаются фактические средние контроля, дисперсии и размеры обеих групп сравнения.
• Если прокрас отсутствует, но мы видим lift, то значит, что если изменение и есть, то оно меньше MDE.
• Если прокрас есть, но lift меньше MDE, то смотрим на его стабильность. Если прокрас единовременный, то скорее всего случайный, и нам лучше подержать тест для увеличения размера выборки ради снижения MDE и повышения мощности, если мы можем себе это позволить. Если прокрас нестабильный и не пробивает MDE, то значит, что мы находимся в флуктуациях p-value и нужно ждать либо стабилизации прокраса, либо пересечения порога MDE. Иначе мы рискуем завышением ошибки первого рода выше заданного нами порога.
• Если прокрас есть, он стабильный по дням (повторяется несколько дней подряд и не прекращается), но не пробивает MDE, то можем принимать изменение, ибо наши симуляции показали, что вероятность ошибки первого рода не растет, но ожидание пересечения порога MDE сильно понижает мощность.
• Если прокрас есть и пробивает MDE, то все четко.

Очень люблю и уважаю JTBD. Это одна из вещей, которая должна быть базой для продактов. Мы на постоянке используем Job Stories, они создают удобство категоризации и быстрого осмысления потребности пользователя и выполняемой работы, но не позволяют достаточно четко и глубоко сформировать их суть, поэтому кому то могут показаться карго культом. Новый взгляд Клемента нравится сильно больше.

JTBD по Клементу в 23 году

Алан Клемент опубликовал Pdf с описанием своего ноу-хау по валидации гипотез продуктов. Можно считать это демо-версией книги, которую он пишет уже 5й год. Я вникаю, но поделиться и обсудить уже хочется.

На картинке пример описания работы. Никаких вам Джоб сторис и стейтментов. Таблица, которая описывает многосоставную потребность пользователя через несколько аспектов мотивации: Желаемые изменения, Катализаторы и неведомая для меня сущность Key Affordances, через которые человек пытается понять будет ли продукт справляться с работой.

Интересно, что последние года полтора на своих курсах я тоже говорю про многосоставные потребности и их описание через похожие сущности, а Джоб стори / работы призываю использовать, как теги для из обозначения.

Наткнулся на интересный кейс эффекта ноцебо при приеме антидепрессантов. Ноцебо, если кто не знает, это как плацебо, но когда вызывается негативный эффект.

В общем, женщина, которая участвовала в слепом рандомизированном исследовании лечения депрессии и была в группе с плацебо, хотела убить себя приняв 26 таблеток этого антидепрессанта, как она думала. Ее госпитализировали в критическом состоянии, у нее было крайне низкое давление, несколько часов откачивали, но потом ей сказали, что это было плацебо и она резко пришла в себя.

https://www.sciencedirect.com/science/article/abs/pii/S0163834307000114

Product Development 2.0: копилоты на ИИ в продуктовых командах. Видение от майкрософт

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

В команде разработчиков, которой помогает второй пилот, ИИ станет основой жизненного цикла разработки продукта, повышая гибкость разработки за счет управления процессами и минимизации ошибок. Традиционные спринты станут короче, а Co-Pilots будут проводить непрерывную аналитику рынка и использования, чтобы упростить планирование до написания кода, уменьшая потребность в нескольких встречах и помогая людям сосредоточиться на творчестве и социальном взаимодействии. Показатели успеха продукта по-прежнему будут зависеть от удовлетворенности клиентов и адаптации пользователей, но мы увидим новые показатели продуктивности команды, такие как взаимодействие человека и второго пилота, автономность выполнения задач, обучение второго пилота и точность.

https://medium.com/data-science-at-microsoft/the-era-of-co-pilot-product-teams-d86ceb9ff5c2

Тут я замечу, что агенты которые натренированы быть связующим звеном между промтом и кодом/продуктовым дизайном - это интересная часть общей тенденции к гиперавтоматизации процессов и продуктов. Авторы даже приводят какое-то исследвоание: https://arxiv.org/abs/2304.03442

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