Kimi K2.6 від Moonshot AI — Що якщо запустити сотні AI-агентів паралельно і платити тільки за електрику?
Відповідь проста: саме це і пропонує нова модель від Moonshot AI. Її можна запустити на власному сервері і платити тільки за електрику.
Moonshot AI випустила модель на 1 трильйон параметрів з яких 32 млрд активні на кожен токен — Mixture of Experts з vision encoder для роботи із зображеннями і відео, контекст до 256 000 токенів. Модель повністю у відкритому доступі.
За незалежними оцінками вона знаходиться приблизно на рівні Qwen3.6 Preview і DeepSeek V4 який ми розбирали минулого разу. Закриті моделі — GPT-5.5, Claude Opus 4.7, Gemini — поки сильніші. Але коли модель безкоштовна і запускається локально — це вже інша розмова про вартість результату.
Але справжня цікавість в тому що модель вміє робити.
Наприкінці 2025 року коли почав набирати популярність Claude Code з'явилася нова неформальна метрика: здатність залишатися на завданні годинами і працювати автономно. Саме в цьому напрямку зараз змагаються Claude Code від Anthropic, Codex від OpenAI і Qwen Coder від Alibaba.
Kimi K2.6 теж рухається туди. У режимі agent swarm координатор розбиває задачу і може створювати до 300 паралельних субагентів які разом виконують до 4000 кроків. Попередня версія давала до 100 агентів і 1500 кроків.
Moonshot показала конкретний тест: модель отримала завдання перенести inference-код на Zig і оптимізувати під Mac. Після понад 4000 викликів інструментів, 14 ревізій і більш ніж 12 годин роботи — продуктивність зросла з 15 до 193 токенів на секунду. Для платної закритої моделі такий сеанс коштував би дуже дорого. На власному сервері з Kimi — тільки світло.
І тут є цікава думка про галюцинації.
Показник у K2.6 — 39.26% проти 64.6% у попередньої версії. Читаючи про різні моделі і як розробники борються з цією проблемою — і в GPT-5.5 і в DeepSeek V4 — у мене виникла думка. Рівень галюцинацій зменшується не тому що модель перестає помилятися. А тому що автономна модель може перевірити свою роботу, знайти помилку і виправити її. Тобто ми уникаємо галюцинацій не на вході а в процесі — через самокорекцію.
Якщо open-weights модель може стабільно працювати годинами над складними задачами і робити це безкоштовно на власній інфраструктурі — це вже серйозний аргумент для тих хто рахує витрати.
🔔 ПІДПИСАТИСЯ
Відповідь проста: саме це і пропонує нова модель від Moonshot AI. Її можна запустити на власному сервері і платити тільки за електрику.
Moonshot AI випустила модель на 1 трильйон параметрів з яких 32 млрд активні на кожен токен — Mixture of Experts з vision encoder для роботи із зображеннями і відео, контекст до 256 000 токенів. Модель повністю у відкритому доступі.
За незалежними оцінками вона знаходиться приблизно на рівні Qwen3.6 Preview і DeepSeek V4 який ми розбирали минулого разу. Закриті моделі — GPT-5.5, Claude Opus 4.7, Gemini — поки сильніші. Але коли модель безкоштовна і запускається локально — це вже інша розмова про вартість результату.
Але справжня цікавість в тому що модель вміє робити.
Наприкінці 2025 року коли почав набирати популярність Claude Code з'явилася нова неформальна метрика: здатність залишатися на завданні годинами і працювати автономно. Саме в цьому напрямку зараз змагаються Claude Code від Anthropic, Codex від OpenAI і Qwen Coder від Alibaba.
Kimi K2.6 теж рухається туди. У режимі agent swarm координатор розбиває задачу і може створювати до 300 паралельних субагентів які разом виконують до 4000 кроків. Попередня версія давала до 100 агентів і 1500 кроків.
Moonshot показала конкретний тест: модель отримала завдання перенести inference-код на Zig і оптимізувати під Mac. Після понад 4000 викликів інструментів, 14 ревізій і більш ніж 12 годин роботи — продуктивність зросла з 15 до 193 токенів на секунду. Для платної закритої моделі такий сеанс коштував би дуже дорого. На власному сервері з Kimi — тільки світло.
І тут є цікава думка про галюцинації.
Показник у K2.6 — 39.26% проти 64.6% у попередньої версії. Читаючи про різні моделі і як розробники борються з цією проблемою — і в GPT-5.5 і в DeepSeek V4 — у мене виникла думка. Рівень галюцинацій зменшується не тому що модель перестає помилятися. А тому що автономна модель може перевірити свою роботу, знайти помилку і виправити її. Тобто ми уникаємо галюцинацій не на вході а в процесі — через самокорекцію.
Якщо open-weights модель може стабільно працювати годинами над складними задачами і робити це безкоштовно на власній інфраструктурі — це вже серйозний аргумент для тих хто рахує витрати.
🔔 ПІДПИСАТИСЯ
👍5🔥3💯1👀1
Нарешті подивився відео з конференції NVIDIA GTC. Білл Даллі — головний науковець Nvidia — розповів про зростаючу роль AI у проєктуванні чипів компанії. Більшість цього не потрапляє в новини, але деталі дуже цікаві.
Почав він з мрії. Каже хочу просто дати AI завдання спроєктувати новий GPU, поїхати кататися на лижах, а повернутися і отримати готовий дизайн 😁 Поки що це фантастика — але частково Nvidia вже рухається саме в цей бік.
Наприклад коли компанія переходить на новий технологічний процес їй потрібно перепроєктовувати тисячі маленьких базових елементів чипа — логічні вентилі, елементи пам'яті тощо. Раніше така робота займала приблизно 10 місяців у восьми інженерів. Тепер система NVCell робить це за одну ніч на одному GPU — використовуючи комбінацію генетичного алгоритму і навчання з підкріпленням.
Інший приклад — проєктування арифметичних схем всередині GPU. Система PrefixRL знаходить рішення які виглядають незвично але виявляються на 20-30% кращими за людські. Наприклад один із спроєктованих нею суматорів займає на 25% менше площі на чипі ніж аналог зроблений традиційним способом. Інженери кажуть що самі б ніколи не розглянули такі конфігурації — вони просто суперечать звичній інтуїції.
Для щоденної інженерної роботи Nvidia донавчила open-weights моделі LLaMA 2 на всій внутрішній документації компанії — включно з низькорівневим кодом для кожного GPU який компанія коли-небудь випускала. Системи ChipNeMo і BugNeMo допомагають інженерам відповідати на технічні питання і розбирати звіти про помилки.
Але повністю спроєктувати GPU з нуля за одним запитом — це все ще далека мета, визнає сам Даллі. Поки AI закриває окремі етапи а не весь процес. Хоча рух у цьому напрямку є: стартап Verkoran описує систему яка за описом із 219 слів автономно спроєктувала процесор на 1.48 ГГц. Дослідники з Princeton застосовують deep learning для проєктування схем бездротового зв'язку.
І тут є красива петля. Nvidia використовує GPU для тренування AI-систем які допомагають проєктувати наступні покоління GPU. Кожне нове покоління чипів пришвидшує створення наступного і стає краще пристосованим для запуску інструментів які допомогли його спроєктувати.
AI поки що не "сам створює майбутнє заліза". Але він вже стає частиною інструментарію через який це майбутнє проєктується.
У пості багато посилань на статті і розбори — збережіть щоб повернутися коли буде час заглибитися 🔖
🔔 ПІДПИСАТИСЯ
Почав він з мрії. Каже хочу просто дати AI завдання спроєктувати новий GPU, поїхати кататися на лижах, а повернутися і отримати готовий дизайн 😁 Поки що це фантастика — але частково Nvidia вже рухається саме в цей бік.
Наприклад коли компанія переходить на новий технологічний процес їй потрібно перепроєктовувати тисячі маленьких базових елементів чипа — логічні вентилі, елементи пам'яті тощо. Раніше така робота займала приблизно 10 місяців у восьми інженерів. Тепер система NVCell робить це за одну ніч на одному GPU — використовуючи комбінацію генетичного алгоритму і навчання з підкріпленням.
Інший приклад — проєктування арифметичних схем всередині GPU. Система PrefixRL знаходить рішення які виглядають незвично але виявляються на 20-30% кращими за людські. Наприклад один із спроєктованих нею суматорів займає на 25% менше площі на чипі ніж аналог зроблений традиційним способом. Інженери кажуть що самі б ніколи не розглянули такі конфігурації — вони просто суперечать звичній інтуїції.
Для щоденної інженерної роботи Nvidia донавчила open-weights моделі LLaMA 2 на всій внутрішній документації компанії — включно з низькорівневим кодом для кожного GPU який компанія коли-небудь випускала. Системи ChipNeMo і BugNeMo допомагають інженерам відповідати на технічні питання і розбирати звіти про помилки.
Але повністю спроєктувати GPU з нуля за одним запитом — це все ще далека мета, визнає сам Даллі. Поки AI закриває окремі етапи а не весь процес. Хоча рух у цьому напрямку є: стартап Verkoran описує систему яка за описом із 219 слів автономно спроєктувала процесор на 1.48 ГГц. Дослідники з Princeton застосовують deep learning для проєктування схем бездротового зв'язку.
І тут є красива петля. Nvidia використовує GPU для тренування AI-систем які допомагають проєктувати наступні покоління GPU. Кожне нове покоління чипів пришвидшує створення наступного і стає краще пристосованим для запуску інструментів які допомогли його спроєктувати.
AI поки що не "сам створює майбутнє заліза". Але він вже стає частиною інструментарію через який це майбутнє проєктується.
У пості багато посилань на статті і розбори — збережіть щоб повернутися коли буде час заглибитися 🔖
🔔 ПІДПИСАТИСЯ
👍6🔥4
Доброго дня ☕️
Google DeepMind опублікували роботу про агента Aletheia — систему яка намагається робити математичні дослідження автономно.
Формально це не історія про "модель яка стала математиком". Це скоріше історія про те що одного сильного режиму міркування вже недостатньо якщо ми говоримо не про олімпіадні задачі а про реальну наукову математику. У Aletheia є три ролі агентів: generator, verifier, reviser. Генератор пропонує розв'язок. Верифікатор шукає слабкі місця. Ревізор переписує або покращує. І цей цикл крутиться доти поки система не знайде прийнятний доказ або не впреться в ліміт спроб. Саме ця архітектура а не просто "більше токенів на роздуми" — головна інженерна ідея.
Без доступу до літератури модель легко починає вигадувати посилання і теореми. З інструментами ситуація краща — система рідше фабрикує джерела повністю, зате все ще може неправильно інтерпретувати реальні статті.
Найчесніша частина статті — розбір задач Ердеша. Автори прогнали Aletheia по 700 відкритих проблем. Агент відібрав 212 кандидатів які здавалися перспективними. Після перевірки математиками: 137 виявилися принципово хибними, 63 — технічно правильними під якимось трактуванням, і лише 13 — змістовно правильними.
І навіть ці 13 — не прориви. Частина виявилася повторним відкриттям уже відомих рішень. Автори попереджають про ризик "підсвідомого плагіату": модель може відтворити відому ідею без посилання бо десь засвоїла її під час навчання. Це стосується не лише математики — для будь-якого AI-assisted дослідження це одна з головних майбутніх проблем.
Стаття досить чесно показує наскільки такі системи поки що ненадійні. І все ж у цьому видно дещо важливе: народжується новий тип інструменту для науки. Не "модель-геній" а агентна система яка може перебирати підходи, перевіряти себе, працювати з літературою і повертатися до задачі багато разів.
Саме тому хочеться думати про більш далекий горизонт. У 2000 році Інститут Клея визначив сім задач тисячоліття — математичних проблем за розв'язання кожної з яких обіцяно мільйон доларів. Розв'язано лише одну — гіпотезу Пуанкаре. Решта шість досі відкриті.
Одна з них — гіпотеза Рімана. Вона стосується розподілу простих чисел і залишається невирішеною вже понад 160 років попри зусилля найвидатніших математиків світу. Коли я навчався в університеті сам намагався в ній розібратися 🙈 Захопливо і безрезультатно 🤷♂️
Питання не в тому чи здатна Aletheia вирішити такі задачі вже зараз. Очевидно що ні. Але такі системи є першими прототипами майбутніх дослідницьких агентів які одного дня зможуть допомагати математикам штурмувати задачі такого масштабу.
🔔 ПІДПИСАТИСЯ
Google DeepMind опублікували роботу про агента Aletheia — систему яка намагається робити математичні дослідження автономно.
Формально це не історія про "модель яка стала математиком". Це скоріше історія про те що одного сильного режиму міркування вже недостатньо якщо ми говоримо не про олімпіадні задачі а про реальну наукову математику. У Aletheia є три ролі агентів: generator, verifier, reviser. Генератор пропонує розв'язок. Верифікатор шукає слабкі місця. Ревізор переписує або покращує. І цей цикл крутиться доти поки система не знайде прийнятний доказ або не впреться в ліміт спроб. Саме ця архітектура а не просто "більше токенів на роздуми" — головна інженерна ідея.
Без доступу до літератури модель легко починає вигадувати посилання і теореми. З інструментами ситуація краща — система рідше фабрикує джерела повністю, зате все ще може неправильно інтерпретувати реальні статті.
Найчесніша частина статті — розбір задач Ердеша. Автори прогнали Aletheia по 700 відкритих проблем. Агент відібрав 212 кандидатів які здавалися перспективними. Після перевірки математиками: 137 виявилися принципово хибними, 63 — технічно правильними під якимось трактуванням, і лише 13 — змістовно правильними.
І навіть ці 13 — не прориви. Частина виявилася повторним відкриттям уже відомих рішень. Автори попереджають про ризик "підсвідомого плагіату": модель може відтворити відому ідею без посилання бо десь засвоїла її під час навчання. Це стосується не лише математики — для будь-якого AI-assisted дослідження це одна з головних майбутніх проблем.
Стаття досить чесно показує наскільки такі системи поки що ненадійні. І все ж у цьому видно дещо важливе: народжується новий тип інструменту для науки. Не "модель-геній" а агентна система яка може перебирати підходи, перевіряти себе, працювати з літературою і повертатися до задачі багато разів.
Саме тому хочеться думати про більш далекий горизонт. У 2000 році Інститут Клея визначив сім задач тисячоліття — математичних проблем за розв'язання кожної з яких обіцяно мільйон доларів. Розв'язано лише одну — гіпотезу Пуанкаре. Решта шість досі відкриті.
Одна з них — гіпотеза Рімана. Вона стосується розподілу простих чисел і залишається невирішеною вже понад 160 років попри зусилля найвидатніших математиків світу. Коли я навчався в університеті сам намагався в ній розібратися 🙈 Захопливо і безрезультатно 🤷♂️
Питання не в тому чи здатна Aletheia вирішити такі задачі вже зараз. Очевидно що ні. Але такі системи є першими прототипами майбутніх дослідницьких агентів які одного дня зможуть допомагати математикам штурмувати задачі такого масштабу.
🔔 ПІДПИСАТИСЯ
👍10
AI не забере вашу роботу завтра. Але може зробити вас неконкурентним 🤷♂️
Гарної п'ятниці ☕️
Готуюся до виступу на AI мітапі в неділю — і готуючись трохи відійшов від теми і поглянув ретроспективно на останні кілька років розвитку AI. Зараз багато хто спекулює на темі скорочень і автоматизації — але мені здається що справжня зміна відбувається в іншому місці.
Є одна думка яка здається мені важливішою за прогнози про "заміну роботи роботами".
Кіан Катанфорош — викладач Stanford і CEO Workera — добре її сформулював: користуватись AI щодня ще не означає вміти з ним працювати.
Це справді різниця. Можна щодня відкривати ChatGPT, просити написати лист або скоротити текст — і залишатися на рівні просунутого користувача Google. А можна будувати систему де AI знає ваш стиль, документи, правила і критерії якості.
Коли з'явився GPT я не відчув особливого захвату — розумів що це трансформер 2018 року, статистична модель. Але якщо дивитися назад, розвиток LLM виявився колосальним. Був час коли я платив до $200 на місяць просто щоб тестувати різні інструменти — просто щоб розуміти що відбувається.
Зараз у моєму стеку є кілька підписок і локальна модель. Але найцікавіше те що я роблю з кількома моделями одночасно. Одна генерує відповідь або робить огляд. Друга перевіряє — наскільки він відповідає дійсності, чи правильні посилання, чи вірно зазначені автори. На основі цього формується оновлений звіт який повертається до першої моделі для корекції. Кілька таких ітерацій — і якість суттєво зростає. Особливо в задачах де важлива точність: дослідження, наукові огляди, перевірка фактів.
По суті це та сама логіка яку Google DeepMind заклали в Aletheia — generator, verifier, reviser. Тільки зібрана вручну з наявних інструментів. Читай минулий пост 👆
Головна думка тут не в тому що AI забере вашу роботу. Вас може замінити не AI а людина яка краще вміє з ним працювати. Adoption — це коли ви використовуєте інструмент. Proficiency — це коли ви розумієте як ним керувати.
Різниця між цими двома рівнями через рік стає дуже помітною.
🔔 ПІДПИСАТИСЯ
Гарної п'ятниці ☕️
Готуюся до виступу на AI мітапі в неділю — і готуючись трохи відійшов від теми і поглянув ретроспективно на останні кілька років розвитку AI. Зараз багато хто спекулює на темі скорочень і автоматизації — але мені здається що справжня зміна відбувається в іншому місці.
Є одна думка яка здається мені важливішою за прогнози про "заміну роботи роботами".
Кіан Катанфорош — викладач Stanford і CEO Workera — добре її сформулював: користуватись AI щодня ще не означає вміти з ним працювати.
Це справді різниця. Можна щодня відкривати ChatGPT, просити написати лист або скоротити текст — і залишатися на рівні просунутого користувача Google. А можна будувати систему де AI знає ваш стиль, документи, правила і критерії якості.
Коли з'явився GPT я не відчув особливого захвату — розумів що це трансформер 2018 року, статистична модель. Але якщо дивитися назад, розвиток LLM виявився колосальним. Був час коли я платив до $200 на місяць просто щоб тестувати різні інструменти — просто щоб розуміти що відбувається.
Зараз у моєму стеку є кілька підписок і локальна модель. Але найцікавіше те що я роблю з кількома моделями одночасно. Одна генерує відповідь або робить огляд. Друга перевіряє — наскільки він відповідає дійсності, чи правильні посилання, чи вірно зазначені автори. На основі цього формується оновлений звіт який повертається до першої моделі для корекції. Кілька таких ітерацій — і якість суттєво зростає. Особливо в задачах де важлива точність: дослідження, наукові огляди, перевірка фактів.
По суті це та сама логіка яку Google DeepMind заклали в Aletheia — generator, verifier, reviser. Тільки зібрана вручну з наявних інструментів. Читай минулий пост 👆
Головна думка тут не в тому що AI забере вашу роботу. Вас може замінити не AI а людина яка краще вміє з ним працювати. Adoption — це коли ви використовуєте інструмент. Proficiency — це коли ви розумієте як ним керувати.
Різниця між цими двома рівнями через рік стає дуже помітною.
🔔 ПІДПИСАТИСЯ
👍12🔥3❤1💯1
Бажаю гарних вихідних 👋
На вихідних не будемо заглиблюватися в складні технічні розбори. Як вже повелося — ділюся цікавим з геополітики навколо AI.
Meta хотіла купити Manus — сінгапурський AI-стартап з китайськими коренями, який став одним із символів нової хвилі general-purpose AI agents. Його ідея в тому, щоб виконувати довгі багатоетапні завдання майже як автономний цифровий працівник. Угода могла сягати $2.5 млрд, але китайський регулятор її заблокував.
Формально Manus вже переїхав до Сінгапуру і закрив бізнес у Китаї. Виглядало як класична стратегія: створити технологію в Китаї, юридично переїхати в нейтральнішу юрисдикцію, залучати західний капітал. WSJ писав що компанія спеціально намагалася обійти питання щодо китайських зв'язків.
Але стратегія дала збій. Китайська NDRC відкрила security review — і угоду заблокували. Пекін дав зрозуміти: якщо технологія була створена в Китаї китайськими інженерами, держава вважає її своїм стратегічним активом незалежно від того де юридично зареєстрована компанія.
Тобто реєстрація в Сінгапурі більше не гарантує свободу для продажу компанії або партнерства з американськими Big Tech. Це стосується багатьох китайських засновників які осіли в Південно-Східній Азії сподіваючись отримати доступ до глобального капіталу.
Контекст тут ширший за одну угоду. Цього тижня лідери США і Китаю мали зустрітися щоб обговорити геополітичні питання включно з AI. Угода між країнами могла б полегшити рух технологій і капіталу. Але якщо глухий кут збережеться — обидві країни ще більше відгородяться і посилять захист власних інтересів.
AI поступово стає не просто ринком а частиною геополітичної інфраструктури. Капітал, таланти і технології все частіше рухатимуться не лише за логікою бізнесу а й за логікою державного контролю.
🔔 ПІДПИСАТИСЯ
На вихідних не будемо заглиблюватися в складні технічні розбори. Як вже повелося — ділюся цікавим з геополітики навколо AI.
Meta хотіла купити Manus — сінгапурський AI-стартап з китайськими коренями, який став одним із символів нової хвилі general-purpose AI agents. Його ідея в тому, щоб виконувати довгі багатоетапні завдання майже як автономний цифровий працівник. Угода могла сягати $2.5 млрд, але китайський регулятор її заблокував.
Формально Manus вже переїхав до Сінгапуру і закрив бізнес у Китаї. Виглядало як класична стратегія: створити технологію в Китаї, юридично переїхати в нейтральнішу юрисдикцію, залучати західний капітал. WSJ писав що компанія спеціально намагалася обійти питання щодо китайських зв'язків.
Але стратегія дала збій. Китайська NDRC відкрила security review — і угоду заблокували. Пекін дав зрозуміти: якщо технологія була створена в Китаї китайськими інженерами, держава вважає її своїм стратегічним активом незалежно від того де юридично зареєстрована компанія.
Тобто реєстрація в Сінгапурі більше не гарантує свободу для продажу компанії або партнерства з американськими Big Tech. Це стосується багатьох китайських засновників які осіли в Південно-Східній Азії сподіваючись отримати доступ до глобального капіталу.
Контекст тут ширший за одну угоду. Цього тижня лідери США і Китаю мали зустрітися щоб обговорити геополітичні питання включно з AI. Угода між країнами могла б полегшити рух технологій і капіталу. Але якщо глухий кут збережеться — обидві країни ще більше відгородяться і посилять захист власних інтересів.
AI поступово стає не просто ринком а частиною геополітичної інфраструктури. Капітал, таланти і технології все частіше рухатимуться не лише за логікою бізнесу а й за логікою державного контролю.
🔔 ПІДПИСАТИСЯ
👍7
На якому рівні роботи з AI ви застрягли — і чи знаєте про це?
Гарної неділі ☕️Цей пост — трохи як налаштування перед новим тижнем. Якщо розуміти де ви зараз — легше зрозуміти куди рухатися далі.
Минулого тижня я писав про різницю між AI adoption і AI proficiency. Сьогодні хочу розгорнути цю думку і показати як це виглядає на практиці — через п'ять рівнів роботи з AI.
Рівень 1. AI як чат
Питання — відповідь. Поясни, переклади, напиши, знайди ідеї. Корисно, але це ще режим "поговорити з моделлю" а не системна робота. Я теж починав з цього — по суті замінив Google.
Рівень 2. AI як помічник
Людина вже не просто питає а веде модель через задачу: спочатку дай ідеї → порівняй → зроби структуру → скороти → перепиши в моєму стилі. У мене цей етап пройшов швидко — я почав генерувати промпти за допомогою одної моделі і використовувати їх для іншої. Тобто одна LLM допомагає краще сформулювати завдання для іншої.
Рівень 3. AI як молодший співробітник
Тут з'являється делегування. Ти вже не просиш "напиши пост". Ти описуєш роль, задачу, контекст, обмеження, формат результату і критерії якості. Anthropic у своєму фреймворку AI Fluency називає це Delegation, Description, Discernment, Diligence — зрозуміти що варто доручити, чітко описати, критично оцінити результат.
Рівень 4. AI як workflow
Один агент шукає інформацію, другий перевіряє джерела, третій пише чернетку, четвертий критикує. Я писав про це раніше: одна модель генерує звіт, інша перевіряє посилання і авторів, повертає оновлений варіант назад. Кілька таких ітерацій суттєво підвищують якість — особливо в задачах де важлива точність.
Рівень 5. AI як команда агентів
Це вже рівень AI-менеджера. Людина проєктує систему: хто що робить, хто кого перевіряє, які є обмеження, де потрібна людина в циклі. Reid Hoffman говорить про AI як про "підсилювач людської агентності" і сам використовує кілька систем паралельно для досліджень і перевірки результатів.
Більшість людей застрягають на першому-другому рівні. Не тому що не вміють — а тому що не уявляють що можливо далі.
А на якому рівні зараз ви?
🔔 ПІДПИСАТИСЯ
Гарної неділі ☕️Цей пост — трохи як налаштування перед новим тижнем. Якщо розуміти де ви зараз — легше зрозуміти куди рухатися далі.
Минулого тижня я писав про різницю між AI adoption і AI proficiency. Сьогодні хочу розгорнути цю думку і показати як це виглядає на практиці — через п'ять рівнів роботи з AI.
Рівень 1. AI як чат
Питання — відповідь. Поясни, переклади, напиши, знайди ідеї. Корисно, але це ще режим "поговорити з моделлю" а не системна робота. Я теж починав з цього — по суті замінив Google.
Рівень 2. AI як помічник
Людина вже не просто питає а веде модель через задачу: спочатку дай ідеї → порівняй → зроби структуру → скороти → перепиши в моєму стилі. У мене цей етап пройшов швидко — я почав генерувати промпти за допомогою одної моделі і використовувати їх для іншої. Тобто одна LLM допомагає краще сформулювати завдання для іншої.
Рівень 3. AI як молодший співробітник
Тут з'являється делегування. Ти вже не просиш "напиши пост". Ти описуєш роль, задачу, контекст, обмеження, формат результату і критерії якості. Anthropic у своєму фреймворку AI Fluency називає це Delegation, Description, Discernment, Diligence — зрозуміти що варто доручити, чітко описати, критично оцінити результат.
Рівень 4. AI як workflow
Один агент шукає інформацію, другий перевіряє джерела, третій пише чернетку, четвертий критикує. Я писав про це раніше: одна модель генерує звіт, інша перевіряє посилання і авторів, повертає оновлений варіант назад. Кілька таких ітерацій суттєво підвищують якість — особливо в задачах де важлива точність.
Рівень 5. AI як команда агентів
Це вже рівень AI-менеджера. Людина проєктує систему: хто що робить, хто кого перевіряє, які є обмеження, де потрібна людина в циклі. Reid Hoffman говорить про AI як про "підсилювач людської агентності" і сам використовує кілька систем паралельно для досліджень і перевірки результатів.
Більшість людей застрягають на першому-другому рівні. Не тому що не вміють — а тому що не уявляють що можливо далі.
А на якому рівні зараз ви?
🔔 ПІДПИСАТИСЯ
👍13
Вітаю з п'ятницею 👋
Тиждень видався напруженим — не мав змоги сісти і написати для вас. Сподіваюся що ви не надто втомилися і залишилися сили на вихідних трохи позайматися своїм розвитком в AI 😄 З наступного тижня повертаюся в звичайний режим.
Ви бачили що в OpenAI змінилась голосова модель?
Голосові AI-агенти стають розумнішими. Але чим більше модель "думає" — тим повільніше відповідає.
OpenAI представила оновлення Realtime API і нову модель GPT-Realtime-2. Головна ідея в тому що розробник тепер може керувати рівнем reasoning — вибирати баланс між швидкістю відповіді і глибиною міркування.
Є кілька режимів: від minimal до xhigh. Minimal — швидша реакція в живому діалозі. High та xhigh — краще справляються зі складними задачами але збільшують затримку. За даними OpenAI перше аудіо з'являється приблизно за 1.12 секунди в minimal і за 2.33 секунди в high режимі.
Для голосового агента затримка — це не просто технічна метрика. Це частина досвіду. Відповідь через 2-3 секунди вже відчувається як незручна пауза а не природний діалог.
Раніше voice AI часто був обгорткою навколо трьох окремих етапів: speech-to-text → LLM → text-to-speech. GPT-Realtime-2 працює ближче до end-to-end підходу: аудіо на вході, reasoning всередині, аудіо на виході.
Також модель реалізує preambles — коли проговорює проміжні дії: "перевіряю календар", "зараз подивлюся". Ми вже говорили про схожий підхід у контексті агентів раніше. Для голосового інтерфейсу це критично — користувач має розуміти що система не зависла а справді щось робить.
Я сам майже не користувався старим голосовим режимом — відповіді здавалися поверхневими порівняно з текстом. Хоча концепція зручна: руки зайняті а рот вільний — обговорити ідею, пропрацювати стратегію поки займаєшся чимось фізичним. Я взагалі завжди використовую thinking режим бо instant здається занадто поверхневим.
І ось тут проблема старого voice mode стає зрозумілою. У тексті ChatGPT може дати розгорнуту відповідь із контекстом і нюансами — і користувач сам керує темпом. У голосі довгі відповіді втомлюють, тому систему оптимізують під коротші репліки. Відповідь стає менш аналітичною — не тому що модель слабша а тому що UX оптимізований під інший тип взаємодії.
Нові speech-to-speech моделі намагаються вирішити саме це. Не просто озвучувати текст а краще працювати з живою розмовною динамікою — паузами, темпом, балансом між швидкістю та reasoning.
Старий голосовий режим — озвучений асистент. Новий realtime підхід — спроба створити справжнього голосового співрозмовника. І це значно складніше ніж просто додати приємний голос до LLM.
А ви користуєтеся голосовим режимом? Подобається чи здається поверхневим?
🔔 ПІДПИСАТИСЯ
Тиждень видався напруженим — не мав змоги сісти і написати для вас. Сподіваюся що ви не надто втомилися і залишилися сили на вихідних трохи позайматися своїм розвитком в AI 😄 З наступного тижня повертаюся в звичайний режим.
Ви бачили що в OpenAI змінилась голосова модель?
Голосові AI-агенти стають розумнішими. Але чим більше модель "думає" — тим повільніше відповідає.
OpenAI представила оновлення Realtime API і нову модель GPT-Realtime-2. Головна ідея в тому що розробник тепер може керувати рівнем reasoning — вибирати баланс між швидкістю відповіді і глибиною міркування.
Є кілька режимів: від minimal до xhigh. Minimal — швидша реакція в живому діалозі. High та xhigh — краще справляються зі складними задачами але збільшують затримку. За даними OpenAI перше аудіо з'являється приблизно за 1.12 секунди в minimal і за 2.33 секунди в high режимі.
Для голосового агента затримка — це не просто технічна метрика. Це частина досвіду. Відповідь через 2-3 секунди вже відчувається як незручна пауза а не природний діалог.
Раніше voice AI часто був обгорткою навколо трьох окремих етапів: speech-to-text → LLM → text-to-speech. GPT-Realtime-2 працює ближче до end-to-end підходу: аудіо на вході, reasoning всередині, аудіо на виході.
Також модель реалізує preambles — коли проговорює проміжні дії: "перевіряю календар", "зараз подивлюся". Ми вже говорили про схожий підхід у контексті агентів раніше. Для голосового інтерфейсу це критично — користувач має розуміти що система не зависла а справді щось робить.
Я сам майже не користувався старим голосовим режимом — відповіді здавалися поверхневими порівняно з текстом. Хоча концепція зручна: руки зайняті а рот вільний — обговорити ідею, пропрацювати стратегію поки займаєшся чимось фізичним. Я взагалі завжди використовую thinking режим бо instant здається занадто поверхневим.
І ось тут проблема старого voice mode стає зрозумілою. У тексті ChatGPT може дати розгорнуту відповідь із контекстом і нюансами — і користувач сам керує темпом. У голосі довгі відповіді втомлюють, тому систему оптимізують під коротші репліки. Відповідь стає менш аналітичною — не тому що модель слабша а тому що UX оптимізований під інший тип взаємодії.
Нові speech-to-speech моделі намагаються вирішити саме це. Не просто озвучувати текст а краще працювати з живою розмовною динамікою — паузами, темпом, балансом між швидкістю та reasoning.
Старий голосовий режим — озвучений асистент. Новий realtime підхід — спроба створити справжнього голосового співрозмовника. І це значно складніше ніж просто додати приємний голос до LLM.
А ви користуєтеся голосовим режимом? Подобається чи здається поверхневим?
🔔 ПІДПИСАТИСЯ
👍11
Промпти вже не важливі? 🤯
Доброго ранку понеділка ☕️
На вихідних підготував багато цікавих розборів - буду ділитися поступово протягом тижня. А поки хочу поділитися своїм підходом який ви зможете спробувати вже сьогодні.
Пам'ятаєте минулої осені у мене була рубрика "Промпт тижня" - де я давав конкретний промпт який покращував роботу з 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