Prompt Engineering: основи

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

Мовна модель не читає думки користувача. Якщо запит нечіткий, вона змушена вгадувати:

• що саме потрібно зробити;

• для кого призначена відповідь;

• наскільки детально її подати;

• які обмеження врахувати;

• у якому форматі повернути результат.

Чим менше важливих деталей модель має вигадати самостійно, тим вища ймовірність якісної відповіді.

Із чого складається хороший промпт

Практичний промпт зазвичай містить кілька компонентів:

1. Роль або контекст — ким має «бути» модель у межах завдання.

2. Завдання — що саме потрібно зробити.

3. Вхідні дані — текст, вимоги, приклади або інша інформація.

4. Обмеження — що дозволено й заборонено.

5. Формат відповіді — структура, стиль, кількість пунктів або формат даних.

6. Критерії якості — як зрозуміти, що результат хороший.

Не кожен запит має містити всі компоненти. Але для складних завдань така структура значно зменшує кількість непорозумінь.

Приклад нечіткого запиту

Напиши про Docker.

З такого запиту не зрозуміло:

• для новачка чи досвідченого розробника;

• коротке пояснення чи повну статтю;

• теорія чи практичний приклад;

• які саме аспекти Docker потрібно розглянути.

Покращений варіант

Поясни Docker розробнику, який уже знає основи Linux і Git, але не працював із контейнерами. Опиши різницю між образом і контейнером, покажи базовий Dockerfile для Node.js-застосунку та наведи три типові команди. Відповідь українською, у форматі короткого навчального матеріалу з підзаголовками.

Другий запит задає напрям, аудиторію, обсяг і формат результату.

Формулюйте завдання дієсловом

Починайте промпт із конкретної дії:

• поясни;

• порівняй;

• узагальни;

• перероби;

• проаналізуй;

• знайди помилки;

• згенеруй;

• переклади;

• класифікуй;

• склади план.

Фраза «Розкажи про REST API» менш точна, ніж:

Поясни принципи REST API для початківця та наведи приклад взаємодії клієнта із сервером.

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

Додавайте контекст

Контекст допомагає моделі адаптувати відповідь до ситуації. Він може містити:

• рівень підготовки читача;

• мову програмування;

• версію технології;

• мету завдання;

• уже наявний код;

• попередні спроби;

• обмеження проєкту;

• очікуваний результат.

Наприклад, запит:

Оптимізуй цей SQL-запит.

майже завжди недостатній. Краще вказати:

Проаналізуй цей SQL-запит для PostgreSQL. Запит виконується на таблиці приблизно з десятьма мільйонами рядків і працює повільно через фільтрацію за created_at. Запропонуй можливі індекси, поясни компроміси та не змінюй структуру таблиць.

Контекст не гарантує правильності відповіді, але робить її релевантнішою.

Визначайте роль і аудиторію

Роль задає перспективу відповіді. Наприклад:

Виступи як технічний редактор і перевір цей текст на точність та зрозумілість.

Або:

Виступи як наставник для розробника-початківця. Пояснюй терміни простими словами та додавай невеликі приклади.

Роль не створює спеціальних можливостей і не робить модель справжнім експертом. Вона лише допомагає сфокусувати стиль і критерії відповіді.

Аудиторія не менш важлива. Порівняйте:

Поясни асинхронність.

і:

Поясни асинхронність JavaScript початківцю, який знає змінні, функції та цикли, але ще не працював із Promise.

Другий варіант дає моделі орієнтир щодо складності пояснення.

Явно задавайте формат результату

Якщо формат важливий, його потрібно описати безпосередньо. Можна вказати:

• кількість пунктів;

• структуру з підзаголовками;

• довжину відповіді;

• тон;

• формат JSON;

• формат списку;

• наявність прикладів;

• заборону певних елементів.

Наприклад:

Порівняй REST і GraphQL у шести пунктах. Для кожного пункту наведи коротке пояснення та ситуацію, у якій відповідний підхід кращий. Не використовуй таблицю.

Або:

Поверни результат у JSON з полями title, summary і risks. Не додавай пояснень поза JSON.

Для машинної обробки варто заздалегідь уточнити, що результат має бути валідним JSON, без Markdown-обгортки та додаткового тексту.

Використовуйте обмеження

Обмеження допомагають уникнути небажаного результату. Вони можуть стосуватися:

• обсягу;

• стилю;

• термінології;

• мови;

• формату;

• допустимих бібліотек;

• версії середовища;

• рівня деталізації.

Приклад:

Напиши функцію на JavaScript без сторонніх бібліотек. Вона має приймати масив об’єктів і повертати лише записи з активним статусом. Використовуй синтаксис ES2022 та додай обробку порожнього масиву.

Обмеження мають бути конкретними. Фраза «зроби коротко» допускає різні трактування. Натомість «до 150 слів, не більше п’яти абзаців» набагато точніша.

Розділяйте інструкцію та дані

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

Наприклад:

Проаналізуй текст нижче.

Завдання:
1. Визнач головну тезу.
2. Назви три аргументи автора.
3. Знайди твердження, які потребують перевірки.
4. Поверни відповідь у форматі нумерованого списку.

Текст для аналізу:
---
[тут розміщується текст]
---

Для коду можна використовувати окремі блоки:

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

Код:
```javascript
function getUserName(user) {
  return user.profile.name;
}

Таке розділення особливо корисне під час аналізу документів, логів, конфігурацій і програмного коду.

## Давайте приклади бажаного результату

Приклад у промпті називають демонстрацією або few-shot prompting. Він показує моделі не лише зміст завдання, а й очікуваний спосіб його виконання.

Наприклад:

```text
Перетворюй назву помилки на короткий опис для користувача.

Приклад:
Вхід: Connection refused
Вихід: Не вдалося підключитися до сервера.

Приклад:
Вхід: Invalid token
Вихід: Сесія завершилася. Увійдіть повторно.

Тепер оброби:
Вхід: Request timeout

Очікуваний напрям очевидний: коротке пояснення українською без технічних подробиць.

Приклади особливо корисні, коли потрібно дотримуватися:

• нестандартного стилю;

• певної структури;

• правил класифікації;

• формату міток;

• специфічної термінології.

Водночас приклади мають бути правильними та узгодженими. Суперечливі приклади лише заплутають модель.

Розбивайте складні завдання на етапи

Одна велика інструкція може містити кілька різних завдань. У такому разі модель може пропустити частину вимог або виконати їх у неправильному порядку.

Замість:

Прочитай цей текст, перевір факти, перепиши його для початківців, зроби SEO-заголовок і переклади англійською.

краще використати послідовність:

1. Визначити основні твердження.

2. Відокремити факти від припущень.

3. Переписати текст для конкретної аудиторії.

4. Запропонувати заголовок.

5. Перекласти фінальну версію.

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

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

Просіть вказувати припущення та невизначеність

Мовна модель може сформулювати переконливу, але помилкову відповідь. Щоб зменшити ризик, додайте інструкції:

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

Для технічних завдань корисно просити:

• перелічити зроблені припущення;

• відокремити факти від рекомендацій;

• позначити потенційно неперевірені твердження;

• вказати, що потрібно перевірити вручну;

• назвати ризики запропонованого рішення.

Наприклад:

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

Це не усуває помилки, але робить межі відповіді помітнішими.

Попросіть модель перевірити результат

Після основного завдання можна додати критерії самоперевірки:

Перед фінальною відповіддю перевір, чи:

• виконано всі пункти;

• приклади відповідають вимогам;

• код синтаксично узгоджений;

• не додано заборонених елементів;

• висновки випливають із наданих даних.

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

Ще надійніший підхід — сформулювати перевірку як окреме завдання після отримання першого результату:

Перевір попередню відповідь за цими критеріями. Для кожного критерію наведи статус «виконано» або «потрібне виправлення» та пояснення.

Працюйте ітеративно

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

1. Сформулюйте початковий запит.

2. Перевірте, що саме модель зрозуміла.

3. Уточніть відсутній контекст.

4. Виправте помилки або невідповідності.

5. Зафіксуйте найкращу версію промпту.

Наприклад, після загальної відповіді можна уточнити:

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

Або:

Відповідь надто складна для початківця. Прибери внутрішні деталі реалізації, поясни терміни та залиш лише один приклад.

Ітеративність особливо важлива для великих текстів, коду, технічних рішень і завдань із неоднозначними вимогами.

Приклад універсального шаблону

Для багатьох завдань можна використовувати такий шаблон:

Контекст:
[коротко опишіть ситуацію]

Роль:
[яку перспективу має використовувати модель]

Завдання:
[конкретна дія]

Вхідні дані:
---
[текст, код або вимоги]
---

Обмеження:
- [мова]
- [обсяг]
- [заборонені або обов’язкові елементи]
- [версії технологій чи інші умови]

Формат відповіді:
[структура очікуваного результату]

Критерії якості:
- [що має бути враховано]
- [що потрібно перевірити]

Якщо даних недостатньо, вкажи це явно й не вигадуй відсутню інформацію.

Це не обов’язковий синтаксис. Його цінність у тому, що він змушує спочатку продумати вимоги.

Практичні приклади

Генерація коду

Нечітко:

Напиши API для користувачів.

Точніше:

Створи приклад REST API на Node.js з використанням Express для отримання списку користувачів. Додай маршрут GET /users, перевірку параметра limit, обробку помилки та приклад відповіді. Не використовуй базу даних: дані мають зберігатися в масиві в пам’яті. Поясни код короткими українськими коментарями.

Рев’ю коду

Проаналізуй наведений TypeScript-код. Знайди помилки типізації, потенційні проблеми з обробкою undefined і складні для підтримки місця. Для кожної проблеми вкажи рядок або фрагмент, пояснення та мінімальне виправлення. Не переписуй увесь файл.

Підготовка тестів

Створи unit-тести для функції calculateDiscount на Jest. Покрий звичайний випадок, нульову суму, граничне значення, некоректний відсоток і виняток. Спочатку переліч сценарії, а потім наведи код тестів.

Узагальнення тексту

Стисни текст до 100–120 слів для менеджера, який не має технічної підготовки. Збережи проблему, наслідки та запропоноване рішення. Не використовуй внутрішні назви змінних і не додавай нових фактів.

Порівняння технологій

Порівняй PostgreSQL і MongoDB для сервісу з транзакціями, складними зв’язками між сутностями та помірним навантаженням. Розглянь модель даних, транзакції, масштабування, зручність запитів і складність підтримки. Заверши рекомендацією та вкажи, за яких умов вона може змінитися.

Як працювати з кодом

Під час запитів про програмування корисно вказувати:

• мову та її версію;

• середовище виконання;

• фреймворк або бібліотеку;

• очікувану поведінку;

• приклади вхідних і вихідних даних;

• обмеження продуктивності;

• вимоги до сумісності;

• спосіб обробки помилок.

Наприклад:

Реалізуй функцію на Python 3.12, яка приймає список рядків і повертає лише унікальні значення без урахування регістру, зберігаючи порядок першої появи. Для порожнього списку повертай порожній список. Не використовуй сторонні бібліотеки. Додай type hints і три приклади виклику.

Після генерації коду не покладайтеся на текстове пояснення як на доказ правильності. Код потрібно:

• запустити;

• перевірити тестами;

• перевірити на граничних випадках;

• переглянути з погляду безпеки;

• зіставити з документацією використовуваних технологій.

Вибір між коротким і докладним промптом

Довший промпт не завжди кращий. Надлишкові або суперечливі вимоги можуть погіршити результат.

Короткого запиту достатньо, коли:

• завдання просте;

• контекст очевидний;

• формат не має значення;

• помилка не створює суттєвих наслідків.

Докладний промпт потрібен, коли:

• завдання багатокрокове;

• потрібен конкретний формат;

• є важливі обмеження;

• відповідь використовуватиметься в автоматизованому процесі;

• помилки коштують дорого;

• потрібно працювати з кодом, даними або конфіденційною інформацією.

Мета — не зробити промпт якомога довшим, а передати всі істотні вимоги без зайвого шуму.

Безпека та конфіденційність

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

• паролі;

• токени доступу;

• приватні ключі;

• персональні дані;

• внутрішні документи;

• комерційна таємниця;

• фрагменти коду, які не можна передавати зовнішнім системам.

Перед передаванням тексту замініть реальні значення на умовні:

API_TOKEN = "<замінено>"
USER_EMAIL = "<приклад адреси>"

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

Типові помилки

Надто загальні запити

Зроби краще.

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

Краще:

Перепиши цей текст у нейтральному стилі, скороти його на третину та прибери повтори, не змінюючи фактичного змісту.

Суперечливі вимоги

Наприклад:

Напиши дуже докладно, але не більше 50 слів.

Якщо обмеження конфліктують, модель обиратиме між ними непередбачувано. Розставляйте пріоритети або усувайте суперечність:

Напиши стисло, до 50 слів, зосередившись лише на трьох головних висновках.

Відсутність формату

Якщо не вказати формат, модель може повернути абзаци замість списку, пояснення замість JSON або повний рефакторинг замість переліку проблем.

Надмірна довіра до впевненої відповіді

Впевнений тон не означає, що твердження правильне. Перевіряйте:

• факти;

• дати;

• версії;

• цитати;

• назви API;

• результати обчислень;

• згенерований код.

Надання недостатніх даних

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

Сліпе копіювання прикладів

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

Спроба вирішити все одним промптом

Складний запит із десятьма незалежними завданнями часто дає нерівномірний результат. Розділіть його на етапи й перевіряйте кожен.

Короткий чекліст перед надсиланням промпту

Перевірте, чи зрозуміло:

• що саме потрібно зробити;

• для кого призначений результат;

• які дані має використати модель;

• які є обмеження;

• у якому форматі потрібна відповідь;

• що робити за відсутності даних;

• як перевірити якість результату.

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

Summary

Prompt engineering — це насамперед ясна постановка завдання, а не набір секретних фраз.

Найбільш практичні принципи:

• формулюйте конкретну дію;

• додавайте необхідний контекст;

• визначайте аудиторію та рівень складності;

• задавайте формат і обмеження;

• відокремлюйте інструкції від вхідних даних;

• використовуйте приклади бажаного результату;

• розбивайте складні завдання на етапи;

• просіть позначати припущення та невизначеність;

• перевіряйте факти й код незалежно від моделі;

• не передавайте секрети та конфіденційні дані.

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