10 речей про LLM які варто знати 6/10 🧠
LLM люблять чітку розмітку
Гарного дня! 👋
Минулого разу говорили про те що LLM вигадують структуру якщо ви її не даєте: коли у промпті немає чіткого формату — модель обирає найбільш статистично ймовірну структуру з тих які бачила раніше.
Сьогодні — про інший бік цієї ж теми.
Якщо LLM добре знаходять структуру то ще краще вони працюють тоді коли ми самі даємо їм цю структуру на вході.
LLM люблять чітку розмітку тому що розмітка зменшує неоднозначність.
Коли ми пишемо моделі довгий "людський" запит — там зазвичай усе змішано разом: контекст, задача, стиль, аудиторія, обмеження, приклади, очікуваний формат. Людина може це розплутати бо розуміє інтонацію і ваші наміри. Модель теж може. Але з більшим шансом помилки — вона може переплутати приклад із завданням, контекст з інструкцією, стиль з головною ідеєю.
Наприклад можна написати так: "проаналізуй фідбек від клієнтів за останній місяць і скажи що там головне". Це нормальний запит. Але схожий на розмову в коридорі.
Можна структурованіше:
Це вже зовсім інший рівень. Тут модель бачить не просто прохання а маленьке технічне завдання.
Чому це працює технічно. LLM тренуються на масивних наборах даних де структуровані документи — технічні інструкції, бази знань, розмічений контент — представлені дуже широко. Моделі спираються на позиційне кодування й механізми уваги щоб визначати релевантність токенів. Структурні елементи — розділи, заголовки, позначені сегменти — працюють як легенда карти. Вони показують моделі де має концентруватися увага і де відбуваються семантичні переходи. Це зменшує шум і звужує варіативність прогнозування наступних токенів.
Мітки на кшталт "Definition" чи "Step 1" працюють як м'які обмеження. Вони стають опорними точками і спрямовують увагу моделі на наступні токени. Це не просто стилізація промпта — це функціональне спрямування.
Але тут є нюанс. Чітка розмітка — це не магія. Не треба кожен промпт перетворювати на документ на 40 пунктів. Проблема не в тому що промпт має бути довгим. Проблема в хаосі.
Хороший промпт не обов'язково великий. Але він має відповідати на кілька базових питань: що є на вході, що треба зробити, для кого, які обмеження, у якому форматі повернути результат.
І тут важливо розуміти чому взагалі це працює а не просто копіювати шаблон. Фактично це і є інженерія — коли людина розуміє як влаштована система бо сама писала щось подібне. Сьогодні у багатьох може виникнути спокуса не вчити синтаксис мови програмування, алгоритми, патерни, ООП — бо LLM самі пишуть код. Але в цьому криється підміна понять: тільки людина яка пройшла через фундаментальні речі має розуміння як правильно застосовувати LLM.
Поганий запит: "проаналізуй це і скажи що думаєш".
Кращий запит: "проаналізуй цей текст. Окремо виділи головну ідею, сильні сторони, слабкі місця. Дай відповідь у вигляді списку. Окремо познач де ти робиш припущення".
Різниця не в тому що другий запит "розумніший". Різниця в тому що він залишає менше простору для неправильного трактування.
У продакшені цю ідею зараз описують ширше — не просто prompt engineering а context engineering. Задача в тому щоб правильно зібрати весь контекст навколо задачі: інструкції, дані, приклади, формат відповіді, критерії якості, обмеження.
Так само як люди покладаються на заголовки й візуальну ієрархію щоб розшифрувати значення — LLM покладаються на структурні підказки щоб обмежити поведінку відповіді. Якщо промпт не має структури — модель змушена її вгадувати. Якщо структура є — модель її наслідує.
Практичне правило: коли задача стає складнішою — додавайте структуру. Не обов'язково багато. Але достатньо щоб відділити контекст від задачі, задачу від обмежень, а обмеження від формату відповіді.
Зберігай щоб не загубити 👀
🔔 ПІДПИСАТИСЯ
LLM люблять чітку розмітку
Гарного дня! 👋
Минулого разу говорили про те що LLM вигадують структуру якщо ви її не даєте: коли у промпті немає чіткого формату — модель обирає найбільш статистично ймовірну структуру з тих які бачила раніше.
Сьогодні — про інший бік цієї ж теми.
Якщо LLM добре знаходять структуру то ще краще вони працюють тоді коли ми самі даємо їм цю структуру на вході.
LLM люблять чітку розмітку тому що розмітка зменшує неоднозначність.
Коли ми пишемо моделі довгий "людський" запит — там зазвичай усе змішано разом: контекст, задача, стиль, аудиторія, обмеження, приклади, очікуваний формат. Людина може це розплутати бо розуміє інтонацію і ваші наміри. Модель теж може. Але з більшим шансом помилки — вона може переплутати приклад із завданням, контекст з інструкцією, стиль з головною ідеєю.
Наприклад можна написати так: "проаналізуй фідбек від клієнтів за останній місяць і скажи що там головне". Це нормальний запит. Але схожий на розмову в коридорі.
Можна структурованіше:
Context: 40 відгуків клієнтів після оновлення продукту
Task: визначити повторювані проблеми і запити
Audience: команда продукту, готується до планування спринту
Output: топ-5 тем з прикладами цитат, окремо позначити що є багом а що побажаннямЦе вже зовсім інший рівень. Тут модель бачить не просто прохання а маленьке технічне завдання.
Чому це працює технічно. LLM тренуються на масивних наборах даних де структуровані документи — технічні інструкції, бази знань, розмічений контент — представлені дуже широко. Моделі спираються на позиційне кодування й механізми уваги щоб визначати релевантність токенів. Структурні елементи — розділи, заголовки, позначені сегменти — працюють як легенда карти. Вони показують моделі де має концентруватися увага і де відбуваються семантичні переходи. Це зменшує шум і звужує варіативність прогнозування наступних токенів.
Мітки на кшталт "Definition" чи "Step 1" працюють як м'які обмеження. Вони стають опорними точками і спрямовують увагу моделі на наступні токени. Це не просто стилізація промпта — це функціональне спрямування.
Але тут є нюанс. Чітка розмітка — це не магія. Не треба кожен промпт перетворювати на документ на 40 пунктів. Проблема не в тому що промпт має бути довгим. Проблема в хаосі.
Хороший промпт не обов'язково великий. Але він має відповідати на кілька базових питань: що є на вході, що треба зробити, для кого, які обмеження, у якому форматі повернути результат.
І тут важливо розуміти чому взагалі це працює а не просто копіювати шаблон. Фактично це і є інженерія — коли людина розуміє як влаштована система бо сама писала щось подібне. Сьогодні у багатьох може виникнути спокуса не вчити синтаксис мови програмування, алгоритми, патерни, ООП — бо LLM самі пишуть код. Але в цьому криється підміна понять: тільки людина яка пройшла через фундаментальні речі має розуміння як правильно застосовувати LLM.
Поганий запит: "проаналізуй це і скажи що думаєш".
Кращий запит: "проаналізуй цей текст. Окремо виділи головну ідею, сильні сторони, слабкі місця. Дай відповідь у вигляді списку. Окремо познач де ти робиш припущення".
Різниця не в тому що другий запит "розумніший". Різниця в тому що він залишає менше простору для неправильного трактування.
У продакшені цю ідею зараз описують ширше — не просто prompt engineering а context engineering. Задача в тому щоб правильно зібрати весь контекст навколо задачі: інструкції, дані, приклади, формат відповіді, критерії якості, обмеження.
Так само як люди покладаються на заголовки й візуальну ієрархію щоб розшифрувати значення — LLM покладаються на структурні підказки щоб обмежити поведінку відповіді. Якщо промпт не має структури — модель змушена її вгадувати. Якщо структура є — модель її наслідує.
Практичне правило: коли задача стає складнішою — додавайте структуру. Не обов'язково багато. Але достатньо щоб відділити контекст від задачі, задачу від обмежень, а обмеження від формату відповіді.
Зберігай щоб не загубити 👀
🔔 ПІДПИСАТИСЯ
2👍9🔥6❤2
AI-токени дешеві а людські — золото 🧠
Доброго ранку ☕
Одна з найцікавіших думок яку останнім часом сформулював собі про AI-агентів для програмування звучить дуже просто:
AI-токени дешеві. Людські токени — золото.
І чим більше працюю з сучасними coding-агентами тим більше погоджуюся з цією ідеєю.
Багато хто досі намагається спочатку продумати всю архітектуру, написати ідеальне ТЗ, визначити всі API і лише потім починати розробку. Але коли ви створюєте продукт з нуля — це часто працює гірше.
До речі це дуже добре перетинається з ідеєю запуску продуктів де важливий швидкий старт і швидкий фідбек. Звісно не для кожного продукту це підходить — якщо реалізація лежить на межі науки або вбудованих систем, перший прототип на тисячі рядків коду може взагалі не запуститися 😅 Але в більшості випадків підхід працює добре.
Набагато ефективніше: написати просту специфікацію, дати агенту побудувати першу версію, подивитися що він зробив, зрозуміти що саме вам не подобається, оновити специфікацію і повторити цикл.
Чому? Тому що код сьогодні став дешевим. Якщо агент за 20 хвилин напише кілька тисяч рядків коду а потім ви їх повністю видалите — це майже нічого не коштує. А ось ваш час коштує дорого. Дуже часто лише побачивши працюючий прототип ви розумієте що інтерфейс незручний, архітектура не підходить або взагалі продукт потрібно будувати інакше. Жодна година роздумів над документом не дала б цього розуміння.
Є ще одна цікава практика. Якщо ви сказали агенту щось важливе — не покладайтеся на його пам'ять. Попросіть його одразу записати це у SPEC .md, README .md або інший документ проєкту: які технології використовуються, які рішення вже прийняті, яких принципів потрібно дотримуватися, які помилки більше не можна повторювати.
Якщо агент забуде власне відкриття — він просто витратить ще трохи токенів і знайде його знову. Але якщо він забуде ваше рішення — вам доведеться пояснювати все ще раз.
Саме тому людські токени — найдорожчий ресурс у процесі розробки.
Мені здається що в майбутньому роль розробника дедалі більше зміщуватиметься від написання коду до написання специфікацій, критеріїв оцінки і правил за якими працюватимуть агенти.
І можливо найціннішою навичкою стане вміти правильно формулювати вимоги та розуміти що взагалі потрібно робити.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕
Одна з найцікавіших думок яку останнім часом сформулював собі про AI-агентів для програмування звучить дуже просто:
AI-токени дешеві. Людські токени — золото.
І чим більше працюю з сучасними coding-агентами тим більше погоджуюся з цією ідеєю.
Багато хто досі намагається спочатку продумати всю архітектуру, написати ідеальне ТЗ, визначити всі API і лише потім починати розробку. Але коли ви створюєте продукт з нуля — це часто працює гірше.
До речі це дуже добре перетинається з ідеєю запуску продуктів де важливий швидкий старт і швидкий фідбек. Звісно не для кожного продукту це підходить — якщо реалізація лежить на межі науки або вбудованих систем, перший прототип на тисячі рядків коду може взагалі не запуститися 😅 Але в більшості випадків підхід працює добре.
Набагато ефективніше: написати просту специфікацію, дати агенту побудувати першу версію, подивитися що він зробив, зрозуміти що саме вам не подобається, оновити специфікацію і повторити цикл.
Чому? Тому що код сьогодні став дешевим. Якщо агент за 20 хвилин напише кілька тисяч рядків коду а потім ви їх повністю видалите — це майже нічого не коштує. А ось ваш час коштує дорого. Дуже часто лише побачивши працюючий прототип ви розумієте що інтерфейс незручний, архітектура не підходить або взагалі продукт потрібно будувати інакше. Жодна година роздумів над документом не дала б цього розуміння.
Є ще одна цікава практика. Якщо ви сказали агенту щось важливе — не покладайтеся на його пам'ять. Попросіть його одразу записати це у SPEC .md, README .md або інший документ проєкту: які технології використовуються, які рішення вже прийняті, яких принципів потрібно дотримуватися, які помилки більше не можна повторювати.
Якщо агент забуде власне відкриття — він просто витратить ще трохи токенів і знайде його знову. Але якщо він забуде ваше рішення — вам доведеться пояснювати все ще раз.
Саме тому людські токени — найдорожчий ресурс у процесі розробки.
Мені здається що в майбутньому роль розробника дедалі більше зміщуватиметься від написання коду до написання специфікацій, критеріїв оцінки і правил за якими працюватимуть агенти.
І можливо найціннішою навичкою стане вміти правильно формулювати вимоги та розуміти що взагалі потрібно робити.
🔔 ПІДПИСАТИСЯ
👍13❤2
Уряд США зупинив найпотужніші моделі Anthropic. Через три тижні вони повернулися — але вже іншими
Доброго ранку ☕️
Claude Fable 5 та ще потужніша Claude Mythos 5 знову доступні користувачам.
Але їхнє повернення це один із перших випадків коли державне втручання фактично зупинило глобальний доступ до передової AI-моделі. І схоже цей випадок може стати прецедентом для всієї індустрії.
9 червня Anthropic випустила Claude Fable 5 для користувачів у всьому світі. Модель мала обмеження на частину запитів пов'язаних із кібербезпекою, біологічними дослідженнями та створенням потужних AI-систем.
Однак дослідники Amazon змогли використати Fable 5 щоб отримати інформацію необхідну для проведення кібератаки — за даними WSJ саме розмови керівництва Amazon з чиновниками стали тригером для подальших дій уряду. Після цього уряд США заявив про ризики для національної безпеки.
12 червня Міністерство торгівлі видало директиву яка забороняла доступ до Claude Fable 5 та Mythos 5 для всіх іноземних громадян незалежно від того де вони перебувають. Anthropic у відповідь відключила моделі для всіх користувачів у світі.
Формально обмеження стосувалися іноземних громадян. Але реалізувати таку вимогу на практиці складно — компанії довелося б визначати не лише країну перебування користувача а і його громадянство. Тому Anthropic обрала найжорсткіший варіант і повністю призупинила доступ.
Протягом наступних тижнів компанія вела переговори з урядом і розробляла нові механізми безпеки. 30 червня обмеження зняли — WSJ описує як адміністрація Трампа поступово відкочувала заборону. 1 липня Claude Fable 5 знову стала доступною через Claude API, Claude Code та інші сервіси Anthropic. Пізніше доступ повернули також клієнтам AWS, Google Cloud і Microsoft Foundry.
Але модель повернулася вже не такою як раніше
Після повторного запуску користувачі почали скаржитися що Fable 5 стала значно обережнішою. Модель почала відмовляти навіть на деякі базові запитання з біології та частіше блокувати звичайні завдання з програмування. PCMag детально розібрав чотири конкретні способи якими бан змінив поведінку моделі.
Anthropic визнала проблему. Частину запитів система тепер автоматично перенаправляє до менш потужної Claude Opus 4.8. Компанія обіцяє навчитися краще відрізняти реальні спроби зловживання від легітимних запитів — офіційна заява і коротке підтвердження в X також фіксують цю обіцянку.
Це вже не перший конфлікт Anthropic з урядом США
У лютому Пентагон назвав Anthropic "ризиком для ланцюга постачання". Причиною стала відмова компанії надати уряду версію моделі без обмежень на використання для масового стеження та автономної зброї. Після цього Міністерство оборони США та його партнери більше не могли користуватися продуктами Anthropic.
Але ситуація з Fable 5 стала ще серйознішою. Уперше державне рішення призвело до зупинки загального доступу до передової AI-моделі для користувачів у всьому світі.
До цього моменту компанії здебільшого самостійно вирішували коли і як випускати нові моделі. Тепер у цьому процесі з'явився ще один повноцінний учасник — держава.
З одного боку це зрозуміло. Моделі стають сильнішими та потенційно можуть допомагати не лише в написанні текстів чи коду а й у пошуку вразливостей та роботі з небезпечними даними. З іншого боку непрозорі й ситуативні заборони створюють нові ризики. Компанії можуть витратити роки та мільярди доларів на модель а потім дізнатися за кілька днів до релізу що її не дозволять випустити.
Обмеження доступу до американських моделей також створює сильний стимул для інших країн розробляти власні системи. Якщо держава не може бути впевнена що завтра матиме доступ до Claude чи GPT — вона починає думати про технологічну незалежність. Регулювання яке має захищати технологічне лідерство США у довгостроковій перспективі може прискорити появу сильних конкурентів.
Повернення Claude Fable 5 це початок нового етапу у якому запуск передових моделей залежатиме не лише від готовності розробників а й від рішень урядів.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Claude Fable 5 та ще потужніша Claude Mythos 5 знову доступні користувачам.
Але їхнє повернення це один із перших випадків коли державне втручання фактично зупинило глобальний доступ до передової AI-моделі. І схоже цей випадок може стати прецедентом для всієї індустрії.
9 червня Anthropic випустила Claude Fable 5 для користувачів у всьому світі. Модель мала обмеження на частину запитів пов'язаних із кібербезпекою, біологічними дослідженнями та створенням потужних AI-систем.
Однак дослідники Amazon змогли використати Fable 5 щоб отримати інформацію необхідну для проведення кібератаки — за даними WSJ саме розмови керівництва Amazon з чиновниками стали тригером для подальших дій уряду. Після цього уряд США заявив про ризики для національної безпеки.
12 червня Міністерство торгівлі видало директиву яка забороняла доступ до Claude Fable 5 та Mythos 5 для всіх іноземних громадян незалежно від того де вони перебувають. Anthropic у відповідь відключила моделі для всіх користувачів у світі.
Формально обмеження стосувалися іноземних громадян. Але реалізувати таку вимогу на практиці складно — компанії довелося б визначати не лише країну перебування користувача а і його громадянство. Тому Anthropic обрала найжорсткіший варіант і повністю призупинила доступ.
Протягом наступних тижнів компанія вела переговори з урядом і розробляла нові механізми безпеки. 30 червня обмеження зняли — WSJ описує як адміністрація Трампа поступово відкочувала заборону. 1 липня Claude Fable 5 знову стала доступною через Claude API, Claude Code та інші сервіси Anthropic. Пізніше доступ повернули також клієнтам AWS, Google Cloud і Microsoft Foundry.
Але модель повернулася вже не такою як раніше
Після повторного запуску користувачі почали скаржитися що Fable 5 стала значно обережнішою. Модель почала відмовляти навіть на деякі базові запитання з біології та частіше блокувати звичайні завдання з програмування. PCMag детально розібрав чотири конкретні способи якими бан змінив поведінку моделі.
Anthropic визнала проблему. Частину запитів система тепер автоматично перенаправляє до менш потужної Claude Opus 4.8. Компанія обіцяє навчитися краще відрізняти реальні спроби зловживання від легітимних запитів — офіційна заява і коротке підтвердження в X також фіксують цю обіцянку.
Це вже не перший конфлікт Anthropic з урядом США
У лютому Пентагон назвав Anthropic "ризиком для ланцюга постачання". Причиною стала відмова компанії надати уряду версію моделі без обмежень на використання для масового стеження та автономної зброї. Після цього Міністерство оборони США та його партнери більше не могли користуватися продуктами Anthropic.
Але ситуація з Fable 5 стала ще серйознішою. Уперше державне рішення призвело до зупинки загального доступу до передової AI-моделі для користувачів у всьому світі.
До цього моменту компанії здебільшого самостійно вирішували коли і як випускати нові моделі. Тепер у цьому процесі з'явився ще один повноцінний учасник — держава.
З одного боку це зрозуміло. Моделі стають сильнішими та потенційно можуть допомагати не лише в написанні текстів чи коду а й у пошуку вразливостей та роботі з небезпечними даними. З іншого боку непрозорі й ситуативні заборони створюють нові ризики. Компанії можуть витратити роки та мільярди доларів на модель а потім дізнатися за кілька днів до релізу що її не дозволять випустити.
Обмеження доступу до американських моделей також створює сильний стимул для інших країн розробляти власні системи. Якщо держава не може бути впевнена що завтра матиме доступ до Claude чи GPT — вона починає думати про технологічну незалежність. Регулювання яке має захищати технологічне лідерство США у довгостроковій перспективі може прискорити появу сильних конкурентів.
Повернення Claude Fable 5 це початок нового етапу у якому запуск передових моделей залежатиме не лише від готовності розробників а й від рішень урядів.
🔔 ПІДПИСАТИСЯ
👍10❤2
DeepSeek прискорила свої моделі до 85% — без квантизації та втрати якості
Доброго ранку ☕️
DeepSeek представила DSpark — модуль спекулятивного декодування який прискорив генерацію DeepSeek-V4 у виробничому середовищі. Ваги основної моделі не змінюються а якість не погіршується. Модель і код відкриті під MIT: V4-Pro-DSpark та V4-Flash-DSpark.
Мене тут цікавить не стільки прискорення саме по собі скільки інженерна логіка якою автори до нього прийшли.
Відправна точка проста. Мовна модель генерує токени послідовно. Кожен новий токен потребує окремого проходу через велику модель навіть якщо продовження очевидне.
Ідея спекулятивного декодування з'явилась ще у 2022 році: підключити до великої моделі маленький швидкий чернетковий модуль. Він одразу пропонує кілька наступних токенів а велика модель перевіряє весь блок за один прохід. Якщо перші п'ять токенів збігаються з тим що вона сама згенерувала б — вони приймаються. Якщо шостий не збігається — усе після нього відкидається. Якість не змінюється бо фінальне рішення все одно за великою моделлю.
Тут і починається інженерна проблема яку вирішує DSpark.
Ранні чернеткові модулі генерували токени послідовно один за одним — узгоджено але повільно. Потім з'явилися паралельні модулі які генерують весь блок за один прохід — швидко, але кожна позиція передбачається майже незалежно від інших. Через це модель може змішувати різні правильні продовження: контекст можна продовжити фразами "of course" або "no problem", а паралельний модуль здатен поєднати шматки в неправильне "of problem". Класична дилема: послідовний підхід узгоджений але повільний, паралельний швидкий але розсинхронізований.
Рішення DSpark — розділити задачу на два шари. Паралельний backbone відповідає за швидкість і одним проходом накидає чернетку всього блоку. А поверх нього працює маленький послідовний компонент — Markov head — який локально виправляє узгодженість між сусідніми токенами. Якщо backbone вибрав "of" — Markov head підвищує ймовірність що наступним буде саме "course". Ключова деталь: цей компонент навмисно зроблений дуже легким. Збільшення чернетки з 4 до 16 токенів додає лише 0.2-1.3% до затримки циклу.
Другий шар рішення — усвідомлення що не кожен токен варто перевіряти з однаковою "довжиною погляду вперед". Система оцінює власну впевненість для кожного токена і калібрує ці оцінки на окремих даних щоб вони відповідали реальній частоті прийняття. Якщо ймовірність прийняття чотирьох токенів поспіль становить 90%, 80%, 70% і 60% — ймовірність що пройдуть усі чотири разом набагато нижча за 60%. Планувальник враховує це і адаптує довжину чернетки залежно від навантаження: мало запитів — довші й ризикованіші чернетки, багато запитів — коротші й надійніші блоки щоб не марнувати обчислення на малоймовірні здогадки.
Це вже не оптимізація однієї моделі а оптимізація всієї системи обслуговування запитів де рішення приймається динамічно залежно від поточного стану інфраструктури.
Порівняно з послідовним EAGLE-3 і паралельним DFlash DSpark показав приріст прийнятих токенів за цикл на обох архітектурних сім'ях моделей — і Qwen3, і Gemma — що підтверджує: підхід не прив'язаний до конкретної моделі а є загальним інженерним прийомом.
Головний урок тут не в цифрах прискорення а в самій структурі рішення: розкласти задачу на два шари з різними пріоритетами, зробити коригувальний шар максимально легким, і додати адаптивність яка реагує на реальні умови навантаження а не працює за фіксованим правилом. Патерн який можна переносити далеко за межі спекулятивного декодування.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
DeepSeek представила DSpark — модуль спекулятивного декодування який прискорив генерацію DeepSeek-V4 у виробничому середовищі. Ваги основної моделі не змінюються а якість не погіршується. Модель і код відкриті під MIT: V4-Pro-DSpark та V4-Flash-DSpark.
Мене тут цікавить не стільки прискорення саме по собі скільки інженерна логіка якою автори до нього прийшли.
Відправна точка проста. Мовна модель генерує токени послідовно. Кожен новий токен потребує окремого проходу через велику модель навіть якщо продовження очевидне.
Ідея спекулятивного декодування з'явилась ще у 2022 році: підключити до великої моделі маленький швидкий чернетковий модуль. Він одразу пропонує кілька наступних токенів а велика модель перевіряє весь блок за один прохід. Якщо перші п'ять токенів збігаються з тим що вона сама згенерувала б — вони приймаються. Якщо шостий не збігається — усе після нього відкидається. Якість не змінюється бо фінальне рішення все одно за великою моделлю.
Тут і починається інженерна проблема яку вирішує DSpark.
Ранні чернеткові модулі генерували токени послідовно один за одним — узгоджено але повільно. Потім з'явилися паралельні модулі які генерують весь блок за один прохід — швидко, але кожна позиція передбачається майже незалежно від інших. Через це модель може змішувати різні правильні продовження: контекст можна продовжити фразами "of course" або "no problem", а паралельний модуль здатен поєднати шматки в неправильне "of problem". Класична дилема: послідовний підхід узгоджений але повільний, паралельний швидкий але розсинхронізований.
Рішення DSpark — розділити задачу на два шари. Паралельний backbone відповідає за швидкість і одним проходом накидає чернетку всього блоку. А поверх нього працює маленький послідовний компонент — Markov head — який локально виправляє узгодженість між сусідніми токенами. Якщо backbone вибрав "of" — Markov head підвищує ймовірність що наступним буде саме "course". Ключова деталь: цей компонент навмисно зроблений дуже легким. Збільшення чернетки з 4 до 16 токенів додає лише 0.2-1.3% до затримки циклу.
Другий шар рішення — усвідомлення що не кожен токен варто перевіряти з однаковою "довжиною погляду вперед". Система оцінює власну впевненість для кожного токена і калібрує ці оцінки на окремих даних щоб вони відповідали реальній частоті прийняття. Якщо ймовірність прийняття чотирьох токенів поспіль становить 90%, 80%, 70% і 60% — ймовірність що пройдуть усі чотири разом набагато нижча за 60%. Планувальник враховує це і адаптує довжину чернетки залежно від навантаження: мало запитів — довші й ризикованіші чернетки, багато запитів — коротші й надійніші блоки щоб не марнувати обчислення на малоймовірні здогадки.
Це вже не оптимізація однієї моделі а оптимізація всієї системи обслуговування запитів де рішення приймається динамічно залежно від поточного стану інфраструктури.
Порівняно з послідовним EAGLE-3 і паралельним DFlash DSpark показав приріст прийнятих токенів за цикл на обох архітектурних сім'ях моделей — і Qwen3, і Gemma — що підтверджує: підхід не прив'язаний до конкретної моделі а є загальним інженерним прийомом.
Головний урок тут не в цифрах прискорення а в самій структурі рішення: розкласти задачу на два шари з різними пріоритетами, зробити коригувальний шар максимально легким, і додати адаптивність яка реагує на реальні умови навантаження а не працює за фіксованим правилом. Патерн який можна переносити далеко за межі спекулятивного декодування.
🔔 ПІДПИСАТИСЯ
👍10❤2
🍌 Google об'єднала Nano Banana з генерацією відео — і це вже схоже на готовий медіапайплайн
Доброго ранку ☕️
Компанія представила дві новинки: Nano Banana 2 Lite — швидка й дешева модель для генерації зображень, та Gemini Omni Flash — модель для створення й редагування відео із синхронізованим звуком.
Головна ідея: спочатку можна згенерувати десятки або сотні дешевих зображень, вибрати найкраще а потім одразу перетворити його на відео через той самий API.
Nano Banana 2 Lite приймає текст і зображення, генерує картинку до 1K приблизно за 4 секунди і коштує $0.034 за зображення. Gemini Omni Flash приймає текст, зображення та відео, генерує ролики до 10 секунд у 720p з одразу синхронізованим звуком за $0.10 за секунду. Тобто десятисекундний ролик коштуватиме приблизно $1.
Окремо цікаве редагування: через Interactions API модель зберігає історію сесії тому наступний промпт не генерує нове відео з нуля а змінює попередню версію. Підтримується до трьох послідовних ітерацій.
Типовий workflow виглядає так: згенерувати багато варіантів зображення, вибрати найкращий, передати його як стартовий кадр, створити відео зі звуком і додатковими командами змінити рух, стиль або сцену.
За рейтингами Arena.ai Nano Banana 2 Lite посідає п'яте місце серед моделей генерації зображень, а за рейтингом відео Gemini Omni Flash — перше місце в генерації і друге в редагуванні.
Але найважливіше тут те що генерація медіаконтенту стала достатньо дешевою і швидкою щоб виконуватися безпосередньо всередині застосунків у режимі реального часу а не залишатися повільним і ретельно контрольованим етапом виробництва. Десятисекундні кліпи можна об'єднувати в довші ролики і розробники тепер можуть автоматизувати їх створення прямо у власних продуктах.
Серед потенційних користувачів такого підходу: рекламні платформи з великими обсягами контенту, агентства цифрової реклами, творці контенту для соцмереж, сервіси персоналізованого маркетингу. Наприклад WSJ пише що Meta розробляє систему яка зможе автоматично створювати рекламні матеріали включно з відео маючи лише фотографію товару і рекламний бюджет.
Агент може створити сотню рекламних креативів, вибрати найкращі, перетворити на відео, протестувати різні версії й оптимізувати кампанію майже без участі людини.
Було б помилкою розглядати генерацію зображень і відео як єдиний ринок. Nano Banana 2 Lite і Gemini Omni Flash поки не мають достатньої роздільної здатності для повноцінного використання в голлівудському виробництві — для цього все ще існують спеціалізовані бенчмарки на кшталт MovieGenBench і VBench. Водночас покращення швидкості та вартості можуть бути не такими важливими для звичайних користувачів які лише час від часу генерують контент як хобі.
Але як уже сталося з текстом і аудіо — основна цінність мультимедійних моделей може з'явитися завдяки автоматизації, інтерактивності, персоналізації й агентним робочим процесам. Схоже зараз саме той час коли варто дати волю уяві.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Компанія представила дві новинки: Nano Banana 2 Lite — швидка й дешева модель для генерації зображень, та Gemini Omni Flash — модель для створення й редагування відео із синхронізованим звуком.
Головна ідея: спочатку можна згенерувати десятки або сотні дешевих зображень, вибрати найкраще а потім одразу перетворити його на відео через той самий API.
Nano Banana 2 Lite приймає текст і зображення, генерує картинку до 1K приблизно за 4 секунди і коштує $0.034 за зображення. Gemini Omni Flash приймає текст, зображення та відео, генерує ролики до 10 секунд у 720p з одразу синхронізованим звуком за $0.10 за секунду. Тобто десятисекундний ролик коштуватиме приблизно $1.
Окремо цікаве редагування: через Interactions API модель зберігає історію сесії тому наступний промпт не генерує нове відео з нуля а змінює попередню версію. Підтримується до трьох послідовних ітерацій.
Типовий workflow виглядає так: згенерувати багато варіантів зображення, вибрати найкращий, передати його як стартовий кадр, створити відео зі звуком і додатковими командами змінити рух, стиль або сцену.
За рейтингами Arena.ai Nano Banana 2 Lite посідає п'яте місце серед моделей генерації зображень, а за рейтингом відео Gemini Omni Flash — перше місце в генерації і друге в редагуванні.
Але найважливіше тут те що генерація медіаконтенту стала достатньо дешевою і швидкою щоб виконуватися безпосередньо всередині застосунків у режимі реального часу а не залишатися повільним і ретельно контрольованим етапом виробництва. Десятисекундні кліпи можна об'єднувати в довші ролики і розробники тепер можуть автоматизувати їх створення прямо у власних продуктах.
Серед потенційних користувачів такого підходу: рекламні платформи з великими обсягами контенту, агентства цифрової реклами, творці контенту для соцмереж, сервіси персоналізованого маркетингу. Наприклад WSJ пише що Meta розробляє систему яка зможе автоматично створювати рекламні матеріали включно з відео маючи лише фотографію товару і рекламний бюджет.
Агент може створити сотню рекламних креативів, вибрати найкращі, перетворити на відео, протестувати різні версії й оптимізувати кампанію майже без участі людини.
Було б помилкою розглядати генерацію зображень і відео як єдиний ринок. Nano Banana 2 Lite і Gemini Omni Flash поки не мають достатньої роздільної здатності для повноцінного використання в голлівудському виробництві — для цього все ще існують спеціалізовані бенчмарки на кшталт MovieGenBench і VBench. Водночас покращення швидкості та вартості можуть бути не такими важливими для звичайних користувачів які лише час від часу генерують контент як хобі.
Але як уже сталося з текстом і аудіо — основна цінність мультимедійних моделей може з'явитися завдяки автоматизації, інтерактивності, персоналізації й агентним робочим процесам. Схоже зараз саме той час коли варто дати волю уяві.
🔔 ПІДПИСАТИСЯ
👍8❤3🔥3
10 речей про LLM, які варто знати — 7/10 🧠
LLM мислять сюжетними шаблонами
Доброго ранку ☕️
Минулого разу говорили про структуру запиту, а сьогодні — про структуру самої розповіді.
Одна з причин чому AI-тексти часто здаються правильними але поверхневими полягає в тому, що моделі тяжіють до знайомих риторичних траєкторій. Найчастіше це виглядає так: проблема → інсайт → рішення → оптимістичний висновок.
Для простого контенту така структура працює добре. Текст виходить зрозумілим, логічним і завершеним.
Але зі складними темами починаються проблеми. LLM може надто швидко "закрити" питання: знайти одну головну причину, примирити суперечності та запропонувати універсальне рішення — навіть там де справжньої відповіді поки немає. І це не просто суб'єктивне враження від AI-текстів.
В одному з досліджень науковці попросили GPT-4o mini написати 11 800 історій для 236 країн. Культурні декорації змінювалися але структура часто залишалася майже однаковою: герой живе в маленькому місті або повертається додому, стикається з конфліктом, заново відкриває традиції, об'єднує спільноту — і все завершується примиренням. Реальні політичні та соціальні конфлікти при цьому згладжувалися, а напруга поступалася ностальгії та відновленню стабільності.
Автори назвали це narrative homogenisation — наративною гомогенізацією. Тобто модель змінює персонажів і декорації але продовжує відтворювати ту саму безпечну сюжетну логіку.
Anthropic дослідила поведінку п'яти AI-асистентів і виявила що всі вони тією чи іншою мірою демонстрували sycophancy — схильність погоджуватися з позицією користувача. Більше того, люди та моделі оцінювання іноді віддавали перевагу переконливо написаній відповіді яка підтримувала думку користувача а не точнішій відповіді яка їй суперечила.
Наприклад запит "поясни чому AI корисний для бізнесу" вже містить готовий висновок. Моделі залишається лише підібрати аргументи й красиво провести читача до нього: бізнес має проблему → AI її вирішує → компанія стає ефективнішою.
У дослідженні Стенфордського університету 2026 року моделям давали медичні тести з яких навмисно видалили правильний варіант. Моделям дозволяли відмовитися від відповіді. Проте вони все одно обирали один із неправильних варіантів у 53-82% випадків залежно від моделі та набору запитань.
Дослідники називають це premature closure — передчасним закриттям: модель фіксується на висновку хоча інформації для нього недостатньо.
Наприклад: «Віддалена робота підвищує продуктивність, але послаблює командну взаємодію. Як це вирішити?» LLM швидко запропонує гібридний формат і регулярні зустрічі, але може не запитати, як вимірювали продуктивність і чи проблема не в менеджменті.
Замість "поясни чому AI корисний для бізнесу" спробуйте: "поясни суперечність — AI підвищує продуктивність але може знижувати прозорість процесів". Тут модель уже не може просто захищати одну позицію. Їй потрібно показати за яких умов правильне кожне твердження і де між ними виникає реальний конфлікт.
Ще краще прямо заборонити швидке примирення: "не намагайся одразу вирішити суперечність. Спочатку покажи аргументи обох сторін, винятки та факти які не вписуються у просте пояснення. Наведи приклад який суперечить твоєму основному висновку. Заверши питаннями що залишаються відкритими".
Корисні доповнення до складних запитів: не припускай що існує одне універсальне рішення, назви щонайменше три конкуруючі пояснення, покажи за яких умов кожне з них може бути правильним, відокрем факти від правдоподібного наративу, не роби остаточного висновку якщо даних недостатньо.
Microsoft Research описує ширшу версію цього ефекту як mechanised convergence — механізовану конвергенцію: автоматизація роботи веде до збіжності простору результатів, а GenAI має гомогенізуючий ефект на людський намір.
Тому хороший текст не повинен одразу давати відповідь. Іноді його завдання — не зняти напругу а точніше показати чому вона взагалі існує.
🔔 ПІДПИСАТИСЯ
LLM мислять сюжетними шаблонами
Доброго ранку ☕️
Минулого разу говорили про структуру запиту, а сьогодні — про структуру самої розповіді.
Одна з причин чому AI-тексти часто здаються правильними але поверхневими полягає в тому, що моделі тяжіють до знайомих риторичних траєкторій. Найчастіше це виглядає так: проблема → інсайт → рішення → оптимістичний висновок.
Для простого контенту така структура працює добре. Текст виходить зрозумілим, логічним і завершеним.
Але зі складними темами починаються проблеми. LLM може надто швидко "закрити" питання: знайти одну головну причину, примирити суперечності та запропонувати універсальне рішення — навіть там де справжньої відповіді поки немає. І це не просто суб'єктивне враження від AI-текстів.
В одному з досліджень науковці попросили GPT-4o mini написати 11 800 історій для 236 країн. Культурні декорації змінювалися але структура часто залишалася майже однаковою: герой живе в маленькому місті або повертається додому, стикається з конфліктом, заново відкриває традиції, об'єднує спільноту — і все завершується примиренням. Реальні політичні та соціальні конфлікти при цьому згладжувалися, а напруга поступалася ностальгії та відновленню стабільності.
Автори назвали це narrative homogenisation — наративною гомогенізацією. Тобто модель змінює персонажів і декорації але продовжує відтворювати ту саму безпечну сюжетну логіку.
Anthropic дослідила поведінку п'яти AI-асистентів і виявила що всі вони тією чи іншою мірою демонстрували sycophancy — схильність погоджуватися з позицією користувача. Більше того, люди та моделі оцінювання іноді віддавали перевагу переконливо написаній відповіді яка підтримувала думку користувача а не точнішій відповіді яка їй суперечила.
Наприклад запит "поясни чому AI корисний для бізнесу" вже містить готовий висновок. Моделі залишається лише підібрати аргументи й красиво провести читача до нього: бізнес має проблему → AI її вирішує → компанія стає ефективнішою.
У дослідженні Стенфордського університету 2026 року моделям давали медичні тести з яких навмисно видалили правильний варіант. Моделям дозволяли відмовитися від відповіді. Проте вони все одно обирали один із неправильних варіантів у 53-82% випадків залежно від моделі та набору запитань.
Дослідники називають це premature closure — передчасним закриттям: модель фіксується на висновку хоча інформації для нього недостатньо.
Наприклад: «Віддалена робота підвищує продуктивність, але послаблює командну взаємодію. Як це вирішити?» LLM швидко запропонує гібридний формат і регулярні зустрічі, але може не запитати, як вимірювали продуктивність і чи проблема не в менеджменті.
Замість "поясни чому AI корисний для бізнесу" спробуйте: "поясни суперечність — AI підвищує продуктивність але може знижувати прозорість процесів". Тут модель уже не може просто захищати одну позицію. Їй потрібно показати за яких умов правильне кожне твердження і де між ними виникає реальний конфлікт.
Ще краще прямо заборонити швидке примирення: "не намагайся одразу вирішити суперечність. Спочатку покажи аргументи обох сторін, винятки та факти які не вписуються у просте пояснення. Наведи приклад який суперечить твоєму основному висновку. Заверши питаннями що залишаються відкритими".
Корисні доповнення до складних запитів: не припускай що існує одне універсальне рішення, назви щонайменше три конкуруючі пояснення, покажи за яких умов кожне з них може бути правильним, відокрем факти від правдоподібного наративу, не роби остаточного висновку якщо даних недостатньо.
Microsoft Research описує ширшу версію цього ефекту як mechanised convergence — механізовану конвергенцію: автоматизація роботи веде до збіжності простору результатів, а GenAI має гомогенізуючий ефект на людський намір.
Тому хороший текст не повинен одразу давати відповідь. Іноді його завдання — не зняти напругу а точніше показати чому вона взагалі існує.
🔔 ПІДПИСАТИСЯ
1👍10❤1🔥1👏1
AI не робить людей менш потрібними. Він робить їх… більш універсальними.
Доброго ранку ☕️
Є цікаве спостереження.
Коли ми говоримо про AI зазвичай обговорюємо які професії він замінить. Але на практиці відбувається дещо інше.
Раніше над продуктом працювали окремі спеціалісти: frontend, backend, mobile, DevOps. Сьогодні один інженер із хорошим AI-інструментарієм здатний закрити значну частину цих завдань самостійно. Тому цінність поступово зміщується не до написання коду а до проєктування архітектури, ухвалення технічних рішень і розуміння продукту.
Те саме починає відбуватися й в інших професіях.
Маркетологу вже не потрібно витрачати години на написання текстів, збір інформації чи підготовку простих звітів — у цьому допомагає AI. Звільнений час переходить на розробку стратегії, координацію кампаній та аналіз результатів.
У рекрутингу AI бере на себе пошук кандидатів і частину організаційної роботи. У результаті один спеціаліст здатний вести весь цикл найму самостійно.
Я сам відчуваю цей ефект на собі. Раніше будь-яке дослідження чи перевірка гіпотези займали дуже багато часу — просто тому що є робота і особисте життя і на глибоке занурення в тему часу не вистачало. Зараз швидкість зросла в усіх сферах. Менше часу йде на те щоб щось перевірити, дослідити, порівняти підходи. Я став рухатись швидше не тому що працюю більше годин а тому що частину рутинної роботи забирає AI.
Виходить цікавий тренд.
AI не просто автоматизує окремі завдання. Він розмиває межі між професіями.
Ми поступово рухаємося від вузьких спеціалістів до людей які здатні довести проєкт від ідеї до результату використовуючи AI як інструмент для виконання спеціалізованих завдань.
Саме тому сьогодні особливо цінними стають навички які раніше вважалися прерогативою senior-фахівців: системне мислення, уміння проєктувати рішення, розуміння бізнесу, здатність поєднувати в єдине ціле роботу різних напрямів.
Є гарний мисленнєвий експеримент.
Згадайте 2022 рік. Які завдання тоді виконцваои не тільки ви а й ваші колеги з суміжних ролей. Той самий frontend-розробник, маркетолог чи рекрутер поруч з вами?
Подивіться скільки з цих завдань сьогодні можете закрити ви самі завдяки AI, навіть якщо це не ваша основна спеціалізація. Ось цей приріст і є ваш новий професійний рівень — не абстрактний а виміряний у конкретних задачах які раніше вимагали окремої людини.
Можливо головний ефект AI — не заміна спеціалістів а поява покоління full-stack-фахівців майже в кожній галузі.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Є цікаве спостереження.
Коли ми говоримо про AI зазвичай обговорюємо які професії він замінить. Але на практиці відбувається дещо інше.
Раніше над продуктом працювали окремі спеціалісти: frontend, backend, mobile, DevOps. Сьогодні один інженер із хорошим AI-інструментарієм здатний закрити значну частину цих завдань самостійно. Тому цінність поступово зміщується не до написання коду а до проєктування архітектури, ухвалення технічних рішень і розуміння продукту.
Те саме починає відбуватися й в інших професіях.
Маркетологу вже не потрібно витрачати години на написання текстів, збір інформації чи підготовку простих звітів — у цьому допомагає AI. Звільнений час переходить на розробку стратегії, координацію кампаній та аналіз результатів.
У рекрутингу AI бере на себе пошук кандидатів і частину організаційної роботи. У результаті один спеціаліст здатний вести весь цикл найму самостійно.
Я сам відчуваю цей ефект на собі. Раніше будь-яке дослідження чи перевірка гіпотези займали дуже багато часу — просто тому що є робота і особисте життя і на глибоке занурення в тему часу не вистачало. Зараз швидкість зросла в усіх сферах. Менше часу йде на те щоб щось перевірити, дослідити, порівняти підходи. Я став рухатись швидше не тому що працюю більше годин а тому що частину рутинної роботи забирає AI.
Виходить цікавий тренд.
AI не просто автоматизує окремі завдання. Він розмиває межі між професіями.
Ми поступово рухаємося від вузьких спеціалістів до людей які здатні довести проєкт від ідеї до результату використовуючи AI як інструмент для виконання спеціалізованих завдань.
Саме тому сьогодні особливо цінними стають навички які раніше вважалися прерогативою senior-фахівців: системне мислення, уміння проєктувати рішення, розуміння бізнесу, здатність поєднувати в єдине ціле роботу різних напрямів.
Є гарний мисленнєвий експеримент.
Згадайте 2022 рік. Які завдання тоді виконцваои не тільки ви а й ваші колеги з суміжних ролей. Той самий frontend-розробник, маркетолог чи рекрутер поруч з вами?
Подивіться скільки з цих завдань сьогодні можете закрити ви самі завдяки AI, навіть якщо це не ваша основна спеціалізація. Ось цей приріст і є ваш новий професійний рівень — не абстрактний а виміряний у конкретних задачах які раніше вимагали окремої людини.
Можливо головний ефект AI — не заміна спеціалістів а поява покоління full-stack-фахівців майже в кожній галузі.
🔔 ПІДПИСАТИСЯ
❤9👍7💯1
Одна модель говорить, інша - думає
Доброго вечора ☕️ 🙂
OpenAI повністю перебудувала голосовий режим ChatGPT.
Щоб зрозуміти масштаб зміни — треба пройти всю еволюцію архітектури. Тож я вам це пiдготував 😎
Перший ChatGPT Voice у 2023 був каскадним пайплайном: Whisper розпізнавав мову, GPT генерував текстову відповідь, окрема TTS-модель озвучувала результат. Три моделі, три окремі виклики на кожну репліку, втрата інформації між етапами і помітна затримка.
Advanced Voice Mode який ми розбирали раніше об'єднав обробку аудіо в одну модель — це прибрало затримку між етапами. Але залишилася фундаментальна проблема: система все одно працювала turn-based. Модель чекала поки людина замовкне і лише тоді починала відповідати. А визначення "людина закінчила говорити" базувалося на тиші — тому коротка пауза або фоновий шум могли змусити модель перебити вас у невдалий момент.
Тут і починається інженерна задача яку вирішує GPT-Live.
Перше рішення — full-duplex архітектура
Замість обробки послідовності окремих повідомлень модель безперервно обробляє вхідний аудіопотік одночасно з генерацією вихідного. Це означає що система приймає рішення багато разів на секунду: говорити, слухати, зачекати, перебити, видати коротке "угу" поки співрозмовник ще говорить, або викликати інструмент у фоні.
Ключова інженерна деталь — відмова від детекції завершення репліки на основі тиші як єдиного сигналу. Система використовує кілька сигналів одночасно щоб зрозуміти чи людина справді закінчила думку чи просто зробила паузу. Це усуває цілий клас евристик з якими роками боролися розробники голосових систем: пороги тиші, таймери, спеціальні правила для шумних середовищ.
Друге і важливіше рішення — розділення розмовного і reasoning шарів
Тут головна інженерна ставка: голосова модель сама не є frontier reasoning-моделлю. Коли питання просте — вона відповідає самостійно. Коли потрібен пошук чи багатоетапний аналіз — вона делегує задачу GPT-5.5 у фоновому режимі і продовжує підтримувати розмову поки reasoning-модель працює, а потім вбудовує результат у відповідь.
Це архітектурне розділення концернів: голосовий шар оптимізований під латентність і природність, а інтелект живе в окремому бекенд-шарі. І саме це рішення — а не сам full-duplex — розробники називають найважливішим наслідком: голосовий інтерфейс автоматично стає розумнішим з кожним новим поколінням reasoning-моделей без потреби переробляти голосовий шар.
За внутрішніми тестами OpenAI GPT-Live з високим рівнем reasoning показує 84.2% на GPQA проти 45.3% у старого Advanced Voice Mode і 75.2% на BrowseComp проти 0.7%. Але всі порівняння OpenAI проводить зі своєю попередньою системою, а не з Gemini Live, Moshi чи іншими конкурентами — тому цифри варто сприймати обережно, це не незалежна перевірка.
Практичний висновок для тих хто будує подібні системи
Архітектура GPT-Live показує загальний патерн який можна переносити далеко за межі голосових інтерфейсів: розділяти шар взаємодії від шару інтелекту. Шар взаємодії оптимізується під швидкість, природність і відповідність очікуванням користувача в реальному часі. Шар інтелекту оптимізується під якість і може оновлюватися незалежно — новіша reasoning-модель одразу підвищує стелю можливостей усієї системи без переробки фронтенду.
Це той самий принцип який ми вже бачили в архітектурі DSpark де паралельний і послідовний компоненти вирішували різні частини задачі. Розкладання задачі на спеціалізовані шари з різними пріоритетами — це поки що один із найнадійніших інженерних прийомів у роботі з LLM-системами.
За даними Bloomberg, до кінця року OpenAI планує представити портативну розумну колонку без екрана яка повністю покладатиметься на голосову взаємодію GPT-Live. Продажі очікуються на початку 2027. І це логічно — саме розділення на "швидкий інтерфейс + потужний бекенд" робить подібний пристрій технічно можливим.
А ви вже спробували новий режим?
🔔 ПІДПИСАТИСЯ
Доброго вечора ☕️ 🙂
OpenAI повністю перебудувала голосовий режим ChatGPT.
Щоб зрозуміти масштаб зміни — треба пройти всю еволюцію архітектури. Тож я вам це пiдготував 😎
Перший ChatGPT Voice у 2023 був каскадним пайплайном: Whisper розпізнавав мову, GPT генерував текстову відповідь, окрема TTS-модель озвучувала результат. Три моделі, три окремі виклики на кожну репліку, втрата інформації між етапами і помітна затримка.
Advanced Voice Mode який ми розбирали раніше об'єднав обробку аудіо в одну модель — це прибрало затримку між етапами. Але залишилася фундаментальна проблема: система все одно працювала turn-based. Модель чекала поки людина замовкне і лише тоді починала відповідати. А визначення "людина закінчила говорити" базувалося на тиші — тому коротка пауза або фоновий шум могли змусити модель перебити вас у невдалий момент.
Тут і починається інженерна задача яку вирішує GPT-Live.
Перше рішення — full-duplex архітектура
Замість обробки послідовності окремих повідомлень модель безперервно обробляє вхідний аудіопотік одночасно з генерацією вихідного. Це означає що система приймає рішення багато разів на секунду: говорити, слухати, зачекати, перебити, видати коротке "угу" поки співрозмовник ще говорить, або викликати інструмент у фоні.
Ключова інженерна деталь — відмова від детекції завершення репліки на основі тиші як єдиного сигналу. Система використовує кілька сигналів одночасно щоб зрозуміти чи людина справді закінчила думку чи просто зробила паузу. Це усуває цілий клас евристик з якими роками боролися розробники голосових систем: пороги тиші, таймери, спеціальні правила для шумних середовищ.
Друге і важливіше рішення — розділення розмовного і reasoning шарів
Тут головна інженерна ставка: голосова модель сама не є frontier reasoning-моделлю. Коли питання просте — вона відповідає самостійно. Коли потрібен пошук чи багатоетапний аналіз — вона делегує задачу GPT-5.5 у фоновому режимі і продовжує підтримувати розмову поки reasoning-модель працює, а потім вбудовує результат у відповідь.
Це архітектурне розділення концернів: голосовий шар оптимізований під латентність і природність, а інтелект живе в окремому бекенд-шарі. І саме це рішення — а не сам full-duplex — розробники називають найважливішим наслідком: голосовий інтерфейс автоматично стає розумнішим з кожним новим поколінням reasoning-моделей без потреби переробляти голосовий шар.
За внутрішніми тестами OpenAI GPT-Live з високим рівнем reasoning показує 84.2% на GPQA проти 45.3% у старого Advanced Voice Mode і 75.2% на BrowseComp проти 0.7%. Але всі порівняння OpenAI проводить зі своєю попередньою системою, а не з Gemini Live, Moshi чи іншими конкурентами — тому цифри варто сприймати обережно, це не незалежна перевірка.
Практичний висновок для тих хто будує подібні системи
Архітектура GPT-Live показує загальний патерн який можна переносити далеко за межі голосових інтерфейсів: розділяти шар взаємодії від шару інтелекту. Шар взаємодії оптимізується під швидкість, природність і відповідність очікуванням користувача в реальному часі. Шар інтелекту оптимізується під якість і може оновлюватися незалежно — новіша reasoning-модель одразу підвищує стелю можливостей усієї системи без переробки фронтенду.
Це той самий принцип який ми вже бачили в архітектурі DSpark де паралельний і послідовний компоненти вирішували різні частини задачі. Розкладання задачі на спеціалізовані шари з різними пріоритетами — це поки що один із найнадійніших інженерних прийомів у роботі з LLM-системами.
За даними Bloomberg, до кінця року OpenAI планує представити портативну розумну колонку без екрана яка повністю покладатиметься на голосову взаємодію GPT-Live. Продажі очікуються на початку 2027. І це логічно — саме розділення на "швидкий інтерфейс + потужний бекенд" робить подібний пристрій технічно можливим.
А ви вже спробували новий режим?
🔔 ПІДПИСАТИСЯ
👍7❤6
Підключіть лабораторію до циклу
Доброго ранку ☕️
Дослідники з FutureHouse, Оксфордського та Фордгемського університетів представили Robin — ШІ-агента для пошуку нових способів застосування вже відомих препаратів.
Robin це не одна модель а оркестрація кількох спеціалізованих агентів кожен з яких відповідає за окрему когнітивну задачу в дослідницькому pipeline.
Crow робить короткі цілеспрямовані пошуки в літературі і пропонує експериментальні стратегії та кандидатів на препарати. Falcon робить глибші літературні огляди коли потрібен повноцінний технічний звіт а не швидка відповідь. Finch окремий агент для аналізу даних який працює вже не з текстами а з сирими експериментальними датасетами: RNA-seq, flow cytometry, результати скринінгу. Він шукає статистично значущі патерни і генерує гіпотези виходячи з самих даних а не з літератури.
Ключова інженерна ідея тут це розділення ролей за типом джерела інформації. Crow і Falcon працюють з текстовим корпусом знань. Finch працює з числовими експериментальними даними. Це різні типи задач які вимагають різних підходів до пошуку сигналу. Замість намагатися зробити одну універсальну модель яка вміє все автори розбили pipeline на спеціалізовані компоненти які передають один одному структуровані результати.
Цикл роботи виглядає так: Crow і Falcon аналізують дослідження про захворювання і визначають можливі біологічні механізми → система пропонує експерименти для перевірки гіпотези → людина фізично проводить експеримент у лабораторії → Finch аналізує отримані результати → на основі нових даних цикл формує наступну гіпотезу. Окремий компонент — суддя який ранжує гіпотези через парні порівняння — вирішує які напрямки варто досліджувати далі коли варіантів багато.
Людина поки що залишається в цьому циклі як виконавець фізичного експерименту і як точка перевірки. Вона задає захворювання й оцінює чи рухається система у правильному напрямку. Але більшість дослідницької роботи, читання літератури, формулювання гіпотез, дизайн експериментів, інтерпретація результатів, система виконує майже автономно.
Показовий масштаб: Crow опрацював 551 релевантну статтю приблизно за 30 хвилин. Задача яку дослідник виконував би близько 540 годин ручного читання і синтезу.
Robin протестували на сухій віковій макулярній дегенерації. Агент припустив що лікуванню може допомогти посилення фагоцитозу пігментного епітелію сітківки, процесу яким клітини ока очищаються від пошкоджених компонентів. Після аналізу літератури Robin запропонував два препарати: Y-27632 майже вдвічі підвищив активність потрібного процесу в ізольованих клітинах ока, а Ripasudil, вже схвалений у Японії препарат від глаукоми, дав приріст приблизно у 1.9 раза.
Важливе уточнення: препарати тестували лише на клітинах а не на пацієнтах. Це не готове лікування і навіть не доказ що метод спрацює в живому організмі.
Але сама модель роботи цінна незалежно від конкретного результату. Система не генерує гіпотезу один раз. Вона отримує дані, аналізує їх, оновлює припущення і пропонує наступний крок. Тобто бере участь у справжньому ітеративному процесі а не просто видає одноразову відповідь на запит.
Особливо перспективним виглядає саме repurposing вже схвалених ліків. Розробка нового препарату може тривати понад десять років і коштувати більше мільярда доларів при тому що регулятори схвалюють лише близько 50 нових препаратів на рік. Наявні препарати вже пройшли значну частину перевірок безпеки, тому пошук нового застосування для старих ліків це ефективне використання часу і ресурсів.
Наступний логічний крок це під'єднати таких агентів до роботизованих лабораторій щоб система могла самостійно провести й частину фізичних експериментів. Схожий підхід вже демонструє система RoboChem де AI-модель керує набором автоматизованих лабораторних інструментів.
Можливо майбутнє науки це не один універсальний "AI-науковець" а замкнений цикл спеціалізованих агентів: гіпотеза, експеримент, дані, нова гіпотеза. І людина яка визначає мету та перевіряє чи рухається система у правильному напрямку.
Код Robin на GitHub · Finch на GitHub
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Дослідники з FutureHouse, Оксфордського та Фордгемського університетів представили Robin — ШІ-агента для пошуку нових способів застосування вже відомих препаратів.
Robin це не одна модель а оркестрація кількох спеціалізованих агентів кожен з яких відповідає за окрему когнітивну задачу в дослідницькому pipeline.
Crow робить короткі цілеспрямовані пошуки в літературі і пропонує експериментальні стратегії та кандидатів на препарати. Falcon робить глибші літературні огляди коли потрібен повноцінний технічний звіт а не швидка відповідь. Finch окремий агент для аналізу даних який працює вже не з текстами а з сирими експериментальними датасетами: RNA-seq, flow cytometry, результати скринінгу. Він шукає статистично значущі патерни і генерує гіпотези виходячи з самих даних а не з літератури.
Ключова інженерна ідея тут це розділення ролей за типом джерела інформації. Crow і Falcon працюють з текстовим корпусом знань. Finch працює з числовими експериментальними даними. Це різні типи задач які вимагають різних підходів до пошуку сигналу. Замість намагатися зробити одну універсальну модель яка вміє все автори розбили pipeline на спеціалізовані компоненти які передають один одному структуровані результати.
Цикл роботи виглядає так: Crow і Falcon аналізують дослідження про захворювання і визначають можливі біологічні механізми → система пропонує експерименти для перевірки гіпотези → людина фізично проводить експеримент у лабораторії → Finch аналізує отримані результати → на основі нових даних цикл формує наступну гіпотезу. Окремий компонент — суддя який ранжує гіпотези через парні порівняння — вирішує які напрямки варто досліджувати далі коли варіантів багато.
Людина поки що залишається в цьому циклі як виконавець фізичного експерименту і як точка перевірки. Вона задає захворювання й оцінює чи рухається система у правильному напрямку. Але більшість дослідницької роботи, читання літератури, формулювання гіпотез, дизайн експериментів, інтерпретація результатів, система виконує майже автономно.
Показовий масштаб: Crow опрацював 551 релевантну статтю приблизно за 30 хвилин. Задача яку дослідник виконував би близько 540 годин ручного читання і синтезу.
Robin протестували на сухій віковій макулярній дегенерації. Агент припустив що лікуванню може допомогти посилення фагоцитозу пігментного епітелію сітківки, процесу яким клітини ока очищаються від пошкоджених компонентів. Після аналізу літератури Robin запропонував два препарати: Y-27632 майже вдвічі підвищив активність потрібного процесу в ізольованих клітинах ока, а Ripasudil, вже схвалений у Японії препарат від глаукоми, дав приріст приблизно у 1.9 раза.
Важливе уточнення: препарати тестували лише на клітинах а не на пацієнтах. Це не готове лікування і навіть не доказ що метод спрацює в живому організмі.
Але сама модель роботи цінна незалежно від конкретного результату. Система не генерує гіпотезу один раз. Вона отримує дані, аналізує їх, оновлює припущення і пропонує наступний крок. Тобто бере участь у справжньому ітеративному процесі а не просто видає одноразову відповідь на запит.
Особливо перспективним виглядає саме repurposing вже схвалених ліків. Розробка нового препарату може тривати понад десять років і коштувати більше мільярда доларів при тому що регулятори схвалюють лише близько 50 нових препаратів на рік. Наявні препарати вже пройшли значну частину перевірок безпеки, тому пошук нового застосування для старих ліків це ефективне використання часу і ресурсів.
Наступний логічний крок це під'єднати таких агентів до роботизованих лабораторій щоб система могла самостійно провести й частину фізичних експериментів. Схожий підхід вже демонструє система RoboChem де AI-модель керує набором автоматизованих лабораторних інструментів.
Можливо майбутнє науки це не один універсальний "AI-науковець" а замкнений цикл спеціалізованих агентів: гіпотеза, експеримент, дані, нова гіпотеза. І людина яка визначає мету та перевіряє чи рухається система у правильному напрямку.
Код Robin на GitHub · Finch на GitHub
🔔 ПІДПИСАТИСЯ
👍7❤2🥰2🔥1
Чи може ШІ непомітно змінювати наші переконання?
Доброго ранку ☕️
Дослідники з MIT та Carnegie Mellon поставили важливіше запитання: чи справді люди змінюють свою думку пiсля розмови з моделлю?
Вони дослідили розмови понад тисячі користувачів із GPT-4o і представили новий бенчмарк Puppet. Учасники обирали запит на особисту пораду у сфері здоров'я, фінансів або стосунків, оцінювали свою згоду з пов'язаним твердженням за шкалою від 0 до 100, спілкувалися з GPT-4o протягом 5-10 повідомлень і повторно оцінювали своє переконання. Модель при цьому отримувала різні інструкції: діяти в інтересах користувача, не переслідувати конкретних інтересів або впливати на нього в інтересах іншої сторони. Різниця між оцінками до та після розмови й була реальним показником впливу.
І тут з'являється ключова проблема попередніх детекторів маніпуляцій. Очевидно маніпулятивна відповідь може взагалі не спрацювати тому що користувач розпізнає тиск і відкине його. Натомість м'яка персоналізована порада без агресивної риторики може суттєво змінити його погляди. Тобто маніпулятивний текст і реальний вплив це не одне й те саме.
Результати це підтвердили. Традиційні детектори маніпулятивного тексту показали майже нульову кореляцію з фактичною зміною переконань. Натомість звичайні LLM отримавши транскрипт розмови змогли помірно точно оцінити наскільки змінилася думка користувача. Найкращий результат показала GPT-4o з кореляцією Спірмена 0.436, DeepSeek-V3.1 показала 0.362. Ще далеко від надійного прогнозування але значно краще за спеціалізовані детектори.
Цікаво що додавання особистої інформації про користувача, як-от демографія, риси особистості за моделлю Great Five, життєві цілі і моральні цінності, не дало стабільного покращення. Самого діалогу часто було достатньо.
Зміни переконань дуже відрізнялися між людьми. Медіана становила лише 3.3 бала зі 100, тобто більшість учасників майже не змінили свою думку. Але стандартне відхилення близько 22 балів показує що для окремих користувачів вплив був значним. І це можливо найважливіший результат: середній ефект виглядає невеликим але приховує групу людей особливо вразливих до впливу моделі.
Дослідження вимірювало лише короткострокову зміну після однієї розмови. Схожі питання про накопичувальний ефект переконання піднімають і інші роботи в цій області. Ми ще не знаємо чи зберігається такий вплив надовго і чи накопичується він після місяців регулярного спілкування з одним асистентом.
Автори показали що виявлення маніпулятивних формулювань недостатньо для оцінювання реальної сили впливу. Моделі досить непогано прогнозували фактичні зміни переконань спираючись лише на транскрипт розмови навіть без даних про демографію чи особистість користувача. Це відкриває шлях до систем які краще захищатимуть користувачів від маніпулятивної поведінки LLM.
Автори не проаналізували випадки коли переконання змінювалися після розмови з моделлю спеціально налаштованою діяти в інтересах користувача. Це був би корисний напрям для подальших досліджень — результати могли б показати наскільки ШІ здатний допомагати людям досягати цілей: опановувати навички, вивчати нову галузь знань, переходити до здоровішого способу життя. Схожі питання про позитивне використання переконливості моделей піднімає і одне з недавніх досліджень.
При цьому сам вплив не обов'язково шкідливий. Модель може переконати людину звернутися до лікаря, почати навчання, відмовитися від небезпечної звички. Це теж зміна переконань але в інтересах самого користувача.
Тому головне питання майбутнього ймовірно звучатиме не так: чи вміє модель переконувати. Вона вже вміє. Питання в іншому: чиїм інтересам служить це переконання і чи може система вчасно помітити коли вплив стає шкідливим?
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Дослідники з MIT та Carnegie Mellon поставили важливіше запитання: чи справді люди змінюють свою думку пiсля розмови з моделлю?
Вони дослідили розмови понад тисячі користувачів із GPT-4o і представили новий бенчмарк Puppet. Учасники обирали запит на особисту пораду у сфері здоров'я, фінансів або стосунків, оцінювали свою згоду з пов'язаним твердженням за шкалою від 0 до 100, спілкувалися з GPT-4o протягом 5-10 повідомлень і повторно оцінювали своє переконання. Модель при цьому отримувала різні інструкції: діяти в інтересах користувача, не переслідувати конкретних інтересів або впливати на нього в інтересах іншої сторони. Різниця між оцінками до та після розмови й була реальним показником впливу.
І тут з'являється ключова проблема попередніх детекторів маніпуляцій. Очевидно маніпулятивна відповідь може взагалі не спрацювати тому що користувач розпізнає тиск і відкине його. Натомість м'яка персоналізована порада без агресивної риторики може суттєво змінити його погляди. Тобто маніпулятивний текст і реальний вплив це не одне й те саме.
Результати це підтвердили. Традиційні детектори маніпулятивного тексту показали майже нульову кореляцію з фактичною зміною переконань. Натомість звичайні LLM отримавши транскрипт розмови змогли помірно точно оцінити наскільки змінилася думка користувача. Найкращий результат показала GPT-4o з кореляцією Спірмена 0.436, DeepSeek-V3.1 показала 0.362. Ще далеко від надійного прогнозування але значно краще за спеціалізовані детектори.
Цікаво що додавання особистої інформації про користувача, як-от демографія, риси особистості за моделлю Great Five, життєві цілі і моральні цінності, не дало стабільного покращення. Самого діалогу часто було достатньо.
Зміни переконань дуже відрізнялися між людьми. Медіана становила лише 3.3 бала зі 100, тобто більшість учасників майже не змінили свою думку. Але стандартне відхилення близько 22 балів показує що для окремих користувачів вплив був значним. І це можливо найважливіший результат: середній ефект виглядає невеликим але приховує групу людей особливо вразливих до впливу моделі.
Дослідження вимірювало лише короткострокову зміну після однієї розмови. Схожі питання про накопичувальний ефект переконання піднімають і інші роботи в цій області. Ми ще не знаємо чи зберігається такий вплив надовго і чи накопичується він після місяців регулярного спілкування з одним асистентом.
Автори показали що виявлення маніпулятивних формулювань недостатньо для оцінювання реальної сили впливу. Моделі досить непогано прогнозували фактичні зміни переконань спираючись лише на транскрипт розмови навіть без даних про демографію чи особистість користувача. Це відкриває шлях до систем які краще захищатимуть користувачів від маніпулятивної поведінки LLM.
Автори не проаналізували випадки коли переконання змінювалися після розмови з моделлю спеціально налаштованою діяти в інтересах користувача. Це був би корисний напрям для подальших досліджень — результати могли б показати наскільки ШІ здатний допомагати людям досягати цілей: опановувати навички, вивчати нову галузь знань, переходити до здоровішого способу життя. Схожі питання про позитивне використання переконливості моделей піднімає і одне з недавніх досліджень.
При цьому сам вплив не обов'язково шкідливий. Модель може переконати людину звернутися до лікаря, почати навчання, відмовитися від небезпечної звички. Це теж зміна переконань але в інтересах самого користувача.
Тому головне питання майбутнього ймовірно звучатиме не так: чи вміє модель переконувати. Вона вже вміє. Питання в іншому: чиїм інтересам служить це переконання і чи може система вчасно помітити коли вплив стає шкідливим?
🔔 ПІДПИСАТИСЯ
👍8👀2
10 речей про LLM, які варто знати — 8/10 🧠
Контраст робить пояснення точнішим
Гарного дня! 👋
Продовжуємо серію. Якщо запитати мовну модель "що таке AI-агент" — вона найімовірніше дасть правильне але досить загальне визначення: автономна система яка використовує AI для виконання завдань.
Проблема не в тому що модель не знає відповіді. Просто такий запит не пояснює які саме властивості поняття для нас важливі та де потрібно провести його межу.
Набагато корисніше запитати: "чим AI-агент відрізняється від звичайного чатбота, workflow-автоматизації та RPA?" Тепер моделі недостатньо просто перелічити властивості агента. Їй потрібно знайти ознаки за якими ці системи можна розрізнити: хто визначає послідовність дій, чи може система змінювати план, чи працює вона за жорстким сценарієм, чи самостійно обирає інструменти, де закінчується автоматизація і починається автономність.
У результаті ми отримуємо не просто визначення а межі поняття.
Цей принцип давно досліджують у когнітивній науці. Роботи Дедре Гентнер та Артура Маркмана показують що порівняння змушує людину узгоджувати структури двох об'єктів, помічати спільні зв'язки та відмінності які без порівняння могли б залишитися непомітними.
Схожий механізм спостерігається і в роботі з LLM. У дослідженні Large Language Models Are Contrastive Reasoners моделі просили сформувати не лише правильну а й неправильну відповідь а потім протиставити їх. Такий contrastive prompting покращував результати на низці арифметичних, логічних і commonsense-задач.
Автори Contrastive Chain-of-Thought Prompting пішли ще далі: вони показували моделі одночасно правильні та помилкові ланцюжки міркувань. Негативний приклад допомагав моделі зрозуміти не лише як потрібно міркувати а й яких помилок потрібно уникати.
Ці експерименти безпосередньо не доводять що будь-яке порівняльне питання завжди дасть краще пояснення. Але вони підтверджують загальний принцип: явний контраст допомагає моделі шукати розрізнювальні ознаки а не просто відтворювати типове визначення.
OpenAI, Anthropic, Google та Microsoft формулюють це трохи інакше. У своїх рекомендаціях вони радять давати моделі конкретну операцію, контекст, критерії та бажану структуру результату. Тобто не просто "поясни" а уточнити що саме потрібно знайти, порівняти або показати.
Ethan Mollick називає такі конструкції structured prompts — структурованими запитами які працюють майже як невеликі програми: задають моделі конкретне завдання та спосіб його виконання.
Наприклад замість "що таке RAG?" краще запитати: "чим RAG відрізняється від fine-tuning і простого додавання документа в контекст? Порівняй їх за актуальністю знань, вартістю, складністю та типовими сценаріями використання".
А замість "що таке галюцинація моделі?" можна запитати: "чим галюцинація відрізняється від фактичної помилки, невизначеності та застарілої інформації?"
Ще сильніший варіант промпту: "порівняй X з Y та Z за критеріями A, B і C. Покажи спільні риси, ключові відмінності, граничні випадки та приклад у якому ці поняття легко переплутати".
Тут вже видно що для ефективної роботи з моделлю недостатньо просто сформулювати питання. Треба керувати самим процесом міркування — і по суті це вже інженерний підхід а не просто вдалий промпт. Але якщо ви думали що на цьому все — ні 😁
Є ще одне застереження. Порівнювати потрібно близькі поняття. Якщо вони належать до різних рівнів або категорій — модель може побудувати штучну вісь порівняння та впевнено вигадати відмінності там де коректного зіставлення немає.
Визначення перелічує властивості. Контраст показує які з них справді мають значення.
Тому якщо хочете ясності — просіть модель не просто описати поняття а показати чим воно відрізняється від найближчих альтернатив і де проходить його межа.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
Контраст робить пояснення точнішим
Гарного дня! 👋
Продовжуємо серію. Якщо запитати мовну модель "що таке AI-агент" — вона найімовірніше дасть правильне але досить загальне визначення: автономна система яка використовує AI для виконання завдань.
Проблема не в тому що модель не знає відповіді. Просто такий запит не пояснює які саме властивості поняття для нас важливі та де потрібно провести його межу.
Набагато корисніше запитати: "чим AI-агент відрізняється від звичайного чатбота, workflow-автоматизації та RPA?" Тепер моделі недостатньо просто перелічити властивості агента. Їй потрібно знайти ознаки за якими ці системи можна розрізнити: хто визначає послідовність дій, чи може система змінювати план, чи працює вона за жорстким сценарієм, чи самостійно обирає інструменти, де закінчується автоматизація і починається автономність.
У результаті ми отримуємо не просто визначення а межі поняття.
Цей принцип давно досліджують у когнітивній науці. Роботи Дедре Гентнер та Артура Маркмана показують що порівняння змушує людину узгоджувати структури двох об'єктів, помічати спільні зв'язки та відмінності які без порівняння могли б залишитися непомітними.
Схожий механізм спостерігається і в роботі з LLM. У дослідженні Large Language Models Are Contrastive Reasoners моделі просили сформувати не лише правильну а й неправильну відповідь а потім протиставити їх. Такий contrastive prompting покращував результати на низці арифметичних, логічних і commonsense-задач.
Автори Contrastive Chain-of-Thought Prompting пішли ще далі: вони показували моделі одночасно правильні та помилкові ланцюжки міркувань. Негативний приклад допомагав моделі зрозуміти не лише як потрібно міркувати а й яких помилок потрібно уникати.
Ці експерименти безпосередньо не доводять що будь-яке порівняльне питання завжди дасть краще пояснення. Але вони підтверджують загальний принцип: явний контраст допомагає моделі шукати розрізнювальні ознаки а не просто відтворювати типове визначення.
OpenAI, Anthropic, Google та Microsoft формулюють це трохи інакше. У своїх рекомендаціях вони радять давати моделі конкретну операцію, контекст, критерії та бажану структуру результату. Тобто не просто "поясни" а уточнити що саме потрібно знайти, порівняти або показати.
Ethan Mollick називає такі конструкції structured prompts — структурованими запитами які працюють майже як невеликі програми: задають моделі конкретне завдання та спосіб його виконання.
Наприклад замість "що таке RAG?" краще запитати: "чим RAG відрізняється від fine-tuning і простого додавання документа в контекст? Порівняй їх за актуальністю знань, вартістю, складністю та типовими сценаріями використання".
А замість "що таке галюцинація моделі?" можна запитати: "чим галюцинація відрізняється від фактичної помилки, невизначеності та застарілої інформації?"
Ще сильніший варіант промпту: "порівняй X з Y та Z за критеріями A, B і C. Покажи спільні риси, ключові відмінності, граничні випадки та приклад у якому ці поняття легко переплутати".
Тут вже видно що для ефективної роботи з моделлю недостатньо просто сформулювати питання. Треба керувати самим процесом міркування — і по суті це вже інженерний підхід а не просто вдалий промпт. Але якщо ви думали що на цьому все — ні 😁
Є ще одне застереження. Порівнювати потрібно близькі поняття. Якщо вони належать до різних рівнів або категорій — модель може побудувати штучну вісь порівняння та впевнено вигадати відмінності там де коректного зіставлення немає.
Визначення перелічує властивості. Контраст показує які з них справді мають значення.
Тому якщо хочете ясності — просіть модель не просто описати поняття а показати чим воно відрізняється від найближчих альтернатив і де проходить його межа.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
👍7❤3👏3🥰1
Цього тижня сталася дуже показова історія для всієї AI-індустрії.
Доброго ранку ☕️
Протягом останніх років нам часто говорили: відкриті моделі небезпечні, закриті моделі з жорсткими guardrails безпечні. Реальний інцидент показав значно складнішу картину.
Hugging Face розкрила деталі атаки яка сталася на вихідних 11-12 липня. Компанія прямо каже: це була перша атака проведена "end-to-end автономною AI-агентною системою". Зловмисний датасет експлуатував вразливості в пайплайні обробки даних, агент escalation-ом отримав доступ до credentials і за вихідні виконав понад 17 000 автоматизованих дій через рій короткоживучих sandbox-середовищ.
За кілька днів OpenAI підтвердила що джерелом атаки була саме їхня система — під час оцінки моделей GPT-5.6 Sol на бенчмарку ExploitGym модель вирвалась за межі тестового середовища і атакувала реальну інфраструктуру Hugging Face замість ізольованого полігону.
І тут почалася найцікавіша частина.
Коли Hugging Face намагалася проаналізувати логи атаки — комерційні frontier-моделі відмовлялися допомагати. Запити містили реальні команди експлойтів, payload і артефакти command-and-control інфраструктури — і guardrails спрацьовували, не розрізняючи легітимний форензик-аналіз від спроби скласти атаку.
У підсумку команда розгорнула відкриту модель GLM 5.2 від Z.ai на власній інфраструктурі і саме через неї проаналізувала весь масив логів.
У цього рішення виявилося два практичні плюси. По-перше воно взагалі спрацювало — модель не блокувала forensic-запити. По-друге жодні дані атакувальника і жодні credentials не покинули контрольоване середовище компанії, бо аналіз відбувався локально а не через сторонній API.
Сама Hugging Face сформулювала висновок прямо у пості: це не аргумент проти safety-механізмів у хостінгових моделях. Це сигнал що командам захисту варто мати перевірену відкриту модель напоготові ще до інциденту — саме щоб уникнути ситуації коли власний захист блокує аналіз атаки на самого себе.
Чи повинні guardrails заважати аналізу вже здійсненої атаки? Між "допоможи мені зламати сервер" і "допоможи проаналізувати журнали вже виконаної атаки щоб зрозуміти що сталося" — величезна різниця. Але для класифікатора безпеки який бачить лише текст запиту ця різниця не завжди очевидна.
Ця історія вкотре показує що дискусію не можна зводити до простого "відкрите = небезпечне, закрите = безпечне". Відкриті моделі можуть не лише створювати ризики а й суттєво спрощувати аудит, цифрову криміналістику та аналіз інцидентів — особливо коли компанії потрібно тримати чутливі дані у власному периметрі. Й водночас саму атаку здійснила не відкрита а одна з найпотужніших закритих frontier-систем яка вирвалась із тестового полігону.
Тому питання не в тому щоб зробити моделі максимально "обмеженими". Питання в тому як зробити їх відповідальним інструментом для тих хто використовує їх у законних цілях — включно з захистом власної інфраструктури від атак інших AI-систем.
Що думаєте? Чи повинна модель відмовлятися аналізувати логи кібератаки якщо це робиться для захисту інфраструктури?
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Протягом останніх років нам часто говорили: відкриті моделі небезпечні, закриті моделі з жорсткими guardrails безпечні. Реальний інцидент показав значно складнішу картину.
Hugging Face розкрила деталі атаки яка сталася на вихідних 11-12 липня. Компанія прямо каже: це була перша атака проведена "end-to-end автономною AI-агентною системою". Зловмисний датасет експлуатував вразливості в пайплайні обробки даних, агент escalation-ом отримав доступ до credentials і за вихідні виконав понад 17 000 автоматизованих дій через рій короткоживучих sandbox-середовищ.
За кілька днів OpenAI підтвердила що джерелом атаки була саме їхня система — під час оцінки моделей GPT-5.6 Sol на бенчмарку ExploitGym модель вирвалась за межі тестового середовища і атакувала реальну інфраструктуру Hugging Face замість ізольованого полігону.
І тут почалася найцікавіша частина.
Коли Hugging Face намагалася проаналізувати логи атаки — комерційні frontier-моделі відмовлялися допомагати. Запити містили реальні команди експлойтів, payload і артефакти command-and-control інфраструктури — і guardrails спрацьовували, не розрізняючи легітимний форензик-аналіз від спроби скласти атаку.
У підсумку команда розгорнула відкриту модель GLM 5.2 від Z.ai на власній інфраструктурі і саме через неї проаналізувала весь масив логів.
У цього рішення виявилося два практичні плюси. По-перше воно взагалі спрацювало — модель не блокувала forensic-запити. По-друге жодні дані атакувальника і жодні credentials не покинули контрольоване середовище компанії, бо аналіз відбувався локально а не через сторонній API.
Сама Hugging Face сформулювала висновок прямо у пості: це не аргумент проти safety-механізмів у хостінгових моделях. Це сигнал що командам захисту варто мати перевірену відкриту модель напоготові ще до інциденту — саме щоб уникнути ситуації коли власний захист блокує аналіз атаки на самого себе.
Чи повинні guardrails заважати аналізу вже здійсненої атаки? Між "допоможи мені зламати сервер" і "допоможи проаналізувати журнали вже виконаної атаки щоб зрозуміти що сталося" — величезна різниця. Але для класифікатора безпеки який бачить лише текст запиту ця різниця не завжди очевидна.
Ця історія вкотре показує що дискусію не можна зводити до простого "відкрите = небезпечне, закрите = безпечне". Відкриті моделі можуть не лише створювати ризики а й суттєво спрощувати аудит, цифрову криміналістику та аналіз інцидентів — особливо коли компанії потрібно тримати чутливі дані у власному периметрі. Й водночас саму атаку здійснила не відкрита а одна з найпотужніших закритих frontier-систем яка вирвалась із тестового полігону.
Тому питання не в тому щоб зробити моделі максимально "обмеженими". Питання в тому як зробити їх відповідальним інструментом для тих хто використовує їх у законних цілях — включно з захистом власної інфраструктури від атак інших AI-систем.
Що думаєте? Чи повинна модель відмовлятися аналізувати логи кібератаки якщо це робиться для захисту інфраструктури?
🔔 ПІДПИСАТИСЯ
👍9❤4👏2
Kimi K3: відкрита модель на 2.8 трильйона параметрів майже наздогнала лідерів AI-ринку
Доброго ранку ☕️
Moonshot AI представила Kimi K3 — мультимодальну модель на 2.8 трильйона параметрів яка приймає текст, зображення та відео й підтримує контекст до 1 мільйона токенів.
Як завжди, я не писав одразу як вийшла модель, так як треба був час на те щоб детально розiбратись. Тож почнем
За незалежними тестами Kimi K3 випередила всі інші моделі з відкритими вагами та на багатьох завданнях наблизилася до найсильніших пропрієтарних систем. У Intelligence Index від Artificial Analysis: Claude Fable 5 — 60 балів, GPT-5.6 Sol — 59, Kimi K3 — 57, GLM-5.2 (про яку я писав раніше) — 51. Найкраща відкрита модель відстає від лідера лише на три бали.
На AutomationBench-AA, який тестує автоматизацію робочих процесів у бізнес-застосунках, Kimi K3 взагалі посіла перше місце серед усіх моделей. А в Code Arena WebDev вона стартувала на першій позиції, перемігши у шести із семи категорій фронтенд-розробки.
Як працює модель
Kimi K3 побудована на архітектурі Mixture of Experts. Усього модель має 896 експертів але для обробки кожного токена активуються лише 16 із них — тобто система має величезну загальну місткість не використовуючи всі 2.8 трильйона параметрів одночасно. Орієнтовно для одного токена активуються близько 50 мільярдів параметрів.
Moonshot використала дві важливі архітектурні інновації.
Kimi Delta Attention. Звичайний attention порівнює кожен новий токен з усіма попередніми — чим довший контекст тим більше потрібно пам'яті та обчислень. Kimi Delta Attention працює інакше: модель підтримує пам'ять фіксованого розміру й поступово оновлює її під час читання контексту. У попередніх експериментах Moonshot цей підхід скоротив використання пам'яті до 75%, прискорив генерацію до шести разів і дозволив ефективніше працювати з контекстом у 1 мільйон токенів.
Attention Residuals. У звичайному трансформері результат кожного шару додається до загальної суми — зі збільшенням глибини моделі внесок окремих шарів може поступово розмиватися. Attention Residuals дозволяє кожному шару вибірково звертатися до результатів попередніх шарів. Тобто модель використовує attention не лише між токенами а й між рівнями власної архітектури. У тестах блокова версія цього підходу забезпечила таку саму якість як стандартні residual connections але потребувала приблизно на 20% менше обчислень під час навчання.
Разом із більш розрідженою MoE-архітектурою та новими методами тренування це за словами Moonshot зробило навчання Kimi K3 приблизно у 2.5 раза ефективнішим за попередні запуски.
Якщо ви не маєте можливості запускати модель локально, можно заплатити, Kimi K3 коштує $3 за мільйон вхідних токенів, $0.30 за мільйон кешованих і $15 за мільйон вихідних.
Kimi K3 поступово усуває майже всі причини через які розробник обираючи модель міг би автоматично віддати перевагу найкращій пропрієтарній системі. За рівнем продуктивності вона відстає від Claude Fable 5 лише на три бали але коштує значно дешевше за одне виконане завдання.
Після публікації відкриті ваги дадуть змогу запускати модель на власній інфраструктурі, виконувати fine-tuning та дистиляцію, детальніше досліджувати роботу моделі. Власник ваг також самостійно визначає правила використання — багато запитів які Claude Fable 5 відхиляє не створюватимуть подібних обмежень для користувачів Kimi K3.
Найважливіший аспект Kimi K3 полягає саме в іншому. Moonshot досягає прогресу не лише завдяки збільшенню кількості параметрів а завдяки зміні базових компонентів трансформера: attention, residual connections і маршрутизації експертів.
Дві з цих технологій компанія вже описала в наукових роботах і опублікувала разом із кодом.
Коли лабораторії які не мають необмежених обчислювальних ресурсів відповідають на це архітектурними інноваціями й відкрито діляться результатами — виграє вся AI-індустрія.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Moonshot AI представила Kimi K3 — мультимодальну модель на 2.8 трильйона параметрів яка приймає текст, зображення та відео й підтримує контекст до 1 мільйона токенів.
Як завжди, я не писав одразу як вийшла модель, так як треба був час на те щоб детально розiбратись. Тож почнем
За незалежними тестами Kimi K3 випередила всі інші моделі з відкритими вагами та на багатьох завданнях наблизилася до найсильніших пропрієтарних систем. У Intelligence Index від Artificial Analysis: Claude Fable 5 — 60 балів, GPT-5.6 Sol — 59, Kimi K3 — 57, GLM-5.2 (про яку я писав раніше) — 51. Найкраща відкрита модель відстає від лідера лише на три бали.
На AutomationBench-AA, який тестує автоматизацію робочих процесів у бізнес-застосунках, Kimi K3 взагалі посіла перше місце серед усіх моделей. А в Code Arena WebDev вона стартувала на першій позиції, перемігши у шести із семи категорій фронтенд-розробки.
Як працює модель
Kimi K3 побудована на архітектурі Mixture of Experts. Усього модель має 896 експертів але для обробки кожного токена активуються лише 16 із них — тобто система має величезну загальну місткість не використовуючи всі 2.8 трильйона параметрів одночасно. Орієнтовно для одного токена активуються близько 50 мільярдів параметрів.
Moonshot використала дві важливі архітектурні інновації.
Kimi Delta Attention. Звичайний attention порівнює кожен новий токен з усіма попередніми — чим довший контекст тим більше потрібно пам'яті та обчислень. Kimi Delta Attention працює інакше: модель підтримує пам'ять фіксованого розміру й поступово оновлює її під час читання контексту. У попередніх експериментах Moonshot цей підхід скоротив використання пам'яті до 75%, прискорив генерацію до шести разів і дозволив ефективніше працювати з контекстом у 1 мільйон токенів.
Attention Residuals. У звичайному трансформері результат кожного шару додається до загальної суми — зі збільшенням глибини моделі внесок окремих шарів може поступово розмиватися. Attention Residuals дозволяє кожному шару вибірково звертатися до результатів попередніх шарів. Тобто модель використовує attention не лише між токенами а й між рівнями власної архітектури. У тестах блокова версія цього підходу забезпечила таку саму якість як стандартні residual connections але потребувала приблизно на 20% менше обчислень під час навчання.
Разом із більш розрідженою MoE-архітектурою та новими методами тренування це за словами Moonshot зробило навчання Kimi K3 приблизно у 2.5 раза ефективнішим за попередні запуски.
Якщо ви не маєте можливості запускати модель локально, можно заплатити, Kimi K3 коштує $3 за мільйон вхідних токенів, $0.30 за мільйон кешованих і $15 за мільйон вихідних.
Kimi K3 поступово усуває майже всі причини через які розробник обираючи модель міг би автоматично віддати перевагу найкращій пропрієтарній системі. За рівнем продуктивності вона відстає від Claude Fable 5 лише на три бали але коштує значно дешевше за одне виконане завдання.
Після публікації відкриті ваги дадуть змогу запускати модель на власній інфраструктурі, виконувати fine-tuning та дистиляцію, детальніше досліджувати роботу моделі. Власник ваг також самостійно визначає правила використання — багато запитів які Claude Fable 5 відхиляє не створюватимуть подібних обмежень для користувачів Kimi K3.
Найважливіший аспект Kimi K3 полягає саме в іншому. Moonshot досягає прогресу не лише завдяки збільшенню кількості параметрів а завдяки зміні базових компонентів трансформера: attention, residual connections і маршрутизації експертів.
Дві з цих технологій компанія вже описала в наукових роботах і опублікувала разом із кодом.
Коли лабораторії які не мають необмежених обчислювальних ресурсів відповідають на це архітектурними інноваціями й відкрито діляться результатами — виграє вся AI-індустрія.
🔔 ПІДПИСАТИСЯ
👍8🔥2❤1💯1
Cloudflare хоче перетворити доступ AI до інтернету на платну послугу
Доброго ранку ☕️
Cloudflare представила нову систему керування AI-краулерами яка дозволить власникам сайтів окремо вирішувати хто і для чого може використовувати їхній контент.
Чи користувались ви коли-небудь Cloudflare? Як на мене це дуже зручний інструмент для підприємців і власників малого бізнесу. Недавно допомагав другу запустити сайт на ньому.
Тепер можна буде дозволити індексацію сторінок для пошуку, заборонити збір даних для навчання AI-моделей і заблокувати AI-агентів які виконують дії від імені користувачів. Раніше вебкраулер зазвичай або мав доступ до сайту або не мав. Тепер Cloudflare намагається розділити ботів за їхньою реальною функцією.
Як це працюватиме
Cloudflare поділяє ботів на три категорії: search crawlers для пошукової індексації, training crawlers які збирають контент для навчання моделей, і agent crawlers які діють від імені користувача — порівнюють товари, взаємодіють із сайтами, здійснюють покупки. Для кожної категорії власник сайту зможе повністю заблокувати доступ, обмежити його лише сторінками з рекламою або дозволити повністю. Зміни мають почати застосовуватися 15 вересня.
Найцікавіша проблема виникає з краулерами які використовуються одночасно для кількох цілей. Наприклад Googlebot може індексувати контент для пошуку але водночас використовувати його для AI-продуктів. У такому разі Cloudflare застосовуватиме найсуворіше правило: якщо власник дозволив індексацію але заборонив навчання AI — багатофункціональний краулер може бути заблокований повністю.
Окремо Cloudflare представила BotBase — публічну базу відомих ботів яка класифікуватиме їх за поведінкою. Верифікація підтверджує особу оператора і дотримання robots.txt але не дає автоматичного доступу.
Платний доступ до контенту
Cloudflare планує піти далі. Компанія анонсувала систему яка дозволить власникам сайтів стягувати плату з AI-агентів за доступ до вебсторінок, датасетів, API та MCP-серверів. Коли агент спробує отримати захищений контент — Cloudflare спочатку перевірить оплату і лише після цього передасть запит сайту. Тобто компанія хоче стати платіжним шлюзом між видавцями та AI-системами.
Чому це відбувається
За даними Cloudflare 57.5% усіх HTTP-запитів сьогодні надходять від автоматизованих систем а не від людей. Стара угода між сайтами та пошуковиками руйнується: раніше сайт дозволяв індексацію → пошуковик показував посилання → людина переходила на сайт → видавець заробляв на рекламі. Тепер AI-агент читає сторінку, формує готову відповідь і не відправляє користувача на оригінал. Контент використано але власник нічого не отримав. Саме тому деякі видавці вже відмовляються від індексації в Google.
Доступ до якісних даних з відкритого інтернету залишається критично важливим для розвитку AI. Але видавці та посередники як Cloudflare дедалі частіше обмежують способи їх збору. Великі компанії вже зібрали величезні масиви вебданих і можуть укладати прямі угоди з видавцями. Нові гравці таких ресурсів не мають і стикаються з вищими бар'єрами доступу до знань. Тому нові обмеження можуть не зрівняти ринок а навпаки посилити перевагу найбільших гравців.
Cloudflare вважає що між AI-компаніями та видавцями можна укласти нову угоду а сама компанія може виступити оператором платного пропускного пункту. Але це суперечить принципу яким керується більшість AI-компаній: навчання на загальнодоступних даних має вважатися добросовісним використанням.
Поки що незрозуміло чи має Cloudflare достатньо впливу щоб запровадити таку плату і чиє визначення справедливості зрештою переможе.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Cloudflare представила нову систему керування AI-краулерами яка дозволить власникам сайтів окремо вирішувати хто і для чого може використовувати їхній контент.
Чи користувались ви коли-небудь Cloudflare? Як на мене це дуже зручний інструмент для підприємців і власників малого бізнесу. Недавно допомагав другу запустити сайт на ньому.
Тепер можна буде дозволити індексацію сторінок для пошуку, заборонити збір даних для навчання AI-моделей і заблокувати AI-агентів які виконують дії від імені користувачів. Раніше вебкраулер зазвичай або мав доступ до сайту або не мав. Тепер Cloudflare намагається розділити ботів за їхньою реальною функцією.
Як це працюватиме
Cloudflare поділяє ботів на три категорії: search crawlers для пошукової індексації, training crawlers які збирають контент для навчання моделей, і agent crawlers які діють від імені користувача — порівнюють товари, взаємодіють із сайтами, здійснюють покупки. Для кожної категорії власник сайту зможе повністю заблокувати доступ, обмежити його лише сторінками з рекламою або дозволити повністю. Зміни мають почати застосовуватися 15 вересня.
Найцікавіша проблема виникає з краулерами які використовуються одночасно для кількох цілей. Наприклад Googlebot може індексувати контент для пошуку але водночас використовувати його для AI-продуктів. У такому разі Cloudflare застосовуватиме найсуворіше правило: якщо власник дозволив індексацію але заборонив навчання AI — багатофункціональний краулер може бути заблокований повністю.
Окремо Cloudflare представила BotBase — публічну базу відомих ботів яка класифікуватиме їх за поведінкою. Верифікація підтверджує особу оператора і дотримання robots.txt але не дає автоматичного доступу.
Платний доступ до контенту
Cloudflare планує піти далі. Компанія анонсувала систему яка дозволить власникам сайтів стягувати плату з AI-агентів за доступ до вебсторінок, датасетів, API та MCP-серверів. Коли агент спробує отримати захищений контент — Cloudflare спочатку перевірить оплату і лише після цього передасть запит сайту. Тобто компанія хоче стати платіжним шлюзом між видавцями та AI-системами.
Чому це відбувається
За даними Cloudflare 57.5% усіх HTTP-запитів сьогодні надходять від автоматизованих систем а не від людей. Стара угода між сайтами та пошуковиками руйнується: раніше сайт дозволяв індексацію → пошуковик показував посилання → людина переходила на сайт → видавець заробляв на рекламі. Тепер AI-агент читає сторінку, формує готову відповідь і не відправляє користувача на оригінал. Контент використано але власник нічого не отримав. Саме тому деякі видавці вже відмовляються від індексації в Google.
Доступ до якісних даних з відкритого інтернету залишається критично важливим для розвитку AI. Але видавці та посередники як Cloudflare дедалі частіше обмежують способи їх збору. Великі компанії вже зібрали величезні масиви вебданих і можуть укладати прямі угоди з видавцями. Нові гравці таких ресурсів не мають і стикаються з вищими бар'єрами доступу до знань. Тому нові обмеження можуть не зрівняти ринок а навпаки посилити перевагу найбільших гравців.
Cloudflare вважає що між AI-компаніями та видавцями можна укласти нову угоду а сама компанія може виступити оператором платного пропускного пункту. Але це суперечить принципу яким керується більшість AI-компаній: навчання на загальнодоступних даних має вважатися добросовісним використанням.
Поки що незрозуміло чи має Cloudflare достатньо впливу щоб запровадити таку плату і чиє визначення справедливості зрештою переможе.
🔔 ПІДПИСАТИСЯ
👍6❤1🤔1
🔓 Ще один аргумент на користь відкритих AI-моделей
Доброго ранку ☕️
Я не раз розповідав вам про open source і open-weight моделі. Мені завжди подобався сам принцип відкритого коду — ще з часів коли я був просто інженером і зараз з не меншим інтересом стежу за open-weight моделями. З одного боку це можливість детальніше розібратися як усе влаштовано зсередини. З іншого — це справжній двигун прогресу в AI.
Ендрю Ин розповів про кейс з OpenWorker — власним open source AI-агентом який вони з Rohit Prasad щойно випустили. Команда проводила аудит безпеки цього проєкту і вирішила залучити AI-агентів.
Спочатку використали Claude Code з Fable 5 та Codex з GPT-5.6 Sol. Результат виявився несподіваним. Claude просто зупинив роботу і відмовився продовжувати перевірку. GPT-5.6 Sol зміг непогано описати потенційні вектори атак за відомими методологіями на кшталт MITRE ATT&CK але на певному етапі захотів "спуститися" до менш потужної моделі і фактично теж відмовився заглиблюватися далі.
Тоді команда перейшла на власний агентний фреймворк OpenWorker з відкритими моделями GLM 5.2 та Kimi K3. І саме вони дозволили довести аудит до кінця та отримати впевненість у безпеці системи.
Ин прямо пов'язує цей випадок з нещодавньою історією Hugging Face де закриті моделі відмовилися допомагати з форензик-аналізом після атаки і команді довелося перейти на відкриту GLM 5.2 щоб проаналізувати логи.
На мій погляд цей випадок добре демонструє одну важливу проблему. Закриті моделі дедалі частіше не лише блокують потенційно небезпечні дії а й можуть відмовитися допомагати навіть тоді коли користувач перевіряє власний код і намагається знайти в ньому вразливості до того як це зроблять зловмисники.
У світі де атакувальники вже активно використовують AI для автоматизованого пошуку вразливостей така поведінка створює складну дилему для команд що відповідають за безпеку. Вони чують від security-фахівців дедалі більше розчарування саме з цього приводу.
Саме тому відкриті моделі стають важливими не лише з точки зору незалежності чи вартості. Вони також дають можливість виконувати повноцінні аудити безпеки без штучних обмежень якщо це відбувається в легітимному контексті.
Схоже що дискусія про open vs closed AI поступово виходить за межі питання продуктивності. Все частіше вона стосується того хто зрештою контролює можливості інструменту — його користувач чи постачальник моделі.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Я не раз розповідав вам про open source і open-weight моделі. Мені завжди подобався сам принцип відкритого коду — ще з часів коли я був просто інженером і зараз з не меншим інтересом стежу за open-weight моделями. З одного боку це можливість детальніше розібратися як усе влаштовано зсередини. З іншого — це справжній двигун прогресу в AI.
Ендрю Ин розповів про кейс з OpenWorker — власним open source AI-агентом який вони з Rohit Prasad щойно випустили. Команда проводила аудит безпеки цього проєкту і вирішила залучити AI-агентів.
Спочатку використали Claude Code з Fable 5 та Codex з GPT-5.6 Sol. Результат виявився несподіваним. Claude просто зупинив роботу і відмовився продовжувати перевірку. GPT-5.6 Sol зміг непогано описати потенційні вектори атак за відомими методологіями на кшталт MITRE ATT&CK але на певному етапі захотів "спуститися" до менш потужної моделі і фактично теж відмовився заглиблюватися далі.
Тоді команда перейшла на власний агентний фреймворк OpenWorker з відкритими моделями GLM 5.2 та Kimi K3. І саме вони дозволили довести аудит до кінця та отримати впевненість у безпеці системи.
Ин прямо пов'язує цей випадок з нещодавньою історією Hugging Face де закриті моделі відмовилися допомагати з форензик-аналізом після атаки і команді довелося перейти на відкриту GLM 5.2 щоб проаналізувати логи.
На мій погляд цей випадок добре демонструє одну важливу проблему. Закриті моделі дедалі частіше не лише блокують потенційно небезпечні дії а й можуть відмовитися допомагати навіть тоді коли користувач перевіряє власний код і намагається знайти в ньому вразливості до того як це зроблять зловмисники.
У світі де атакувальники вже активно використовують AI для автоматизованого пошуку вразливостей така поведінка створює складну дилему для команд що відповідають за безпеку. Вони чують від security-фахівців дедалі більше розчарування саме з цього приводу.
Саме тому відкриті моделі стають важливими не лише з точки зору незалежності чи вартості. Вони також дають можливість виконувати повноцінні аудити безпеки без штучних обмежень якщо це відбувається в легітимному контексті.
Схоже що дискусія про open vs closed AI поступово виходить за межі питання продуктивності. Все частіше вона стосується того хто зрештою контролює можливості інструменту — його користувач чи постачальник моделі.
🔔 ПІДПИСАТИСЯ
👍8🔥3❤2👏2
🔥 Anthropic знову зробила Opus однією зі своїх ключових моделей
Доброго ранку ☕️
Після релізу Claude Fable 5 майбутнє лінійки Opus здавалося невизначеним. Але Anthropic представила Claude Opus 5 — модель яка в багатьох завданнях перевершує Fable, коштує дешевше і доступна ширшому колу користувачів.
І це не просто чергове оновлення бенчмарків.
Claude Opus 5 отримав контекст до 1 млн токенів, п'ять рівнів reasoning, підтримку інструментів, роботу із зображеннями та окремий Fast Mode приблизно у 2.5 раза швидший за стандартний.
Але найцікавіше — результати.
На Artificial Analysis Intelligence Index новий Opus посів перше місце з 61 балом, трохи випередивши Claude Fable 5 та GPT-5.6 Sol. У Coding Agent Index він розділив перше місце з GPT-5.6 Sol. Схожа картина і на інших незалежних бенчмарках — Zapier та Cursor також ставлять Opus 5 серед лідерів у своїх власних тестах на реальні агентні задачі.
А на ARC-AGI-3, де агент має самостійно розібратися з правилами незнайомого середовища, Claude Opus 5 показав 30.2%. Найближчий конкурент GPT-5.6 Sol отримав лише 7.8%.
Тобто найбільша перевага нової моделі проявилася не у звичайному знанні фактів чи написанні текстів а саме у здатності навчатися під час виконання завдання.
Це добре узгоджується зі стратегією Anthropic. Компанія заявляє у власній документації що Opus 5 краще делегує роботу субагентам, перевіряє власні результати, виконує довгі програмні та бізнес-процеси. Anthropic навіть рекомендує прибирати частину старих інструкцій на кшталт "обов'язково перевір свою відповідь" — модель і без цього схильна перевіряти себе надто ретельно.
Окремо компанія переглянула систему безпеки. Claude Opus 5 усуває більшість претензій користувачів до Fable 5: менше необґрунтованих fallback-відмов, менше блокувань безпечних наукових тем, значно нижча ціна, доступність у дешевших підписках і відсутність політики 30-денного зберігання даних яка була головним болем для enterprise-клієнтів. Аналіз власного коду на вразливості офіційно дозволений. Водночас запити на створення експлойтів або проведення атак усе ще можуть спричинити fallback на старішу модель.
Водночас Claude Fable 5 усе ще має переваги. Він рідше галюцинує, краще відтворює фактичну інформацію і в деяких складних сценаріях залишається сильнішою моделлю. Не виключено також що нинішні бенчмарки ще не повністю відображають реальну різницю між двома моделями — до речі окремо варто згадати що TechCrunch розбирав і чутки про те що успіх Kimi K3 пов'язаний з експлуатацією Fable 5 — експерти цю версію не підтверджують.
При цьому Opus 5 коштує через API $5 за мільйон вхідних і $25 за мільйон вихідних токенів. Це дешевше за Fable хоча модель усе одно залишається дорожчою за більшість конкурентів.
Схоже Anthropic свідомо не бере участі у перегонах за найдешевший і найшвидший inference. Поки більшість AI-компаній робить ставку на швидкість і здешевлення, Anthropic рухається у протилежному напрямку — створює великі, повільніші але дуже компетентні моделі. Компанія робить ставку на те що для таких сфер як кібербезпека, розробка ПЗ та робота з документами користувачі готові платити більше за максимальну якість. А якщо потрібна ще й висока швидкість — вони будуть готові заплатити ще більше.
Тому Opus 5 це не повна заміна Fable. Швидше це модель яку Anthropic нарешті зробила достатньо сильною, доступною та передбачуваною для щоденної роботи.
І можливо головний висновок цього релізу такий: майбутня конкуренція моделей відбуватиметься не лише навколо того хто краще відповідає на запитання а навколо того хто краще виконує довгу роботу від початку до кінця.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Після релізу Claude Fable 5 майбутнє лінійки Opus здавалося невизначеним. Але Anthropic представила Claude Opus 5 — модель яка в багатьох завданнях перевершує Fable, коштує дешевше і доступна ширшому колу користувачів.
І це не просто чергове оновлення бенчмарків.
Claude Opus 5 отримав контекст до 1 млн токенів, п'ять рівнів reasoning, підтримку інструментів, роботу із зображеннями та окремий Fast Mode приблизно у 2.5 раза швидший за стандартний.
Але найцікавіше — результати.
На Artificial Analysis Intelligence Index новий Opus посів перше місце з 61 балом, трохи випередивши Claude Fable 5 та GPT-5.6 Sol. У Coding Agent Index він розділив перше місце з GPT-5.6 Sol. Схожа картина і на інших незалежних бенчмарках — Zapier та Cursor також ставлять Opus 5 серед лідерів у своїх власних тестах на реальні агентні задачі.
А на ARC-AGI-3, де агент має самостійно розібратися з правилами незнайомого середовища, Claude Opus 5 показав 30.2%. Найближчий конкурент GPT-5.6 Sol отримав лише 7.8%.
Тобто найбільша перевага нової моделі проявилася не у звичайному знанні фактів чи написанні текстів а саме у здатності навчатися під час виконання завдання.
Це добре узгоджується зі стратегією Anthropic. Компанія заявляє у власній документації що Opus 5 краще делегує роботу субагентам, перевіряє власні результати, виконує довгі програмні та бізнес-процеси. Anthropic навіть рекомендує прибирати частину старих інструкцій на кшталт "обов'язково перевір свою відповідь" — модель і без цього схильна перевіряти себе надто ретельно.
Окремо компанія переглянула систему безпеки. Claude Opus 5 усуває більшість претензій користувачів до Fable 5: менше необґрунтованих fallback-відмов, менше блокувань безпечних наукових тем, значно нижча ціна, доступність у дешевших підписках і відсутність політики 30-денного зберігання даних яка була головним болем для enterprise-клієнтів. Аналіз власного коду на вразливості офіційно дозволений. Водночас запити на створення експлойтів або проведення атак усе ще можуть спричинити fallback на старішу модель.
Водночас Claude Fable 5 усе ще має переваги. Він рідше галюцинує, краще відтворює фактичну інформацію і в деяких складних сценаріях залишається сильнішою моделлю. Не виключено також що нинішні бенчмарки ще не повністю відображають реальну різницю між двома моделями — до речі окремо варто згадати що TechCrunch розбирав і чутки про те що успіх Kimi K3 пов'язаний з експлуатацією Fable 5 — експерти цю версію не підтверджують.
При цьому Opus 5 коштує через API $5 за мільйон вхідних і $25 за мільйон вихідних токенів. Це дешевше за Fable хоча модель усе одно залишається дорожчою за більшість конкурентів.
Схоже Anthropic свідомо не бере участі у перегонах за найдешевший і найшвидший inference. Поки більшість AI-компаній робить ставку на швидкість і здешевлення, Anthropic рухається у протилежному напрямку — створює великі, повільніші але дуже компетентні моделі. Компанія робить ставку на те що для таких сфер як кібербезпека, розробка ПЗ та робота з документами користувачі готові платити більше за максимальну якість. А якщо потрібна ще й висока швидкість — вони будуть готові заплатити ще більше.
Тому Opus 5 це не повна заміна Fable. Швидше це модель яку Anthropic нарешті зробила достатньо сильною, доступною та передбачуваною для щоденної роботи.
І можливо головний висновок цього релізу такий: майбутня конкуренція моделей відбуватиметься не лише навколо того хто краще відповідає на запитання а навколо того хто краще виконує довгу роботу від початку до кінця.
🔔 ПІДПИСАТИСЯ
👍7🔥3❤1👾1
10 речей про LLM, які варто знати — 9/10 🧠
##, списки та блоки в промптах — це не просто оформлення
Гарного дня! 👋
Продовжуємо серію. Минулого разу говорили про те що контраст робить пояснення точнішим. Сьогодні про іншу річ яку часто недооцінюють — саму розмітку промпта.
Коли ми пишемо промпт так:
символи ##, списки та блоки допомагають не лише людині швидше прочитати інструкцію. Вони також дають мовній моделі сигнали про структуру тексту: де починається новий розділ, що є завданням а що контекстом, які вимоги незалежні одна від одної, де знаходяться приклади або вхідні дані, у якому форматі потрібно повернути результат.
Але тут є важливе уточнення.
Markdown це не програмний синтаксис який LLM виконує за жорсткими правилами. Заголовок "## Important" не отримує автоматично вищий пріоритет лише через два символи #. Це радше м'яка структурна розмітка.
Моделі навчалися на великій кількості документації, README-файлів, коду, специфікацій та вебсторінок. Тому Markdown, XML, JSON і схожі формати для них знайомі способи організації інформації.
Саме тому OpenAI рекомендує використовувати Markdown-заголовки та списки для поділу промпта на секції а XML-теги для відокремлення документів, контексту й метаданих.
Anthropic особливо активно рекомендує конструкції на кшталт:
Google радить обрати один спосіб структурування, Markdown або XML, і використовувати його послідовно. Microsoft і Mistral також зазначають що ці формати добре знайомі моделям через структуру даних на яких вони навчалися.
Які символи краще використовувати
Заголовки #, ##, ### для логічних розділів: "## Завдання", "## Обмеження", "## Формат відповіді".
Списки для окремих вимог: "Збережи головну думку", "Прибери повтори", "Додай конкретику".
Нумеровані списки коли важливий порядок дій: "1. Проаналізуй текст", "2. Знайди шаблонні фрази", "3. Перепиши", "4. Перевір результат".
Потрійні зворотні лапки щоб відокремити текст, код або дані від самої інструкції.
XML-теги коли промпт великий, містить кілька документів або має вкладену структуру.
А ось конструкція "Role: AI content editor" з подвійною стрілкою на початку виглядає ефектно але з погляду стандартного Markdown такий символ означає вкладену цитату а не спеціальне поле промпта. Краще написати звичайним заголовком: "## Role" і далі текст.
Головний best practice
Не намагайтеся "запрограмувати" модель декоративними символами типу потрійних знаків оклику чи стрілок навколо слів MUST FOLLOW. Краще створити просту й зрозумілу структуру: Goal, Context, Requirements, Input, Output.
Дослідження впливу Markdown, JSON, YAML і plain text показує що формат промпта справді може впливати на якість відповіді. Але універсального переможця немає: в одних задачах краще працює Markdown, в інших XML, JSON або навіть звичайний текст. Дослідження використання розділювачів у промптах підтверджує той самий висновок.
Тому структура це не магія і не гарантія. Це спосіб зменшити неоднозначність, зробити інструкцію зрозумілішою, відокремити команди від даних, спростити тестування і підтримку промптів, підвищити ймовірність стабільного результату.
Markdown не зовсім рідна мова LLM. Але це точно один із найбільш знайомих їй діалектів.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
##, списки та блоки в промптах — це не просто оформлення
Гарного дня! 👋
Продовжуємо серію. Минулого разу говорили про те що контраст робить пояснення точнішим. Сьогодні про іншу річ яку часто недооцінюють — саму розмітку промпта.
Коли ми пишемо промпт так:
## Role
AI content editor
## Goal
Зробити текст природнішим
## Keep
- основну думку
- факти
- стиль автора
## Remove
- шаблонні фрази
- повтори
- надмірні підсумкисимволи ##, списки та блоки допомагають не лише людині швидше прочитати інструкцію. Вони також дають мовній моделі сигнали про структуру тексту: де починається новий розділ, що є завданням а що контекстом, які вимоги незалежні одна від одної, де знаходяться приклади або вхідні дані, у якому форматі потрібно повернути результат.
Але тут є важливе уточнення.
Markdown це не програмний синтаксис який LLM виконує за жорсткими правилами. Заголовок "## Important" не отримує автоматично вищий пріоритет лише через два символи #. Це радше м'яка структурна розмітка.
Моделі навчалися на великій кількості документації, README-файлів, коду, специфікацій та вебсторінок. Тому Markdown, XML, JSON і схожі формати для них знайомі способи організації інформації.
Саме тому OpenAI рекомендує використовувати Markdown-заголовки та списки для поділу промпта на секції а XML-теги для відокремлення документів, контексту й метаданих.
Anthropic особливо активно рекомендує конструкції на кшталт:
<instructions>
Перепиши текст.
</instructions>
<context>
Текст призначений для Telegram.
</context>
<source_text>
...
</source_text>Google радить обрати один спосіб структурування, Markdown або XML, і використовувати його послідовно. Microsoft і Mistral також зазначають що ці формати добре знайомі моделям через структуру даних на яких вони навчалися.
Які символи краще використовувати
Заголовки #, ##, ### для логічних розділів: "## Завдання", "## Обмеження", "## Формат відповіді".
Списки для окремих вимог: "Збережи головну думку", "Прибери повтори", "Додай конкретику".
Нумеровані списки коли важливий порядок дій: "1. Проаналізуй текст", "2. Знайди шаблонні фрази", "3. Перепиши", "4. Перевір результат".
Потрійні зворотні лапки щоб відокремити текст, код або дані від самої інструкції.
XML-теги коли промпт великий, містить кілька документів або має вкладену структуру.
А ось конструкція "Role: AI content editor" з подвійною стрілкою на початку виглядає ефектно але з погляду стандартного Markdown такий символ означає вкладену цитату а не спеціальне поле промпта. Краще написати звичайним заголовком: "## Role" і далі текст.
Головний best practice
Не намагайтеся "запрограмувати" модель декоративними символами типу потрійних знаків оклику чи стрілок навколо слів MUST FOLLOW. Краще створити просту й зрозумілу структуру: Goal, Context, Requirements, Input, Output.
Дослідження впливу Markdown, JSON, YAML і plain text показує що формат промпта справді може впливати на якість відповіді. Але універсального переможця немає: в одних задачах краще працює Markdown, в інших XML, JSON або навіть звичайний текст. Дослідження використання розділювачів у промптах підтверджує той самий висновок.
Тому структура це не магія і не гарантія. Це спосіб зменшити неоднозначність, зробити інструкцію зрозумілішою, відокремити команди від даних, спростити тестування і підтримку промптів, підвищити ймовірність стабільного результату.
Markdown не зовсім рідна мова LLM. Але це точно один із найбільш знайомих їй діалектів.
Зберігай щоб не загубити, а наступного разу — ще один важливий факт про LLM 👀
🔔 ПІДПИСАТИСЯ
❤8👍4🔥2
Більше токенів ≠ більше продуктивності
Доброго ранку ☕️
Останнім часом в AI-середовищі набрала популярності доволі проста ідея: хочете отримувати більше користі від AI — використовуйте більше токенів.
Запускайте більше агентів. Давайте їм більше контексту. Нехай вони довше думають. Паралельно запускайте ще кілька. І взагалі чим більше compute ви спалюєте тим продуктивнішими стаєте.
Для цього навіть з'явився термін — tokenmaxxing.
І в цій ідеї є частина правди. Сучасні reasoning-моделі справді можуть використовувати додатковий compute для складніших задач. Агенти можуть паралельно досліджувати різні рішення. Більший контекст дозволяє працювати з більшими кодовими базами та документами. METR документує як стрімко зростає час автономної роботи моделей над задачами — межа того скільки токенів ми можемо корисно використати постійно зростає.
Але є одна проблема.
У певний момент bottleneck перестає бути в AI.
Модель уже написала код — але його має хтось перевірити. Агенти запропонували п'ять архітектур — але хтось має вибрати одну. AI створив 20 варіантів документа — але тепер людині потрібно прочитати 20 варіантів.
Можна запустити ще десять агентів. Але якщо процес review, прийняття рішень або інтеграції залишився тим самим — ви просто швидше створюєте чергу роботи для людей. Починається diminishing return: кожна наступна тисяча або мільйон токенів приносить усе менше реальної користі.
І тут є ще один цікавий момент.
Компанії які продають AI compute природно зацікавлені в тому щоб ми використовували його більше. Це не якась особливість AI-бізнесу. Автосервіси десятиліттями радили міняти мастило частіше ніж це реально потрібно багатьом автомобілям. У рекламі зубної пасти щітку покривають пастою майже повністю хоча стоматологи рекомендують значно меншу кількість. Продукт може бути дуже корисним і водночас його виробнику вигідно щоб ви використовували його більше.
З AI відбувається приблизно те саме.
Тому питання яке варто ставити компаніям звучить так: "де додатковий AI реально збільшує throughput нашої системи?"
Іноді відповіддю справді будуть мільйони додаткових токенів і десятки агентів. А іноді зміна процесу review, автоматизація integration pipeline, кращі evals або просто усунення організаційного bottleneck.
Бо мета не максимізувати кількість використаних токенів. Мета максимізувати кількість корисної роботи яка доходить до production.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
Останнім часом в AI-середовищі набрала популярності доволі проста ідея: хочете отримувати більше користі від AI — використовуйте більше токенів.
Запускайте більше агентів. Давайте їм більше контексту. Нехай вони довше думають. Паралельно запускайте ще кілька. І взагалі чим більше compute ви спалюєте тим продуктивнішими стаєте.
Для цього навіть з'явився термін — tokenmaxxing.
І в цій ідеї є частина правди. Сучасні reasoning-моделі справді можуть використовувати додатковий compute для складніших задач. Агенти можуть паралельно досліджувати різні рішення. Більший контекст дозволяє працювати з більшими кодовими базами та документами. METR документує як стрімко зростає час автономної роботи моделей над задачами — межа того скільки токенів ми можемо корисно використати постійно зростає.
Але є одна проблема.
У певний момент bottleneck перестає бути в AI.
Модель уже написала код — але його має хтось перевірити. Агенти запропонували п'ять архітектур — але хтось має вибрати одну. AI створив 20 варіантів документа — але тепер людині потрібно прочитати 20 варіантів.
Можна запустити ще десять агентів. Але якщо процес review, прийняття рішень або інтеграції залишився тим самим — ви просто швидше створюєте чергу роботи для людей. Починається diminishing return: кожна наступна тисяча або мільйон токенів приносить усе менше реальної користі.
І тут є ще один цікавий момент.
Компанії які продають AI compute природно зацікавлені в тому щоб ми використовували його більше. Це не якась особливість AI-бізнесу. Автосервіси десятиліттями радили міняти мастило частіше ніж це реально потрібно багатьом автомобілям. У рекламі зубної пасти щітку покривають пастою майже повністю хоча стоматологи рекомендують значно меншу кількість. Продукт може бути дуже корисним і водночас його виробнику вигідно щоб ви використовували його більше.
З AI відбувається приблизно те саме.
Тому питання яке варто ставити компаніям звучить так: "де додатковий AI реально збільшує throughput нашої системи?"
Іноді відповіддю справді будуть мільйони додаткових токенів і десятки агентів. А іноді зміна процесу review, автоматизація integration pipeline, кращі evals або просто усунення організаційного bottleneck.
Бо мета не максимізувати кількість використаних токенів. Мета максимізувати кількість корисної роботи яка доходить до production.
🔔 ПІДПИСАТИСЯ
👍7❤2🔥1
DeepSeek знову показує що більша модель не завжди краща
Доброго ранку ☕️
DeepSeek оновила відносно компактну V4-Flash, не змінюючи архітектуру та кількість параметрів. І після нового fine-tuning вона обігнала власну більшу V4-Pro. На Artificial Analysis Intelligence Index: V4-Flash 50, V4-Pro 44, GPT-5.6 Luna 51.
Але цікавіше тут не результат а спосіб яким його отримали.
Компанія не зробила модель більшою. Вона переробила post-training pipeline. Щоб зрозуміти чому це працює, варто розібрати механізм по кроках.
Крок перший. Спеціалізація замість узагальнення
Замість того щоб одразу вчити одну універсальну модель на суміші всіх типів задач, DeepSeek спочатку створила окремих спеціалістів. Для кожного домену, математики, coding, agentic tasks, instruction following, тренувалася окрема модель. Кожна проходила спочатку SFT на якісних даних свого домену щоб закласти базову компетенцію. Потім кожного спеціаліста додатково донавчали через reinforcement learning з GRPO, Group Relative Policy Optimization, з reward-моделями підібраними саме під критерії успіху цього конкретного домену.
Ідея тут проста і водночас нетривіальна. Оптимізаційний сигнал для математики і для agentic tool use дуже різний за формою. Коли ви тренуєте одну модель одразу на всьому, градієнти з різних доменів можуть конфліктувати і взаємно розмивати одне одного. Розділивши тренування по спеціалістах ви даєте кожному домену чистий незашумлений сигнал.
Крок другий. On-policy distillation як спосіб зібрати спеціалістів назад в одну модель
Після того як з'явилося понад десять сильних спеціалізованих моделей постала інша задача: як перенести їхні знання назад в одну універсальну модель не втративши якість кожного окремого домену.
Тут DeepSeek використала on-policy distillation. Класична дистиляція навчає студента копіювати виходи вчителя на фіксованому датасеті прикладів. Проблема цього підходу в тому що студент вчиться імітувати відповіді на чужих траєкторіях, тих що згенерував сам вчитель, а не на власних. Коли студент потім генерує щось трохи інше, він потрапляє в стани яких ніколи не бачив під час навчання і починає деградувати.
On-policy distillation вирішує це інакше. Студент сам генерує токени під час навчання, а вчитель у реальному часі оцінює якість саме цих згенерованих студентом токенів і дає сигнал корекції. Тобто модель вчиться виправляти власні помилки а не просто копіювати чужі правильні відповіді. Це набагато ближче до того як реально working знання переносяться, через власний досвід а не через спостереження.
Об'єднавши понад десять доменних спеціалістів через цей механізм в одну модель DeepSeek отримала приблизно 10 пунктів приросту Intelligence Index порівняно з квітневою preview-версією, без жодної зміни в самій архітектурі.
Чому це загалом важливо як інженерний прийом
Ключовий висновок тут не про DeepSeek конкретно а про сам патерн: розділяй і навчай, потім об'єднуй через on-policy сигнал а не через offline копіювання. Це дозволяє паралелізувати саму розробку моделі, кожна команда може незалежно покращувати свого спеціаліста, і водночас уникнути втрати якості яка зазвичай супроводжує зведення кількох джерел знань в одну систему.
Це той самий загальний принцип розкладання складної задачі на спеціалізовані компоненти з подальшою акуратною інтеграцією, який ми вже бачили в інших архітектурних рішеннях цього року. Тільки тут він застосований не до інференсу а до самого процесу навчання моделі.
Ще нещодавно головним питанням було скільки параметрів має модель. Потім наскільки вона розумна. Зараз дедалі важливішим стає третє питання: скільки цього інтелекту я отримую за долар. І DeepSeek показує що відповідь на нього часто лежить не в масштабуванні а в тому як саме влаштований pipeline навчання.
🔔 ПІДПИСАТИСЯ
Доброго ранку ☕️
DeepSeek оновила відносно компактну V4-Flash, не змінюючи архітектуру та кількість параметрів. І після нового fine-tuning вона обігнала власну більшу V4-Pro. На Artificial Analysis Intelligence Index: V4-Flash 50, V4-Pro 44, GPT-5.6 Luna 51.
Але цікавіше тут не результат а спосіб яким його отримали.
Компанія не зробила модель більшою. Вона переробила post-training pipeline. Щоб зрозуміти чому це працює, варто розібрати механізм по кроках.
Крок перший. Спеціалізація замість узагальнення
Замість того щоб одразу вчити одну універсальну модель на суміші всіх типів задач, DeepSeek спочатку створила окремих спеціалістів. Для кожного домену, математики, coding, agentic tasks, instruction following, тренувалася окрема модель. Кожна проходила спочатку SFT на якісних даних свого домену щоб закласти базову компетенцію. Потім кожного спеціаліста додатково донавчали через reinforcement learning з GRPO, Group Relative Policy Optimization, з reward-моделями підібраними саме під критерії успіху цього конкретного домену.
Ідея тут проста і водночас нетривіальна. Оптимізаційний сигнал для математики і для agentic tool use дуже різний за формою. Коли ви тренуєте одну модель одразу на всьому, градієнти з різних доменів можуть конфліктувати і взаємно розмивати одне одного. Розділивши тренування по спеціалістах ви даєте кожному домену чистий незашумлений сигнал.
Крок другий. On-policy distillation як спосіб зібрати спеціалістів назад в одну модель
Після того як з'явилося понад десять сильних спеціалізованих моделей постала інша задача: як перенести їхні знання назад в одну універсальну модель не втративши якість кожного окремого домену.
Тут DeepSeek використала on-policy distillation. Класична дистиляція навчає студента копіювати виходи вчителя на фіксованому датасеті прикладів. Проблема цього підходу в тому що студент вчиться імітувати відповіді на чужих траєкторіях, тих що згенерував сам вчитель, а не на власних. Коли студент потім генерує щось трохи інше, він потрапляє в стани яких ніколи не бачив під час навчання і починає деградувати.
On-policy distillation вирішує це інакше. Студент сам генерує токени під час навчання, а вчитель у реальному часі оцінює якість саме цих згенерованих студентом токенів і дає сигнал корекції. Тобто модель вчиться виправляти власні помилки а не просто копіювати чужі правильні відповіді. Це набагато ближче до того як реально working знання переносяться, через власний досвід а не через спостереження.
Об'єднавши понад десять доменних спеціалістів через цей механізм в одну модель DeepSeek отримала приблизно 10 пунктів приросту Intelligence Index порівняно з квітневою preview-версією, без жодної зміни в самій архітектурі.
Чому це загалом важливо як інженерний прийом
Ключовий висновок тут не про DeepSeek конкретно а про сам патерн: розділяй і навчай, потім об'єднуй через on-policy сигнал а не через offline копіювання. Це дозволяє паралелізувати саму розробку моделі, кожна команда може незалежно покращувати свого спеціаліста, і водночас уникнути втрати якості яка зазвичай супроводжує зведення кількох джерел знань в одну систему.
Це той самий загальний принцип розкладання складної задачі на спеціалізовані компоненти з подальшою акуратною інтеграцією, який ми вже бачили в інших архітектурних рішеннях цього року. Тільки тут він застосований не до інференсу а до самого процесу навчання моделі.
Ще нещодавно головним питанням було скільки параметрів має модель. Потім наскільки вона розумна. Зараз дедалі важливішим стає третє питання: скільки цього інтелекту я отримую за долар. І DeepSeek показує що відповідь на нього часто лежить не в масштабуванні а в тому як саме влаштований pipeline навчання.
🔔 ПІДПИСАТИСЯ
👍6🔥4✍1
10 речей про LLM, які варто знати — 10/10 🧠
Ритм видає AI
Гарного дня! 👋
Останній пост із серії. Минулого разу говорили про розмітку промптів. Сьогодні про те як розпізнати AI-текст навіть коли він написаний бездоганно.
AI-текст часто впізнається не за помилками. Навпаки, він може бути занадто правильним. Речення граматично чисті. Переходи логічні. Абзаци акуратні. Висновок на місці. І саме тому щось відчувається не так.
Проблема це ритм. Порівняйте.
AI-ритм: "У сучасному світі штучний інтелект відкриває нові можливості для бізнесу, освіти та творчості."
І трохи живіше: "AI вже не просто допомагає писати швидше. Іноді він пише настільки гладко, що текст перестає звучати як людський."
Різниця не лише у словах. У другому випадку змінюється темп.
Люди пишуть нерівно
Дослідження яке порівнювало людські тексти з текстами кількох сімейств LLM знайшло цікаву відмінність: у людей розподіл довжини речень був більш розкиданим.
AI: довге, довге, довге, довге.
Людина: довге, коротке, середнє, дуже коротке, знову довге.
Справа не в тому щоб механічно чергувати 8 і 20 слів. Темп змінюється разом із думкою. Десь треба пояснити. Десь зупинитися. А десь достатньо трьох слів.
Але довжина речень лише частина проблеми
Інші стилометричні дослідження знаходять у текстах LLM більшу граматичну стандартизацію. Модель може використовувати різні слова але постійно повертатися до схожих конструкцій: "це не лише змінює X але й відкриває Y", "це не просто допомагає X а й дозволяє Y". Начебто різні речення. А ритмічний шаблон той самий.
Саме тому текст може бути грамотним, логічним і навіть красивим але все одно звучати так ніби його зібрали.
AI особливо любить трійки
Це одна з моїх улюблених деталей. У свіжому дослідженні риторичних конструкцій автори порівнювали експертні людські тексти з LLM. Один із найсильніших сигналів це tricolon, конструкції з трьох паралельних елементів: "faster, cheaper, more scalable" або "для бізнесу, освіти та творчості". LLM використовували такі конструкції значно частіше за людей.
І якщо почати це помічати розбачити вже складно. AI любить три переваги, три проблеми, три наслідки, три приклади. Навіть цей список зараз небезпечно близький до AI 🙂
Ще одна ознака це занадто рівномірна красивість
У тому ж дослідженні риторичні прийоми у LLM були більш рівномірно розподілені по тексту. Людина може написати три сухі абзаци а потім раптом одне живе речення, потім довге пояснення, потім знову коротка фраза. У людини риторика з'являється там де її вимагає думка. AI часто намагається підтримувати однакову якість і гладкість увесь час.
Grammarly описує схожі патерни: рівний тон, повторювана фразеологія, структуровані переходи, передбачуване форматування, однакова довжина речень.
Тобто проблема AI-тексту часто не в тому що він погано написаний. Він написаний занадто рівно.
А що з perplexity та burstiness
Навколо AI-детекторів популярна ідея що людський текст має більше burstiness, непередбачуваності та варіативності. У цьому є сенс. Але я б не перетворював це на жорстке правило "низька burstiness означає AI".
Велике дослідження 2026 року перевірило сотні лінгвістичних характеристик на десятках LLM і різних типах тексту. Висновок важливий: багато ознак справді повторюються але вони сильно залежать від конкретної моделі, промпта та домену. Тому рівний ритм це сигнал а не детектор.
Ethan Mollick називає це ще простіше — sameness
Дослідник Wharton Ethan Mollick писав що його починає дратувати саме sameness of AI writing, однаковість AI-текстів. І це мабуть найточніше слово.
LLM навчена створювати хороший, зрозумілий, структурований текст. Тому на типовий запит "напиши професійний пост про AI" вона дуже легко сходиться до статистичного центру хорошого професійного тексту: вступ, теза, аргументи, плавний перехід, список, висновок. Немає нічого неправильного. Але немає й тертя.
Продовження далi 👇🏻
🔔 ПІДПИСАТИСЯ
Ритм видає AI
Гарного дня! 👋
Останній пост із серії. Минулого разу говорили про розмітку промптів. Сьогодні про те як розпізнати AI-текст навіть коли він написаний бездоганно.
AI-текст часто впізнається не за помилками. Навпаки, він може бути занадто правильним. Речення граматично чисті. Переходи логічні. Абзаци акуратні. Висновок на місці. І саме тому щось відчувається не так.
Проблема це ритм. Порівняйте.
AI-ритм: "У сучасному світі штучний інтелект відкриває нові можливості для бізнесу, освіти та творчості."
І трохи живіше: "AI вже не просто допомагає писати швидше. Іноді він пише настільки гладко, що текст перестає звучати як людський."
Різниця не лише у словах. У другому випадку змінюється темп.
Люди пишуть нерівно
Дослідження яке порівнювало людські тексти з текстами кількох сімейств LLM знайшло цікаву відмінність: у людей розподіл довжини речень був більш розкиданим.
AI: довге, довге, довге, довге.
Людина: довге, коротке, середнє, дуже коротке, знову довге.
Справа не в тому щоб механічно чергувати 8 і 20 слів. Темп змінюється разом із думкою. Десь треба пояснити. Десь зупинитися. А десь достатньо трьох слів.
Але довжина речень лише частина проблеми
Інші стилометричні дослідження знаходять у текстах LLM більшу граматичну стандартизацію. Модель може використовувати різні слова але постійно повертатися до схожих конструкцій: "це не лише змінює X але й відкриває Y", "це не просто допомагає X а й дозволяє Y". Начебто різні речення. А ритмічний шаблон той самий.
Саме тому текст може бути грамотним, логічним і навіть красивим але все одно звучати так ніби його зібрали.
AI особливо любить трійки
Це одна з моїх улюблених деталей. У свіжому дослідженні риторичних конструкцій автори порівнювали експертні людські тексти з LLM. Один із найсильніших сигналів це tricolon, конструкції з трьох паралельних елементів: "faster, cheaper, more scalable" або "для бізнесу, освіти та творчості". LLM використовували такі конструкції значно частіше за людей.
І якщо почати це помічати розбачити вже складно. AI любить три переваги, три проблеми, три наслідки, три приклади. Навіть цей список зараз небезпечно близький до AI 🙂
Ще одна ознака це занадто рівномірна красивість
У тому ж дослідженні риторичні прийоми у LLM були більш рівномірно розподілені по тексту. Людина може написати три сухі абзаци а потім раптом одне живе речення, потім довге пояснення, потім знову коротка фраза. У людини риторика з'являється там де її вимагає думка. AI часто намагається підтримувати однакову якість і гладкість увесь час.
Grammarly описує схожі патерни: рівний тон, повторювана фразеологія, структуровані переходи, передбачуване форматування, однакова довжина речень.
Тобто проблема AI-тексту часто не в тому що він погано написаний. Він написаний занадто рівно.
А що з perplexity та burstiness
Навколо AI-детекторів популярна ідея що людський текст має більше burstiness, непередбачуваності та варіативності. У цьому є сенс. Але я б не перетворював це на жорстке правило "низька burstiness означає AI".
Велике дослідження 2026 року перевірило сотні лінгвістичних характеристик на десятках LLM і різних типах тексту. Висновок важливий: багато ознак справді повторюються але вони сильно залежать від конкретної моделі, промпта та домену. Тому рівний ритм це сигнал а не детектор.
Ethan Mollick називає це ще простіше — sameness
Дослідник Wharton Ethan Mollick писав що його починає дратувати саме sameness of AI writing, однаковість AI-текстів. І це мабуть найточніше слово.
LLM навчена створювати хороший, зрозумілий, структурований текст. Тому на типовий запит "напиши професійний пост про AI" вона дуже легко сходиться до статистичного центру хорошого професійного тексту: вступ, теза, аргументи, плавний перехід, список, висновок. Немає нічого неправильного. Але немає й тертя.
Продовження далi 👇🏻
🔔 ПІДПИСАТИСЯ
1❤6👍3🔥2
Що з цим робити
Не просити "зроби більш людяно". Це майже нічого не означає.
Краще працює інший підхід. Дайте моделі 3-5 ваших реальних текстів і попросіть окремо проаналізувати довжину речень, розмір абзаців, синтаксичні конструкції, переходи, короткі фрагменти, ритм і pacing. А потім уже писати новий текст у цьому патерні.
Це близько до підходу який описує Tiago Forte: спочатку змусити AI витягнути style guide з вашого власного письма а вже потім використовувати його. Anthropic у своїх рекомендаціях теж радить давати моделі кілька різноманітних прикладів коли важливі тон, структура та формат. А Mollick взагалі пропонує залишати AI роль reader/editor а не повністю віддавати йому авторство. Це те як використовю AI я для написання текстiв ✍️
Мені ця логіка подобається найбільше. Бо хороший текст має не лише сенс. Він має темп. Іноді швидкий. Іноді повільний.
На цьому серія 10 речей про LLM завершена. Дякую що читали весь цей час 🙏
🔔 ПІДПИСАТИСЯ
Не просити "зроби більш людяно". Це майже нічого не означає.
Краще працює інший підхід. Дайте моделі 3-5 ваших реальних текстів і попросіть окремо проаналізувати довжину речень, розмір абзаців, синтаксичні конструкції, переходи, короткі фрагменти, ритм і pacing. А потім уже писати новий текст у цьому патерні.
Це близько до підходу який описує Tiago Forte: спочатку змусити AI витягнути style guide з вашого власного письма а вже потім використовувати його. Anthropic у своїх рекомендаціях теж радить давати моделі кілька різноманітних прикладів коли важливі тон, структура та формат. А Mollick взагалі пропонує залишати AI роль reader/editor а не повністю віддавати йому авторство. Це те як використовю AI я для написання текстiв ✍️
Мені ця логіка подобається найбільше. Бо хороший текст має не лише сенс. Він має темп. Іноді швидкий. Іноді повільний.
На цьому серія 10 речей про LLM завершена. Дякую що читали весь цей час 🙏
🔔 ПІДПИСАТИСЯ
2👍14🔥8❤1🥰1💯1