Разработка агентов на основе оценки (Eval-Driven): Как я перестал настраивать промпты на интуиции

Я изменил промпт. Следующий запуск выглядел лучше. Помогла ли эта правка или мне просто повезло?

Долгое время моим ответом было «Думаю, да». Я подправлял команду, запускал пайплайн, смотрел на успешный результат и выпускал продукт. Это — инженерия на интуиции (vibes-based engineering). Почти все, кто создает агентов, поступают так, потому что альтернативный путь кажется слишком сложным.

Но агенты для написания кода недетерминированы. Вы можете запустить одну и ту же задачу дважды и получить два разных результата. Один удачный запуск ничего вам не говорит. Вы не можете понять, сработала ли ваша правка или просто выпал удачный случай.

Я решил эту проблему, применив дисциплину машинного обучения. Я создал фреймворк для оценки (evaluation framework), который охватывает всю мою систему.

Вот как работает этот фреймворк:

• Target (Цель): Замороженная кодовая база. Она остается неизменной, чтобы результаты были сопоставимы. • Task (Задача): Конкретный элемент бенчмарка с промптом и оракулом. • Oracle (Оракул): Детерминированная проверка. Это shell-команды, которые должны завершиться успешно. • Variant (Вариант): Конкретное изменение, которое вы тестируете, например, новый планировщик (planner). • Trial (Попытка): Один запуск. Я запускаю каждую задачу несколько раз, чтобы учесть фактор случайности.

Я использую два типа оценки, чтобы выявлять разные виды ошибок:

  • Code Graders (Детерминированные): Проверяют процент прохождения тестов, стоимость, время и изменения в файлах.
  • LLM Judge (Вероятностный): Отдельная фиксированная модель оценивает качество спецификации и точность реализации.

Code graders говорят вам, работает ли код. Judge говорит, хорош ли этот код. Вам нужны оба.

Я также перестал использовать средние значения. Среднее арифметическое лжет, когда речь идет об агентах. Если задача выполняется 2 раза из 3, это кажется нормальным. Но это ненадежно. Вместо этого я использую две метрики:

  • pass@k: Удалось ли агенту справиться хотя бы один раз? (Возможности)
  • pass^k: Удалось ли агенту справиться каждый раз? (Надежность)

Рост pass^k — это настоящая победа. Это значит, что вы сделали агента стабильным, а не просто удачливым.

Чтобы поддерживать систему в тонусе, я добавляю сложные задачи, требующие глубокого понимания. Когда агент не справляется с реальным багом, я превращаю этот провал в постоянную задачу. Это создает замкнутый цикл. Бенчмарк усложняется по мере того, как агент становится лучше.

Создание такой инфраструктуры требует много сил, но это самая эффективная вещь, которую я когда-либо строил. Это превратило «мне кажется, так лучше» в «это на 20% надежнее при меньших затратах».

Агентов для кодинга легко демонстрировать, но трудно им доверять. Если вы хотите выйти за рамки демо-версий, вы должны решиться на измерения.

Source: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

Optional learning community: https://t.me/GyaanSetuAi