У світі LLM‑агентів дедалі очевидніше: розгорнути систему в продакшн — лише половина справи. Справжній виклик починається тоді, коли її потрібно системно покращувати, не зупиняючи сервіс і не переписуючи код щоразу, коли з’являється кращий промпт чи модель. Самуель Колвін, творець бібліотеки Pydantic і засновник однойменної компанії, демонструє, як це робити на практиці за допомогою стеку Pydantic AI та платформи спостережуваності Logfire.
У центрі його воркшопу — конкретне завдання: агент має з тексту статей Вікіпедії про британських депутатів (MPs) витягати структуровані дані про політичні династії, тобто виявляти предків‑політиків. На цьому кейсі Колвін показує, як поєднати класичні evals, керовані змінні Logfire та генетичний алгоритм GEPA, щоб не просто «на око» покращувати промпти, а будувати керований процес оптимізації агентів у продакшні.
Політичні династії як полігон для оптимізації
Завдання виглядає простим: для кожного депутата з Вікіпедії потрібно знайти родичів, які теж були політиками, і сформувати структурований список зв’язків. Насправді ж це виявляється нетривіальним тестом на точність промптів і моделей.
Пайплайн побудований навколо Pydantic AI: агент отримує HTML‑сторінку Вікіпедії, код попередньо очищує її за допомогою BeautifulSoup, видаляючи розмітку, і передає «чистий» текст у модель. Вихід — не вільний текст, а структурований список об’єктів «політичний зв’язок», описаний через Pydantic‑схему. Це той самий підхід до структурованих відповідей, який можна застосувати до будь‑чого: від виділення адреси з листа до розбору рядків інвойсу з PDF.
Ключова тонкість задачі — не просто знайти будь‑яких родичів‑політиків, а саме предків: батьків, дідусів, прадідів. Діти, брати, сестри, подружжя тут не мають значення. Саме ця вимога виявляється для моделей найскладнішою. Як тільки в інструкції з’являється слово «relations», моделі вперто додають у відповідь дружин, дітей, сестер‑ін‑ло, навіть якщо промпт прямо просить цього не робити.
Раніше Колвін обходив це грубою післяобробкою: дозволяв моделі повертати всі зв’язки, а потім фільтрував їх за типом, відкидаючи «непредків». У воркшопі він ставить амбітнішу мету — знайти промпт, який змусить агента одразу повертати тільки потрібні зв’язки. І робить це не інтуїтивно, а через вимірювані evals.
Для цього підготовлено два набори даних. Тестовий сет містить 65 депутатів — саме на ньому відбувається початкове порівняння промптів і моделей. Повний датасет — близько 650 депутатів — використовується вже для масштабнішої оптимізації, коли обрані кращі конфігурації.
Золотий еталон для порівняння — JSON‑файл із «правильними» політичними зв’язками для кожного депутата. Ці дані були згенеровані моделлю Claude Opus 4.6, а потім вручну вибірково перевірені. Саме цей golden dataset виступає ground truth для evals: відповіді агента порівнюються з ним детермінованими метриками, без використання «LLM‑як‑суддя».
Вимірювана сила промпта: від 85% до 92% точності
Перший крок — зрозуміти, наскільки добре працює найпростіший промпт. У Pydantic AI агент описаний як функція зі структурованим виходом, а інструкції до нього можна міняти. Базовий, «наївний» промпт формулює завдання доволі загально: знайти політичні зв’язки, зосереджуючись на предках. Без додаткових уточнень, прикладів чи суворих заборон.
Коли цей промпт проганяють через evals на тестовому наборі з 65 депутатів, результат виявляється несподівано непоганим: приблизно 85–87% точності. Для задачі, де модель має читати довгі біографічні тексти, розрізняти політичні й неполітичні ролі та ще й правильно класифікувати тип родинного зв’язку, це вже пристойний рівень.
Далі в гру вступає більш детальний «експертний» промпт. Він формулює вимоги значно жорсткіше: чітко пояснює, що вважати предком, що таке політик у цьому контексті, які типи зв’язків включати, а які ігнорувати. У ньому можуть бути додаткові інструкції на кшталт «не включати подружжя» або «ігнорувати дітей і братів/сестер, навіть якщо вони політики». Структура промпта стає ближчою до технічної специфікації, ніж до загального опису завдання.
Результат вимірюється тими ж evals на тому ж тестовому сеті з 65 депутатів. Точність зростає до приблизно 92%. Різниця у 5–7 відсоткових пунктів на тому самому наборі даних демонструє, наскільки промпт‑інжиніринг, підкріплений системними evals, може бути ефективним інструментом оптимізації агентів.
Важливо, що це не суб’єктивне враження розробника, а формалізований процес: є фіксований тестовий сет, є golden dataset, є метрика точності. Змінюється лише промпт, а Logfire фіксує, як це впливає на результат.
Evals як продукт: інтерфейс Logfire і порівняння прогонів
У традиційному світі observability платформи зосереджуються на логах, метриках і трасах. Logfire, який Pydantic позиціонує як платформу спостережуваності на базі OpenTelemetry, йде далі й додає в цей набір evals як повноцінну функцію.
У випадку з політичними династіями eval‑прогони запускаються проти golden dataset, а Logfire надає для цього окремий інтерфейс. У ньому видно не лише загальну точність, а й детальні результати по кожному кейсу. Для кожного депутата можна подивитися, які зв’язки агент знайшов, які пропустив, а які додав помилково.
Ключова можливість — порівняння кількох eval‑прогонів поруч. Наприклад, можна взяти результати базового промпта й експертного промпта та подивитися, де саме вони розходяться. У кейсах, де один промпт включає дружину як «політичного предка», а інший — ні, це одразу видно в UI. Такі розбіжності стають конкретними прикладами для аналізу: чи проблема в нечіткій інструкції, чи в неоднозначності тексту Вікіпедії, чи в самій моделі.
Це порівняння не лише допомагає обрати кращий промпт, а й виявляє системні помилки. Якщо, скажімо, обидва промпти регулярно плутають «громадського діяча» з «політиком», це сигнал, що проблема не в формулюванні завдання, а в тому, як модель інтерпретує контекст. У такому разі оптимізація промпта має межі, і варто подумати про зміну моделі або додаткову постобробку.
Той факт, що evals інтегровані в платформу спостережуваності, а не існують як окремий скрипт «десь у ноутбуці», важливий для продакшн‑команд. Розробники бачать, як зміни промптів чи моделей впливають на якість відповідей у часі, поруч із класичними метриками на кшталт латентності чи частоти помилок.
Керовані змінні: коли промпт — це не просто текст у коді
Більшість інструментів для роботи з промптами пропонують щось на кшталт «prompt management»: текст промпта зберігається в UI платформи, його можна редагувати без зміни коду, а агент підтягує актуальну версію під час виконання.
Logfire йде далі й вводить поняття керованих змінних (managed variables). Ідея в тому, що в платформі можна зберігати не лише текстові промпти, а будь‑які об’єкти, які описуються Pydantic‑моделлю. Це можуть бути:
модельні конфігурації (назва моделі, температура, максимальна довжина відповіді),
складні структури інструкцій,
набори правил постобробки,
цілі конфігурації агентів.
У кейсі з політичними династіями це означає, що промпт, вибір моделі, параметри генерації або навіть логіка фільтрації зв’язків можуть жити в Logfire як керовані змінні. Продакшн‑сервіс, наприклад FastAPI‑додаток, просто звертається до цих змінних під час виконання. Щоб змінити промпт або модель, не потрібно деплоїти нову версію сервісу — достатньо оновити значення змінної в Logfire.
Pydantic AI підтримує механізм override, який дозволяє підміняти промпти й моделі під час eval‑прогонів, не змінюючи основний код застосунку. Це критично для безпечних експериментів: можна прогнати новий промпт на історичних даних або на тестовому сеті, порівняти результати в Logfire, а вже потім, якщо він кращий, зробити його продакшн‑версією через оновлення керованої змінної.
Такий підхід перетворює промпт і конфігурацію агента на частину керованої конфігурації платформи, а не на «захардкожений» рядок у коді. Для команд, які часто експериментують із моделями й промптами, це знімає значну операційну напругу: експерименти можна проводити швидко, а зміни — розгортати без перезапуску сервісів.
GEPA: генетичний алгоритм для еволюції промптів
Наступний рівень — автоматизація самої оптимізації. Тут у гру вступає GEPA, або «Jepper», як його вимовляє Колвін. Це бібліотека генетичних алгоритмів, орієнтована на оптимізацію рядків. Рядком може бути як звичайний текстовий промпт, так і JSON‑структура з параметрами агента.
GEPA працює за принципом, схожим на селекцію скакових коней. Спочатку є набір кандидатів — різних промптів або конфігурацій. Вони оцінюються за певною метрикою якості, у нашому випадку — за результатами evals проти golden dataset. Далі бібліотека бере найкращих кандидатів, які лежать на так званому Парето‑фронті, і «схрещує» їх, комбінуючи частини успішних рішень, додаючи невеликі мутації й генеруючи нові варіанти.
На відміну від випадкового перебору, генетичний підхід системно рухається в бік кращих рішень, використовуючи інформацію про те, які промпти вже показали себе добре. Якщо один промпт чудово справляється з відсіканням подружжя, але іноді пропускає дідусів‑політиків, а інший навпаки, GEPA може спробувати поєднати їхні сильні сторони в новому кандидатові.
У контексті Logfire і Pydantic AI GEPA стає ще потужнішим інструментом. Кандидатні промпти або конфігурації можуть зберігатися як керовані змінні, evals — запускатися автоматично проти тестового або навіть продакшн‑трафіку, а результати — повертатися в GEPA як сигнали якості. Таким чином утворюється замкнений цикл: платформа збирає дані, GEPA генерує нові варіанти, evals їх оцінюють, а керовані змінні оновлюються відповідно до кращих рішень.
Колвін підкреслює, що зараз це ще певною мірою «Heath Robinson»‑конструкція, тобто зібрана з окремих компонентів, які потрібно поєднувати вручну. Але напрямок зрозумілий: від ручного промпт‑інжинірингу до напівавтоматичної еволюції промптів на основі реальних даних.
До автономних агентів: коли платформа оптимізує сама
Наступний логічний крок, над яким працює Pydantic, — зробити цей цикл оптимізації більш автономним. Ідея полягає в тому, щоб Logfire міг не лише збирати трейсинг агентів і зберігати керовані змінні, а й самостійно ініціювати процес покращення.
Уявлення про цю функцію таке: платформа аналізує продакшн‑трейси, збирає сигнали зворотного зв’язку (явні або неявні), запускає evals на репрезентативних підмножинах даних, а потім за допомогою GEPA або подібних алгоритмів генерує й тестує нові конфігурації агентів. Коли новий промпт або модель стабільно показують кращі результати, Logfire може запропонувати їх до розгортання або навіть поступово виводити в продакшн через механізми на кшталт A/B‑тестування.
Ключовим будівельним блоком тут залишаються керовані змінні. Оскільки будь‑який об’єкт, описаний Pydantic‑моделлю, може бути збережений і оновлений у Logfire, платформа отримує важіль впливу на поведінку агентів без необхідності змінювати код сервісів. Це відкриває шлях до сценаріїв, де оптимізація агентів стає постійним фоновим процесом, а не разовою активністю під час релізу.
У кейсі з політичними династіями це може означати, що платформа, помітивши систематичні помилки, наприклад, у розрізненні політиків і просто публічних фігур, сама ініціює пошук промптів, які краще пояснюють цю різницю моделі. Або, якщо з’являється нова, краща модель, Logfire може автоматично протестувати її на наявному golden dataset і запропонувати міграцію.
Важливо, що Pydantic не позиціонує це як «магічну чорну скриньку», яка «сама зробить агента кращим». Навпаки, наголос робиться на прозорості: evals, трейсинг, керовані змінні й GEPA мають залишатися доступними й керованими для інженерів. Автономність тут — це радше автоматизація рутинних кроків, ніж повна передача контролю.
Висновок: від ручної настройки до безперервної еволюції
Кейс із виявленням політичних династій у біографіях британських депутатів показує, як виглядає сучасний підхід до оптимізації LLM‑агентів, коли в команді є і фреймворк, і платформа спостережуваності, і інструменти для автоматизації.
На першому рівні — чітко визначене завдання, структурований вихід і golden dataset. На другому — evals, які дозволяють вимірювати вплив змін промптів: від простого базового варіанта з точністю 85–87% до експертного промпта з близько 92% на тому ж тестовому сеті з 65 депутатів. На третьому — Logfire як середовище, де ці evals живуть поруч із логами й трейсами, а керовані змінні дозволяють змінювати промпти й моделі без деплою.
І нарешті, на четвертому рівні — GEPA як генетичний алгоритм, що вміє еволюціонувати рядки‑промпти, комбінуючи найкращі кандидати за принципом Парето‑фронту. У поєднанні з Logfire це створює основу для майбутніх автономних систем, де агенти не просто працюють у продакшні, а постійно вдосконалюються на основі реальних даних і формалізованих метрик якості.
Для інженерів це означає перехід від інтуїтивного «підкручування» промптів до керованого, вимірюваного процесу оптимізації, який можна масштабувати, відтворювати й поступово автоматизувати. А для платформ на кшталт Logfire — шанс перетворити observability з пасивного моніторингу на активний інструмент еволюції агентів.
Джерело
Playground in Prod: Optimising Agents in Production Environments — Samuel Colvin, Pydantic