Пам’ятаєте кінець 2022 року? Тоді «prompt engineering» ще звучав для багатьох як назва чергової професії майбутнього та точкою входу в «нову айтішку». Тоді дійсно чимало хто занурився в цю тему з головою — хтось просто через цікавість, а хтось хотів розібратись з практичної точки зору — як це все працює та як його використовувати на свою користь?
Я належав до другого табору, хоч і прийшов до цієї теми трішечки раніше — читав дослідження, намагався знайти наукове підґрунтя того, як змусити ШІ працювати ефективно, застосовував на практиці всі ці «chain-of-thought», «few-shot» та інші, на той час мало кому відомі, заклинання.
Якщо коротко, то з часом я дізнався усе, що мене цікавило та досяг «дзену» (як мінімум я так думав) — виробив власні, емпіричні підходи й перестав так прискіпливо стежити за кожною новою публікацією.
Але нещодавно я вирішив повернутися до цієї теми, ще раз сфокусовано заглибитись — що ж змінилося та до чого дійшла академічна думка? І, на мій подив, останні дослідження, що лягли в основу цієї статті, показали плюс-мінус ті ж інсайти, до яких я дійшов сам методом проб і помилок.
Але справа утому, що більшість досі вважає, що промптинг — це звичайна гра в слова. Що є якась секретна фраза, яка змусить АІ видати геніальний результат. Але це все одно, що намагатися керувати ядерним реактором, стукаючи по ньому гайковим ключем. Коротше кажучи, промпт-інженеринг переживає кризу ідентичності, і це причина чому я пишу цю статтю.
Ми маємо справу з однією з найскладніших систем, створених людством. І щоб нею ефективно користуватись, потрібно розуміти не її «психологію», а архітектуру, механізми уваги та те, як вона насправді «бачить» інформацію.
Що відбувається, коли ви натискаєте Enter
У 90 % випадків, коли хтось звертається до мене з питаннями про промптинг, вони завжди починають з одного й того самого: «Як правильно писати промпти?», а я, як справжня скотина, відповідаю питанням на питання: «А ти взагалі розумієш, про що ми зараз будемо розмовляти?», — так-так, цей хлопака уявляє себе токсично-харизматичним молодим професором із фільмів 2000-х.
Так от, після мого запитання зазвичай настає незручна пауза, бо питання було не риторичним — на нього треба відповісти.
Коротше, я до чого веду — люди звикли думати про промптинг як про набір правил та трюків. Напишеш «думай покроково», додаси кілька прикладів, обернеш у потрійні лапки — і все працюватиме. Але насправді ми маємо справу з набагато цікавішим і складнішим «чимось».
Давайте на прикладах: уявіть, що ви розмовляєте з істотою, яка має 175 мільярдів нейронних з’єднань, натренованих на всьому, що людство коли-небудь написало. При цьому ця істота не «розуміє» мову в нашому розумінні, але вона навчилася передбачати наступне слово з такою точністю, що це стало неможливо відрізнити від розуміння. А тепер подумайте: як би ви розмовляли з такою істотою?
Останнім часом я переглядав дослідження з різними моделями — короткий висновок: усе, що ми думали про промптинг два роки тому, стало неактуальним, але не тому, що з’явилися нові та більш потужні «лайфхаки», а тому, що змінилася сама природа того, із чим ми взаємодіємо.
Головний інсайт — це як кардинально змінилися патерни уваги. В архітектурах типу GPT-3 механізм уваги працював досить хаотично. Модель могла «зациклитися» на випадкових токенах, втратити нитку розмови через незначні зміни у форматуванні. Умовно кажучи, тестуючи різні промпти, ви часто могли стикнутись із непередбачуваністю — один і той самий запит міг дати радикально різні результати залежно від того, поставили ви крапку чи двокрапку.
Сучасні моделі працюють інакше. Коли я аналізую, як Claude 4 Sonnet обробляє структурований промпт, то бачу, що ваги уваги розподіляються набагато більш логічно. Модель дійсно скоріше «читає» ієрархію інформації, розуміє зв’язки між частинами тексту та може утримувати контекст на значно більших відстанях.
Найпростіший спосіб це побачити — порівняти, як різні архітектури реагують на зміну порядку інформації в промпті.
Старі моделі демонстрували так званий recency bias (упередження новизни) — вони надавали непропорційно велику вагу інформації, яку бачили останньою, тобто тій, що була в кінці промпту.
Сучасні ж моделі показують щось ближче до genuine semantic processing (справжньої семантичної обробки) — вони аналізують весь контекст цілісно і здатні виділяти найрелевантніші частини, незалежно від їхньої позиції в тексті.
Компресія та структурування
Але найбільший переворот стався з контекстним вікном. Перехід від 4–8 тисяч токенів до 200 тисяч, а тепер і до 2 мільйонів — це не просто кількісна зміна. Це якісний стрибок, який змінює концепцію взаємодії з моделлю.
Раніше промптинг був мистецтвом компресії — як втиснути максимум інформації в мінімум токенів. Зараз це мистецтво структурування — як організувати величезні масиви інформації так, щоб модель могла з ними ефективно працювати. Я можу завантажити в Gemini документацію проекту, додати купу файлів із кодом та приправити це ледь не десятком наукових статтей — і модель опрацює це як єдиний семантичний простір.
Практично це означає, що майже весь апарат «prompt engineering» — ці безкінечні гайди з хаками — став таким же застарілим, як спроби вручну оптимізувати асемблер-код для сучасного процесора. Сучасним моделям не потрібні хитрощі — їм потрібна ясність.
Найкращий промпт сьогодні — це не той, який використовує якусь магічну формулу, а той, який чітко структурує завдання відповідно до того, як працює архітектура трансформерів.
І коли я бачу, як хтось досі поширює використання підходів із 2023 року — ці довгі ланцюжки «act as an expert, step by step, in the style of» — стає трохи сумно.
Але ось парадокс — поки я пишу цю статтю, велика кількість академічних досліджень присвячені ще версії GPT-4, при цьому не дуже пізній. У кращому випадку — Claude 3.5 Sonnet.
А тим часом люди вже використовують Claude 4 Sonnet, працюють з reasoning моделями та чекають на GPT-5, який має от-от з’явитися (не здивуюсь, якщо на момент виходу статті вже й реліз відбудеться).
Цей розрив між академічним світом та практикою досяг абсурдних розмірів. Науковці публікують ретельні дослідження про моделі, якими вже майже ніхто не користується. Цикл peer review займає стільки часу, що вже встигають вийти дві-три нові моделі. Результат — купа «наукових рекомендацій» для моделей, які вже фактично стали реліктами.
Тепер я думаю вам буде зрозуміло, що коли я згадую в цій статті дослідження GPT-4 та Claude 3.5, то це не тому, що вони ще супер актуальні, а тому, що наразі тільки для них існують систематичні дослідження.
При цьому, незалежно від того, чи це GPT-4, Claude 4, чи майбутній GPT-5 — усі вони побудовані на тих самих принципах трансформеру. І якщо ви розумієте, як працюють шари уваги, як модель обробляє семантичну структуру, як розподіляються ваги між токенами — то зможете ефективно взаємодіяти з будь-якою із цих архітектур.
Модель не потрібно переконувати чи обманювати. Їй потрібно просто ясно пояснити, що ви від неї хочете. І якщо ви розумієте, як вона працює на архітектурному рівні, то зможете з нею працювати значно ефективніше за чергові «промпт-хаки» з інтернетів.
Архітектура — як (не) потрібно?
Окей, тепер до справи. Якщо ви досі пишете промпти за старими рецептами, то ризикуєте втратити до половини потенційної ефективності. І це не гіпербола — це результат порівняння traditional prompting з тим, як насправді працюють сучасні архітектури.
Найбільша помилка — це священна віра в few-shot examples. Якщо ви думаєте: «Чим більше прикладів дам моделі, тим краще вона зрозуміє завдання», — ось вам контрінтуїтивна правда: для складних завдань менша кількість прикладів часто дає кращі результати. Іншими словами, якість > кількість.
Чому так? Сучасні моделі мають достатньо контексту з pre-training, щоб зрозуміти завдання з одного-двох якісних прикладів. А надлишок прикладів змушує модель фокусуватися на поверхневих патернах замість семантики завдання — ви ненавмисно звужуєте її гігантський простір знань до вашого власного, обмеженого бачення задачі. Це як пояснювати математику через зазубрювання формул замість розуміння принципів.
Натомість справжню магію створює structured output. Серйозно, якщо ви захочете сфокусуватись тільки на одній речі із цієї статті — фокусуйтесь на structured prompting. Ось приклад того, як НЕ треба:
Проаналізуй цей код і знайди помилки. Ось код: [тут ваш код]А ось як треба:
<analysis_task> <!-- Блок завдання -->
<objective>Знайти логічні та синтаксичні помилки</objective>
<code_sample> <!-- Блок вхідних даних -->
[ваш код тут]
</code_sample>
<output_requirements> <!-- Блок вимог до результату -->
<format>structured_list</format>
<details>
— error_type
— line_number
— explanation
— fix_suggestion
</details>
</output_requirements>
</analysis_task>І перш ніж ви подумаєте «це ж складно» — насправді не складніше, ніж писати звичайний текст. Теги — це просто спосіб сказати моделі «ця частина — завдання, ця — дані, а ця — вимоги до результату».
Як це зробити за 30 секунд:
Візьміть будь-який ваш звичайний промпт і задайте собі три питання:
Що модель має зробити? →
<task>або<objective>З чим працювати? →
<input>,<data>,<context>Як подати результат? →
<output>,<format>,<requirements>
Різниця не тільки в якості відповіді — вона в консистентності. Структуровані промпти дають більш передбачувані результати навіть при переході між різними версіями моделей. Чому? Тому що XML створює чіткі семантичні межі, які шари уваги розуміють інтуїтивно.
Але тут є підступний момент — не всі формати створені однаково. Markdown, наприклад, працював раніше непогано, але сучасні моделі значно краще справляються саме з XML-подібною розміткою. Це не тому, що XML якийсь «новий тренд» — це тому, що для механізму уваги XML-теги створюють чіткі, вкладені «контейнери» сенсу.
Різниця між ними в тому, що markdown — це візуальне форматування, а XML — семантична структура. Модель не просто «бачить» текст, вона «розуміє», що токен <code> є дочірнім елементом токена <analysis_task>.
Ще один інсайт, який здивує багатьох: порядок інформації в промпті має значення, але не так, як ви думаєте. Старі моделі страждали від ефекту «останнє запам’ятовується краще» (recency bias) — усе, що було наприкінці промпту, мало непропорційно великий вплив на відповідь. Якщо ви писали довгий промпт з інструкціями на початку, а в кінці додавали «але будь стислим», модель робила акцент саме на стислості.
Сучасні моделі демонструють трішки інший патерн — U-подібний розподіл уваги (U-shaped attention). Простими словами: вони найбільше уваги приділяють початку та кінцю промпту, а середина отримує менше фокусу. Це як читання статті — ви запам’ятовуєте заголовок, пробігаєте середину і фіксуєтеся на висновках.
Практично це означає: найважливішу інформацію (мета завдання, ключові інструкції) розміщуйте на початку, деталі — у середині, а специфічні вимоги до формату — у кінці. Не тому, що так «правильно», а тому, що так тупо працює архітектура.
А ще — будь ласка, починайте по-трішки відходити від монолітних промптів. Послідовна взаємодія в кілька ходів (multi-turn conversation design) стає не просто корисною, а інколи навіть критично важливою. Замість того, щоб втискати все в один запит, спробуйте розбити складне завдання на логічну послідовність кроків — як діалог, де кожен наступний запит будується на попередній відповіді.
Дуже умовний приклад — замість: «Проаналізуй цей документ, знайди ключові тренди, порівняй із минулорічними даними, запропонуй рекомендації та створи executive summary»
Краще:
Спочатку: «Проаналізуй цей документ і виділи 5 ключових трендів»
Потім: «Тепер порівняй ці тренди з даними за минулий рік: [дані]"
Далі: «На основі порівняння запропонуй 3 конкретні рекомендації»
Нарешті: «Створи executive summary із цих рекомендацій»
Пояснюю — сучасні моделі краще підтримують контекст між відповідями, ніж працюють із величезним одиничним промптом.
Кожен новий «хід» дозволяє моделі перерахувати ваги уваги, сфокусувавшись на новому, більш вузькому завданні. Замість того, щоб тримати в «оперативній пам’яті» одразу десять цілей, вона послідовно вирішує одну за одною, використовуючи результат попередньої як фундамент для наступної. Це обчислювально ефективніше і значно надійніше. Плюс, ви можете скоригувати напрямок на будь-якому етапі.
І, мабуть, останнє, але не за значенням — динамічний контекстний менеджмент.
Коли ви працюєте з великими документами (а з 2M контекстним віконцем це вже норма), не просто вставляйте весь текст у промпт. Використовуйте теги метаданих, щоби позначити релевантні секції:
<document_analysis>
<primary_focus>financial_data</primary_focus>
<sections>
<section type=«executive_summary» priority=«high»>
[текст executive summary]
</section>
<section type=«detailed_analysis» priority=«medium»>
[детальний аналіз]
</section>
<section type=«appendix» priority=«low»>
[додатки]
</section>
</sections>
</document_analysis>Це дозволить моделі правильно розподілити увагу між різними частинами документа замість того, щоб обробляти все як однорідну масу тексту.
Майбутнє: промпт, якого ще немає
По-перше, ми бачимо, як класичні методи, на кшталт «ланцюжка думок» (Chain-of-Thought), поступово втрачають свою ексклюзивність. Нові моделі вже навчені мислити покроково за замовчуванням, і пряма вказівка «думай крок за кроком» дає все менший приріст у продуктивності.
На зміну лінійному CoT приходять «Tree of Thoughts» (ToT) та «Graph of Thoughts» (GoT), які дозволяють моделі не просто йти одним шляхом, а досліджувати ціле дерево чи навіть граф можливих рішень, оцінювати їх і відкидати тупикові гілки.
Ще один вектор розвитку — це відмова від природної мови як єдиного інструменту. На горизонті народжується концепція «компресії промптів».
Замість того, щоби писати довжелезні інструкції та приклади, ми вчимося стискати їх у компактні, інформаційно насичені «м’які промпти» (soft prompts). Це вже не природна мова, а навчені, безперервні вектори, які модель розуміє набагато ефективніше. Уявіть, що замість довгого листа ви надсилаєте концентрований згусток думки, який миттєво розгортається в голові у вашого співрозмовника — ну десь про це ми зараз і говоримо.
Ще одне передбачення на майбутнє — це перехід до неявного промптингу. Моделі навчаться розуміти наші потреби з контексту нашої роботи, без прямих вказівок. Система буде бачити, що ви працюєте над фінансовим звітом, й автоматично підлаштовуватиме свій стиль і базу знань.
Промпт перестане бути тим, що ви пишете, і стане тим, що ви робите. Це буде ера «нульового інтерфейсу», де найкращий промпт — це відсутність промпту. Наша роль зміститься від прямого оператора до того, хто лише задає вектор — усі проміжні кроки система виконує сама.
Замість висновків, тримайте — це ілюзія контролю
Отже, до чого ми прийшли? До того, що епоха «промпт-хакінгу» добігає кінця. На зміну їй приходить «архітектурна емпатія» — вміння спілкуватися з моделлю мовою її власної структури. Ми пройшли шлях від спроб обдурити систему до спроб її зрозуміти, і це, мабуть, найважливіший зсув парадигми.
Дослідження підтверджують: не існує універсальних та простих рішень. Ввічливість, погрози, маніпуляції — усе це ефективно НЕ працює, хоча ситуація і дещо варіюється від моделія до моделі, завдання і навіть конкретного запитання. Немає філософського каменя, немає інструкції користувача. Єдине, що працює стабільно — це структура, яка відповідає архітектурі моделі.
І в цьому, мабуть, криється найглибший сенс. Штучний інтелект не просто дає нам відповіді — він змушує нас вчитись ставити кращі запитання. Це часто вимагає від нас розбивати складні проблеми на прості частини, чітко визначати мету, структурувати інформацію. І взаємодіючи з АІ на такому рівні, ми мимоволі тренуємо власне системне мислення.
Тому раджу забути про пошук «ідеального промпту» — його не існує. Є лише нескінченний процес ітерацій та поступове глибше розуміння того, як це все працює: «Самурай не має мети, лише шлях, а шлях самурая — це смерть».
Інтерпретуйте як хочете — бо навіть ця стаття не про те, щоб просто отримати відповіді.
