В 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
Telegram
(java || kotlin) && devOps
Вместо этого поста я мог бы просто дать вот эту ссылку https://github.com/affaan-m/ECC/tree/main/skills
И порекомендовать медленно промотать содержимое страницы, обращая внимание на назначение скилов.
Но все же прокомментирую)
Первый набор скилов по ссылке…
1June 24, 2026 131
