Как оценивать AI-фичи: практический фреймворк для продуктовых команд

Оценка AI-фич сложнее, чем CRUD-сайзинг — happy path врёт. Трёхосевой фреймворк для скоупинга AI: допустимая точность, восстановимость и экспозиция данных.

Фреймворк оценки AI-фич — трёхосевая матрица риска

Оценка CRUD-фичи — это привычка. Оценка AI-фичи — это спор. Модель работает в демо, падает 8% в реальном использовании, и эти 8% — ровно там, где живут ваши пользователи. Вот фреймворк, который мы сейчас применяем перед тем, как назвать клиенту число.

Три оси оценки AI-фич

Каждую AI-фичу в сайзинге мы кладём на три оси. Допустимая точность — насколько неправильным может быть вывод, пока пользователю всё равно. Восстановимость — если модель ошиблась, сколько стоит восстановление. Экспозиция данных — что модель должна увидеть, и каков blast radius при утечке.

Трёхосевая матрица оценки AI-фичи — Каждая AI-фича попадает на трёхосевую матрицу ещё до получения числа.

Матрица — не игрушка для скоринга. Две фичи с одинаковым счастливым путём расходятся втрое, как только восстановление и доступ к данным оказываются на одном листе с точностью.

Фреймворк вырос из оценок, которые мы завалили, а не из сессии у доски. Ролик ниже — студия, где такие разборы и проходят.

Ролик студии.

Что мы неправильно делали в AI-оценке

Наш первый год AI-оценок был по сути софт-оценкой плюс fudge-коэффициент. Скоупили happy path, умножали на 1.5 — и всё. Стабильно упускали eval-харнесс, fallback UI и human-in-the-loop. Ни одно из этого не опционально в проде; всё это невидимо в демо.

Одна страница, которую мы заполняем на каждую AI-фичу

Каждая новая AI-фича — один документ. Определение задачи в один абзац. Пол точности одним числом. Fallback UI двумя скетчами. Human-in-the-loop путь — диаграммой. Data footprint — списком пунктов. Если хоть одно из этих пяти замахнули рукой — фича не готова к оценке.