Налаштування Prompt Engineering для AI-помічника мобільного додатку
GPT-4o без правильно налаштованого промпта на одне питання дасть пространний відповідь, на наступне змінить тон, а на третє поверне JSON замість тексту. Prompt engineering — це не «написати хорошу інструкцію», це управління детермінованістю поведінки моделі через системні промпти, кілька прикладів та контроль контекстного вікна.
Системний промпт: структура має значення
Поганий системний промпт: «Ти полезний асистент нашого додатку. Відповідай коротко та по справі.»
Робочий системний промпт містить чотири зони:
Роль та обмеження домену. «Ти асистент додатку особистих фінансів. Відповідаєш тільки на питання про бюджетування, категоризацію витрат та фінансове планування. На питання поза темою відповідай: 'Я помагаю тільки з питаннями особистих фінансів.'»
Формат виведення. Якщо асистент повинен повертати структуровані дані — опиши схему прямо в системному промпті з прикладом. Модель набагато надійніше дотримується формату, коли бачить конкретний зразок.
Тон та стиль. «Відповідай коротко — не більше 3 речень. Не використовуй маркові списки в розмовних відповідях. Не починай відповідь з 'Звичайно!' або 'Відмінне питання!'»
Контекст користувача. Сюди інжектується динамічна інформація: ім'я користувача, поточний розділ додатку, останні дії.
// iOS — формування системного промпту з контекстом
func buildSystemPrompt(user: User, currentScreen: AppScreen) -> String {
return """
Ти фінансовий асистент додатку MoneyMap.
Користувач: \(user.name), валюта: \(user.currency).
Поточний розділ: \(currentScreen.description).
Бюджет на місяць: \(user.monthlyBudget). Витрачено: \(user.spent).
Відповідай коротко українською мовою без списків.
"""
}
Few-shot приклади та управління контекстним вікном
Few-shot — це 2–5 пар «питання → правильна відповідь» на початку діалогу. Вони роблять шаблон поведінки. Критично: приклади повинні покривати граничні випадки, а не тільки «ідеальний» сценарій.
Проблема мобільних асистентів — обмеженість контекстного вікна при довгих сеансах. У gpt-4o-mini — 128K токенів, але вартість зростає лінійно. Стратегії управління історією:
- Sliding window: зберігаємо тільки останні N повідомлень (зазвичай 10–20). Дешево, але асистент «забуває» початок розмови
- Summary compression: періодично стискаємо історію: «Користувач обговорював категоризацію витрат, додав 3 транзакції» — замінює 10 повідомлень
- Retrieval-augmented memory: важливі факти з діалогу зберігаються у векторне сховище та витягуються за релевантністю. Складніше, але масштабується
Temperature, top_p та коли їх змінювати
temperature=0 — детермінований вихід, модель завжди вибирає найймовірніший токен. Для структурованих відповідей (JSON, числа, класифікація) — встановіть 0 або 0.1. Для генерування тексту «у стилі» — 0.7–0.9.
top_p=0.9 + temperature=0.7 — стандартна комбінація для розмовного асистента. Не рекомендується змінювати обидва параметри одночасно — вони взаємодіють непередбачувано.
Орієнтири за часом
Проектування та тестування системного промпту — 2–4 дні. Реалізація управління контекстним вікном — 1–2 дні. Разом: 3–5 робочих днів на базову налаштування. Ітеративне вдосконалення після запуску — безперервний процес на основі фідбеку користувачів.







