AI od teorii do praktyki – przykładzie Venom v 1.5

A

Wstęp

English version (PDF)

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 – Analiza przebiegu zapytania — przepływ decyzji i diagnostyka orkiestratora

III. Architektura systemu Venom

Rozmowy o architekturze najlepiej zacząć od diagramu. W przypadku Venom zaprojektowany został dedykowany ekosystem.

Rysunek 2- Architektura systemu Venom v1.5 — ujęcie warstwowe

W projektach preferuję analogie ze świata rzeczywistego zamiast nazw kodowych, które niewiele mówią osobom spoza projektu. Prosta, poglądowa tabela idei — bez niuansów implementacyjnych — pozwala spojrzeć na system z szerokiej perspektywy.

W systemach tego typu łatwo wpaść w pułapkę „ma robić wszystko”. Jasny podział na wersje oraz kolejność realizacji skutecznie porządkują rozwój projektu.

Poniżej lista komponentów systemu Venom.

OrganFunkcjaRola w organizmieTechnologiaWersja
HabitatŚrodowiskoSandboxWSL2 + Dev ContainersV1.0
KomunikacjaWymiana myśliSilnik inferencjiOllama / vLLM
FastAPI + WebSocket
Next.js
v1.0
System nerwowyOrkiestracjaDialog, pętle decyzyjneAutoGen + Orchestrator (FastAPI)v1.0
MetabolizmWydajnośćWykonanie modeliONNX / GGUFv1.0
Układ krążenia (Hive)Kolejki i dystrybucjaRouting i statusy zadańRedis + ARQv1.0
Płat czołowySzybkie myślenieGeneruje 90% koduPhi-3 (ONNX/GGUF), Ollama/vLLMv2.0
WyroczniaGłębokie myślenieTrudne problemyOpenAI GPT-4o, Gemini, Claudev1.0
Rozszerzona inteligencjaZmysł zewnętrznyWiedza z internetuResearcher Agent + DDG/Tavilyv2.0
HipokampPamięćMapa wiedzyGraphRAG + LanceDBv1.0
Móżdżek (CerebellumUczenie (Fine-tuning)Pamięć mięśniowa, odruchyThe Academy (LoRA/QLoRA)V1.5
Kora przedczołowa (Prefrontal Cortex)KontrolaŚwiadome planowanieWorkflow Control Planev1.5
RęceDziałaniePliki, shell, gitSemantic Kernel + Skillsv1.0
Oczy (cyfrowe)Percepcja UIAnaliza zrzutów ekranu (eyes.py)Ollama (vision) / OpenAI GPT-4ov1.6
Oczy (cyfrowe)Percepcja UIDocelowy engine lokalnyFlorence-2 ONNXv2.0
UszySłuch (STT)Transkrypcja audio (WhisperSkill)faster-whisper (CTranslate2)v1.6
UstaMowa (TTS)Synteza głosu (VoiceSkill)Piper TTS (ONNX)v1.6
Oczy (fizyczne)Percepcja w świecieObiekty, przeszkodyYOLO ONNXv2.0
NogiRuchMobilnośćIntegracja z Rider-PiV2.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:

  1. Venom Core (/venom_core) – Mózg operacji
    • Rdzeń systemu odpowiedzialny za logikę decyzyjną Asystenta.
    • To tutaj działa orkiestrator, zarządzanie agentami oraz warstwa pamięci. Core realizuje proces „myślenia” i wystawia API, ale nie posiada własnego interfejsu graficznego — jest czystą logiką biznesową.
  2. Web Next (/web-next) – Control Plane
    • Warstwa operatorska oddzielona od logiki systemu.
    • Nowoczesny frontend pełni rolę centrum dowodzenia: prezentuje stan agentów, logi decyzyjne i metryki w czasie rzeczywistym. Rozdzielenie prezentacji od rdzenia umożliwia asynchroniczną pracę i pełną obserwowalność procesu.
  3. Venom Spore (/venom_spore) – Agenci wykonawczy
    • Zalążek architektury rozproszonej.
    • Spore to lekki komponent wykonawczy, który może realizować zadania poza głównym rdzeniem — odciążając „Mózg” i przygotowując system do pracy w środowisku wielowęzłowym.
  4. The Academy – Warstwa uczenia
    • Mechanizm przekształcający historię działań w materiał rozwojowy.
    • System potrafi destylować doświadczenia i wykorzystywać je do dalszego dostrajania modeli, zachowując wersjonowanie oraz kontrolę nad zmianą „inteligencji”. To przejście od wykonawcy promptów do systemu uczącego się z własnych działań.
  5. Workflow Control – Plan zanim Apply
    • Warstwa zarządzania konfiguracją i zmianą.
    • Wprowadza kontrolowany przepływ Plan → Apply, ograniczając przypadkowe modyfikacje. Zmiany są walidowane, a ich skutki przewidywalne. To architektoniczne zabezpieczenie przed chaosem w systemie agentowym.
  6. Polityka bezpieczeństwa – Podwójny model zaufania
    • System jest chroniony zarówno przed nadmierną autonomią agenta, jak i przed niekontrolowaną ingerencją operatora.
    • Wyraźnie oddzielone są obszary systemowe i robocze, a operacje mutujące przechodzą przez kontrolę uprawnień i audyt.
  7. Metryki i obserwowalność
    • Venom traktuje AI jako system inżynieryjny, nie „czarną skrzynkę”.
    • Monitorowana jest ekonomia tokenów, wydajność oraz ścieżka decyzyjna agentów. Pozwala to analizować nie tylko kod, ale sam proces podejmowania decyzji.

Podsumowanie

Projekt Venom stanowi praktyczną weryfikację tezy, że kluczowym wyzwaniem w systemach opartych na LLM nie jest generowanie odpowiedzi, lecz kontrola procesu decyzyjnego i odpowiedzialność za jego rezultaty. Zastosowana architektura dowodzi, że koncepcja Asystenta AI – z jasno zdefiniowanymi normami, rolami i poziomami autonomii – może zostać zaimplementowana w działającym systemie, w którym decyzje pozostają jednoznaczne i otwarte na analizę.

Jednocześnie projekt potwierdza, że ​​w oparciu o technologie otwartego oprogramowania  możliwe jest osiągnięcie architektonicznej i funkcjonalnej bliskości do rozwiązań komercyjnych, pod warunkiem przyjęcia systemowego podejścia do orkiestracji, pamięci i wykonywania.

Venom to użyteczne narzędzie do analizy decyzji podejmowanych przez systemy oparte na LLM.

W kolejnym artykule skupię się na innym aspekcie projektu Venom – automatyzacji procesu tworzenia oprogramowania oraz wpływie podejścia do wytwarzania oprogramowania wspomaganego przez AI na rolę architekta i sposób pracy zespołów wytwórczych.

Repozytorium projektów

Venom jest rozwijany jako otwarty eksperyment inżynieryjny.

Pełny kod źródłowy, diagramy architektury i dokumentacja są publicznie dostępne:

👉 https://github.com/mpieniak01/Venom

Repozytorium odzwierciedla obecną architekturę v1.5 oraz jej ewolucyjną ścieżkę od weryfikacja koncepcji do środowiska analizy decyzji.

Recent Posts

    Recent Comments

    Brak komentarzy do wyświetlenia.