Войти
Многие LLM-as-a-Judge фейлятся просто потому, что «судья» слишком вежлив. Он с радостью закрывает глаза на критические нарушения бизнес-логики только потому, что не хочет огорчать пользователя.
Многие спрашивают, как мне живется в моей новой роли. Этот пост - ответ на вопрос.
ИИ может за час сделать то, на что раньше уходили недели. Но готовы ли вы выкатить этот результат в прод без код-ревью от сеньора?
В сфере ML Evaluation, особенно при использовании подхода LLM-судьи, мы часто попадаемся в ловушку «гало-эффекта» (Halo Effect). Если ответ тестируемой AI-модели звучит авторитетно и профессионально, LLM-судья автоматически ставит высокий балл, напрочь упуская из виду смысл.
Идея этого поста пришла мне в голову, когда неделю назад мы с менторами, SDET крупных международных компаний, на регулярной встрече обсуждали перспективы рынка автоматизаторов и пришли к довольно интересным выводам. Ещё несколько лет назад путь из manual QA в автоматизацию был очевидным апгрейдом:
Когда вы используете одну LLM для оценки других, прилагательные в промптах работают против вас. Слова вроде «хорошо», «плохо», «вежливо» - это размытые ярлыки, которые судья интерпретирует через призму своих обучающих данных, а не вашей бизнес-логики.
Если вы используете одну LLM для оценки других, всегда лучше иметь под рукой «золотой стандарт» для сравнения. В противном случае ваш «судья» полагается только на собственную память и может галлюцинировать гораздо чаще, особенно в узкопрофессиональной нише.
Традиционный QA, даже вооруженный до зубов AI-инструментами, принципиально не отличается от тестирования без них. Вы планируете покрытие, опираясь на классический тест-дизайн:
Ранее меня просили рассказать про subj. Итак, домашнее задание по оценке навыков ML Evaluation Engineer:
Если вы задумываетесь о переходе из QA в ML-инженеры, стоит начать с изучения основных концепций больших языковых моделей (LLM) и способов оценки их результатов. Одна из ключевых идей здесь - оценка работы «младшей» модели с помощью «старшей» (вместо или вместе с проверкой человеком).
Один мой день (разумеется, без нарушения NDA!). 09:30 – 10:30 Смена архитектуры Начала день с синка по нашему агентскому воркфлоу (agentic workflow).
На рынке сейчас царит терминологическая путаница: под вывеской "AI тестирования" скрываются три принципиально разные роли, и смешивать их при найме или поиске работы - дорогая ошибка.
Если вы работаете QA automation и посматриваете в сторону AI, то моя история смены специализации может вам пригодиться. Некоторое время назад я перешла из QA в ML evaluation.
Лекция преподавателя школы Николая Мишина.
Доклад преподавателя школы Сергея Герасимова на Agile Kitchen.
Доклад преподавателя школы Сергея Герасимова на Analyst Days.
Доклад преподавателя школы Лилии Урмазовой на SQA Days EU, Рига, Латвия (английский язык).
Доклад преподавателя школы Лилии Урмазовой на Dynamic Talks, Белград, Сербия (английский язык).
Доклад преподавателя школы Лилии Урмазовой на AnalystDays.
Вебинар преподавателя школы Сергея Герасимова, посвященный часто задаваемым вопросам о найме начинающих тестировщиков в ведущие компании Москвы и Петербурга.
На вебинаре от Mentorpiece мы расскажем начинающим тестировщикам о том, что такое автоматизация тестирования и кто такие тестировщики-автоматизаторы. Стоит ли идти в автоматизацию, минуя ручное тестирование?
Какие бывают типы, виды, уровни и подходы к тестированию? Как эти понятия соотносятся друг с другом?