Harness Warsztaty

W tym roku na BB4IT wróciły warsztaty jednym z tematów był harness enginering. Uznałem, że warto się tam pojawić żeby poszerzyć wiedzę na ten temat. W końcu od maja próbuje coś takiego stworzyć a idzie jak po grudzie.

Krótki opis tego co było na warsztatach

Na wstępie zaliczyłem wpadkę, hm, zapomniałem laptopa ( człowiek idzie na warsztaty i zapomina laptopa- szczyt, szczytów) za to miałem zeszyt, którego kilka stron zostało zapełnionych, dzięki temu powstanie ten wpis i mój kolejny projekt dotyczący harnessa zostanie zapgrejdowany.

Czego nie mam u mnie a co powinno być?

AI jako maszyna do robienia softwaru, czemu nie, taki był jeden z motywów przewodnich tego warsztatu. Coś co stanie się deterministycznym narzędziem umożliwiającym:

• zbudowanie
• testowanie
• kontrolowanie

Problemem LLM-ów jest niedeterministczność, brak powtarzalności, taki hareness może to zmienić poprzez włączenie w proces punktów które nie są ejajowe, są wywołaniem deterministycznych skryptów które umożliwią kontrole wyprodukowanej treści. 

No to było by na tyle.

Co wyniosłem dla siebie (nie był to czyiś laptop, były całkiem nie złe porównując do mojego)? Zrozumiałem, że zbłądziłem, sam warsztat wyznacza cel pokazuje jak do niego dotrzeć poprzez zastosowanie tego co jest w np w moim przypadku w dokumentacji klaudiusza, ale reszta to jest moja praca która włożę w implementacje zdobytej wiedzy.

Tym o to sposobem powstała wersja 0.2.0 mojego chomąta, tak zmieniłem numeracje, zmieniłem wiele rzeczy.

Na początek postanowiłem że odejdę od quality gate w formie mojej osoby, na rzecz automatów, to był temat szeroko omawiany na warsztacie czyli jak zadbać o jakoś, jak sprawdzić czy kolega AI (ajaj) wykonuje zadanie dobrze?

Quality Gates

W moim przypadku jest to i proste i nie co trudniejsze, dlaczego?

Tematem mojego projektu jest refaktoryzacja no i wprowadzenie zmian, stworzenie bram jakościowych jest proste bo jednym z zadań refaktoryzacji jest stworzenie testów czyli mamy gotową bramę typu sprawdz czy testy są zielone.

Trudne, ponieważ ja podzieliłem każdy etap na kroki analiza - implementacja to quality gate do analizy jest dla mnie wyzwaniem, nie implementacja.

Jak sprawdzić że analiza czyli propozycja zmian jest właściwa?

Jeżeli chodzi np  o zaproponowanie testów do istniejacego kodu, to nie jest tak źle, ale np zmiany żeby te testy można było wprowadzić, i jak sprawdzić czy te zmiany są właściwe? owszem to może być sprawdzone po implementacji zmian. Ale jak wspominałem, ja mam podział analiza czyli wytworzenie zmian jako instrukcja oraz implementacja jako wprowadzenie zmian w kodzie, to nie wydaje mi się już takie proste, na razie jest to rozwiązane poprzez sprawdzenie czy posiadam pliki wynikowe czy one składają się z odpowiednich sekcji, sam etap1 i krok poświęcony analizie jest oparty o to co zaproponował Feathers w swojej książce więc mam jakieś oparcie o istniejące infrormacje.

Podział taki daje mi możliwość przełączania między modelami, analiza Opus, implementacja Sonet.

(tak na marginesie poprawiam to kilka dni po tym jak napisałem wersje pierwszą niniejszego tekstu i już mam rozwiązanie jak zrobić quality gate do analizy ;-), opis później, jak przetestuje).

Jak najmniej AI w AI - zdanie które padło podczas warsztatów

Hooki - to coś co motywuje klaudiusza do bezwględnego posłuszeństwa, nie miałem tego, ale już mam (tylko nie przetestowane na chwilę tworzenia posta), dzięki temu mogę wymusić na modelu zachowanie określone np za pomoca eventów np w czasie startu (`SessionStart` ),  czy np w czasie startu agenta (`SubagentStart`) i wiele innych tyle, że hooki nie są przenaszalne między dostawcami, są zależne od modelu na którym pracuje.

Co do samych hook-ów, uczę się jak to zastosować, mam już jeden w moim harnasiu ale jeszcze nie jestem pewny jego.

Za pomniałem dodać, hooki i quality gates można ze sobą powiązać, ale nie trzeba. Najważniejsze to sprawdzenie jakości wypluwanych odpowiedzi.

Agenci

To też ważny aspekt harnessa, to tu odsyłam zadania poprzez orkiestratora, to tu idą zlecenia pracy, dla poszczególnych agentów. Agent ma to do siebie, że działa na swoim kontekście ma swoją pamięć i po zakończeniu działania poprostu jest wyłączony więc nie zabiera kontekstu orkiestratora.

Ja podeszłem źle do moich agentów, zresztą do hook-ów też. Klaudiusz wprowadził mnie w błąd, nie po raz pierwszy zresztą, dlatego od dziś będę dokładniej sprawdzał dokumentacje bo sam LLM lubi błądzić i udowadnia to co chwilę, a ja błądzę razem z nim z powodu mojej nie wiedzy.

 

MCP

O tym nic nie powiem, bo na tę chwilę nic nie wiem, nie korzystam z tego w moim projekcie, chyba że nie wiem że korzystam ale to inna sprawa.

I koniec... no nie zupełnie na koniec posumowanie.

Podsumowanie

HM? Warto było na warsztaty przyjść, (ale z laptopem ehhh), informacje podane na tacy plus kontakt z prowadzącymi i możliwość otrzymania szybkiego fedbacku gdy coś robie dobrze lub źle. Podejście od zera do tematów zaawansowanych też było właściwe jak dla mnie, bo nawet taki ktoś jak ja który już przed warsztatem coś próbował wyskrobać samemu, widział, że mogłem rzeźbić lepiej.

A na koniec, bez własnych prób to i tak wiedza taka nie przetrwa za długo, to jak z programowaniem trzeba próbować implementować zdobytą wiedzę, i to właśnie robię, czy dobrze, czy źle? to jest inna kwestia ale uzyskana wiedza z warsztatów prowadzi do tej drugiej opcji. 

Na koniec linki do mojego nowego harness

• Chomąto do refaktoryzacji - dwie wersje, pierwszą testuje drugą rozwijam
  
•  coś dla masochistów DIY Tutorial - Jak zrobić uprząż? Harness krok po kroku
• nawet jestem na zdjęciach skromnie powiem że ten najprzystojnieszy, najbystrzejszy, najmądrzejszy i najskromniejszy Warsztaty BBDays4It

P.S.
Zapomniałem napisać kto prowadził warsztaty:

• Michał Michaluk
• Artur Dorda

Projekt harnesa związanego z event stormingiem, został zakończony. 

Uznałem, że nie ma sensu go kontynuować, nie panuje nad zmianą, rozrósł się do niebotycznych rozmiarów. Doświadczenia przy nim zebrane pchnęły mnie w objęcia nowego projektu, tym razem harness do refaktoryzacji.

Bogatszy o poprzednie doświadczenia, i potrzebę chwili rozpocząłem generowanie nowego projektu. Tym razem postanowiłem wziąć na warsztat temat pracy z legacy kodem, który intensywnie eksploatuje od jakiegoś czasu. Potrzebowałem ustrukturyzować i zautomatyzować kroki, które są potrzebne do bezpiecznej zmiany.  

Wersje

Aktualnie mam wersje trzecią tego projektu.

1. Ta wersja to był po prostu skill, w którym zaczołem opisywać zasady w jaki sposób będę podchodził do refaktoru.
2. W tej wersji wprowadziłem orkiestratora, bo się skill rozrósł i naturalnie poszedłem w kierunku harnessa.
3. Tutaj aktualnie jestem, wprowadziłem opcje testowania - jeszcze nie przetestowana.

Oczywiście to nie koniec, pomysły mam kolejne ale muszę się powstrzymywać bo te pomysły w poprzednim projekcie spowodowały jego niepokojący rozrost.

Krótki opis tego co mam.

Całość to jest pięć plików:

• orkiestrator - zarządca niewolników,
• etap 0 - ten etap jest od sprawdzenia czy harness był już uruchamiany,
• etap 1 - etap analizy i wprowadzania testów
• etap 2 - etap właściwej zmiany
• etap 3 - niegotowy/niezaimplementowany

Szczegółowy opis

Ten mój mały harness opisuje podejście do refaktoru, na początek kierowałem się bardziej Feathrsem i to jego podejście było główną przyczyną do tego żeby to powstało, ale później uznałem, że LLM ma też kierować się innymi "wielkimi", także są tam jakby cztery konteksty w których się ma poruszać. 

Uznałem, że ten harness  w pierwszym etapie swojego istnienia będzie działał w oparciu o decyzje użytkownika. Dlaczego tak a nie automatycznie jak we wcześniejszym projekcie? To ze względu na to że nie ufam LLM-om, nadmiar zmian jest nie doogranięcia (przeze mnie) więc uznałem że na razie nie będzie automatu póki nie napiszę jakieś sensownej weryfikacji zmian to weryfikował to będzie człowiek.

Twarda zasada jest taka, że nie ma komitowania, uruchamiania przez AI to człowiek musi robić.

Etap 0

Podstawą działania tego harnesa jest wznowienie pracy po np wyczyszczeniu kontekstu co jest też kolejną podstawą w tym projekcie, tych podstaw to będzie kilka, może filar to lepsze słowo.

No to podstawowe założenie, to jedno z nich właśnie takie, że harness ma działać po tym jak  z jakiegoś powodu zakończy, przerwie działanie ma wznowić w tym samym miejscu. Od tego jest etap 0 żeby to zweryfikować. W wersji 3 weszły jeszcze testy wiec etap 0 oprócz normalnego odpalania bada czy był też test uruchamiany.

Ten etap wykonuje agent, żeby nie marnować cennego kontekstu. Wynikiem jest json i tylko tyle. Orkiestrator otrzymuje wiadomość czy kontynuować sesje czy robić od nowa całą konfigurację. Etap 0 sprawdza też plik refactor-session.md który zapisuje start poprzedniej sesji jeżeli jest więcej niż godzina różnicy orkiestrator nie kontynuuje sesji, zaczyna nową. Ten warunek nie jest jeszcze definitywny, na razie taki czas jest ustawiony na podstawie testów będzie go można zmienić. Mam też taki pomysł żeby dodać plik konfiguracji do harnesa z opcjami, które wpłyną na zmianę zachowania, bez potrzeby ingerencji w defincje samego projektu. Ale to w późniejszych wersjach.

Orkiestrator

Nim przejdę do etapu pierwszego słów kilka o orkiestratorze, tym razem zarządca niewolników pełni inna rolę, tylko zarządza, a przynajmniej na razie tak mu się wydaje. We wcześniejszym projekcie orkiestrator miał znacznie szersze kompetencje, on sterował procesem i był pośrednikiem między różnymi etapami, przygotowywał informacje i przekazywał różnym etapom. Tym razem jest inaczej z powodu specyfiki tematu nie potrzebuje poprzez orkiestratora przekazywać informacji, etapy z definicji działają w izolacji, wyniki jest dostępny w kodzie, bo na kodzie poszczególne etapy bazują, żerują.

Wracając do miszcza ceremoni, orkiestrator bardziej skupia się na zarządzaniu, czyli po odpowiedzi z etapu 0 następuje konfiguracja czyli użytkownik musi odpowiedzieć na kilka pytań, co orkiestrator skrzętnie zapisuje i pamięta, oraz przesyła do poszczególnych etapów. 

Dlaczego tak, ponieważ zauważyłem, że czasami mi się konfiguracja traciła i co jakiś czas muszę przypominać ją jak pracuje z LLM-em. Teraz konfiguracja jest w pliku i jest przekazywana do etapu, po za tym orkiestrator ma ją zapamiętać w swoim kontekście i po zakończeniu każdego etapu sprawdzić czy to co zapamiętał zgadza się ze stanem zapisanym w pliku, to takie zabezpieczenie na wypadek wystąpienia "piątek kolumny". Jeżeli coś takiego wystąpi to jest to sygnał na natychmiastowe przerwanie działania harnessa, dla mnie to kritikal error.

Orkiestrator ma jeszcze kilka dodatkowych funkcji, może np przełączyć etap drugi na pierwszy jeżeli dostanie takiego requesta, np zaistniał refaktor albo zmiana w kodzie i trzeba zmienić testy, a testami zajmuje się etap 1 nie 2, więc idzie request do orkiestratora który go przepycha do etapu 1.

Ogólne funkcje orkiestratora:

• inicjuje cały proces - co sobie omówiliśmy,
• ustala tryb uruchomienia - normalny czy test, - o tym później, bo się tworzy dopiero,
• przekazuje plik konfiguracji - o tym wspominałem
• czuwa w trakcie trwania - o tym wspominałem przy okazji requestów z etapów,
• pilnuje integralności - sprawdzanie konfiga, 
• pilnuje poprawnego wykonania etapów, o tym potem,
• prowadzi log - tu za bardzo nie ma co omawiać

Co też istotne, wspominałem o tym to, że ja chcę bazować na częstym resetowaniu kontekstu, czyli jeżeli chodzi o clude code, to funkcja /clear. Z tego co wiem to nie da się jej wywołać automatycznie więc na razie jest prośba o ręczne wykonanie tej metody i póki co monit o to nie będzie powiązany ze zużyciem. Na tę chwilę pomysł jest taki żeby po każdej iteracji (o tym przy omawianu etapu 1) wysłać monit o reset. Dlatego tak istotne żeby pamiętać stan i decyzje, po takim resecie wykona się etap 0.

Poprzedni projekt też miał takie zabezpieczenia, znaczy takie które pozwalały wrócić, do kontekstu.

Teraz jednak chciałbym to bardziej rozbudować, pomysł jest taki żeby nad orkiestratorem wprowadzić jeszcze jednego zarządce, a sam orkiestrator pracował by jako agent, czyli wykonał by zadanie i zwolnił zasoby, ale to będzie wymagało doprecyzowania i jakiegoś planu, to w kolejnych wersjach.

Przy okazji wspomnę że zmiany w projekcie też powstają inaczej niż w poprzedniej wersji, są dwa pliki changes.md i changes-test.md. Pliki te służą za wprowadzenie moich pomysłów i realizacje ich przez Klaudiusza, są też swoistą historią, tego jak to powstawało, oprócz gita.

Na razie tyle o orkiestratorze, nadmienię że jest on dość obszerny już, jak w poprzedniej wersji.

Etap 1.

Etap tworzenia testów, przygotowania kodu, na przyjęcie testów. Z tym kodem z którym ja mam styczność bywa różnie ale znacząca większość nie pozwala uruchomić testów, więc trzeba zadbać żeby się dało. Od tego jest ten etap, przygotowanie kodu do utworzenia testów, ale bez jego modyfikacji, czyli minimalna zmiana. Coś takiego właśnie pokazywał Michael Feathers w swojej książce.

Szczegóły

Komunikacja odbywa się za pomocą json, czyli na wejściu i wyjściu generowany jest odpowiedni komunikat, nie przekazuje stanu etapu, tylko polecenie lub info o zakończeniu.

Ten etap pracuje w pętli analiza - implementacja, ale każda faza zaczyna się od wczytania pliku z konfiguracją. Tak jak wspominałem to jest zabezpieczenie, przed tym, że LLM zapomni co zostało we wstępnej fazie ustalone.

Cykl analiza - implementacja może powtarzać się wielokrotnie ale może też być tylko raz, analizę zatwierdza człowiek. W późniejszych wersjach chcę  to zrobić też w pełni automatycznie ale nim to będzie tak działać potrzebuje testów i czegoś co pozwoli mi zweryfikować poprawność wyniku, teraz jeszcze nie mam tego, na razie jest człowiek. Implementacja będzie mogła być robiona przez słabsze modele jeżeli będzie ona dobrze zrobiona, na razie też jeszcze tego nie ma.

 Ogólnie etap dzieli się na kroki:

• ocena testowalności,
• identyfikacja zależności blokujących testy,
• propozycja minimalnego odsprzęgnięcia,
• gdy odprzęgnięcie nie jest możliwe:
• zakończenie działania,
• zakończenie z decyzją użytkownika,
• opakowanie dodatkową abstrakcja,
• pytanie o kierunek zmian
• napisanie testu - obecnego kodu,
• wydzielenie dużych metod - w zależności od ilości kodu którego obejmuje refaktor,
• sprawdzenie wyniku przez użytkownika

W tym etapie znajduje się również opis tego co wspominałem wcześniej czyli przykładu że etap drugi potrzebuje zmiany testu. Ja przyjąłem warunek że tylko etap 1 zmienia piszę, zmienia testy, etap kolejny będzie puszczał requesta z monitem zmiany, szczegóły są opisane właśnie w etapie 1 w sekcji Tryb zadaniowy.

Etap pierwszy ma również opis loga, co jest istotne gdyż dzięki temu można stwierdzić co zastało zrobione, liczę też że dzięki temu będzie  możliwe wznowienie po przerwaniu procesu. 

Ogólnie pracę nad etapami wciąż trwają, coś poprawiam coś dodaje więc ta wersja nie jest ostateczna,  a testy mogą przynieść weryfikacje w poszczególnych punktach.

Etap 2

 Ten etap jest uruchamiany przez orkiestratora, użytkownik akceptuje etap pierwszy. Ten etap to konkretne zmiany, mamy testy jesteśmy bezpieczni.

Ten etap docelowo będzie miał dwie funkcje zmiana funkcjonalności i refaktor, oraz sam refaktor. Na razie zaimplementowana jest opcja druga tylko refaktor, ale nie przetestowana.

Wariant refaktor składa się z kilku kroków, opisałem je według moich wytycznych, w późniejszych wersjach będzie można je zmienić i wpisać swoje.

• czytelność (nazewnictwo),
• magic numbery,
• przerwanie zależności

kolejne kroki są jeszcze w budowie, czyli jeszcze nie są zdefiniowane. Cały harnes nie jest skończony, w miarę przechodzenia przez kolejne etapy testów części harnessa będą uzupełniane.

Podsumowanie

Tak jak wspominałem, część etapów jest w budowie, nie wszystko jest zaimplementowane. Aktualnie skupiłem się nad zaimplementowaniem orkiestratora głównych etapów oraz testów narzędzia z możliwością mockowania, tę opcje muszę przetestować i stworzyć system ocenny, scenariusze testowe. 

Jak będzie to gotowe to można znowu przejść do rozbudowy poszczególnych etapów.

A w ramach testów samego narzędzia mogę uruchomić etap pierwszy i częściowo drugi, co pozwoli na weryfikacje działania poza trybem testowym.

Na koniec link do repo projektu :

legacy-refaktor-harness

Testy wersji 3.4

Narzędzie mam "gotowe".

Gotowe na jakimś etapie, testy już robiłem ale wyniki nie są dla mnie zadowalające, bo samo określenie tego czym jest wynik jest kiepskie. Bo właściwe pytanie jakie powinno paść, jaki jest cel?

Dobre pytanie, nie wiem.

Na początek miał być skill do analizy, potem się rozrósł do orkiestratora i etapu big picture i process level z oceną wsadu i dokładniejszą realizacją poszczególnych kroków. Teraz okazało się, że nie generują się dodatkowe zdarzenia w big picture co też było jedną z podstaw ale dlatego, że działałem na dużym zbiorze wsadowym to tego nie zauważyłem.

Po za tym mam kilka trybów i liczyłem na taki agentowy automatyczny, bo jestem leniwy ale z tego trybu wiele nie uzyskam, wydaje się, że lepszym będzie tryb pół automatyczny w którym będę razem z LLM przechodził po kolei przez proces. To podejście już testowałem przy któreś wersji.

Reszta trybów to tylko dodatek, który rozwijany gdzieś obok  przy okazji mógłby być.

Tylko pojawił się problem z oceną wyjścia.

System oceniania.

Z oceną był problem od samego początku, ale natchnął mnie film z MIT Sloan Management Review Polska (materiał nie jest o tym, ale ta część mnie zaciekawiła) gdzie była wzmianka o systemie oceniania.

Ja taki system spróbuje sobie zaimplementować, będzie on działał na przynajmniej trzech poziomach.

1. Ocena narzędzia,
2. Ocena wyjścia na podstawie wejścia,
3. Ocena procesu.

Pokrótce przedstawię jak to widzę, potem będzie zderzenie z rzeczywistością.

Ocena narzędzia

Moje narzędzie czyli orkiestrator, działa na podstawie kroków, musi je wykonać w pewnej sekwencji, prawie zawsze, te prawie zawsze zależy od trybu i jakości wsadu ale te kroki można ubrać w ocenę narzędzia i wyznaczyć czy za każdym przejściem wykonuje kroki, które przewidziałem po wybraniu danej ścieżki. 

Pamiętam, że przy któreś wersji to badałem ale bez napisania takiego systemu ocennego. Teraz powinienem też skupić się nad logowaniem poszczególnych kroków chociaż istnieje już plik który się generuje na podstawie działania orkiestratora czyli session.md.

Na początek jakieś założenia?:

• determinizm, czyli powtarzalność procesu, tu muszę zaznaczyć, że powtarzalność dla wybranych opcji, więc tak powtarzalność ale zależy co wybiorę
• ocena na poziomie true/false, jest/ nie ma, czyli podejście najprostsze nie wymagające dodatkowych interpretacji,
• tu będę musiał rozpisać scenariusze, czyli kroki procesu jaki powinien być wygenerowany jako wynik

Na razie więcej założeń nie przychodzi mi do głowy

Pojawiło się kilka pytań, które razem z LLM rozstrzygnąłem, wnioski:

• testowanie pełnej ścieżki,
• testowanie tylko orkiestratora, bez danych,
• nie zmieniam testu póki sam proces nie ulegnie zmianie, i nie wymusi zmiany,

Tu pojawia się problem testowanie tylko orkiestratora, trzeba by zrobić mocka do danych, to może być ciekawe.

Na tę chwilę skupie się na zbudowaniu "czegoś" co posłuży do wykonania kroku pierwszego, potem reszta. Przy okazji zbiorę też jakie dodatkowe informacje jak by to miało działać, jak spełnie te podstawowe kroki i sprawdzę czy to działa wtedy można kontynuować. 

Nie zamierzam od razu robić wszystkich trzech etapów ale skupić się na jednym.

Linki

• Ocena agenta dla LLM
  
• Ramy oceny agentów LLM
  
• Repo projektu
  

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, 

P.S.

Po kilku dniach od napisania tego posta pojawiła się kolejna wątpliwość co do wzorca który służy do porównywania wyników, zmieni on formułę na plik json, nie będzie on tekstem, uznałem jednak że to zły pomysł, trzymać wzorzec w formie tekstu. Komparator ma więcej roboty żeby to przetworzyć i porównać jeżeli to będzie json w formacie lżej strawnym dla LLM narzędzie porównawcze będzie miało łatwiejszą robotę. Po za tym to będzie można łatwiej rozwijać, no i sama kwestia tego że taki format pliku będzie bardziej zbliżony do wyników.

Wersja 3.1 wnioski

Testy

Zacznę od testów, zdałem sobie sprawę, że nie jestem w stanie ocenić rezultatów w sposób odpowiedni. Do tej pory to było powiązane z moim doświadczeniem w tym kontekście, ale to za mało. Każda sesja generuje sporą ilość materiałów, potrzeba mi narzędzia do porównywania wyników testu.

Aktualnie testuje tryb agentowy, automatyczny z każdym razem wygląda on coraz lepiej, nie ma pomijania faz, mieszania, LLM sam podpowiada opcje do wyboru i są one właściwe - powiązane z kontekstem. Nie trzeba pisać, ale czasami trzeba doprecyzować bo nie trafia z podpowiedzą. Na razie testy opierają się na big picture i process level i na pełnych materiałach, które mam.

Takie testy chce jeszcze kilka razy przeprowadzić, żebym mieć więcej materiałów porównawczych, potem chce  przejść pełny proces z design level w trybie automatycznym - agentowym. By następnie się wrócić do dwóch pierwszych ale z ograniczonymi materiałami.

Wnioski

Tak jak wspominałem będę budował razem z Klaudiuszem instrukcje testowania wyników, ale już teraz widzę że jednym z problemów jest to że LLM potrzebuje bardzo dokładnych instrukcji co ma zrobić, jeżeli nie będą dokładne to ogólny zarys zadania będzie dobrze zrobiony ale reszta, która nie jest dobrze wytłumaczona, czyli tło będzie wymyślane na bieżąco. W moim przypadku widać do w rozrastarającyh się plikach skilla, zadaje coś Klaudiuszowi on robi to dobrze, weryfikuje to co piszę ale za każdym razem dodaje dodatkową "panierkę".

Plik z instrukcjami porównywania V3.1/deep-analysis-test-comparator.md

Zapomniałem o ważnej rzeczy Klaudiusz ma jeszcze pamięć swoją schowaną w katalogu .claude/projects/, pamięć poprzednich sesji, powinienem ją usuwać za każdym razem albo wrzucić w skilla info że by sam kasował.

Wersja 3.1

 Wersja 3.1

Zmiany względem poprzedniej wersji:

• dodanie kolejnego pliku, który przejmie od orkiestratora obsługę badania pokrycia materiałami poszczególnych faz ES,
• dane wsadowe mają teraz swój katalog wpisany w orkiestratora,
• nastąpiła zmiana i wymuszenie wyboru trybu pracy, a nie zawsze wybieranie domyślnego
• został dodany log - orkiestrator ma zapisywać każdy krok który wykonuje w formacie data, godzina, krótki opis, dwa trzy słowa,

Testy

Testy będą takie jak poprzednio ale tym razem postaram się uruchomić test w trybie automatycznym, jeżeli się to uda kolejne testy będą prowadzone w tym trybie. Później przejdę do kolejnego trybu, tu jest trochę trudniej z ustaleniem prawidłowego wyniku, muszę stworzyć taki wzór danych wejściowych, tekstowych, które mogły być uzupełnieniem materiałów z event stromingu.

Nim jednak przejdę do trybu drugiego czyli Eksperckiego to chce sprawdzić jak się zachowa ten skill gdy dane będą mniejsze.

Sama sekwencja testów czyli takie przypadki testowe, będą tworzone na bieżąco, tu również mam kilka pomysłów które można by realizować.

Wyniki

Rezultaty jak i sam przebieg testu nie będę już wrzucał w formie posta, a w repozytorium z wynikami każda wersja będzie miała swój katalog z testami, wnioskami czy też uwagami. W poście będą kolejne zmiany jakie będą w następnych wersjach, ogólne uwagi i być może jakieś wnioski. Tym razem nie będę się rozpisywał co i jak zostało podane i wrzucone jako wsad, chce żeby to było przy wynikach testowania danej wersji. Również będę dążył do tego żeby materiały wsadowe były takie same między różnymi wersjami i przypadkami testowymi.

Wnioski

W porównaniu z pierwszą czy drugą wersja trzecia jest znacznie bardziej rozbudowa, w głowie zaczyna mi się powoli rysować obraz tego jak to testować i poprawiać, ale nim wizja się wyklaruje minie jeszcze trochę czasu. Sądzę że wersja 3.1 będzie bardziej testowana niż poprzednia i dłużej będę zwlekał z przejściem do wersji kolejnej, chce w końcu zdobyć pewną ścieżkę do testowania i weryfikacji wyników, wielokrotnie uruchomić te skille i sprawdzić na dłuższej "ścieżce" jak się to zachowa.

Główne repo projektu będą tam wrzucane kolejne wersje skilla a rezultaty usuwane i przenoszone do repozytorium wynikowego, tu powstanie struktura do przechowywania wyników i plików z danej wersji, mam nadzieję że zachowam porządek.

Skill do analizy wersja trzecia

wersja druga dobijała do limitu 500 linii na plik, postanowiłem ją podzielić. Dodatkowo rozdzielić zadania, tak powstał orkiestrator i kolejne skille odpowiedzialne za różne zadania. Czyli wersja numer 3.

Skill się rozrósł, jest trochę większy:

• deep-analysis-orchestrator,
• deep-analysis-data-prep
• deep-analysis-big-picture
• deep-analysis-process-level
• deep-analysis-design-level
• deep-analysis-specialist
• deep-analysis-mermaid-generator
• deep-analysis-llm-blueprint
• phase-1-template
• phase-2-template
• phase-3-template

W czasie testów wersji drugiej, miałem kolejne pomysły i tak się to rozrastało, w końcu razem z Klaudiuszem wysmarowaliśmy jedenaście plików, z czego faktycznie gotowe do testów są cztery pierwsze. W tej fazie, wersji zależy mi na przetestowaniu orkiestratora i sprawdzeniu czy działa zgodnie z założeniami.

Założenia

Zastanawiałem się nad tym jaki powinien być ten skill kilka rzeczy mi się nasuneło, będzie ewoluowało w trakcie testów wersji trzeciej mogę już napisać kilka podstawowych celów.

• Skill musi być deterministyczny - powtarzalny nie zależnie od domeny, 
• Musi wykonywać kroki w zależności od dostępnych materiałów
• Musi współpracować z użytkownikiem i niczego nie narzucać, być współpracownikiem, a nie zarządcą.
• Człowiek ma moc decyzyjną ale LLM na podstawie reguł ze skilla może sugerować rozwiązania oraz ostrzegać przed konsekwencjami,
• Wyniki muszą być czytelne dla LLM ale też dla człowieka, na różnych stanowiskach,
• Nie może być tak że sam skill będzie pożerał tokeny
• Skill musi być odporny na awarie, czynniki zewnętrzne, które mogą przerwać proces

Na razie tyle, albo aż tyle, spełnienie wszystkich może być trudne ale jest do czego dążyć.

Szczegóły

Orkiestartor nie bierze udziału w analizie jest "nadzorcą" modułów, które mają wykonywać poszczególne kroki analizy.

W aktualnej wersji orkiestrator rozpoczyna proces od zbadania czy jest to kontynuacja czy nowa sesja

w katalogu state jest zapisywany stan sessji.

Nadzorca zbiera podstawowe dane:

• Cel sesji,
• stan materiałów wsadowych - na których ma się oprzeć analiza,
• krótki opis kontekstu,
• poziom szczegółowości event stromingu

Tu jest istotna uwaga, system (nazwę to w ten sposób żeby było łatwiej mi opisywać jego zachowanie, będzie to tylko określenie w kontekście tego posta) będzie sugerował różne tryby i rozwiązania ale i tak człowiek, operator, może zadecydować inaczej i pominąć pewne kroki.

Np. Jeżeli nie mamy materiałów wsadowych system zasugeruje rozpocząć od big picture ale operator może zadecydować inaczej ale w tym momencie LLM powinien ostrzec przed konsekwencjami jeżeli nie znamy procesu rezultat może być nie odpowiedni.

Jeżeli mamy materiały zostaną one zapisane w katalogu state/inputs będą one przetworzone i ich format zostanie zamieniony w taki sposób żeby nie trzeba było za każdym razem marnować tokenów na wczytywanie kontekstu.

Po załadowaniu materiałów następuje faza ich badania w celu wykrycia z na które fazy event stromingu są zrealizowane lub też ile materiału przypada na poszczególne części. Kryteria:

• Big Picture   [X%] — kryteria: aktorzy, zdarzenia domenowe, granice systemu,  liczba zdarzeń względem złożoności
• Process Level [X%] — kryteria: przepływy, reguły biznesowe, wyjątki, hot spoty
• Design Level  [X%] — kryteria: agregaty, encje, kontrakty, bounded contexts

Wynik zapisany w state/inputs/processed/

Przed każdym krokiem analizy orkiestrator przygotowuje dane dla agenta w odpowiednim formacie.

Tryby pracy, zgodne z poprzednią wersją:

### Tryb 1 — Agentowy (Claude orkiestruje)

Claude dzieli domenę na konteksty i przydziela je sub-agentom.

### Tryb 2 — Ekspercki (użytkownik jako ekspert domenowy) ← domyślny

Sub-agent zadaje pytania, użytkownik odpowiada.

Claude śledzi spójność między odpowiedziami i sygnalizuje konflikty.

### Tryb 3 — Mixed (współpraca)

Część kontekstów trafia do sub-agentów, część użytkownik prowadzi sam.

### Tryb 4 — Użytkownik jako orkiestrator

Użytkownik decyduje co i kiedy badać, sub-agenci dostają konteksty od użytkownika.

Claude reaguje na pytania i pilnuje spójności na żądanie.

Obowiązuje coś takiego jak pętla zwrotna jeżeli analiza danej fazy będzie miała wpływ na poprzednie fazy będzie to uwzględnione w rezultacie fazy poprzedniej.

Testy

Zastanawiałem się nad tymi testami, środowiskiem testowym. Na początek będzie osobne repo na wersję trzecią, zostaną stworzone logi które ręcznie będę ściągał, posłużą do śledzenia tego co robi model.

Ciekawi mnie to czy dane wynikowe nie będą wykorzystywane przez Klaudiusza do poprawienia wyników więc trzeba będzie wyniki trzymać na osobnym repo. 

Co będę sprawdzał w tej wersji? Skupie się bardziej na orkiestratorze i jego pracy.

Trzeba będzie wrócić do tego co robiłem dziesięć czy więcej lat temu czyli do pisania scenariuszy testowych, historia zatacza koło, znowu jestem testerem ;-).

Ale takie use casy nieuniknione są, tylko nie mogę być pewny w tym wypadku czy dostanę za każdym razem to samo ale do tego będę dążył bo to jedno z założeń. I tak nie ma co ukrywać Klaudiusz będzie mi pomagać testować, zresztą sam podsuwa mi pomysły co robić.

Sądze że trzeba będzie przejść przez proces BIG Picrure i Procces Level uzyskując najlepszy wynik zbliżony do oczekiwanego, stworzyć go jako wzorcowy i porównywać wyniki kolejnych prób do niego, jeżeli próby będą takie same albo lepsze wtedy taka próba staje się wzorcem.

Docelowo repo z wynikami oraz plikami wynikowymi z każdej sesji będzie osobne żeby zabezpieczyć się przed fałszowaniem danych przez samego LLM.

Ale na razie testy orkiestratora i pracy z poszczególnymi częściami.

Wyniki

W między czasie przeprowadziłem pierwszy test tu jest repo wyniki oraz repo ze skillem w wersji 3. Mam już poprawki i powoli przygotowuje wersje 3.1. Będzie dodatkowy plik który będzie służył tylko do oceny jakości materiałów, dzięki temu sam orkiestrator będzie nie co lżejszy. Muszę też poprawić obsługę trybów oraz ustalić komendy które będą trigerować rozpoczęcie kolejnego etapu. Co do danych testowych to mam event strorming na różnym etapie od Big Picture do Desing level więc mogę się bawić różnymi materiałami wsadowymi.

Testy będą długie już mogę stwierdzić że, core domain został wybrany inaczej niż w wersji drugiej ale nie jestem pewny czy to nie przez moje odpowiedzi. Dlatego też zależy mi na poprawnym uruchomieniu trybu automatycznego dzięki któ©emu będzie można lepiej sprawdzić wyniki.

......