Четвер, 11 Червня, 2026
Додому Блог

Як міряти якість генеративних систем: LM‑судді, болючі eval-и й роль людського «смаку»

0

У 999‑му епізоді подкасту Super Data Science авторка бестселера AI Engineering Чіп Хуєн обговорює одну з найменш «гламурних», але ключових тем сучасних LLM‑продуктів — оцінювання їхньої якості. Вона стверджує, що без якісних eval‑ів ви буквально не знаєте, чи ваша система працює, пояснює, чому класична парадигма тест‑драйвен розробки ламається на генеративному виході, і розповідає, як спроби покластися на «LM‑як‑суддю» перетворюються на болючу роботу з гайдами й інструкціями.

Від test‑driven до evaluation‑driven: чому без вимірювання немає розробки

У традиційній розробці софту десятиліттями домінувала ідея test‑driven development: спочатку пишемо тести, потім — код під них. Якщо функція повертає не той рядок символ у символ, тест падає, і проблема очевидна.

З генеративними моделями така схема руйнується. Відповідей на одне й те саме запитання може бути багато, і всі вони можуть бути «правильними» у різному ступені. Це робить старі підходи малопридатними.

Хуєн проводить пряму аналогію: для AI потрібна власна парадигма — evaluation‑driven development. Йдеться не про окремі експерименти у ноутбуку, а про систематичне, вбудоване в життєвий цикл продукту оцінювання моделей:

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

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

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

Чому генеративний вихід «ламає» класичні тести

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

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

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

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

LM‑як‑суддя: приваблива ідея з болючою реалізацією

На цьому тлі багато команд звертаються до популярної сьогодні практики LM‑as‑a‑judge. Логіка проста: раз вже LLM добре розбирається в текстах, чому б не доручити їй оцінювати відповіді іншої (або тієї ж) моделі? Друга модель читає вхід, вихід і виставляє оцінку — здається, автоматизація проблеми.

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

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

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

Основні вузли цієї болю:

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

Гайди для AI‑суддів: як не потонути у власних інструкціях

Що робити, якщо LM як суддя все одно потрібна? Хуєн пропонує дуже приземлену, але рідко виконувану практику: ставитися до гайдлайна як до продукту, що має проходити «юзер‑тестування».

Вона радить після написання гайду зробити дві прості речі.

По‑перше, самому спробувати бути «моделлю‑суддею». Взяти guideline, пройти кілька прикладів і подивитися, чи здатні ви, як людина, стабільно слідувати власним інструкціям і приходити до послідовних оцінок. Якщо навіть вам це важко, від моделі чекати послідовності не варто.

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

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

Іншими словами, LM‑суддя не звільняє від роботи з якістю — він лише переносить її в інший шар: дизайн інструкцій, тестування цих інструкцій людьми, пошук і усунення протиріч.

Невидимий ризик: AI‑система без валідних метрик

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

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

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

Саме тому вона наполягає на evaluation‑driven підході: «є лише обмежена кількість застосунків, де ви не можете виміряти вихід». У всіх інших випадках відсутність якісних eval‑ів — це вибір, а не неминучість.

Людський контроль як останній бар’єр

Ще одна важлива думка Хуєн стосується довіри до автоматизованих eval‑ів. Навіть якщо здається, що написаний промпт для судді‑моделі ідеальний, цього недостатньо, щоб просто «повірити» її оцінкам.

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

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

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

Висновок: без болючих eval‑ів ми не знаємо, що будуємо

Розмова з Чіп Хуєн демонструє, що в епоху foundation‑моделей головна складність часто лежить не в самому inference, а в тому, як ми міряємо результат.

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

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


Джерело

Super Data Science: What’s Left to Build When Software Is Free (with Chip Huyen)

Стартуй просто: prompting, RAG, а fine-tuning — в самому кінці

0

AI-інженерка та авторка бестселерів O’Reilly Chip Huyen у розмові з подкастом Super Data Science розбирає те, що сьогодні турбує майже кожну команду, яка будує продукти на LLM: як саме структурувати воркфлоу, коли достатньо «розумного» промпта, коли вже потрібен RAG, а коли — все‑таки час йти у власний fine‑tuning. І чому більшість складних систем ламаються задовго до того, як «дійде» до налаштування ваг моделі.

Fine‑tuning як «останній рубіж», а не стартова точка

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

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

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

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

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

Тому Huyen пропонує дивитися на fine‑tuning прагматично: як на дорогий, складний інструмент, виправданий лише тоді, коли всі інші шари системи — інструкції, контекст, інструменти — справді вичерпані.

«Я ледача, тому стартую просто»: чому складність шкодить

Центральний принцип, який Huyen пропонує як протиотруту до інстинкту «зробити відразу складну систему», звучить просто: start simple.

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

Якщо у продакшні одночасно працюють складний промпт, RAG‑шар з купою евристик, кілька інструментів, веб‑пошук і ще й fine‑tuned‑модель, будь‑яка помилка перетворюється на детектив: де саме все зламалося? У витягу контексту, у промпті, у функціональному виклику, у самій моделі?

Huyen наполягає: спочатку потрібно добре зрозуміти, як система поводиться в максимально простій конфігурації, і лише потім нарощувати складність шарами. Її підхід: подивитися, де саме система «провалюється», і реагувати на конкретні failure cases, підбираючи мінімально достатнє доповнення — замість того, щоб одразу будувати багатошаровий «замок» з RAG, fine‑tuning і агентичних фреймворків.

Сила промпта: від «на відчепись» до продуманої інструкції

У цій ієрархії промпт — перший і найдешевший інструмент. І його, на думку Huyen, системно недооцінюють.

Вона каже, що «prompting can actually take you pretty far» і що різниця між «напів‑якось» написаним промптом і тим, над яким справді ретельно працювали, — «huge». Перефразовуючи, у великій кількості застосунків можна «вичавити» суттєве зростання якості без жодного коду чи навчання, лише через продуману інструкцію.

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

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

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

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

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

Коли не вистачає знань: контекст, документи й RAG

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

Рішення — забезпечити модель правильним контекстом. Один з варіантів — передавати релевантні документи (транскрипти, внутрішні матеріали, бази знань), до яких LLM може звертатися при відповіді. Інший — надати доступ до інструментів, наприклад до веб‑пошуку, щоб модель могла самостійно знаходити потрібну інформацію.

Саме тут починається шар, який часто називають RAG (retrieval‑augmented generation), хоча Huyen у розмові не заглиблюється в терміни, а описує його через практичні елементи: надання документів, індекси, пошук, вибір релевантних фрагментів.

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

Веб‑пошук: найболючіша стаття витрат

Окрема тема — веб‑пошук як джерело контексту. Huyen називає його «painfully expensive» і таким, що змушує боятися запускати моделі через вартість токенів.

Вона наводить досвід експериментів із «ринковими» завданнями, де просила агентів робити глибоке дослідження певного ринку й формувати прогнози. Одна така сесія могла коштувати долар, а іноді й два — і значна частина вартості припадала саме на веб‑пошук. В одному з запитів агент відвідав близько тисячі URL‑ів, але, як виявилося при аналізі, унікальними були лише приблизно двадцять. Решта — повтори.

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

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

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

Хоча ця тема у розмові виходить за межі чистого ланцюжка «prompting → RAG → fine‑tuning», вона добре підкреслює головну лінію Huyen: перш ніж ускладнювати технічну систему, варто зрозуміти, де насправді виникають витрати й збої.

Коли все ж таки час для fine‑tuning

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

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

У підсумку її підхід до побудови LLM‑систем можна сформулювати як поетапне «вичавлювання» якості з кожного шару перед тим, як переходити до наступного:

спочатку — серйозна робота над промптом, включно з його регулярним очищенням від суперечностей;
далі — системне надання контексту, документи, інструменти, RAG‑шар;
лише потім — fine‑tuning як відповідь на ті обмеження, які справді неможливо обійти іншими засобами.

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


Джерело

Super Data Science: What’s Left to Build When Software Is Free (with Chip Huyen)

Як пришвидшити роботу Windows 11 на старих комп’ютерах вимкненням прозорості та анімації

0

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

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

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

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

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

AI engineering проти ML engineering: де тепер справжня робота

0

Роль інженерів у штучному інтелекті за останні два роки змінилася радикальніше, ніж за попереднє десятиліття. Про це відверто говорить Чіп Хюєн — інженерка, підприємниця та авторка бестселерів “Designing Machine Learning Systems” і “AI Engineering”, яка очолює рейтинги O’Reilly. У розмові з ведучим подкасту Super Data Science Джоном Кроном вона пояснює, чому класичний ML engineering більше не є центром всесвіту, як народився окремий напрям AI engineering і чому системний дизайн раптом став головною навичкою для тих, хто хоче лишатися потрібним.

Від моделей з нуля до «модель як сервіс»

Класичний образ machine learning engineer формується довкола однієї задачі: збудувати модель. Це означало повний цикл — від сирих даних до продакшн‑сервісу.

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

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

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

Не «AI vs ML», а «яку проблему ви розв’язуєте»

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

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

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

Хюєн наводить типовий приклад: клієнтський чат‑бот. Генеративна модель — не єдине, що там працює, і далеко не завжди перше, до чого варто звертатися. Є крок перед нею: перевірити, чи запит взагалі релевантний продукту, чи не варто його відфільтрувати, чи достатньо віддати статичну сторінку з FAQ.

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

У підсумку роль інженера зміщується з «обрати стека» до «скласти правильну комбінацію» під конкретну бізнес‑проблему.

Як виглядає сучасна AI‑система: багато компонентів, одна відповідальність

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

На прикладі того ж саппорт‑бота видно типовий шаблон AI‑engineering сьогодні:

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

Далі, для частини запитів достатньо взагалі не звертатися до LLM: якщо йдеться про «як змінити пароль», можна просто повернути посилання на релевантний розділ FAQ. Для цього знову можна застосувати окремий класифікатор, який мапить запит до бази знань.

Лише запити, які справді потребують гнучкого, контекстно‑залежного міркування, йдуть до великої моделі. І вже навколо неї з’являються інші AI engineering‑теми: промпти, контекст, пам’ять, guardrails.

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

Тут і проявляється розрив між ML та AI engineering: перший сфокусований на якості окремої моделі, другий — на тому, як модель вбудована в потік подій, даних і рішень.

Інженер — це не «той, хто пише код»

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

Її шлях до системного мислення почався задовго до хайпу навколо ChatGPT. Ще у 2018–2019 роках, коли вона викладала курс по TensorFlow, швидкий прогрес фреймворків став для неї болісним досвідом: виходила нова версія, і «доводилося переробляти 80% туторіалів». Це підштовхнуло її до питання: які знання швидко старіють, а які — стійкіші?

Після розмов з колегами й практиків вона «приземлилася» на системному мисленні та дизайні систем. Саме це лягло в основу її конспектів з design of machine learning systems, які перетворилися на популярний GitHub‑репозиторій, потім — на курс у Стенфорді, а далі — на книгу.

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

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

Системний дизайн в епоху foundation‑моделей

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

Це не абстрактна порада, а практична відповідь на нову реальність:

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

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

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

Усі ці фактори роблять системний дизайн центральною компетенцією AI‑інженера. Не лише розуміти, як працює LLM, а й проєктувати, як вона:

  • взаємодіє з класичними моделями,
  • споживає зовнішні сервіси (від веб‑пошуку до внутрішніх API),
  • використовує пам’ять, кеші, бази знань,
  • вписується у вже наявну інфраструктуру компанії.

Де тепер «справжня робота» інженера

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

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

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

У цій картині ML engineering не зникає — він стає частиною більшого полотна. Дешеві, сфокусовані моделі продовжують відігравати важливу роль, але як елементи системи, а не самоціль. А AI engineering стає дисципліною про зв’язки: між моделями, сервісами, даними, користувачами та часом.

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

Джерело

YouTube: What’s Left to Build When Software Is Free (with Chip Huyen)

Google зберігатиме ваші фото з Lens, записи Search Live та аудіо з Translate для тренування штучного інтелекту

0

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

Це охоплює фотографії, які користувачі шукають за допомогою Google Lens, записи з інструменту реального часу Search Live, голосові запити та фрази, введені через Translate. Користувачі мають можливість вимкнути функцію “Історія пошукових сервісів” та відповідну опцію “Зберегти медіа”, якщо вони не бажають, аби ці взаємодії зберігалися.

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

Для тих, хто вже обмежив збереження історії пошуку через “Активність у мережі та додатках”, функція “Історія пошукових сервісів” залишиться вимкненою після переходу. Персоналізовані налаштування також будуть збережені при впровадженні цих змін протягом “найближчих місяців”.

Чому веб‑пошук робить AI‑агентів нестерпно дорогими

0

У подкасті Super Data Science AI‑інженерка та авторка бестселера «AI Engineering» Чіп Хюєн обговорює практичні пастки запуску LLM‑систем у продакшн. Один з найяскравіших фрагментів розмови — про те, чому саме веб‑пошук перетворює AI‑агентів на фінансову чорну діру, навіть коли сама «розумова робота» моделі коштує відносно недорого.

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


«Боляче дорого»: коли веб‑пошук дорожчий за мислення моделі

Чіп Хюєн прямо формулює проблему: веб‑пошук у зв’язці з LLM «extremely expensive… painfully expensive… it makes me scared to run my model because of token consumption». Йдеться не про самі виклики моделі, а про те, що відбувається, коли до неї додають агента з доступом до інтернету.

У своєму експерименті вона досліджувала, чи можуть AI‑агенти аналізувати ринок. Запит був типовий для «розумного» агента: «Given this market do a bunch of research… and make predictions on the outcome of this market». Результат — шокуючий навіть для досвідченої інженерки:

  • кожен запит обходився орієнтовно в долар,
  • іноді «Claude was like $2» за одну дослідницьку задачу.

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

При цьому, як підкреслює Хюєн, «the actual reasoning [is] a lot cheaper», а головний драйвер вартості — «use new tokens»: веб‑пошук, файловий пошук, інтеграції з сервісами на кшталт пошти чи месенджерів. Саме вони роздувають токенні рахунки, а не те, що модель формує відповідь.


Тисяча URL‑ів, з яких унікальних — лише двадцять

Справжній масштаб марнотратства відкрився, коли Хюєн подивилася на те, що саме роблять агенти «під капотом». В одному з запитів агент, досліджуючи ринок, «visited like a thousand URLs… a thousand web page». Здавалося б, ґрунтовне дослідження. Але аналіз показав інше:

«Out of this thousand web pages only 20 of them are unique».

Інакше кажучи, близько 980 звернень пішли на сторінки, які агент уже відкривав. Далі — ще гірше: «this agent like keep revisiting a web page over and over again». Причина тривіальна, але дорога: для одного й того самого завдання агент генерує багато пошукових запитів:

спочатку, умовно, «Super Data Science podcast», потім «Super Data Science podcast guests» тощо. Різні формулювання повертають той самий набір URL‑ів, але агент це не усвідомлює й «might visit… over and over».

Кожне таке «повторне відкриття» — це:
– запит до пошукового API,
– парсинг фрагменту сторінки,
– додаткові токени для аналізу.

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


Кеш не рятує: як пошукові системи ріжуть веб‑сторінки на шматки

На перший погляд, ситуація кричить: «це ж ідеальна задача для кешування». Хюєн сама пройшла цей логічний крок: «it sounds like an opportunity for caching». Але, коли вона глибше подивилася на те, як влаштовано веб‑пошук, виявилось, що все складніше.

Пошукові системи, пояснює вона, організують дані «based on data chunk». Коли ви надсилаєте запит, движок:
– знаходить релевантний сайт,
– але «surface the part of the website that is most related to the query».

Тобто «when you do search you don’t retrieve the whole web page, you retrieve the part of the web page that’s relevant to you». Два різні запити до тієї самої сторінки можуть повертати зовсім різні текстові фрагменти. І з погляду кешу це вже не «той самий ресурс», а інший шматок контенту з іншою семантикою.

Додайте сюди ще один шар складності, на який звертає увагу Хюєн: «there’s a whole part about… how you decide the freshness [of] information». Для новинної теми сторінка дворічної давнини практично марна, а запит типу «what is an embedding» може спокійно опиратися на матеріал п’ятирічної давнини. Це означає, що:

  • десь кеш застаріває критично швидко,
  • десь — майже не старіє,
  • але універсальної політики для всіх сценаріїв немає.

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


Системні промпти як дзеркало хаосу веб‑пошуку

Ще одна цікава оптика Хюєн — погляд на системні промпти популярних сервісів. Вона спеціально дивилася «at a system prompt of a lot of these services… like GPT or Claude» і звернула увагу:

«You will see that they have like a really really big section just trying to get the model to do web search».

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

У цих промптах, за її словами, вручну прописано, що для одних типів запитів можна використовувати дані тижневої давнини, для інших — лише найновіші. «It is very… still very much manual», резюмує вона. Це не акуратна, елегантна система правил, а радше наростаючий шар патчів, яким намагаються компенсувати слабкі місця моделей у роботі з вебом.

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


Вартість токенів як новий простір для інновацій

На фоні всіх цих проблем Хюєн не звучить фаталістично. Навпаки, вона вважає, що «there’s still a lot of room for improvement in how to make web search more efficient». І чітко розводить два типи витрат:

  • обчислення для reasoning — порівняно дешеві;
  • все, що стосується «use new tokens» — основне джерело болю.

До «нових токенів» вона відносить не лише веб‑пошук, а й широкий клас «productivity tools», які інтегруються з Gmail, Slack, Asana й іншими сервісами. Кожен виклик API, кожне читання листа чи повідомлення, кожен розбір результатів — це нові токени, які потрібно оплатити.

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

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

Поки цього немає, компанії змушені миритися з тим, що «each of the requests cost… like a dollar», а агенти знову й знову відвідують ті самі сторінки — часто навіть не усвідомлюючи цього.


Висновок: де цінність для інженерів, коли пошук все з’їдає

Розмова з Чіп Хюєн показує: найбільший ворог економіки AI‑агентів сьогодні — не глибина моделей, а банальна неефективність у роботі з вебом. Веб‑пошук:

  • генерує лавину повторних запитів,
  • погано масштабується через фрагментовані «чанки» сторінок,
  • вимагає гігантських, ручно написаних системних промптів,
  • і врешті робить розумних агентів «painfully expensive».

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


Джерело

Подкаст Super Data Science, епізод 999, «What’s Left to Build When Software Is Free (with Chip Huyen)»
https://www.youtube.com/watch?v=vi6UILzThgo

Добірка найшвидших портативних акумуляторів 2026 року з потужністю від 200 ват (на всі порти)

0

Сучасні портативні акумулятори стали необхідним доповненням до гаджетів, оскільки здатні підтримувати роботу смартфонів та ноутбуків без доступу до електромережі. Більшість моделей високого класу сьогодні використовують технологію USB Power Delivery 3.1, що дозволяє передавати до 240 ват енергії через порти USB-C. Пристрої з потужністю від 200 ват та ємністю акумулятора понад 20 000 міліампер-годин дозволяють одночасно заряджати кілька енергоємних гаджетів, залишаючись при цьому придатними для транспортування в літаках.

Першим у списку є Anker Power Bank ємністю 20 000 міліампер-годин та потужністю 200 ват, що має три порти для підключення. Цей пристрій забезпечує до 100 ват на один порт, дозволяючи зарядити 16-дюймовий MacBook Pro до 50 відсотків за 40 хвилин, а повна зарядка самого акумулятора займає близько 75 хвилин. Користувачі можуть відстежувати стан енергоспоживання через вбудований цифровий дисплей, а вартість гаджета становить 139,99 доларів США на платформі Best Buy.

UGreen Portable Power Station виділяється великою ємністю 48 000 міліампер-годин та п’ятьма портами, що дає змогу одночасно живити кілька ноутбуків і смартфонів. Завдяки підтримці USB Power Delivery 3.1, один із портів видає до 140 ват потужності, а загальний показник сягає 300 ват. Використання літій-залізо-фосфатних акумуляторів LiFePO4 дозволяє зберегти 80 відсотків ємності навіть після 3 000 циклів заряду, а ціна цього пристрою на офіційному сайті складає 169,99 доларів.

UGreen Nexode Power Bank ємністю 25 000 міліампер-годин видає 200 ват загальної потужності. Один із портів USB-C підтримує швидку зарядку 140 ват, що дозволяє зарядити 16-дюймовий ноутбук на 54 відсотки за 30 хвилин. Модель оснащена системою захисту ThermalGuard та вогнетривким корпусом, а для повної зарядки акумулятора від 65-ватного блоку потрібно близько 2 годин. Пристрій оцінений у 129,99 доларів та має високий рейтинг користувачів на рівні 4,8 зірок.

Anker Prime Power Bank на 26 250 міліампер-годин забезпечує загальну вихідну потужність 300 ват та підтримує одночасне заряджання двох MacBook Pro та iPhone. При використанні спеціальних 5-амперних кабелів два порти USB-C можуть видавати до 140 ват кожен. Через мобільний додаток можна налаштовувати параметри подачі енергії, а вартість цього портативного рішення складає 229,99 доларів, що є одним із найбільш високих показників у сегменті за швидкістю та продуктивністю.

Ще одна модель від Anker, Prime Power Bank ємністю 27 650 міліампер-годин, видає 250 ват потужності та коштує 179,99 доларів. Завдяки підтримці швидкої зарядки 140 ват, акумулятор можна повністю зарядити за 40 хвилин при використанні двох портів USB-C. Додатково передбачено функцію пошуку пристрою через Bluetooth, що видає звуковий сигнал. Понад 3 480 відгуків на Amazon підтверджують затребуваність цієї моделі серед користувачів, які часто подорожують з багатьма гаджетами.

Denvix PowerX 4-в-1 пропонує чотири способи заряджання, включаючи магнітну бездротову панель на 15 ват та два порти USB-C з потужністю до 140 ват. Ємність акумулятора складає 25 000 міліампер-годин, а система штучного інтелекту контролює температуру для запобігання перегріву. Пристрій вартістю 179,99 доларів оснащений OLED-дисплеєм з функцією автоповороту, що відображає дані про вхідну та вихідну потужність, а також рівень залишку заряду в реальному часі.

Apple випустить складаний iPhone лише в одному кольорі, щоб не ускладнювати виробництво

0

Зважаючи на те, що більшість уваги останнім часом зосереджена на нових функціях iOS та оновленому macOS, найцікавіша новинка від Apple, ймовірно, з’явиться дещо пізніше, очікується, що компанія представить свій перший складний iPhone у вересні цього року. Чутки про такий пристрій циркулюють вже не перший рік, і хоча деякі анонсовані продукти Apple ніколи не бачать світла, наприклад, Apple HDTV чи електромобіль, численні витоки з достовірних джерел вказують на високу ймовірність виходу складного iPhone.

Більше того, з’явилися детальні витоки, що стосуються специфікацій, а також фотографії, які, як стверджується, демонструють зовнішній вигляд готового продукту. Останні дані свідчать про те, що складний iPhone від Apple може бути випущений лише в одному кольорі. Відомий викривач інформації Сонні Діксон опублікував фотографії макета iPhone Fold, де зазначено, що “не схоже, аби Apple пропонувала кілька кольорів, наразі білий виглядає як єдиний доступний варіант”.

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

Такий підхід відповідає історичній практиці Apple, яка полягає в спрощенні виробництва та мінімізації кількості SKU при запуску нових продуктів, як це було з ранніми версіями iPhone та iPod, що випускалися лише в одному кольорі, з подальшим поступовим розширенням палітри. Тому, якщо ви мрієте про яскраво-помаранчевий складний iPhone, ймовірно, доведеться зачекати кілька років, а будь-які відмінності між моделями, швидше за все, будуть стосуватися лише обсягу вбудованої пам’яті.

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

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

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

Чому «спеки», а не промпти: перший шар методу Карпаті для роботи з Claude

0

У 2026 році Андрій Карпаті, колишній керівник AI у Tesla, запропонував підхід до роботи з великими мовними моделями, який різко контрастує з типовою культурою «просто напиши кращий промпт». Підприємець і розробник Остін Марчезе, який будує продукти на базі Claude, розклав цей підхід на три шари. Перший і ключовий з них — це правильно побудована специфікація (spec), яка перетворює людське розуміння задачі на формат, з яким модель справді може надійно працювати.

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

Автомийка за 50 метрів: як проста задача викриває глибоку проблему AI

Карпаті наводить, на перший погляд, банальне запитання: «Я хочу поїхати на автомийку, щоб помити машину. Вона за 50 метрів. Мені їхати чи йти пішки?» Сучасні моделі впевнено відповідають: «Йти пішки, бо це дуже близько».

Марчезе перевірив це на чотирьох провідних системах — Claude, Gemini, Grok і ChatGPT. Усі порадили йти. Формально логіка виглядає розумною: коротка відстань, отже, пішки. Але в реальному світі це помилка: ціль — не «дійти до автомийки», а «помити машину», а для цього машина має опинитися на автомийці.

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

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

Саме цей розрив і має закрити перший шар методу Карпаті — шар специфікації.

Спека як міст між людською інтуїцією та «обчислювальним мозком» Claude

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

Марчезе описує перший шар методу так: це створення детальної спеки, яка переносить людське розуміння в формат, придатний для Claude. На відміну від «план-режиму» (plan mode), який генерує загальний план дій, Карпаті вважає, що цього рівня абстракції недостатньо. План занадто високорівневий і залишає моделі надто багато простору для інтерпретацій — саме там і народжуються помилки на кшталт «прогулянки до автомийки».

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

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

У цьому підході головне — не красномовність промпта, а точність і структурованість опису задачі.

Від завдання до цілі: чому «зроби звіт» — це погана спека

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

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

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

Тому перший крок у побудові спеки — виявити справжню ціль. Не «що треба зробити», а «яке рішення або зміну в реальному світі це має забезпечити». У випадку з автомийкою ціль — «чиста машина», а не «людина біля автомийки». У випадку з бізнес-звітом — «чітке управлінське рішення», а не «красивий PDF на 20 сторінок».

Марчезе пропонує системно вбудувати цей крок у роботу з Claude: замість того, щоб одразу просити модель «зробити X», варто спочатку попросити її провести з вами міні-інтерв’ю.

Claude як інтерв’юер: як витягнути справжню ціль і обмеження

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

Замість промпта на кшталт «Створи end-of-month звіт по продажах» варто почати з інструкції: «Проведи зі мною інтерв’ю, щоб виявити ціль цього проєкту, ключові рішення, які мають бути ухвалені на основі результату, і обмеження, в яких ми працюємо». Далі Claude ставить уточнювальні запитання, а ви відповідаєте, поступово розкриваючи:

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

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

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

Agile проти waterfall: чому великі промпти ламають навіть найкращі моделі

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

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

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

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

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

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

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

«Будь точним і користуйся мозком»: чому AI має змушувати вас думати

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

У практиці це означає дві речі.

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

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

Інакше кажучи, Claude має не просто видати готову спеку, а змусити користувача пройтися по критичних точках і підтвердити або скоригувати їх. Це може стосуватися, наприклад:

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

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

«Сучасна інженерія»: як виглядає зріла робота з Claude на першому шарі

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

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

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

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

Висновок: AI не вгадає вашу ціль — її треба зафіксувати

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

Метод Карпаті, у викладі Остіна Марчезе, пропонує просту, але вимогливу відповідь: перестати покладатися на високорівневі плани й почати будувати детальні спеки, які явно кодують людське розуміння цілей, контексту й обмежень. Для цього варто використовувати Claude не лише як виконавця, а як інтерв’юера й співавтора специфікацій, працювати в agile-ритмі невеликих кроків і змушувати себе явно підтверджувати ключові рішення.

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


Джерело

Stop Prompting Claude. Use Karpathy’s Method Instead. — Austin Marchese

Чому агентні AI-системи ламаються при масштабуванні

0

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

Агент, який працює в демо, і агент, який має жити в продакшені — це різні істоти

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

  • Планування — розбиття задачі на кроки
  • Виконання — виклики інструментів, API, сервісів
  • Пам’ять — збереження релевантного контексту
  • Рефлексія — оцінка дій, корекція стратегії

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

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

  • Планування займає більше часу, бо зростає кількість варіантів дій
  • Виконання ускладнюється: потрібно обирати між більшою кількістю інструментів
  • Пам’ять роздувається, у кожен крок передається більше контексту
  • Рефлексія стає дорожчою і менш надійною — корисні сигнали губляться в «шумі»

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

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

Коли маленька помилка отруює всю систему

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

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

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

Формально все відпрацювало «правильно» — але на хибному припущенні. Помилка на вході:

  • визначила весь план
  • вплинула на всі наступні дії
  • була закріплена в пам’яті як частина історії взаємодії

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

Тобто зі зростанням масштабу агенти:

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

Проблема не в моделі, а в тому, хто за що відповідає

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

  • приймає всі рішення
  • тримає всю пам’ять
  • відповідає за всі домени

то зі зростанням обсягу задач:

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

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

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

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

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

Мультиагентні системи: не модний тренд, а вимушена архітектура

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

  • працює з меншим контекстом
  • приймає менше рішень
  • має вужчу сферу дії

У сукупності це дає:

  • дешевші й швидші окремі рішення
  • локалізацію складності
  • обмеження поширення збоїв

Так природно виникають мультиагентні системи — як наслідок правильного масштабування, а не як самоціль.

Але разом із цим з’являється новий клас проблем: координація між агентами. Потрібно вирішити, як вони:

  • ділять роботу
  • обмінюються результатами
  • управляють залежностями

Тут постає ключове архітектурне питання: де розміщувати нові можливості?

Горизонтальне vs вертикальне масштабування можливостей

Є дві основні стратегії:

  1. Горизонтальне масштабування
    Додаються нові агенти з окремими зонами відповідальності. Плюси:
  2. легше повторно використовувати можливості
  3. чіткіші межі відповідальності

Мінус: координація стає вузьким місцем, а накладні витрати на комунікацію швидко ростуть.

  1. Вертикальне масштабування
    Існуючі агенти «обростають» новими інструментами або підагентами. Плюси:
  2. менше координаційних кроків
  3. менше міжагентних залежностей

Мінус: зростає складність і латентність усередині окремих агентів.

На практиці це зводиться до питання: винести можливість в окремий агент чи вбудувати в наявний?

Приклад: дослідницький асистент

Уявімо систему дослідницького асистента з такою структурою:

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

Як додати фактчекінг?

  • Логічно зробити окремого агента, який перевіряє вихідні дані по всій системі.
    Це:
  • окрема, багаторазово використовувана можливість
  • зі своїми правилами й політиками
  • корисна в різних точках пайплайну

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

А як додати ранжування та фільтрацію знайдених документів?

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

Звідси випливає практичне правило:

  • Виносити в окремих агентів — можливості, які:
  • повторно використовуються
  • відносно незалежні
  • мають власну політику й логіку

  • Вбудовувати в існуючих агентів — можливості, які:

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

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

Масштабування підсилює не лише інтелект, а й усі проблеми

На кожному етапі масштабування агентних систем:

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

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

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

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


Джерело

Building AI Agent Systems and Scaling Challenges in Agentic AI — IBM Technology

Засновник e-scooter залучив $5 млн на дата-центри в космосі

0

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

Засновник e-scooter залучив $5 млн на дата-центри в космосі

Orbital — нова фірма, що в травні вийшла з акселератора a16z Speedrun із посівним раундом у $5 млн, — стала черговою компанією, яка обіцяє виконувати AI-обчислення на орбіті, щойно Starship почне регулярні польоти. Серед інших інвесторів — Basis Set, Human Element, Wayfinder, Antler, Anti Fund, Ascent, Rubik, Zero Knowledge Ventures, LYVC, Feld Ventures, New Legacy, FNDR, UpHonest і Asterisk.

Засновник і CEO Orbital Ювін Пун раніше створив компанію електросамокатів Spin у 2017 році й уже за рік продав її Ford, приєднавшись до автогіганта. Коли він був готовий запускати нову компанію, в a16z Speedrun охоче погодилися його підтримати. Партнер фонду Ендрю Чен розповів TechCrunch, що Пун пропрацьовував кілька ідей, перш ніж зупинитися на космічних дата-центрах.

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

Як і багато конкурентів, Orbital робить ставку на те, що SpaceX відпрацює свою ракету Starship і запропонує її комерційним клієнтам. «Ми вийдемо на повний масштаб, коли Starship стане доступною», — пояснює Пун. Поточна ціна запусків Falcon 9, нинішнього флагмана SpaceX, «робить це економічно нереалістичним».

Поки що Пун і його команда — близько десятка людей у Лос-Анджелесі з досвідом роботи в Amazon LEO, SpaceX і Northrop Grumman — готуються до демонстраційного польоту. У його межах Orbital відправить чип Nvidia Blackwell на супутнику-партнері, щоб протестувати власні технології радіаційного захисту та терморегулювання. У 2028 році компанія сподівається запустити свій перший космічний апарат для обробки даних із GPU Nvidia Space-1 класу Vera Rubin.

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

Мета Orbital — вивести на орбіту 10 000 супутників, які забезпечать розподілену обчислювальну потужність на рівні гігавата, при цьому кожен апарат має генерувати 100 кВт. Для порівняння: Ілон Маск заявляв, що AI-супутники SpaceX зможуть видавати до 150 кВт, а Starcloud розраховує розгорнути ще більші апарати на 200 кВт для роботи чипів.

Деякі компанії не хочуть чекати Starship. Cowboy Space Company, ще один стартап космічних дата-центрів, що також має підтримку a16z, нещодавно вирішив самостійно будувати ракети. А космічна компанія Джеффа Безоса Blue Origin оголосила плани виводити дата-центри в космос за допомогою своєї ракети New Glenn.

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

Чен вважає, що досвід Пуна в масштабуванні бізнесу, який розгорнув 250 000 самокатів у 100 містах, доводить його здатність впоратися зі складним завданням побудови аерокосмічної компанії. У довгостроковій перспективі на такий проєкт може піти десятиліття та $5 млрд і більше, але, за словами Чена, венчурні фонди стають більш комфортно почуватися з такими горизонтами.

«Подібна ідея звучала б божевільно 10 років тому, коли ми всі робили мобільні додатки, — каже він. — Запустити таке в 2026-му означає скористатися всією енергією та ентузіазмом, які зараз є на ринку капіталу».

Пун прийшов до ідеї космічних дата-центрів обхідним шляхом. Після виходу з Ford він просто заради цікавості купив GPU Nvidia A100, розмістив його в дата-центрі в Санта-Кларі й почав надавати доступ до моделей з відкритими вагами. Власний досвід переконав його в цінності надання обчислювальних потужностей в епоху ШІ.

Тепер йому залишилося тільки вивести на орбіту пару тисяч GPU.

Джерело

TechCrunch

Lovable досягла $500 млн річної виручки

0

Європейський стартап з «vibe‑coding» Lovable повідомив TechCrunch, що перевищив позначку у $500 млн річної виручки (annualized revenue run rate).

Lovable досягла $500 млн річної виручки

Востаннє Lovable розкривала показники в лютому, коли компанія заявляла про подолання рівня $400 млн. У серпні 2024 року в Lovable прогнозували, що зможуть вийти на $1 млрд річної виручки протягом 12 місяців. Хоча компанія, ймовірно, не подвоїть цю цифру до літа, її зростання все одно виглядає вражаючим: стартап, заснований наприкінці 2023 року, ще навіть не відсвяткував третю річницю.

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

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

Цей перелік багато про що говорить. AI‑платформи для «vibe‑coding» уже сприймаються як загроза для класичного SaaS‑ПЗ: навіщо купувати дорогі річні підписки, якщо можна «навайбити» потрібний софт самостійно? Опитування Lovable дає певні підстави вважати, що це вже відбувається.

Однак Lovable і більшість побудованих на ній проєктів ще надто молоді, щоб відповісти на головне запитання щодо «vibe‑coded» ПЗ: чи виявиться такий підхід довгоживучим? Проблема зазвичай не в початковому створенні продукту, а в його довгостроковій підтримці та розвитку.

Джерело

TechCrunch

Sandstone залучила $30 млн для AI в юрдепартаменти

0

На тлі того, як стартапи Harvey та Legora витрачають десятки мільйонів доларів інвестицій, юридичні інструменти стали одним із найшвидше зростаючих і найгарячіших напрямів серед AI‑стартапів. Однак попри фокус цих рішень на юридичній практиці для зовнішніх клієнтів, частина ринку досі залишається недослуженою.

Sandstone залучила $30 млн для AI в юрдепартаменти

Стартап Sandstone, який у вівторок оголосив про залучення $30 млн інвестицій у раунді серії A, націлений саме на цей менш помітний сегмент — внутрішні юридичні команди компаній, що працюють із заплутаним набором завдань і розрізнених систем.

Раунд серії A очолив фонд Lightspeed Venture Partners, до нього також долучилися наявні інвестори Mantis VC, SV Angel, Operator Partners, Kearny Jackson, Daybreak Ventures, Litquidity Ventures та інші. Нове фінансування надійшло лише через шість місяців після посівного раунду обсягом $10 млн у січні, який очолювала Sequoia.

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

“Вони зранку відкривають ноутбук і бачать весь обсяг роботи, що надійшла через різні канали — повідомлення в Slack, електронні листи, Jira”, — розповів TechCrunch співзасновник і операційний директор Sandstone Джаррид Стрідом. — “AI допомагає їм правильно маршрутизувати й сортувати ці запити, а потім на нашій платформі можна будувати кастомні робочі процеси для виконання завдань — від підготовки документів і ревʼю до надання юридичного аналізу”.

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

“Одне з переконань Lightspeed полягає в тому, що вони вірять у високоспеціалізований вертикальний AI”, — каже Стрідом. — “Тому що потрібне дуже детальне розуміння робочих процесів, аби по‑справжньому точно визначити, як саме AI може допомогти”.

Джерело

TechCrunch

App Store від Apple отримує персональні рекомендації

0

Пошук нових застосунків в App Store від Apple менше залежатиме від перегляду топ-чартів чи добірок від редакторів. Цього тижня Apple оголосила про низку нових інструментів відкриття контенту, які персоналізуватимуть рекомендації застосунків залежно від інтересів і поведінки користувачів, відкриваючи для розробників нові можливості бути поміченими.

App Store від Apple отримує персональні рекомендації

На конференції розробників WWDC Apple представила в App Store функцію Personalized Collections — персоналізовані добірки, які показуватимуть рекомендації, підібрані під конкретного користувача. У цих добірках також з’являться нові «App Notes» — пояснення, чому саме ці застосунки пропонуються вам. Починаючи з цього тижня, нові персональні поради будуть з’являтися в різних розділах App Store, зокрема на вкладках Apps або Games, а також на вкладці Search.

Рекомендації змінюватимуться з часом залежно від того, які застосунки користувач завантажує та як ними користується.

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

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

Наприклад, розробники тепер зможуть використовувати багаті зображення та відео в шапці сторінки застосунку й у результатах пошуку, щоб підкреслити новий контент або сезонні пропозиції. Це може спонукати наявних користувачів повернутися до застосунку, щоб подивитися, що змінилося. Також вони зможуть впорядковувати свої маркетингові матеріали в новій бібліотеці Asset Library, де зберігатимуться постійно використовувані ресурси для in-app подій, розпродажів та промо-акцій. Окремо розробники отримають можливість показувати спеціальні пропозиції й залучати гравців через застосунок Apple Games.

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

У межах нової системи розробники також зможуть продавати підписки більшим групам і організаціям, завдяки новим опціям створення багатокористувацьких сценаріїв in-app покупок.

Джерело

TechCrunch

Fire Emblem: Fortune’s Weave вийде на Switch 2 17 вересня

0

Вересень і так виглядав надзвичайно насиченим місяцем для великих ігор, адже багато великих розробників і видавців намагаються уникати дати релізу Grand Theft Auto 6, запланованої на 19 листопада. Під час останньої презентації Nintendo Direct компанія ще більше посилила конкуренцію, підтвердивши, що Fire Emblem: Fortune’s Weave вийде на Switch 2 вже 17 вересня.

Fire Emblem: Fortune's Weave вийде на Switch 2 17 вересня

Це перша нова частина серії з часів Fire Emblem Engage 2023 року. Nintendo анонсувала останню на сьогодні гру франшизи минулого вересня.

Джерело

Engadget

Orbitals вийде на Switch 2 3 вересня

0

Orbitals, ексклюзивна гра для Switch 2 в аніме-стилі від видавця Kepler Interactive, вийде 3 вересня. Про це Nintendo оголосила сьогодні під час своєї літньої презентації Direct. Перший повноцінний погляд на гру показали ще в лютому, коли вона завершувала показ партнерського Direct. Тоді Nintendo обіцяла реліз Orbitals «влітку», і зараз виглядає, що гра дотримається цього графіка.

Orbitals вийде на Switch 2 3 вересня

Якщо Orbitals ще не потрапила у ваше поле зору, її найкраще описати як кооперативну пригодницьку головоломку для двох гравців. Ви разом з другом або членом родини граєте за пару міжгалактичних дослідників, які мають врятувати свою домівку від космічної бурі, що наближається. Візуальний стиль у дусі аніме 1990-х одразу впадає в око, але гра також виглядає як цікава варіація на кшталт It Takes Two та Split Fiction.

Orbitals підтримуватиме локальний і онлайн-кооператив, а завдяки функції GameShare на Switch 2 лише одному гравцю потрібно буде придбати гру, щоб у неї могли грати двоє. Попереднє замовлення Orbitals уже доступне в Nintendo eShop.

Джерело

Engadget