AI-продукту одного PRD уже недостаточно
Документ с требованиями к продукту (PRD) фиксирует, что продукт должен делать. Но после изменения модели, промпта, скилла или агента нужно ещё проверить, стало ли лучше.
Мы создали внутренний продукт, который берёт задачу из трекера, передаёт её агенту и возвращает Merge Request. Отслеживаем, решена ли задача, сколько времени и ручных вмешательств потребовалось. Но рост доли принятых изменений ещё не доказывает, что система стала лучше. В выборку могли попасть задачи, меньшие по объёму, с меньшим числом затронутых файлов и более полными требованиями. Продуктовые метрики нужны, но сравнение качества на одинаковых задачах они не заменяют.
Evals
Есть такая штука как evals. Это повторяемые проверки на заранее выбранных задачах с критериями успеха. По сути, это контрольная работа (эксперимент? контролируемый эксперимент?), где задания одинаковые, а мы меняем систему и сравниваем результат. Проверяем выполнение требований, прохождение тестов, отсутствие лишних изменений и стабильность при повторных запусках. Считаем время и стоимость именно успешно решённой задачи, а не одного запуска. Такой набор дополняет PRD конкретными примерами и исполняемыми проверками, но не заменяет требования.
Где применять
Сравнивать можно что угодно, от моделей и настроек агента до промптов из интернета. Сейчас проверяем свою обвязку, включая скиллы, правила, системные инструкции, MCP, доп. инструменты и цепочки агентов. О том, что она устаревает вместе с развитием моделей, уже много людей писали. То, что раньше помогало, после обновления модели может начать мешать, добавлять лишний шаг, раздувать контекст или конфликтовать с другими настройками. Поэтому главный вопрос не что ещё добавить, а когда пора удалить старое, вместо того чтобы громоздить сверху новую инструкцию.
Как используем
Написали скрипт, который синхронизирует настройки для разных провайдеров и прогоняет одинаковые задачи с конкретным скиллом и без него. Если при повторных проверках без скилла качество не падает, а затраты ниже, мы его убираем. После появления новых моделей в работе полезность проверяем заново. Так обвязка не только накапливается, но и со временем сокращается.
Кстати, для синхронизации файлов и настроек между репами есть RuleSync (Гриша, спасибо за наводку!).
Итог
Зрелость AI-продукта не в количестве настроек вокруг модели, а в способности доказать их пользу. PRD фиксирует, какого поведения мы ждём, evals помогают проверить, получаем ли мы его после изменений. Поэтому новая фича для нас не улучшение по умолчанию, а гипотеза. Иногда лучший результат такой проверки в том, чтобы с гордостью удалить то, что сам же неделю назад написал.
P.S. В Claude Code есть похожий подход для проверки плагинов и скиллов.
#kts #ai #evals
Документ с требованиями к продукту (PRD) фиксирует, что продукт должен делать. Но после изменения модели, промпта, скилла или агента нужно ещё проверить, стало ли лучше.
Мы создали внутренний продукт, который берёт задачу из трекера, передаёт её агенту и возвращает Merge Request. Отслеживаем, решена ли задача, сколько времени и ручных вмешательств потребовалось. Но рост доли принятых изменений ещё не доказывает, что система стала лучше. В выборку могли попасть задачи, меньшие по объёму, с меньшим числом затронутых файлов и более полными требованиями. Продуктовые метрики нужны, но сравнение качества на одинаковых задачах они не заменяют.
Evals
Есть такая штука как evals. Это повторяемые проверки на заранее выбранных задачах с критериями успеха. По сути, это контрольная работа (эксперимент? контролируемый эксперимент?), где задания одинаковые, а мы меняем систему и сравниваем результат. Проверяем выполнение требований, прохождение тестов, отсутствие лишних изменений и стабильность при повторных запусках. Считаем время и стоимость именно успешно решённой задачи, а не одного запуска. Такой набор дополняет PRD конкретными примерами и исполняемыми проверками, но не заменяет требования.
Где применять
Сравнивать можно что угодно, от моделей и настроек агента до промптов из интернета. Сейчас проверяем свою обвязку, включая скиллы, правила, системные инструкции, MCP, доп. инструменты и цепочки агентов. О том, что она устаревает вместе с развитием моделей, уже много людей писали. То, что раньше помогало, после обновления модели может начать мешать, добавлять лишний шаг, раздувать контекст или конфликтовать с другими настройками. Поэтому главный вопрос не что ещё добавить, а когда пора удалить старое, вместо того чтобы громоздить сверху новую инструкцию.
Как используем
Написали скрипт, который синхронизирует настройки для разных провайдеров и прогоняет одинаковые задачи с конкретным скиллом и без него. Если при повторных проверках без скилла качество не падает, а затраты ниже, мы его убираем. После появления новых моделей в работе полезность проверяем заново. Так обвязка не только накапливается, но и со временем сокращается.
Кстати, для синхронизации файлов и настроек между репами есть RuleSync (Гриша, спасибо за наводку!).
Итог
Зрелость AI-продукта не в количестве настроек вокруг модели, а в способности доказать их пользу. PRD фиксирует, какого поведения мы ждём, evals помогают проверить, получаем ли мы его после изменений. Поэтому новая фича для нас не улучшение по умолчанию, а гипотеза. Иногда лучший результат такой проверки в том, чтобы с гордостью удалить то, что сам же неделю назад написал.
P.S. В Claude Code есть похожий подход для проверки плагинов и скиллов.
#kts #ai #evals