{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Product × Science: заметки с тегом ИИ",
    "_rss_description": "Заметки про проектирование, исследования и данные. Делюсь опытом и рассказываю как с их помощью создавать сложные технологические продукты. Автор — аналитик, разработчик и исследователь с опытом создания сервисов с многомилионной аудиторией.",
    "_rss_language": "ru",
    "_itunes_email": "martsen.anton@yandex.ru",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/pxs.md\/pictures\/userpic\/userpic-square@2x.jpg?1768130329",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/pxs.md\/tags\/ai\/",
    "feed_url": "https:\/\/pxs.md\/tags\/ai\/json\/",
    "icon": "https:\/\/pxs.md\/pictures\/userpic\/userpic@2x.jpg?1768130329",
    "authors": [
        {
            "name": "Антон Марцен",
            "url": "https:\/\/pxs.md\/",
            "avatar": "https:\/\/pxs.md\/pictures\/userpic\/userpic@2x.jpg?1768130329"
        }
    ],
    "items": [
        {
            "id": "24",
            "url": "https:\/\/pxs.md\/all\/willingness-to-delegate\/",
            "title": "Готовность делегировать цифровому ассистенту",
            "content_html": "<p>В <a href=\"https:\/\/pxs.md\/all\/ux-metrics-guide\/\">гиде по UX-метрикам<\/a> я писал, что показателей много, но есть ограниченный набор сущностей, которые интересны для замера с точки зрения дизайна и продукта. Похоже, с развитием ИИ-помощников на сцену выходит новая концепция — готовность человека делегировать выполнение и\/или принятие решений цифровому ассистенту.<\/p>\n<p>В работе <a href=\"https:\/\/dl.acm.org\/doi\/10.1145\/3544549.3585763\">Expectation vs Reality in Users’ Willingness to Delegate to Digital Assistants<\/a> создается модель «готовности делегировать»: определены основные «переменные» и причинно-следственные связи.<\/p>\n<p><i>Исследование опубликовано в начале 2023г, поэтому часть тезисов выглядят банальными, а рекомендации устаревшими, но все еще злободневно даже три года спустя.<\/i><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/willingness-to-delegate-concept.png\" width=\"2160\" height=\"1215\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Теоретическая модель на основе изученной литературы<\/div>\n<\/div>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/conceptial-model-of-willingness-to-delegate.png\" width=\"2160\" height=\"1215\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Модель на основе проведенного исследования и применения математического аппарата<\/div>\n<\/div>\n<h2>Ключевые тезисы и рекомендации<\/h2>\n<p><b>Завышенные ожидания пользователей от ассистентов<\/b><\/p>\n<ol start=\"1\">\n<li>Чем проще работа с ассистентом, тем выше желание делегировать ему задачу (или как минимум попробовать)<\/li>\n<li>При этом, чем больше человек пробовал работать с агентами, тем меньше желание делегировать (видимо, столкнулся с негативным опытом и понял ограничения)<\/li>\n<\/ol>\n<p>Выводы отсюда очевидные: работать над качеством, менеджить ожидания, более сдержанно давать обещания<\/p>\n<p><b>Процесс работы ассистентов не прозрачен, а контроля практически нет<\/b><\/p>\n<p>Чем важнее задача, тем меньше желание делегировать. Так как нет доверия к системе, то и делегировать «субъективно рисковые» задачи не хочется. Даже если пользователь думает, что агент мог бы быть полезен.<\/p>\n<p>Чтобы повысить шанс допуска агентов к более сложным задачам со стороны юзера, нужно:<\/p>\n<ol start=\"1\">\n<li>Определить сценарии, где людям нужен больший контроль.<\/li>\n<li>Бить критичные задачи на подзадачи, объяснять что будет сделано, дать контроль порядком шагов и их наполнением<\/li>\n<\/ol>\n<p><b>Полезность ассистентов возрастает, когда человеку сложно выполнить задачу, но при этом увеличивается и субъективная сложность работы<\/b><\/p>\n<ol start=\"1\">\n<li>Используйте ситуации, в которых пользователям сложно выполнить задачу без посторонней помощи, например, когда у них заняты руки или они не видят экран, чтобы продемонстрировать преимущества помощника.<\/li>\n<li>Сделайте взаимодействие в таких ситуациях ещё проще<\/li>\n<\/ol>\n<p><b>Частотность сценариев работы ассистента не связана с субъективной полезностью, но повышает доверие к системе<\/b><\/p>\n<p>Например, пользователи не доверяют ИИ в вопросах, связанных со страховыми случаями, хотя в этом случае ассистенты кажутся полезными. Пользователи доверяют роботам в вопросах информации о погоде, но это не самый полезный сценарий.<br \/>\nСортировать беклог только по частотности сценария выглядит не самым разумным подходом.<\/p>\n<h2>Ссылки<\/h2>\n<ol start=\"1\">\n<li><a href=\"https:\/\/youtu.be\/Lgk2bBXRnsQ?si=vEA8_ciN9BwEChSu\">Краткая видео-презентация<\/a> и <a href=\"https:\/\/drive.google.com\/file\/d\/1DO2d0PtnxUbZougAK8U8JSkgMwlcqnia\/view?usp=drive_link\">слайды<\/a><\/li>\n<li><a href=\"https:\/\/dl.acm.org\/doi\/10.1145\/3544549.3585763\">Научная работа<\/a><\/li>\n<li><a href=\"https:\/\/sea94.github.io\/\">Сайт автора работы<\/a><\/li>\n<\/ol>\n",
            "date_published": "2026-01-19T10:31:58+03:00",
            "date_modified": "2026-01-19T12:31:06+03:00",
            "tags": [
                "HCI",
                "ИИ",
                "Исследования"
            ],
            "image": "https:\/\/pxs.md\/pictures\/willingness-to-delegate-concept.png",
            "_date_published_rfc2822": "Mon, 19 Jan 2026 10:31:58 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "24",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/willingness-to-delegate-concept.png",
                    "https:\/\/pxs.md\/pictures\/conceptial-model-of-willingness-to-delegate.png"
                ]
            }
        },
        {
            "id": "1",
            "url": "https:\/\/pxs.md\/all\/embodied-ai-eai-safety\/",
            "title": "Конспект лекции про Embodied AI (eAI) Safety",
            "content_html": "<p class=\"lead\">Конспект лекции от Фила Купмана<\/p>\n<p>Чтобы охватить надежность «воплощенных» ИИ-систем с разных сторон, нужно разобраться в четырех областях:<\/p>\n<ol start=\"1\">\n<li>Системная безопасность \/ теория надежности<\/li>\n<li>Кибербезопасность<\/li>\n<li>Машинное обучение \/ искуственный интеллект<\/li>\n<li>Человеко-машинное взаимодействие (Human-Computer Interaction, HCI)<\/li>\n<\/ol>\n<h2>Ключевые вопросы<\/h2>\n<ol start=\"1\">\n<li>Что такое допустимый\/приемлемый риск?<\/li>\n<li>Какие актуальные вопросы стоят в индустрии?<\/li>\n<li>Переопределение и развитие системной безопасности в контексте интеллекутальных систем<\/li>\n<\/ol>\n<blockquote>\n<p>Люди совершают ошибки, но и компьютеры тоже<\/p>\n<\/blockquote>\n<h2>Концепты системной безопасности<\/h2>\n<ol start=\"1\">\n<li>Задача — снижение рисков. Нужны методы...\n<ul>\n  <li>Определения угроз и рисков<\/li>\n  <li>Снижение рисков и валидации принятых мер<\/li>\n<\/ul>\n<\/li>\n<li>Технологисекие аспекты\n<ul>\n  <li>Резервирование систем для повышения отказоустойчивости<\/li>\n  <li>Соответствие стандартам<\/li>\n  <li>Проектирование систем безопасными, а не только тестирование на безопасное поведение<\/li>\n<\/ul>\n<\/li>\n<li>Создание рабочей среды \/ культуры, где инструменты обеспечения безопасности реально используются, а не просто существуют для галочки<\/li>\n<\/ol>\n<h2>Анализ рисков<\/h2>\n<p class=\"loud\">Риск = Частота * ТяжестьПоследствий<\/p>\n<p>Простaя таблица рисков 2х2, которую используют для подобного анализа:<\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\"><\/td>\n<td style=\"text-align: left\">Тяжесть последствий<\/td>\n<td style=\"text-align: center\"><\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\">Частотность<\/td>\n<td style=\"text-align: center\">Низкая<\/td>\n<td style=\"text-align: center\">Высокая<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\">Низкая<\/td>\n<td style=\"text-align: center\">Низкий риск<\/td>\n<td style=\"text-align: center\">???<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\">Высокая<\/td>\n<td style=\"text-align: center\">Средний риск<\/td>\n<td style=\"text-align: center\">Высокий риск<\/td>\n<\/tr>\n<\/table>\n<p>Для кейса с маленькой частотностью, но тяжкими последствиями сложно математически рассчитать уровень риска, т. к. тут дело не в сухих цифрах, а в социальной приемлемости.<\/p>\n<p>Safety Integrity Level (SIL) — это уровень полноты безопасности, стандартизированный показатель, который количественно оценивает надёжность систем, предотвращающих аварийные ситуации.<\/p>\n<p>SIL задаёт, насколько вероятно, что система безопасности выполнит требуемую функцию в заданный момент времени — и тем самым предотвратит опасный отказ. Чем выше уровень SIL, тем строже требования к надёжности (в т.ч. технические) и тем ниже допустимая вероятность сбоя.<\/p>\n<p>SIL и требуемые меры проработаны во многих промышленных стандартах, но они только формируются для робототехнических \/ «вопрощенных» систем.<\/p>\n<h2>Вызов №1 — только негативные случаи имеют значение<\/h2>\n<p>Метрики надежности могут выглдяеть как:<\/p>\n<ul>\n<li>«99.999.999 vs. 99.999.998 км без инцидентов»<\/li>\n<li>«1 vs. 2 инцедента на 100.000.000 км»<\/li>\n<\/ul>\n<p>Первый и второй подход к показателям имеют разный акцент. В первом варианте системы практически идентичны, во втором — разница в два раза. <b>Метрики надежности формируются исходя из второго подхода.<\/b><\/p>\n<p class=\"loud\">Как следствие — единичная короткая поездка ничего не говорит о надежности системы.<\/p>\n<h2>Вызов №2 — редкие и тяжкие события<\/h2>\n<p>Какой уровень риска у событий с околонулевой вероятностью, но тяжелейшими последствиями?<\/p>\n<p class=\"loud\">zero probabilty * infinity cost = ???<\/p>\n<p>Аргументы с т.з. экономики, будут подталкивать оценить риск как низкий. Социальные и медийные аргументы будут подталкивать оценить риск как высокий.<\/p>\n<p>Философия оценки редких и тяжких событий зависит от прикладной области. По наблюдениям Фила Купмана, в автомобильной индустрии риск принимается скорее как низкий, а в авиации — как высокий.<\/p>\n<p>Один из ярких инцедентов в 2023г привел к закрытию бизнес-направления (см. дело Cruise <a href=\"https:\/\/en.wikipedia.org\/wiki\/Cruise_(autonomous_vehicle)\">https:\/\/en.wikipedia.org\/wiki\/Cruise_(autonomous_vehicle)<\/a> )<\/p>\n<p>Тем не менее, в 2025-м году General Motors возобонил проект и нанимает команду<br \/>\n<a href=\"https:\/\/www.bloomberg.com\/news\/articles\/2025-08-11\/gm-plans-renewed-push-on-driverless-cars-after-cruise-debacle\">https:\/\/www.bloomberg.com\/news\/articles\/2025-08-11\/gm-plans-renewed-push-on-driverless-cars-after-cruise-debacle<\/a><br \/>\n<a href=\"https:\/\/www.businessinsider.com\/gm-hires-former-tesla-exec-ronalee-mann-self-driving-cruise-2025-12\">https:\/\/www.businessinsider.com\/gm-hires-former-tesla-exec-ronalee-mann-self-driving-cruise-2025-12<\/a><\/p>\n<h2>Кибербезопасность<\/h2>\n<p><b>1. Целостность и доступность<\/b><\/p>\n<ul>\n<li>В eAI системах упор на целостности и доступности системы. То есть, юзер должен быть уверен, что автономный автомобиль не заражен зловредной программной, которая может повлияеть на его поведение. Вопрос конфеденциальности не стоит так остро как в онлайн-сервисах, т. к. машины и так на виду на дорогах и можно визуально отследить кто куда едет.<\/li>\n<\/ul>\n<p><b>2. Вредоносные ошибки<\/b><br \/>\nКибератаки могут перестроить уровни угроз, т. к. какой-то вид инцидентом может стать более частотным.<\/p>\n<p><b> 3. Физический доступ к устройству<\/b><br \/>\nЗлоумышленник может подключиться к eAI систете и провести более сложные манипулации, нежели с удаленным сервером.<\/p>\n<h2>ML<\/h2>\n<ol start=\"1\">\n<li>Обучается по примерам и отталкивается от статистики, вероятностей, частотности\n<ul>\n  <li>Модели не закладывают фундаментальные законы работы мира<\/li>\n  <li><i>[прим. АМ] для роботехники разрабатываются специальные модели, которые имеют представление о законах физики и причинно-следственных связей, но на уровне научных исследований<\/i><\/li>\n  <li>Машинное обучение несовместимо с Vee-моделью создания надежных технических систем.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p class=\"loud\">Тестирование — это не про доказательство корректности работы системы, а про проверку реализованных шагов при проектировании системы и адекватность процесса разработки.<\/p>\n<p>Машинное обучение учится на основе данных удовлетворять продуктовым требованиям. Как убедиться, что данные соотвествуют требованиям? Что в них точо есть, нужные примеры? Или наоброт — в них нет лишнего, что может повляить на обучение под требования? Система может обучаться непредсказуемо, что приводит к брутфорс-тестированию всего возможного и невозможного. На практике это невозможно, что еще раз подчеркивает, что тестирование не может обеспечить гарантию корректности работы системы.<\/p>\n<p><i>Тут видимо идейно про то, что нельзя сделать ТЗ для конкретных микро-фичей и ожидать корректность работы всей системы. Нельзя решить задачу надежности для ML в общем виде<\/i><\/p>\n<p>Что с этим делать? Уходить от абстрактной задачи обеспечения надежности к более конкретным. Проектировать дизайн эксперемента (датасеты и критерии успеха) так, чтобы можно было аргументированно рассказать почему разработчик системы считает, что это повышает надежность.<\/p>\n<h2>Human & eAI Safety<\/h2>\n<p>Человек плохо подходит для рутинной задачи контроля почти идеального автопилота<\/p>\n<ol start=\"1\">\n<li>Perception-Response Time (PRT)<\/li>\n<\/ol>\n<p>Людям нужно время, чтобы разобраться в ситуации и понять что делать дальше. У экспертов может вырабатываться мышечная память как поступать в тех или иных ситуациях, что ускоряет ответную реакцию.<\/p>\n<ol start=\"2\">\n<li>Ирония автоматизации удленяет PRT\n<ul>\n  <li>больше автоматизации ведет к меньшей практике людьми => во время отказа системы, у оператора может не хватить квалификации для своевременного принятия верного решения<\/li>\n  <li>предвзятость в пользу автоматизации (automation bias) — люди склонны доверять решению специализированной системы, а не себе. особенно, если система долгое время работает корректно<\/li>\n  <li>чем дольше система работает корректно, тем больше человек ей доверяет и тем сложнее быстро вмешаться, когда что-то идет не так<\/li>\n  <li>Ирония: чем эффективнее автоматика тем менее эффективен процесс контроля за ней со стороны людей<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<h2>Этическая и юридическая проблема<\/h2>\n<ol start=\"1\">\n<li>Кто отвественен за некорректное поведение eAI системы?<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Перекладывание отвественности на человека, не делает систему надежнее и безопаснее.<\/li>\n<\/ol>\n<blockquote>\n<p>Moral crumple zone («моральная зона смятия») — концепция, описывающая ситуацию, когда человек становится «буфером ответственности» в сбоях сложных автоматизированных или автономных систем.<br \/>\nТермин построен на аналогии с зоной смятия в автомобиле (энергопоглощающей частью кузова, которая деформируется при ударе, защищая пассажиров). В социотехнических системах «моральная зона смятия»: «поглощает» вину за сбой системы;<br \/>\nперекладывает моральную и юридическую ответственность на человека‑оператора;<br \/>\nзащищает репутацию и целостность технологии\/организации, жертвуя репутацией или правовым положением человека.<br \/>\nПонятие предложил исследователь Мэдлин Клэр Элиш (Madeleine Clare Elish) в работе «Moral Crumple Zones: Cautionary Tales in Human‑Robot Interaction» (2019). Она показала, как медиа и юридические системы часто упрощают причинно‑следственные связи, делая человека «удобным» виновником.<\/p>\n<\/blockquote>\n<h2>Известные проблемы...<\/h2>\n<p>...которые видны за последние годы пилотных запуском<\/p>\n<p><b>1. Ложные срабатывания систем безопасности автомобиля<\/b><\/p>\n<ul>\n<li>ненужные торможения и передача управления водителю<\/li>\n<li>автономный траспорт начинает вести себя непредсказуемо с т.з. других участников движения, что повышает риск аварии<\/li>\n<\/ul>\n<p><b>2. Непредсказуемость работы системы<\/b><\/p>\n<ul>\n<li>Какие гарантии, что система поведет себя точно так же в такой ситуации? Зачастую поведение недетрменировано, а ситуации хоть чуть-чутьт да различаются.<\/li>\n<li>Сколько раз система должна пройти тестовый сценарий, чтобы убедиться в корректности работы? Хватит ли одного раза? Десяти? Тысячи? Миллиона?<\/li>\n<\/ul>\n<p><b>3. Статистический подход при работе с надежностью<\/b><\/p>\n<ul>\n<li>Технические метрики для ML-систем в районе 90%-99% это супер-круто<\/li>\n<li>Но в задачах надежности нужны 99.9999999...% . Какие подходы могут добиться этих значений при обучении моделей?<\/li>\n<\/ul>\n<p><b>4. «Длинный (бескончный) хвост» редких и необычных случаев<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/image.png\" width=\"400\" height=\"400\" alt=\"\" \/>\n<\/div>\n<ul>\n<li>Как построить надежную eAI-систему, которая не может физически быть обучена на всех видах ситуаций?<\/li>\n<li>Нужен человеческий бекап + система должна понимать когда она не может работать<\/li>\n<\/ul>\n<p class=\"loud\">Безопасность — это не только про травмы и смерти, но и про неадекватное (рисковое) поведение.<\/p>\n<p>Например, Cruise заезжай на стройплощадки и не был готов к ситуациям, когда территория огорена подручными средствами.<\/p>\n<h2>Социальные риски из будущего<\/h2>\n<ol start=\"1\">\n<li>АТ может быть в среднем безопаснее, но иметь явный паттерн рискового поведения. Это ОК или НеОК?<\/li>\n<li>АТ приоритезириует безопасность людей в салоне относительно людей на улице.<\/li>\n<li>АТ может быть законопослушным, но что если другой участник движения нарушил ПДД и это сподвигает АТ нарушить ПДД, чтобы избежать рисковой ситуации? (механизм компенсации)<\/li>\n<li>Роботакси теоретичеки может не закончить поездку до конца и высадить пассажира в «плохом районе в плохое время».<\/li>\n<\/ol>\n<p>Безопасность включает в себя разные критерии успеха, которые важны разным стейкхолдреам. Не получится сделать одну метрику, которая докажет что система безопасна. Будет много ограничений, которые надо учитывать.<\/p>\n<h2>Юридические аспекты<\/h2>\n<p><b>Duty of Care for Human (осторожное поведение \/ забота)<\/b><\/p>\n<ol start=\"1\">\n<li>В Праве есть понятие «здравомыслящего человека», который соблюдает юридические и социальные нормы, что помогает предотвратить приченение вреда другим людям.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Пренебрежение этих норм можно описать как халатное поведение<\/li>\n<\/ol>\n<p><b>Duty of Care for Computers<\/b><\/p>\n<ol start=\"1\">\n<li>Текущий подход: ошибка на дороге = ошибка в проектировании системы = надо проводить тех.экспертизу, доказывать ее наличие именно в системе, а не окружающей среде, т. е. потенциальо не будет отвественного<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Предлагаемый подход: ошибка компьютера интерпретировать как ошибку человека, со всеми вытекающими последствиями которые будут наложена на производителя автономного транспорта<\/li>\n<\/ol>\n<p>Представим, что человек накатал миллион км и никого не сбил, хотя по статистике к этому моменту должно было быть 10 аварий. И на миллионном километре он сбил пешехода. Он не сможет защитить себя в суде аргументами в стиле «я катаюсь лучше среднего и у меня в запасе еще 9 ДТП». Судья отклонит этот аргумент.<\/p>\n<p>Производители автопилотов хотят оперировать статистикой для защиты своих интересов, а не фактом наличия нарушений.<\/p>\n<h2>Запутывающий слоган<\/h2>\n<p>Обратная сторона тезиса «автопилоты спасают жизни». Нужны другие слоганы<\/p>\n<ol start=\"1\">\n<li>Чтобы это доказать надо миллиарды киллометров<\/li>\n<li>Медийка не даст времени, чтобы это доказать.\n<ul>\n  <li>Любой прецидент будет использован, чтобы поставить под сомнение основной тезиc<\/li>\n  <li>Люди воспринимают истории, а не статистику<\/li>\n  <li>Фотка с ДТП имеет большой эффект наглядности, который будет бить любую статистику<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/ka-jvqwJtvA?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2026-01-10T01:53:16+03:00",
            "date_modified": "2026-01-10T15:11:00+03:00",
            "tags": [
                "Безопасность",
                "ИИ"
            ],
            "image": "https:\/\/pxs.md\/pictures\/image.png",
            "_date_published_rfc2822": "Sat, 10 Jan 2026 01:53:16 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "1",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/image.png",
                    "https:\/\/pxs.md\/pictures\/remote\/youtube-ka-jvqwJtvA-cover.jpg"
                ]
            }
        },
        {
            "id": "4",
            "url": "https:\/\/pxs.md\/all\/techphilosophy\/",
            "title": "Две тех.философии",
            "content_html": "<p><a href=\"https:\/\/stratechery.com\/2025\/tech-philosophy-and-ai-opportunity\/\">Бен Томпсон пытается систематизировать подходы разных компаний в области ИИ<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-11-15.58.37.jpeg\" width=\"1280\" height=\"893\" alt=\"\" \/>\n<\/div>\n<p>Он предлагает 2х2 матрицу с разбивкой по «философии в отношении ИИ» и «влияние на существующую бизнес-модель».<\/p>\n<p>Если супер-кратко, то есть два лагеря:<\/p>\n<ol start=\"1\">\n<li>Софт (или ИИ в контексте 2025г от Рождества Христова) — это <a href=\"https:\/\/pxs.md\/all\/bicycle-of-the-mind\/\" class=\"nu\">«<u>the bicycle of the mind<\/u>»<\/a> как однажды выразился Стив Джобс еще до того, как стал носить черные водолазки. То есть, это человеческий усилитель.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Софт\/ИИ — это личный слуга, который делает вещи за человека.<\/li>\n<\/ol>\n<p>И битву этих двух якодзун мы и наблюдаем в медийном и финансовом пространстве.<\/p>\n<p><a href=\"https:\/\/stratechery.com\/2018\/techs-two-philosophies\/\">Бен подметил эти два лагеря еще в 2018<\/a> (а может и ранее) и периодически ссылается на это в текстах и развивает мысль.<\/p>\n<p>Борьба за трактовки и интерпретации как может и должен выглядеть прислужливый ИИ разгорячилась где-то в 2022-м вместе с бумом LLM и технологии трансформеров.<\/p>\n<p>Источник бума технооптимисты, учёные и инженеры во главе с Эндрю Ыном (Andrew Ng). В 2024-м он предложил свои <a href=\"https:\/\/www.deeplearning.ai\/the-batch\/how-agents-can-improve-llm-performance\/\">дизайн-паттерны для агентов<\/a>. Технари взяли их на вооружение и понесли в треды на твиттере и в презентации к инвесторам. <a href=\"https:\/\/askell.io\/\">Anthropic нанимает штатного философа, чтобы стройно излагать кто они и зачем<\/a>.<\/p>\n<p>Но пятью годами раньше, кмк, тон дискуссии задавали в дизайнерском сообществе. На ум мне приходят отличные книги, конференции и статьи, где практики рассказывают как строить полезные человекоцентричные интеллектуальные продукты.<\/p>\n<ul>\n<li>книга <a href=\"https:\/\/rosenfeldmedia.com\/books\/designing-agentive-technology\/\">Designing Agentive Technology: AI That Works for People<\/a> (<a href=\"https:\/\/uxmag.com\/articles\/designing-agentive-technology-ai-that-works-for-peopleобзорная\">статья от автора<\/a>)<\/li>\n<li>исследования и гайдбуки от <a href=\"https:\/\/pair.withgoogle.com\/\">People AI Research Group из Google<\/a><\/li>\n<li>еще в 2019м на <a href=\"https:\/\/sigchi.org\/\">ACM SIGCHI<\/a> учёные и практики рассказывали как систематизируют опыт и делают полезные умные продукты.<\/li>\n<\/ul>\n<p>Сейчас наблюдаю в нишевом проф.сообществе битву определений, виженов и стратегий.<br \/>\nДизайнеры делают ответный выпад. Готовятся новые книги, прототипируются новые продукты, формируются стили и паттерны:<\/p>\n<ul>\n<li><a href=\"https:\/\/rosenfeldmedia.com\/books\/sentient-design\/\">sentient design<\/a> (<a href=\"https:\/\/bigmedium.com\/speaking\/sentient-design-josh-clark-talk.htmlобзор\">автора<\/a>)<\/li>\n<li>в январе ждем <a href=\"https:\/\/rosenfeldmedia.com\/books\/designing-assistant-technology\/\">Designing Assistant Technology: AI That Makes Us Smarter<\/a><\/li>\n<\/ul>\n<p>Если максимально упростить, то:<\/p>\n<ul>\n<li>условная «башня дизайнеров» развивает концепции «велосипедов для ума» и систем которым «мы делегируем рутину, но все равно контролируем исполнение»<\/li>\n<li>условная «башня программистов» топит за полную автоматизацию (алгоритмизацию, стандартизацию, упрощение?) большой части нашей жизни, где потенциально внимание человека вообще не будет нужно.<\/li>\n<\/ul>\n<p>Кто победит? Как говорится, it depends.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/tg-poll-2025-12-27.png\" width=\"694\" height=\"332\" alt=\"\" \/>\n<\/div>\n",
            "date_published": "2025-12-27T14:00:00+03:00",
            "date_modified": "2026-01-12T19:30:36+03:00",
            "tags": [
                "ИИ",
                "Мировоззрение"
            ],
            "image": "https:\/\/pxs.md\/pictures\/photo_2026-01-11-15.58.37.jpeg",
            "_date_published_rfc2822": "Sat, 27 Dec 2025 14:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "4",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-11-15.58.37.jpeg",
                    "https:\/\/pxs.md\/pictures\/tg-poll-2025-12-27.png"
                ]
            }
        }
    ],
    "_e2_version": 4171,
    "_e2_ua_string": "Aegea 11.4 (v4171e)"
}