У межах практичного воркшопу на каналі AI Engineer творець Pydantic і засновник однойменної компанії Семюел Колвін показує нетиповий, але показовий кейс для агентів штучного інтелекту. Замість чергового чат-бота чи кодувального асистента він бере політику — точніше, Вікіпедію британських депутатів — і ставить перед моделлю конкретне завдання: виявити політичні династії в Палаті громад.
Завдання виглядає просто: з’ясувати, у яких депутатів є політичні предки — батьки, дідусі чи бабусі, які також були політиками. Насправді ж це перетворюється на повноцінний пайплайн зі скрейпінгом Вікіпедії, очищенням HTML, структурованими відповідями агента, побудовою «золотого» датасету та подальшими оцінками якості моделей.
Від подкастного запитання до формалізованого завдання
Початок цієї історії — не у світі ML, а в політичному подкасті The Rest is Politics. Там обговорювали, наскільки британська політика пронизана династіями: скільки чинних депутатів походять із сімей, де політика — спадкова професія.
Щоб не сперечатися навмання, Колвін одного разу вже використав Pydantic AI для аналізу Вікіпедії всіх членів Палати громад. Агенти проходилися по сторінках депутатів і шукали згадки про родичів, які також були політиками. Попередній результат вийшов показовим: приблизно 24% депутатів мали хоча б одного політичного предка. Цю цифру озвучили в подкасті, але тоді вона була радше «розумною оцінкою», ніж ретельно перевіреним дослідженням.
У нинішньому воркшопі це завдання перетворюється на демонстраційний кейс: як побудувати агент, який витягує структуровані родинно-політичні зв’язки з неструктурованого тексту Вікіпедії, як сформувати «золотий» еталонний датасет і як потім вимірювати якість моделей уже не інтуїтивно, а за чіткими метриками.
Ключова ідея: замість того, щоб просто «запитати модель», будується повноцінна система з чітко визначеним форматом вхідних і вихідних даних, контрольним набором прикладів і автоматизованими порівняннями результатів.
Що саме потрібно від агента: лише політичні предки, жодних дружин
На перший погляд завдання звучить тривіально: знайти в тексті згадки про родичів-депутатів. Але формулювання мети тут дуже вузьке й принципове.
По-перше, цікавлять лише політичні предки: батьки, дідусі, бабусі та, загалом, попередні покоління. Діти, брати й сестри, подружжя, зяті, невістки та інші родичі того ж або молодшого покоління до підрахунку династій не входять. Ідея в тому, щоб виміряти саме «спадковість» політики, а не широту політичних зв’язків родини.
По-друге, потрібно відфільтрувати не лише тип родинного зв’язку, а й тип діяльності. Не кожен відомий родич — політик. У біографіях депутатів часто згадують бізнесменів, митців, науковців, дипломатів. Агенти мають відрізняти політичні ролі від інших публічних статусів.
Саме тут з’являється одна з головних труднощів. Моделі LLM, отримавши інструкцію «знайти родинні зв’язки», схильні повертати все, що схоже на родичів, — дружин, дітей, сестер, навіть якщо явно просять цього не робити. У попередньому, «подкастному» аналізі Колвін змушений був піти на обхідний маневр: дозволити моделі повертати всі родинні зв’язки, а потім уже окремим скриптом фільтрувати небажані типи (подружжя, діти, брати й сестри) і залишати лише предків.
У новій версії кейсу завдання ускладнюється: потрібно знайти таку формулювання промпту й таку конфігурацію агента, щоб він одразу повертав тільки релевантні зв’язки — політичних предків — без подальшого «ручного» очищення.
Це перетворює кейс із простої інформаційної вибірки на тест для точності інструкцій, здатності моделі дотримуватися обмежень і якості структурованого виводу.
Від HTML до структурованих об’єктів: як працює пайплайн
Щоб перетворити Вікіпедію на дані для аналізу, потрібен повноцінний технічний ланцюжок. У воркшопі він побудований доволі класично, але з важливими деталями.
Перший крок — зібрати сирі сторінки Вікіпедії для всіх депутатів. Для цього використовується архів із HTML-сторінками, який скрипт завантажує автоматично. Це дозволяє уникнути масового онлайн-скрейпінгу під час воркшопу й гарантує стабільність вхідних даних.
Далі йде попередня обробка. HTML-сторінки містять не лише текст біографії, а й навігаційні елементи, таблиці, меню, посилання, службові блоки. Усе це лише заважає моделі. Тому перед тим, як передати контент агенту, скрипт використовує бібліотеку BeautifulSoup, щоб «зчистити» HTML до чистого тексту. В результаті агент бачить лише текстову частину статті, без розмітки та зайвих елементів.
Наступний шар — схема даних. Для кожного депутата визначається структура, яка включає ім’я, політичну роль, URL сторінки та, головне, список родинних зв’язків. Окремо описується схема для самих зв’язків: тип відносин (батько, мати, дід, бабуся, подружжя, брат, сестра тощо), ім’я родича, його політична роль, якщо вона є.
Ключовий момент: агент не повертає вільний текст. Він працює в режимі структурованого виводу. Вихід агента — це список об’єктів «політичний родинний зв’язок», які відповідають визначеній Pydantic-схемі. Умовно кажучи, замість відповіді «його батько був депутатом, а дружина — прем’єр-міністеркою» агент має повернути масив об’єктів із полями на кшталт relation_type, relative_name, relative_role, is_political.
Такий підхід перетворює задачу з «прочитати й переказати» на «витягнути структуровані факти». Це не лише зручно для подальшого аналізу, а й критично важливо для автоматизованих оцінок: об’єкти можна порівнювати програмно, без залучення ще однієї моделі як «судді».
Після запуску агента для кожного депутата формується JSON-файл із усіма знайденими зв’язками. Окремо зберігаються метадані: список депутатів, їхні URL, сирі HTML-сторінки. Усе це лягає в локальну директорію MPs, яка стає робочим набором даних для подальших експериментів.
«Золотий» датасет: як створювали еталон політичних зв’язків
Щоб оцінювати якість роботи агента, потрібен еталон — набір депутатів із «правильними» політичними зв’язками, з яким можна порівнювати результати моделей. У цьому кейсі таким еталоном стає «золотий» датасет родинних відносин.
Структурно він виглядає так само, як вихід агента: для кожного депутата — список об’єктів, що описують родичів-політиків. Наприклад, для Стівена Кіннока, одного з найбільш показових прикладів політичної династії у Великій Британії, у цьому датасеті перелічені всі відомі політичні родичі. Серед них — і дружина, яка була прем’єр-міністеркою Данії, хоча для підрахунку династій подружжя формально не входить до потрібної категорії «предків».
Це не випадковість, а наслідок обраної стратегії: на рівні «золотого» датасету фіксуються всі політичні зв’язки, а вже потім, для конкретних метрик, можна застосовувати додаткові фільтри за типом відносин. Важливо, що структура даних дозволяє це зробити без втрати інформації.
Як же створювався цей еталон? Спочатку для всіх депутатів був запущений окремий скрипт, який використовував модель Claude Opus 4.6. Вона, так само як і агент у воркшопі, витягувала родинні зв’язки з Вікіпедії й повертала їх у структурованому вигляді. Отриманий масив JSON-об’єктів став основою «золотого» датасету.
На цьому процес не закінчився. Щоб підвищити надійність еталону, дані пройшли ручну вибіркову перевірку. Колвін переглядав окремі кейси, звіряв їх із Вікіпедією й переконувався, що модель не вигадує родичів і не пропускає очевидні зв’язки. Повної суцільної верифікації не було, але багаторазова вибіркова перевірка дала підстави вважати датасет достатньо точним для використання як бенчмарк.
У результаті «золотий» датасет став тим самим «ґрунтом під ногами», якого бракувало в першому, подкастному експерименті. Тепер замість інтуїтивного «виглядає правдоподібно» з’явилася можливість вимірювати точність моделей у відсотках, порівнювати різні промпти й конфігурації та бачити, де саме агент помиляється.
Тестовий набір, повний корпус і перші цифри точності
Щоб не ганяти моделі по всіх 650 депутатах щоразу, у воркшопі використовується двошарова структура даних. Є повний корпус — приблизно 650 депутатів із повними HTML-сторінками та «золотими» зв’язками. І є тестовий набір — 65 депутатів, які служать компактним, але репрезентативним зрізом для швидких експериментів.
Саме на цьому тестовому наборі запускаються перші оцінки якості. Агент із базовим, доволі простим промптом досягає приблизно 85–87% точності відносно «золотого» датасету. Це означає, що в більшості випадків він правильно знаходить і класифікує політичні зв’язки, але все ще регулярно плутає типи родинних відносин або включає небажані категорії, як-от подружжя чи дітей.
Далі в хід іде більш детальний, «експертний» промпт. Він містить чіткіші інструкції щодо того, кого саме вважати предком, як трактувати різні типи родинних зв’язків і як відрізняти політичні ролі від інших публічних статусів. З таким промптом точність на тому ж тестовому наборі піднімається приблизно до 92%.
Ці цифри важливі не лише як показник якості конкретної моделі. Вони демонструють, що:
по-перше, навіть відносно прості агенти вже можуть досить надійно витягувати складні структуровані факти з неструктурованого тексту;
по-друге, якість сильно залежить від точності формулювання завдання — промпт-інженерія тут дає відчутний приріст;
по-третє, наявність «золотого» датасету й чітких метрик дозволяє не просто «відчувати», що стало краще, а бачити це в числах і відслідковувати прогрес.
Структурований вивід як альтернатива «LLM-судді»
Окрема цінність цього кейсу — у тому, як саме оцінюється якість агента. Замість популярного підходу «LLM-as-a-judge», коли одна модель оцінює відповіді іншої, тут використовується повністю детермінований, програмний підхід.
Оскільки і «золотий» датасет, і вихід агента мають однакову структуровану форму — списки об’єктів із чітко визначеними полями — їх можна порівнювати без участі ще однієї моделі. Для кожного депутата можна порахувати, скільки зв’язків збіглися повністю, де були пропуски, де — зайві або неправильно класифіковані родичі. На основі цього обчислюються метрики точності, повноти, F1 та інші показники.
Такий підхід має кілька переваг. По-перше, він прозорий: кожну помилку можна відтворити й розібрати, не покладаючись на «смак» іншої моделі. По-друге, він стабільний: однакові вхідні дані завжди дають однакові оцінки. По-третє, він дешевший і простіший в експлуатації, оскільки не потребує додаткових викликів LLM для оцінювання.
У цьому сенсі кейс із політичними династіями демонструє ширшу тенденцію в роботі з агентами: перехід від «розмовних» сценаріїв до чітко типізованих задач, де моделі виступають не як співрозмовники, а як функції, що перетворюють один формат даних в інший.
Навіщо все це: політичні династії як тестовий полігон для агентів
З погляду політичної науки, цифра в районі 24% депутатів із політичними предками вже сама по собі цікава. Вона підтверджує інтуїцію про те, що британська політика значною мірою є справою сімейних традицій. Але в контексті воркшопу ця цифра — лише побічний продукт.
Головна цінність кейсу — у тому, що він поєднує реальну суспільно значущу тему з технічно насиченим завданням для агентів. Тут є все, що важливо для сучасних систем на базі LLM:
неструктуровані джерела даних у вигляді HTML-сторінок Вікіпедії;
попередня обробка тексту й очищення від шуму;
складні, контекстно залежні правила відбору фактів (лише предки, лише політики);
структурований вивід у вигляді об’єктів із чіткими полями;
«золотий» датасет як еталон;
тестовий і повний набори даних для експериментів і масштабування;
кількісні метрики точності, що дозволяють об’єктивно порівнювати різні промпти й конфігурації.
Усе це робить кейс із політичними династіями зручним полігоном для відпрацювання підходів до побудови й оптимізації агентів, які мають працювати не в лабораторних умовах, а з реальними, брудними, неоднорідними даними.
Висновок: коли ШІ стає інструментом для емпіричної політики
Історія з аналізом політичних династій у британському парламенті показує, як інструменти на кшталт Pydantic AI можуть виходити далеко за межі класичних «AI-продуктів». Тут модель не просто відповідає на запитання, а стає частиною дослідницького інструменту, який перетворює відкриті джерела на структуровані дані для подальшого аналізу.
Кейс демонструє, що:
агенти вже сьогодні здатні з високою точністю (понад 90% на тестовому наборі) витягувати складні, контекстно залежні факти з текстів на кшталт Вікіпедії;
якість таких систем критично залежить від наявності добре побудованого «золотого» датасету й чітких, детермінованих метрик оцінки;
структурований вивід і попередня обробка даних (зокрема очищення HTML) є не менш важливими, ніж вибір моделі;
навіть «ігрові» на перший погляд завдання — на кшталт підрахунку політичних династій — можуть стати серйозними тестами для інфраструктури агентів, якщо підійти до них як до повноцінних дата-проєктів.
У підсумку політичні династії виявляються не лише темою для подкастів, а й зручним майданчиком, на якому нове покоління інструментів ШІ вчиться працювати з реальним світом — таким, яким він є у Вікіпедії: хаотичним, неоднорідним, але структурованим рівно настільки, наскільки дозволяють наші власні схеми й моделі.
Джерело
Playground in Prod: Optimising Agents in Production Environments — Samuel Colvin, Pydantic