Claude автоматизує evals і hill-climbing

Дві команди замикають цикл оцінювання та покращення

Для мене головна зміна тут проста: Claude об’єднує проєктування evals та оптимізацію застосунку в один повторюваний контур. В офіційній публікації блогу Claude Automating eval design and hillclimbing with Claude описано дві команди: /claude-api build-eval і /claude-api hillclimb.

Перша створює набір перевірок усередині кодової бази. У документації Claude для таких наборів згадано точний збіг, перевірки кодом та оцінювання за допомогою LLM, а також еталонні відповіді й метрики на кшталт точності та затримки. Тобто eval тут не окрема таблиця, про яку згадують перед релізом, а частина робочого проєкту.

Друга команда ітеративно змінює застосунок і оцінює результат за вже створеними тестами. Згідно з матеріалами Claude Platform, пошук може охоплювати системні промпти, вибір моделі, рівень зусиль та інші параметри API. Це не навчання ваг моделі, а автоматизований перебір конфігурації навколо неї.

Критично важлива деталь: дані розділяють на train і test, а фінальний результат перевіряють на відкладеній вибірці. Без цього hill-climbing швидко навчився б вигравати на конкретному наборі прикладів, не покращуючи поведінку системи загалом.

Станом на 30 вересня 2026 року я сприймаю цю публікацію як розбір інженерної методики, а не як датований реліз: в оригінальному описі немає дати анонсу. Водночас сама ідея вже цілком практична на рівні архітектури процесу.

Налаштування промптів стає задачею пошуку

Головний наслідок такий: покращення AI-застосунку можна перетворити із серії суб’єктивних правок на вимірюваний цикл. Схема особливо добре підходить для задач із відтворюваними входами, перевірюваними результатами та стабільною функцією оцінювання.

Я б насамперед перевірив три речі: витік прикладів між train і test, нестабільність LLM-грейдера та відповідність метрики реальній якості. Якщо рубрика слабка, hill-climbing дуже дисципліновано оптимізуватиме не те. До оцінювання також принципово додати вартість, затримку та помилки, інакше переможе конфігурація, хороша лише за одним показником.

Це не магічна кнопка для покращення Claude, а спосіб зробити експерименти відтворюваними й менше залежними від смаку автора промпту. Найскладніший компонент не змінився: система настільки розумна, наскільки чесно сформульовано її eval.

Раніше ми розглядали, як вимірювати надійність LLM-as-a-Judge за допомогою метрик IRT. Ця методика допомагає перевірити, чи відображають покращення автоматизованих evals стабільне зростання якості, а не шумне оцінювання.