Сьогодні ми випускаємо наш Eval Engineering Skill — навичку, яка допомагає кодувальним агентам створювати eval’и, використовуючи контекст із репозиторію та трас агента.
Навичка аналізує структуру агента, видобуває патерни з трас (якщо вони доступні) і пропонує здібності для тестування.
Навичка розроблена для інтерв’ювання користувача — він може давати зворотний зв’язок щодо пропозицій і ітеративно затверджувати кожен eval. Кінцевий результат — набір виконуваних eval’ів у форматі Harbor.
Створення середовища та завдання
Спочатку навичка зчитує репозиторій і мапує поверхню агента, включно з підказками (prompts), моделями, інструментами, навичками, хуками тощо. Вона також визначає дані та сервіси, які забезпечують цю поведінку, наприклад виклики API.
Користувачі також можуть вказати агенту на траси, які можна отримати за допомогою інструментів на кшталт langsmith-cli. Траси показують, як інструменти поводяться на практиці — їхні аргументи, результати та помилки. Ці спостережувані контракти допомагають навичці відтворювати відповідну продуктивну поведінку в контрольованому середовищі.
Обхід репозиторію та трас дає агенту знання про те, які здібності є важливими, коли він пропонує завдання для eval’ів. Ми виявили, що інтерв’ювання користувача призводить до значно кращого прийняття eval’ів, ніж однократна генерація. Користувач обирає з запропонованих напрямків eval’ів і дає вказівки щодо таких питань, як: які інструменти та залежності мають працювати в реальному часі, а які потребують симуляції. Наприклад, виклики інструментів, які спричиняють витрати або потребують запису в продуктивну базу, можна симулювати замість того, щоб виконувати їх при кожному запуску eval’а.
Ми протестували цей процес на нашому агенті для відповідей на запитання з документації — chat-langchain. Для цього агента середовище потребувало корпусу даних, доступного через інструменти пошуку агента, змодельовані на основі продуктивного агента. Завдання включали реалістичні запитання з документації, взяті з реальних трас, і верифікатор, який перевіряв відповідь за допомогою еталонного рядка та цитованих документів.
Дизайн eval’ів є ітеративним
Ми виявили, що хоча агенти іноді здатні створювати eval’и за один раз, найкращі eval’и з’являлися завдяки зворотному зв’язку від користувачів, які вказували, які саме здібності варто вимірювати в агентах. Кодувальні агенти та навички забезпечують природний інтерфейс, де закодовано доменні знання про те, як побудувати хороший eval, і користувачі можуть ітеративно їх покращувати з часом.
Наприклад, ми помітили, що під час створення верифікаторів перший верифікатор рідко був остаточним. Корисним способом його вдосконалення було запустити eval і перевірити обидві сторони результату:
- траєкторію агента, включно з його повідомленнями, викликами інструментів та діями;
- траєкторію верифікатора, докази, міркування та остаточну оцінку.
Це допомагало виявити, чи завдання або дизайн верифікатора вимірювали те, що нас цікавило, чи їх можна обдурити (reward hacking), коли агенти могли знаходити шляхи. Такі шляхи можуть включати надмірне цитування нерелевантних джерел для отримання повної оцінки, ствердження про дію, яку агент ніколи не виконував, використання доступного матеріалу відповіді або задоволення проксі-завдання без виконання основного. Спостереження за трасами того, як агенти вирішують проблеми, часто виявляє джерела таких помилок. Потім завдання, середовище та верифікатор можна переглянути і запустити знову.
Eval’и у форматі Harbor
Навичка створює eval’и як завдання Harbor:
- Інструкція: повідомлення, яке надається агенту на початку, що описує завдання.
- Середовище: надається у вигляді Dockerfile, що містить налаштування для завдання, наприклад, які інструменти встановити або які дані розмістити у файловій системі.
- Верифікатор, який оцінює, чи правильно агент виконав завдання.
Навичка збирає ці компоненти разом як завдання Harbor:
1evals/<task-id>/2├── task.toml3├── instruction.md4├── environment/5└── tests/
Harbor запускає агента в середовищі та записує його траєкторію, артефакти, винагороду та помилки. Один і той самий eval можна потім запускати з різними моделями, підказками, інструментами та версіями агента.
Чому це важливо
Постійне навчання можна розглядати як безперервну задачу видобутку даних, де продуктивні дані використовуються для створення eval’ів, які з часом покращують агентів. Команди аналізують траси, щоб знайти повторювані запити користувачів, помилки, невдалі виклики інструментів і неправильні зміни стану. Це перетворюється на eval’и, щоб ту саму поведінку можна було виміряти та запобігти їй у майбутньому.
Eval’и — це тренувальні дані для агентів. Команди можуть підганяти поведінку агента під них за допомогою інженерії, наприклад змінюючи підказки та інструменти або здійснюючи тонке налаштування (fine-tuning). Eval забезпечує фіксовану ціль для визначення того, чи покращили ці зміни задуману здатність.
Контейнеризовані eval’и пришвидшують цей процес. Завдання та середовище залишаються стабільними, тоді як конфігурація агента змінюється, тому розробники можуть замінювати моделі, інструменти, підказки або цілі версії агентів і безпосередньо порівнювати результати. Кілька конфігурацій можуть працювати паралельно.
Відтворювані середовища є критичними для цього сигналу. Коли eval відображає відповідні інструменти, дані, дозволи, стан та режими збоїв з продуктивного середовища, розробники отримують стабільний полігон, який все ще репрезентує роботу агента. Вони можуть швидко експериментувати, не покладаючись на змінні продуктивні системи або запис у продуктивний стан.
Отриманий цикл виглядає так:
аналізуй траси → вияви збій → створи eval → покращ агента → запусти знову
Спробуйте сьогодні
Eval Engineering Skill доступний у langchain-ai/langchain-skills repository.
Встановіть навичку в Codex або Claude Code, відкрийте репозиторій з агентом, якого хочете оцінити, вкажіть агенту на набір трас (якщо вони є) і почніть із простого запиту:
Ми з нетерпінням чекаємо на розширення цієї навички та створення інструментів, які полегшать автоматичне створення eval’ів і самостійне підлаштування агентів під них.
