Comments 5
Хорошая мысль, что оценивать надо не модель, а всю систему. Без evals под реальные сценарии легко принять красивое демо за рабочий продукт.
Спасибо за систематизацию. В production я бы ещё добавил отдельный слой evals для маршрутизации между моделями: фиксировать не только качество ответа, но и latency, cost, timeout/ошибки, долю fallback и стабильность на одинаковом наборе задач. Иначе при переходе между провайдерами кажется, что достаточно поменять model/base_url, а фактически меняется распределение ошибок и поведение на edge cases.
На практике хорошо работает небольшой regression-набор из реальных запросов плюс регулярный прогон по нескольким моделям до релиза.
Я сам часто с таким сталкиваюсь. Regression-набор правда спасает в этом смысле.
Можете поделиться опытом изменения распределения ошибок при замене провайдера?Интересно, есть ли какой-то конкретный пример изменений на edge cas'ах, и какие-то наблюдения по типу "Модель M у провайдера A дает другое качество, по сравнению с провайдером B"?
Агент, который удалил прод и потом сам же написал что сделал катастрофическую ошибку, это уже не баг, а готовый сценарий для филосовской драмы - агент я дрожащий или правое все удалить имею?)
Evals: что должен знать каждый AI-инженер в 2026