В классической разработке разработчики системно недооценивают QA

— Типа это какие-то люди, которым не хватает навыка писать код, они "всего лишь" проверяют за меня, великого разработчика, как нажимаются кнопки — слышал такое мнение пару раз (осуждаю). — А что стоит твой код, очень красивый, весь такой на правильной чистой архитектуре и модных фреймворках, если он "работает только на твоем компьютере?" — То есть твой код не работает в реальных условиях, а в дураках его потребитель? Качество начинается с культуры владения****, ответственности разработчиков за результат и процессов, в которых они реализует проверки, гейты, метрики и наблюдаемость. Но, еще сложнее обстоят дела, когда мы разрабатываем LLM-продукты. Они не детерминированы, тут надо проверять, как ведёт себя непредсказуемая, вероятностная хрень, которая ещё и каждый раз отвечает по-разному. И если в классической разработке хватает одного-двух тестировщиков, то в LLM-продуктах нужна целая evaluation-команда, которая системно ищет слабые места модели и превращает их в датасеты для проверки поведения агента. Каждый пример фиксирует конкретное ожидаемое или проблемное поведение, а на таких кейсах — «как должно быть» и «где ломается» — строятся метрики качества. Чем лучше агент проходит эти испытания, тем стабильнее и предсказуемее он ведёт себя в реальных условиях.

Если интересно, как это работает в реальной жизни — обязательно почитайте историю, как ребят позвали спасти чужой продукт, разработанный на ручных проверках качества, и как они за 7 дней, eval-driven подходом дотянули его до вменяемого качества


В этом посте были ссылки, но мы их удалили по правилам Сетки

В классической разработке разработчики системно недооценивают QA
— Типа это какие-то люди, которым не хватает навыка писать код, они "всего лишь" проверяют за меня, великого разработчика, как нажимают... | Сетка — социальная сеть от hh.ru