AI PRD: пять обязательных элементов требований к ИИ-продукту
Claude и Qwen поспорили, что джун поймёт: токены или VRAM
Статья объясняет, почему PRD для ИИ-продуктов нельзя писать как обычное техническое задание. Вместо жёстких пар «вход — выход» нужно описывать вероятностные условия и границы приемлемого поведения. Автор выделяет пять обязательных элементов: измеримые критерии оценки, допустимые ошибки и пороги успеха, список запрещённых действий, бюджет на использование модели, а также точки участия человека и условия отката. На примере чат-бота поддержки показано, как такая спецификация помогает безопасно выводить ИИ-функции в продакшен. Материал полезен продакт-менеджерам и разработчикам, которые переходят от детерминированного ПО к системам с непредсказуемыми ответами.
Статья на примере записи альбома Майлза Дэвиса Kind of Blue объясняет, почему требования к ИИ-продуктам должны быть устроены иначе, чем привычные PRD. Дэвис не прописывал музыкантам каждую ноту, а задавал границы: тональность, настроение и форму, внутри которых допускалась свободная импровизация. При этом сами границы были строгими: выход за них считался ошибкой. По мнению автора, это точная метафора для AI PRD. Обычный PRD был детерминированной спецификацией: у каждой кнопки был один ожидаемый результат, и тестировщик проверял соответствие этому результату. С ИИ такой подход не работает, потому что на один и тот же вопрос модель может отвечать по-разному, а возможные формулировки пользователей бесконечны. Поэтому AI PRD должен быть вероятностной спецификацией: описывать не точный ответ, а условия, которым ответ должен удовлетворять, и границы допустимого. Автор выделяет пять обязательных элементов. Первый — измеримые критерии оценки. Вместо фразы «на вопрос о возврате отвечай, что деньги можно вернуть в течение семи дней» нужно писать требования: ответ должен опираться на политику возвратов, не выдумывать отсутствующие условия и сохранять вежливый тон, а проверять его нужно по фактическому совпадению с документом. Второй — успешность и допустимые ошибки. Нужно численно определить, какой процент ответов достаточно хорош, и заранее согласовать, какие ошибки допустимы. Например, честный ответ «я не знаю» лучше признать успехом, чем выдуманную информацию. Третий — запрещённые действия. Это не просто плохие ответы, а красные линии, которые нельзя переходить ни при каком качестве остальных ответов; их считают не в процентах, а нулём инцидентов. Четвёртый — бюджет. В отличие от классического софта, ИИ потребляет ресурсы при каждом запросе, поэтому PRD должен фиксировать ограничения по стоимости и времени, иначе после запуска можно получить неожиданно большой счёт. Пятый — человеческие контрольные точки и условия отката. Поскольку модель может незаметно деградировать, нужно заранее определить, в каких местах подключается человек и при каком пороге продукт откатывается к предыдущей версии. Автор предлагает прямо сейчас открыть PRD текущей ИИ-функции, найти раздел с примерами «вход — выход» и переписать его в формате «условия, которым должен удовлетворять выход, плюс способ измерения». Пустой пункт в чек-листе из пяти элементов указывает на главный риск продукта. Также рекомендуется договориться с командой хотя бы об одном предложении: какое поведение для продукта абсолютно недопустимо. Такой список запретов защищает продукт надёжнее, чем длинный список желаемых результатов. Статья завершается мыслью, что долговечность Kind of Blue связана с тем, что Дэвис не пытался контролировать всё.