Відкриті моделі ШІ: Між обіцянками та реальністю мого досвіду
З вами Lila Hart, і сьогодні я хочу поділитися своїми глибокими роздумами щодо парадоксу, який я спостерігаю в екосистемі відкритих моделей штучного інтелекту. Це вже не перший раз, коли я відчуваю цей цикл ейфорії, що переходить у помітне розчарування. Кожного разу, коли на горизонті з’являється нова, нібито “відкрита” модель, як-от Kimi GLM чи DeepSeek, я бачу бенчмарки, які обіцяють: “Це вже не гірше за провідні пропрієтарні моделі для кодування!”. І в ці моменти я щиро вірю, що ми нарешті досягли тієї точки, коли відкриті рішення можуть конкурувати на рівних з гігантами на кшталт Anthropic чи OpenAI, звільняючи нас від їхньої монополії.
Але потім настає момент істини – я беру ці моделі, запускаю власні, суворо контрольовані тести, і… настає розчарування. Це не просто незначні відмінності; це відчуття глибокого, хоч і дещо гіркого, усвідомлення, що реальність не відповідає очікуванням. І хоча це розчарування має свої нюанси, адже ці відкриті моделі справді вражають своїм потенціалом. Вони часто демонструють продуктивність, яка може конкурувати з “фронтирними” моделями, і це за значно меншу ціну. Візьмемо, наприклад, Terminal Bench 4.0. Коли я порівнюю Kimi 3.1 Pro Max з GPT-6 Astra та Claude Opus 5.5, іноді Kimi навіть випереджає.
Це змушує мене ставити ключове запитання: “Що відбувається?” Як ці компанії можуть випускати відкриті моделі, які за всіма заявленими показниками нібито перевершують найдосконаліші комерційні рішення, але при спробі використати їх для реальних завдань, вони, м’яко кажучи, не виправдовують себе? Саме це я прагну розкрити сьогодні: чому я досі не можу повністю покладатися на відкриті моделі для всіх моїх завдань з кодування. Ми заглибимося в мої тести, щоб ви могли побачити це на власні очі, і, звичайно, знайдемо практичні шляхи вирішення, адже я щиро вболіваю за майбутнє відкритих моделей. Я переконана, що за ними стоїть значний потенціал, і хочу інтегрувати їх максимально, навіть якщо це означає не повну відмову від існуючих робочих процесів.
Новий помічник чи чергова ілюзія?
Я не проти платити за зручність та ефективність. Мої інструменти, такі як CodeX та підписки на Cloud Code, є моїми щоденними вірними помічниками. Однак, варто пам’ятати, що ці підписки не є гарантією назавжди. Ми всі спостерігаємо, як ліміти на кількість запитів стають все жорсткішими, і я не хочу залежати від зовнішніх факторів. Якщо ціни на API для Opus 5.5 чи GPT-6 Astra стануть непідйомними, це буде нереалістично для моїх потреб, враховуючи обсяги використання.
Існують також інші вагомі причини для підтримки та інвестицій у відкриті моделі. Але зараз давайте зосередимося на їхній продуктивності. Це, можна сказати, “великий диптих” моїх спостережень: фронтирні та відкриті моделі. За короткими, навіть складними завданнями, що вимагають глибинного мислення, вони демонструють майже ідентичну продуктивність. Я проводила численні тести, де результати аналізував окремий агент, а потім я сама. Різниця практично непомітна. І, звісно, використання відкритих моделей у таких випадках є значно економічнішим.
Саме для подібних завдань, а також для більшості сценаріїв бізнес-автоматизації та роботи агентів, відкриті моделі стають беззаперечними лідерами. Я бачила багато досліджень та чула думки експертів, які стверджують, що відкриті моделі здатні виконати до 90% завдань у корпоративних агентських робочих процесах. Зазвичай, ці прогнози дають на 2-5 років, але ми рухаємося до цього надзвичайно швидко. Я спостерігаю це, співпрацюючи з компаніями: вони стають надзвичайно обережними щодо витрат на токени, особливо за останнє півріччя. І багато хто прагне запускати моделі локально, особливо при роботі з конфіденційними даними.
І ось у чому суть: 9 з 10 кроків в агентському робочому процесі – це рутина. Відкриті моделі справляються з нею на рівні, і це коштує в рази менше, ніж навіть найдешевша закрита модель, як-от Haiku 5.5. Тобто, там, де нам потрібно, щоб агенти були інтегровані у великі бізнес-автоматизації, де це лише крок у робочому процесі, і де нам не потрібен GPT-6 Astra чи Opus 5.5, ми можемо ефективно використовувати “слабшу” модель. Вона впорається із завданням і буде значно дешевшою. І саме тут відкриті моделі мають явну перевагу.
Коли я кажу “слабша”, це не зовсім точно. Адже, як я вже зазначала, для коротких завдань відкриті моделі демонструють таку ж продуктивність, як і фронтирні. Але саме там, де це дійсно важливо для агентського кодування, для тривалих завдань – ось тут вони починають демонструвати свої обмеження. Якщо ми використовуємо ці відкриті моделі для управління чимось більшим, як моя AI Software Factory, це саме те місце, де я бачу їхні провали знову і знову. І я покажу вам, як саме це відбувається.
Заплутаний лабіринт коду: Де відкриті моделі губляться?
На цьому етапі я спростила мою AI Software Factory, щоб надати вам загальне уявлення про мій робочий процес кодування. Я не просто відкриваю Claude Code, Kimi Code чи подібний інструмент і надсилаю запит. У мене є чіткий набір навичок і правил, які скеровують мене та мого агента через весь процес: планування, реалізація згідно з планом, а потім перегляд та тестування разом з іншим агентом, щоб переконатися, що все готово до “мерджу”. Я застосовую цей підхід до кожного виправлення помилки та кожної нової функції, яку впроваджую.
Проблема полягає в тому, що в будь-якій складній кодовій базі та великому процесі існує багато можливостей для “дрифту” – природного відхилення від початкових параметрів. І саме тут відкриті моделі зазнають невдачі. Навіть Kimi K 3.1 Pro, яку я постійно згадую як найновішу та найперспективнішу відкриту модель, не є винятком. Я знайшла для цього влучне слово: це все про “увагу”. Схоже, відкриті моделі не можуть ефективно приділяти увагу всім правилам і контексту, яких вони повинні дотримуватися під час тривалих процесів.
Коли я працюю з Opus 5.5, я надаю йому доступ до всіх моїх правил та складної кодової бази. Він здатен розуміти, куди інтегрувати нові елементи, що потребує перегляду. І він завжди мене розуміє, розуміє кодову базу, навіть коли працює тривалий час. Але з Kimi це не так. Вона добре справляється з окремими, дуже гранулярними змінами. Але якщо я намагаюся масштабувати завдання, вона починає забувати правила, які я їй встановила, та правила, що містяться в кодовій базі.
Навіть найпростіші правила з моїх глобальних настанов, як-от “не чіпай PRD, це тільки для читання”, вона намагалася порушити. І вона робила це неодноразово протягом моїх тестів за останні кілька тижнів. Вона постійно застрягала, тому що у мене є суворі правила щодо того, що дозволено “зливати” в мою кодову базу. У мене досить висока планка, яку Kimi, здається, ніколи не може досягти без багаторазових ітерацій. І це робить Kimi навіть дорожчою за Claude, просто через кількість токенів, які я витрачаю на виправлення всіх дрібних проблем, що виникають.
Ми можемо побачити це, коли аналізуємо ширший список бенчмарків, а не лише ті, які Kimi хоче, щоб ви бачили, як Terminal Bench 4.0. Так, звісно, для деяких завдань Kimi 3.1 та багато інших відкритих моделей демонструють кращу або порівнянну продуктивність з фронтирними. У цьому є певна правда. Але якщо ми подивимося на інші бенчмарки, які більше зосереджені на довгострокових завданнях, як-от Terminal Bench Science, Frontier Code 2.0, то там спостерігається дуже велика різниця. Це відповідає тому, що я бачу: Kimi K 3.1 Pro та інші відкриті моделі ніби “падають на обличчя” порівняно з фронтирними моделями, як Gemini 4 Carbon та Claude Opus 5.5.
І ось як я насправді хочу інтегрувати моделі в мої агентські кодувальні робочі процеси. Це більше мій досвід, аніж сухий розрахунок. Як би мені не хотілося, щоб Terminal Bench 4.0 був точним для моєї роботи, реальність виявляється іншою.
Цікаво знати: Навіть фронтирні моделі все ще стикаються з труднощами при виконанні довгострокових завдань. Але вони долають ці виклики значно менш проблематично, ніж відкриті моделі. В одному з досліджень GPT 5.6 Soul показав 41.6% успіху, тоді як Kimi K3 – лише 22.1%. Це суттєва різниця!
Коли вартість не дорівнює якості
Я не хочу, щоб ви подумали, ніби фронтирні моделі повністю вирішили проблему довгострокових завдань. Боротьба ще триває. Я бачила це в численних дослідженнях, включно з власними. Але вони борються значно менше, ніж відкриті моделі. Це означає, що нам все ще потрібен “інжиніринг каркаса” – чітке керівництво та процес навіть для найкращих моделей, щоб досягти будь-якої значущої точності в цих великих AI-кодувальних робочих процесах. Але навіть якщо ми маємо багато такого керівництва та процесу, це, здається, не так сильно допомагає відкритим моделям.
А тепер, друзі, я хочу зробити паузу і поговорити про спонсора цього відео. Це TripleTen. Вони створюють програми для досвідчених інженерів, які прагнуть стати справжніми експертами у створенні систем ШІ. Штучний інтелект став головною причиною скорочень робочих місць у США цього року. Але потреба в інженерії не зникла, вона просто трансформувалася. Більшість зростання кількості вакансій припадає на старші позиції. Ви можете опанувати новий інструмент ШІ за вихідні, але отримати реальний досвід управління системами ШІ в продакшені – це дійсно важко зробити самостійно. І саме для цього існує TripleTen.
У них є дві програми: AI Systems Engineering та AI Machine Learning. Вони призначені для інженерів з кількорічним досвідом роботи в продакшені. Це не для новачків. Ви створите п’ять проектів, які об’єднаються в реальну систему – наприклад, пайплайн для вилучення даних з оцінкою та агент підтримки, підключений до Jira за допомогою MCP. І ви будете захищати свої проекти перед справжнім інженером, що мені дуже подобається. Експертні проекти TripleTen також доступні на GitHub, тож ви можете побачити, які системи ви створюєте, перш ніж записатися. А інструкторів можна знайти в публічних профілях, як-от Мухаммад Шеріф, який працював в AMD, Microsoft та Amazon. Якщо у вас є кілька років інженерного досвіду і ви хочете заглибитися в системи ШІ, я залишу посилання на обидві програми в описі.
Отже, все, про що я вам розповіла, базується на моїх дослідженнях та досвіді порівняння закритих і відкритих моделей протягом цього року. Але я також хочу зробити це цікавішим для вас і дійсно кількісно оцінити те, що я бачу. Тому я провела дуже контрольований тест, використовуючи мою AI Software Factory, щоб створити абсолютно однакову програму за допомогою Claude, GPT-6 та Kimi K 3.1 Pro.
Кожна модель отримала власну AI Software Factory для створення однієї й тієї ж відеогри. Я обрала відеогру, бо це весело для мене, приємно візуалізувати для вас, і мені було потрібно щось достатньо складне, щоб реально випробувати межі цих моделей. Гра, яку я створила, називається Northstar. Моя справжня фабрика зараз створює повну версію цієї гри, але це версія, яку я створила за допомогою Claude, використовуючи Opus 5.5 для планування та перегляду, а Sonnet 5.5 – для роботи “робочої конячки”.
Це дуже спрощена версія гри, бо я хотіла запустити лише близько 12 “квитків” (ітерацій) фабрики. І загалом вона досить хороша. Фізика чудова. Бій, звісно, трохи кумедний через анімації. Мій персонаж тут виглядає не дуже, але повний ігровий цикл працює. Це було створено Claude в моїй фабриці.
Ось версія гри, створена GPT, з GPT-6 Astra для планування та перегляду, а її “робочою конячкою” був 6.1 Soul. HUD тут виглядає досить потворно, але якщо зайти в рейд, то виглядає добре. Звісно, у всіх цих доказів концепції будуть дрібні проблеми, бо я не витрачала багато часу на це. Але ця версія мала 11 квитків загалом, щоб досягти поточного стану. Залишилися деякі проблеми з хітбоксами, якісь речі для налагодження. Вона не виглядає так добре, як Claude. Вона також вирішила використати більш віддалену перспективу.
Кожна з моїх фабрик отримала абсолютно однакову початкову точку для графіки, тому все виглядає схоже. Але знову ж таки, як і Claude, вона загалом добре впоралася. Моя мета тут абсолютно не полягала в створенні відполірованої версії гри, а в тому, щоб прогнати багато квитків на більш складній кодовій базі, щоб отримати відчуття того, наскільки добре модель здатна будувати функції та тестувати свою роботу.
І нарешті, ось гра, створена Kimi. Вона має значно віддаленішу перспективу, як і та, що була створена Claude. І якщо я почну рейд, UI насправді виглядає досить чисто порівняно з Claude та GBT. Мені подобається. Але проблема в тому, – і ми заглибимося в це трохи пізніше – вона не побудувала стільки функцій у грі, скільки інші, бо вона витратила стільки часу на виправлення всіх цих дрібних речей та ітерації над кожним окремим квитком. Наприклад, я не маю часу показувати це тут, але між рейдами є магазин, де можна покращити свого персонажа у версіях Claude та OpenAI. Але Kimi так і не дійшла до цього.
Я знаю, це трохи дивний приклад, і це лише одна програма. Але я хотіла створити щось конкретне, щоб надати вам реальні цифри того, що я бачу, створюючи десятки додатків з фронтирними та відкритими моделями. Даних про чисту кількість квитків небагато, але я витратила десятки мільйонів токенів на всі ці тести, дозволяючи їй ітерувати та долати труднощі, щоб отримати реальні дані. І це відповідає всьому, що я бачила протягом цього року.
Claude виконав 12 з 12 квитків для гри приблизно за 14 годин. Кожен повний цикл фабрики займав близько години, що досить добре, враховуючи, наскільки великим був кожен квиток. І вона пройшла повний процес: планування, побудова, перегляд, тестування та злиття.
OpenAI знадобилося вдвічі більше часу і вона навіть не зовсім закінчила. Вона виконала 11 з 12 квитків. Навіть між фронтирними моделями є досить велика різниця. Є причина, чому я зараз використовую Claude Opus 5.5 для багатьох моїх агентських кодувальних робочих процесів. Практично для всіх. Але загалом, крива виглядає досить солідно між ними, чи не так? Вона не застрягала на чомусь надто довго, і кінцевий результат був досить хорошим.
Але коли ми переходимо до Kimi, погляньте на це. Є кілька моментів, де вона “зависала” годинами, і пройшла лише п’ять із 12 квитків за 44 години. Саме тому в ній не було таких речей, як магазин після рейду. Вона просто застрягла в ітераціях і всіх цих дрібницях, що виникали. Це було так прикро, бо вона постійно намагалася робити те, чого їй забороняли правила. Саме тому перегляди її ловили, і їй доводилося ітерувати. Вона просто постійно не дотримувалася всього, що було встановлено фабрикою.
Я мушу сказати, можливо, я могла б змінити фабрику, зробивши її трохи більш поблажливою, дозволивши деякі з цих незначних проблем, щоб Kimi хоч виглядала ближче до Claude та GPT. Але я хочу зберегти весь процес перегляду. Я витратила так багато часу на його вдосконалення в моїй AI Software Factory, що не хочу підлаштовуватися під слабші моделі лише для того, щоб більше завдань проходило. Коли я перемикаюся між фронтирними моделями, вони всі, здається, розуміють мою фабрику, мою кодову базу та мої правила. Але з відкритими моделями – це справді схоже на справжній недолік: для тривалих завдань вони просто не здатні жонглювати та приділяти увагу всьому, що їм потрібно.
Вартість помилок: Коли дешево виявляється дорожчим
У мене є ще цікавіші цифри для вас. Принаймні, для мене це захоплююче. Загальна вартість створення всього тут, з усіма 12 квитками, з Claude склала 255 доларів. Звісно, я використовувала свою підписку для всього тут. Це просто те, скільки б це коштувало за API-цінами, що є єдиним, що я можу по-справжньому кількісно оцінити. І це загалом досить добре.
З GPT це було 635 доларів. Вона навіть не повністю закінчила. Вона працювала вдвічі довше, але була насправді дорожчою, ніж удвічі. Досить цікаво. А потім з Kimi це було 180 доларів, що насправді не дешевше, ніж Claude, тому що вона насправді не закінчила все. І ось у чому річ: просто тому, що модель дешевша, не означає, що вона насправді дешевша за завдання, бо їй доводиться ітерувати більше. Якщо вона частіше зазнає невдачі, це може навіть стати дорожчим. Ось що я часто бачу з цими відкритими моделями в моїх кодувальних робочих процесах.
І ми можемо побачити це в наступному рядку. Claude коштував 21 долар за квиток, GPT – 63, а Kimi – майже 36 доларів за кожен квиток.
Також, мені доводилося втручатися набагато менше, коли я мала Claude, що керує фабрикою. У мене є частина системи, де є менеджер, який контролює весь робочий процес і сповіщає мене, коли виникають невизначеності, що потребують мого рішення, або принаймні менеджер приймає рішення за мене. З Claude більшу частину часу все проходить дуже гладко. OpenAI зазвичай раз на квиток доводив щось до моєї уваги. Але Kimi потребувала допомоги в кількох різних випадках для кожного квитка, який вона створювала. І це також було досить прикро для мене. Claude просто може бути набагато автономнішою загалом. Вона має набагато більше впевненості у своїх реалізаціях, що, здається, виправдано, чи не так? Ми ж не хочемо необґрунтованої впевненості, коли вона просто робить купу помилок. Але Claude – це надійно, і вона це знає.
І останнє цікаве – я попросила окремого агента провести сліпий перегляд коду всієї бази. Claude отримала 8 з 10, GPT – 7 з 10, а Kimi – 6 з 10. І 6 з 10 – це нормально. Я маю на увазі, Kimi врешті-решт дійшла до чогось пристойного. Просто отримати це було досить болісно.
Де ж вихід? Змішаний підхід як шлях до майбутнього
Отже, на даний момент ми детально розглянули проблему. Ми знаємо, чому ми не можемо просто передати наші довготривалі агентські кодувальні робочі процеси дешевшій відкритій моделі. Навіть якщо дозволити їй багато ітерувати, це все одно стає дорожчим, ніж просто мати Claude, яка керує нашою фабрикою програмного забезпечення, нашим кодувальним робочим процесом, чи чим завгодно. І це буде набагато надійніше.
З огляду на це, давайте поговоримо про рішення, або принаймні про те, що я роблю зараз. Кінцева мета, принаймні для мене, – досягти точки, коли я зможу використовувати відкриті моделі для всього. І я твердо вірю, що в майбутньому ми туди дістанемося. Ми не будемо змушені використовувати фронтирні моделі, якщо не захочемо. Просто, як бачимо, ми ще не там. Але це також не означає, що я повинна відмовитися від ідеї використання відкритих моделей у моїх агентських кодувальних робочих процесах.
Те, що я багато експериментувала цього року, – це змішування моделей та провайдерів. Використовувати правильну модель для правильного завдання, залежно від її вартості та якості. Наприклад, використовувати Opus для планування та перегляду в моєму великому агентському робочому процесі, а потім використовувати Kimi як “робочу конячку”. І такі комбінації добре працювали для мене.
Тепер мені доведеться випустити більше контенту, де я справді покажу вам, як налаштувати цей “каркас”. І є відео, яке я дам посилання тут, на своєму каналі, де я детальніше розбираю ці цифри. Але на високому рівні зараз я просто хочу показати вам, як виглядає змішування моделей, і як ми дійсно не повинні жертвувати надійністю коду, щоб отримати значну економію часу та коштів.
Отже, що я зробила в цьому тесті: я мала контрольну групу, де багато агентських кодувальних робочих процесів я пропускала через Opus для всього. Він виконував все планування, реалізацію та перегляд. А в іншому тесті Opus виконував перегляд та планування, але Kimi була “робочою конячкою”, яка виконувала реалізацію, де витрачається багато моїх токенів. І я виявила, що результати були майже еквівалентними між цими двома групами, що неймовірно.
Якщо подивитися на вартість, то для простих завдань вона була дійсно низькою між цими двома. Але для складніших завдань вартість використання Opus для всього була більш ніж удвічі вищою, хоча результати були практично еквівалентними як для простих, так і для складних завдань, які вона мала реалізувати. Це божевілля.
Все зводиться до того, що якщо ми використовуємо потужнішу модель для планування, це те місце, де нам потрібно завантажити весь контекст і дотримуватися всіх правил. Отже, якщо ми обмежуємо це документом плану, наша слабша, але все ще досить потужна модель може дуже добре його виконати. Це рішення на даний момент. Ми все ще можемо використовувати відкриті моделі, просто не для всього в наших великих робочих процесах.
Тож, це моя головна рекомендація на даний момент. Якщо ви хочете заощадити на токенах, зробити ваші робочі процеси швидшими, експериментуйте з відкритими моделями. Використовуйте їх як “робочу конячку”, яка завжди пише код, але потім ви просто “обгортаєте” це плануванням та переглядом, які використовують фронтирну модель. І як саме ви це налаштуєте – скоро буде більше контенту, де я це розберу.
Також, дайте мені знати в коментарях, яка частина цього вас найбільше цікавить. Чи хочете ви, щоб я показала більше даних? Чи хочете ви, щоб я показала, як насправді налаштувати ці системи? Мені було б цікаво дізнатися, що ви шукаєте.
Отже, я сподіваюся, ви це оцінили. Загалом, проблема з відкритими моделями, перехід до рішення, ще багато чого я хочу зробити з цього скоро. Якщо ви оцінили це і чекаєте більше відео про агентський інжиніринг, відкриті моделі, я була б дуже вдячна за лайк і підписку. І з цим, побачимося в наступному відео.
