Google випустили повну версію Gemma 3n

Це перша модель менше 10 мільярдів параметрів, яка набрала на LMArena > 1300 балів. Плюс це on-device, тобто модель призначена для локального запуску.

Підтримується текст, картинки, аудіо і навіть відео. За розміром є два варіанти: E2B і E4B. Буква E означає effective. Фактично в моделях 5В і 8В параметрів відповідно, але за рахунок архітектурних особливостей їх можна запускати на залізі з тими ж витратами, як якщо б це були 2B і 4В. На першу вистачить всього 2GB.

В основі – MatFormer. Суть в тому, що більша модель містить менші версії себе. Теоретично, це означає, що модель зможе на інференсі динамічно перемикатися між моделями в залежності від складності запиту.

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

The Unreasonable Ineffectiveness of the Deeper Layers 🤷‍♂️

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

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

Архітектура 👷

Пригадаємо, що трансформер побудований на базі residual connections. Це означає, що через всю архітектуру йде так званий residual stream, який починається з token embeddings. Кожен шар зчитує інформацію з residual stream, оброблює її, і потім додає свою поправку назад. Ця поправка може бути використана як наступними шарами, так і для вирішення безпосередньої задачі, тобто next-token-prediction.

Методологія дослідження 🔎

Алгоритм прунінгу, який застосовують автори, базується на наступній гіпотезі: якщо шар (або N послідовних шарів) майже не змінюють зміст residual stream (тобто поправка дуже незначна), то їх можна відкинути, бо вони навряд чи вплинуть на кінцевий результат.

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

Після цього також можна робити так званий “healing”, тобто донавчання моделі (робиться через QLoRA), щоб дати моделі можливість адаптуватися під зміни, що відбулися.

Автори виконують цю процедуру на різних моделях (Llama 2, Qwen, Mistral, Phi-2) на наборах даних з двох кластерів: Question-answering та Reasoning.

Результати ✍️

- Для будь-якого розміру блоку виявляється, що алгоритм вирішує відрізати саме глибші шари. Тобто вони значно рідше змінюють стан residual stream.

- Цікаво, що це не стосується останніх одного-двох шарів, які, здається, грають ключову роль для трансформації інформації з residual stream у next token embeddings, тому вони дуже важливі.

- Для question-answering задач можна відрізати від 20 до 50 відсотків шарів (цей відсоток корелює з розміром моделі) майже без втрати якості, особливо якщо застосувати healing. Отже, модель зберігає майже всі знання, необхідні для відповідей на запитання, у своїх початкових шарах.

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

Відкриті питання 🙋‍♂️

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

Можливо, це артефакт навчання поточних архітектур, які все ще не можуть використовувати глибші шари на максимум. Наприклад, дуже схоже, що саме residual connections навʼязують моделі, що більш ранні шари є важливішими, адже вони беруть участь у більшій кількості інтеракцій всередині моделі.

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

🎯Шукаєте команду, де можна досліджувати, експериментувати й впроваджувати інноваційні ML-рішення?

У SQUAD, одному з найбільших R&D центрів в Україні, ви працюватимете над технологіями детекції руху, що поєднують Edge та Cloud.

Позиція Computer Vision Engineer передбачає щоденні дослідницькі завдання:
🔹формулювання гіпотез,
🔹збір і аналіз даних,
🔹навчання моделей,
🔹підготовка наукових матеріалів.

Деталі вакансії — https://bit.ly/4lWusIX 👀

👌Google релізнули цікавий інструмент, за допомогою якого можна «вирізати» з великої моделі готові моделі поменше

Пам'ятаєте, нещодавно вони виклали в опенсорс повноцінну Gemma 3n?  Ця модель мала незвичайну архітектуру трансформер, щось схоже на вкладену в саму себе меньшу версію, наприклад Gemma 3n еластична, тобто у неї є вкладені моделі – звідси і назва.

Зокрема, сама вона була навчена як модель на Е4В, це 4В ефективних параметрів з 35 шарами і розміром прихованого шару 16384, але всередині неї є повністю самодостатня модель на E2B вже з 30 шарами і розмірністю 8192. Тренують це все, звичайно, спеціальним чином за допомогою Nested Doll Representation Learning.

Але і це не все: з такої структури можна витягувати моделі взагалі будь-якого розміру між 2В і 4В. Раніше – теоретично, а тепер і на практиці за допомогою готової тулзи від самих Google😋.

Оибираєте, який розмір буде оптимальним для вашого заліза -> виставляєте відповідну конфігурацію -> відпрацьовує метод Mix-n-Match, який вирізає з моделі потрібне вкладення (це відбувається без навчання) -> ви отримуєте готові ваги, які можете, до речі, відразу ж залити на HF.

Виглядає дуже круто, до речі, оформлено у вигляді ноутбука ipynb, так що запустити можна однією кнопкою.

Moonshot AI випустив нову модель Kimi K2

Kimi K2 має під капотом 1 трильйон загальних параметрів і 32 активних. Ця архітектура забезпечує баланс між потужністю та практичними обчислювальними витратами під час інференс моделі. Сама модель має 61 шар, 7168 скритих параметрів та довжину контексту 128K.

Архітектура включає 384 різних експертів, причому модель інтелектуально вибирає 8 експертів для кожного токена, який вона обробляє. Цікаво що в Kimi K2, додали свій оптимізатор MuonClip, який вирішив критичну проблему «exploading attention logits», яка зазвичай призупиняє навчання великих моделей. Попередньо модель навчили на 15,5 трильйонах токенів без піків навчання, що зробило можливим створення стабільної моделі з трильйоном параметрів з відкритим кодом. Модель доступна у двох варіантах:

– Kimi-K2-Base для дослідників, які прагнуть повного контролю та тонкого налаштування
– Kimi-K2-Instruct для загальних діалогових та агентних взаємодій.

Бенчмарки Kimi K2 демонструє доволі гарну продуктивність у ключових тестах у порівнянні з іншими моделями. У завданнях з математичного міркування Kimi-K2-Base набирає 70,2 бали в тесті MATH і 92,1 бали в GSM8k, демонструючи сильні логічні здібності. У прямих порівняннях моделі Kimi постійно перевершувала DeepSeek V3 у математичних тестах, а Kimi-k1.5 значно перевершив DeepSeek-V3 0324 як у тестах AIME 2024, так і MATH-500.

Щодо кодінгу, тут теж все добре, модель Kimi K2 демонструє результат 80,3 балів у тесті EvalPlus і 26,3 Pass@1 у тесті LiveCodeBench v6, що доволі круто. Модель навіть перевершила Claude Sonnet 4 (без різонінг) і GPT-4.1, у тестах з кодування, набравши 65,8% на SWE-bench Verified порівняно з 50,2% у Claude і 40,8% у GPT.

Загалом вийшло доволі круто, враховуючі що модель опенсорс.

📣 Онлайн-мітап для research-, data-, MLOPS-інженерів і всіх, хто працює з великими масивами даних

єТЕМА: Як опанувати життєвий цикл даних: масштабована автоанотація, синтетика та доставка 📊🤖

Спікери з 10+ річним досвідом у напрямках Machine Learning та Computer Vision:

🎙️ Богдан Бобиль, Applied Science Manager у SQUAD
Розповість про оптимізовану доставку та управління даними, а також чому найкращі дані не працюють без правильного транспорту.
🎙️ Юрій Пащенко, AI Tech Lead (NDA)
Розкриє проблематику даних у реальних ML/AI-проєктах: дефіцит якісних анотованих даних, виклики масштабування, упередженість і шум у датасетах, фрагментованість пайплайнів.
🗓️ 31 липня, 19:00 | online

Реєстрація вже відкрита, участь безкоштовна. Не пропустіть 🦾

OpenAI презентували ChatGPT agent✌️

Це Deep Research і Operator в одному флаконі. Тобто агент, який зможе переглядати веб-сторінки мультимодально, на відміну від Deep Research, викликати API та інші інструменти, виконувати якісь завдання і все це – з ризонінгом.

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

Результат на Humanity's Last Exam – 42%. Це дуже серйозний приріст щодо o3 і навіть Deep Research. На Frontier Math теж помітний стрибок.

До речі, під капотом не o3 і не o4-mini, а якась нова модель, навчена спеціально під agent mode і computer use.

Цікаво, що розгорнули агента не тільки для Pro передплатників за 200$. Доступ дадуть і звичайним користувачам з Plus, ліміти – 40 запитів на місяць😁.

Google Research випустили MLE‑STAR агент для ML-інжинірингу 🤖

Google представив MLE‑STAR — агент на основі LLM, який автоматизує ML-завдання різних типів і досягає висот у порівнянні з попередніми підходами.

Що нового:

- Використовує веб-пошук для пошуку сучасних моделей і прикладів коду
- Робить абляційний аналіз (ablation study), щоб визначити найбільш впливовий компонент в ML-пайплайні, і ітеративно доопрацьовує його
- Розвиває ансамблювання - генерує кілька рішень і збирає їх в одне покращене
- Включає модулі контролю: дебагер, перевірку витоків даних і контроль використання всіх джерел даних. Результати цікаві MLE‑STAR виграє медалі в 63–64 % з бенчмарку MLE‑Bench‑Lite, випереджаючи найкращі існуючі методи (~25–26 %).

Покроковій степ
- Пошук потрібних моделей через веб
- Генерація і злиття кращих кандидатів
- Абляційний аналіз → вибір блоку → уточнення цього блоку
- Ітеративне поліпшення і об'єднання ансамблів
- Контрольні модулі: дебаг, витоки, використання даних

Поки всі говорять про GPT-5, краще подивимось що за новий метод розмітки даних для файнтюнінгу представиви Google 😌

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

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

— Вихідна мовна модель отримує завдання і сама розмічає дані як «клікбейт» або «звичайна реклама».

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

— В ході кластеризації з'являються, перекриваються кластери різних груп. І ось саме ці «спірні» пари передаються на ручну розмітку.

Витончено та красиво ☺️. У підсумку точність моделей після файнтюнінгу така ж, а даних потрібно розмічати в тисячі разів менше. Уявіть, яка економія.

Тут одна добра душа, поділилась детальним гайдом зі співбесіди в OpenAI☺️

Інженер, який щойно вийшов на роботу в OpenAI, написав величезний блог-пост про процес відбору в стартап. І виглядає це як ультимативний гайд про те, як прокачатися в проходженні співбесід на будь-яку ML-роль.

1 етап – Recruiter intro (15–30 хв).
Це просто базовий скрин: вам розповідають про команду, етапи, терміни, правила проходження інтерв'ю тощо. Ви розповідаєте про себе. Обов'язково потрібно підготуватися, порепетирувати з друзями, бути лаконічним, задати питання і все записати.

2 етап – Hiring Manager chat. Питання на кшталт чому ви підходите цій команді і т.д. На цьому етапі вже важливо розуміти цілі компанії, показати предметний інтерес і дотримуватися балансу скромності та впевненості.

3 етап – Кодинг.
Починається найцікавіше. Ось що можуть запитати, наприклад:
– дебаггінг трансформера (помилка може бути в механізмі уваги, наприклад, або в формі тензорів)
– реалізація KV-cache, BPE або зворотного поширення з нуля
– класика алгоритмів: Дейкстра, купи, сортування, бінарний пошук

Автор пише, що тут важливіше робити швидко, ніж ідеально якісно. Краще залишати #todo і assert, ніж плутатися і гальмувати. Ну а з підготовкою все просто: 100+ годин на LeetCode і стільки ж на читання та імплементацію статей.

4 етап – ML.
Перевіряють фундамент + якісь актуальні знання. Наприклад, можуть запитати: supervised vs unsupervised, математика лінійної регресії, як навчити модель з контекстом 10М токенів, GRPO vs PPO, методи інтерпретованості. Тут знову ж таки: читаємо багато статей і базові книги.

5 етап – Поведінкове інтерв'ю.
Перевіряють, як ви дієте в складних ситуаціях. До цього інтерв'ю теж не забуваємо готуватися і відповідаємо завжди за методом STAR(I): Situation, Task, Action, Result, Insight. Окремо готуємося до питань про провал і конфлікти, вони будуть обов'язково.

Скарб одним словом😌. Більш детально можна глянути тут.

MetaAI релізнули DINOv3 — нова модель комп'ютерного зору 😌

Модель навчена на зображеннях без використання розміток даних. Це зробило навчання швидшим, дешевшим та без втрати якості генерації моделей. Особливістю є те, що одна «frozen» основа (без тонкого налаштування) перевершує багато спеціалізованих моделей у складних завданнях, по типу виявлення об'єктів і семантична сегментація.

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

Також компанія випустила менші версії (такі як ViT-B/L і ConvNeXt), які на рівні або краще з інішими моделей на основі архітектури CLIP.

Сама модель навченна на обсязі близько 1 млд нерозмічених зображень 😳

Розбираємось, чому стаття «Hierarchical Reasoning Model» наводить стільки шуму😳

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

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

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

Навчається HRM не зовсім звично для рекуррентної моделі: тут, замість того щоб зберігати всі внутрішні стани, автори вирішили оновлювати градієнти тільки по фінальному статусу. Дивно, але факт – це працює.

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

Що ми маємо у підсумку?

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

P.S Авторам вдалося створити модельку всього на 27 мільйонів параметрів, яка обійшла o3-mini на ARC-AGI-1. Що що, а це база👌

Повна стаття

Google знайшли фундаментальний баг в RAG 😳

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

Сучасний пошук і RAG часто спираються на single-vector ембеддінги: у кожного запиту і документа – по одному вектору, схожість вимірюємо скалярним добутком/косинусом, далі беремо топ-k найближчих.

І тут виникає питання, а взагалі чи можливо при фіксованій розмірності векторів побудувати такий пошук, який завжди буде повертати правильні топ-k документів для будь-яких запитів? Відповідь – ні. І збій відбувається вже на дуже простих прикладах.

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

Розглянемо приклад, уявімо матрицю A, де рядки – це запити, а стовпці – документи, і на перетині стоїть 1, якщо документ релевантний, і 0 – якщо ні. Ми хочемо, щоб пошук на ембеддінгах відтворював саме таку матрицю «хто кому підходить». Тоді оцінки схожості будуть матрицею B = UᵀV, де U і V – це вектори запитів і документів у просторі фіксованої розмірності d. Але sign-rank матриці (2A−1) може виявитися більшим за d, а це означає, що жодні d-вимірні ембеддінги не зможуть побудувати B з правильними значеннями. Формально: якщо sign-rank(A) > d, то коректний поділ релевантних і нерелевантних пар в такому просторі просто неможливий, яким би мегарозумним не був ваш ембеддер.

Наприклад, якщо у вас ембеддінги розмірності 512, то ваш RAG буде працювати нормально, поки документів у вашій базі менше 500 тисяч (а це досить небагато). При розмірності 1024 – до ~4 млн. При 4096 – приблизно до 250 млн. Далі система почне сипатися.

І ці розрахунки Google підвели в ідеальних умовах, коли вектори оптимізовані під завдання. На практиці, коли ви не донавчаєте ембеддінги, межі ще нижчі.

Щоб показати це на практиці, автори придумали спеціальний бенчмарк LIMIT. Він побудований так, що для кожного запиту релевантні рівно два документи, але комбінацій цих пар дуже багато. У підсумку навіть найкращі сучасні ембеддери (GritLM, Qwen3, Gemini та ін.) показують на LIMIT катастрофічно низький recall – близько 20% (причому навіть на маленькій версії датасету з 46 документами, караул!).

Для порівняння, класичний BM25 або multi-vector моделі на кшталт ColBERT вибивають майже 100%. Фішка в тому, що тут ми вже не обмежені одним вектором на документ і запит. Наприклад, у ColBERT стоїть багато векторів на документ.

Ну коротше, мораль така: пошук на одному векторі – це зручно і швидко, але у нього є жорстка фундаментальна межа. Тому для серйозних систем RAG все-таки потрібні гібридні підходи: розріджений пошук, multi-vector та інше.

P.S Повна стаття