Пошук в інтернеті пройшов шлях від примітивного зіставлення слів до складних агентних систем, що вміють планувати, перевіряти джерела й синтезувати знання. Канал IBM Technology простежує цю еволюцію — від класичних індексів до agentic RAG, який перетворює великі мовні моделі на адаптивних дослідників.

Коли пошук бачив лише слова

Перші пошукові системи відповідали на просте запитання: «Де зустрічається це слово?». В основі лежали інвертовані індекси — мапа «ключове слово → документи», де це слово є.

Далі вступали в гру алгоритми ранжування на кшталт TF‑IDF чи BM25, які оцінювали важливість терміну в документі та в колекції загалом. Цей підхід і досі живе в багатьох системах, але має ключовий недолік: він не розуміє мову.

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

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

Семантичний пошук і гібридні системи

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

Ці векторні подання (ембеддинги) навчаються великими нейромережами на масивах текстів. Завдяки контексту:

• схожі поняття опиняються близько одне до одного в просторі;
• різні слова з подібним значенням (наприклад, «кава» і «еспресо») стають «сусідами»;
• несхожі поняття («кава» і «будинок») розносяться далеко.

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

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

• точність keyword‑пошуку;
• широту семантичного пошуку.

Уперше пошук наблизився до розуміння наміру, а не просто текстового збігу.

LLM і народження RAG: коли генерація зустріла пошук

Поява великих мовних моделей (LLM) знову змінила правила гри. Ці моделі навчаються на гігантських корпусах текстів і вміють:

• продовжувати текст, передбачаючи наступні токени;
• формувати зв’язні відповіді на запити;
• узагальнювати, перефразовувати, структурувати інформацію.

Однак у LLM є фундаментальне обмеження: вони не «знають» нічого поза тим, що було в їхніх тренувальних даних до певного моменту часу. Вони:

• не мають доступу до актуальної інформації;
• не бачать внутрішніх документів конкретної організації;
• не оновлюють знання без дорогого перенавчання.

Рішенням стало повернення до пошуку — у новій ролі. Так з’явився RAG (retrieval augmented generation):

1. Користувач ставить запит.
2. Система шукає релевантні документи в зовнішній базі знань.
3. Знайдені фрагменти додаються до промпту LLM.
4. Модель генерує відповідь, спираючись на цей контекст.

RAG дає LLM «зовнішню пам’ять». Це дозволяє:

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

Перші RAG‑конвеєри були лінійними: документи заздалегідь векторизувалися й складалися у векторну базу, при запиті один раз виконувалося отримання релевантних фрагментів, які напряму передавалися в модель. Це вже суттєво зменшувало галюцинації й відкривало шлях до використання LLM у бізнесі.

Але залишалася стара проблема: якість відповіді дорівнює якості пошуку. Система не вміла адаптуватися до нових сценаріїв — конвеєр був жорстко заданий.

Від статичного RAG до агентів

Щоб зробити RAG гнучкішим, у конвеєри почали додавати нові елементи:

• Rerankers — моделі, які перевпорядковують результати пошуку за релевантністю.
• Переписування запитів — розширення або переформулювання запиту для кращого покриття.
• Гібридний ретривал — одночасне використання keyword‑пошуку й векторного пошуку.

Це підвищило точність, але архітектура залишалася статичною: кроки були наперед визначені, система не приймала рішень самостійно.

Наступний злам — поява агентів. Агент — це система, яка використовує LLM і набір інструментів для автономного виконання завдань. У її розпорядженні можуть бути:

• сама мовна модель;
• пам’ять;
• планувальник;
• критики (модулі перевірки);
• різні ретривери;
• інші інструменти й API.

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

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

Такий підхід дозволяє:

• порівнювати джерела;
• перевіряти твердження;
• уточнювати й переформульовувати запити;
• викликати зовнішні API;
• працювати з кількома базами знань;
• інтегрувати мультимодальні дані.

RAG у цьому контексті стає не фіксованим етапом, а інструментом, який агент викликає в міру потреби. Так формується agentic RAG — системи, здатні до:

• багатокрокових досліджень;
• синтезу інформації з різних документів;
• адаптивної поведінки залежно від завдання.

Фокус зміщується: система не просто відповідає, а спершу вирішує, як знайти відповідь.

Куди рухається пошук далі

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

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

Джерело

YouTube: RAG’s Evolution: From Simple Retrieval to Agentic AI

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

У лютому компанія повідомляла, що планує випустити від 25 000 до 27 000 автомобілів у 2026 році. Це набагато менше за сотні тисяч машин, які Lucid Motors обіцяла виробити та продати цього року, коли виходила на біржу у 2021-му. Водночас навіть ці плани означали б суттєве зростання порівняно з торішнім показником приблизно у 18 000 авто.

Зміну прогнозу оголосив фінансовий директор Тауфік Буссаїд під час презентації результатів за перший квартал. Це сталося лише за кілька місяців після того, як компанія скоротила 12% персоналу, про що TechCrunch вперше повідомив у лютому. У поданих у вівторок документах Lucid Motors зазначила, що ці звільнення коштуватимуть близько 40 млн доларів у короткостроковій перспективі, однак, на її думку, в перспективі кількох років зекономлять до 500 млн доларів.

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

«Очевидно, що для реалізації повного потенціалу Lucid потрібні чіткіший фокус і послідовне виконання, особливо в частині спрощення, пріоритезації та швидкості», — сказав Наполі під час дзвінка.

Також у вівторок Lucid Motors повідомила, що перший квартал виявився гіршим за очікування, переважно через перебої у виробництві та тимчасову зупинку продажів, яка протягом 29 днів блокувала поставки кросовера Gravity через проблеми з постачальником сидінь.

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

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

Усе це відбувається на тлі планів Lucid Motors цього року запустити у виробництво свій перший справді масовий електромобіль вартістю менше 50 000 доларів. Компанія раніше заявляла, що почне випуск першої моделі на новій середньорозмірній платформі до кінця 2026 року. У вівторок вона знову зробила акцент на наступному році, підтвердивши, що «залишається в графіку щодо нарощування виробництва середньорозмірної моделі у 2027 році».

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

Оновлення: Статтю доповнено уточненням, що поставки були зупинені на 29 днів.

Джерело

TechCrunch

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

Стартап Altara із Сан-Франциско, який щойно залучив $7 млн посівних інвестицій, стверджує, що створив AI-шар, покликаний подолати ці розриви в даних і звести фрагментовану технічну інформацію в єдину платформу. Раунд очолив фонд Greylock за участі Neo, BoxGroup, Liquid 2 Ventures та Джефа Діна (Jeff Dean).

Altara заснували у 2025 році Єва Теке (праворуч на фото), яка раніше займалася дослідженнями в галузі фізики елементарних частинок у Fermilab і працювала в SpaceX, та Кетрін Ю (ліворуч на фото), колишня інженерка з штучного інтелекту в Warp. Вони познайомилися під час навчання на факультеті компʼютерних наук Гарвардського університету.

«Уявіть, що ви компанія, яка створює батареї нового покоління, і акумулятор виходить з ладу під час випробувань комірок у процесі R&D, — пояснює Ю. — Команда інженерів змушена вручну перевіряти безліч різних джерел даних — від логів із сенсорів до даних про температуру та вологість. Вони звіряють історичні звіти про відмови».

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

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

Партнерка Greylock Корін Райллі порівнює те, що робить Altara у сфері фізичних наук, з роллю інженерів із надійності сайтів (SRE) у світі ПЗ. Якщо система виходить з ладу, «SRE заходить і дивиться на стек спостережуваності компанії, — каже вона. — Хтось вніс зміну в код, і саме це спричинило збій».

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

Altara — не єдиний стартап, що застосовує штучний інтелект для пришвидшення розробок у фізичних науках. Такі компанії, як Periodic Labs та Radical AI, також намагаються переосмислити наукові дослідження з нуля.

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

Фактично Райллі з Greylock називає AI для фізичних наук «наступним великим фронтиром» і прогнозує швидкий сплеск розвитку в цьому секторі.

Джерело

TechCrunch

Поки Bumble готується до масштабного оновлення, покликаного повернути покоління Z (якому дедалі більше набридають дейтинг-додатки), свіжий фінансовий звіт компанії показує подальше падіння кількості платних користувачів. У першому кварталі 2026 року їхня загальна кількість зменшилася на 21,1% — до 3,2 млн проти 4 млн роком раніше.

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

Так, загальна виручка компанії скоротилася на 14,1% — до $212,4 млн (хоча це й вище за очікування аналітиків), а дохід саме від застосунку Bumble знизився до $172,7 млн. Втім, середній дохід на одного платного користувача зріс майже на 9%. Компанія також показала вищий прибуток: чистий прибуток збільшився до $52,6 млн проти $19,8 млн за аналогічний період минулого року — переважно завдяки скороченню витрат на продажі та маркетинг.

Засновниця та CEO Bumble Вітні Вулф Герд під час дзвінка назвала спад платних користувачів частиною «свідомого перезапуску».

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

Попри таке пояснення, факт скорочення платної аудиторії складно ігнорувати. Тому значна частина розмови під час колу була присвячена майбутнім змінам. Bumble закликає інвесторів дивитися вперед — на масштабний перезапуск, який має згодом розвернути тренд.

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

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

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

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

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

Змінюються й профілі. Bumble експериментує з більш деталізованими, «розділовими» (chapter-style) профілями, які виходять за межі просто фото та короткого опису.

Окрім дейтингу, компанія демонструє певний прогрес і в інших напрямах. Її застосунок для пошуку друзів Bumble BFF минулого року отримав вкладку Groups, де користувачі можуть приєднуватися до чатів, планувати зустрічі та організовувати події. За словами Герд, залученість у цьому розділі зростає, особливо серед жінок покоління Z. За даними компанії, кількість приєднань до груп майже подвоїлася в період з грудня по березень.

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

Джерело

TechCrunch

Коли банк знає про вас більше, ніж друзі

На сцені TEDNext 2025 комік Майк Альбо перетворює нібито зірваний виступ через дзвінок із банку на сатиричний розбір того, як цифрові сервіси й дані бачать нас глибше, ніж ми самі. Історія про «підозрілу транзакцію» швидко стає історією про тотальну прозорість нашого життя перед алгоритмами.

Як звичайна перевірка транзакцій перетворюється на цифрове оголення

Сюжет починається з банальної ситуації: тривожний SMS про «іноземну транзакцію», автоматичне меню, очікування оператора. Далі — стандартна процедура безпеки: підтвердити останні операції за 24 години.

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

Але щойно оператор переходить до «справжніх» витрат, стає зрозуміло, що банк знає не лише про фінансову поведінку, а й про емоційний та особистий ландшафт людини:

• покупки в супермаркеті з деталізацією до двох курячих грудок і броколі;
• вино в одному магазині, а потім — у другому, щоб продавці не бачили повторної покупки;
• підписки на знайомства для геїв (Grindr, Scruff);
• оренда фільму «Call Me By Your Name» і реакція на нього;
• оформлення підписки на Peloton після емоційного зриву.

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

Дані як дзеркало самотності, віку й статусу

Найбільш промовистий момент — коли оператор починає описувати не лише покупки, а й внутрішній стан власника картки. На основі послідовності дій — алкоголь, додатки для знайомств, перегляд фільму, підписка на фітнес-сервіс — вимальовується портрет:

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

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

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

Коли смартфон стає співавтором нашого сценарію

Окрема лінія — залежність від смартфона й додатків. Телефон присутній у кожному кроці:

• перевірка повідомлень просто перед виходом на сцену;
• нескінченні перевірки Scruff і Grindr — у місті, в аеропорту, в Uber, уже на майданчику конференції;
• спроби знайти «гарячих хлопців» навіть серед глядачів у залі.

Смартфон тут — не просто інструмент, а постійний посередник між людиною й реальністю. Він:

• фіксує кожен імпульс (від нудьги до самотності);
• пропонує миттєві «рішення» — від вина до фітнес-підписки;
• зберігає сліди кожної емоційної покупки.

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

Гумор як спосіб говорити про контроль і вразливість

Попри комічну подачу, історія оголює кілька серйозних тем:

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

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

Джерело

My Bank Called In the Middle of My TED Talk | Mike Albo | TED

Чому корпоративний AI буксує: моноліт знань і пастка «племінної» експертизи

У великих компаніях штучний інтелект уже давно не екзотика. За оцінкою McKinsey за 2025 рік, близько 88% компаній декларують використання AI. Але реальна віддача від цих інвестицій вражає своєю скромністю: лише близько 6% створеної цінності. Цей розрив між очікуваннями й результатом особливо добре видно в інженерних організаціях, де AI-агенти вміють писати код, аналізувати інциденти й навіть збирати повноцінні застосунки, але Jira-дошки й далі стоять, як стояли.

Про те, чому так відбувається, розповідає Радж Навакоті, staff software engineer в IKEA у домені Delivery Services, де він працює з понад сотнею інженерів у шести продуктових командах. На практичному воркшопі для каналу AI Engineer він розбирає головну причину низької ефективності корпоративного AI: те, як влаштовані знання в організаціях, і чому монолітна база знань та «племінна» експертиза ламають навіть найкращі агенти й наймодніші RAG/MCP-рішення.

6% цінності при 88% впровадження: де зникає ефект від AI

У технічних командах сьогодні важко знайти людей, які не користуються хоча б якимось агентом — від GitHub Copilot до внутрішніх чат-ботів. Моделі вражають: вони генерують код, будують full‑stack застосунки за лічені хвилини, пишуть тести, роблять рев’ю pull‑request’ів, допомагають з інцидент-менеджментом.

Але якщо подивитися не на демо, а на операційну реальність, картина інша. Ключові бізнес-метрики — виконані Jira-тикети, закриті епіки, швидкість доставки фіч — змінюються набагато повільніше, ніж обіцяють презентації. Саме це й фіксує цифра McKinsey: 88% компаній користуються AI, а відчутна цінність — лише близько 6%.

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

Три шари знань: зелений, помаранчевий і червоний

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

Перший шар — «зелений». Це загальні знання, на яких уже навчені великі моделі. Стандарти HTTP, типові REST‑патерни, базові практики CI/CD, синтаксис мов програмування, типові архітектурні рішення — усе це вже є в LLM «з коробки». Коли Jira‑тикет вимагає саме такого типу роботи, агент справляється блискуче: пише код, виправляє баги, пропонує оптимізації.

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

Третій шар — «червоний». Це інституційні, або «племінні», знання. Вони живуть у головах людей, у фрагментах старих документів, у Slack‑тредах, у неформальних домовленостях між командами. Це відповіді на питання на кшталт: чому цей сервіс поводиться так дивно після 23:00; які саме edge‑кейси колись «підпалили» прод; чому певний API не можна чіпати в пікові години; як насправді працює інтеграція зі старою системою, яку ніхто не хоче чіпати.

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

Монолітна база знань: коли RAG і MCP не рятують

Індустрія вже кілька років пропонує стандартну відповідь на проблему інституційних знань: побудувати «retrieval layer». Підключити Confluence, Jira, SharePoint, GitHub, Slack, бази даних; накрити все це RAG‑шаром, знання‑графом або мережею MCP‑серверів; дати агенту інструменти для пошуку й витягування потрібного контексту.

На папері це виглядає як ідеальне рішення. На практиці — ні.

Радж оцінює, що за наявності більш‑менш задокументованої бази знань RAG або knowledge graph дозволяють досягти приблизно 40% фактичної точності. Це означає, що близько сорока відсотків відповідей агента, заснованих на корпоративній документації, будуть коректними за фактами. Для демо цього достатньо. Для продакшену — ні.

Проблема в тому, що сама корпоративна база знань зазвичай є монолітом із дуже низькою якістю. Радж описує типовий розклад:

Близько 20% знань — застарілі. Документи не оновлювалися роками, описують уже неіснуючі сервіси або старі версії процесів.

Ще 20% — ненадійні. Це фрагментарні нотатки, чернетки, презентації, які ніхто не валідував і не підтримує.

Ще приблизно 10% — дублікати. Одна й та сама інформація в різних версіях розкидана по різних просторах Confluence, Google Docs, внутрішніх wiki.

І нарешті, близько 40% критично важливих знань взагалі не задокументовано. Це та сама «tribal knowledge» — те, що знають конкретні люди й конкретні команди, але що ніколи не потрапляло в офіційні системи.

У такій ситуації кількість підключених джерел майже не має значення. Можна побудувати 10, 15 чи навіть 20 MCP‑серверів, як це зробив сам Радж, але якщо вони всі дивляться в один і той самий монолітний, частково гнилий масив знань, результат буде передбачуваний: недетерміновані, ненадійні й неперевірені відповіді.

20+ MCP‑серверів пізніше: чому інтеграції не працюють як очікується

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

Реальність виявилася іншою. Вихідні дані з цих інтеграцій у більшості випадків були:

недетермінованими — одна й та сама задача з однаковим контекстом могла давати різні відповіді;

ненадійними — агент часто «витягував» не ті документи, не ті версії, не ті фрагменти, які реально потрібні для задачі;

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

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

Це не означає, що RAG або MCP — хибні технології. Вони корисні, але лише настільки, наскільки корисний базовий шар знань, до якого вони підключені. Якщо цей шар — моноліт із застарілою, суперечливою й неповною інформацією, жоден retrieval‑шар не перетворить його на надійне джерело правди.

Моноліт знань як структурна проблема, а не технічний баг

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

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

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

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

Зі знаннями відбувається те саме. Монолітна база знань — це «legacy‑система» організації. Поки вона не буде розбита на менші, чітко визначені, перевірені контекстні блоки, агенти не зможуть надійно працювати з інституційною інформацією. І жоден зовнішній вендор не вирішить цю проблему за компанію: постачальники LLM зосереджені на якості моделей, ринок retrieval‑інструментів — на пошуку й індексації, але ніхто не прийде й не «перепише» ваші внутрішні знання.

Від моноліту до контекстних блоків: що потрібно агентам насправді

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

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

щоб він був актуальним — застарілі версії мають бути або видалені, або явно позначені;

щоб він був повним у межах своєї теми — не покладатися на «само собою зрозуміло» з інших, неочевидних джерел;

щоб він був пов’язаний із іншими блоками — через явні посилання, схеми, метамоделі домену;

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

Лише в такому вигляді знання стають придатними для систематичного використання агентами. RAG і MCP у цьому випадку перестають бути «пилососами» по всьому Confluence й перетворюються на механізми адресної доставки потрібних блоків у потрібний момент.

Радж наголошує: це робота, яку має зробити сама організація. Моделі будуть ставати кращими, retrieval‑інструменти — розумнішими, але без структурованої, розбитої на блоки інституційної пам’яті агенти й далі будуть упиратися в ті самі обмеження. Саме тому сьогоднішній «AI‑стек» у підприємствах часто виглядає так: блискучі моделі, модні агенти, дорогий retrieval‑шар — і монолітна, хаотична база знань під ними.

Чому 40% «племінних» знань — це не дрібна прогалина, а критичний ризик

Цифра, яку наводить Радж, — близько 40% знань у вигляді «tribal knowledge» — може здаватися абстрактною, поки не подивитися на неї через призму ризиків і вартості.

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

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

По‑третє, саме ця зона найгірше піддається класичним підходам до документації. Люди не люблять і не вміють систематично описувати те, що для них давно стало «фоновим знанням». Звідси й спокуса технічних команд: замість того, щоб боротися з монолітом знань, побудувати ще один RAG, ще один MCP, ще один «розумний» пошук. Але без зміни структури це лише ускладнює систему, не підвищуючи її надійності.

У підсумку 40% «племінних» знань — це не просто «дірка» в документації. Це системний бар’єр для будь‑яких спроб зробити AI реальним учасником робочих процесів, а не лише помічником у написанні коду.

Висновок: AI не виправить моноліт, якщо моноліт не виправити самому

Сьогоднішній стан корпоративного AI можна описати як парадокс. З одного боку, моделі досягли рівня, коли вони здатні будувати повноцінні застосунки, аналізувати складні інциденти й підтримувати інженерів у щоденній роботі. З іншого — бізнес бачить лише близько 6% реальної цінності від цих інвестицій, попри те, що 88% компаній уже «впровадили AI».

Розв’язання цього парадоксу лежить не в черговому поколінні LLM і не в новому фреймворку для агентів. Воно починається з чесної оцінки того, як влаштовані інституційні знання в організації. Поки вони залишаються монолітом із застарілою, суперечливою й частково «племінною» інформацією, будь‑які RAG‑ і MCP‑інтеграції будуть давати лише частковий, нестабільний ефект.

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

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

Джерело

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

Генеральний директор Nvidia Дженсен Хуанг вважає, що американським працівникам не варто боятися, що штучний інтелект масово позбавить їх роботи. Під час розмови з ведучою MSNBC Беккі Квік на заході, організованому економічним аналітичним центром Milken Institute, керівник Nvidia назвав ШІ «промисловим генератором робочих місць», а не провісником масового безробіття, як його часто описують так звані «AI-doomers».

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

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

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

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

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

Джерело

TechCrunch

Кооперативний екшен-спіноф Horizon Hunters Gathering проведе ще один плейтест з 22 по 25 травня. Реєстрація вже відкрита через програму PlayStation Beta Program, випробувати гру можна буде як на ПК, так і на PS5. Попередній тест відбувався наприкінці лютого.

Horizon Hunters Gathering — це мультиплеєрна гра у всесвіті Horizon. Її розробляє студія Guerrilla, відома за Horizon Zero Dawn та Horizon Forbidden West. Робота над цим спінофом триває щонайменше чотири роки — саме тоді про нього вперше з’явилася інформація.

Gathering не є пригодницькою грою з відкритим світом і фокусом на дослідження, як оригінальні частини. Це кооперативний екшен, у якому гравці полюють на вбивчі машини в дусі Monster Hunter. «Бої є тактичними, реактивними та вимагають високих навичок, спираючись на тактичну точність ігор Horizon і водночас розкриваючи динаміку командної гри», — написав директор гри Ар’ян Бак у блозі PlayStation.

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

Джерело

Engadget

Напередодні виходу торішньої Citizen Sleeper 2: Starward Vector автор гри Гарет Деміан Мартін заявляв, що завершив роботу над новими відеоіграми у всесвіті Citizen Sleeper. Замість цього Мартін пообіцяв продовжити серію у форматі настільних рольових ігор. Це виглядало логічно, адже значна частина натхнення для Citizen Sleeper та Citizen Sleeper 2 прийшла з настільних RPG на кшталт Blades in the Dark. І Мартін швидко дотримався обіцянки, випустивши Spindlejack — безкоштовну соло-гру, дія якої відбувається на одній зі станцій, доступних гравцям у CS2, — вже за кілька місяців. Як фанат серії, я думав, що на цьому новий контент із Citizen Sleeper на деякий час закінчиться, але сьогодні Мартін оголосив, що працює над абсолютно новою настільною грою Citizen Sleeper: Helion Rising.

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

Якщо коротко, Helion Rising має перетворити світ Citizen Sleeper на досвід, яким можна поділитися з друзями за столом. Якщо ви ще не грали у відеоігри серії, дуже раджу це зробити: в них розповідаються справді захопливі історії про те, як знаходити спільноту й важливі зв’язки в, здавалося б, безнадійних ситуаціях. Обидві частини зараз продаються зі найбільшими знижками за весь час у Steam та інших цифрових крамницях.

У будь-якому разі, Мартін пообіцяв поділитися додатковими подробицями про Helion Rising пізніше цього року. Він також натякає на інші спін-офи Citizen Sleeper, але поки що не розкриває, якими саме вони будуть. І нарешті, 7 червня Мартін покаже нову відеогру, над якою працює з моменту виходу CS2, описуючи її як «цілком новий проєкт у новому світі, над яким я працюю вже багато років». Чекаємо з нетерпінням.

Джерело

Engadget

Підприємець Алекс Хормозі, співзасновник Acquisition.com із понад $250 млн річного виторгу, відкрито називає штучний інтелект своїм пріоритетом №1 у бізнесі. Але замість гонитви за «найкращою моделлю» він робить ставку на інше: на власні дані як головний конкурентний мур. У розмові, яку розібрав технопідприємець і контент‑креатор Остін Марчезе, проступає чітка стратегія: модель може бути будь-якою, справжня перевага — у тому, чим її годують.

Цей підхід уже втілено в продукті AC AI, який Хормозі побудував на базі десятків мільйонів доларів реального консалтингового досвіду. Паралельно Марчезе повторює ту саму логіку у власному бізнесі, створюючи «AI-клон» себе для команди. У центрі обох історій — одна ідея: дані як особистий і корпоративний актив, який перетворює загальнодоступні моделі на унікальний інструмент.

Модель — не мур. Мур — це те, що ви в неї заливаєте

У публічних поясненнях Хормозі послідовно розводить два рівні: інфраструктуру AI та дані, на яких вона працює. Моделі — від Claude до GPT — стають дедалі доступнішими, дешевшими й більш взаємозамінними. Те, що ще вчора здавалося проривом, сьогодні можна отримати через API за копійки. У такому світі важко будувати довгострокову перевагу лише на виборі «правильної» моделі.

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

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

AC AI: $31 млн консалтингу, упаковані в систему впровадження

Найочевидніше втілення цієї філософії — продукт AC AI. Формально це ще один AI‑інструмент для бізнесу. Фактично — інтерфейс до приватної бази знань, яку неможливо відтворити без доступу до досвіду Хормозі.

За даними продуктового опису, AC AI тренується на понад $31 млн консалтингових даних, зібраних із 1 026 реальних бізнесів. У систему завантажені тисячі внутрішніх консалтингових нотаток, рішень і, головне, фактичних результатів: що було зроблено, що спрацювало, що провалилося. Це не теоретичні кейси з книжок, а закриті робочі матеріали, які ніколи не потрапляли у відкритий доступ.

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

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

AI-клон засновника: як Хормозі масштабує себе через дані

Ще один шар цієї стратегії — персональний. Хормозі цілеспрямовано записує й документує власні знання з однією метою: створити «AI-клон» себе, доступний команді.

Логіка проста. Засновник — вузьке місце в будь-якій компанії. До нього йдуть із питаннями про стратегію, позиціонування, формулювання офферів, оцінку ризиків. Коли ж усі ці рішення, аргументи й міркування систематично фіксуються, а потім потрапляють у AI‑систему, команда отримує можливість «звертатися» до версії засновника, яка доступна 24/7 і масштабується без його фізичної присутності.

У випадку Хормозі це не метафора. Він буквально перетворює власні нотатки, розбори, консультації та внутрішні матеріали на тренувальний корпус. Коли співробітники працюють із AC AI, вони фактично консультуються з агрегованою версією його досвіду, а не з абстрактним «штучним інтелектом». Це дозволяє йому бути «в нескінченній кількості місць одночасно» — формулювання, яке добре передає задум: не замінити людину, а розмножити її судження.

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

Власний AI для контенту: як Марчезе повторив стратегію на менших масштабах

Остін Марчезе, який розбирав систему Хормозі, застосував ту ж логіку у власному бізнесі контент‑продакшену. Він керує командою, що відповідає за різні канали — від YouTube до LinkedIn і розсилок. Сценарії для відео він пише сам, але інші формати делегує. Проблема була типовою: команда постійно поверталася з питаннями «як ти це бачиш», «який у тебе погляд на тему», «як би ти це сформулював».

Щоб розв’язати це, Марчезе побудував власну AI‑систему, яку навчив на своєму ж контенті й робочих матеріалах. У неї він завантажив записи консалтингових дзвінків, дослідницькі нотатки, власні фреймворки, сценарії відео — усе, що відображає його стиль мислення й аргументації. Тепер замість того, щоб чекати відповіді від нього, команда звертається до цієї системи й отримує відповіді, узгоджені з його підходом.

Це, по суті, той самий «AI-клон», але на рівні контент‑бізнесу. Важливо, що Марчезе не має доступу до $31 млн консалтингових даних, як Хормозі. Але принцип працює й без цього: достатньо системно збирати власні артефакти — від розмов до чернеток — і перетворювати їх на тренувальний корпус. Модель може бути стандартною, але дані роблять її «своєю».

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

Як побудувати власний «data moat», навіть якщо ви не Хормозі

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

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

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

Перший — запис зустрічей. На ринку багато сервісів, які обіцяють автоматичні to‑do, резюме й «розумні» інсайти. Хормозі відкидає маркетинговий шар і фокусується на головному: отримати повний транскрипт розмови. Саме текст зустрічі — із питаннями, запереченнями, аргументами — є цінним тренувальним матеріалом. Його можна завантажити в систему й поступово навчати модель на реальних діалогах, а не на вигаданих сценаріях.

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

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

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

Дані як новий вид капіталу

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

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

У цьому контексті порада «дані — ваш мур» звучить не як абстракція, а як практичний план дій. Поки більшість користувачів сприймає AI як розумніший пошук, Хормозі й Марчезе будують над ним власні шари — із приватних, важко відтворюваних знань. І саме ці шари, а не вибір між Claude чи GPT, можуть стати тим, що відрізняє їхні бізнеси від усіх інших у найближчі роки.

Висновок

Стратегія Алекса Хормозі щодо AI починається не з моделі, а з питання: які унікальні дані ми маємо й як можемо їх зафіксувати. AC AI — це приклад того, як десятки мільйонів доларів консалтингового досвіду перетворюються на продукт, що продає не інформацію, а впровадження. Особисті AI‑клони, які будують і він, і Остін Марчезе, показують, як та сама логіка працює на рівні окремого засновника чи експерта.

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

Джерело

How Alex Hormozi ACTUALLY Uses AI — Austin Marchese

У світі, де штучний інтелект робить складні навички доступними «з коробки», ключовою перевагою стає не вміння програмувати чи проєктувати, а здатність діяти — особиста агентність. На це звертають увагу співрозмовники подкасту Lenny’s Podcast, розмірковуючи про те, як змінюється роль людини в новій технологічній реальності.

Коли навички більше не виправдання

Довгий час було зручно пояснювати власну бездіяльність браком компетенцій: «я ніколи не зможу це зробити, бо не вмію X». Сьогодні генеративні моделі на кшталт ChatGPT чи Claude Code знімають частину цих обмежень: складні знання та інструменти опиняються «на відстані запиту».

У такому середовищі виявляється, що вирішальним фактором стає не сам набір навичок, а готовність ними скористатися. Якщо інструменти вже «під рукою», питання звучить інакше: чи є внутрішня установка щось змінювати, пробувати, запускати?

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

Агентність розподілена нерівномірно

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

Водночас така впевненість у власному впливі на події — агентність — розподілена дуже нерівномірно. Частина людей живе з відчуттям, що може переписувати правила гри, інші — що можуть лише підлаштовуватися під уже наявні.

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

Від «обійти систему» до «створити своє»

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

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

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

Як розвивати агентність у цифрову добу

У середовищі, де ШІ знімає бар’єри входу в багато професій, розвиток агентності стає стратегічною навичкою. З практичної точки зору це означає:

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

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

Джерело

Agency isn’t evenly distributed — Lenny’s Podcast

Українське техношоу УТ-2 у свіжому випуску обговорює хвилю нових кібератак — від дивного шкідливого коду в науковому софті до небезпечної вразливості в ядрі Linux і болючого питання: чому Docker створює ілюзію безпеки, а не саму безпеку. На тлі історій про старі Windows, сучасні експлойти й практики захисту інфраструктури вимальовується тривожна картина: атаки стають дедалі більш таргетованими й витонченими, а наші звичні захисні рефлекси часто виявляються застарілими.

FAS16 і «невидимий» саботаж: коли malware не краде, а псує науку

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

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

Шкідливий код підміняв одну з бібліотек Windows, через яку проходили розрахунки. Замість того, щоб змінювати сам FAS16 або масово заражати систему, malware працював точково: перехоплював виклики до бібліотеки, змінював логіку обчислень і повертав уже спотворені результати. Зовні все виглядало коректно: програма запускалася, дані оброблялися, файли зберігалися. Але всередині формули давали «трохи не ті» значення.

Це не випадковий баг і не халатність розробників. Це саме цілеспрямований науковий саботаж. Важливо, що шкідливе ПЗ не було частиною FAS16 як такого — воно активувалося лише за наявності конкретного ПЗ і конкретного середовища. Тобто хтось витратив чималі зусилля, щоб створити вузькоспеціалізований інструмент, який:

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

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

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

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

Вузькоспеціалізований malware: нова норма замість масових вірусів

Malware для FAS16 показує важливий тренд: атаки стають дедалі більш вузькоспеціалізованими. Це не «черв’як», який розповзається по всьому інтернету, а інструмент, який чекає дуже конкретних умов.

У цьому випадку шкідливий код:

• активується лише тоді, коли в системі присутній FAS16;
• не чіпає інші програми;
• працює через підміну однієї Windows-бібліотеки, а не через модифікацію десятків файлів.

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

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

На цьому тлі стає зрозуміло, чому експерти говорять про «нову хвилю» кібератак, яку порівнюють із 1990-ми, коли одна за одною з’являлися вразливості типу buffer overflow. Тоді головною проблемою була технічна неграмотність у поводженні з пам’яттю. Сьогодні — складність і глибина стеку технологій, на якій будуються критичні системи, і поява інструментів (включно з AI), що полегшують пошук і експлуатацію таких нішевих дірок.

Дірка в ядрі Linux: 768 байт коду проти всієї моделі безпеки

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

Йдеться про баг, пов’язаний із криптографічним модулем ядра та системним викликом splice. Комбінація цих механізмів дозволяла робити те, що в нормальній моделі безпеки вважається неможливим: підміняти вміст page cache — кешу сторінок пам’яті, де ядро тримає дані файлів, — не змінюючи самі файли на диску.

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

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

• знайти в page cache потрібний виконуваний файл, наприклад su;
• змінити в ньому кілька байтів — наприклад, у місці перевірки пароля чи прав доступу;
• отримати ескалацію привілеїв до root.

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

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

• відключити відповідний криптомодуль, якщо він не критичний для навантаження;
• оновити ядро до версії, де баг уже виправлено.

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

Docker як ілюзія безпеки: коли контейнер — це не стіна, а шторка

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

Вразливість із підміною page cache демонструє це особливо наочно. Якщо в ядрі є така дірка, то:

• код усередині контейнера може скористатися нею;
• експлойт працює на рівні ядра, а не user space;
• у результаті з контейнера можна отримати root-доступ до всієї хост-системи.

Тобто Docker не є повноцінним механізмом безпеки. Це зручний інструмент для ізоляції процесів, розгортання й масштабування, але не бар’єр, який можна вважати достатнім захистом від атак. Якщо адміністратор виходить із припущення «контейнер = sandbox», він уже програє.

На практиці це означає кілька речей.

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

По-друге, модель довіри до контейнерів має бути переглянута. Якщо в інфраструктурі є можливість запуску довільного коду в контейнері (наприклад, multi-tenant середовище, CI/CD для зовнішніх репозиторіїв, платформи на кшталт PaaS), то кожен такий контейнер потенційно може стати плацдармом для атаки на хост.

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

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

Jumpbox як мінімум здорового глузду: як захищають продакшн сьогодні

На тлі історій про таргетований саботаж і дірки в ядрі особливо актуальним стає питання: що реально роблять команди, щоб захистити продакшн-інфраструктуру?

Одна з практик, яка давно прижилася в серйозних компаніях, — використання jumpbox-серверів. Ідея проста: замість того, щоб відкривати SSH-доступ безпосередньо на всі продакшн-сервери, зовнішній доступ дозволяється лише на один або кілька спеціальних вузлів — jumpbox’и. Уже з них адміністратори підключаються до внутрішніх машин.

Це не панацея, але дає кілька важливих переваг.

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

По-друге, спрощується контроль доступу. На jumpbox можна накласти жорсткі політики: обов’язковий MFA, обмеження за IP, детальний логінг усіх сесій, інтеграцію з корпоративними системами ідентифікації. Внутрішні сервери при цьому можуть бути взагалі недоступні з інтернету.

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

У світі, де з контейнера можна вийти в ядро, а з ядра — у весь хост, подібні базові практики стають не просто «enterprise-ритуалом», а необхідним мінімумом. Особливо якщо врахувати, що сучасні атаки часто комбінують кілька векторів: спочатку компрометація облікового запису, потім — використання вразливості в ядрі, далі — горизонтальний рух по інфраструктурі.

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

Висновок: безпека більше не про «патчі раз на квартал»

Історії про malware у FAS16, вразливість page cache у Linux і ілюзію безпеки Docker показують одну спільну рису сучасної кіберреальності: атаки стають глибшими, тихішими й більш таргетованими, а наші звичні уявлення про безпеку часто не встигають за ними.

Науковий саботаж через підміну Windows-бібліотеки в нішевому софті демонструє, що навіть інструменти для симуляцій можуть стати полем бою. Дірка в ядрі Linux, яку можна експлуатувати скриптом на 768 байт, нагадує, що фундаментальні компоненти системи — не менш вразливі, ніж веб-фреймворки. А Docker, який багато хто сприймає як «коробку з піском», насправді лише тонка шторка поверх спільного ядра.

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

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

Джерело

Гейб радує Лінуса, GitHub губить ваш код, і чому RAG більше не потрібен. Все горить. mvc #27