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

Наприклад, тепер можна буде фільтрувати та сортувати події за такими ознаками, як «Виявлено людину», «Виявлено посилку», «Чутно звук биття скла». Мініатюри попереднього перегляду стали анімованими та автоматично фокусуються на об’єктах, щоб легше було з першого погляду зрозуміти, що саме зафіксувала камера. Вікно програвача при цьому залишається видимим під час прокручування списку подій.

Передплатники розширеного тарифу Google Home Premium зможуть бачити описи подій безпосередньо в таймлайні. Ця функція, так само як і збільшені мініатюри попереднього перегляду, з’явиться й для камер Nest попередніх поколінь.

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

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

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

Google також зазначає, що Gemini 3.1 краще розуміє подібні назви списків, що допомагає уникати створення дублікатів. Керування будильниками та календарем теж має стати простішим завдяки кращій роботі з повторюваними подіями на весь день. Компанія додає, що «також вирішила проблеми з плутаниною AM/PM під час встановлення будильника», тобто виправила помилку в базовій функції, яка мала б працювати бездоганно з самого початку.

Джерело

Engadget

Схоже, нові ігри серії Call of Duty більше не з’являтимуться на консолях минулого покоління на кшталт PS4 та Xbox One, і шанувальникам франшизи доведеться переходити на дорожчі нові приставки. Офіційний акаунт бренду нещодавно повідомив у соцмережах, що «наступна Call of Duty не розробляється для PS4». Про Xbox One прямо не йшлося, але важко уявити, що розробник витрачатиме ресурси на ще менш популярну платформу.

Call of Duty була однією з останніх великих ігрових серій, що продовжували підтримувати старе покоління консолей. Попередня частина, Call of Duty: Black Ops 7, виходила майже на всьому, включно з PS4 та Xbox One.

З одного боку, це природний цикл життя консолей. PS5 та Xbox Series X/S незабаром виповниться шість років, і необхідність забезпечити роботу сучасних ігор на старіших приставках може обмежувати можливості всіх версій гри. Це постійний компроміс.

З іншого боку, економічна ситуація складна, і багато хто просто не може дозволити собі PS5 або Xbox Series X/S. Додає проблем дефіцит пам’яті на тлі буму ШІ, який призвів до численних підвищень цін. Звичайна дискова PS5 тепер коштує близько $650 — на $150 більше за стартову ціну. Нагадаємо, консоль вийшла ще у 2020 році. Ціни на Xbox Series X/S також істотно зросли від моменту запуску.

Не дивно, що складна економіка та зростання вартості консолей вдарили по продажах. Sony нещодавно повідомила, що продажі PS5 під час святкового сезону 2025 року впали на 16 відсотків порівняно з 2024-м. З погляду «класичної» логіки індустрії вже давно час прощатися з консолями минулого покоління, але нині ситуація далека від звичайної.

У будь-якому разі, нову Call of Duty очікують уже цього року, хоча офіційних подробиць поки немає. Чутки свідчать, що це може бути Call of Duty: Modern Warfare 4. Activision Blizzard ще в червні минулого року випустила тизер Black Ops 7.

Джерело

Engadget

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

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

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

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

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

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

Джерело

Engadget

Apple довго вибудовувала свою стратегію щодо штучного інтелекту, і схоже, що ключовим елементом тут стане надання користувачам вибору. Згідно з останнім звітом Марка Гурмана з Bloomberg, компанія планує дозволити користувачам обирати з переліку сторонніх моделей, коли вони просять свої пристрої виконати завдання з генеративного AI. Ця зміна, за даними джерел видання, має з’явитися в iOS 27, iPadOS 27 та macOS 27.

Компанії, що займаються AI і погодяться інтегруватися та додати підтримку в свої програми з App Store, зможуть використовуватися для роботи інструментів Apple у форматі, який всередині компанії називають Extensions (розширення). «Extensions дозволяють отримувати доступ до можливостей генеративного AI з установлених додатків на вимогу — через функції Apple Intelligence, такі як Siri, Writing Tools, Image Playground та інші», — йдеться у повідомленні в тестових версіях ПЗ.

Раніше цього року вже з’являлися натяки, що «вибір» стане одним із ключових принципів стратегії Apple щодо Apple Intelligence. У березні Bloomberg повідомляв, що майбутній чат-бот компанії матиме підтримку різних AI‑моделей, між якими можна буде перемикатися. А впродовж останніх кількох років ChatGPT ставав дедалі важливішою частиною Apple Intelligence: платформа OpenAI вже зараз доступна для обробки частини завдань генеративного AI.

Джерело

Engadget

Steam Controller останні кілька тижнів активно обговорюють у світі ПК-геймінгу, і тепер з’явився новий привід для розмов: Valve оприлюднила CAD-файли корпусу цього геймпада. Їх можна безплатно завантажити за ліцензією Creative Commons, тож користувачі тепер можуть проєктувати та створювати власні аксесуари для Steam Controller і його «шайби».

Файли стосуються лише зовнішньої оболонки пристрою: надрукувати на 3D-принтері «начинку» і повністю зібрати контролер з нуля не вийде. Це означає, що тим, хто полює на Steam Controller, і надалі, ймовірно, доведеться зачекати, поки розпроданий геймпад знову з’явиться у продажу.

Разом з тим Valve поки не оголосила дати виходу Steam Machine та VR-шолома Steam Frame, тож для більшості геймерів купівля контролера зараз не є критично необхідною. Але якщо вам пощастить його знайти, це справді вдалий геймпад, а відкриття доступу до дизайну корпусу — цікавий крок, який дає спільноті простір для творчості.

Джерело

Engadget

Meta почне використовувати штучний інтелект для сканування фото та відео в пошуках візуальних ознак того, чи користувачу менше 13 років і його слід видалити з Facebook та Instagram. Про це компанія повідомила у вівторок. Серед таких візуальних ознак — зріст людини та її структура кісток.

«Хочемо чітко пояснити: це не технологія розпізнавання обличчя, — зазначає Meta у своєму блозі. — Наш ШІ аналізує загальні патерни та візуальні сигнали, наприклад зріст чи структуру кісток, щоб приблизно оцінити вік людини; він не ідентифікує конкретну особу на зображенні. Поєднуючи ці візуальні інсайти з аналізом тексту та взаємодій, ми можемо суттєво збільшити кількість неповнолітніх акаунтів, які виявляємо та видаляємо».

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

Компанія каже, що ця система є частиною її зусиль, спрямованих на недопущення дітей до 13 років на свої платформи. До таких заходів входить використання ШІ для аналізу цілих профілів у пошуках контекстних ознак — наприклад, святкувань дня народження чи згадок про шкільні класи. Meta шукає ці сигнали в різних форматах: дописах, коментарях, біографіях, підписах до фото тощо. У майбутньому компанія планує розширити використання цієї технології на більше розділів своїх застосунків, зокрема Instagram Live та Facebook Groups.

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

Оголошення пролунало через кілька тижнів після того, як присяжні в штаті Нью-Мексико зобов’язали Meta виплатити 375 млн доларів цивільних штрафів за введення споживачів в оману щодо безпечності її платформ та наражання дітей на ризики. Компанію також зобов’язали впровадити фундаментальні зміни у своїх сервісах. У відповідь Meta пригрозила припинити роботу своїх соцмереж у цьому штаті.

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

Meta також оголосила у вівторок про розширення технології, яка автоматично переводить підлітків у більш суворий режим «Teen Accounts» в Instagram, на 27 країн ЄС і Бразилію. Такі підліткові акаунти забезпечують жорсткіший режим із додатковими запобіжниками: можливість отримувати приватні повідомлення лише від людей, на яких користувач підписаний або вже з’єднаний, приховування шкідливих коментарів та встановлення приватності акаунта за замовчуванням.

Крім того, Meta повідомила, що вперше розширює цю технологію й на Facebook у США, а в червні її отримають користувачі у Великій Британії та країнах ЄС.

Джерело

TechCrunch

Освітній техногігант Instructure підтвердив витік даних, що зачепив конфіденційну інформацію студентів. За злам відповідає хакерське угруповання ShinyHunters, яке займається вимаганням.

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

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

Один із учасників ShinyHunters надав TechCrunch зразок викрадених даних, до якого увійшла інформація з двох шкіл у США — в штатах Массачусетс і Теннессі. Для школи в Массачусетсі зразок включав повідомлення, що містять імена, електронні адреси та деякі номери телефонів. Для школи в Теннессі зразок містив повні імена студентів та їхні електронні адреси.

У зразку не було паролів чи інших типів даних, які, за заявою Instructure, не постраждали внаслідок інциденту.

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

ShinyHunters також поділилися списком приблизно з 8 800 шкіл, які нібито постраждали від зламу. TechCrunch не зміг підтвердити, чи справді всі перелічені установи зазнали витоку, а також чи всі вони є клієнтами Instructure. На своєму офіційному сайті Instructure вказує, що обслуговує понад 8 000 навчальних закладів.

На запит TechCrunch представниця Instructure Кейт Голмс не відповіла на низку запитань щодо інциденту, натомість переадресувала на офіційну сторінку компанії, де публікуються оновлення про витік.

На своєму сайті для зливу даних, де ShinyHunters беруть на себе відповідальність за кібератаки та намагаються тиснути на жертв, вимагаючи викуп, хакери стверджують, що злам торкнувся майже 9 000 шкіл по всьому світу та даних 275 мільйонів людей, включно зі студентами, викладачами та іншим персоналом. В онлайн-чаті учасник ShinyHunters повідомив TechCrunch, що загальна кількість унікальних електронних адрес у викрадених даних становить 231 мільйон.

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

Джерело

TechCrunch

Фахівці з безпеки компанії Kaspersky заявили, що виявили шкідливий бекдор, вбудований у популярне програмне забезпечення для створення образів дисків під Windows – Daemon Tools.

Російська компанія з кібербезпеки повідомила у вівторок, що зібрані з комп’ютерів по всьому світу, на яких встановлено антивірус Kaspersky, дані свідчать про «широкомасштабну» атаку. Вона націлена на тисячі комп’ютерів з Windows, де використовується Daemon Tools.

Хакери, яких Kaspersky пов’язує з китайськомовною групою на основі аналізу шкідливого ПЗ, використали бекдор у Daemon Tools для встановлення додаткового malware на десяток комп’ютерів у роздрібній торгівлі, науковій та виробничій сферах, а також у державних структурах. У Kaspersky зазначають, що компрометація саме цих систем вказує на «цільовий» характер атаки.

За даними компанії, організації, які стали мішенню, розташовані в Росії, Білорусі та Таїланді.

Kaspersky повідомляє, що вперше бекдор було виявлено 8 квітня.

У компанії зазначили, що звернулися до Disc Soft, розробника Daemon Tools, але не уточнили, чи відповів розробник або вжив якихось заходів. Kaspersky стверджує, що атака на ланцюжок постачання «досі активна», що дає змогу зловмисникам і надалі встановлювати шкідливе ПЗ на тисячі комп’ютерів, де працює це програмне забезпечення для роботи з образами дисків.

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

Раніше цього року пов’язані з урядом Китаю хакери скомпрометували популярний текстовий редактор Notepad++, щоб доставляти malware низці організацій, які мають інтереси у Східній Азії. Минулого місяця дослідники безпеки також попереджали про іншу атаку, спрямовану на користувачів, котрі відвідували сайт компанії CPUID, розробника популярних інструментів HWMonitor та CPU-Z.

Журналісти TechCrunch завантажили інсталятор Daemon Tools для Windows з офіційного сайту, і під час перевірки файлу через онлайн-сервіс сканування на віруси VirusTotal було виявлено наявність бекдору.

Поки невідомо, чи була скомпрометована версія Daemon Tools для macOS, а також чи зачеплена інша продукція Disc Soft.

У відповіді на запит про коментар представник Disc Soft заявив, що компанія «знає про цей звіт і наразі розслідує ситуацію».

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

Джерело

TechCrunch

Microsoft у квітні зробила майже неможливе — знизила ціну медіа-підписки, частково відкотавши скандальне подорожчання Game Pass Ultimate 2025 року (хоча новий план без Call of Duty все одно дорожчий, ніж раніше). Якщо ви скасували підписку після підвищення цін, Xbox сподівається повернути вас завдяки травневим новинкам Game Pass, серед яких — чи не найбільший за довгий час ексклюзив Microsoft, Forza Horizon 6.

Нова частина стабільно відмінної серії гоночних ігор з відкритим світом вирушає цього разу до Японії й обіцяє понад 550 реальних автомобілів, на яких можна рвати дороги Токіо. Кореспондент Engadget Кріс Голт минулого місяця зіграв у пролог гри й залишився вражений віртуальною Японією від Playground Games, а також надихнувся на подорож до її реального аналога.

Forza Horizon 6 з’явиться в Game Pass Ultimate та PC Game Pass 19 травня. Як і попередниця, гра згодом вийде і на PS5, але дата релізу на консолі Sony поки невідома.

До цього часу сервіс також отримає кілька помітних новинок. 7 травня в Game Pass Ultimate на консолі та ПК виходить стильна наративна адвенчура Mixtape від Annapurna Interactive. За цією грою стежать уже давно — на неї варто звернути увагу, якщо ви ностальгуєте за 1990-ми.

14 травня вийде Subnautica 2. Довгоочікуване продовження підводного виживастика 2018 року технічно перебуватиме в ранньому доступі ще певний час, але, з огляду на те, що це зараз найчастіше додавана до списків бажаного гра в Steam, для Game Pass це ще одне велике поповнення місяця.

Ось повний список усього, що з’явиться в Game Pass найближчими тижнями.

6 травня

• Ben 10 Power Trip — Game Pass Ultimate, Game Pass Premium та PC Game Pass
• Descenders Next (Game Preview) — Game Pass Premium (вже доступна в Game Pass Ultimate та PC Game Pass)
• Wheel World — Game Pass Premium (вже доступна в Game Pass Ultimate та PC Game Pass)
• Wildgate — Game Pass Ultimate, Game Pass Premium та PC Game Pass
• Wuchang: Fallen Feathers — Game Pass Premium (вже доступна в Game Pass Ultimate та PC Game Pass)

7 травня

• Mixtape — Game Pass Ultimate та PC Game Pass

11 травня

• Outbound — Game Pass Ultimate та PC Game Pass

12 травня

• Black Jacket — Game Pass Ultimate та PC Game Pass
• Call of the Elder Gods — Game Pass Ultimate та PC Game Pass
• Elite Dangerous — Game Pass Ultimate та Game Pass Premium

14 травня

• Doom: The Dark Ages — Game Pass Premium (вже доступна в Game Pass Ultimate та PC Game Pass)
• Subnautica 2 — Game Pass Ultimate та PC Game Pass

Як завжди, нові ігри в Game Pass означають, що частина бібліотеки має звільнити місце. Усі проєкти, які покинуть сервіс 15 травня, Microsoft оголосить окремо.

Джерело

Engadget

Coinbase стала черговою техкомпанією, яка суттєво скорочує штат у межах «AI‑центричної» реструктуризації. Компанія звільнить близько 14 відсотків працівників, написав CEO Браян Армстронг у блозі. За даними Reuters, це становить приблизно 700 співробітників.

Армстронг заявив, що бачив, як інженери «завдяки ШІ випускають продукт за дні, на який раніше в команди йшли тижні», а нетехнічні підрозділи компанії «виводять у продакшн код», у той час як Coinbase автоматизує багато своїх процесів. «Усе це привело нас до точки зламу не лише для Coinbase, а й для кожної компанії, — написав Армстронг. — Найбільший ризик зараз — нічого не робити. Ми коригуємося завчасно та цілеспрямовано, щоб перебудувати Coinbase у струнку, швидку й AI‑native компанію. Нам потрібно повернути швидкість і фокус нашого стартап‑початку, з ШІ в ядрі».

Багато компаній посилаються на зростання ефективності завдяки штучному інтелекту як на причину (або привід) для скорочення персоналу. Meta минулого місяця заявила, що уріже ще 8 000 робочих місць, а Amazon у жовтні минулого року звільнила 14 000 людей.

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

За словами Армстронга, компанія прибирає окремі управлінські ланки та організовує бізнес навколо «AI‑native талантів, які можуть керувати флотом агентів і досягати непропорційно великого ефекту». «Ми також експериментуватимемо зі зменшеними розмірами команд, включно з “одиночними командами”, де інженери, дизайнери та продакт‑менеджери поєднуватимуться в одній ролі». Це фактично виглядає як спроба покласти на працівників більше обов’язків.

Ті, кого звільнять у США, отримають 16 тижнів базової зарплати плюс ще по два тижні виплат за кожен рік роботи в Coinbase. У пакет вихідної допомоги також увійдуть наступне нарахування акцій і шість місяців покриття медстрахування COBRA. За словами Армстронга, працівники в інших країнах отримають подібні умови.

Джерело

Engadget

Ірландські регулятори відкрили два розслідування щодо Meta, аби з’ясувати, чи компанія належно виконує європейський закон, який зобов’язує платформи надавати користувачам альтернативи таргетованим алгоритмічним стрічкам. Coimisiún na Meán, ірландський наглядовий орган за інтернетом, у вівторок заявив, що реагує на скарги про використання компанією «темних патернів», аби заважати людям отримувати доступ до альтернативних стрічок у Facebook та Instagram.

Згідно з Актом про цифрові послуги (Digital Services Act, DSA), який набрав чинності в Європі у 2023 році, великі платформи на кшталт сервісів Meta зобов’язані пропонувати користувачам альтернативу таргетованим стрічкам, що базуються на «профілюванні». У відповідь компанія додала в ЄС хронологічні варіанти перегляду Stories та Reels. Однак, за даними Coimisiún na Meán, Meta може не робити такі опції «легко доступними» і свідомо відводити користувачів від цих налаштувань (це й називають темним патерном).

«Coimisiún na Meán визнає занепокоєння багатьох людей щодо систем рекомендацій і потенційної шкоди, якої ці алгоритми можуть завдати, постійно підштовхуючи шкідливий контент у стрічки користувачів, особливо дітей та молоді», – йдеться в заяві регулятора. – «Наш меседж чіткий: неприйнятно, коли платформи заважають людям користуватися своїми правами, гарантованими законом, або намагаються маніпулювати ними, аби відвернути від усвідомленого вибору, чи дозволяти стрічкам на основі систем рекомендацій контролювати те, що вони бачать онлайн».

Якщо з’ясується, що Meta порушує DSA, компанії може загрожувати значний штраф. Закон дозволяє накладати санкції до 6% від глобального річного доходу компанії.

«Ми не погоджуємося з будь-якими твердженнями про порушення нами DSA», – заявив представник Meta у коментарі для Engadget. – «Ми суттєво змінили наші процеси та системи, щоб відповідати регуляторним вимогам, і співпрацюватимемо з Coimisiún na Meán, щоб надати деталі цієї роботи».

Джерело

Engadget

За власним зізнанням операційного директора OpenAI минулого лютого, «ми ще не бачили справжнього проникнення ШІ в бізнес-процеси підприємств». Але для гіганта корпоративного ПЗ SAP, акції якого суттєво просіли у 2026 році частково через «SaaSpocalypse», це питання залишається ключовим.

У понеділок європейський важковаговик оголосив про намір придбати німецький стартап Prior Labs, що займається штучним інтелектом, за нерозкритою сумою. Після отримання регуляторних дозволів SAP планує інвестувати в бізнес €1 млрд (близько $1,16 млрд) протягом наступних чотирьох років, щоб перетворити його на AI-лабораторію, зосереджену на структурованих даних — таблицях і базах даних, де зазвичай зберігається корпоративна інформація.

SAP відмовилася розкривати суму самої угоди, але джерела повідомили Pathfounders, що це був «здоровий» екзит: майже повністю грошова угода, в межах якої засновники стартапу — Франк Хуттер (Frank Hutter), Ноа Голлманн (Noah Hollmann) і Саурадж Гамбхір (Sauraj Gambhir) — отримають готівкою понад пів мільярда доларів авансом.

Трійка заснувала Prior Labs лише 18 місяців тому, зосередившись на табличних базових моделях (tabular foundation models, TFM) — моделях ШІ, що вміють будувати прогнози на основі даних у таблицях і базах даних. Потенційно це краще підходить для корпоративних клієнтів, ніж мовні моделі. І вже точно це краще пасує SAP, чиє широко використовуване ПЗ для бухгалтерії, HR, закупівель і управління витратами спирається на власну базу даних.

Водночас найцінніша компанія Німеччини, схоже, грає і в обороні, поки індустрія рухається до агентного ШІ. Працюючи над створенням власної AI-лабораторії, компанія заблокувала OpenClaw та будь-які інші агентні технології, які вона явно не санкціонувала, як першою помітила The Information.

У відповідь на запит щодо коментаря пресслужба SAP послалася на оновлену політику використання API. У ній вказано, що SAP «забороняє» доступ агентів ШІ до своїх продуктів через API, за винятком тих, що працюють у «схвалених SAP архітектурах».

До авторизованих архітектур, звісно, входить і власне рішення SAP — Joule Agents, що поки перебуває в бета-версії й дозволяє клієнтам створювати власних агентів. Nvidia ще в березні оголосила, що SAP Joule підтримує Agent Toolkit від Nvidia — програмне забезпечення для керування агентами. Саме на ньому побудований орієнтований на корпоративний сегмент, з фокусом на безпеку конкурент OpenClaw від Nvidia — NemoClaw. Відповідно, клієнти SAP зможуть офіційно використовувати агентів NemoClaw.

Для такого гіганта, як SAP, ШІ одночасно є і загрозою, і можливістю. «Усе залежить від того, як швидко ми як SAP зможемо впровадити ці технології у наш R&D-портфель, щоб зберегти відносну перевагу економії на масштабі», — сказав фінансовий директор SAP Домінік Ассам (Dominik Asam) в інтерв’ю CNBC у січні.

SAP не сиділа склавши руки. Німецька компанія інвестувала в генеративні AI-компанії, що розробляють мовні моделі різного масштабу. У 2023 році SAP підтримала конкурента OpenAI — Anthropic, а також Aleph Alpha і Cohere, які тепер планують об’єднатися, щоб створити «глобальну AI-силу».

Компанія також розробила SAP-RPT-1 — реляційну попередньо натреновану трансформерну модель. «Доволі рано SAP усвідомила, що найбільш недооціненим шансом у корпоративному ШІ є не великі мовні моделі, а ШІ, створений для структурованих даних, на яких працює бізнес усього світу», — заявив у коментарі технічний директор SAP Філіп Херціг (Philipp Herzig).

Придбання Prior Labs стало суттєвим скороченням шляху в цьому напрямку. Серія моделей TabPFN отримала значну популярність серед розробників. У блозі про угоду засновники стартапу повідомили, що їхні open source-моделі вже завантажили понад три мільйони разів.

У пресрелізі SAP пообіцяла зберегти відкриті версії моделей Prior Labs: «Лабораторія працюватиме як незалежний підрозділ, щоб зберегти швидкість досліджень, тоді як SAP забезпечить довгострокові інвестиції і прямий шлях до продуктів по всьому портфелю SAP — через SAP AI Core і SAP Business Data Cloud, а також агентний шар на базі Joule».

SAP і стартап, що базується у Фрайбурзі (Німеччина), сподіваються, що ці інвестиції дозволять створити TFM, здатні «діставати» дані безпосередньо з таблиць, поєднуючи їх із мовою, міркуванням і доменною експертизою.

Більше того, вони розраховують, що Prior Labs із цим «масштабним бустом» від SAP зможе стати «новою глобальною передовою AI-лабораторією зі структурованих даних — у Європі, у відкритому форматі», — написав засновник і CEO Франк Хуттер у пості в X.

У лютому 2025 року стартап залучив близько $9,3 млн у пре-сід-раунді на чолі з Balderton Capital — більше, ніж конкурент Neuralk-AI, але значно менше, ніж Fundamental, який вийшов із режиму stealth з раундом Series A на $255 млн у лютому.

У своєму дописі в X партнер Balderton Джеймс Вайз (James Wise) назвав угоду з Prior Labs «одним із найбільших венчурних результатів у Німеччині за всю історію». Акції SAP на момент публікації торгуються з невеликим зростанням.

Джерело

TechCrunch

Стартап Nuro отримав дозвіл на початок безпілотних випробувань електрокросоверів Lucid Gravity з його автономною технологією на громадських дорогах Каліфорнії. Саме ці автомобілі згодом планують використовувати в преміальному сервісі роботаксі Uber. Водночас компанія зі Силіконової долини, яку підтримують Nvidia та Uber, заявляє, що ще не готова одразу виходити на дороги без водія.

Департамент автотранспорту Каліфорнії (DMV), що регулює тестування та розгортання автономних авто в штаті, підтвердив TechCrunch, що змінив безпілотний дозвіл Nuro, щоб додати до нього автомобілі Lucid Gravity.

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

Оновлений дозвіл дозволяє Nuro тестувати автомобілі Lucid без водія-безпеки за кермом. Представник компанії Девід Салґеро повідомив TechCrunch, що Nuro планує розпочати безпілотні випробування пізніше цього року, не розкриваючи точніші терміни.

Цей дозвіл — лише один із низки регуляторних бар’єрів, які Nuro має подолати, перш ніж Uber зможе запустити свій преміальний сервіс роботаксі. Компанії також необхідно отримати дозвіл на безпілотні поїздки від Комісії з громадських послуг Каліфорнії (CPUC) і дозвіл на комерційне розгортання від DMV.

Поки що Nuro та Uber тестують Lucid Gravity в автономному режимі з водієм-безпекою на місці водія. Минулого місяця ці випробування розширили: тепер співробітники Uber можуть замовити поїздку в автономному Lucid роботаксі через застосунок Uber — але з водієм-безпекою всередині.

Паралельно з прогресом Nuro у тестах Uber збільшує свої зобов’язання перед Lucid.

Коли в липні 2025 року оголосили про тристоронню угоду, Uber заявляв, що інвестує в Lucid 300 млн доларів і придбає 20 000 кросоверів Gravity, готових до роботаксі. З того часу угоду розширили до 500 млн доларів та мінімум 35 000 роботаксі. Оновлена домовленість передбачає щонайменше 10 000 кросоверів Gravity і 25 000 електромобілів на майбутній середньорозмірній платформі Lucid.

Усі ці електромобілі оснастять автономною системою Nuro, яка працює на обчислювальній платформі Nvidia Drive AGX Thor. Роботаксі Lucid Gravity, представлене в січні, має високороздільні камери, твердотільні лідари та радари, що допомагають системі автопілоту сприймати реальний світ і орієнтуватися в ньому.

Uber також інвестував у Nuro кількамільйонну суму.

Lucid вже поставила 75 інженерних автомобілів для Nuro та Uber, і процес тестування та накопичення пробігу триває в кількох містах США, повідомив автовиробник під час квартального звіту у вівторок.

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

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

Джерело

TechCrunch

Малі відкриті моделі стають ключовим інструментом для пошуку, агентів і обробки документів, але більшість продакшн‑інфраструктури досі заточена під один великий модельний контейнер на GPU. У виступі на каналі AI Engineer інженер Superlinked Філіп Макрадулі розповів, як команда побудувала власний inference‑двигун для малих моделей з динамічним завантаженням, hot‑swap’ом і «розумним» вивантаженням з пам’яті — замість класичної схеми «одна модель — один контейнер — один GPU».

Чому малі моделі критичні для агентів і пошуку

Головний контекст — проблема «context rot»: якість відповідей великих моделей погіршується зі зростанням обсягу контексту, навіть якщо збільшувати вікно контексту. Дослідження Chroma показують, що деградація якості неминуча, коли в контексті накопичується забагато інформації.

Малі моделі тут працюють як шар попередньої обробки:

• Контекст‑менеджмент. Невеликі моделі можуть фільтрувати, агрегувати й структурувати дані до того, як вони потрапляють у LLM. Це зменшує кількість токенів і навантаження на основну модель.
• Tool calling. Малі моделі виступають окремими інструментами — наприклад, для класифікації, витягування сутностей чи побудови таксономій. У Superlinked вже використовували такий підхід у продакшні для класифікації товарів в e‑commerce через tool calling.
• Покращення «класичного» пошуку. Попередня обробка даних робить навіть прості інструменти на кшталт grep і файлових індексів ефективнішими.

Спільнота рухається в тому ж напрямку: Андрій Карпатий будує графові бази знань на основі NER‑моделей, Chroma випустила власну модель для фільтрації й управління контекстом, а інші розробники створюють рішення для агресивного скорочення токенів перед викликом LLM.

Чим inference для малих моделей НЕ є

Інтуїтивна відповідь на проблеми inference — «додати ще GPU». Для малих моделей це часто означає масове марнування ресурсів:

• Типові моделі для ембеддингів, реранкінгу чи NER (Stella, GlyNER тощо) займають лише кілька гігабайтів пам’яті.
• Якщо виділяти окремий GPU під кожну таку модель, більшу частину часу він простоює.

Для цього класу задач критичною стає можливість:

• Hot‑swap моделей на одному GPU. Кілька моделей ділять один GPU, завантажуючись і вивантажуючись за потреби.
• Евікція за принципом LRU. Моделі, які давно не використовувалися, вивантажуються з пам’яті, звільняючи місце для нових.
• Швидке перемикання інструментів. Якщо в агенті одна задача потребує реранкера, інша — NER‑моделі, інфраструктура має дозволяти миттєво змінювати набір активних моделей без перепідняття контейнерів.

Ще одна хибна уява: inference — це лише «сервер, який крутить модель». У реальному продакшні потрібен повний ланцюжок:

• роутинг запитів;
• авто‑масштабування;
• черги;
• моніторинг (Prometheus, Grafana);
• керування GPU‑пулами та spot‑інстансами.

На ринку, за оцінкою Superlinked, немає open‑source рішення, яке б з’єднувало inference‑двигун і продакшн‑кластер в одному стеку для малих моделей. Саме цю нішу команда й намагається закрити.

«Інь і ян» inference: моделі проти інфраструктури

Superlinked пропонує дивитися на inference як на поєднання двох рівнозначних частин.

Інь: широка підтримка відкритих моделей

Без підтримки потрібних моделей будь‑яка інфраструктура втрачає сенс. Відкритий простір моделей зростає вибухово:

• На Hugging Face вже мільйони моделей (станом на березень — близько 3 млн).
• Open‑source швидко наздоганяє й переганяє керовані сервіси в точкових задачах: на бенчмарках на кшталт MTEB вузькоспеціалізовані моделі часто показують кращі результати.
• Невеликі моделі на кшталт Gemma з низькою кількістю параметрів демонструють ELO‑рейтинги, вищі за значно більші моделі.

Підтримати «сотні моделей» — нетривіальне завдання, бо:

• Різні реалізації attention. BERT, Qwen, ColBERT та інші використовують різні варіанти flash attention, grouped query attention тощо.
• Різні позиційні кодування. BERT працює з абсолютними позиційними ембеддингами, Qwen — з rotary embeddings; це вимагає різної логіки в forward‑проході.
• Різні вихідні формати.
• ColBERT генерує множину векторів (late interaction).
• Cross‑encoders і реранкери можуть повертати не вектори, а скорингові значення.

Щоб уніфікувати це, Superlinked:

• реімплементує forward‑прохід моделей, адаптуючи attention, padding і роботу з Q/K/V;
• підтримує змінну довжину послідовностей у flash attention, щоб:
• робити токен‑орієнтоване батчування;
• не витрачати обчислення на «порожні» токени при падингу до максимальної довжини в батчі.

Це дозволяє ефективно працювати з моделями різних архітектур, не жертвуючи продуктивністю.

Ян: кластер і API як єдине ціле

Друга половина — інфраструктурна. Superlinked описує її як шар між простим API і реальним залізом.

Базові примітиви API:

• encode — отримання ембеддингів;
• score — обчислення скорів (наприклад, для реранкінгу);
• extract — витягування структурованої інформації.

Під ними працює:

• Роутер і черги. Розподіляють навантаження між пулами ресурсів залежно від поточного трафіку.
• Різні GPU‑пули. Поєднання spot‑інстансів і потужніших GPU для різних типів задач.
• Авто‑масштабування через KEDA + Prometheus. Метрики з Prometheus використовуються для динамічного масштабування кластерів і перерозподілу моделей, щоб уникати простою GPU.
• Декларативне керування. Моделі описуються в конфігурації; далі достатньо зробити terraform apply. Для розгортання доступні Helm‑чарти та Docker‑образи.

Ключова ідея — дати розробникам не окремо «двигун для моделей» і «кластер Kubernetes», які треба зшивати власним кодом, а цілісний стек для inference малих моделей.

Від теорії до open source

Результатом цієї роботи став open‑source inference‑двигун Sie (Superlinked inference engine), який поєднує:

• адаптований forward‑прохід для широкого спектра малих моделей (ембеддинги, реранкери, NER, ColBERT‑подібні архітектури);
• кластерну інфраструктуру з роутингом, авто‑масштабуванням і GPU‑менеджментом.

За задумом авторів, це має закрити прогалину між експериментами з малими моделями й реальним продакшном, де важливі не лише FLOPS, а й ефективне використання пам’яті, гнучке завантаження моделей і повноцінний спостережуваний стек.

Джерело

The Small Model Infrastructure Nobody Built (So We Did) — Filip Makraduli, Superlinked

Штучний інтелект дедалі частіше опиняється в центрі суспільних дискусій — від страхів щодо втрати роботи до сценаріїв з наукової фантастики. У розмові на подкасті «20VC with Harry Stebbings» CEO Shopify окреслює ще один тренд: ШІ стає ідеальним виправданням для будь-яких непопулярних рішень бізнесу, зокрема масових скорочень.

Чому ШІ зручно звинувачувати у всьому

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

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

Індустрія страху: як формується негативне сприйняття

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

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

Між страхом і реальними перевагами

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

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

Що означає «ідеальний цап-відбувайло» для ринку праці

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

У такій ситуації є ризик, що:

• працівники не отримують чесного пояснення причин звільнень;
• суспільство переоцінює роль ШІ й недооцінює інші фактори;
• регулятори реагують на страхи, а не на реальні виклики.

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

Джерело

YouTube: https://www.youtube.com/watch?v=6Q0ULF76n6c

Як інциденти перетворюються на знання: Git, сканери прогалин і нова дисципліна для enterprise‑AI

У великих компаніях сьогодні вже нікого не здивуєш десятками MCP‑серверів, RAG‑шарів і інтеграцій з Confluence чи Slack. Але Jira‑квитки все одно рухаються повільно, а агенти поводяться як талановитий стажер, який постійно щось перепитує. На конференції AI Engineer про те, як змінити цю картину, розповідає Радж Навакоті — staff software engineer в IKEA у домені Delivery Services, де понад сотня інженерів і шість продуктових команд будують внутрішні AI‑системи.

Навакоті пропонує не черговий «чарівний» RAG, а операційну дисципліну: demand‑driven context — методологію, де реальні інциденти, провали агентів і Git‑репозиторій стають рушієм побудови знань. У цьому матеріалі — як саме інциденти перетворюються на структуровані context blocks, як автоматичний сканер прогалин виявляє «дірки» в документації, і чому GitHub стає центральним джерелом правди для корпоративного знання, навіть якщо кінцеві користувачі читають його в Confluence чи Slack.

Від розбору інциденту до нових сутностей: як агент виявляє «дірки» в знаннях

У центрі підходу — не абстрактні use case’и, а дуже конкретний сценарій: розбір кореневої причини інциденту. Це типовий для enterprise завдання, де переплітаються системна архітектура, бізнес‑логіка, внутрішні сервіси, API й неформальні процеси.

Методологія працює так: агент отримує інцидент як робочий елемент, намагається провести root cause analysis, спираючись на існуючу монолітну базу знань, і… закономірно натикається на те, чого там немає.

Спочатку агент робить стандартний крок: через RAG, MCP чи інший retrieval‑шар витягує все, що може, з наявної документації — Confluence, Jira, GitHub, внутрішні wiki. На цьому етапі він поводиться як будь‑який сучасний enterprise‑агент: збирає фрагменти, будує гіпотезу, формує пояснення.

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

• невідомими термінами, які не знаходить у жодному джерелі;
• внутрішніми сервісами чи API, що згадуються в логах або тікетах, але не описані в документації;
• бізнес‑правилами, які явно впливають на поведінку системи, але існують лише як «усна традиція» в команді.

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

Агент не просто констатує, що йому чогось бракує. Він формулює це як конкретні knowledge gaps: «існує термін X, який використовується в логах і Jira, але не має визначення», «є сервіс Y, який впливає на цей інцидент, але немає опису його API», «є бізнес‑правило Z, яке змінює поведінку системи, але воно ніде не задокументоване».

Далі в гру вступає людина. Інженер або доменний експерт відповідає на ці запити, пояснює, що таке X, Y, Z, як вони пов’язані з інцидентом і з іншими частинами системи. І тут відбувається принципово важливий крок: ці пояснення не залишаються в чаті чи особистих нотатках, а перетворюються на нові context blocks — окремі, чітко структуровані фрагменти знань, які додаються до бази.

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

14 інцидентів і стрибок впевненості: як виміряти, що знання справді ростуть

Одна з ключових проблем enterprise‑AI — відсутність метрик, які показують, що «агент став розумнішим» не в абстрактному сенсі, а саме в контексті конкретного домену. У demand‑driven context ця проблема вирішується через повторювані цикли на реальних інцидентах.

Навакоті проганяє описаний вище процес не один раз, а на серії з 14 інцидентів. Кожен інцидент — це:

• спроба агента провести root cause analysis, використовуючи поточну базу знань;
• виявлення прогалин: невідомі терміни, відсутні описи сервісів, неформалізовані бізнес‑правила;
• уточнення цих прогалин людиною;
• перетворення уточнень на нові context blocks і додавання їх до репозиторію.

Щоб уникнути суб’єктивності, вводиться числова метрика — умовний «рівень впевненості» агента в тому, що він має достатній контекст для якісного аналізу інциденту. На старті, коли база знань ще майже не адаптована під конкретний домен, цей показник тримається на рівні близько 1,5. Це означає, що агент постійно натикається на невідомі поняття, робить припущення, які не витримують перевірки, і вимагає великої кількості уточнень від людини.

Після того як процес проходить через 14 інцидентів, картина змінюється. Впевненість агента зростає до приблизно 4,4. Це не магічне «AGI прокинулося», а наслідок дуже конкретної роботи:

• кожен інцидент додає кілька нових сутностей і зв’язків до бази;
• повторювані патерни — наприклад, одна й та сама бізнес‑логіка, яка впливає на різні інциденти, — фіксуються один раз як окремий context block;
• наступні інциденти вже «знаходять» ці блоки через retrieval‑шар, і агенту не потрібно щоразу перепитувати людину.

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

Цей підхід нагадує test‑driven development: замість того щоб намагатися «одразу описати все», команда йде від провалів на реальних задачах. Кожен інцидент — це фактично новий тест, який або проходить, або виявляє, що в системі знань бракує ще одного блоку.

Git як джерело правди: чому контекстні блоки живуть у flat‑файлах

Щойно з’являється ідея «context blocks» як окремих одиниць знань, постає практичне питання: де й як їх зберігати. Навакоті у своїй реалізації робить вибір на користь максимально простого, але дисциплінованого підходу: Git‑репозиторій з flat‑файлами.

У демонстраційному фреймворку кожен context block — це, по суті, Markdown‑файл у Git. У ньому описується конкретна сутність або фрагмент домену: сервіс, бізнес‑процес, API, специфічне правило, яке впливає на поведінку системи. Файли організовані так, щоб їх було легко індексувати retrieval‑шаром і водночас читати людям.

Чому саме Git, а не одразу Confluence чи інша корпоративна wiki? У цього вибору кілька прагматичних причин.

По‑перше, GitHub (або інший Git‑хостинг) вже дає все, що потрібно для колективної роботи над знаннями: pull request’и, code review, історію змін, механізми вирішення конфліктів. Це означає, що контекстні блоки можна розвивати так само, як код: одна команда додає новий блок, інша — переглядає, коментує, пропонує правки. Для організацій, де інженерна культура вже побудована навколо Git, це природне продовження звичних практик.

По‑друге, Git добре підходить для сценарію, де знання спочатку формуються як «чернетка для агентів», а вже потім публікуються в більш дружніх до бізнесу інструментах. Навакоті прямо підкреслює: Git‑репозиторій з curated context blocks — це не обов’язково кінцевий інтерфейс для всіх співробітників. Це радше джерело правди, з якого можна синхронізуватися в Confluence, Slack, внутрішні портали чи інші системи.

По‑третє, Git добре масштабується для мультикомандних сценаріїв. У IKEA Delivery Services, де працює Навакоті, понад 100 інженерів у шести продуктових командах. У такому середовищі неминуче виникають конфлікти й дублювання знань. Git дозволяє їх виявляти й вирішувати на рівні pull request’ів, а не в хаотичних правках у wiki.

При цьому фреймворк не обмежується лише Git. Він може бути підключений до Confluence, Slack, GitHub чи інших джерел через MCP або RAG. Але саме Git‑репозиторій з flat‑файлами виступає як curated шар — місце, де знання проходять відбір, структурування й рев’ю, перш ніж стати частиною «офіційного» контексту для агентів.

Автоматичний сканер прогалин: як інциденти й Jira‑тікети перевіряють базу знань

Ручний розбір інцидентів — потужний, але обмежений інструмент. Щоб масштабувати demand‑driven context, Навакоті додає ще один компонент — автоматичний сканер прогалин у контексті.

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

Технічно процес виглядає так. Спочатку сканер бере, наприклад, опис інциденту або Jira‑квитка і генерує з нього набір probe’ів — цільових запитів, які мають перевірити, чи достатньо в базі знань інформації, щоб агент міг розв’язати це завдання. Це можуть бути питання про конкретні сервіси, бізнес‑процеси, API, залежності між системами, нетривіальні статуси чи конфігурації.

Далі ці probe’и проганяються через retrieval‑шар проти поточної бази знань — того самого Git‑репозиторію з context blocks та інших підключених джерел. Сканер аналізує відповіді й класифікує стан документації для кожного аспекту:

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

Результатом роботи сканера стає консолідований огляд того, чого саме бракує в знаннях для кожного інциденту чи тікета. Це не абстрактне «нам потрібно краще документувати систему», а конкретний перелік відсутніх елементів: системна інформація, API, бізнес‑процеси, «племінні» знання, які досі жили лише в головах окремих інженерів.

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

Пріоритизація прогалин: критичне, високе, середнє — і що документувати першим

Коли сканер проганяє десятки чи сотні інцидентів і Jira‑квитків, кількість виявлених прогалин швидко зростає. Якщо просто скласти їх у довгий список, команда ризикує опинитися в знайомій ситуації: «так, ми знаємо, що документація погана, але з чого почати?».

Щоб цього уникнути, у фреймворку вводиться ще один рівень структурування — класифікація прогалин за критичністю. Кожен виявлений gap отримує оцінку: critical, high або medium.

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

High‑пріоритет отримують прогалини, які не блокують завдання повністю, але суттєво знижують якість роботи агента: він змушений робити припущення, часто перепитувати людину, витрачати більше часу на уточнення. Це можуть бути, наприклад, частково описані API без прикладів реальних payload’ів або бізнес‑процеси без чітких варіантів гілкування.

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

Така класифікація перетворює amorphous «нам треба краще документуватися» на керований беклог робіт з документацією. Команди можуть планувати спринти, де поруч із фічами й техборгом з’являються задачі на створення або оновлення конкретних context blocks, прив’язаних до критичних і high‑прогалин.

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

Висновок: знання як інфраструктура, а не побічний продукт

Історія, яку показує Радж Навакоті, — це не про черговий «правильний стек» для AI‑агентів. LLM, MCP, RAG — усе це вже є в більшості великих компаній. Проблема в тому, що вони живляться з монолітної, фрагментованої й частково усної бази знань, де 40% критичної інформації існує лише як tribal knowledge.

Demand‑driven context пропонує поставити знання на ті самі рейки, що й код: інциденти як тести, провали як сигнал про прогалини, Git‑репозиторій як джерело правди, автоматичні сканери як інструмент контролю якості, пріоритизація за критичністю як спосіб планування роботи.

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

Для enterprise‑команд це означає неприємну, але неминучу істину: ніхто ззовні не прийде й не «полагодить» вашу базу знань. LLM‑провайдери покращуватимуть моделі, ринок retrieval‑інструментів зростатиме, але моноліт внутрішнього знання доведеться розбирати самим — інцидент за інцидентом, context block за context block’ом.

Джерело

Demand-Driven Context: A Methodology for Coherent Knowledge Bases Through Agent Failure — AI Engineer