Wersja 3.4

 Nowa wersja, mnóstwo zmian.

Na horyzoncie pojawił się Fable (na chwilę) ale w ramach testów dałem mu do przejrzenia orkiestratora i pliki z faza big picture i process level. No cóż, zaproponował zmiany, dużo zmian.

Zmiany.

W ostatnich wersjach nie skupiłem się na samym procesie event stromingu a na orkiestratorze, i patrząc w pliki tych dwóch części dane tam zgromadzone uległy erozji. Nie były wystarczające do tego żeby właściwe przeprowadzić analizę wsadu. No właśnie analizę wsadu bo określiłem, że taki będzie cel tego narzędzia, analiza zgromadzonych materiałów i próba uzupełnienia ich o dodatkowe dane.

Czyli to już nie narzędzie do analizy całego procesu, a narzędzie do weryfikacji rezultatu analizy. Dlaczego? Bo to zawęża obszar działań, pozbywam się jednej gałęzi i skupiam większą uwagę na reszcie. Tryb bez wsadowy pozostał ale nie wiadomo na jak długo.

Fable przerobił mi kroki big picture i proccess level, przy okazji orkiestratora również, no i oczywiście wszystko spuchło (wersja 3.4 repo). Ale to nie koniec zmian, uświadomiłem sobie, że testy tego i poprawności danych są nie wystarczające, a właściwie brak jakiegoś algorytmu sprawdzania. Postanowiłem to naprawić pisząc wzorzec, który posłuży do walidacji wyniku.

Ale poklei najpierw zmiany w krokach ES

1. Zasada odpowiedzialności za jakość wsadu, to materiały wejściowe w dużej mierze decydują o jakości danych wyjściowych, LLM ma nie zgadywać, a trzymać się ram, granic,
2. Tryby analizy 
1. audit - na bazie materiałów wsadowych, bez materiałów wsadowych niedostępny
2. elicit - bez materiałów dane pozyskiwane w formie dialogu (nie testowałem nie wiem jak działa)
3. Etap przygotowania danych
4. Etap sprawdzania pokrycia poszczególnych kroków ES, sprawdzana jakość materiałów
5. Tryby pracy pozostały bez zmian:
1. Agentowy - automat, ma się dziać automatycznie ale testy wypadały różnie, czasami przypomina tryb drugi, 
2. Ekspercki (domyślny) - sub-agent pyta użytkownik odpowiada,
3. Mixed - nie zbadany anie nie przetestowany, być może wyleci bo jakoś nie widzę jakby to miało działać,
4. Użytkownik jako orkiestrator 
6. Mapa zdarzeń - według której działa orkiestrator (przynajmniej w teorii)

Tyle z orkiestratora, są jeszcze zmiany, większość rzeczy nie jest przetestowana, na razie testy dotyczyły pierwszej i drugiej fazy i to nie zawsze druga była w pełni kompletna. Co do testów to jeszcze opisze, okazało się to bardziej skomplikowane niż sądziłem.

Na razie nie będę opisywał zmian w poszczególnych krokach, jest ich całkiem sporo, to zostawiam na później. Teraz testy.

Testy

Testy okazały się prawdziwym wyzwaniem takiego kalibru jak sam orkiestrator. W początkowych wersjach to było studiowanie wyników, czyli ręczny przegląd, potem pojawił się comparator, do porównywania struktury rezultatu bo skupiłem się na orkiestratorze, a teraz pojawił się skill do sprawdzania danych ze wzorcem. A same testy zaczęły zabierać cały czas, który wcześniej był poświęcony na prace z orkiestratorem. Dodatkowo zacząłem się w końcu zastanawiać ile te rozwiązanie przepala "paliwa".

Czym jest wzorzec?

Jest niczym innym jak ogólnym opisem całego kontekstu testowanego wsadu, ale nie kontekstem wsadu a wyniku. Tu plik wzorca.

Do porównywania wyników ze wzorcem powstał comparator, dokładnie to jest poprzedni, który patrzył na strukturę, a ten to jest kolejna jego wersja.

W ten sposób jednocześnie trzeba rozwijać skilla do testowania i do analizy.

Ten "porównywacz", ma za zadanie sprawdzić pliki wyjściowe, dane jakie zostały wygenerowane z każdej sesji i porównać ze wzorcem czy za bardzo od niego nie odbiegają.

Dlaczego powstało takie narzędzie?

Ilość wyników jest przytłaczająca, problem pojawił się przy sprawdzaniu poprawności, no właśnie poprawności, czym ona jest, trzeba było stworzyć wzorzec który będzie gwarantował pewne granice w których musi się utrzymać rezultat.

Te narzędzie generuje dwa pliku wynikowe, przykładowe pliki:

• niezgodności - co jest obecne, czego brakuje,
• rozszerzenia - w których obszarach rezultat wyszedł po za wzorzec, wymyślił coś nowego w obrębie kontekstu 

Dlaczego taka forma?

Pisałem to już jakiś czas temu przy któreś wersji, ze chciałbym samodoskonalący się rezultat, tu dzięki rozszerzeniom mogę robić coraz lepszy wzorzec i doskonalić wynik (przynajmniej w teorii, bo praktyka na razie pokazuje nie wiele).

Zrobiłem pięć takich testów i znowu zauważyłem, że materiałów za dużo, no to (jako że jestem leniwy) powstał kolejny porównywacz tym razem do rezultatu testów.

Żeby utrzymać jakość materiałów wyjściowych potrzebuje rozbudowanych testów, ale muszę również pohamować się z pomysłami, bo nie wyjdę ze stabilną wersją a ciągłymi zmianami.

Na koniec dnia dostałem do utrzymania orkiestratora z całą trzódką, wzorzec porównywacz do nie go, oraz porównywacz do rezultatów porównywacza, a miało być tylko prościej.

Moduły

Big Picture

Moduł ES Big Picture też został zmieniony, w porównaniu do poprzedniej wersji granicę tego etapu zostały wyraźniej zaznaczone. Również kroki są lepiej opisane, a sam etap ma wyraźniej oznaczony cel tzn zebrać ogólne informacje a nie zagłębiać się w szczegóły.  Moduł jest podzielony na kroki:

• weryfikacja danych wejściowych,
• chaotyczna eksploracja - ale tylko przy trybie bez materiałów wsadowych, przy wsadzie ten krok nie ma sensu, ale jest opcja uzupełnienia zdarzeń jeżeli użytkownik sobie tego życzy,
• oś czasu, weryfikacja zdarzeń,
• granice i pivotal events,
• weryfikacja języka wszechobecnego (Ubiquitous Language),
• hot spoty i aktorzy,
• przejście przez cały proces od początku do końca - weryfikacja czy nic z poprzednich kroków nie zostało pominięte,
• weryfikacja procesu od tyłu - wymagane przy wsadzie,
• synteza i zapis wyniku,
• weryfikacja rezultatów

Rezultaty poszczególnych faz mają własne pliki wynikowe, dzięki temu można łatwiej rozeznać się co zostało zmienione lub dodane w danej fazie, dodatkowo jest też informacja gdzie co zostało wykonane więc można zacząć od ostatniego zarejestrowanego wyniku.

Process Level

Moduł drugi też został zmieniony, uzupełniony o kroki których brakowało i uszczegółowiony.  Został nadany mu dokładniejszy sens i wyznaczone jego granice. Kroki tego procesu:

• utworzenie struktury katalogów,
• załadowanie rezultatu fazy pierwszej oraz jeżeli jest danych wejściowych ze wsadu,
• odkrywanie subdomen - heurystyki,
• typy subdomen,
• pivotal events - weryfikacja,
• bounded contexty - heurystyki,
• przepływy procesów,
• polityki,
• relacje między kontekstami,
• zapis wyniku,
• weryfikacja rezultatów

Każda faza jak poprzednio zapisuje wynik w swoim pliku.

Wnioski ze zmian

Fable namnożył bytów, moje uwagi nie były tak dokładne a model dołożył ich trochę i wyglądają sensownie, ale to wyjdzie w praniu, być może z częścią z nich się pożegnam, albo zmienię. Testy pokażą czy to właściwe podejście, czy nie trzeba będzie ponownie dzielić czy też modyfikować zawartości.

A co z design level? Na tę chwilę nie rozwijam tego kroku ani następnych chce prejść przez dwa pierwsze, spróbować doszlifować orkiestratora, zrobić jakieś "mocne" i poprawne jakościowe testy. Dopiero po tym jak będę miał gotowe te kroki przejść dalej, żeby spiąć to w jedną całość, aczkolwiek jak już wspominałem może być potrzeba podzielenia tego na więcej osobnych części.

Co teraz?

Teraz, czas odpalić testy i przepalać tokeny w nadziei na lepsze jutro i brak nowych pomysłów.

Linki:

• plik wzorca,
• comparator wzroca z wynikami testu,
• przykładowy rezultat niezgodności,
• przykładowy rezultat rozszerzania,