То есть вам нужно не закрывать своими руками каждый неправильный кейс, а дизайнить систему, в которой операционная команда сможет самостоятельно закрывать эти кейсы по очень хорошему курсу размена эффектов на усилия. Ваша система обречена если инженер должен будет своими глазами смотреть каждый отвал и писать каждый доп кейс в промпт. Так что работая над ошибками системы нужно дизайнить систему, в которой кто-то другой увидив глазами этот кейс сделал бы именно то, что вам нужно (добавил бы примером в тренировку, переразмеиил, добавил бы кубик в граф вычислений, etc). У всех этих операционных процессов, обусловленных дизайном системы есть своя стоимость операции и отдача на усилия. И у зрелых команд гипотезы оцениваются не только по изменению метрики в моменте, а еще и по стоимости обслуживания процесса в долгосроке. Если бы я мог вернуться к себе десятилетней давности, то я был дал ровно один совет: «каждый твой шаг в МЛ должен радикально снижать неопределенность». Если руководствоваться этим мотто, то здоровый воркфлоу мл проекта сложится сам собой.
Лидерство и ИИ [Артем Бондарь]
Subscribers
854
tracking since 14 Nov
Reach per post (ERR)
82.1%701 avg views
Posting
1.6/week
last 4 days ago
Reactions per 1K views
32.8
❤ 🔥 👍
Views over time
| When | Views |
|---|---|
| 11 May 2026, 09:21 | 0 |
| 14 Nov 2026, 02:47 | 902 |
Who shared this post
Posts in other channels we index that link to this one. (Forwards with a hidden source can't be traced.)
Nobody yet.