Flint: język wykresów, który agent może napisać i człowiek poprawić

Flint to język pośredni dla wykresów: człowiek lub agent opisuje dane i zamysł wizualizacji, a kompilator wypełnia wiele szczegółów technicznych. Microsoft Research przedstawił go jako sposób na tworzenie czytelnych wykresów z krótkich, edytowalnych specyfikacji. Kod Flint obejmuje bibliotekę oraz serwer MCP dla agentów.

Co daje warstwa semantyczna?

Pole marża nie jest zwykłą liczbą: często jest procentem, ma ograniczony zakres i wymaga określonego sposobu formatowania. Pole miesiąc jest okresem, nie etykietą dowolnego tekstu. Flint korzysta z typów semantycznych i mapowania pól na osie lub kolor, aby dobrać formatowanie, skalę i układ. Jedna specyfikacja może być kompilowana do różnych bibliotek, m.in. Vega-Lite, Apache ECharts i Chart.js, zgodnie z opisem projektu.

To pomaga w pracy agenta. Zamiast wymagać setek szczegółowych parametrów biblioteki wykresów, prosimy o krótką strukturę, którą łatwiej zweryfikować i zmienić. Data Formulator używa Flint do własnych wizualizacji. Agent w AI SDLC może wygenerować specyfikację, uruchomić walidację i porównać obraz z oczekiwaniem użytkownika.

Gdzie automatyka może zawieść?

Poprawny technicznie wykres może manipulować interpretacją, jeśli ma złą podstawę osi, agreguje nieporównywalne wartości lub ukrywa brakujące dane. Flint nie zna automatycznie polityki firmowych metryk. Definicje jednostek, agregacji i uprawnień do danych muszą przyjść z zaufanego modelu semantycznego. Przy raporcie decyzji warto zapisać specyfikację obok zapytania i wersji danych, aby wynik dało się odtworzyć.

Alternatywami są bezpośrednie pisanie Vega-Lite, ECharts lub Chart.js. Flint ma sens, gdy wiele wykresów powstaje z udziałem agentów, a zespół chce krótki, wspólny kontrakt między intencją a rendererem. Jeżeli potrzebny jest jeden ręcznie dopracowany wykres, bezpośrednia biblioteka może dawać pełniejszą kontrolę. O wyborze niech zdecyduje test na rzeczywistych, trudnych danych firmy, nie tylko galeria przykładów.

Krótka specyfikacja nadal potrzebuje dobrych danych

Załóżmy, że agent chce pokazać „liczbę aktywnych klientów według miesiąca”. Flint może dobrać oś czasu i czytelne etykiety, lecz najpierw trzeba ustalić, co znaczy „aktywny”. Jeśli jedna tabela liczy firmy z otwartą umową, a druga firmy z zakupem w ostatnich 90 dniach, kompilator wykresu nie rozstrzygnie sporu. Specyfikacja powinna zatem wskazywać nie tylko typ wizualizacji, ale też identyfikator zatwierdzonej metryki albo jawny sposób obliczenia.

W pracy z agentami przydaje się walidacja przed renderowaniem. Sprawdź, czy pole istnieje, czy jednostka zgadza się z osią, czy agregacja ma sens i czy dane nie są puste. Dopiero potem pozwól wygenerować wykres. W przeciwnym razie agent może wyprodukować elegancki obraz z nieistniejącej kolumny albo porównać procent ze złotówkami. Flint zmniejsza liczbę niskopoziomowych decyzji o stylu, ale nie usuwa obowiązku oceny znaczenia danych.

Wielobackendowość jest korzystna, gdy zespół ma różne miejsca publikacji: interaktywny panel webowy, notatnik i raport. Trzeba jednak sprawdzić, czy konkretny typ wykresu zachowuje podobną interpretację we wszystkich rendererach. Ten sam zamiar wizualny może być obsługiwany inaczej przez Vega-Lite i Chart.js. Test regresyjny powinien więc obejmować wynikową specyfikację oraz obraz dla kilku reprezentatywnych danych.

Flint może też służyć jako kontrakt między analitykiem a agentem kodującym. Analityk opisuje sens pól i zamysł prezentacji, agent przygotowuje specyfikację, a kompilator odtwarza rezultat. Dzięki temu poprawka podpisu lub typu osi nie wymaga przepisywania całego kodu biblioteki. Warunkiem jest przechowywanie specyfikacji razem z definicją danych i historią zmiany.