Пост В AI разработке только и разговоров что об evals)

В AI разработке только и разговоров что об evals) Что это за зверь такой? По сути это приемочные тесты, наличие которых - базовое отличие разработки с AI от вайб-кодинга. Что это на практике? Если речь про архитектуру и аналитику: 1) проверки формата полученного артефакта - структура файлов, структура разделов внутри, 2) наличие обязательных элементов 3) единообразие терминов 4) ограничение по размеру 5) банально правильная нумерация разделов и ссылок Если речь про разработку - сразу стоит подсветить важный нюанс. Агент сам пишет тесты и даже следует TDD (см. предыдущие серии) И поэтому рассматривать наличие тестов как eval - неправильно, мы их содержимым особо не управляем. Но при этом тесты - лучшие eval. Поэтому в самой постановке задачи должны быть проверяемые требования, которые превратятся в генерируемые агентом тесты. unit или интеграционные - не критично, зависит от уровня, на котором можно проверить работу фичи. И вот наличие таких приемочных тестов и их прохождение - это уже evals. Также evals - это успешные проверки линтеров (Checkstyle к примеру) и внешних статических анализаторов кода (SonarQube, Checkmarx, ...). Сюда же процент покрытия тестами нового кода из SonarQube. С линтерами есть важный момент - агент в теории может поменять их настройки. Это запрещается через хуки, есть такой хук в ECC плагине https://t.me/javaKotlinDevOps/610 Можно втащить к себе в проект как часть плагина или просто позаимствовать адаптировав под свои файлы настроек. Еще в качестве evals могут выступать: - запрет на использование тех или иных библиотек\классов (по всему проекту или в отдельных модулях) - запрет циклических ссылок (spring beans, ArchUnit) - запрет на "ломающие" изменения в API или БД - наличие JavaDoc в определенных местах - требования к SQL скриптам, например, наличие CREATE INDEX CONCURRENTLY - время выполнения вызова ... В общем все, что выполняется достаточно быстро и без сложных интеграций, имеет смысл сделать evals и проверять пораньше. Ну и один из самых важных evals - соответствие реализации постановке. В целом все это уже должно было проверяться в CI pipeline с одним исключением, о котором ниже. Как оформить evals? Как и все остальное - в виде скила. И тут еще один важный нюанс. Любую проверку можно выполнить 3 способами: - запуск кода (тест или shell скрипт) - просьба сделать проверку агенту - запуск нового CLI агента в headless режиме Всегда, когда это технически возможно, стоит использовать первый вариант. Почему? AI все-таки по природе своей ленив - любит быстро достигать результата. Т.е. на явную просьбу что-то проверить в скиле он может сказать: "все ок"- ничего не проверяя. Или даже написать - проверь сам. Да, он может "подшаманить" скрипт проверки, чтобы пройти дальше. С последним нужно бороться хуками с запретом на редактирование. А с первым как раз помогает "хардкод" проверки. А еще вызов LLM всегда дороже по времени. Если же технически невозможно написать скрипт - как, например, для проверки соответствия кода и аналитики - тогда имеет смысл запускать такое ревью в отдельном субагенте. И по возможности с другой моделью. И вот как раз возможность проверки кода LLM моделью и есть важный бонус, которого ранее не было в CI pipeline. Но, повторюсь, использовать с осторожностью) У кого был опыт написания evals для агента - делитесь, что еще можно проверить? #ai #harness #ai_agents