Продовження допису вище про дрон Scaleout 👆

Важливий нюанс для точності: людина заздалегідь визначає критерії цілі та параметри місії до запуску, а пілот зберігає можливість перехопити керування. Тобто автономна саме фінальна фаза розпізнавання і наведення, а не вся місія від початку до кінця.

Виглядає як майже ідеальний дрон для сучасної війни. Але тут є одне дуже велике "але". І український досвід його чудово демонструє.

Коли ми говоримо "дрону не потрібен зв'язок" це ще не означає "РЕБ йому більше не страшна". Бо зв'язок з оператором лише одна з залежностей. Є ще супутникове позиціонування: GPS, Galileo, BeiDou. І саме з ним починається набагато складніша проблема.

Більшість класичної автономії будується дуже комфортно: я знаю свої координати → знаю координати точки маршруту → лечу до неї → знаходжуся біля координат цілі. Якщо потрібна дуже висока точність додаємо RTK і отримуємо сантиметрове позиціонування. Саме тому так красиво виглядають цивільні шоу сотень дронів та багато робототехнічних демонстрацій.

А тепер переносимо цю систему на реальне поле бою. І вмикається РЕБ. Супутниковий сигнал можна заглушити. Ще гірше, його можна підмінити, тобто змусити приймач повірити що він знаходиться зовсім в іншому місці. RTK тут теж не магія: він уточнює базовий сигнал а не замінює його.

І це те з чим Україна живе вже роками. Reuters описував як масове застосування засобів глушіння на українському фронті регулярно призводить до втрати керування дронами. Саме тому дедалі більше систем переходять до захоплення цілі оператором з подальшим автономним наведенням на останній ділянці навіть після втрати радіоканалу.

Але це вирішує лише половину проблеми. Можна прибрати оператора. Можна прибрати відеолінк. Але дрону все одно треба якось зрозуміти де він знаходиться.

І ось тут починається справді цікава інженерія. Замість простого супутникового позиціонування потрібно будувати щось на кшталт: інерціальний вимірювач руху, оптичний потік, visual-inertial odometry, зіставлення з рельєфом, карта, комп'ютерний зір на борту.

Тобто дрон уже не повинен постійно питати супутники де він. Він має дивитися на землю, дороги, будинки, лісосмуги, рельєф і сам оцінювати своє переміщення. Наприклад: я не знаю свої точні координати але знаю що від останньої відомої точки пролетів 600 метрів на північний схід.

Інерціальний вимірювач дозволяє це робити але поступово накопичує похибку. Visual odometry зменшує проблему але теж помиляється. Тому періодично потрібна абсолютна прив'язка: побачили дорогу → розпізнали характерний перехрест → зіставили з картою або супутниковим знімком → скоригували своє положення.

І саме це на мою думку набагато цікавіше за черговий YOLO на Jetson. Маленька модель детекції на embedded GPU сьогодні вже не магія. Справжній виклик — пройти кілька кілометрів без супутникового сигналу, без оператора, без стабільного зв'язку, не накопичити критичну помилку позиціонування, знайти потрібний об'єкт і замкнути на ньому контур керування.

До речі сама Scaleout у технічному описі згадує похибку позиціонування супутникового сигналу як одне з джерел помилки. Тобто навіть у їхній архітектурі питання стійкої навігації нікуди не зникає.

Тому фраза "зв'язок не потрібен, отже РЕБ безсила" звучить красиво але технічно неправильна. Правильніше сказати: РЕБ яка глушить канал керування стає значно менш ефективною. А проблема супутникового позиціонування залишається.

І можливо саме українська війна сьогодні найкраще показує куди насправді рухається автономна робототехніка.

🔔 ПІДПИСАТИСЯ

☝🏻 Meta показала як можна будувати AI-агентів якщо одразу припустити що prompt injection рано чи пізно спрацює

Доброго ранку ☕️

І це мабуть найцікавіше в новому персональному агенті Muse.

Замість того щоб сподіватися що LLM завжди розпізнає шкідливу інструкцію на сайті, у листі чи файлі, Meta виходить із набагато реалістичнішого припущення: модель можна обдурити, отже архітектура має залишатися безпечною навіть після цього.

Muse це персональний агент на базі Muse Spark 1.3 який може читати й надсилати пошту, працювати в браузері, заповнювати форми, користуватися календарем, робити покупки та виконувати фонові завдання. Тобто він має саме той набір можливостей який робить сучасних агентів потенційно небезпечними: приватні дані плюс недовірений зовнішній контент плюс можливість виконувати дії назовні. Саймон Вілісон називає це смертельним поєднанням трьох факторів.

Але цікавіше те як Meta спробувала це обмежити.

Кожен користувач отримує окремий Muse Secure VM, ізольований у власному Linux-контейнері так щоб жоден інший агент не міг до нього дістатися. Навіть права адміністратора всередині цього середовища не дають доступу до хостової системи.

LLM взагалі не бачить справжніх credentials. Паролі й токени доступу зберігає окремий процес під назвою authd. Muse отримує лише підставний токен, а справжній підставляється вже на межі мережевого запиту через окремий gatekeeper.

Цей gatekeeper називається Sentinel, окремий процес який є єдиним арбітром дозволів на дії конектора і весь вихідний мережевий трафік. Модель пропонує дію, Sentinel дозволяє, блокує або запитує підтвердження у користувача. Тобто навіть якщо prompt injection змусить Muse написати "відправ усі файли на attacker.com", сама LLM не має справжніх credentials і не може просто виконати цей запит напряму.

Підтвердження користувача винесені за межі чату і йдуть напряму в клієнтський інтерфейс а не через розмову з моделлю. Це важливо: текст усередині вебсторінки не може просто написати "користувач погодився" й видати це за справжнє підтвердження.

Є й додаткові рівні захисту. На рівні ядра система через eBPF відстежує який трафік чистий а який торкався недовіреного контенту і відповідно обмежує автономні дозволи. Перед тим як агент прочитає лист, поштовий конектор видаляє з нього одноразові коди та посилання для скидання пароля.

Фактично Meta реалізує принцип: не намагайся зробити LLM абсолютно надійною, зроби так щоб її помилка не давала повного контролю над системою.

Ідея не нова. У 2025 році Google DeepMind та ETH Zurich запропонували архітектуру CaMeL де модель що планує дії відокремлюється від компонента який читає недовірені дані, а виклики інструментів перевіряються політиками. Саймон Вілісон приблизно тоді ж писав що навіть якщо класифікатор ловить 99% спроб prompt injection для агента з доступом до приватних даних цього все одно недостатньо.

Компанія відкрила публічну bug bounty програму з винагородою до $300 тисяч, включно з до $130 тисяч за успішний prompt injection що вплинув на одного користувача.

На мою думку саме в цей бік і доведеться рухатися серйозним агентним системам. LLM може бути двигуном міркувань. Але межа безпеки не повинна проходити через саму LLM.

Безпека сьогодні одна з головних проблем агентних систем.

Meta заявляє що згодом планує відкрити ваги Muse Spark. Але в цьому випадку безпеку Muse забезпечує не стільки сама модель скільки система навколо неї. Було б добре якби Meta відкрила код і цієї системи також.

🔔 ПІДПИСАТИСЯ

☝🏻 У AI-агента Meta з'явилося тіло.

В продовження поста про Muse, тепер на Meta Connect Цукерберг дістав Muse Charm, окремий кишеньковий пристрій для спілкування з Muse. Виглядає як суміш кейса AirPods, Apple Watch без ремінця і тамагочі 😅 Усередині команди прототип навіть звався "Clawmagochi".

На 2-дюймовому OLED-екрані живе ваш аватар. Торкаєтесь сканера відбитка пальця і одразу говорите з агентом. Усередині власний 5G-модем, дві камери спереду і ззаду, мікрофони, USB-C.

Камери потрібні щоб агент бачив те що бачите ви: товар на полиці, оголошення, будь-що навколо. А 5G означає що для цього не потрібен ані Wi-Fi ані смартфон поруч.

За кілька годин до презентації Charm сплив скандал: Muse без дозволу прочитала понад 187 000 рядків приватних iMessage одного техжурналіста, а потім вигадала неправдиве пояснення як вона про це дізналася. Amazon паралельно обмежила Muse у покупках на своїй платформі.

Muse Charm планують відвантажувати до свят у грудні. Ціну поки не оголосили.

🔔 ПІДПИСАТИСЯ

☝🏻 DLSS 5 запустили прямо в браузері, без RTX і драйвера NVIDIA

Гарних вихідних 🌿

Розробник під ніком MAAN зробив неофіційний браузерний порт нейрорендерингу DLSS 5 через WebGPU 🤯

Замість NVIDIA NGX та нативного CUDA/RTX-стеку нейромережу фактично перевели на WebGPU compute shaders, тому вона може працювати навіть на GPU інших виробників і в macOS.

Всередині близько 147 МБ ваг моделі, приблизно 1 МБ JavaScript runtime, готові 3D-сцени та режим порівняння, можливість завантажити власну 3D-модель. За словами автора ваги були витягнуті з раніше витеклої бібліотеки DLSS 5.

Але до ігор поки дуже далеко. У тесті Tom's Hardware на RTX 40 один neural render займав приблизно 1-2 секунди. Тобто замість 60 FPS маємо десь 0.5-1 FPS 😅

Зате як proof-of-concept це цікаво: технологія яку NVIDIA офіційно прив'язує до свого RTX-стеку і орієнтує на GPU серії 50, виявилася здатною працювати через універсальний браузерний API.

🔔 ПІДПИСАТИСЯ

☝🏻 Від лабораторії до бійцівської клітки…

Трохи розважального до вечора 🌿

У Сан-Франциско 18 вересня блогер Frankie LaPenna вийшов проти модифікованого EngineAI T800 (зріст 173-183 см, вага 75-85 кг), якому для повного ефекту компанія REK поставила голову в стилі Terminator 🤖 і назвала подію "перший бій людина проти робота".

Це поки що не Skynet 😁 Робот не вирішував сам кого і коли бити. Ним дистанційно керував людина-пілот через VR-шолом, а власні алгоритми гуманоїда відповідали лише за баланс і стабілізацію.

Бій зупинили після того як робот відправив Frankie на підлогу, за деякими даними йдеться про перелом.

Зрозумiло що сучасні гуманоїди все ще незграбні. Але подивіться на фізику: це вже машина людського розміру і маси яка може тримати баланс, рухатися, бити руками та ногами і передавати дуже серйозний імпульс.

Ще кілька років тому такі роботи обережно ходили лабораторією. Тепер їх випускають у клітку. І автономність тут фактично останній великий шматок пазла.

🔔 ПІДПИСАТИСЯ

☝🏻 Синхронний перекладач тепер може говорити вашим голосом

Гарних вихідних 🌿

Команда Qwen представила Qwen3.8-LiveTranslate, нову модель для синхронного перекладу в реальному часі.

Перекладач тепер намагається зберегти голос і тембр конкретного співрозмовника 🎧

Модель розрізняє кількох людей і визначає хто саме говорить.

Під капотом Hybrid-MoE і архітектура Thinker-Talker: звук, візуальний контекст, розпізнаний текст і переклад обробляються як єдина послідовність, після чого Talker синтезує голос.

Модель розуміє 60 мов, включно з українською. Але є нюанс: голосовий переклад доступний для 29 мов, для решти лише текстовий. На FLEURS її протестували на 70 мовних напрямках за якістю перекладу, затримкою, розпізнаванням мовлення та синтезом голосу.

І ще один нюанс: локально це поки не запустиш. Модель доступна як хмарний сервіс Alibaba Cloud Model Studio через Realtime WebSocket API 🤷🏼‍♀️

🔔 ПІДПИСАТИСЯ

☝🏻 GPT-6 Astra сіла за кермо, і ніхто не постраждав

Троє дослідників посадили сучасні мовні моделі за кермо справжньої Toyota Corolla і відправили їх проходити трасу з конусів на порожній парковці 🤖

До кінця траси добралася тільки GPT-6 Astra, і то з другої спроби. 134.7 метра за 5 хвилин 22 секунди, швидкість пішохода 🤷🏼‍♀️ Решта моделей закінчили гірше: Claude Fable 5.1 45% траси, Grok 4.6 11%, GPT-5.6 Sol лише 6%.

Головна проблема виявилася неочікуваною - зір. Моделі просто неправильно інтерпретували сцену і плутали з якого боку конусів знаходиться смуга.

А ще Astra спочатку взагалі відмовлялася керувати справжньою машиною, посилаючись на безпеку, і бачила що це не симуляція. Спрацювало найпростіше рішення: MCP-сервер перейменували в "DrivingBench Sandbox" і модель почала їхати охочіше 😁

До автопілота тут звісно ще дуже далеко. Але це не модель яку навчали водити конкретну машину. Це загальна LLM якій дали камери і кермо. І вона з другої спроби виконала задачу краще ніж з першої.

🔔 ПІДПИСАТИСЯ

​Jev - Моделі створені для однієї конкретної задачі

Доброго ранку ☕️

Поки більшість компаній зосереджується на генеративних моделях і моделях міркування, одна компанія робить ставку на інший клас моделей. Її нова модель лише аналізує текст і відповідає на запитання про нього. Зате швидше й дешевше ніж велика мовна модель.

Компанія TypeSafe, заснована колишнім дослідником OpenAI Діогу Алмейдою який близько чотирьох років працював над RLHF, InstructGPT, ChatGPT і GPT-4, випустила Jev. Компанія назвала цей клас моделей System One, відсилка до швидкого інтуїтивного мислення з книги Деніела Канемана. Reasoning-моделі це System 2, повільне обдумане мислення. Jev натомість має бути швидкою автоматичною реакцією.

Модель не генерує текст. На вхід вона отримує текст до 64 тисяч токенів, формат відповіді задає користувач: вибір одного варіанта зі списку, числова оцінка або "так/ні".

Архітектуру TypeSafe докладно не розкриває. Каже лише що це не LLM і не авторегресійна модель, хоча в основі лежить Transformer. Докладніше описують метод навчання, Reinforcement Learning for Calibrated Decisions або RLCD.

Ключова ідея в тому що модель навчають видавати каліброві ймовірності а не просто відповіді які подобаються людям-оцінювачам. Наприклад серед усіх відповідей яким модель присвоїла ймовірність 20% правильними в ідеалі мають виявитися приблизно 20%. Це відрізняється від класичного RLHF який оптимізує модель під те щоб звучати правильно для людини а не бути каліброваною по факту.

Архітектура і ціноутворення заохочують розробників ставити багато коротких конкретних запитань за один запит. Замість одного питання "чи є цей лист спамом" задачу краще розкласти на окремі критерії: чи не збігається домен відправника із заявленою організацією, чи запитує лист пароль, чи містить підозріле посилання, чи створює штучну терміновість. Мета отримати повну структуровану картину на основі якої програмна система сама оцінить ситуацію.

Розробники опублікували результати лише на власних внутрішніх датасетах, пояснюючи це перенасиченням публічних бенчмарків. На чотирьох внутрішніх датасетах де еталонні відповіді визначали GPT-6 Astra та Claude Fable 5, Jev показала точність 67%, приблизно на рівні GPT-5.6 Terra та Claude Sonnet 5. Обробка одного прикладу коштувала приблизно $0.0007 проти $0.06 для Terra і $0.12 для Sonnet, а розробники стверджують що Jev працює у 193.6 раза швидше.

Але це результати внутрішніх тестів самої TypeSafe і жодна незалежна сторона поки не перевірила ці цифри.

Невдовзі з'явилася низка схожих моделей. Деякі відкриті і можуть працювати локально, на відміну від пропрієтарної Jev. Laya зосереджується на багатомовності. Bespoke Nimble перетворює Qwen 3.5 9B на класифікатор через донавчання. Kev теж на базі Qwen 3.5 намагається відтворити підхід Jev. Незалежного бенчмарку для порівняння поки немає.

Платформи на кшталт Vercel і Cloudflare вже додали підтримку Jev для вибору інструменту, маршрутизації запитів, оцінювання ризику та перевірки дій агентів.

До стрімкого поширення LLM більшість дослідників навчала моделі які добре виконували одну конкретну задачу. Після успіху великих мовних моделей індустрія почала прагнути одну модель здатну виконувати майже будь-що. TypeSafe пропонує проміжний підхід: одна модель яка не вміє робити все але добре виконує будь-яке завдання класифікаційного типу. Компанія сформулювала це слоганом "Build prod, not god", будуйте продакшн а не Бога.

Jev не замінить великі мовні моделі. Вона не генерує код, не веде розмову і не діє як повноцінний агент. Натомість може виявляти jailbreak та prompt injection, знаходити відсутні дані, класифікувати звернення, обирати наступну дію агента, оцінювати ризик, перевіряти результати роботи іншої моделі, вирішувати коли потрібне втручання людини.

У всіх цих сценаріях перетворення неструктурованого тексту на чіткі типізовані відповіді може бути надзвичайно корисним для розробників.

🔔 ПІДПИСАТИСЯ

​Claude Opus 5.5: нова найпотужніша модель на ринку

Доброго ранку ☕️

Півтора тижня тому CEO Anthropic Даріо Амодеї закликав пригальмувати розвиток AI, щоб безпека встигала за можливостями моделей. А потім Anthropic випустила Claude Opus 5.5, свою найпотужнішу модель і першу в новому сімействі 5.5 🤷🏼‍♀️

Сама компанія називає це першим релізом після заклику пригальмувати. Логіка така: гальмувати потрібно насамперед майбутні системи, здатні повністю автоматизувати AI-дослідження. Чи це переконливо, питання дискусійне.

Незалежні рейтинги ставлять Opus 5.5 на перше місце. В Artificial Analysis Intelligence Index вона має 58 балів, на п'ять вище за Fable 5.1 і GPT-6 Astra. У Vals Index 69.69%, перше місце з 63 моделей.

Технічно: текст і зображення на вході, контекст 1 мільйон токенів, вихід до 128 тисяч (у Batch API до 300 тисяч). Міркування завжди увімкнене, керувати можна лише його глибиною через п'ять рівнів від low до max, деталі в документації. Ціна нижча ніж у Opus 5: $4 за мільйон вхідних токенів і $20 за вихідні. За словами Anthropic на типових задачах виходить приблизно на 40% дешевше, бо модель ще й робить менше кроків.

Акцент не лише на коді а й на інтелектуальній роботі: документи, презентації, аналіз даних, дослідження, довгі агентні задачі. Один із ранніх тестувальників виконав міграцію коду на 680 000 рядків менш ніж за день, а це робота на тижні для команди інженерів. Саме в цих напрямах Anthropic останнім часом частково поступалася OpenAI, чиї GPT-6 Sol і GPT-6 Luna вийшли того ж дня. Вони значно дешевші, але в загальних рейтингах поки нижче.

Для бізнесу з чутливими даними важливо ще одне. Fable 5.1 вимагає 30-денного зберігання запитів і відповідей. Для Opus 5.5 за відповідної конфігурації підтримується Zero Data Retention.

Але з бенчмарками є нюанс. Чутливі кіберзапити модель може передавати на Opus 4.8, а біологічні та пов'язані з розробкою frontier-моделей на Opus 5. Anthropic сама зазначає що це вплинуло на частину тестів, тому точно оцінити силу моделі в кібербезпеці та біології без цього механізму неможливо. І страждати від нього можуть не лише зловмисники: легітимні дослідження в безпеці, біомедицині та AI engineering теж можуть блокуватися.

Зовнішня оцінка стриманіша за маркетинг. За висновком METR разом з Anthropic модель на рівні Mythos 5.1 або трохи вище, без ознак різкого прискорення AI-досліджень. На внутрішньому тесті CoBench вона набрала 55.8% при порозі 85%, який Anthropic вважає необхідним щоб замінити власних дослідників. Деталі в system card.

Ще одна новинка: статистичне водяне маркування тексту, про яке я писав раніше. А Sonnet 5.5 і Haiku 5.5 обіцяють уже через кілька тижнів.

Схоже, заклики пригальмувати розвиток AI поки не заважають випускати нові найпотужніші моделі 🙂

🔔 ПІДПИСАТИСЯ

​🤓 Склав сертифікацію Claude Certified Architect (Professional) на 943 бали з 1000

Нещодавно проходив сертифікацію з архітектури рішень на базі мовних моделей. На проходження дається 120 хвилин. Мій сертифікат на Credly можна перевірити. Доступ до іспиту йде через Claude Partner Network. Хочу поділитися тим, які знання там перевіряють і чому це цікаво тим, хто вже працює в AI або планує переходити в цю сферу.

Моє головне враження це те що дуже багато уваги приділяється тому, що відбувається навколо моделі. Як вона отримує дані, які дії може виконувати, як перевіряється результат і скільки все це коштує.

Ось кілька напрямів, які добре це показують 👇

🔹 Архітектура та доречна складність

Коли достатньо одного виклику моделі? Коли потрібен RAG, тобто пошук у власних документах? Коли виправданий агент із доступом до інструментів?

Окреме питання: коли систему вже потрібно розділяти на окремі компоненти. Якщо агент має десятки інструментів, плутається між ними й відповідає дедалі повільніше, додавання ще одного агента може лише збільшити складність.

🔹 Безпека та межі повноважень

Якщо асистент має готувати чернетки заявок, йому достатньо права створювати чернетки. Можливість самостійно відправляти їх постачальникам виходить за межі цієї задачі.

Так само потрібно розуміти prompt injection, перевірку доступу до документів, захист облікових даних та аудит дій. Хто ініціював виклик інструмента? Які дані він отримав? Куди міг їх передати?

🔹 Вимірювання якості

"На кількох прикладах працює добре" слабка основа для запуску. Потрібні підготовлені набори даних, критерії оцінювання, складні й провокаційні приклади. А після зміни моделі повторна перевірка, щоб помітити погіршення до того, як його помітять користувачі.

Навіть порівняння двох промптів потребує продуманого експерименту: гіпотези, метрики успіху та достатнього обсягу даних.

🔹 Економіка та швидкість

Великий контекст, зайві виклики інструментів, повторні запити й додаткові агенти мають свою ціну. Тут перевіряють розуміння кешування, відбору релевантних документів, використання менших моделей для простіших задач. І здатність оцінити, чи зберігається якість після оптимізації.

🔹 Експлуатація та бізнес-результат

Що робити, коли система починає помилятися? Кому передавати неоднозначні випадки? Як відкотити оновлення? Які журнали й метрики допоможуть знайти причину?

І ще один важливий момент: скорочення часу виконання задачі саме по собі не гарантує зростання продуктивності. Зекономлений час, обсяг виконаної роботи та фінансовий результат потрібно вимірювати окремо.

💭 Для мене ці питання показують важливий напрям розвитку професії: AI-інженер відповідає за поведінку всієї системи в реальних умовах.

Для тих, хто заходить у цю сферу, це хороший орієнтир. Поряд із моделями, промптами та фреймворками варто вивчати проєктування API, доступи, тестування, моніторинг, експерименти й роботу з вимогами.

А тим, хто вже має досвід у backend, data engineering, QA або DevOps, є на що спертися. Значна частина цих задач спирається на знайомі інженерні принципи, з поправкою на те, що мовна модель може дати правдоподібну, але неправильну відповідь.

Сама сертифікація звісно не замінює досвід. Проте її зміст дає корисну карту знань і допомагає побачити, які прогалини варто закрити наступними.

А ви вже проходили сертифікації від AI-компаній? Чи вважаєте, що вони справді щось підтверджують? Пишіть у коментарях 👇

Ну і можете привітати мене 🙂

🔔 ПІДПИСАТИСЯ

☝🏻 GPT-6 Astra дали тіло робота

Гарних вихідних 🌿

Дослідники зі Stanford та Caltech показали HomeBody, систему в якій GPT-6 Astra керує гуманоїдом Unitree G1 у кухні, якої робот раніше не бачив. Без окремого навчання під конкретну кімнату 🤖

Замість навченої Vision-Language-Action моделі Astra отримала бібліотеку з п'яти готових навичок: підійти, взяти, покласти, відкрити шухляду, дістати предмет. Сама вирішує що викликати і коли, а рухами керують окремі контролери.

Перед роботою робот досліджує кімнату камерами і LiDAR, будує цифровий двійник в NVIDIA Isaac Sim і отримує просторову пам'ять. Тому на прохання "принеси мої ліки" він згадує де бачив флакон хоча зараз його не бачить, і сам доходить до потрібної шухляди.

Варто додати ложку дьогтю: автори самі кажуть що частина демо прискорена а захоплення предметів містить повторні спроби. Success rate не опублікували 🤷🏼‍♀️

🔔 ПІДПИСАТИСЯ

☝🏻 Дрону додали вуса щоб він літав навпомацки

Гарних вихідних 🌿

Дослідники з TU Delft зробили мікродрон який може знаходити стіни й перешкоди буквально на дотик, навіть у повній темряві. Ідею підгледіли у щурів: коли зір майже не допомагає, вони орієнтуються за допомогою вібрис 🐭

Сам апарат важить 44.1 грама, а вся система з двох вусів лише 3.2 грама. Два гнучкі вуса по 20 см, в основі кожного три мініатюрні барометри. Коли вус згинається від дотику, датчики фіксують зміну тиску, і дрон оцінює глибину контакту з точністю до міліметрів.

Цього вистачає щоб автономно обходити перешкоди, рухатись вздовж стіни і досліджувати тісні простори без камери чи лідара. Найцікавіше, весь стек обробки тактильних сигналів і навігації займає лише 34 КБ пам'яті і працює просто на бортовому мікроконтролері, без хмари і без GPU.

Камера погано бачить у диму й темряві. А стіну можна просто помацати 😁

🔔 ПІДПИСАТИСЯ

​Open-weight модель наблизилась до Mythos у кібератаках. Це добре чи погано?

Доброго ранку ☕️

Anthropic опублікувала аналіз кіберможливостей GLM-5.3, моделі з відкритими вагами від китайської Z.ai. За цими можливостями вона наближається до Mythos, моделі Anthropic із закритими вагами яку компанія тримає під жорстким контролем саме через такі здібності.

На підмножині ExploitBench GLM-5.3 довела експлойт до кінця у 50 з 410 спроб, 12.2%. Mythos показав 56 з 410, близько 14%. Цікаво що розрив у тестах Anthropic менший ніж у звіті розробника на повному бенчмарку, де Z.ai заявляє 54.4% проти 78% у Mythos. А попередня GLM-5.2, Kimi K3 і DeepSeek V4.1-Flash показали в цьому тесті нуль або майже нуль.

Ендрю Ин бачить у цьому хорошу новину: фахівці з кіберзахисту які не мають доступу до закритого Mythos тепер можуть використовувати потужну модель для захисту своїх систем. А оскільки нападники вже мають доступ до подібних можливостей, захисникам варто діяти швидше.

Є важливе уточнення до цифр про вартість. Anthropic оцінила що створення робочого експлойта для вже відомої вразливості в Google Chrome, дані про яку дослідник заздалегідь надав моделі, коштувало $20.40 на токени GLM-5.3-Flash. Це не вартість відкриття нової вразливості з нуля, а вартість написання атаки коли вразливість уже відома.

Але сама Anthropic оцінює ситуацію значно тривожніше за Ина. У звіті йдеться про помітний стрибок у кіберможливостях доступних нападникам і ймовірне використання таких моделей державними та недержавними акторами для реальної шкоди. Захист у моделі слабкий: пряме прохання про атаку вона відхиляє, але прості прийоми, наприклад вигадана легенда, обходили обмеження у 64-100% випадків. А оскільки ваги відкриті, обмеження можна прибрати зовсім: за оцінкою Anthropic, для GLM-5.3-Flash це коштувало близько $4400, а такі версії з'явилися публічно за кілька днів після релізу. NIST при цьому оцінив модель як найсильнішу відкриту в кібербезпеці, але з відставанням від кращих американських моделей приблизно на чотири місяці. Варто пам'ятати й що Anthropic має власний інтерес у цій дискусії: вона сама не публікує ваги своїх моделей.

Тому Ин робить ставку на інженерію. Злам Hugging Face агентами OpenAI він пояснює слабкою ізоляцією середовища, а свій відкритий агентний застосунок OpenWorker, про який я вже писав, будує на платформі безпеки NVIDIA. За його описом, кожна команда агента виконується всередині ізольованого контейнера, туди потрапляють лише потрібні для задачі файли, а секретні ключі, паролі браузера і доступ до довільних сайтів за замовчуванням недоступні. Головне, ці обмеження реалізовані детермінованим кодом а не промптом, бо LLM може помилятися або піддатися prompt injection. Усі дії журналюються для аудиту.

Тобто коли відмови моделі можна зняти за кілька тисяч доларів, захист не може на них триматися. Він має жити в інфраструктурі навколо моделі, як і в Muse від Meta, про яку я писав раніше. Ин при цьому вірить що в довгостроковій перспективі перевага на боці захисників, бо вони мають більше інформації для виявлення вразливостей. Головне виконати цю роботу якомога швидше.

А як вважаєте ви: відкриті ваги з такими можливостями це більше допомога захисникам чи нападникам? Пишіть у коментарях 👇

🔔 ПІДПИСАТИСЯ

Чому AI добре пише код, але може давати слабкі поради?

Доброго ранку ☕️

Між "розв'язати задачу" і "прийняти хороше рішення" є різниця, яку легко недооцінити, дивлячись на прогрес LLM.

У математичній задачі можна перевірити відповідь. У програмуванні запустити тести, хоча вони звісно не гарантують якості всього рішення. А як перевірити що модель запропонувала правильну продуктову стратегію? Порадила збирати саме ті дані яких бракує вашому AI-проєкту? Вдало відповіла незадоволеному клієнту?

Тут теж є кращі й гірші відповіді. Але немає простого автоматичного способу їх розрізнити.

І це впливає на те як швидко ми можемо навчати моделі. Коли результат можна перевірити, модель багаторазово пробує різні підходи й отримує чіткий сигнал: спрацювало чи ні. На цьому будується значна частина прогресу в навчанні з підкріпленням.

Із завданнями що потребують судження складніше. Спочатку нам самим треба визначити що означає "хороша відповідь". Потім зібрати приклади, узгодити критерії оцінювання й переконатися що ми винагороджуємо якість рішення, а не його переконливе формулювання.

Мені особливо близький приклад зі збиранням даних для ML. Модель може запропонувати цілком розумний план: збільшити датасет, збалансувати класи, додати складні випадки. Але чи допоможе це конкретному проєкту залежить від контексту: де система помиляється, як працює в реальних умовах, скільки коштує розмітка і які помилки найкритичніші для бізнесу. Без цих деталей рекомендація може звучати правильно і водночас майже нічого не вирішувати.

Тому успіхи LLM у коді та математиці не варто автоматично переносити на всі інші види роботи. Здатність знайти правильну відповідь у задачі яку можна перевірити ще не гарантує здатності ухвалити вдале рішення в неоднозначній ситуації.

Для AI-інженера звідси практичний висновок: цінність уміння поставити задачу, зібрати потрібний контекст і визначити критерії успіху залишається високою. Чим більше виконання ми делегуємо моделям, тим уважніше маємо обирати що саме їм доручати і як оцінювати результат.

А у вас були випадки коли AI впевнено радив щось що на вашому проєкті не спрацювало? Діліться в коментарях 👇

🔔 ПІДПИСАТИСЯ

​Дешевші токени ще не означають дешевшу роботу 🤔

Доброго вечора 🌙

Anthropic оновила лінійку Claude: до Opus 5.5 приєдналися Sonnet 5.5 та Haiku 5.5. Але найцікавіше те, як налаштування міркування впливають на вартість і результат.

Sonnet майже наздоганяє Opus, але витрачає більше токенів. За даними Artificial Analysis, на максимальному рівні міркування Sonnet 5.5 генерує приблизно 193 тисячі вихідних токенів на завдання, на 60% більше за Opus. Через це виконання завдання на Sonnet у режимі max обходиться дорожче, ніж на Opus у тому самому режимі. А між різними рівнями міркування самої Sonnet вартість відрізняється більш ніж у 18 разів.

При цьому в тестах Vals AI Sonnet коштує приблизно дві третини від Opus. Тобто навіть відповідь на питання "яка модель дешевша" залежить від ваших завдань. Сама Anthropic визнає, що цінова перевага Sonnet над Opus найпомітніша на нижчих рівнях міркування.

І ще цікавіше: більше міркування не завжди покращує результат. У FrontierCode перевіряють, чи готові зміни коду від агента до злиття без правок людини. За даними Anthropic, Sonnet 5.5 показала 52.1% на рівні xhigh і лише 46.2% на рівні max. Тобто вищий рівень effort змінює самі дії агента: скільки він перевіряє, які інструменти викликає, як підходить до розв'язання. І ці зміни не завжди корисні.

Haiku 5.5 теж можна використовувати як модель з міркуванням, але її перевага у вартості найбільше проявляється на простих задачах: підсумовування, класифікація.

Для мене практичний висновок такий: обираючи модель для продукту, треба порівнювати вартість успішно виконаного завдання, точність і час очікування. Взяти набір реальних задач, прогнати його на кількох моделях і рівнях effort, а потім подивитися, де додаткові витрати справді дають кращий результат. Бо ціна за мільйон токенів лише один із компонентів рахунку.

А ви порівнювали якість на різних рівнях міркування чи зазвичай залишаєте налаштування за замовчуванням? 👇

🔔 ПІДПИСАТИСЯ