Wstęp
Asystenci AI świetnie odpowiadają na pytania. Zdecydowanie gorzej radzą sobie z odpowiedzialnością za decyzje.
Venom powstał po to, by monitorować proces decyzyjny i sterować nim tam, gdzie decyzje mają realne konsekwencje.
W dotychczasowej serii artykułów popularnonaukowych zajmowałem się teoretycznymi rozważaniami na temat sztucznej inteligencji, opartymi na wypracowanej definicji Asystenta AI. Przyszedł czas na weryfikację tych tez w praktyce.
Niniejszy artykuł stanowi kolejny krok — przejście od teorii do prezentacji narzędzia, które pozwala te założenia sprawdzić. Innymi słowy: od teorii do eksperymentu.
W ostatnich miesiącach stworzyłem na GitHubie kilka repozytoriów będących wynikiem eksperymentów z automatyzacją procesów, opartych na architekturze projektowanej pod konkretne, zdefiniowane cele. Jednym z tych projektów jest Venom.
Venom został zaprojektowany w celu weryfikacji dwóch kluczowych założeń:
Czy koncepcję Asystenta AI — z jasno określonymi normami oraz ustalonym poziomem autonomii — można skutecznie zaimplementować w działający system wspierający proces decyzyjny.
Czy bazując na technologiach open source, możliwe jest architektoniczne i funkcjonalne zbliżenie się do rozwiązań komercyjnych rozwijanych przez największych graczy technologicznych w obszarze AI.
I.Kontekst biznesowy
Większość użytkowników przywykła już do prowadzenia konwersacji z modelami językowymi w formie chatu — takimi jak Gemini, GPT czy Grok. Interakcja ta staje się coraz bardziej naturalna, a wrażenie „rozumienia potrzeb użytkownika” jest coraz silniejsze. I słusznie — z perspektywy doświadczenia użytkownika chat okazał się wyjątkowo skutecznym interfejsem. Nie jest to jednak naturalna domena działania większości modeli językowych.
W swoim podstawowym założeniu modele LLM generują odpowiedź na ostatnie wejście tekstowe. Nie „pamiętają” rozmowy w sposób ciągły ani nie śledzą jej znaczenia w czasie. To, co użytkownik odbiera jako kontekst rozmowy, jest w praktyce efektem działania dodatkowych mechanizmów: systemów pamięci, narzędzi pomocniczych, reguł sterujących oraz technicznych promptów dołączanych do treści jawnej użytkownika.
Rozwiązania komercyjne nie prezentują warstwy technicznej konwersacji. W efekcie użytkownik ma wrażenie, że wchodzi w interakcję z „inteligentnym bytem” działającym na zasadzie czarnej skrzynki — bez wglądu w reguły, według których przeprowadzone zostało wnioskowanie prowadzące do zaprezentowania takiej, a nie innej odpowiedzi.
II.Założenia biznesowe projektu Venom
Venom jest systemem eksperymentalnym zaprojektowanym do analizy i kontroli procesów decyzyjnych w rozwiązaniach opartych na modelach językowych. Nie jest produktem końcowym, lecz systemem, który pozwala obserwować, testować i modyfikować sposób działania asystenta AI poza samym modelem LLM.
Podstawowym założeniem projektu jest lokalne przetwarzanie. System może zostać uruchomiony i skonfigurowany na standardowym komputerze osobistym. Po skonfigurowaniu wersji minimalnej może działać bez dostępu do Internetu.
Venom z definicji zakłada tryb jednego użytkownika pełniącego rolę superwizora systemu. Użytkownik decyduje o zakresie autonomii, odpowiedzialności systemu oraz dostępie do zasobów zewnętrznych. Wykorzystanie zewnętrznych usług lub komercyjnych API ma charakter referencyjny lub służy pozyskaniu wiedzy pomocniczej w sytuacjach, gdy lokalne wyniki działania systemu są niezadowalające.
Integralnym elementem Venoma jest interfejs webowy, zaprojektowany jako narzędzie operacyjne. Jego celem jest zapewnienie informacji na temat;
- przebieg procesów decyzyjnych.
- aktualnego stanu systemu,
- zależności pomiędzy komponentami.
Kluczowe elementy interfejsu obejmują:
- Inspektor — umożliwiający śledzenie ścieżki decyzyjnej dla poszczególnych interakcji,
- Graf Wiedzy — prezentujący dynamiczny model kontekstu i relacji pomiędzy informacjami.
W projektowaniu interfejsu zastosowano strategię „dane blisko użytkownika”, polegającą na prezentowaniu informacji zgodnie z ich priorytetem oraz umożliwieniu przechodzenia do szczegółów na zasadzie one-click.
W Venom poziom szczegółowości opomiarowania może sprawiać wrażenie nadmiarowego. Wynika to jednak bezpośrednio z charakteru projektu — zarówno sama realizacja Venoma, jak i jego kluczowe użyteczności opierają się na systemach multiagentowej sztucznej inteligencji.
W tego typu architekturach rozliczalność działań poszczególnych komponentów oraz ich dokumentowanie nie są dodatkiem, lecz warunkiem kontrolowanego rozwoju i dalszej ewolucji systemu.
Bez jawnego opomiarowania i rozliczalności procesów decyzyjnych projekt oparty na AI nie jest systemem — jest zbiorem przypadkowych zachowań.
Rysunek 1- Główny ekran ze szczegółami zapytania
III. Architektura systemu Venom
Rozmowy o architekturze dobrze jest rozpocząć od zaprezentowania diagramu. W przypadku Venom zaprojektowany został dedykowany ekosystem.
Rysunek 1 przedstawia wysokopoziomowy diagram architektury logicznej systemu Venom, ilustrujący warstwową budowę systemu, role poszczególnych komponentów oraz rzeczywisty przepływ procesów decyzyjnych pomiędzy silnikiem kognitywnym, agentami, pamięcią i infrastrukturą wykonawczą.
Rysunek 2- Wysokopoziomowy diagram architektury logicznej systemu Ventom
W projektach preferuję posługiwać się analogiami ze świata rzeczywistego zamian nazw kodowych albo nazw własnych – które też niewiele mówią osoba spoza projektu. Bardzo prosta poglądowa tabela idei bez niuansów implementacji – pomaga patrzeć na projekt z szerokiego aspektu. W projektach tego typu łatwo popaść w ambicjonalizm i postawić sobie cel projekt – ma robić wszystko. Zastosowanie jasnego podziału na wersje z kluczem kolejności realizacji skutecznie rozwiązuje ten problem. Poniżej lista komponentów systemu Venom.
Tabela komponentów systemu Venom:
| Organ | Funkcja | Rola w organizmie | Technologia | Wersja |
| Habitat | Środowisko | Sandbox | WSL2 + Dev Containers | V1.0 |
| Komunikacja | Wymiana myśli | Silnik inferencji | Ollama / vLLM FastAPI + WebSocket Next.js | v1.0 |
| System nerwowy | Orkiestracja | Dialog, pętle decyzyjne | AutoGen + Orchestrator (FastAPI) | v1.0 |
| Metabolizm | Wydajność | Wykonanie modeli | ONNX / GGUF | v1.0 |
| Układ krążenia (Hive) | Kolejki i dystrybucja | Routing i statusy zadań | Redis + ARQ | v1.0 |
| Płat czołowy | Szybkie myślenie | Generuje 90% kodu | Phi-3 (ONNX/GGUF), Ollama/vLLM | v2.0 |
| Wyrocznia | Głębokie myślenie | Trudne problemy | OpenAI GPT-4o, Gemini, Claude | v1.0 |
| Rozszerzona inteligencja | Zmysł zewnętrzny | Wiedza z internetu | Researcher Agent + DDG/Tavily | v2.0 |
| Hipokamp | Pamięć | Mapa wiedzy | GraphRAG + LanceDB | v1.0 |
| Ręce | Działanie | Pliki, shell, git | Semantic Kernel + Skills | v1.0 |
| Oczy (cyfrowe) | Percepcja UI | Analiza zrzutów ekranu (eyes.py) | Ollama (vision) / OpenAI GPT-4o | v1.0 |
| Oczy (cyfrowe) | Percepcja UI | Docelowy engine lokalny | Florence-2 ONNX | v2.0 |
| Uszy | Słuch (STT) | Transkrypcja audio (WhisperSkill) | faster-whisper (CTranslate2) | v1.0 |
| Usta | Mowa (TTS) | Synteza głosu (VoiceSkill) | Piper TTS (ONNX) | v1.0 |
| Oczy (fizyczne) | Percepcja w świecie | Obiekty, przeszkody | YOLO ONNX | v2.0 |
| Nogi | Ruch | Mobilność | Integracja z Rider-Pi | V2.0 |
IV. Ewolucja Architektury
W przeciągu 50 dni. Projekt Venom wyewoluował od prostego skryptu proof-of-concept do modularnego systemu rozproszonego. Obecna struktura repozytorium odzwierciedla podział na logiczne domeny odpowiedzialności. Jest to ekosystem trzech współpracujących bytów:
- Venom Core (/venom_core) – Mózg Operacji
To serce systemu, napisane w Pythonie. W pierwszej fazie projektu (v1) wszystko znajdowało się w jednym pliku main.py. Obecnie venom_core to zorganizowany backend realizujący logikę biznesową Asystenta:
- Orkiestracja: Tutaj znajduje się implementacja pętli decyzyjnych (orchestrator) i zarządzanie stanem rozmowy.
- Zarządzanie Agentami: Definicje ról (Architekt, Koder, Krytyk) i ich prompty systemowe.
- Pamięć: Moduły obsługujące bazy wektorowe (ChromaDB) i grafowe (GraphRAG).
To tutaj zachodzi proces „myślenia”. Core wystawia API, ale sam nie posiada interfejsu graficznego – jest czystą logiką.
- Web Next (/web-next) – Centrum Dowodzenia (Control Plane)
Największa zmiana architektoniczna w v2.0 to całkowite oddzielenie interfejsu od logiki. Zamiast prostych bibliotek typu Streamlit, Venom wykorzystuje nowoczesny stack frontendowy: Next.js + Tailwind CSS.
Decyzja architektoniczna: Oddzielenie warstwy prezentacji pozwala na asynchroniczne odświeżanie stanu. Operator widzi „na żywo” logi myślowe agenta, statusy usług i wykresy użycia tokenów, nie blokując głównego wątku rozmowy.
- Venom Spore (/venom_spore) – Agenci Wykonawczy
Zalążek architektury rozproszonej. Spore (Zarodnik) to lekki kontener wykonawczy, który może być uruchomiony w innym środowisku (np. w chmurze lub na innym serwerze), aby wykonać konkretne zadanie (np. ciężkie obliczenia lub scrapping sieci), nie obciążając głównej maszyny „Mózgu”.
- Metryki i Obserwowalność: Inżynieria zamiast Magii
Posiada wbudowaną warstwę telemetrii. W kodzie zaimplementowano twarde wskaźniki efektywności:
- Ekonomia Tokenów (token_economist.py)
Każda interakcja z modelem kosztuje – albo pieniądze (API OpenAI), albo prąd i czas GPU (Lokalne LLM).
- System na bieżąco zlicza zużycie tokenów dla każdego agenta.
- Pozwala to zidentyfikować „rozrzutnych” agentów i optymalizować ich prompty systemowe (np. skracając kontekst, gdy nie jest potrzebny).
- Latencja i Wydajność (scripts/bench, locustfile.py)
W repozytorium znajdują się skrypty do testów obciążeniowych (używając narzędzia Locust). Mierzymy:
- TTFT (Time To First Token): Jak szybko model zaczyna odpowiadać? (Kluczowe dla odczucia płynności rozmowy).
- Total Generation Time: Ile trwa pełna odpowiedź?
- Debugowanie Kognitywne (Inspektor)
Metryki to nie tylko liczby. W systemach agentowych kluczowe jest śledzenie ścieżki rozumowania – czyli w języku biznesowym podejmowanie decyzji. Venom rejestruje każdy krok decyzyjny Orkiestratora. Jeśli system popełni błąd, mogę cofnąć się w logach i zobaczyć: „Aha, Agent Architekt źle zinterpretował intencję użytkownika w kroku 2”. To pozwala na debugowanie samej inteligencji, a nie tylko kodu.
Podsumowanie
Projekt Venom stanowi praktyczną weryfikację tezy, że kluczowym wyzwaniem w systemach opartych na LLM nie jest generowanie odpowiedzi, lecz kontrola procesu decyzyjnego oraz odpowiedzialność za jego przebieg. Zastosowana architektura pokazuje, że koncepcja Asystenta AI — z jasno określonymi normami, rolami i poziomem autonomii — może zostać zaimplementowana w działającym systemie, w którym decyzje pozostają jawne i możliwe do analizy.
Jednocześnie projekt potwierdza, że w oparciu o technologie open source możliwe jest architektoniczne i funkcjonalne zbliżenie się do rozwiązań komercyjnych, pod warunkiem systemowego podejścia do orkiestracji, pamięci i wykonania.
Venom jest przydatnym narzędziem do analizy decyzji podejmowanych przez systemy oparte na LLM.
W kolejnym artykule skupię się na innym aspekcie projektu Venom — automatyzacji procesu wytwarzania oprogramowania oraz wpływie podejścia AI-Augmented Development na rolę architekta i sposób pracy zespołów inżynierskich.