Самовдосконалюваний застосунок: замкнений цикл поліпшень

1. Навіщо застосунку потрібен замкнений цикл поліпшень

Будь‑який LLM‑застосунок живе в мінливому світі. У вас зʼявляються нові користувачі й сценарії, OpenAI випускає нові моделі та захисні механізми, ви самі оновлюєте MCP‑сервер, Agents SDK, UI‑віджет… І навіть якби весь код був написаний ідеально (так-так, я знаю, що ви майже так і робите), одна зміна моделі або промпта може непомітно зламати половину сценаріїв.

Без циклу поліпшень усе виглядає так. Користувач пише в підтримку: «GiftGenius почав пропонувати подарунки дорожче бюджету» або «сидить і думає по 15 секунд». Ви відкриваєте журнали, щось правите в system‑promptʼі, перемикаєте модель, розгортаєте зміни. За тиждень усе повторюється — але вже в іншому місці. У підсумку — хронічні «пожежі» й купа «магічних» правок, які ніхто не може пояснити.

Із циклом усе інакше. У вас є:

• зрозумілий набір сигналів із техніки, грошей, продукту та якості;
• регулярний ритуал: дивитися на них і обирати гіпотези;
• контрольовані зміни в коді/конфігах;
• автоматичні перевірки: golden‑кейси, LLM‑evals і експерименти.

Тоді застосунок перетворюється зі «застиглого промпта» на живу систему, яка:

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

І ще бонус: такий цикл чудово накладається на все, що ви вже зробили в попередніх модулях. Журнали та SLO з М17 дають технічні сигнали, cost‑інструментація й AARRR з М19 — економічні та продуктові, golden‑кейси й LLM‑evals з М20.1–2 — сигнали якості. Залишається лише повʼязати все це в зрозумілий операційний цикл.

2. Карта сигналів для поліпшень

Щоб застосунок міг сам підказувати, де саме його поліпшувати, потрібно чітко розуміти, які сигнали у вас узагалі є і звідки вони беруться. Зручно мислити чотирма групами.

Технічні сигнали приходять із вашого observability‑стека: журнали tool_invocation, метрики latency та error‑rate, health‑checks MCP/ACP, збої OAuth. Вони відповідають на запитання: «чи сервіс узагалі живий і наскільки стабільно він працює».

Економічні сигнали народжуються в cost‑інструментації та білінгу: cost_per_tool_call, cost_per_task, cost_per_user, неочікувані сплески витрат за конкретними інструментами чи сценаріями. Вони підказують: «ми спалюємо токени й гроші більше, ніж очікували» або, навпаки, «є запас — можна підвищувати якість».

Продуктові сигнали формуються з подій на кшталт app_opened, workflow_started, workflow_completed, checkout_*. Це activation‑rate, конверсії між кроками воронки, retention за когортами. Вони показують, що відбувається з реальною поведінкою людей.

Сигнали якості та поведінки включають результати LLM‑evals за golden‑кейсами (бали за correctness/helpfulness/style/safety), вибіркові ручні перегляди діалогів, thumbs up/down, скарги й відгуки в Store. Це те, що найближче до відчуття: «застосунок став розумнішим / дурнішим».

Зручно зібрати це в таблицю:

Ключовий момент: усі ці сигнали фіксуються в журналах із привʼязкою до конкретного сценарію та версії застосунку. Тобто в подіях є щонайменше scenario, appVersion і experimentId. Тоді, побачивши, що helpfulness за golden‑кейсами впав із 8.5 до 6.2, ви можете сказати не просто «стало гірше», а: «стало гірше в сценарії "gift_selection" після релізу "1.3.0", у варіанті експерименту "B"».

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

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // e.g. "gift_selection"
  metric: string;         // e.g. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // значення "до"
};

Такі обʼєкти зручно подавати і дашбордам, і вашому майбутньому асистентові поліпшень.

3. Канонічний feedback‑loop: 4 кроки

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

flowchart TD
  A[Сигнал: щось болить
або є шанс зростання] --> B[Гіпотеза:
що і як змінюємо]
  B --> C[Контрольована зміна
в code/config]
  C --> D[Перевірка:
offline + online]
  D --> A

Крок 1. Виявити проблему або шанс

На цьому кроці ви відповідаєте на запитання: «куди дивитися». Приклади:

• LLM‑eval за golden‑кейсами з бюджетом показує падіння helpfulness.
• p95 latency для інструмента "suggest_gifts" зріс із 1.2 с до 3.8 с.
• cost_per_task за сценарієм "gift_selection" зріс на 40 % після переходу на reasoning‑модель.
• Конверсія workflow_completed → checkout_success просіла на 5 в. п. після зміни UX‑майстра.
• У Store за тиждень зʼявилося 10 скарг: «подарунки дорожче зазначеного ліміту».

Важливий нюанс: іноді сигнал каже не «погано», а «можна краще». Наприклад, ви бачите, що cost_per_task помітно нижче допустимого порога, а quality‑score уже 9/10. Отже, можна спробувати дорожчу модель або «розумніший» сценарій — раптом конверсія зросте.

Крок 2. Сформулювати гіпотезу

Гіпотеза — це не «ми перепишемо промпт», а «ми вважаємо, що конкретна зміна X у компоненті Y поліпшить метрику Z, тому що…». Без «тому що» це не гіпотеза, а просто побажання.

Приклади:

• «Якщо ми зробимо правило суворого дотримання бюджету в system‑promptʼі й попросимо завжди пояснювати, як використано бюджет, helpfulness у кейсах із бюджетом зросте щонайменше на 2 бали».
• «Якщо ми замінимо дорогу модель на "gpt-mini" у кроці rerank, cost_per_task впаде на 30 %, а конверсія не просяде більш ніж на 1 в. п.».
• «Якщо ми спростимо майстер (обʼєднаємо два кроки в один) і перепишемо CTA, activation‑rate зросте на 5 в. п.».

У коді таку гіпотезу зручно описувати явно — хоча б як обʼєкт:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "Що змінюємо і навіщо"
  targetMetric: string;  // e.g. "quality.helpfulness" або "conversion.checkout"
  successCriteria: string;
};

Так, це майже як завдання в Jira, але принаймні в типізованому вигляді.

Крок 3. Зробити контрольовану зміну

Тут важливі два слова: контрольована і роздільна.

Контрольована означає, що зміна оформлена як PR/commit, привʼязана до гіпотези, має changelog і, за можливості, feature‑flag або версію. Ви не просто «підправили промпт у продакшені», а можете чітко сказати, який саме реліз це приніс.

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

• зміните модель,
• перепишете половину system‑promptʼа,
• і додасте новий крок у UX,

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

З технічного боку зміни можуть бути де завгодно:

• system‑prompt агента (lib/prompt/systemPrompt.ts);
• описи MCP‑tools (description, inputSchema, annotations);
• конфіг агента (ліміти reasoning‑кроків, вибір моделі для конкретного tool);
• код віджета (CTA, порядок кроків, тексти помилок).

Крок 4. Перевірити, чи стало краще

Перевірку варто розділити на офлайн і онлайн.

Офлайн‑перевірка — це прогін golden‑кейсів через нову версію застосунку без реальних користувачів. Тут у вас уже є:

• LLM‑evals (модуль 20.1);
• threshold/baseline‑логіка (модуль 20.2).

Ви дивитеся, як змінилися quality‑score за цільовими сценаріями: зросли, впали чи лишилися такими самими. Також перевіряєте safety‑кейси: будь‑які правки промпта спочатку мають пройти через safety‑набір.

Онлайн‑перевірка — це експеримент на реальному трафіку. У найпростішому варіанті ви вмикаєте нову версію для N % користувачів і порівнюєте:

• конверсію в цільову дію (checkout, повторний запуск сценарію);
• cost_per_task;
• скарги/зворотний звʼязок.

Після цього цикл або закривається (гіпотезу підтверджено/спростовано й задокументовано), або породжує нову гіпотезу.

4. Внутрішній «асистент поліпшень» як окремий агент

Тепер найцікавіше: давайте надамо LLM‑моделі ще одну роль — не лише відповідати користувачам, а й допомагати вам поліпшувати застосунок. Це внутрішній агент, окремий від користувацького GiftGenius.

Що це за «звір»

Цей асистент живе у вашому внутрішньому середовищі (у тому самому репозиторії, у Dev Mode, в окремому ChatGPT App). Він:

• читає журнали та вибірки діалогів;
• дивиться на метрики;
• аналізує system‑prompt і описи tools;
• допомагає формулювати проблеми й пропозиції щодо змін.

По суті, ви отримуєте «віртуального продакт‑менеджера або аналітика», який:

• не втомлюється читати діалоги;
• швидко знаходить повторювані патерни;
• уміє писати чернетки промптів і changelog.

Який вхід він отримує

Корисно формалізувати вхідні дані, щоб агенту було простіше. Наприклад, тип:

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // з попереднього розділу
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

Ви можете зібрати такий обʼєкт, вивантаживши з журналів 10–20 невдалих діалогів за сценарієм "gift_selection" і додавши поточний system‑prompt та описи інструментів.

Який вихід він має дати

Також зручно зафіксувати очікувану відповідь:

export type ImprovementSuggestion = {
  patterns: string[];     // повторювані проблеми
  promptPatches: string[]; // пропозиції фрагментів для system-prompt
  toolsPatches: string[];  // ідеї щодо описів tools
  uxCopyIdeas: string[];   // варіанти UX-текстів
  changelog: string[];     // короткий список "що змінити"
};

Метапромпт для такого агента буде приблизно такий:

• «проаналізуй приклади та сигнали»;
• «опиши 2–3 патерни проблем»;
• «запропонуй по 1–2 зміни в промпті, в tools‑описах і в UX‑текстах»;
• «поверни все у суворо визначеному JSON».

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

5. Типи змін: що взагалі можна «налаштовувати»

Коли зʼявляється такий асистент і зрозумілий цикл, дуже легко звести все до «підкинь мені нову версію system‑promptʼа». Насправді поле поліпшень набагато ширше.

Промпт та інструкції

System‑prompt задає роль, тон, пріоритети та жорсткі правила (наприклад, бюджет, safety, порядок кроків). Його можна:

• спрощувати, прибираючи суперечливі або дубльовані інструкції;
• посилювати, додаючи відсутні правила (як у прикладі з бюджетом);
• пристосовувати до різних сценаріїв (окремі підпромпти для "gift_selection", "post_purchase_help" тощо).

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

• більш явних «Use this when… / Do not use when…»;
• уточнення формулювань (менше перетину з іншими tools);
• додавання інформації про наслідки (destructiveHint, isConsequential).

Safety‑правила — це частина промпта/описів, яка відповідає за поведінку у складних доменах. Їх краще змінювати лише після якісних safety‑evalʼів.

Архітектура поведінки (behavior)

Іноді проблему не розвʼязати промптом: потрібно змінювати порядок дій.

Приклади:

• додавати обовʼязковий крок уточнення параметрів перед викликом дорогого tool;
• виносити частину обчислень в окремий, дешевший крок (наприклад, попередню фільтрацію на backendʼі);
• обмежувати кількість послідовних tool‑викликів в одному сценарії.

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

UX і копірайтинг

Так, тексти на кнопках і в помилках — це теж частина якості. GiftGenius, який пише:

«Помилка 500. Зверніться до адміністратора»,

справляє зовсім інше враження, ніж:

«Не змогли отримати відповідь від магазину. Ваші вибрані ідеї нікуди не зникли — спробуйте оформити покупку трохи пізніше».

Проміжні екрани, підказки, структура майстрів — усе це впливає на той самий activation‑rate і конверсії, які ви вимірюєте.

Економіка

Тут ми граємо в добре знайому гру «якість ↔ вартість»:

• вибір моделі (дорога з reasoning, швидка/дешева);
• глибина reasoning/агентних кроків (скільки ітерацій допускаємо);
• ліміти діалогу (наприклад, не більше N перерахунків добірки за одну сесію);
• «дешеві» fallback‑режими, коли вичерпано бюджет за токенами/лімітами.

Сигнали звідси йдуть у cost_per_task, cost_per_user, маржу та поєднуються з quality‑score.

6. Guardrails: що не можна віддавати на відкуп LLM

Коли в системі зʼявляється «асистент поліпшень» і зручний цикл, дуже хочеться натиснути кнопку «Авто‑оптимізація» й піти пити каву. Давайте одразу домовимося, де така кнопка заборонена.

Зміни в дозволах (OAuth scopes, MCP‑інструменти, доступ до даних) — це завжди зона human‑in‑the‑loop. Жодна модель не повинна сама вирішувати, що тепер застосунок може читати замовлення, торкатися платежів або надсилати листи користувачам. Те саме стосується commerce‑флоу: будь‑які зміни довкола ACP/Stripe, лімітів, типів платежів і повернень проходять через людський перегляд та тестування.

Safety‑профіль застосунку (у яких доменах він має право радити, а де зобовʼязаний відмовляти) — теж не те, що варто доручати LLM. Модель може допомогти сформулювати текст правил, але рішення, яким темам ви довіряєте застосунок, залишається за вами.

Політика даних і логування (що логувати, скільки зберігати, як відповідати на запити на видалення даних) — у тому ж списку. LLM може підказати структуру Privacy Policy, але не повинен змінювати retention у коді без вашої участі.

Що можна напівавтоматизувати? Формулювання промптів, описи tools і UX‑тексти, пріоритети інструментів (у розумних межах), додаткові уточнювальні запитання. Усе це можна довірити асистентові як джерелу ідей, але останнє слово й перевірка — за людиною та eval‑скриптами.

7. End‑to‑end приклад циклу поліпшення (GiftGenius)

Повернімося до нашого героя.

Проблема

Користувач вказує бюджет, але GiftGenius часто пропонує подарунки дорожче цього ліміту. У журналах видно багато продовжень діалогу: «ні, це занадто дорого» і «зроби дешевше».

Сигнали

Спочатку ви бачите якість: LLM‑eval за golden‑кейсами типу «добери подарунок до 50 $» дає helpfulness близько 6/10. Суддя регулярно пише в reason, що «подарунки перевищують бюджет» або «не пояснено, як ураховано бюджет».

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

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

Аналіз за допомогою асистента поліпшень

Ви збираєте 20 діалогів, де користувачі скаржилися на ціну, і формуєте ImprovementInput:

• scenario = "gift_selection_with_budget";
• signals зі спадом helpfulness і конверсії;
• examples з діалогами;
• поточний system‑prompt і описи tools.

Подаєте це внутрішньому агенту поліпшень. У відповідь він видає, наприклад:

• Патерни:
  • бюджет, сформульований як «приблизно до 50 $», сприймається надто вільно;
  • system‑prompt не містить явної вимоги «ніколи не пропонувати подарунки дорожче ліміту»;
  • відповіді не пояснюють користувачеві, як саме враховано бюджет.
• Пропозиції:
  • додати в system‑prompt інструкцію про жорстке дотримання ліміту;
  • попросити модель завжди проговорювати, що «усі варіанти ≤ X»;
  • додати уточнювальне запитання, якщо бюджет звучить розмито («приблизно», «біля»).

Гіпотеза і зміна

Формулюєте гіпотезу:

«Якщо ми явно зафіксуємо жорстке дотримання ліміту й попросимо пояснювати використання бюджету, helpfulness за кейсами з бюджетом зросте щонайменше до 8/10, а конверсія в покупку — на 3 в. п.».

Вносите в system‑prompt такий фрагмент:

export const budgetRule = `
Якщо користувач указує бюджет (наприклад, "до 50$" або "приблизно 30€"),
сприймай цю суму як ЖОРСТКУ верхню межу.

Ніколи не пропонуй варіанти дорожче цього ліміту.
У кожній відповіді явно проговорюй, що всі варіанти вкладаються в бюджет
і як саме (наприклад: "усі подарунки не дорожче 45$").
`.trim();

І додаєте budgetRule до загального system‑prompt GiftGenius.

Offline‑валідація

Проганяєте набір golden‑кейсів «подарунки з бюджетом» через нову версію:

• LLM‑eval helpfulness зростає з 6.0 до 8.5;
• correctness теж зростає: бюджет дотримується;
• safety не погіршується (принаймні).

Якщо навпаки — helpfulness не зростає або safety падає — зміну не проходимо, а гіпотезу переглядаємо.

Online‑тест

Далі запускаєте експеримент:

• 10 % користувачів отримують нову версію промпта (варіант B);
• решта 90 % — стару (варіант A).

За тиждень дивитеся:

• конверсія workflow_completed → checkout_success для B стала, скажімо, 13 % замість 10 % у A;
• cost_per_task майже не змінився;
• частка діалогів зі скаргами на «занадто дорого» впала.

Експеримент визнано успішним.

Закріплення

Після цього:

• розгортаєте новий промпт на 100 % трафіку;
• додаєте новий golden‑кейс «мʼякий бюджет до 50 $» у регресійний набір;
• фіксуєте результат у changelog і, можливо, у технічних нотатках: щоб за пів року було зрозуміло, чому в промпті є настільки жорстке формулювання про бюджет.

Цикл закрито. Наступна ітерація може стосуватися, наприклад, рекомендацій для людей із дуже рідкісними захопленнями або оптимізації вартості добору.

8. Міні‑дорожня карта самовдосконалюваного застосунку

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

Версія 1.0: мінімальний improvement‑loop

На першому кроці достатньо трьох речей.

По‑перше, структурні журнали та базові SLO. Ви вже вмієте логувати tool_invocation, workflow_completed, checkout_* із requestId, userId, scenario, appVersion, costEstimateUsd. Поверх цього будуються SLO: latency, error‑rate, успішність checkout.

По‑друге, 10–20 golden‑кейсів і LLM‑eval‑скрипт. Невеликий, але добре підібраний набір прикладів за ключовими сценаріями + safety‑кейси. Один CLI‑скрипт, що проганяє їх через застосунок і суддю та видає JSON‑оцінки.

По‑третє, простий ритуал раз на два тижні. Сісти (самостійно або з командою) і відкрити:

• 2–3 дашборди за SLO, cost, продуктовими метриками;
• звіт LLM‑eval за golden‑кейсами;

і обрати 1–2 гіпотези для наступного циклу. Сформулювати, задокументувати, зробити невеликий реліз, перевірити.

Версія 2.0: «розумний» improvement‑loop

На наступному рівні зʼявляються:

Внутрішній асистент поліпшень. Це окремо описаний агент (або ChatGPT App), який приймає ImprovementInput і повертає ImprovementSuggestion. Він допомагає вам не витрачати години на ручний перебір діалогів.

Автоматизовані звіти. На основі журналів і evalʼів можна генерувати:

• кластери проблемних кейсів (наприклад, усі випадки, коли користувач переписував бюджет);
• готові до використання чернетки змін промптів і описів tools;
• короткий changelog.

CI‑хуки. Будь‑яка зміна промптів, конфігів агентів, descriptions інструментів автоматично запускає:

• функціональний golden‑suite;
• safety‑suite.

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

9. Практика

Вправа 1. Міні‑feedback‑loop для свого застосунку

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

Опишіть у довільній формі (або створіть невеликий improvement-plan.md):

Які сигнали будете відстежувати. По одному:

• технічний: наприклад, p95 latency по інструменту, який робить основну роботу;
• економічний: cost_per_task за цим сценарієм;
• продуктовий: конверсія workflow_started → workflow_completed або до цільової дії;
• якісний: середній quality_score за кількома golden‑кейсами для цього сценарію.

Далі зафіксуйте, які пороги ви вважаєте деградацією. Не «колись подивимося», а цілком конкретно:

• p95 > 5 с — погано;
• cost_per_task зріс більш ніж на 30 % без зростання виручки — тривога;
• quality_score упав нижче 7 — треба розбиратися.

І сформулюйте першу гіпотезу. Наприклад:

«Підозрюю, що ми ставимо забагато уточнювальних запитань. Якщо скоротити майстер на один крок і зробити запитання трохи загальнішими, то activation‑rate зросте, а helpfulness майже не постраждає. Перевірю це через невелику UX‑зміну та A/B‑експеримент».

Це вже не просто «поліпшимо UX», а цілком конкретний крок у циклі.

Вправа 2. Meta‑prompt для асистента поліпшень

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

• Описати, хто він: «Ти аналітик якості застосунку N, який…».
• Перелічити, який вхід він отримує: діалоги, сигнали, system‑prompt, descriptions.
• Сформулювати задачі:
  • знайти 2–3 патерни проблем;
  • запропонувати по 1–2 зміни в промпті, tools, UX‑текстах;
  • зібрати короткий changelog.
• Описати формат відповіді: структурований JSON з полями patterns, suggestions, changelog.

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

10. Типові помилки під час побудови циклу поліпшень

Помилка № 1: оптимізація лише під одну метрику.
Зосередитися на чомусь одному дуже спокусливо. Можна гнатися лише за cost, радіти зменшенню рахунку від OpenAI — і не помітити, як quality‑score, конверсії та retention поповзли вниз. Можна, навпаки, «підкрутити» якість до 10/10 на reasoning‑моделях і забути, що кожен сценарій став коштувати по долару. Цикл поліпшень має зважати на пакет метрик: якість ↔ гроші ↔ поведінка користувачів.

Помилка № 2: «магічні» промпт‑зміни без вимірювань.
Фраза «я переписав system‑prompt, тепер має бути краще» без golden‑кейсів і evalʼів — це спосіб улаштувати собі сюрприз за кілька тижнів. Будь‑яка зміна промпта — особливо в продакшені — повинна проходити через зрозумілий конвеєр: набір кейсів, LLM‑eval до/після, за потреби — онлайн‑експеримент. Інакше ви не поліпшуєте застосунок, а розкидаєте якість у випадковому напрямку.

Помилка № 3: авто‑деплой змін від LLM‑асистента.
Навіть якщо асистент поліпшень пише неймовірно красиві фрагменти промпта й переконливі описи інструментів, це не привід впроваджувати їх у продакшен без ревʼю. Модель може не бачити всіх бізнес‑обмежень, safety‑ризиків і контексту ваших метрик. Її роль — консультант, а не DevOps із правом релізу.

Помилка № 4: відсутність звʼязку змін із гіпотезою та сигналами.
Іноді команди роблять правки «за відчуттями» й не фіксують, який сигнал призвів до зміни та яку гіпотезу вони перевіряють. У підсумку за місяць ніхто не памʼятає, навіщо зʼявився дивний абзац у промпті й кому він узагалі був потрібен. Хороший PR із якості має відповідати щонайменше на три запитання: «що боліло?», «що ми змінюємо?», «за якою метрикою зрозуміємо, що стало краще?».

Помилка № 5: забути про safety під час поліпшень.
У гонитві за корисністю легко послабити safety‑обмеження, прибрати з промпта «зайві відмови» або забути прогнати safety‑кейси. Будь‑яка зміна system‑promptʼа, описів tools і agent‑behaviorʼа спочатку має проходити через safety‑eval‑набір. Якщо бодай один кейс, який раніше проходив, тепер провалюється, — це стоп‑сигнал, хоч би як красиво не виглядали решта метрик.

Помилка № 6: бажання «оптимізувати все й одразу».
Переписати половину промпта, змінити модель, додати ще один MCP‑tool і новий майстер — усе в одному релізі — звучить продуктивно, але повністю вбиває можливість зрозуміти, яка зміна дала ефект. Цикл поліпшень ефективний лише тоді, коли він ітеративний і сфокусований: одна‑дві гіпотези, невеликий набір змін, зрозумілий план відкату (rollback).

Помилка № 7: перетворювати цикл поліпшень на рідкісний «генеральний день прибирання».
Якщо ви раз на пів року влаштовуєте грандіозний «день якості», а решту місяців живете без evalʼів і аналізу метрик, застосунок більшу частину часу «плинутиме за течією». Набагато корисніший невеликий, але регулярний ритуал: раз на тиждень або раз на два тижні дивитися на сигнали, оновлювати гіпотези та робити маленькі кроки. Саме так ваш ChatGPT‑застосунок перестає бути статичним і починає справді самовдосконалюватися.