Британський інженер Самуель Колвін став відомим завдяки Pydantic — популярній Python‑бібліотеці для валідації даних і роботи з моделями. Сьогодні це вже не лише open source‑проєкт, а й компанія Pydantic, яка розбудовує навколо початкової бібліотеки цілу екосистему для роботи з LLM‑агентами в продакшені: від фреймворку Pydantic AI до платформи спостережуваності Logfire та мульти‑провайдерного Pydantic Gateway.
У межах практичного воркшопу для AI‑інженерів Колвін показує, як ці частини складаються в єдиний стек: як будувати агентів, як спостерігати за ними в реальному середовищі та як керувати моделями через один API‑шар. За цим стоїть чітка ідея: Pydantic більше не лише про типи й валідацію, а про інфраструктуру для сучасних AI‑систем.
Від бібліотеки до компанії: що таке Pydantic сьогодні
Pydantic починався як утилітарна бібліотека для Python‑розробників: декларативні моделі, автоматична валідація, зручна робота з JSON та API‑даними. Цей шар і досі залишається фундаментом — компанія продовжує підтримувати «класичний» Pydantic Validation Library, на якому тримаються тисячі проєктів.
Проте навколо цього фундаменту виросла нова інфраструктура.
По‑перше, з’явився Pydantic AI — фреймворк агентів, який використовує ті самі принципи структурованих моделей, але вже для LLM‑систем. Агент у такій парадигмі — це не просто виклик моделі з текстовим промптом, а функція з чітко описаними вхідними та вихідними структурами. Pydantic‑моделі визначають, що саме агент має повернути: наприклад, список об’єктів із політичними зв’язками, адреси з листа чи рядки інвойсу з PDF.
Це дозволяє будувати агентів як частину типової Python‑системи, а не як окремий «магічний» шар. Вихід LLM одразу приводиться до строго типізованих структур, з якими можна працювати далі в коді, зберігати в базу даних чи проганяти через аналітику.
По‑друге, компанія вийшла за межі суто бібліотечного світу й почала пропонувати хмарні сервіси. Саме тут з’являються Logfire та Gateway — два ключові елементи, які перетворюють Pydantic на повноцінний продакшен‑стек для AI.
Logfire: спостережуваність, яка не обмежується «AI‑логами»
Logfire у Pydantic позиціонують не як вузький «AI observability»‑продукт, а як загальну платформу спостережуваності. Під капотом — стандартний стек OpenTelemetry: логи, метрики, трейси. Це означає, що Logfire може збирати та корелювати події з різних частин системи, а не лише з LLM‑викликів.
Колвін прямо говорить, що не вірить у «AI observability» як окрему категорію: на його думку, це радше фіча, яка неминуче буде поглинута або класичною спостережуваністю, або AI‑платформами. Попри це, сьогодні Logfire продається саме як інструмент для спостереження за AI‑системами — просто тому, що це зрозумілий запит ринку.
Важливий нюанс: Logfire не обмежується базовими можливостями на кшталт логів і метрик. На ньому будують вищий рівень функціональності, який безпосередньо стосується якості агентів і моделей.
Ключові надбудови — це evals та керовані змінні (managed variables).
Evals у Logfire — це механізм, який дозволяє порівнювати виходи моделей із «золотою» розміткою, рахувати точність і бачити, де саме агент помиляється. У воркшопі ці evals використовуються для порівняння різних промптів і моделей на одному й тому самому наборі даних, але сама платформа задумана як універсальний інструмент оцінки якості.
Керовані змінні — ще один рівень абстракції, який виходить за межі класичного «prompt management».
Керовані змінні: не лише промпти, а будь‑які об’єкти моделей
Багато AI‑платформ пропонують prompt management: можливість зберігати текстові промпти в хмарі, редагувати їх через UI й оновлювати без релізу коду. Logfire йде далі й вводить поняття managed variables — керованих змінних, які можуть бути будь‑якими об’єктами, визначеними через Pydantic‑моделі.
Це принципова відмінність. Замість того, щоб думати лише в термінах «основний промпт» чи «системне повідомлення», розробник може винести в Logfire цілі конфігураційні структури: наприклад, набір правил фільтрації, схему постобробки, параметри температури й топ‑p, складні JSON‑конфіги для інструментів агента.
Якщо об’єкт можна описати Pydantic‑моделлю, його можна зробити керованою змінною в Logfire. Далі цей об’єкт підтягується в рантаймі, без перезапуску сервісу. Для продакшен‑середовища це означає можливість змінювати поведінку агентів на льоту: оновлювати інструкції, структуру вихідних даних, параметри моделей.
У воркшопі керовані змінні використовуються разом із бібліотекою GEPA (у вимові Колвіна — «Джепер») для напівавтоматичної оптимізації промптів. Поки що це робиться «по‑Хіт‑Робінсону», як жартує сам автор, але в дорожній карті Logfire — зробити цей процес повністю інтегрованим: щоб платформа могла автономно оптимізувати агентів, використовуючи історичні трейси, фідбек і evals.
Компанія вже працює над функцією, яка дозволить оптимізувати агентів безпосередньо з Logfire: від збору даних до зміни керованих змінних. Ідея в тому, щоб замкнути цикл: спостереження → оцінка → оптимізація → оновлення конфігурації — без ручного втручання в код.
GEPA: генетичний алгоритм для оптимізації рядків і промптів
Ще один елемент екосистеми, який Колвін демонструє в поєднанні з Logfire, — це бібліотека GEPA (він же «Jepper»). Це реалізація генетичного алгоритму, заточена на оптимізацію рядків. Під «рядком» тут розуміється не лише plain text, а й JSON, який у підсумку може містити будь‑яку структуру.
Механіка класична для генетичних алгоритмів. GEPA шукає «кращі» кандидати за заданою метрикою, а потім комбінує їх, щоб отримати нові варіанти. Назва відсилає до Pareto‑фронту: бібліотека бере кандидатів із «фронтиру» найкращих прикладів і «схрещує» їх, подібно до того, як у селекції розводять лише найшвидших скакових коней, а не додають у мікс повільних.
У контексті AI‑агентів це означає, що GEPA може еволюціонувати промпти чи конфігурації, які представлені як рядки або JSON. Наприклад, можна мати кілька варіантів системних інструкцій, прогнати їх через evals у Logfire, обрати найкращі, а потім дозволити GEPA згенерувати нові комбінації, які потенційно працюватимуть ще краще.
Сам Колвін використовує GEPA як окрему бібліотеку, яку можна поєднувати з керованими змінними Logfire. Поки що це вимагає певної ручної роботи, але в перспективі саме цей підхід має лягти в основу автономної оптимізації агентів на платформі.
Pydantic Gateway: один ключ до OpenAI, Anthropic, Groq і Gemini
Третій важливий компонент екосистеми — Pydantic Gateway. Це шар, який дозволяє звертатися до різних провайдерів моделей через єдиний API‑ключ і уніфікований інтерфейс.
У воркшопі Gateway використовується як «префікс» до імені моделі: замість прямого виклику OpenAI чи Anthropic код звертається до gateway‑моделі. Якщо розробник хоче використовувати власний ключ OpenAI чи Anthropic, він може просто прибрати префікс і працювати напряму. Але Gateway дає низку додаткових можливостей, які роблять мульти‑модельний підхід придатним для продакшену.
По‑перше, це спостережуваність. Всі виклики через Gateway автоматично потрапляють у Logfire: їх можна логувати, трасувати, аналізувати час відгуку, частоту помилок, вартість. Це важливо, коли система використовує кілька моделей від різних провайдерів і потрібно розуміти, як вони поводяться в реальному навантаженні.
По‑друге, Gateway додає кешування. Якщо однакові запити часто повторюються, відповідь може бути повернута з кешу, що знижує затримки й витрати. Для багатьох продакшен‑сценаріїв це критично, особливо коли мова йде про дорогі моделі на кшталт топових GPT чи Claude.
По‑третє, Gateway реалізує fallback‑механізми. Якщо основний провайдер недоступний або перевищено ліміт, запит може автоматично перейти на іншу модель. Це дозволяє будувати більш стійкі системи, де збій одного вендора не призводить до повної зупинки сервісу.
У демонстраційному проєкті Колвін показує, як через Gateway можна працювати з OpenAI, Anthropic, Groq, Gemini та іншими провайдерами, не змінюючи бізнес‑логіку. Для розробника це означає можливість експериментувати з різними моделями, не переписуючи код інтеграції щоразу.
GPT‑4.1 через Gateway: баланс швидкості й вартості
Хоча Gateway підтримує кількох провайдерів, у воркшопі основний акцент робиться на OpenAI GPT‑4.1. Саме ця модель використовується для запуску прикладового агента через Pydantic Gateway.
Причина — прагматична. GPT‑4.1 дає прийнятний баланс між якістю, швидкістю й вартістю для задачі, яку демонструє Колвін. У межах воркшопу агент багаторазово проганяється на різних даних, промпти змінюються, запускаються evals. Для такого сценарію важливо, щоб модель була достатньо потужною, але при цьому не надто дорогою й повільною.
Gateway у цьому контексті виконує роль «універсального адаптера». Учасники можуть або використовувати наданий ключ Gateway, або підставити власні ключі OpenAI чи Anthropic, просто змінивши назву моделі в коді. Але в обох випадках архітектура залишається тією самою: агент побудований на Pydantic AI, спостережуваність і evals — через Logfire, а доступ до моделей — через уніфікований шар Gateway.
Цей підхід добре ілюструє загальну філософію Pydantic як компанії: не прив’язуватися до одного вендора моделей, а будувати інфраструктуру, яка дозволяє комбінувати різні LLM і керувати ними як єдиною системою.
Як усе складається в єдиний стек
Якщо скласти всі елементи разом, вимальовується досить цілісний продакшен‑стек для LLM‑агентів.
На нижньому рівні — класичний Pydantic, який забезпечує строгі моделі даних і валідацію. Ці ж моделі використовуються в Pydantic AI для опису вхідних і вихідних структур агентів, що дозволяє працювати зі структурованими відповідями, а не з «сирим» текстом.
На рівні інфраструктури моделей — Pydantic Gateway, який дає єдиний спосіб звертатися до OpenAI, Anthropic, Groq, Gemini та інших, додаючи поверх цього кешування, fallback і спостережуваність.
На рівні спостережуваності — Logfire, який збирає OpenTelemetry‑логи, метрики й трейси, а також надає спеціалізовані інструменти для AI‑систем: evals, UI для порівняння запусків, керовані змінні, що дозволяють змінювати поведінку агентів без релізу.
Над цим — експериментальний шар оптимізації: GEPA як бібліотека генетичних алгоритмів для еволюції промптів і конфігурацій, інтегрована з керованими змінними Logfire. У планах — зробити цей шар частиною самої платформи, щоб агенти могли оптимізуватися автономно на основі реальних даних.
Усе це разом перетворює Pydantic із «бібліотеки для валідації» на повноцінну екосистему для побудови, запуску й оптимізації LLM‑агентів у продакшені. При цьому ключовою залишається початкова ідея: строгі структури даних, прозорість і контроль замість «чорної скриньки» з текстовими промптами.
Висновок: інфраструктура важливіша за окремі моделі
На тлі стрімкої гонки моделей легко зосередитися на порівнянні GPT, Claude, Gemini чи Groq. Підхід Pydantic нагадує, що в довгостроковій перспективі важливішою стає інфраструктура навколо моделей: як описані дані, як побудовані агенти, як збирається телеметрія, як відбувається оптимізація.
Колвін, який починав із «простого» інструмента для валідації, тепер будує стек, що закриває весь життєвий цикл LLM‑агента: від моделі даних до автономної оптимізації в продакшені. І саме цей рівень — спостережуваність, керовані змінні, мульти‑провайдерний доступ — може виявитися тим, що відрізняє експериментальні AI‑проєкти від стабільних, керованих систем у реальному бізнесі.
Джерело
Playground in Prod: Optimising Agents in Production Environments — Samuel Colvin, Pydantic