Промпти вже не важливі? 🤯
Доброго ранку понеділка ☕️
На вихідних підготував багато цікавих розборів - буду ділитися поступово протягом тижня. А поки хочу поділитися своїм підходом який ви зможете спробувати вже сьогодні.
Пам'ятаєте минулої осені у мене була рубрика "Промпт тижня" - де я давав конкретний промпт який покращував роботу з LLM? Так от за останній рік я помітив важливий зсув. Раніше всі шукали "ідеальний промпт": Act as…, Think step by step…, Use this framework… Це працювало. Але чим сильніші стають моделі - тим менше цінності в магічних формулюваннях. Я вже писав про це у контексті The Bitter Lesson: у довгостроковій перспективі виграють підходи які масштабуються з обчисленнями а не ручна оптимізація. Prompt engineering - це якраз ручна оптимізація.
Натомість зростає цінність іншого: уміння передати моделі контекст.
Сьогодні важливіше не "написати красивий промпт" а правильно пояснити задачу.
Мій робочий підхід зараз такий. Я не намагаюся одразу написати ідеальний промпт вручну. Натомість спочатку даю моделі максимум сирого контексту — часто просто наговорюю голосом через Whisper Flow.
Коли пишемо текст руками — автоматично скорочуємо думку, прибираємо "зайве", формулюємо акуратніше. Але разом з цим втрачаємо нюанси. Коли говоримо голосом — з'являється більше живого контексту: сумніви, мотиви, проміжні думки, приклади. Такий текст хаотичний — але це хороша задача для LLM а не проблема людини.
Мій паттерн на практиці:
1. Наговорити задачу максимально детально — через Whisper Flow або будь-який голосовий ввід
2. Попросити ChatGPT перетворити це на структурований бриф — з цим він справляється добре і відносно дешево
3. Попросити написати промпт для іншої моделі або агента
4. Використати цей промпт для виконання задачі — тут вже агенти або більш потужна модель
5. Уточнити що спрацювало а що ні - і повторити цикл
Тобто LLM стає не тільки виконавцем а й редактором постановки задачі.
Anthropic нещодавно опублікували детальний розбір саме цієї теми — Effective context engineering for AI agents. Особливо важливо для агентів: агенту недостатньо сказати "зроби добре". Йому потрібно пояснити ціль, межі, послідовність дій і що робити при невизначеності.
Хороший промпт сьогодні - це не красива фраза. Це маленька специфікація задачі.
І парадокс у тому що найкращий спосіб написати таку специфікацію часто починається не з письма а зі звичайного людського пояснення голосом.
Модель помиляється тому що ми не передали їй половину того що було у нас в голові.
Спробуйте цього тижня - і напишіть чи відчули різницю 👇
🔔 ПІДПИСАТИСЯ
Доброго ранку понеділка ☕️
На вихідних підготував багато цікавих розборів - буду ділитися поступово протягом тижня. А поки хочу поділитися своїм підходом який ви зможете спробувати вже сьогодні.
Пам'ятаєте минулої осені у мене була рубрика "Промпт тижня" - де я давав конкретний промпт який покращував роботу з LLM? Так от за останній рік я помітив важливий зсув. Раніше всі шукали "ідеальний промпт": Act as…, Think step by step…, Use this framework… Це працювало. Але чим сильніші стають моделі - тим менше цінності в магічних формулюваннях. Я вже писав про це у контексті The Bitter Lesson: у довгостроковій перспективі виграють підходи які масштабуються з обчисленнями а не ручна оптимізація. Prompt engineering - це якраз ручна оптимізація.
Натомість зростає цінність іншого: уміння передати моделі контекст.
Сьогодні важливіше не "написати красивий промпт" а правильно пояснити задачу.
Мій робочий підхід зараз такий. Я не намагаюся одразу написати ідеальний промпт вручну. Натомість спочатку даю моделі максимум сирого контексту — часто просто наговорюю голосом через Whisper Flow.
Коли пишемо текст руками — автоматично скорочуємо думку, прибираємо "зайве", формулюємо акуратніше. Але разом з цим втрачаємо нюанси. Коли говоримо голосом — з'являється більше живого контексту: сумніви, мотиви, проміжні думки, приклади. Такий текст хаотичний — але це хороша задача для LLM а не проблема людини.
Мій паттерн на практиці:
1. Наговорити задачу максимально детально — через Whisper Flow або будь-який голосовий ввід
2. Попросити ChatGPT перетворити це на структурований бриф — з цим він справляється добре і відносно дешево
3. Попросити написати промпт для іншої моделі або агента
4. Використати цей промпт для виконання задачі — тут вже агенти або більш потужна модель
5. Уточнити що спрацювало а що ні - і повторити цикл
Тобто LLM стає не тільки виконавцем а й редактором постановки задачі.
Anthropic нещодавно опублікували детальний розбір саме цієї теми — Effective context engineering for AI agents. Особливо важливо для агентів: агенту недостатньо сказати "зроби добре". Йому потрібно пояснити ціль, межі, послідовність дій і що робити при невизначеності.
Хороший промпт сьогодні - це не красива фраза. Це маленька специфікація задачі.
І парадокс у тому що найкращий спосіб написати таку специфікацію часто починається не з письма а зі звичайного людського пояснення голосом.
Модель помиляється тому що ми не передали їй половину того що було у нас в голові.
Спробуйте цього тижня - і напишіть чи відчули різницю 👇
🔔 ПІДПИСАТИСЯ
👍18❤3🔥1
OpenClaw вже не актуальний?
Доброго раночку ☕️ ☀️
Можливо, помітили як останнім часом у стрічці з'явилося багато "експертів з AI-агентів": ще вчора людина розповідала про особистий бренд, а сьогодні вже демонструє агента який автоматизує всю її роботу. І дуже часто під капотом у таких демо — саме OpenClaw.
Він зробив ідею персонального AI-агента зрозумілою і масовою. Я сам консультував бізнес по налаштуванню OpenClaw де потрібно було організувати взаємодію з месенджерами — і там все заходить на ура. Для таких задач він працює відмінно.
Але не встигло пройти й пів року як з'явився цікавий конкурент — Hermes Agent від Nous Research. І вся іронія в тому що Hermes нещодавно обігнав OpenClaw у рейтингу OpenRouter за кількістю токенів які агенти споживають щодня. Тобто його почали активно тестувати і використовувати.
На перший погляд вони схожі. Обидва працюють з різними LLM, використовують інструменти, інтегруються з месенджерами і виконують задачі через агентний цикл: користувач задає ціль → агент збирає контекст → LLM вирішує що робити → агент викликає інструмент або відповідає.
Але ключова відмінність Hermes — у двох речах: пам'ять і самопокращення.
Hermes може автоматично створювати нові навички. Якщо агент знайшов рішення або виправив помилку — він може перетворити цей досвід на окрему інструкцію для майбутнього використання. Тобто він не просто виконав задачу і "забув" як це зробив. Він зберігає успішний патерн як skill.
Друга важлива річ — складніша архітектура пам'яті. Hermes зберігає не тільки вподобання користувача а й робочі процеси, уроки з попередніх задач і може шукати по базі минулих розмов. Це вже більше схоже на довготривалого цифрового помічника ніж на чат який тримає контекст поточної сесії.
Окремо цікава функція — persistent goal tracking. Користувач задає ціль, після відповіді окрема модель-суддя перевіряє чи справді ціль виконана. Якщо ні — агент продовжує працювати поки ціль не виконана або не досягнуто ліміт кроків.
Є й мінуси. Частина користувачів скаржиться що Hermes менш ефективний у використанні токенів — тобто може коштувати дорожче.
Власне у мене в роботі більш точкові агенти під конкретні задачі ніж OpenClaw. Але є план зробити AI-ресерчера: кілька агентів які шукають і перехресно перевіряють інформацію по наукових статтях. Руки поки не доходять але архітектура Hermes для цього виглядає цікавіше.
Тут бачимо перехід від агентів першої хвилі де головною фішкою була інтеграція з інструментами — до агентів другої хвилі де ключовими стають довготривала пам'ять, автоматичне створення навичок і накопичення досвіду.
AI-агенти поступово перестають бути просто "оболонкою навколо LLM". Вони стають системами які мають пам'ять, інструменти, механізми перевірки результату і здатність покращувати власну поведінку на основі попереднього досвіду.
🔔 ПІДПИСАТИСЯ
Доброго раночку ☕️ ☀️
Можливо, помітили як останнім часом у стрічці з'явилося багато "експертів з AI-агентів": ще вчора людина розповідала про особистий бренд, а сьогодні вже демонструє агента який автоматизує всю її роботу. І дуже часто під капотом у таких демо — саме OpenClaw.
Він зробив ідею персонального AI-агента зрозумілою і масовою. Я сам консультував бізнес по налаштуванню OpenClaw де потрібно було організувати взаємодію з месенджерами — і там все заходить на ура. Для таких задач він працює відмінно.
Але не встигло пройти й пів року як з'явився цікавий конкурент — Hermes Agent від Nous Research. І вся іронія в тому що Hermes нещодавно обігнав OpenClaw у рейтингу OpenRouter за кількістю токенів які агенти споживають щодня. Тобто його почали активно тестувати і використовувати.
На перший погляд вони схожі. Обидва працюють з різними LLM, використовують інструменти, інтегруються з месенджерами і виконують задачі через агентний цикл: користувач задає ціль → агент збирає контекст → LLM вирішує що робити → агент викликає інструмент або відповідає.
Але ключова відмінність Hermes — у двох речах: пам'ять і самопокращення.
Hermes може автоматично створювати нові навички. Якщо агент знайшов рішення або виправив помилку — він може перетворити цей досвід на окрему інструкцію для майбутнього використання. Тобто він не просто виконав задачу і "забув" як це зробив. Він зберігає успішний патерн як skill.
Друга важлива річ — складніша архітектура пам'яті. Hermes зберігає не тільки вподобання користувача а й робочі процеси, уроки з попередніх задач і може шукати по базі минулих розмов. Це вже більше схоже на довготривалого цифрового помічника ніж на чат який тримає контекст поточної сесії.
Окремо цікава функція — persistent goal tracking. Користувач задає ціль, після відповіді окрема модель-суддя перевіряє чи справді ціль виконана. Якщо ні — агент продовжує працювати поки ціль не виконана або не досягнуто ліміт кроків.
Є й мінуси. Частина користувачів скаржиться що Hermes менш ефективний у використанні токенів — тобто може коштувати дорожче.
Власне у мене в роботі більш точкові агенти під конкретні задачі ніж OpenClaw. Але є план зробити AI-ресерчера: кілька агентів які шукають і перехресно перевіряють інформацію по наукових статтях. Руки поки не доходять але архітектура Hermes для цього виглядає цікавіше.
Тут бачимо перехід від агентів першої хвилі де головною фішкою була інтеграція з інструментами — до агентів другої хвилі де ключовими стають довготривала пам'ять, автоматичне створення навичок і накопичення досвіду.
AI-агенти поступово перестають бути просто "оболонкою навколо LLM". Вони стають системами які мають пам'ять, інструменти, механізми перевірки результату і здатність покращувати власну поведінку на основі попереднього досвіду.
🔔 ПІДПИСАТИСЯ
👍11❤3🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
AI як справжній співрозмовник ☕️
Мене давно бентежило, що голосові AI-асистенти часто працюють не як живий співрозмовник, а як звичайний чат з озвучкою: ти щось кажеш → модель чекає → думає → відповідає.
Thinking Machines Lab — компанія Міри Мураті — показала TML-Interaction-Small. Головна ідея тут в тому що модель не чекає поки користувач повністю завершить репліку. Вона обробляє аудіо, відео і текст паралельно маленькими micro-turns приблизно по 200 мс.
Під капотом — цікава архітектура. Є foreground interaction model: швидка модель, яка слухає, бачить і підтримує розмову в реальному часі. І є background reasoning model: окрема модель, яка може думати довше, викликати інструменти, шукати інформацію — і не ламати діалог.
Latency у розмовних turn'ах — близько 0.40 секунди. Для порівняння: GPT-Realtime-2 який ми розбирали нещодавно показує 1.12 секунди в minimal режимі.
Про те, чим ця архітектура відрізняється від підходу OpenAI — у наступному пості сьогодні.
🔔 ПІДПИСАТИСЯ
Мене давно бентежило, що голосові AI-асистенти часто працюють не як живий співрозмовник, а як звичайний чат з озвучкою: ти щось кажеш → модель чекає → думає → відповідає.
Thinking Machines Lab — компанія Міри Мураті — показала TML-Interaction-Small. Головна ідея тут в тому що модель не чекає поки користувач повністю завершить репліку. Вона обробляє аудіо, відео і текст паралельно маленькими micro-turns приблизно по 200 мс.
Під капотом — цікава архітектура. Є foreground interaction model: швидка модель, яка слухає, бачить і підтримує розмову в реальному часі. І є background reasoning model: окрема модель, яка може думати довше, викликати інструменти, шукати інформацію — і не ламати діалог.
Latency у розмовних turn'ах — близько 0.40 секунди. Для порівняння: GPT-Realtime-2 який ми розбирали нещодавно показує 1.12 секунди в minimal режимі.
Про те, чим ця архітектура відрізняється від підходу OpenAI — у наступному пості сьогодні.
🔔 ПІДПИСАТИСЯ
👍7
TML vs OpenAI: два різних підходи до голосового AI
Продовжуємо тему з ранкового посту. 🥣
Коли дивишся на TML-Interaction-Small і GPT-Realtime-2 — здається що це схожі продукти. Обидва мультимодальні, обидва працюють у реальному часі, обидва мають foreground і background компоненти.
Але різниця принципова.
GPT-Realtime-2 — це orchestration підхід. Real-time voice model через tool calls передає складні запити окремій reasoning-моделі а потім вбудовує її відповідь назад у розмову. Перевага — гнучкість: будь-яку real-time модель можна поєднати з будь-якою reasoning-моделлю без додаткового навчання. Недолік — система фундаментально залишається turn-based а передача між моделями оркеструється вручну.
TML-Interaction-Small пішла інакше. Foreground і background моделі навчаються спільно. Вони мають спільний контекст і background модель вбудовує результат назад у розмову тоді коли це доречно — не через ручну оркестрацію а через саму архітектуру.
Є ще один важливий момент. Thinking Machines Lab заявила що має більші pretrained interaction-моделі але поки не може обслуговувати їх достатньо швидко для real-time взаємодії. Компанія планує випустити їх пізніше цього року. Тобто TML-Interaction-Small — це не фінальний продукт а демонстрація підходу.
Серед моделей з відомим розміром TML-Interaction-Small є найбільшою яка спеціально навчена для інтерактивної продуктивності: 276 млрд параметрів проти 9 млрд у найближчого архітектурно схожого конкурента MiniCPM-o 4.5.
Тобто ми бачимо два різних погляди на одну проблему. OpenAI каже: візьмемо сильну reasoning-модель і додамо до неї гнучку голосову обгортку. TML каже: навчимо foreground і background разом щоб вони розуміли одна одну без ручної оркестрації.
Який підхід виявиться кращим — покаже практика.
Про те куди це все рухається — у вечірньому пості.
🔔 ПІДПИСАТИСЯ
Продовжуємо тему з ранкового посту. 🥣
Коли дивишся на TML-Interaction-Small і GPT-Realtime-2 — здається що це схожі продукти. Обидва мультимодальні, обидва працюють у реальному часі, обидва мають foreground і background компоненти.
Але різниця принципова.
GPT-Realtime-2 — це orchestration підхід. Real-time voice model через tool calls передає складні запити окремій reasoning-моделі а потім вбудовує її відповідь назад у розмову. Перевага — гнучкість: будь-яку real-time модель можна поєднати з будь-якою reasoning-моделлю без додаткового навчання. Недолік — система фундаментально залишається turn-based а передача між моделями оркеструється вручну.
TML-Interaction-Small пішла інакше. Foreground і background моделі навчаються спільно. Вони мають спільний контекст і background модель вбудовує результат назад у розмову тоді коли це доречно — не через ручну оркестрацію а через саму архітектуру.
Є ще один важливий момент. Thinking Machines Lab заявила що має більші pretrained interaction-моделі але поки не може обслуговувати їх достатньо швидко для real-time взаємодії. Компанія планує випустити їх пізніше цього року. Тобто TML-Interaction-Small — це не фінальний продукт а демонстрація підходу.
Серед моделей з відомим розміром TML-Interaction-Small є найбільшою яка спеціально навчена для інтерактивної продуктивності: 276 млрд параметрів проти 9 млрд у найближчого архітектурно схожого конкурента MiniCPM-o 4.5.
Тобто ми бачимо два різних погляди на одну проблему. OpenAI каже: візьмемо сильну reasoning-модель і додамо до неї гнучку голосову обгортку. TML каже: навчимо foreground і background разом щоб вони розуміли одна одну без ручної оркестрації.
Який підхід виявиться кращим — покаже практика.
Про те куди це все рухається — у вечірньому пості.
🔔 ПІДПИСАТИСЯ
👍10
Що всередині TML-Interaction-Small: три технічні рішення
Технічний розбір для тих кому цікаво що під капотом.
Більшість мультимодальних систем збирається з готових компонентів: Whisper для розпізнавання мови, Vision Transformer для відео, окремий LLM для мислення. TML пішла інакше — навчила всі компоненти разом з нуля. Вони називають це encoder-free early fusion.
Аудіо
Замість складного кодека аудіосигнал токенізується через dMel — прості дискретизовані мел-спектрограми. Ніякого стиснення через нейромережу — пряме перетворення частотних смуг в інтенсивність. Підхід від Apple показав що така проста токенізація працює краще ніж складні альтернативи і стійкіша до шуму та незнайомих даних.
Відео
Зображення розбивається на патчі 40x40 пікселів, ембедінги яких генерує ієрархічний багатошаровий перцептрон. Без великих попередньо навчених візуальних енкодерів — що критично для обробки кожні 200 мс.
Генерація аудіо і тексту на виході
Використовується Flow Matching — підхід де модель навчається поступово перетворювати шум на цільовий сигнал. Дає природніший голос ніж класичні вокодери.
Усі три компоненти навчалися разом — без залежності від готових великих енкодерів. Саме це дозволяє системі обробляти аудіо, відео і текст паралельно маленькими фрагментами і відповідати з затримкою близько 0.40 секунди.
Основна стаття TML для тих хто хоче заглибитися.
🔔 ПІДПИСАТИСЯ
Технічний розбір для тих кому цікаво що під капотом.
Більшість мультимодальних систем збирається з готових компонентів: Whisper для розпізнавання мови, Vision Transformer для відео, окремий LLM для мислення. TML пішла інакше — навчила всі компоненти разом з нуля. Вони називають це encoder-free early fusion.
Аудіо
Замість складного кодека аудіосигнал токенізується через dMel — прості дискретизовані мел-спектрограми. Ніякого стиснення через нейромережу — пряме перетворення частотних смуг в інтенсивність. Підхід від Apple показав що така проста токенізація працює краще ніж складні альтернативи і стійкіша до шуму та незнайомих даних.
Відео
Зображення розбивається на патчі 40x40 пікселів, ембедінги яких генерує ієрархічний багатошаровий перцептрон. Без великих попередньо навчених візуальних енкодерів — що критично для обробки кожні 200 мс.
Генерація аудіо і тексту на виході
Використовується Flow Matching — підхід де модель навчається поступово перетворювати шум на цільовий сигнал. Дає природніший голос ніж класичні вокодери.
Усі три компоненти навчалися разом — без залежності від готових великих енкодерів. Саме це дозволяє системі обробляти аудіо, відео і текст паралельно маленькими фрагментами і відповідати з затримкою близько 0.40 секунди.
Основна стаття TML для тих хто хоче заглибитися.
🔔 ПІДПИСАТИСЯ
👍9🔥2
Майбутнє AI-інтерфейсу
Завершуємо сьогоднішню серію про голосові моделі.
Новина про TML-Interaction-Small цікава не тільки сама по собі. Вона добре показує куди рухається весь AI-інтерфейс.
Ми довго жили в парадигмі чату. Користувач пише prompt → модель генерує відповідь. Потім до цього додали голос. Але голосовий режим часто залишався тим самим чатом тільки з озвучкою.
Я сам пробував це на практиці. Описав ChatGPT свій досвід тренувань, дав йому образ тренера у якого я займався — і використовував голосовий режим просто в навушниках під час тренувань. Модель тримала контекст, знала мої цілі, мала дані з Apple Watch — сон, калорії, активність. І в цілому це непогано інтегрувалося. Коли я говорив що не можу зробити підхід — вона радила знизити вагу або мотивувала продовжувати.
Але чогось не вистачало. Саме живого голосового контакту. Модель була розумною але не живою. Все одно відчувалося що розмовляєш з чат-ботом який озвучує відповіді а не з тренером який присутній поруч.
Саме це і є та межа яку намагається подолати TML. Справжній зсув починається тоді коли модель присутня в процесі. Бачить що відбувається. Чує як саме говорить користувач. Розуміє паузи, перебивання. Реагує не після ідеального запиту а в моменті.
Це відкриває сценарії які були неможливі для класичних turn-based систем: спортивний коучинг де модель бачить твою техніку руху, асистент для навчання який розуміє де ти завис, live-перекладач який не чекає завершення всього речення.
Майбутня конкуренція між моделями буде не тільки за розум. А ще й за здатність до живої взаємодії. Яка модель краще відчуває ритм людини. Яка менше ламає природний темп розмови. Яка може бути поруч у процесі а не просто відповідати після команди.
🔔 ПІДПИСАТИСЯ
Завершуємо сьогоднішню серію про голосові моделі.
Новина про TML-Interaction-Small цікава не тільки сама по собі. Вона добре показує куди рухається весь AI-інтерфейс.
Ми довго жили в парадигмі чату. Користувач пише prompt → модель генерує відповідь. Потім до цього додали голос. Але голосовий режим часто залишався тим самим чатом тільки з озвучкою.
Я сам пробував це на практиці. Описав ChatGPT свій досвід тренувань, дав йому образ тренера у якого я займався — і використовував голосовий режим просто в навушниках під час тренувань. Модель тримала контекст, знала мої цілі, мала дані з Apple Watch — сон, калорії, активність. І в цілому це непогано інтегрувалося. Коли я говорив що не можу зробити підхід — вона радила знизити вагу або мотивувала продовжувати.
Але чогось не вистачало. Саме живого голосового контакту. Модель була розумною але не живою. Все одно відчувалося що розмовляєш з чат-ботом який озвучує відповіді а не з тренером який присутній поруч.
Саме це і є та межа яку намагається подолати TML. Справжній зсув починається тоді коли модель присутня в процесі. Бачить що відбувається. Чує як саме говорить користувач. Розуміє паузи, перебивання. Реагує не після ідеального запиту а в моменті.
Це відкриває сценарії які були неможливі для класичних turn-based систем: спортивний коучинг де модель бачить твою техніку руху, асистент для навчання який розуміє де ти завис, live-перекладач який не чекає завершення всього речення.
Майбутня конкуренція між моделями буде не тільки за розум. А ще й за здатність до живої взаємодії. Яка модель краще відчуває ритм людини. Яка менше ламає природний темп розмови. Яка може бути поруч у процесі а не просто відповідати після команди.
🔔 ПІДПИСАТИСЯ
👍9
Anthropic щойно опублікувала звіт, після якого важко думати про безпеку по-старому.
Думаю, ви вже бачили тривожну новину: AI-згенерований скрипт для обходу двофакторної автентифікації. Microsoft у своєму Cyber Signals фіксує що великі мовні моделі вже використовуються не просто для фішингових листів чи генерації шкідливого коду — а для пошуку реальних вразливостей у програмному забезпеченні.
Раніше інструменти для пошуку багів працювали механічно: шукали відомі патерни, запускали fuzzing, перевіряли типові помилки. Але LLM додають інший рівень — вони можуть аналізувати логіку коду й розуміти що програма мала б робити.
І ось тут з'являється новина яка показує наскільки швидко все змінюється.
Дослідники з Calif за 5 днів зібрали exploit для macOS kernel memory corruption на Apple M5. Їм допомагала нова модель Anthropic — Claude Mythos Preview.
Тобто мова вже не про "AI допоміг написати скрипт". Мова про те що AI проходить дуже складний шлях: від аналізу коду й пошуку помилок до побудови робочого exploit для сучасної операційної системи з сильними механізмами захисту.
Claude Mythos Preview поки недоступна публічно. Anthropic описує її як модель нового класу для автономного дослідження вразливостей. І цифри там дуже показові.
Opus 4.6 майже не справлявся з автономним написанням exploits для Firefox — лише кілька успішних спроб із сотень. Mythos Preview на тому самому класі задач — 181 успішний exploit із кількох сотень спроб. Це не покращення метрик. Це зміна класу можливостей.
Модель знаходила: 27-річний баг в OpenBSD — системі яка відома своїм акцентом на безпеці; 16-річну вразливість у FFmpeg — одній із найбільш перевірених медіабібліотек у світі; 17-річну вразливість у FreeBSD яка дозволяє отримати root-доступ через мережу.
Важлива деталь: Anthropic не тренувала Mythos спеціально як security-модель. Ці можливості виникли як побічний ефект загального покращення коду, мислення і автономності.
Саме це найбільш тривожне. Якщо модель не була спеціально натренована "ламати системи" але все одно навчилася знаходити й експлуатувати складні вразливості — питання вже не в тому чи буде AI використовуватися в кібербезпеці. Питання в тому хто першим використає ці можливості проти вашого коду — ваша команда чи хтось ззовні.
Тому Anthropic не випускає Mythos Preview публічно. Натомість запустили Project Glasswing — обмежений доступ для критичної інфраструктури та open source проєктів, щоб дефендери встигли закрити найважливіше до того як подібні можливості стануть доступні ширше. Станом на 22 травня 2026 вже розкрито 1596 вразливостей у 281 open source проєкті.
AISI фіксує зростаючий розрив між здатністю LLM знаходити вразливості та можливостями широко використовуваних методів кіберзахисту. Наступні покоління LLM можуть експлуатувати баги швидше ніж команди безпеки встигатимуть впроваджувати патчі.
Я писав C++ код бiльше 12ти рокiв, який у реальному часі обробляє дані в автiвках. Це не веб-форми. Логічна вразливість у нас — це потенційна проблема безпеки за кермом. І те що раніше міг знайти тільки досвідчений security-інженер після годин ручного аналізу, тепер агент робить за ніч.
Security більше не може бути "останнім етапом" перед релізом. У світі AI-агентів і автономного дослідження вразливостей безпека має ставати частиною інженерного процесу з самого початку.
Бо AI вже не просто допомагає писати код. Він починає перевіряти де цей код можна зламати.
Хтось із вас вже налаштував автоматизований security review на базі LLM — чи поки тільки думаєте про це?
🔔 ПІДПИСАТИСЯ
Думаю, ви вже бачили тривожну новину: AI-згенерований скрипт для обходу двофакторної автентифікації. Microsoft у своєму Cyber Signals фіксує що великі мовні моделі вже використовуються не просто для фішингових листів чи генерації шкідливого коду — а для пошуку реальних вразливостей у програмному забезпеченні.
Раніше інструменти для пошуку багів працювали механічно: шукали відомі патерни, запускали fuzzing, перевіряли типові помилки. Але LLM додають інший рівень — вони можуть аналізувати логіку коду й розуміти що програма мала б робити.
І ось тут з'являється новина яка показує наскільки швидко все змінюється.
Дослідники з Calif за 5 днів зібрали exploit для macOS kernel memory corruption на Apple M5. Їм допомагала нова модель Anthropic — Claude Mythos Preview.
Тобто мова вже не про "AI допоміг написати скрипт". Мова про те що AI проходить дуже складний шлях: від аналізу коду й пошуку помилок до побудови робочого exploit для сучасної операційної системи з сильними механізмами захисту.
Claude Mythos Preview поки недоступна публічно. Anthropic описує її як модель нового класу для автономного дослідження вразливостей. І цифри там дуже показові.
Opus 4.6 майже не справлявся з автономним написанням exploits для Firefox — лише кілька успішних спроб із сотень. Mythos Preview на тому самому класі задач — 181 успішний exploit із кількох сотень спроб. Це не покращення метрик. Це зміна класу можливостей.
Модель знаходила: 27-річний баг в OpenBSD — системі яка відома своїм акцентом на безпеці; 16-річну вразливість у FFmpeg — одній із найбільш перевірених медіабібліотек у світі; 17-річну вразливість у FreeBSD яка дозволяє отримати root-доступ через мережу.
Важлива деталь: Anthropic не тренувала Mythos спеціально як security-модель. Ці можливості виникли як побічний ефект загального покращення коду, мислення і автономності.
Саме це найбільш тривожне. Якщо модель не була спеціально натренована "ламати системи" але все одно навчилася знаходити й експлуатувати складні вразливості — питання вже не в тому чи буде AI використовуватися в кібербезпеці. Питання в тому хто першим використає ці можливості проти вашого коду — ваша команда чи хтось ззовні.
Тому Anthropic не випускає Mythos Preview публічно. Натомість запустили Project Glasswing — обмежений доступ для критичної інфраструктури та open source проєктів, щоб дефендери встигли закрити найважливіше до того як подібні можливості стануть доступні ширше. Станом на 22 травня 2026 вже розкрито 1596 вразливостей у 281 open source проєкті.
AISI фіксує зростаючий розрив між здатністю LLM знаходити вразливості та можливостями широко використовуваних методів кіберзахисту. Наступні покоління LLM можуть експлуатувати баги швидше ніж команди безпеки встигатимуть впроваджувати патчі.
Я писав C++ код бiльше 12ти рокiв, який у реальному часі обробляє дані в автiвках. Це не веб-форми. Логічна вразливість у нас — це потенційна проблема безпеки за кермом. І те що раніше міг знайти тільки досвідчений security-інженер після годин ручного аналізу, тепер агент робить за ніч.
Security більше не може бути "останнім етапом" перед релізом. У світі AI-агентів і автономного дослідження вразливостей безпека має ставати частиною інженерного процесу з самого початку.
Бо AI вже не просто допомагає писати код. Він починає перевіряти де цей код можна зламати.
Хтось із вас вже налаштував автоматизований security review на базі LLM — чи поки тільки думаєте про це?
🔔 ПІДПИСАТИСЯ
👍9❤7👀2
AI-агенти найкраще замінюють тих хто їх і створює.
На початку року я писав про AGI і про те що чесніший критерій готовності агентів — не benchmark а здатність кілька днів виконувати реальну роботу поруч із людиною.
Нове дослідження Carnegie Mellon і Stanford якраз про це.
Автори взяли понад 10 000 прикладів із 43 agent benchmarks і зіставили їх із реальною структурою ринку праці США через O*NET — урядову базу де робота описується не в стилі "зробити bubble sort" а через стандартизовані робочі активності й навички. Зіставлення робили через Claude 3.5 Sonnet: приклад "реалізувати bubble sort" → робоча активність "писати, оновлювати та підтримувати комп'ютерні програми…"
Результат показовий.
Кожен окремий benchmark покривав менше ніж 50% усіх робочих активностей і менше ніж 60% навичок. Усі benchmark'и разом — 56.5% робочих активностей. Тобто майже половина реальної роботи взагалі не представлена в тестах.
І причина очевидна якщо подивитися на цифри. Benchmark'и домінують у "computer and mathematical" задачах. Але в реальній економіці США:
"computer and mathematical" — 5.2 млн людей, $563 млрд виплат на рік
"office and administrative support" — 18.2 млн людей, $869 млрд
"management" — 11 млн людей, $1.326 трлн
Є ще одна іронія яку часто згадують в мемах: ми як інженери створюємо те що замінює нас у першу чергу.
Програмна інженерія — логічний інкубатор для agentic AI. У коді найпростіше виміряти результат і побудувати feedback loop. Тому прогрес агентів тут виглядає найпереконливіше. Але найбільша економічна цінність агентів може виявитися не там де їх найзручніше тестувати.
Агенти вже підвищили продуктивність у програмній інженерії. Якщо той самий прогрес відбудеться в адміністративному, фінансовому та управлінському секторах — це торкнеться значно більшої частини економіки і значно більшої кількості людей.
Тому очікуємо що з часом з'являться benchmark'и які краще вимірюватимуть продуктивність агентів у ширшому спектрі робочих активностей. І тоді розмова про автоматизацію праці стане значно конкретнішою.
🔔 ПІДПИСАТИСЯ
На початку року я писав про AGI і про те що чесніший критерій готовності агентів — не benchmark а здатність кілька днів виконувати реальну роботу поруч із людиною.
Нове дослідження Carnegie Mellon і Stanford якраз про це.
Автори взяли понад 10 000 прикладів із 43 agent benchmarks і зіставили їх із реальною структурою ринку праці США через O*NET — урядову базу де робота описується не в стилі "зробити bubble sort" а через стандартизовані робочі активності й навички. Зіставлення робили через Claude 3.5 Sonnet: приклад "реалізувати bubble sort" → робоча активність "писати, оновлювати та підтримувати комп'ютерні програми…"
Результат показовий.
Кожен окремий benchmark покривав менше ніж 50% усіх робочих активностей і менше ніж 60% навичок. Усі benchmark'и разом — 56.5% робочих активностей. Тобто майже половина реальної роботи взагалі не представлена в тестах.
І причина очевидна якщо подивитися на цифри. Benchmark'и домінують у "computer and mathematical" задачах. Але в реальній економіці США:
"computer and mathematical" — 5.2 млн людей, $563 млрд виплат на рік
"office and administrative support" — 18.2 млн людей, $869 млрд
"management" — 11 млн людей, $1.326 трлн
Є ще одна іронія яку часто згадують в мемах: ми як інженери створюємо те що замінює нас у першу чергу.
Програмна інженерія — логічний інкубатор для agentic AI. У коді найпростіше виміряти результат і побудувати feedback loop. Тому прогрес агентів тут виглядає найпереконливіше. Але найбільша економічна цінність агентів може виявитися не там де їх найзручніше тестувати.
Агенти вже підвищили продуктивність у програмній інженерії. Якщо той самий прогрес відбудеться в адміністративному, фінансовому та управлінському секторах — це торкнеться значно більшої частини економіки і значно більшої кількості людей.
Тому очікуємо що з часом з'являться benchmark'и які краще вимірюватимуть продуктивність агентів у ширшому спектрі робочих активностей. І тоді розмова про автоматизацію праці стане значно конкретнішою.
🔔 ПІДПИСАТИСЯ
👍10
This media is not supported in your browser
VIEW IN TELEGRAM
Створи гру за допомогою AI
Натрапив на пост в X: людина створила зображення через GPT Image 2, перетворила їх на ігрові ресурси, а Codex + GPT-5.5 зібрали з цього браузерну гру з якою можна грати.
AI закриває весь творчо-технічний шлях від ідеї до працюючого прототипу. Візуальна концепція → спрайти та фони → логіка, анімації, управління.
Мені особисто ця тема близька. Як і більшість айтівців мого покоління — починав програмувати у школі щоб створити власну гру. Але завжди упирався в одне й те саме: мало вміти програмувати, потрібні ще художник, аніматор, геймдизайнер. Читав "Кров і пікселі" про Stardew Valley — людина зробила гру сама але за ціну кількох років і серйозних жертв усієї родини. Далеко не кожен може собі таке дозволити.
Тепер частина цього бар'єру зникає. Це ще не заміна повноцінної команди — хороший продукт потребує смаку і якості. Але як інструмент для швидкого proof-of-concept це вже новий стандарт.
Можливо в якийсь відпуск нарешті закрию цей ґештальт 😄
🔔 ПІДПИСАТИСЯ
Натрапив на пост в X: людина створила зображення через GPT Image 2, перетворила їх на ігрові ресурси, а Codex + GPT-5.5 зібрали з цього браузерну гру з якою можна грати.
AI закриває весь творчо-технічний шлях від ідеї до працюючого прототипу. Візуальна концепція → спрайти та фони → логіка, анімації, управління.
Мені особисто ця тема близька. Як і більшість айтівців мого покоління — починав програмувати у школі щоб створити власну гру. Але завжди упирався в одне й те саме: мало вміти програмувати, потрібні ще художник, аніматор, геймдизайнер. Читав "Кров і пікселі" про Stardew Valley — людина зробила гру сама але за ціну кількох років і серйозних жертв усієї родини. Далеко не кожен може собі таке дозволити.
Тепер частина цього бар'єру зникає. Це ще не заміна повноцінної команди — хороший продукт потребує смаку і якості. Але як інструмент для швидкого proof-of-concept це вже новий стандарт.
Можливо в якийсь відпуск нарешті закрию цей ґештальт 😄
🔔 ПІДПИСАТИСЯ
3👍7🔥5
Продовжую тему зі створення ігор через AI
Спробував промпт для HUD і результат на скріншоті. Вийшло непогано з першого разу.
Найкорисніша порада з community: не намагатися одразу отримати ідеальний sprite sheet одним промптом. Правильний підхід — спочатку згенерувати повний sheet, потім уточнювати окремі кадри, а Codex використовувати щоб розрізати sheet і обробити frames по одному.
Із showcase OpenAI найбільше сподобався Theme Park Builder — GPT Image генерував sprites для атракціонів, магазинів і гостей, а Codex збирав ігровий цикл з грошима, чистотою і рейтингом. Workflow той самий що ми обговорювали в попередньому пості.
Пам'ятаю як у 90-х грав у Theme Park на Sega. А нещодавно публікував розбір книги Supremacy — і там було описано що Демis Гасабіс, той самий який заснував і очолив Google DeepMind, розробляв цю гру в 90-х. І саме в ній він хотів реалізувати можливості штучного інтелекту — але на той момент це не вдалося, хоча гра вже тоді вирізнялася рішеннями нетиповими для свого часу.
🔔 ПІДПИСАТИСЯ
Спробував промпт для HUD і результат на скріншоті. Вийшло непогано з першого разу.
Найкорисніша порада з community: не намагатися одразу отримати ідеальний sprite sheet одним промптом. Правильний підхід — спочатку згенерувати повний sheet, потім уточнювати окремі кадри, а Codex використовувати щоб розрізати sheet і обробити frames по одному.
Із showcase OpenAI найбільше сподобався Theme Park Builder — GPT Image генерував sprites для атракціонів, магазинів і гостей, а Codex збирав ігровий цикл з грошима, чистотою і рейтингом. Workflow той самий що ми обговорювали в попередньому пості.
Пам'ятаю як у 90-х грав у Theme Park на Sega. А нещодавно публікував розбір книги Supremacy — і там було описано що Демis Гасабіс, той самий який заснував і очолив Google DeepMind, розробляв цю гру в 90-х. І саме в ній він хотів реалізувати можливості штучного інтелекту — але на той момент це не вдалося, хоча гра вже тоді вирізнялася рішеннями нетиповими для свого часу.
🔔 ПІДПИСАТИСЯ
1👍7👏4❤3
This media is not supported in your browser
VIEW IN TELEGRAM
Stable Audio 3.0 від Stability AI — сімейство моделей для генерації музики та звукових ефектів за текстовим описом 🎵
Зараз можна самостійно створювати візуал і збирати ігровий прототип через AI. Але в іграх є ще один важливий шар — звук.
Виникає логічне питання: є ж Suno, навіщо ще якась модель?
Suno сильніший для готових пісень із вокалом під ключ. Stable Audio 3.0 цікавіша як інструмент для розробника: звукові ефекти, інструментальна музика, ambience, редагування аудіо. Не "зроби мені хіт" а "дай інструмент для вбудовування звуку в продукт".
І головна перевага — open-weight. Компактна модель Small SFX запускається на звичайному залізі без серверної інфраструктури. Для інді-розробки і прототипування це дуже практично.
Хто планує працювати зі звуковими ефектами - зберігайте собі. Може хтось вже пробував?
🔔 ПІДПИСАТИСЯ
Зараз можна самостійно створювати візуал і збирати ігровий прототип через AI. Але в іграх є ще один важливий шар — звук.
Виникає логічне питання: є ж Suno, навіщо ще якась модель?
Suno сильніший для готових пісень із вокалом під ключ. Stable Audio 3.0 цікавіша як інструмент для розробника: звукові ефекти, інструментальна музика, ambience, редагування аудіо. Не "зроби мені хіт" а "дай інструмент для вбудовування звуку в продукт".
І головна перевага — open-weight. Компактна модель Small SFX запускається на звичайному залізі без серверної інфраструктури. Для інді-розробки і прототипування це дуже практично.
Хто планує працювати зі звуковими ефектами - зберігайте собі. Може хтось вже пробував?
🔔 ПІДПИСАТИСЯ
1👍8🎉2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
На фоні появи нових image-моделей особливо цікаво дивитися на проєкти які йдуть далі за генерацію картинок.
Добрий ранок ☕️
CADAM — open-source text-to-CAD інструмент який дозволяє описати об'єкт текстом або дати image reference і отримати 3D-модель у форматах .STL, .SCAD або .DXF.
LLM генерує OpenSCAD-код який рендериться у браузері. Тобто це AI який пише параметричну CAD-модель: розміри, форми, отвори, симетрія, параметри, експорт у формати для 3D-друку. Це конкретний інженерний опис об'єктів.
Далi це може виглядати так: "зроби корпус для плати з такими розмірами, отворами під гвинти, вентиляцією і можливістю друку без підтримок". Ось тут AI + CAD може реально змінити дрібне інженерне виробництво.
Після університету я працював в Moduleworks де розробляли CAD-CAM системи. Працював над C++ алгоритмами геометрії. Це був 2013 рік. У мене вже тоді виникали думки про те як нейромережі могли б допомогти в окремих частинах цього проекту — але цi наробiтки так i залишились пiд пилом в SVN 😅
🔔 ПІДПИСАТИСЯ
Добрий ранок ☕️
CADAM — open-source text-to-CAD інструмент який дозволяє описати об'єкт текстом або дати image reference і отримати 3D-модель у форматах .STL, .SCAD або .DXF.
LLM генерує OpenSCAD-код який рендериться у браузері. Тобто це AI який пише параметричну CAD-модель: розміри, форми, отвори, симетрія, параметри, експорт у формати для 3D-друку. Це конкретний інженерний опис об'єктів.
Далi це може виглядати так: "зроби корпус для плати з такими розмірами, отворами під гвинти, вентиляцією і можливістю друку без підтримок". Ось тут AI + CAD може реально змінити дрібне інженерне виробництво.
Після університету я працював в Moduleworks де розробляли CAD-CAM системи. Працював над C++ алгоритмами геометрії. Це був 2013 рік. У мене вже тоді виникали думки про те як нейромережі могли б допомогти в окремих частинах цього проекту — але цi наробiтки так i залишились пiд пилом в SVN 😅
🔔 ПІДПИСАТИСЯ
1👍10🔥5❤2👎1
Open-weights моделі поступово переходять у нову фазу.
Гарного вівторка! 👋
Минулий місяць був місяцем відкритих моделей — вийшла нова Kimi і потужний DeepSeek V4, я детально їх розбирав. Але незаслужено пропустив ще одну китайську модель — GLM-5.1 від Z.ai.
Може виникнути логічне питання: навіщо ще одна якщо є Kimi K2.6?
Обидві моделі грають у довгі агентні задачі. Але акцент різний.
GLM-5.1 позиціонується як модель для тривалих інженерних задач. Z.ai прямо вказує що вона може автономно працювати над одним завданням до 8 годин: планувати, виконувати кроки, перевіряти результат, оптимізувати підхід.
Kimi K2.6 ширша: текст, зображення і відео, 256K контекст, мультиагентна оркестрація. Орієнтована не тільки на код а й на UI, дизайн, frontend, DevOps.
Тобто різниця така:
GLM це агент який довго тримає одну складну інженерну задачу. Краще для великих репозиторіїв, тестів, рефакторингу, CI/CD.
Kimi це мультимодальний агент для продуктових процесів. Краще для UI, скриншотів, дизайну, full-stack прототипів.
Я як інженер не тільки писав код а й постійно налагоджував пайплайни, тести і CI/CD — це невід'ємна частина розробки. І певний рівень автоматизації тут критично важливий щоб уникати людських помилок і економити час.
Реальна інженерна цінність AI в тому що він може пройти весь шлях: від задачі → аналізу → коду → тестів → помилок → виправлень → стабільного результату.
Open-weights моделі вже заходять саме в цю зону. І саме тут починається наступний етап конкуренції — хто довше й надійніше може працювати на реальній задачі.
Хтось із вас вже пробував GLM-5.1 або Kimi K2.6 в агентному процесі — через Cline, Cursor чи власну систему?
🔔 ПІДПИСАТИСЯ
Гарного вівторка! 👋
Минулий місяць був місяцем відкритих моделей — вийшла нова Kimi і потужний DeepSeek V4, я детально їх розбирав. Але незаслужено пропустив ще одну китайську модель — GLM-5.1 від Z.ai.
Може виникнути логічне питання: навіщо ще одна якщо є Kimi K2.6?
Обидві моделі грають у довгі агентні задачі. Але акцент різний.
GLM-5.1 позиціонується як модель для тривалих інженерних задач. Z.ai прямо вказує що вона може автономно працювати над одним завданням до 8 годин: планувати, виконувати кроки, перевіряти результат, оптимізувати підхід.
Kimi K2.6 ширша: текст, зображення і відео, 256K контекст, мультиагентна оркестрація. Орієнтована не тільки на код а й на UI, дизайн, frontend, DevOps.
Тобто різниця така:
GLM це агент який довго тримає одну складну інженерну задачу. Краще для великих репозиторіїв, тестів, рефакторингу, CI/CD.
Kimi це мультимодальний агент для продуктових процесів. Краще для UI, скриншотів, дизайну, full-stack прототипів.
Я як інженер не тільки писав код а й постійно налагоджував пайплайни, тести і CI/CD — це невід'ємна частина розробки. І певний рівень автоматизації тут критично важливий щоб уникати людських помилок і економити час.
Реальна інженерна цінність AI в тому що він може пройти весь шлях: від задачі → аналізу → коду → тестів → помилок → виправлень → стабільного результату.
Open-weights моделі вже заходять саме в цю зону. І саме тут починається наступний етап конкуренції — хто довше й надійніше може працювати на реальній задачі.
Хтось із вас вже пробував GLM-5.1 або Kimi K2.6 в агентному процесі — через Cline, Cursor чи власну систему?
🔔 ПІДПИСАТИСЯ
🔥5👍4
Доброго ранку! ☕️ Знову середа — і черговий розбір наукової статті.
Якщо ви пробували генерувати зображення — впевнений стикалися з цією проблемою. Промпт конкретний: "ведмідь завис над срібною ложкою". А модель малює ведмедя поруч із ложкою або в дивній композиції де формально все є але просторовий сенс втрачено.
T2I-CompBench++ підтверджує: навіть сильні text-to-image моделі системно помиляються в композиційних задачах — коли треба правильно зв'язати об'єкти, атрибути, кількість і просторові відношення.
Нова робота Think in Strokes, Not Pixels пропонує цікаву ідею: можливо зображення не треба генерувати "одним пострілом". Варто навчити модель створювати сцену поетапно — майже як художник.
Схема (у статті: textual planning, visual drafting, textual reflection, visual refinement):
1. Plan — модель формулює що саме додати на наступному кроці
2. Sketch — генерує проміжне зображення
3. Inspect — перевіряє чи відповідає результат промпту
4. Refine — формулює виправлення і повторює цикл
Ключовий момент: кожен наступний крок ґрунтується не тільки на тексті промпту а й на поточному візуальному стані. Тобто модель бачить що вже намальовано і вирішує як саме це змінити далі.
Для навчання автори взяли BAGEL-7B — unified multimodal model яка не лише розуміє текст і зображення а й може генерувати мультимодальний результат. GPT-4o перетворював промпти з двох датасетів у scene graphs. Зображення для кожного кроку генерували через FLUX.1 Kontext і залишали тільки ті проміжні результати які автоматична перевірка через GPT-4o визнала узгодженими з інструкцією. Датасет для plan/sketch — близько 32 000 прикладів. Окремо модель навчали етапу inspect на ~7 000 коректних і ~8 000 прикладів із помилками.
Тобто модель навчали не тільки малювати а й критикувати власний проміжний результат.
Результати на WISE — BAGEL піднявся з 0.70 до 0.76. На GenEval з 77% до 83%. Особливо покращилися сцени зі складними просторовими відношеннями.
Тут є цікава паралель з LLM. Ми вже звикли що мовні моделі краще справляються зі складними задачами коли розбивають їх на кроки. Тепер схожий підхід переносять у генерацію зображень.
Важливо: це не означає що проблема повністю вирішена. Метод показує напрямок — зробити генерацію більш контрольованою і перевірюваною. Але це поки дослідницький підхід а не стандарт у кожному image generator.
Справжня цінність тут не тільки в якості картинки а в появі керованого процесу: модель має план, проміжний стан, самоперевірку і механізм виправлення. Це вже ближче до візуального агента ніж до "магічного автомату для красивих картинок".
Сьогодні картинки. Завтра — відео, 3D-сцени, ігрові рівні.
🔔 ПІДПИСАТИСЯ
Якщо ви пробували генерувати зображення — впевнений стикалися з цією проблемою. Промпт конкретний: "ведмідь завис над срібною ложкою". А модель малює ведмедя поруч із ложкою або в дивній композиції де формально все є але просторовий сенс втрачено.
T2I-CompBench++ підтверджує: навіть сильні text-to-image моделі системно помиляються в композиційних задачах — коли треба правильно зв'язати об'єкти, атрибути, кількість і просторові відношення.
Нова робота Think in Strokes, Not Pixels пропонує цікаву ідею: можливо зображення не треба генерувати "одним пострілом". Варто навчити модель створювати сцену поетапно — майже як художник.
Схема (у статті: textual planning, visual drafting, textual reflection, visual refinement):
1. Plan — модель формулює що саме додати на наступному кроці
2. Sketch — генерує проміжне зображення
3. Inspect — перевіряє чи відповідає результат промпту
4. Refine — формулює виправлення і повторює цикл
Ключовий момент: кожен наступний крок ґрунтується не тільки на тексті промпту а й на поточному візуальному стані. Тобто модель бачить що вже намальовано і вирішує як саме це змінити далі.
Для навчання автори взяли BAGEL-7B — unified multimodal model яка не лише розуміє текст і зображення а й може генерувати мультимодальний результат. GPT-4o перетворював промпти з двох датасетів у scene graphs. Зображення для кожного кроку генерували через FLUX.1 Kontext і залишали тільки ті проміжні результати які автоматична перевірка через GPT-4o визнала узгодженими з інструкцією. Датасет для plan/sketch — близько 32 000 прикладів. Окремо модель навчали етапу inspect на ~7 000 коректних і ~8 000 прикладів із помилками.
Тобто модель навчали не тільки малювати а й критикувати власний проміжний результат.
Результати на WISE — BAGEL піднявся з 0.70 до 0.76. На GenEval з 77% до 83%. Особливо покращилися сцени зі складними просторовими відношеннями.
Тут є цікава паралель з LLM. Ми вже звикли що мовні моделі краще справляються зі складними задачами коли розбивають їх на кроки. Тепер схожий підхід переносять у генерацію зображень.
Важливо: це не означає що проблема повністю вирішена. Метод показує напрямок — зробити генерацію більш контрольованою і перевірюваною. Але це поки дослідницький підхід а не стандарт у кожному image generator.
Справжня цінність тут не тільки в якості картинки а в появі керованого процесу: модель має план, проміжний стан, самоперевірку і механізм виправлення. Це вже ближче до візуального агента ніж до "магічного автомату для красивих картинок".
Сьогодні картинки. Завтра — відео, 3D-сцени, ігрові рівні.
🔔 ПІДПИСАТИСЯ
🔥7👍3❤1
AI-агенти вже почали переписувати правила інтернету.
Доброго ранку ☕️
За даними звіту Human Security, AI-driven трафік — взаємодії згенеровані AI-системами або виконані від їхнього імені — майже потроївся у 2025 році.
68% цього трафіку становлять crawlers які збирають дані для навчання моделей. Ще 32% — scrapers для збору цін, наявності товарів, умов бронювання. А найцікавіша категорія — AI-агенти та агентні браузери. Їхня частка поки мала але за рік зросла майже у 80 разів.
77% агентних взаємодій відбувалися на сторінках товарів і пошуку. Тобто агенти вже поводяться як користувачі: шукають, порівнюють, аналізують. Частина активності також була пов'язана зі сторінками акаунтів, автентифікацією і транзакціями.
І тут починається найцікавіше з точки зору кібербезпеки.
Легітимний AI-агент дуже схожий на бота. Він швидко відкриває сторінки, порівнює товари, може проходити авторизацію і виконувати транзакції. Раніше така поведінка була сигналом атаки. Тепер це може бути нормальна поведінка AI-асистента.
Я вже бачив у мережі кілька прикладів де агенти помилково замовляли їжу — приїжджав кур'єр а людина не була в курсі замовлення. І в коментарі до замовлення фігурував Claude. Смішно але показово: старі правила виявлення ботів починають ламатися а нові ще не сформовані.
Паралельно malicious scraping зріс на 47%. Атаки на акаунти загалом зменшилися але стали небезпечнішими: у 4 рази зросла кількість атак після входу в акаунт. Тобто проблема зміщується від "зламати логін" до використання вже активних акаунтів.
Агентний трафік лише починається. 80-кратне зростання минулого року ймовірно ще багато разів посилиться коли агенти стануть надійнішими і масовішими. Інфраструктуру потрібно будувати або модернізувати з урахуванням цього вже зараз.
Інтернет який ми знаємо будувався навколо людини-користувача. Наступний етап — інтернет де значну частину дій виконуватимуть агенти. Сайтам доведеться навчитися відповідати на нові питання: як відрізнити корисного AI-агента від шкідливого бота, як дозволити агенту купувати але не красти дані, як зміниться SEO коли сторінки читатимуть не тільки люди.
Веб перебудовуватиметься під агентів: не лише як нових "читачів" контенту, а як повноцінних акторів які діють, купують і приймають рішення.
Повний звіт
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
За даними звіту Human Security, AI-driven трафік — взаємодії згенеровані AI-системами або виконані від їхнього імені — майже потроївся у 2025 році.
68% цього трафіку становлять crawlers які збирають дані для навчання моделей. Ще 32% — scrapers для збору цін, наявності товарів, умов бронювання. А найцікавіша категорія — AI-агенти та агентні браузери. Їхня частка поки мала але за рік зросла майже у 80 разів.
77% агентних взаємодій відбувалися на сторінках товарів і пошуку. Тобто агенти вже поводяться як користувачі: шукають, порівнюють, аналізують. Частина активності також була пов'язана зі сторінками акаунтів, автентифікацією і транзакціями.
І тут починається найцікавіше з точки зору кібербезпеки.
Легітимний AI-агент дуже схожий на бота. Він швидко відкриває сторінки, порівнює товари, може проходити авторизацію і виконувати транзакції. Раніше така поведінка була сигналом атаки. Тепер це може бути нормальна поведінка AI-асистента.
Я вже бачив у мережі кілька прикладів де агенти помилково замовляли їжу — приїжджав кур'єр а людина не була в курсі замовлення. І в коментарі до замовлення фігурував Claude. Смішно але показово: старі правила виявлення ботів починають ламатися а нові ще не сформовані.
Паралельно malicious scraping зріс на 47%. Атаки на акаунти загалом зменшилися але стали небезпечнішими: у 4 рази зросла кількість атак після входу в акаунт. Тобто проблема зміщується від "зламати логін" до використання вже активних акаунтів.
Агентний трафік лише починається. 80-кратне зростання минулого року ймовірно ще багато разів посилиться коли агенти стануть надійнішими і масовішими. Інфраструктуру потрібно будувати або модернізувати з урахуванням цього вже зараз.
Інтернет який ми знаємо будувався навколо людини-користувача. Наступний етап — інтернет де значну частину дій виконуватимуть агенти. Сайтам доведеться навчитися відповідати на нові питання: як відрізнити корисного AI-агента від шкідливого бота, як дозволити агенту купувати але не красти дані, як зміниться SEO коли сторінки читатимуть не тільки люди.
Веб перебудовуватиметься під агентів: не лише як нових "читачів" контенту, а як повноцінних акторів які діють, купують і приймають рішення.
Повний звіт
🔔 ПІДПИСАТИСЯ
👍13❤5🔥3
10 речей про LLM які варто знати 1/10 🧠
Prompt engineering — це не зовсім "інженерія промптів"
Ще рік тому з'являлися цілі курси про те як правильно писати промпти. Але пройшов рік — і ми бачимо наскільки якість промптів стала менш важливою. LLM самі навчилися писати промпти, а більшої значущості набув context engineering про який я вже писав раніше.
Щоб зрозуміти чому — потрібно розуміти як LLM взагалі працюють.
LLM не знають фактів і не виконують промпт як програмний код. GPT-подібні моделі прогнозують наступні токени на основі попереднього контексту — саме так це описано в роботі про GPT-3 Language Models are Few-Shot Learners яку ми розбираємо зі студентами на лекціях.
Тобто промпт — це не кнопка "зроби X". Це контекстний сигнал. Він задає моделі рамку: про що ми говоримо, у якій ролі має відповідати, який стиль очікується, для кого текст, які обмеження важливі.
Тому мені дедалі більше подобається інша назва — semantic framing. Семантичне фреймування. Ми не пишемо інструкцію — ми конструюємо контекст який допомагає моделі зрозуміти в якому режимі їй треба продовжувати текст.
Якщо промпт — це постріл у темряву він дає слабкий результат не тому що модель "дурна" а тому що ми дали занадто розмиту рамку.
"Напиши пост про AI" — широкий сигнал. Модель не знає для кого, у якому стилі, з якою позицією.
"Напиши Telegram-пост українською для інженерної аудиторії. Тон — публіцистично-науковий. Поясни чому X. Заверши практичним висновком." — це вже рамка. Модель отримує роль, аудиторію, стиль і комунікативний намір.
Хороше промптування — це не магія і не список "секретних фраз". Це вміння правильно задати семантичну рамку: хто говорить, кому, навіщо, у якому стилі, з якими обмеженнями.
Чим сильніше ви звужуєте ймовірнісні шляхи моделі — тим менше вона блукає у просторі можливих відповідей.
Зберігай щоб не загубити, а наступного четверга — ще один важливий факт про LLM: контекстні вікна 👀
🔔 ПІДПИСАТИСЯ
Prompt engineering — це не зовсім "інженерія промптів"
Ще рік тому з'являлися цілі курси про те як правильно писати промпти. Але пройшов рік — і ми бачимо наскільки якість промптів стала менш важливою. LLM самі навчилися писати промпти, а більшої значущості набув context engineering про який я вже писав раніше.
Щоб зрозуміти чому — потрібно розуміти як LLM взагалі працюють.
LLM не знають фактів і не виконують промпт як програмний код. GPT-подібні моделі прогнозують наступні токени на основі попереднього контексту — саме так це описано в роботі про GPT-3 Language Models are Few-Shot Learners яку ми розбираємо зі студентами на лекціях.
Тобто промпт — це не кнопка "зроби X". Це контекстний сигнал. Він задає моделі рамку: про що ми говоримо, у якій ролі має відповідати, який стиль очікується, для кого текст, які обмеження важливі.
Тому мені дедалі більше подобається інша назва — semantic framing. Семантичне фреймування. Ми не пишемо інструкцію — ми конструюємо контекст який допомагає моделі зрозуміти в якому режимі їй треба продовжувати текст.
Якщо промпт — це постріл у темряву він дає слабкий результат не тому що модель "дурна" а тому що ми дали занадто розмиту рамку.
"Напиши пост про AI" — широкий сигнал. Модель не знає для кого, у якому стилі, з якою позицією.
"Напиши Telegram-пост українською для інженерної аудиторії. Тон — публіцистично-науковий. Поясни чому X. Заверши практичним висновком." — це вже рамка. Модель отримує роль, аудиторію, стиль і комунікативний намір.
Хороше промптування — це не магія і не список "секретних фраз". Це вміння правильно задати семантичну рамку: хто говорить, кому, навіщо, у якому стилі, з якими обмеженнями.
Чим сильніше ви звужуєте ймовірнісні шляхи моделі — тим менше вона блукає у просторі можливих відповідей.
Зберігай щоб не загубити, а наступного четверга — ще один важливий факт про LLM: контекстні вікна 👀
🔔 ПІДПИСАТИСЯ
arXiv.org
Language Models are Few-Shot Learners
Recent work has demonstrated substantial gains on many NLP tasks and benchmarks by pre-training on a large corpus of text followed by fine-tuning on a specific task. While typically task-agnostic...
👍13❤2💯1
🇪🇺 Європа натискає на гальма в регулюванні AI
Добрий ранок та гарних вихiдних! Трошки вирiшив розбавити технiчнi розмови геополiтекою навколо AI ☕️
ЄС, який ще недавно хотів бути головним регулятором штучного інтелекту у світі, починає пом'якшувати власний AI Act.
Причина проста: бізнес і частина політиків дедалі голосніше кажуть що надмірне регулювання робить європейські компанії менш конкурентними порівняно з США та Китаєм.
Що змінюється — вимоги до "високоризикових" AI-систем у правоохоронній сфері, критичній інфраструктурі, працевлаштуванні та персональній ідентифікації відкладаються з серпня 2026 до грудня 2027 року. Окремі дедлайни для AI-продуктів переносяться до серпня 2028. Вимоги щодо watermarking AI-контенту та прозорості — приблизно до грудня 2026. Також спрощують процедури для малого бізнесу щоб compliance не перетворився на окремий бюрократичний квест.
Цікавий момент: в одному напрямі регулювання навпаки посилюють — забороняють генерацію сексуалізованих зображень дітей і несанкціонованих інтимних зображень реальних людей.
І ось тут починається найцікавіше.
AI Act спочатку будувався навколо ідеї "системних ризиків" — ризиків які можуть впливати не на окрему людину а на цілі сектори економіки. Поняття запозичене з фінансового регулювання. Але проблема в тому що частина цих ризиків залишається спекулятивною. Натомість ризик надмірного регулювання дуже конкретний: компанії витрачають ресурси не на розробку а на юридичну адаптацію і документацію.
Поправки мають на меті збалансувати ризики й переваги: зменшити навантаження на розробників, дати компаніям більше часу щоб зрозуміти вимоги і відкрити шлях для інновацій у критичних галузях. Самі поправки ще очікують офіційного прийняття.
Європа вже має структурну проблему: фрагментований ринок, 27 національних юрисдикцій, слабше масштабування технологічних компаній порівняно з США та Китаєм. Якщо поверх цього накласти надто важкий регуляторний шар — можна отримати ситуацію де ЄС стане не лідером AI-безпеки а територією де інновації просто повільніше доходять до ринку.
Багато положень оригінального AI Act були нечіткими або надто широкими. Ці зміни схоже роблять закон менш обтяжливим зберігаючи корисні елементи. Це хороший крок для конкурентоспроможності Європи.
Навіть Європа яка традиційно робить ставку на регулювання починає визнавати: у гонці AI недостатньо просто "захищати громадян". Потрібно ще не задушити власну індустрію до того як вона встигне вирости.
🔔 ПІДПИСАТИСЯ
Добрий ранок та гарних вихiдних! Трошки вирiшив розбавити технiчнi розмови геополiтекою навколо AI ☕️
ЄС, який ще недавно хотів бути головним регулятором штучного інтелекту у світі, починає пом'якшувати власний AI Act.
Причина проста: бізнес і частина політиків дедалі голосніше кажуть що надмірне регулювання робить європейські компанії менш конкурентними порівняно з США та Китаєм.
Що змінюється — вимоги до "високоризикових" AI-систем у правоохоронній сфері, критичній інфраструктурі, працевлаштуванні та персональній ідентифікації відкладаються з серпня 2026 до грудня 2027 року. Окремі дедлайни для AI-продуктів переносяться до серпня 2028. Вимоги щодо watermarking AI-контенту та прозорості — приблизно до грудня 2026. Також спрощують процедури для малого бізнесу щоб compliance не перетворився на окремий бюрократичний квест.
Цікавий момент: в одному напрямі регулювання навпаки посилюють — забороняють генерацію сексуалізованих зображень дітей і несанкціонованих інтимних зображень реальних людей.
І ось тут починається найцікавіше.
AI Act спочатку будувався навколо ідеї "системних ризиків" — ризиків які можуть впливати не на окрему людину а на цілі сектори економіки. Поняття запозичене з фінансового регулювання. Але проблема в тому що частина цих ризиків залишається спекулятивною. Натомість ризик надмірного регулювання дуже конкретний: компанії витрачають ресурси не на розробку а на юридичну адаптацію і документацію.
Поправки мають на меті збалансувати ризики й переваги: зменшити навантаження на розробників, дати компаніям більше часу щоб зрозуміти вимоги і відкрити шлях для інновацій у критичних галузях. Самі поправки ще очікують офіційного прийняття.
Європа вже має структурну проблему: фрагментований ринок, 27 національних юрисдикцій, слабше масштабування технологічних компаній порівняно з США та Китаєм. Якщо поверх цього накласти надто важкий регуляторний шар — можна отримати ситуацію де ЄС стане не лідером AI-безпеки а територією де інновації просто повільніше доходять до ринку.
Багато положень оригінального AI Act були нечіткими або надто широкими. Ці зміни схоже роблять закон менш обтяжливим зберігаючи корисні елементи. Це хороший крок для конкурентоспроможності Європи.
Навіть Європа яка традиційно робить ставку на регулювання починає визнавати: у гонці AI недостатньо просто "захищати громадян". Потрібно ще не задушити власну індустрію до того як вона встигне вирости.
🔔 ПІДПИСАТИСЯ
👍10❤2
Друзі, доброго вечора! 👋
Дійшли руки створити YouTube-канал як ви і хотіли 🙂
Нажаль часу на зйомки майже немає але буду намагатися інколи записувати щось цікаве. Формат відео-лекції дозволяє більш розгорнуто розкривати тему ніж пост у Telegram.
Підпишіться щоб не пропустити. А поки — перше відео для вас 👇
https://youtu.be/1XqpgxPp7KY
🔔 ПІДПИСАТИСЯ
Дійшли руки створити YouTube-канал як ви і хотіли 🙂
Нажаль часу на зйомки майже немає але буду намагатися інколи записувати щось цікаве. Формат відео-лекції дозволяє більш розгорнуто розкривати тему ніж пост у Telegram.
Підпишіться щоб не пропустити. А поки — перше відео для вас 👇
https://youtu.be/1XqpgxPp7KY
🔔 ПІДПИСАТИСЯ
3🔥12❤4👍4👏1
This media is not supported in your browser
VIEW IN TELEGRAM
Доброго ранку! ☕️
Натрапив на цікаву модель для генерації говорячих аватарів.
LongCat-Video-Avatar 1.5 від Meituan LongCat Team генерує відео говорячого персонажа по аудіо і зображенню або текстовому опису. На вхід даєш голос і фото — на виході отримуєш відео де людина говорить із синхронізацією губ, мімікою і збереженням ідентичності.
Модель побудована на базі LongCat-Video з 13.6B параметрів, код і ваги відкриті, ліцензія MIT. Раніше подібна якість частіше була доступна через закриті комерційні сервіси. Як аудіоенкодер використовується Whisper-Large — що дає точнішу синхронізацію губ ніж у попередній версії. Підтримуються стилізовані персонажі: anime, тварини, digital humans. Є підтримка мультиперсонажних сцен з кількома аудіопотоками.
Як аудіоенкодер використовується Whisper-Large-v3 — навчений на 680 000 годин мовлення 99 мовами включно з українською. Офіційний benchmark тестувався на китайській та англійській, але підтримка інших мов випливає з архітектури самого Whisper.
🔔 ПІДПИСАТИСЯ
Натрапив на цікаву модель для генерації говорячих аватарів.
LongCat-Video-Avatar 1.5 від Meituan LongCat Team генерує відео говорячого персонажа по аудіо і зображенню або текстовому опису. На вхід даєш голос і фото — на виході отримуєш відео де людина говорить із синхронізацією губ, мімікою і збереженням ідентичності.
Модель побудована на базі LongCat-Video з 13.6B параметрів, код і ваги відкриті, ліцензія MIT. Раніше подібна якість частіше була доступна через закриті комерційні сервіси. Як аудіоенкодер використовується Whisper-Large — що дає точнішу синхронізацію губ ніж у попередній версії. Підтримуються стилізовані персонажі: anime, тварини, digital humans. Є підтримка мультиперсонажних сцен з кількома аудіопотоками.
Як аудіоенкодер використовується Whisper-Large-v3 — навчений на 680 000 годин мовлення 99 мовами включно з українською. Офіційний benchmark тестувався на китайській та англійській, але підтримка інших мов випливає з архітектури самого Whisper.
🔔 ПІДПИСАТИСЯ
👍7❤5🔥4