Самосовершенствующийся App: замкнутый цикл улучшений

1. Зачем App нужен замкнутый цикл улучшений

Любой LLM‑App живёт в меняющемся мире. У вас появляются новые пользователи и сценарии, OpenAI выкатывает новые модели и защитные механизмы, вы сами обновляете MCP‑сервер, Agents SDK, UI‑виджет… И даже если бы весь код был написан идеально (да‑да, я знаю, что вы почти так и делаете), одна смена модели или промпта может незаметно сломать половину кейсов.

Без цикла улучшений жизнь выглядит так. Пользователь пишет в поддержку: «GiftGenius начал предлагать подарки дороже бюджета» или «сидит и думает по 15 секунд». Вы открываете логи, что‑то правите в system‑prompt’е, переключаете модель, выкатываете. Через неделю всё повторяется, но в другом месте. На выходе — хронический пожар и куча «магических» изменений, которые никто не может объяснить.

С циклом всё по‑другому. У вас есть:

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

Тогда App превращается из «застывшего промпта» в живую систему, которая:

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

Плюс бонус: такой цикл очень хорошо ложится на всё, что вы уже сделали в предыдущих модулях. Логи и SLO из М17 дают технические сигналы, cost‑инструментация и AARRR из М19 — экономические и продуктовые, golden‑кейсы и LLM‑evals из М20.1–2 — сигналы качества. Осталось только связать это в понятный операционный цикл.

2. Карта сигналов для улучшений

Чтобы App мог сам подсказывать, где его улучшать, нужно чётко понимать, какие сигналы у вас вообще есть и откуда они берутся. Удобно мыслить четырьмя группами.

Технические сигналы приходят из вашего observability‑стека: логи tool_invocation, метрики latency и error‑rate, health‑чеки 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. Это то, что ближе всего к ощущению «App стал умнее/глупее».

Удобно собрать это в таблицу:

Ключевой момент: все эти сигналы логируются с привязкой к конкретному сценарию и версии App. То есть в событиях фигурируют хотя бы 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 п.п.».
• «Если мы упростим wizard (объединим два шага в один) и перепишем 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 и, по возможности, фиче‑флаг или версию. Вы не просто «подправили промпт в проде», а можете сказать, какой именно релиз это принёс.

Раздельное означает, что вы стараетесь не мешать в одном релизе сразу три разных гипотезы. Если вы одновременно:

• смените модель,
• перепишете half system‑prompt’а,
• и добавите новый шаг в UX,

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

С технической стороны изменения могут быть где угодно:

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

Шаг 4. Проверить, стало ли лучше

Проверка делится на offline и online.

Offline‑проверка — это прогон golden‑кейсов через новую версию App без реальных пользователей. Здесь у вас уже есть:

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

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

Online‑проверка — это эксперимент на реальном трафике. В простейшем варианте вы включаете новую версию для N% пользователей и сравниваете:

• конверсию в целевое действие (checkout, повторный запуск сценария);
• cost_per_task;
• жалобы/фидбек.

После этого цикл либо закрывается (гипотеза подтверждена/опровергнута и задокументирована), либо порождает новую гипотезу.

4. Внутренний «ассистент улучшений» как отдельный агент

Теперь самое вкусное: давайте дадим LLM‑модели ещё одну роль — не только отвечать пользователям, но и помогать вам улучшать App. Это внутренний агент, отдельный от пользовательского 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[];     // краткий список "что поменять"
};

Meta‑prompt для такого агента будет примерно:

• «проанализируй примеры и сигналы»;
• «опиши 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 и copywriting

Да, тексты на кнопках и в ошибках — это тоже часть качества. GiftGenius, который пишет:

«Ошибка 500. Обратитесь к администратору»,

создаёт совсем другое впечатление, чем:

«Не смогли получить ответ от магазина. Ваши выбранные идеи никуда не пропали, попробуйте оформить покупку чуть позже».

Промежуточные экраны, подсказки, структура мастеров — всё это влияет на того самого activation‑rate и конверсии, которые вы меряете.

Экономика

Здесь мы играем в хорошо знакомую игру «качество ↔ стоимость»:

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

Сигналы отсюда идут в cost_per_task, cost_per_user, маржу и совмещаются с quality‑score.

6. Guardrails: что нельзя отдавать на откуп LLM

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

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

Safety‑профиль App (в каких доменах он имеет право советовать, где обязан отказывать) — тоже не то, что стоит перепоручать LLM. Модель может помочь сформулировать текст правил, но решение, каким темам вы доверяете App, остаётся за вами.

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

Что можно полуавтоматизировать? Формулировки и wording промптов, описаний tools и UX‑текстов, приоритеты инструментов (в разумных пределах), дополнительные уточняющие вопросы. Всё это можно доверить ассистенту как источнику идей, но последне слово и проверка за человеком и eval‑скриптами.

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

Вернёмся к нашему герою.

Проблема

Пользователь указывает бюджет, но GiftGenius часто предлагает подарки дороже этого лимита. В логах видно много продолжений диалога «нет, это слишком дорого» и «сделай дешевле».

Сигналы

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

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

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

Анализ с помощью ассистента улучшений

Вы собираете 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% пользователей получают новую версию промпта (variant B);
• остальные 90% — старую (variant A).

Через неделю смотрите:

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

Эксперимент признан успешным.

Закрепление

После этого:

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

Цикл закрыт. Следующая итерация может касаться, например, рекомендаций для людей с очень редкими увлечениями или оптимизации стоимости подбора.

8. Мини‑дорожная карта самосовершенствующегося App

Чтобы это не выглядело как «ещё 100500 задач сверху», полезно увидеть, какой минимум нужен, чтобы App уже считался самосовершенствующимся, и что можно добавить потом.

Версия 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‑скрипт, который прогоняет их через App и судью и выдаёт JSON‑оценки.

В‑третьих, простой ритуал раз в 2 недели. Сесть (в одиночку или с командой), открыть:

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

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

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

На следующем уровне появляются:

Внутренний ассистент улучшений. Это отдельно описанный агент (или ChatGPT App), который принимает ImprovementInput и возвращает ImprovementSuggestion. Он помогает вам не тратить часы на ручной перебор диалогов.

Автоматизированные отчёты. На основе логов и eval’ов можно генерировать:

• кластеры проблемных кейсов (например, все случаи, когда пользователь переписывал бюджет);
• ready‑to‑use черновики изменений промптов и описаний tools;
• короткий changelog.

CI‑хуки. Любое изменение промптов, конфигов агентов, descriptions инструментов автоматически запускает:

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

Если safety‑кейсы падают или качество ключевых сценариев перестаёт проходить пороги — сборка красная, релиза нет.

9. Практика

Упражнение 1. Мини‑feedback‑loop для своего App

Возьмите один ключевой сценарий своего приложения. Для 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 — нужно разбираться.

И сформулируйте первую гипотезу. Например:

«Подозреваю, что мы задаём слишком много уточняющих вопросов. Если сократить wizard на один шаг и сделать вопросы чуть более общими, то activation‑rate вырастет, а helpfulness почти не пострадает. Проверю это через небольшое UX‑изменение и A/B‑эксперимент».

Это уже не просто «улучшим UX», а вполне конкретный шаг в цикле.

Упражнение 2. Meta‑prompt для ассистента улучшений

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

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

Даже если вы пока не будете вызывать этого агента из кода, один такой промпт уже поможет вам лучше структурировать размышления о том, как вы улучшаете App.

10. Типичные ошибки при построении цикла улучшений

Ошибка №1: оптимизация только под одну метрику.
Сосредоточиться на чём‑то одном очень соблазнительно. Можно гнаться только за cost, радоваться падению счёта от OpenAI — и не заметить, как quality‑score, конверсии и retention поползли вниз. Можно, наоборот, закрутить качество до 10/10 на reasoning‑моделях и забыть, что каждый сценарий стал стоить по доллару. Цикл улучшений должен смотреть на пакет метрик: качество ↔ деньги ↔ поведение пользователей.

Ошибка №2: «магические» промпт‑изменения без измерений.
Фраза «я переписал system‑prompt, теперь должно быть лучше» без golden‑кейсов и eval’ов — это способ устроить себе сюрприз через пару недель. Любое изменение промпта — особенно в продакшене — должно проходить через понятный pipeline: набор кейсов, LLM‑eval до/после, при необходимости — online‑эксперимент. Иначе вы не улучшаете App, а разбрасываете качество в случайном направлении.

Ошибка №3: авто‑деплой изменений от LLM‑ассистента.
Даже если ассистент улучшений пишет невероятно красивые фрагменты промпта и убедительные описания инструментов, это не повод пушить их в прод без ревью. Модель может не видеть всех бизнес‑ограничений, safety‑рисков, контекста ваших метрик. Её роль — консультант, а не DevOps с правом релиза.

Ошибка №4: отсутствие связи изменений с гипотезой и сигналами.
Иногда команды делают правки «по ощущениям» и не фиксируют, какой сигнал привёл к изменению и какую гипотезу они проверяют. В итоге через месяц никто не помнит, зачем появился странный абзац в промпте и кому он вообще был нужен. Хороший PR по качеству должен отвечать минимум на три вопроса: «что болело?», «что мы меняем?», «по какой метрике поймём, что стало лучше?».

Ошибка №5: забыть про safety при улучшениях.
В погоне за полезностью легко ослабить safety‑ограничения, убрать из промпта «лишние отказы» или забыть прогнать safety‑кейсы. Любое изменение system‑prompt’а, описаний tools и agent‑behavior’а сначала должно проходить через safety‑eval‑набор. Если хоть один кейс, который раньше проходил, теперь проваливается, — это стоп‑сигнал, как бы красиво ни выглядели остальные метрики.

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

Ошибка №7: превращать цикл улучшений в редкий «генеральный уборочный день».
Если вы раз в полгода устраиваете грандиозный «день качества», а остальные месяцы живёте без eval’ов и анализа метрик, App будет большую часть времени «плыть по течению». Гораздо полезнее маленький, но регулярный ритуал: раз в неделю/две смотреть на сигналы, обновлять гипотезы и делать маленькие шаги. Именно так ваш ChatGPT App перестаёт быть статичным и начинает действительно самосовершенствоваться.