Чому одна й та сама модель дає кардинально різні результати
Досвідчені користувачі AI помічають парадокс: GPT-4 з поганим промптом програє Claude Haiku з хорошим. Модель — це потенціал. Контекст — це те що цей потенціал реалізує або вбиває.
Що входить до «контексту»
Контекст — не тільки текст запиту. Це весь вхідний «пакет» який бачить модель:
- Системний промпт — хто ти, яка задача, які обмеження, який формат виводу
- Релевантні дані — фрагменти документів, попередні повідомлення, результати пошуку
- Приклади — few-shot examples що показують бажаний формат і стиль
- Поточний запит — що конкретно потрібно зробити зараз
Модель не має доступу до твоїх думок. Все що не написано явно — модель або вгадує, або ігнорує.
Три техніки що дають найбільший ефект
- Role + Goal + Format. «Ти — старший Python-розробник. Задача: рефакторинг цієї функції. Виведи: новий код + пояснення змін у 2-3 реченнях.» Три компоненти → вдвічі кращий результат ніж просто «покращ цей код».
- Негативні обмеження. «НЕ додавай коментарі. НЕ змінюй сигнатуру функції. НЕ використовуй lambda.» Модель краще розуміє що не треба робити ніж абстрактне «зроби добре».
- Chain of thought. «Спочатку поясни своє розуміння задачі, потім запропонуй рішення.» Примушуючи модель «думати вголос» — ти отримуєш кращу логіку і легше помічаєш де вона помилилась.
Реальний приклад: той самий запит, різний результат
Запит «перекласти цей текст» до GPT-4 може дати посередній переклад. Той самий запит з системним промптом «ти — перекладач технічної документації з 10 роками досвіду, переклад має зберігати технічну точність і природньо звучати для носіїв мови» — дасть суттєво кращий результат. Не через іншу модель — через кращий контекст.
Коли більша модель таки потрібна
Є задачі де контекст не компенсує розмір моделі: дуже довгі документи (потрібне велике контекстне вікно), складний математичний аналіз, задачі де потрібна extended thinking. Але це менше 20% типових задач білдера. Для решти — промпт важливіший за модель.
Структура ефективного системного промпту
Після сотень ітерацій з різними моделями я прийшов до такої структури:
- Роль (1-2 речення): хто ти, яка твоя експертиза
- Задача (1 речення): що конкретно потрібно зробити
- Контекст (параграф): що я вже знаю, які є обмеження
- Формат виводу: точно що і як повернути (JSON, bullet points, код, тощо)
- Заборони: що НЕ робити
Це не магія — це просто усунення ambiguity. Кожне невизначене місце модель заповнює «найімовірнішою» відповіддю зі свого тренування. Часто це не те що тобі потрібно.
Few-shot приклади: коли вони вирішують
Найефективніший інструмент для складних задач — показати 2-3 приклади «вхід → очікуваний вивід». Це особливо важливо для задач де «якість» суб'єктивна: тон тексту, стиль коду, формат звіту. Приклади передають те що складно описати словами.
Правило: якщо пояснення зайняло б більше абзацу — краще дати приклад.
Динамічний контекст: вставляй тільки релевантне
Для RAG-систем і агентів з великим контекстом — якість пошуку релевантних фрагментів важливіша за обсяг контексту. Краще 3 найрелевантніші абзаци ніж 20 сторінок де є відповідь десь посередині. Модель «розмивається» на великому контексті — ключова інформація має бути помітною, не похованою.
Ітеративне поліпшення промптів як інженерна практика
Промпт-інженерія — це інженерна дисципліна, не мистецтво. Це означає: версіонування промптів, A/B тестування варіантів, вимірювані метрики успіху. Якщо промпт «просто здається кращим» — це не достатньо для продакшн рішення.
Простий підхід: зберігай промпти в окремих файлах (не в коді), відстежуй версії з git, і для ключових промптів май набір test cases де ти можеш перевірити що зміна не зламала попередньо добре працюючу поведінку. Це займає трохи часу на старті але економить години при кожній ітерації.
Питання: скільки часу варто витрачати на оптимізацію промптів?
Залежить від частоти використання. Промпт що запускається тисячі разів на день — варто відполірувати. Одноразовий запит — взяти перший варіант що дав прийнятний результат. Правило: час на оптимізацію має бути пропорційний до кількості майбутніх використань промпту.
Питання: як зберігати і організовувати промпти для великого проекту?
Найпростіше що добре масштабується: окрема директорія prompts/ в репозиторії, файли з описовими назвами (analyze-contract.md, extract-entities.txt), версіонування через git. Для команди — PR review для змін промптів так само як для змін коду. Промпт — це конфігурація, і вона заслуговує такого ж відношення.