У 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)

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)

Роль інженерів у штучному інтелекті за останні два роки змінилася радикальніше, ніж за попереднє десятиліття. Про це відверто говорить Чіп Хюєн — інженерка, підприємниця та авторка бестселерів “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)

У подкасті 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