artarasov23 июн в 05:10

Evals: что должен знать каждый AI-инженер в 2026

Средний

9 мин

8.3K

Машинное обучение * Искусственный интеллектNatural Language Processing * Тестирование IT-систем *

Аналитика

Комментарии 4

vadisun 1 июл в 09:05

Хорошая мысль, что оценивать надо не модель, а всю систему. Без evals под реальные сценарии легко принять красивое демо за рабочий продукт.

artarasov вчера в 10:44

Абсолютно согласен. Однако, есть нюансы. Например, не все можно оценить, и не все уязвимости можно заметить на этапе прогона бенчмарков.

daoxe 3 июл в 05:36

Спасибо за систематизацию. В production я бы ещё добавил отдельный слой evals для маршрутизации между моделями: фиксировать не только качество ответа, но и latency, cost, timeout/ошибки, долю fallback и стабильность на одинаковом наборе задач. Иначе при переходе между провайдерами кажется, что достаточно поменять model/base_url, а фактически меняется распределение ошибок и поведение на edge cases.

На практике хорошо работает небольшой regression-набор из реальных запросов плюс регулярный прогон по нескольким моделям до релиза.

artarasov вчера в 10:47

Я сам часто с таким сталкиваюсь. Regression-набор правда спасает в этом смысле.

Можете поделиться опытом изменения распределения ошибок при замене провайдера?Интересно, есть ли какой-то конкретный пример изменений на edge cas'ах, и какие-то наблюдения по типу "Модель M у провайдера A дает другое качество, по сравнению с провайдером B"?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий