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)