Ваш AI-агент двічі оплачує той самий рахунок — WikiSkill від Google покликаний це зупинити

Найдорожчий співробітник у вашій компанії ніколи не пам'ятає вчорашнього дня

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

Google Research щойно опублікував фреймворк, який атакує цю проблему напряму. Те, що він розкриває про економіку корпоративного AI — і про те, які компанії поглинатимуть цей тягар, а які позбудуться його — варто зрозуміти раніше за конкурентів.

Є особливий вид втрат, який не відображається на жодному дашборді. AI-агент у відділі закупівель неправильно читає формат відповіді API постачальника і не фіксує замовлення. Команда помічає, виправляє вручну, рухається далі. Через два тижні той самий агент знову звертається до того самого API. Та сама помилка читання. Той самий збій. Те саме ручне виправлення. Агент не пам'ятає, що сталося раніше — бо за своєю архітектурою він і не може.

Це не гіпотетичний крайній випадок. Це поведінка за замовчуванням практично кожного AI-агента, що працює у виробничому середовищі сьогодні. Дослідники з Google Research і Virginia Tech визначили це як одне з найстійкіших структурних обмежень агентних систем: запустіть того самого агента двічі на схожій задачі — і він часто повторить ту саму помилку, бо нічого з першої спроби не переноситься. Стаття, опублікована 27 серпня 2026 року під назвою WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution, пропонує конкретну архітектурну відповідь.

Що WikiSkill насправді робить — і чого не робить

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

Механізм працює в чотири чіткі кроки. Спочатку inference-агент виконує завдання, спираючись на поточні навички, і генерує трейси виконання — сирий лог того, що він робив і що з цього вийшло. Компонент під назвою «Wiki Maintainer» аналізує ці трейси, виявляє патерни збоїв і вдалі стратегії, а потім записує висновки у wiki. «Skill Proposer» використовує оновлену wiki та дані виконання, щоб запропонувати точкові зміни в операційних процедурах агента. Нарешті, механізм перевірки тестує запропоновану зміну на окремій валідаційній вибірці — і лише якщо вона справді покращує результат, зміна приймається. Якщо ні — навичка відкочується назад, але wiki залишається незмінною.

Цей останній момент важливіший, ніж здається. Навіть невдалі пропозиції не зникають безслідно: wiki фіксує, що саме пробували і чому це не спрацювало — і Skill Proposer будує на цьому знанні в наступних ітераціях. Шар знань ніколи не скидається. До агента, який обробляє реальні завдання, доходять лише перевірені покращення.

Wiki, яка «ніколи не скидається і лише зростає» — це ключова заява, бо більшість сучасних агентних фреймворків досі починають кожну сесію з чистого аркуша.

Важливо чітко розуміти, чим WikiSkill не є. Ваги базової моделі не оновлюються. Агент не навчається у безперервному сенсі — це залишається невирішеною проблемою AI-досліджень. Змінюється якість інструкцій, які агент отримує перед кожним запуском. Уявіть це не як навчання співробітника, а як передачу йому постійно оновлюваного операційного посібника, написаного колегою, який спостерігав за кожною попередньою зміною і документував кожну помилку. Модель залишається тією самою — але інструкції стають точнішими.

Триярусна архітектура

WikiSkill розділяє операційну історію агента на три окремі шари: сирі трейси виконання (незмінні докази), кураторська wiki (накопичені знання) і версійні навички (активні процедури). Це розділення — не косметика. Воно дозволяє зберігати повний аудит-слід усього, що агент робив, водночас дозволяючи лише перевіреним інструкціям впливати на живу поведінку. У регульованих галузях, де комплаєнс вимагає відстежуваності, ця різниця принципова.

Архітектурно фреймворк спирається на концепцію, яку Андрій Карпаті опублікував у квітні 2026 року: ідею «LLM Wiki», що компілює досвід у постійні накопичувальні знання замість того, щоб збирати їх заново для кожного запиту. WikiSkill переносить цю ідею в розробку агентів і додає критичний шар, який перетворює знання на виконувані процедури, — разом із механізмом оцінки того, чи варто взагалі приймати запропоновану зміну.

Цифри продуктивності — і що вони означають для витрат

Дослідники тестували WikiSkill у п'яти категоріях бенчмарків: математичне міркування, вебпошук, робота з таблицями, відповіді на запитання за документами та інтерактивні завдання у віртуальному середовищі. Серед протестованих моделей — варіанти Qwen (4B, 9B і 27B параметрів), Gemma-4-31B і Gemini-3.5-Flash.

Результати виявилися суттєвими. WikiSkill підняв точність Gemini-3.5-Flash з 49,5% до 68,1%, а Qwen-3.6-27B — з 39,4% до 63,3%. У всіх протестованих конфігураціях WikiSkill стабільно перевершував і попередні методи еволюції навичок, і базовий варіант без навичок.

Один результат заслуговує особливої уваги з точки зору бізнес-архітектури: розрив між WikiSkill і базовим варіантом зростає зі збільшенням розміру моделі. Більші моделі отримують більше від накопиченого досвіду. Це означає, що дорогі фронтирні моделі, які вже використовують багато компаній, мають найбільше виграти від постійної пам'яті — не лише в сирій точності, а й у накопичувальному ефекті від відсутності повторних дорогих помилок.

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

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

Що це означає для корпоративних AI-розгортань

Комплаєнс і аудит-слід

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

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

Зменшення «податку» на людський контроль

Один із прихованих витрат у корпоративних AI-розгортаннях — це те, що можна назвати петлею виправлень: регулярні людські зусилля, потрібні для того, щоб помічати й виправляти помилки агента, які той повторюватиме нескінченно. Коли агент неправильно обробляє формат документа, неправильно маршрутизує затвердження або не може розпарсити відповідь API — хтось у вашій команді поглинає цей збій. Якщо агент не пам'ятає інциденту, ця людина поглине його знову наступного тижня.

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

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

Проблема застарілої пам'яті

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

Є й питання деградації навичок. Процедура, вивчена для одного інтерфейсу, може стати шкідливою після оновлення застосунку. Якщо постачальник змінить структуру API, перевірена навичка, побудована навколо старої структури, може активно вводити агента в оману. Це означає, що метрики для відстеження віку навичок, їхнього походження, частоти відкатів і виявлення застарілої пам'яті не менш важливі, ніж заголовкова точність на завданнях. База знань, яка лише зростає, також має справлятися з суперечливими або застарілими уроками — і поточне дослідження не повністю вирішує, як WikiSkill обрізає або узгоджує погані навички після їх валідації.

Це реальні обмеження, а не теоретичні. Але вони також є інженерними проблемами з вирішуваними рішеннями, а не фундаментальними запереченнями проти підходу. Альтернатива — агенти без пам'яті взагалі — має добре задокументовану вартість, яка накопичується з кожною повторною помилкою.

Як думати про це як про бізнес-рішення

Питання «будувати зараз чи чекати»

WikiSkill — це дослідницький фреймворк, опублікований на arXiv, а не готовий до виробництва продукт, який можна розгорнути наступного кварталу. Чесне формулювання: він демонструє напрямок, а не кінцеву точку. Але напрямок, який він демонструє, — це той, до якого корпоративні AI-команди мають активно рухатися, незалежно від того, чи використовуватимуть вони саме цю реалізацію.

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

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

Менші моделі, розумніша операція

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

Це не означає, що треба переходити на менші моделі. Це означає, що критерії оцінки AI-інфраструктури мають включати архітектуру пам'яті поряд із бенчмарк-показниками. Модель на 9B параметрів, яка вчиться на своїх помилках у виробництві, може давати більше бізнес-цінності, ніж модель на 27B, яка цього не робить.

Для команд, які прораховують повну картину витрат на AI-агентів порівняно з людською працею, питання архітектури пам'яті — одна зі змінних, яка найбезпосередніше впливає на точку беззбитковості, поряд із вартістю inference, рівнем помилок і накладними витратами на виправлення. Корисний фреймворк для такого аналізу є в статті Як розрахувати точку окупності AI-агента замість найму нового співробітника.

Скільки насправді коштує втрата інституційної пам'яті

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

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

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

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

І коли рада директорів запитає, як ви управляєте AI-ризиком у масштабі, відповідь «наші системи мають перевірений, аудитований механізм для перетворення збоїв на покращення» звучить інакше, ніж «ми уважно моніторимо». Керівники, які можуть говорити про архітектуру своєї AI-інфраструктури — а не лише про її результати — сприймаються як будівельники, а не як гравці в рулетку.

---

FAQ

Що таке фреймворк WikiSkill від Google? WikiSkill — це фреймворк постійної пам'яті, розроблений дослідниками Google Research і Virginia Tech, опублікований у серпні 2026 року. Він дає AI-агентам структуровану базу знань, що самооновлюється: накопичує записи про минулі збої та успіхи і перетворює їх на перевірені операційні процедури без перенавчання моделі.

Як WikiSkill покращує продуктивність AI-агентів? Підтримуючи постійну wiki трейсів виконання і дистилюючи їх у багаторазові «Agent Skills», WikiSkill не дає агентам повторювати ті самі помилки між сесіями. У бенчмарк-тестуванні він підняв точність Gemini-3.5-Flash з 49,5% до 68,1%, а Qwen-3.6-27B — з 39,4% до 63,3%.

Чи змінює WikiSkill базову AI-модель? Ні. Ваги моделі не оновлюються. WikiSkill покращує поведінку агента, генеруючи кращі інструкції — перевірені операційні процедури, — які агент отримує перед кожним запуском. Навчання відбувається на процедурному рівні, а не всередині самої моделі.

Чи доступний WikiSkill для корпоративного розгортання сьогодні? Станом на серпень 2026 року WikiSkill є дослідницьким фреймворком, а не комерційним продуктом. Проте архітектурні принципи, які він демонструє — розділення трейсів виконання, накопичених знань і активних процедур — вже зараз можуть визначати, як корпоративні команди оцінюють і проектують свою AI-агентну інфраструктуру.

Які ризики несе підхід WikiSkill із постійною пам'яттю? Головні ризики — деградація навичок (перевірена процедура може стати шкідливою після зміни зовнішньої системи) і складність узгодження суперечливих або застарілих уроків у базі знань, яка лише зростає. Дослідники визнають це відкритими інженерними проблемами. Моніторинг віку навичок, їхнього походження та частоти відкатів є обов'язковим для виробничих розгортань.

Як WikiSkill співвідноситься з RAG (Retrieval-Augmented Generation)? WikiSkill відрізняється від стандартного RAG. Замість того щоб витягувати документи за семантичною схожістю в момент запиту, він підтримує структуровану кураторську базу знань, дистильовану з операційного досвіду і перетворену на процедурні інструкції. Розділення між доказами, знаннями і процедурами виконання є більш структурованим — і більш релевантним для поведінки агентів у виробництві — ніж типові реалізації RAG.

---

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