Od marzeń o agencie RAG do prototypu VBA: rozdzielanie danych surowych i pochodnych

Plan był skromny: stworzenie małej wersji Merge, osobistego agenta AI. Eksperymenty z RAG, LangChain, LangGraph, embeddingami oraz magazynami wektorowymi trwały już wtedy, a pierwotnym pomysłem było zapewnienie agentowi pamięci długoterminowej oraz dostępu do wewnętrznych dokumentów. Wtedy pojawił się inny problem. Zarządzanie projektami na zlecenie stało się chaotyczne, co skłoniło do napisania najpierw małego narzędzia VBA. Wydawało się to proste, ale tak nie było. W miarę postępu prototyp VBA przekształcił się w coś innego – w sposób na badanie logiki biznesowej, którą agent AI mógłby kiedyś odziedziczyć.

Projekty, które odrzucają uporządkowany cykl życia

Praca jako freelancer nie przebiega według ustalonego schematu. Wysyła się stronę docelową, a potem klient chce jej przeprojektowania. Zmienia się kierunek działalności, pojawia się integracja płatności, potem automatyzacja w LINE, a następnie kolejny projekt powiązany z tym tematem. Pod względem finansowym jedno z zadań może zostać już ukończone i opłacone, podczas gdy cała współpraca wciąż trwa. Umowy konserwacyjne są jeszcze bardziej zaskakujące, ponieważ wiele z nich trwa po prostu do chwili, aż klient oznajmi, że ich już nie potrzebuje.

Jedno pole stanu nie jest w stanie tego opisać. Kilka niezależnych wymiarów stanu może to zrobić:

billing_status = closed
task_status = active
invoice_status = pending

Według tego tekstu, po wspólnej lekturze, kwota jest ostateczna, zadanie pozostaje aktywne, a faktura nie została wysłana. W przeciwnym razie potrzebne byłyby dwadzieścia ręcznie zdefiniowanych połączonych stanów. Niezależne pola sprawiają, że model pozostaje mały.

Rozdzielenie obowiązków

Po kilku dniach zastanowienia pojawiła się zasada warstwowości:

Raw Data
   ↓
Small Logic
   ↓
Secondary Data
   ↓
END

Dane pierwotne zawierają fakty. Dane wtórne zawierają obliczone lub przetworzone informacje przeznaczone dla ludzkich oczu. Obowiązuje tu jedna sztywna zasada: brak danych trzeciorzędnych. Arkusz wtórny nigdy nie może służyć do kolejnych obliczeń. Gdy potrzebny jest nowy wynik, praca wraca do danych surowych i tworzy kolejny zestaw danych wtórnych. To może oznaczać ostatecznie wiele arkuszy wtórnych, co jest do przyjęcia. Dwadzieścia niezależnych widoków jest lepsze niż taka łańcuchowa struktura:

Raw
 ↓
Secondary A
 ↓
Secondary B
 ↓
Secondary C
 ↓
Dashboard

ponieważ jeden błąd w środku rozprzestrzenia się wszędzie. Zasada działania polega na tym, że większa liczba arkuszy nie stanowi problemu, natomiast głębsze zależności już tak.

Ścisła struktura pliku roboczego

Arkusze są dzielone według obszaru odpowiedzialności, przy użyciu konwencji prefiksów:

D_ = Raw Data
M_ = Master Data
S_ = System Rules
V_ = Secondary Views

Arkusze danych surowych wyglądają w ten sposób:

D_Task
D_Point
D_Pharmacy

a arkusze główne wyglądają w ten sposób:

M_Company
M_Project
M_Contact
M_Product
M_GroupS_SystemV_TaskList
V_MonthlyBilling
V_CurrentSummary

Arkusze D_ stanowią źródło prawdy. Arkusze M_ to słowniki biznesowe obejmujące firmy, produkty, projekty oraz kontakty. S_System przechowuje konfigurację specyficzną dla VBA: stawki podatkowe, znaczenie poszczególnych stanów, stawkę godzinową oraz cele dochodowe. Arkusze z przedrostkiem V_ to tymczasowe wyniki. Każdy z nich może zostać odtworzony na żądanie i służy wyłącznie do czytania, a nie jako podstawa dla innych wzorów.

Brak bezpośrednich edycji

Stosowano również drugą zasadę: normalna praca nie powinna wymagać ręcznej edycji surowych danych ani głównych arkuszy przez użytkownika. UserForms zajmują się tworzeniem, aktualizowaniem oraz logicznym usuwaniem rekordów. Usuwanie nie odbywa się w sposób fizyczny – zamiast tego rekord jest oznaczony specjalnym symbolem:

record_status = deleted

Wiersz pozostaje w systemie, co powinno ułatwić śledzenie historii i zapobiec przypadkowej utracie danych.

VBA jako narzędzie obserwacji

To właśnie w tym momencie cały projekt zmienił kierunek. Początkowo VBA miało służyć do automatyzacji procesów. Jego lepszą rolą może być obserwacja tych procesów. System może obliczyć przewidywane dochody projektu i farmaceuty, ile dodatkowych dochodów jest jeszcze potrzebnych, co pozostaje w każdym projekcie, które faktury jeszcze nie zostały wysłane, na jakim etapie znajduje się każdy projekt oraz ile punktów zostało już wydanych.

Analiza tych liczb prowadzi do podjęcia decyzji, na przykład do stwierdzenia, że w przyszłym miesiącu nie są potrzebne dodatkowe zmiany farmaceutów. Zapytaj Merge, jak podjęto tę decyzję – uczciwa odpowiedź brzmi dziś mniej więcej „doświadczenie”. Właśnie dlatego decyzja ta nie jest jeszcze zautomatyzowana. System powinien spójnie pokazywać te same informacje, a po wystarczająco długim użyciu w praktyce mogą stać się widoczne określone wzorce w podejmowanych decyzjach. Te wzorce można następnie przenieść do Pythona, a w końcu do agenta. Możliwy przebieg:

Raw Data
   ↓
Python Logic
   ↓
Secondary Information
   ↓
AI Agent
   ↕
Human adjustment through Slack

Zatem wersja VBA nie musi być ostateczną aplikacją. Służy jako laboratorium do ustalenia, co musi wiedzieć ostateczna aplikacja.

Różne narzędzia, różne zadania

Próba umieszczenia wszystkiego w jednym systemie byłaby błędem. Excel obsługuje liczby, faktury, statusy, rekordy oraz wykresy finansowe. Notion przechowuje szczegółowe zadania, notatki i informacje o projektach. Fizyczna tablica informacyjna służy do zapisywania rzeczy, które należy pamiętać lub zauważyć.

Długoterminowy obraz łączy dwa podejścia: jedno przedstawione w formie raportu, a drugie w formie chronologii, przy czym Merge funkcjonuje w Slacku jako główne miejsce do rozmów. Urządzenie Merge w wersji fizycznej mógłoby później odczytywać ważne wiadomości z Slacka na głos za pomocą funkcji konwersji tekstu na mowę. Początkowo generowałoby ono jedynie tekst, a odpowiedzi byłyby wpisywane bezpośrednio w Slacku, ponieważ rozpoznawanie mowy jest trudne na zewnątrz, a wcześniejsze eksperymenty skutkowały nieprzyjemnie głośną mową do komputera. Do bezpośrednich rozmów głosowych z urządzeniem fizycznym znów mógłby zostać wykorzystany Raspberry Pi.

Interfejs użytkownika przemienia się w tablicę

Po dniach rozmów na temat architektury rozpoczęto prace nad pierwszym UserForm, który zarządza grupami, firmami, projektami, kontaktami i produktami. Początkowo zakładano, że będzie służył wyłącznie do celów osobistych i że wygląd nie ma znaczenia. Następnie wybrano zabawny font, zmieniono tło, pojawiły się białe linie rozdzielające, a poważna forma do zarządzania danymi głównymi przekształciła się w interfejs w stylu tablicy. Ocena zespołu Merge brzmiała, że przypomina MergeLab, a szczera reakcja była taka, że jest dość przyjemny w użyciu.

Wewnętrznie wszystko jest ściśle regulowane: zależności, własność surowych danych, logiczne usuwanie oraz zakaz danych trzeciorzędnych. Wizualnie przypomina to kogoś, kto w połowie nocy uczy normalizacji bazy danych na tablicy. VBA nadal nie działa, ale przynajmniej interfejs jest spójny.

Lekcje

Najważniejszą lekcją jest to, że automatyzacja nie powinna zaczynać się od samej automatyzacji. Najpierw trzeba ustalić, która informacja jest faktograficzna, która pochodzi z obliczeń, a które decyzje wymagają nadal ludzkiego osądu.

Mniej arkuszy nie oznacza automatycznie mniejszej złożoności. Wiele niezależnych widoków wtórnych może być łatwiejsze do zrozumienia niż zintegrowane rozwiązanie z długimi łańcuchami danych pochodnych.

Różne rodzaje stanów należą do różnych pól. Zamiast wielu połączonych statusów, niezależne pola mogą opisywać znacznie bardziej złożone sytuacje rzeczywiste:

task_status
billing_status
invoice_status
record_status

Logika biznesowa powinna pozostać poza interfejsem użytkownika. Formularz UserForm zbiera dane wejściowe i wywołuje logiczne funkcje wielokrotnie używalne, arkusz kalkulacyjny uruchamia odświeżanie i pokazuje wyniki, a obliczenia znajdują się w małych, wielokrotnie używalnych modułach. To ułatwia późniejszą migrację prototypu.

Najważniejsze jest to, że prototyp może ujawnić ukryte zasady decyzyjne. Nie musi podejmować każdej decyzji od razu – wystarczy, że te decyzje będą widoczne.

Kolejne kroki

Najpilniejszym zadaniem jest sprawienie, by VBA wykonywało jakieś działania, począwszy od MasterManagementForm, który rejestruje i zarządza grupami, firmami, projektami, kontaktami oraz produktami. Jego podstawowy przebieg to:

Input
 ↓
Validation
 ↓
Generate ID
 ↓
Create / Update / Logical Delete
 ↓
Master Data

Gdy dane podstawowe będą już funkcjonować, następują oddzielne formularze wprowadzania danych dla surowych arkuszy:

D_Task
D_Point
D_Pharmacy

Następnie można utworzyć pierwsze widoki wtórne. Najważniejsze na razie:

V_TaskList
V_MonthlyBilling
V_CurrentSummary

Gdy te rozwiązania staną się przydatne w rzeczywistej pracy, stanie się jasne, które widoki faktycznie są otwierane, a które były tylko wyobrażone. Dopiero gdy ten proces pracy stanie się stabilny, prawidłowa odbudowa z użyciem Pythona, integracji z Slackiem oraz agenta AI stanie się poważną opcją.

Sekwencja działań do tej pory wygląda tak: próba stworzenia agenta opartego na RAG, potem Excel, następnie kilka dni na określaniu granic danych, a na końcu system typu tablica czarna. Rozwój oprogramowania przebiega pomyślnie.