Основи промпт-інжинірингу (3/4)

Snake Lab став повноцінним сервером із API на ZeroMQ, перевіркою конфігурацій, базою даних і можливістю проводити експерименти незалежно від клієнта. Тому очевидним стало наступне запитання:

Що буде, якщо дозволити LLM керувати ним?

Так з’явився Fr3d.

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

Snake Lab проводить експеримент.

Fr3d дивиться на результат.

Потім пробує знову.

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

Дати ШІ експеримент

Я почав складати промпти, які пояснювали моделі експеримент зі «Змійкою».

У промпті описувалися нейронна мережа, доступні параметри, допустимі діапазони, поточна конфігурація та релевантна історія експериментів. Потім Fr3d вибирав значення параметра й надсилав новий експеримент через API Snake Lab.

Усе це утворювало цикл:

промпт → LLM → конфігурація → Snake Lab → результат → промпт

І напрочуд швидко все запрацювало.

Не ідеально.

Але працювало.

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

Це вже було не просто прохання до LLM створити правдоподібний JSON.

Вона мала ухвалювати рішення на основі справжніх експериментальних результатів.

Короткий експеримент із комп’ютерним зором

Приблизно тоді я ненадовго відволікся на Qwen 2.5 VL, мультимодальну версію моделі з підтримкою зображень.

Ідея здавалася привабливою.

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

Модель із підтримкою зображень просто міркувала гірше за Qwen 3.5. Для цього застосування здатність до аналізу була набагато важливішою за зір.

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

«Цей промпт — нісенітниця».

Можливо, не буквально, але зміст був саме такий.

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

Спостерігаючи за міркуваннями, я міг побачити ці помилки.

Це був, мабуть, мій перший справжній урок промпт-інжинірингу. Погана відповідь не обов’язково означає погану модель. Іноді ви просто поставили погане запитання.

Промпт-інжиніринг — це програмна інженерія

До Fr3d я здебільшого сприймав промпти як інструкції. Наприкінці проєкту почав ставитися до них радше як до інтерфейсів.

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

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

Промпти стали частиною архітектури системи.

Проблема прототипу

Приблизно за тиждень Fr3d запрацював.

• Він міг спілкуватися зі Snake Lab.
• Міг надсилати експерименти.
• Міг отримувати результати.
• Міг аналізувати їх і вибирати наступну конфігурацію.
• Це був справжній автономний цикл експериментів від початку до кінця.

А код був жахливий.

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

• Промпти були вбудовані безпосередньо в код застосунку.
• Специфічна для експерименту логіка переплелася із загальною логікою сервера LLM.
• Було дублювання.
• Стан був розкиданий по різних місцях.
• Щоб зрозуміти, що сталося під час експерименту, доводилося читати купу журналів і виконувати ситуативні SQL-запити.
• Змінюючи одну частину процесу, потрібно було обережно простежувати залежності через доволі монолітну програму.

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

Звітність від початку мала бути повноцінною складовою

Я ставився до журналювання та звітності як до речей, які можна додати навколо експерименту. Насправді все навпаки. Для автономної експериментальної системи спостережуваність є частиною самого експерименту. Мені потрібно було легко відповідати на прості запитання:

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

Теоретично стос журналів міг дати відповіді. Але технічна можливість отримати відповідь і зрозумілість системи — зовсім різні речі. Наступну версію потрібно було від самого початку будувати навколо звітності.

Знайти межі відповідальності

Fr3d також навчив мене бачити природні межі між модулями.

Деякі частини системи були загальними:

• Спілкування з локальним сервером LLM
• Керування розмовами
• Надсилання запитів
• Зберігання стану
• Опрацювання відповідей
• Запис подій

Інші стосувалися саме цього експерименту:

• Параметри конфігурації Snake Lab
• Діапазони параметрів
• Історія експериментів
• Промпти
• Логіка порівняння
• Правила вибору наступного значення

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

• Промпти потрібно було зробити керованими даними.
• Побудову промптів потрібно було винести в окрему абстракцію.
• Звітність треба закласти в архітектуру.
• Специфічну для експерименту логіку слід відокремити від загального механізму взаємодії з LLM.

Почати спочатку

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

Я вирішив цього не робити.

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

Головний висновок із Fr3d був зовсім не «спочатку спроєктуйте все правильно». Майже навпаки.

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

Fr3d був неохайним. Але працював. І саме завдяки цьому я нарешті знав, що потрібно будувати далі.

Посилання

• Частина 1/4 — локальна LLM пише хайку
• Частина 2/4 — еволюція Snake Lab
• Частина 3/4 — ця стаття
• Частина 4/4 — від прототипу до продукту

• 2026 19
• 2025 16
• 2024 2