Написал обзор гайда
Главная мысль. Агент - это не чатик, а система принятия решений с инструментами, памятью и ограниченной «властью». Работает в вероятностном мире, значит, всё вокруг него должно быть измеряемо, наблюдаемо и ограничено по полномочиям.
Почему это не “ещё один сервис”:
От детерминизма к вероятностям: одинаковый ввод → разные исходы. Нужны другие тесты и выпуск.
Code-first уходит, приходит evaluation-first: шипим только с доказательствами (качество, латентность, безопасность, стоимость).
Агент = инструменты + политика полномочий + трассы рассуждений (observable traces).
ADLC вместо SDLC (DevSecOps для агентов): Plan → Code/Build → Test/Optimize/Release → Deploy → Monitor (runtime loop) → Operate. Две «внутренние петли»: эксперименты на сборке и оптимизация в рантайме.
Безопасность по-взрослому:
Песочницы (Firecracker/gVisor/политики контейнеров) + kill-switch + least-privilege.
Агентские угрозы: memory poisoning, tool misuse, goal hijack - нужны отдельные контроли, не только классический AppSec.
Наблюдаемость и метрики:
Не «жив ли сервис?», а «прав ли агент?». Логи/трейсы рассуждений, groundedness, hallucination rate, cost per outcome, champion-challenger.
Говернанс:
Каталог сертифицированных агентов/инструментов/промптов, версии, риск-профиль, артефакты оценок и редтиминга - прежде чем выпускать.
Интеграции = MCP-серверы:
Инструменты выводим через Model Context Protocol, поверх - MCP-Gateway (политики, мTLS, квоты, аудит, многоарендность). Это «входные ворота» ко всем бэкендам.
Когда вообще строить агента? Если есть многошаговая логика/суждение и измеримые бизнес-метрики; не стесняйтесь выбирать простые решения вместо «агентов ради агентов».
Что делать завтра:
1) Завести ADLC как стандарт (шаблоны метрик/гейтов).
2) Включить агентские evals в CI/CD.
3) Поставить MCP-gateway и каталог.
4) Обязать песочницы и авторизацию «минимум прав».
5) Сделать общую панель «качество-стоимость-риски»
Мне отдельно нравится про Evals
Evals - это «медосмотр» агента.
Проверки, которые показывают: «агент делает правильно, безопасно и за разумные деньги». Они нужны потому, что агент отвечает по-разному на один и тот же запрос - важно мерить «прав ли он», а не только «живет ли сервис».
Как их делают (3 вида):
• Offline - в сборке/CI: гоняем набор задач и ловим регрессии до релиза.
• Online - в проде: постоянно мерим качество/безопасность/бизнес-эффект.
• In-the-loop - прямо во время работы: микропроверка, которая подсказывает агенту что делать дальше (например, релевантен ли контекст).
Что мерим (примеры метрик):
• успех задачи, groundedness, успех вызовов инструментов.
• частота джейлбрейков, утечки данных, нарушения политик.
• стоимость/токены на задачу, классы ошибок.
• CSAT/оценки, cost per outcome (сколько стоит результат).
Как раскатывать версии:
• Champion–Challenger: новую версию сравниваем с текущей на реальном трафике/данных; победителя - в промо. Это весомее офлайна.
Главная мысль. Агент - это не чатик, а система принятия решений с инструментами, памятью и ограниченной «властью». Работает в вероятностном мире, значит, всё вокруг него должно быть измеряемо, наблюдаемо и ограничено по полномочиям.
Мне особенно нравится мысль про вероятностный мир
Почему это не “ещё один сервис”:
От детерминизма к вероятностям: одинаковый ввод → разные исходы. Нужны другие тесты и выпуск.
Code-first уходит, приходит evaluation-first: шипим только с доказательствами (качество, латентность, безопасность, стоимость).
Агент = инструменты + политика полномочий + трассы рассуждений (observable traces).
ADLC вместо SDLC (DevSecOps для агентов): Plan → Code/Build → Test/Optimize/Release → Deploy → Monitor (runtime loop) → Operate. Две «внутренние петли»: эксперименты на сборке и оптимизация в рантайме.
Безопасность по-взрослому:
Песочницы (Firecracker/gVisor/политики контейнеров) + kill-switch + least-privilege.
Агентские угрозы: memory poisoning, tool misuse, goal hijack - нужны отдельные контроли, не только классический AppSec.
Наблюдаемость и метрики:
Не «жив ли сервис?», а «прав ли агент?». Логи/трейсы рассуждений, groundedness, hallucination rate, cost per outcome, champion-challenger.
Говернанс:
Каталог сертифицированных агентов/инструментов/промптов, версии, риск-профиль, артефакты оценок и редтиминга - прежде чем выпускать.
Интеграции = MCP-серверы:
Инструменты выводим через Model Context Protocol, поверх - MCP-Gateway (политики, мTLS, квоты, аудит, многоарендность). Это «входные ворота» ко всем бэкендам.
Когда вообще строить агента? Если есть многошаговая логика/суждение и измеримые бизнес-метрики; не стесняйтесь выбирать простые решения вместо «агентов ради агентов».
Что делать завтра:
1) Завести ADLC как стандарт (шаблоны метрик/гейтов).
2) Включить агентские evals в CI/CD.
3) Поставить MCP-gateway и каталог.
4) Обязать песочницы и авторизацию «минимум прав».
5) Сделать общую панель «качество-стоимость-риски»
Мне отдельно нравится про Evals
Evals - это «медосмотр» агента.
Проверки, которые показывают: «агент делает правильно, безопасно и за разумные деньги». Они нужны потому, что агент отвечает по-разному на один и тот же запрос - важно мерить «прав ли он», а не только «живет ли сервис».
Как их делают (3 вида):
• Offline - в сборке/CI: гоняем набор задач и ловим регрессии до релиза.
• Online - в проде: постоянно мерим качество/безопасность/бизнес-эффект.
• In-the-loop - прямо во время работы: микропроверка, которая подсказывает агенту что делать дальше (например, релевантен ли контекст).
Что мерим (примеры метрик):
• успех задачи, groundedness, успех вызовов инструментов.
• частота джейлбрейков, утечки данных, нарушения политик.
• стоимость/токены на задачу, классы ошибок.
• CSAT/оценки, cost per outcome (сколько стоит результат).
Как раскатывать версии:
• Champion–Challenger: новую версию сравниваем с текущей на реальном трафике/данных; победителя - в промо. Это весомее офлайна.
1🔥13❤4❤🔥3🤯2👌2👀1
Короче, есть такой прикол, что природа вокруг дает нам уроки менеджмента.
Вот пара примеров:
1.
Чтобы образовалась звезда/планета, нужна «песчинка», материал вокруг не и центробежная сила. Дальше все закрутится и образуется новый объект.
2.
Чтобы образовалась на ниточке соль (помните такой эксперимент, все в школе делали) нужны: нитка - аналог песчинки, материал вокруг нее и испарение лишнего. Вот тебе и образуется новый кристалл.
Чтобы сделать безболезненную трансформацию нужно:
1.
общую цель/врага
2.
Давление сверху - аналог того самого испарения.
Или желание участников - аналог центробежной силы.
3.
А дальше процессы и продукт поменяется под те самые общие цели.
Вот пара примеров:
1.
Чтобы образовалась звезда/планета, нужна «песчинка», материал вокруг не и центробежная сила. Дальше все закрутится и образуется новый объект.
2.
Чтобы образовалась на ниточке соль (помните такой эксперимент, все в школе делали) нужны: нитка - аналог песчинки, материал вокруг нее и испарение лишнего. Вот тебе и образуется новый кристалл.
Чтобы сделать безболезненную трансформацию нужно:
1.
общую цель/врага
2.
Давление сверху - аналог того самого испарения.
Или желание участников - аналог центробежной силы.
3.
А дальше процессы и продукт поменяется под те самые общие цели.
🔥16💯7❤5👍4🤔3👏2
Есть только 3 типа людей в лифте😁
Anonymous Poll
5%
Сначала кнопка закрытия, потом этаж
85%
Сначала этаж, потом кнопка закрытия
10%
Доверяюсь судьбе и ничего не жму😅
😁12🤔7👍2🤣2
Плохой Project Артём Арюткин
Просто офигительная книга по стратегии. На этой неделе дочитаю, в следующую среду выпущу обзор. Но, вдруг, вы не сможете удержаться и начнете читать раньше🙃
🎯 Почему у вас нет стратегии (и никогда не было)
В итоге я не удержался и дочитал книгу)
Напомню, мы тут с вами обсуждаем книгу Ричарда Румельта «Взлом стратегии».
Да, того самого, кто когда-то разрушил корпоративные “стратегические сессии” фразой:
.
🧩 Румельт предлагает новое слово - Crux.
Crux - это не “направление развития”, не “инициатива по улучшению”.
Это та самая проблема, которая держит вас за горло.
Проблема, которую если решить - всё остальное начнёт двигаться само.
🚀 Примеры:
• SpaceX - не «летим на Марс», а снижаем стоимость запуска в 10 раз.
• Netflix - не «становимся лидером стриминга», а уходим от зависимости от лицензий.
• Nvidia - не «растим долю GPU», а ищем область, где GPU дают преимущество.
И вот ты сидишь на корпоративной «стратегической сессии», где обсуждают 12 инициатив.
Digital, AI, NPS, HR-brand, CX…
А на самом деле никто не ответил на главный вопрос:
в чём наш Crux?
💣 Румельт жёсткий:
Если вы не можете сказать, от чего отказались, у вас нет стратегии.
А если стратегия не говорит «нет» -
значит, она просто Excel с цветными квадратиками.
🧗 Хорошая стратегия, как альпинизм.
Ты не штурмуешь гору со всех сторон.
Ты ищешь тот хребет, который реально пройти.
И лезешь по нему, шаг за шагом.
📉 Всё остальное -
брейнштормы, красивые слайды и бессмертные “инициативы по улучшению эффективности”.
🔥 Итого
«Взлом стратегии» - книга не про стратегию.
А про честность.
С собой, с компанией и с тем, что ты называешь “планом на год”.
🔥 - если читал и зашло
❤️ - если забрал в бэклог
💊 - если читал и не зашло
@badtechproject
В итоге я не удержался и дочитал книгу)
Напомню, мы тут с вами обсуждаем книгу Ричарда Румельта «Взлом стратегии».
Да, того самого, кто когда-то разрушил корпоративные “стратегические сессии” фразой:
Хорошая стратегия - это не список целей
.
🧩 Румельт предлагает новое слово - Crux.
Блин, мне очень понравился это символ 🧩, он супер подходит.
Crux - это не “направление развития”, не “инициатива по улучшению”.
Это та самая проблема, которая держит вас за горло.
Проблема, которую если решить - всё остальное начнёт двигаться само.
🚀 Примеры:
• SpaceX - не «летим на Марс», а снижаем стоимость запуска в 10 раз.
• Netflix - не «становимся лидером стриминга», а уходим от зависимости от лицензий.
Стали делать свой контент, а все остальное подтянулось
• Nvidia - не «растим долю GPU», а ищем область, где GPU дают преимущество.
Ииии… кто в век ИИ продает лопаты 😉
И вот ты сидишь на корпоративной «стратегической сессии», где обсуждают 12 инициатив.
Digital, AI, NPS, HR-brand, CX…
А на самом деле никто не ответил на главный вопрос:
в чём наш Crux?
💣 Румельт жёсткий:
Если вы не можете сказать, от чего отказались, у вас нет стратегии.
А если стратегия не говорит «нет» -
значит, она просто Excel с цветными квадратиками.
🧗 Хорошая стратегия, как альпинизм.
Ты не штурмуешь гору со всех сторон.
Ты ищешь тот хребет, который реально пройти.
И лезешь по нему, шаг за шагом.
📉 Всё остальное -
брейнштормы, красивые слайды и бессмертные “инициативы по улучшению эффективности”.
🔥 Итого
«Взлом стратегии» - книга не про стратегию.
А про честность.
С собой, с компанией и с тем, что ты называешь “планом на год”.
🔥 - если читал и зашло
❤️ - если забрал в бэклог
💊 - если читал и не зашло
@badtechproject
❤126🔥18👍6💊4👌1👀1
Forwarded from Product Сult / Паращенко Сергей
Вот бегаем мы с вами с этими AI, LLM, Агентами и тд. с горящими глазами.
А прикиньте, если для окружающих мы выглядим такими же фанатиками, как для нас выглядят ярые Криптаны, и от нас так же стараются держаться подальше?
А прикиньте, если для окружающих мы выглядим такими же фанатиками, как для нас выглядят ярые Криптаны, и от нас так же стараются держаться подальше?
😁46💯24❤4
This media is not supported in your browser
VIEW IN TELEGRAM
😁61🤣43💯4👍2🔥2❤1
С днем отца, друзья!
Нет у нас в жизни работы, важнее, чем эта!
Быть папой - это быть примером крепкой любви к маме, быть примером амбиций и силы, быть тем примером моря спокойствия, которое нужно иногда всем нам!
И помним, что чудесные у нас такие детки, в наших девочек ❤️
Нет у нас в жизни работы, важнее, чем эта!
Быть папой - это быть примером крепкой любви к маме, быть примером амбиций и силы, быть тем примером моря спокойствия, которое нужно иногда всем нам!
И с задачкою трудной самой
Папа справится, дайте срок!
Мы потом уж решаем с мамой
Все,что папа решить не смог!
И помним, что чудесные у нас такие детки, в наших девочек ❤️
❤81❤🔥20🤗5😁1
Так-с, в пятницу было Avito Tech Conf.
Я заехать не сумел, чуть придавило работой.
Но! Интернет все помнит.
Так что ловите 8 часовое видео!
А фото для затравки, чтобы оценить крутизну мероприятия!
Я заехать не сумел, чуть придавило работой.
Но! Интернет все помнит.
Так что ловите 8 часовое видео!
А фото для затравки, чтобы оценить крутизну мероприятия!
🔥31❤16👍6👏2
Есть темный паттерн, но выглядящий привлекательно: прийти и сказать, что у вас все плохо.
А затем предложить что-то, что супер сложно реализуемо.
Иногда так действуют тренеры в фитнес клубе. Они предлагают подопечному чуть-чуть поменять технику выполнения упражнения, подопечный берет меньший вес и, в целом, ему сложнее выполнить упражнение.
И тогда создается впечатление, что раньше он точно делал неправильно.
А затем предложить что-то, что супер сложно реализуемо.
Иногда так действуют тренеры в фитнес клубе. Они предлагают подопечному чуть-чуть поменять технику выполнения упражнения, подопечный берет меньший вес и, в целом, ему сложнее выполнить упражнение.
И тогда создается впечатление, что раньше он точно делал неправильно.
💯19👍4🔥3👎2
Когда даже Amazon падает: что менеджеру стоит понять из недавнего сбоя AWS
Amazon выпустили свой пост Мортем, ну а мы с вами его почитаем.
В ночь на 20 октября у AWS случилось то, что не должно было случиться никогда - легла DynamoDB.
И если вы думаете: «да какая мне разница, я же не в Amazon», - зря. Из таких историй стоит делать выводы.
🚨 Что произошло
Один из внутренних компонентов AWS, который отвечает за автоматическое обновление DNS (по сути, «куда ходят» запросы), внезапно удалил адреса у живого сервиса.
И всё - запросы перестали знать, куда идти.
Сначала упала DynamoDB, потом посыпались EC2, балансировщики, Lambda, EKS, ECS - словом, всё, что от неё зависело.
Классическая история про эффект домино, только в масштабе всей североамериканской инфраструктуры.
Что оказалось в корне
Виновата не халатность и не «людской фактор», а состояние гонки (race condition) - ситуация, когда два автоматических процесса пытаются изменить одно и то же, и старое значение перезаписывает новое.
По сути:
Один автомат обновил DNS-запись,
Второй отработал чуть позже и стер то, что уже было исправлено.
Система посчитала, что адрес не нужен, и удалила его.
Звучит как мелочь, но когда в цепочке миллионы клиентов - это мгновенный обвал.
К чему это привело
Невозможно было запустить новые виртуалки (EC2).
Балансировщики удаляли здоровые узлы, думая, что они мертвы.
Сервисы вроде Lambda и EKS висли из-за потери зависимостей.
Даже внутренние инструменты AWS перестали работать, усложнив восстановление.
Проблемы тянулись почти 15 часов.
Даже для Amazon это больно.
🛠️ Что AWS сделала
Переписала логику обновления DNS и устранила состояние гонки.
Ввела дополнительные проверки и «тормоза» для автоматизации.
Улучшила систему зависимости сервисов (чтобы сбой одного не клал всё подряд).
Пересмотрела лимиты и алгоритмы управления нагрузкой.
Что из этого важно нам, менеджерам
Автоматизация - не панацея.
Даже идеально автоматизированная система способна завалить себя же. Нужен контроль, наблюдаемость и механизмы ручного вмешательства.
Зависимости - главная угроза.
Продукт редко падает сам по себе - его валит зависимый сервис.
Чем больше таких связей, тем выше риск каскадного обрушения.
В своих системах важно знать: кто от кого зависит и что будет, если этот кто-то “ляжет”.
“Blast radius” - новый KPI менеджера.
Задача не только в том, чтобы быстро восстанавливаться, но и в том, чтобы сбой не утащил за собой соседние команды и продукты.
То есть проектировать системы так, чтобы падать «локально».
Коммуникация во время кризиса.
AWS держала всех в курсе. И да, это важнее, чем “пофиксить быстро”.
Люди легче переживают инцидент, когда им понятно, что происходит.
Чем проще инженеру понять, что происходит при сбое, тем быстрее компания восстанавливается.
Хорошие инструменты, дашборды, наблюдаемость - это не “для красоты”, это страховой полис.
В сухом остатке
Падение AWS - напоминание:
никакая масштабность и зрелость процессов не спасает от мелких, но критичных ошибок в инфраструктуре.
А наша задача, как менеджеров - уметь проектировать так, чтобы даже при падении системы не падали люди:
ни по моральному духу, ни по довериям к процессам, ни по коммуникации.
Amazon выпустили свой пост Мортем, ну а мы с вами его почитаем.
В ночь на 20 октября у AWS случилось то, что не должно было случиться никогда - легла DynamoDB.
И если вы думаете: «да какая мне разница, я же не в Amazon», - зря. Из таких историй стоит делать выводы.
🚨 Что произошло
Один из внутренних компонентов AWS, который отвечает за автоматическое обновление DNS (по сути, «куда ходят» запросы), внезапно удалил адреса у живого сервиса.
И всё - запросы перестали знать, куда идти.
Сначала упала DynamoDB, потом посыпались EC2, балансировщики, Lambda, EKS, ECS - словом, всё, что от неё зависело.
Классическая история про эффект домино, только в масштабе всей североамериканской инфраструктуры.
Что оказалось в корне
Виновата не халатность и не «людской фактор», а состояние гонки (race condition) - ситуация, когда два автоматических процесса пытаются изменить одно и то же, и старое значение перезаписывает новое.
По сути:
Один автомат обновил DNS-запись,
Второй отработал чуть позже и стер то, что уже было исправлено.
Система посчитала, что адрес не нужен, и удалила его.
Звучит как мелочь, но когда в цепочке миллионы клиентов - это мгновенный обвал.
К чему это привело
Невозможно было запустить новые виртуалки (EC2).
Балансировщики удаляли здоровые узлы, думая, что они мертвы.
Сервисы вроде Lambda и EKS висли из-за потери зависимостей.
Даже внутренние инструменты AWS перестали работать, усложнив восстановление.
Проблемы тянулись почти 15 часов.
Даже для Amazon это больно.
🛠️ Что AWS сделала
Переписала логику обновления DNS и устранила состояние гонки.
Ввела дополнительные проверки и «тормоза» для автоматизации.
Улучшила систему зависимости сервисов (чтобы сбой одного не клал всё подряд).
Пересмотрела лимиты и алгоритмы управления нагрузкой.
Что из этого важно нам, менеджерам
Автоматизация - не панацея.
Даже идеально автоматизированная система способна завалить себя же. Нужен контроль, наблюдаемость и механизмы ручного вмешательства.
Зависимости - главная угроза.
Продукт редко падает сам по себе - его валит зависимый сервис.
Чем больше таких связей, тем выше риск каскадного обрушения.
В своих системах важно знать: кто от кого зависит и что будет, если этот кто-то “ляжет”.
“Blast radius” - новый KPI менеджера.
Задача не только в том, чтобы быстро восстанавливаться, но и в том, чтобы сбой не утащил за собой соседние команды и продукты.
То есть проектировать системы так, чтобы падать «локально».
Коммуникация во время кризиса.
AWS держала всех в курсе. И да, это важнее, чем “пофиксить быстро”.
Люди легче переживают инцидент, когда им понятно, что происходит.
Чем проще инженеру понять, что происходит при сбое, тем быстрее компания восстанавливается.
Хорошие инструменты, дашборды, наблюдаемость - это не “для красоты”, это страховой полис.
В сухом остатке
Падение AWS - напоминание:
никакая масштабность и зрелость процессов не спасает от мелких, но критичных ошибок в инфраструктуре.
А наша задача, как менеджеров - уметь проектировать так, чтобы даже при падении системы не падали люди:
ни по моральному духу, ни по довериям к процессам, ни по коммуникации.
🔥52❤19⚡5👍5👨💻2
Собирать бэклог книг теперь, офигенно, просто!
Обожаю такие диалоги с чат ГПТ теперь.
Представь, что мне нужно стать экспертом по кастдеву. Однако, за всю жизнь я могу прочитать только 1 статью или книгу или посмотреть фильм/сериал. Что посоветуешь?
Обожаю такие диалоги с чат ГПТ теперь.
Представь, что мне нужно стать экспертом по кастдеву. Однако, за всю жизнь я могу прочитать только 1 статью или книгу или посмотреть фильм/сериал. Что посоветуешь?
<Отвечу как мировой эксперт по Customer Development, лауреат реальной премии Thinkers50 Distinguished Achievement (Innovation)>
TL;DR: если можно только ОДНУ вещь — бери книгу Steve Blank & Bob Dorf “The Startup Owner’s Manual”(полная версия). Это самая практичная “библия” кастдева: пошаговый процесс Customer Discovery → Customer Validation, готовые чек-листы, шаблоны интервью, метрики, анти-паттерны. По одной книге ты реально сможешь ставить гипотезы, проводить интервью без “мамтест-ошибок”, валидировать спрос и принимать продуктовые решения.
1✍26🔥17👍11❤3🥴1🤗1
Понимают ли LLM, когда ими манипулируют?
Я не знаю, как там и что по науке, но факт в том, что наша с вами головешка очень даже анализирует в моменте времени огромное количество данных, что позволяет нам улавливать тонкости.
Новое исследование из Принстона и Anthropic: «Are Large Language Models Sensitive to the Motives Behind Communication?» Ребата такие сели и решили понять:
может ли ИИ отличить искренний совет от манипуляции?
И ответ... не такой уж однозначный.
И я короче за вас прочитал и сделал выводы для себя. Вдруг, и вам понадобится.
Что проверяли?
Учёные провели три серии экспериментов, где LLM нужно было отличать:
1️⃣ нейтральную информацию от намеренно «впариваемой» (как реклама),
2️⃣ совет друга, соседа или незнакомца - с разными личными выгодами,
3️⃣ реальные рекламные вставки с YouTube (NordVPN, AG1 и др.).
Результаты шокируют - модели вроде GPT-4o и Claude 3.5 умеют немного отличать манипуляцию… но только в лабораторных условиях.
В реальных, «шумных» сценариях (например, спонсорская интеграция на YouTube) всё рушится:
корреляция с рациональной моделью падает ниже 0.2.
Главный инсайт
LLM пока не умеют по-настоящему читать намерения - они слишком послушны.
Но если добавить в промпт простую фразу вроде
“Обрати внимание на мотивы и выгоды говорящего”,
результаты резко улучшаются!
То есть модели могут быть бдительными, если их об этом прямо попросить.
(и да, GPT-4o в этих тестах оказался самым «разумным»)
Почему это важно?
👉Если LLM не понимает мотивацию источника - она легко повторяет ложь, ведётся на манипуляции и делает «человеческие» ошибки.
👉🏼А теперь представьте это в корпоративном ассистенте, который читает внутренние отчёты или маркетинговые тексты…
ИИ-ассистент, который помогает тебе в компании - читает отчёты, письма, маркетинговые тексты — учится на том же типе данных, что и LLM в эксперименте.
А эти данные всегда написаны людьми с мотивами.
👉🏻 Когда маркетинг пишет, что «новая фича - революция» - это не факт, а намерение повлиять.
👉🏻 Когда отчёт «всё зелёное по OKR» - это тоже коммуникация с мотивацией (удержать доверие руководства, не потерять бюджет и т.д.).
Если LLM не умеет видеть эти мотивы, она:
- принимает пиар за правду,
- усиливает внутренние искажения,
- может давать советы, основанные на «манипулятивной» информации,
- а потом менеджер, доверяя ассистенту, принимает решение на неверных основаниях.
То есть негатив в том, что ИИ без «внимательности к мотивам» становится ретранслятором корпоративного самообмана.
💬 Что это значит для нас?
👉🏼 В будущем «внимательность к мотивам» (motivational vigilance) станет новой метрикой качества ИИ,
рядом с factuality, reasoning и alignment.
👉🏼 А промпт-дизайн, делающий мотивы источников явными, - ключ к надёжным агентам.
Ну если решите почитать сами, то вот вам отборнейших 40 страниц😉
Я не знаю, как там и что по науке, но факт в том, что наша с вами головешка очень даже анализирует в моменте времени огромное количество данных, что позволяет нам улавливать тонкости.
Новое исследование из Принстона и Anthropic: «Are Large Language Models Sensitive to the Motives Behind Communication?» Ребата такие сели и решили понять:
может ли ИИ отличить искренний совет от манипуляции?
И ответ... не такой уж однозначный.
И я короче за вас прочитал и сделал выводы для себя. Вдруг, и вам понадобится.
Что проверяли?
Учёные провели три серии экспериментов, где LLM нужно было отличать:
1️⃣ нейтральную информацию от намеренно «впариваемой» (как реклама),
2️⃣ совет друга, соседа или незнакомца - с разными личными выгодами,
3️⃣ реальные рекламные вставки с YouTube (NordVPN, AG1 и др.).
Результаты шокируют - модели вроде GPT-4o и Claude 3.5 умеют немного отличать манипуляцию… но только в лабораторных условиях.
В реальных, «шумных» сценариях (например, спонсорская интеграция на YouTube) всё рушится:
корреляция с рациональной моделью падает ниже 0.2.
Главный инсайт
LLM пока не умеют по-настоящему читать намерения - они слишком послушны.
Но если добавить в промпт простую фразу вроде
“Обрати внимание на мотивы и выгоды говорящего”,
результаты резко улучшаются!
То есть модели могут быть бдительными, если их об этом прямо попросить.
(и да, GPT-4o в этих тестах оказался самым «разумным»)
Почему это важно?
👉Если LLM не понимает мотивацию источника - она легко повторяет ложь, ведётся на манипуляции и делает «человеческие» ошибки.
👉🏼А теперь представьте это в корпоративном ассистенте, который читает внутренние отчёты или маркетинговые тексты…
ИИ-ассистент, который помогает тебе в компании - читает отчёты, письма, маркетинговые тексты — учится на том же типе данных, что и LLM в эксперименте.
А эти данные всегда написаны людьми с мотивами.
👉🏻 Когда маркетинг пишет, что «новая фича - революция» - это не факт, а намерение повлиять.
👉🏻 Когда отчёт «всё зелёное по OKR» - это тоже коммуникация с мотивацией (удержать доверие руководства, не потерять бюджет и т.д.).
Если LLM не умеет видеть эти мотивы, она:
- принимает пиар за правду,
- усиливает внутренние искажения,
- может давать советы, основанные на «манипулятивной» информации,
- а потом менеджер, доверяя ассистенту, принимает решение на неверных основаниях.
То есть негатив в том, что ИИ без «внимательности к мотивам» становится ретранслятором корпоративного самообмана.
💬 Что это значит для нас?
👉🏼 В будущем «внимательность к мотивам» (motivational vigilance) станет новой метрикой качества ИИ,
рядом с factuality, reasoning и alignment.
👉🏼 А промпт-дизайн, делающий мотивы источников явными, - ключ к надёжным агентам.
Ну если решите почитать сами, то вот вам отборнейших 40 страниц😉
1🔥25❤10👏4👍1
Пока я был в командировке ребята из издательства Питер прислали мне топовую книжку почитать ❤️
❤21🔥12👀2