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.
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, w ostatecznej wersji one znikną, są tylko na czas testów.
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ń, głównym 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
......
