Уставший техдир

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

— Типа это какие-то люди, которым не хватает навыка писать код, они "всего лишь" проверяют за меня, великого разработчика, как нажимаются кнопки — слышал такое мнение пару раз (осуждаю).
— А что стоит твой код, очень красивый, весь такой на правильной чистой архитектуре и модных фреймворках, если он "работает только на твоем компьютере?"
— То есть твой код не работает в реальных условиях, а в дураках его потребитель?

Качество начинается с культуры владения, ответственности разработчиков за результат и процессов, в которых они реализует проверки, гейты, метрики и наблюдаемость. Но, еще сложнее обстоят дела, когда мы разрабатываем LLM-продукты. Они не детерминированы, тут надо проверять, как ведёт себя непредсказуемая, вероятностная хрень, которая ещё и каждый раз отвечает по-разному.

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

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

🔥15🤔4👍3❤2🫡2

www.group-telegram.com/jp/tired_glebmikheev.com/2188

4.23K viewsOct 8 at 07:38

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

— Типа это какие-то люди, которым не хватает навыка писать код, они "всего лишь" проверяют за меня, великого разработчика, как нажимаются кнопки — слышал такое мнение пару раз (осуждаю).
— А что стоит твой код, очень красивый, весь такой на правильной чистой архитектуре и модных фреймворках, если он "работает только на твоем компьютере?"
— То есть твой код не работает в реальных условиях, а в дураках его потребитель?

Качество начинается с культуры владения, ответственности разработчиков за результат и процессов, в которых они реализует проверки, гейты, метрики и наблюдаемость. Но, еще сложнее обстоят дела, когда мы разрабатываем LLM-продукты. Они не детерминированы, тут надо проверять, как ведёт себя непредсказуемая, вероятностная хрень, которая ещё и каждый раз отвечает по-разному.

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

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

BY Уставший техдир