EA - Wektorowe bazy danych - wstęp

 W erze rosnącej popularności modeli językowych, rekomendacji, wyszukiwania semantycznego i rozpoznawania obrazów coraz częściej słyszymy o bazach danych wektorowych. Choć ich koncepcja istnieje od lat, to właśnie rozwój sztucznej inteligencji dał im nowe życie. W tym artykule pokażę Ci, czym są, do czego służą i jak się z nimi pracuje w praktyce.

Czym są wektorowe bazy danych?

Bazy danych wektorowe służą do przechowywania i wyszukiwania danych w postaci wektorów osadzonych (embeddings). W odróżnieniu od klasycznych baz SQL czy NoSQL, gdzie szukamy po kluczach, tekstach czy relacjach, tutaj wyszukujemy po podobieństwie matematycznym między punktami w przestrzeni wielowymiarowej.

Do czego to służy?

Bazy wektorowe są fundamentem takich zastosowań jak:

• Wyszukiwanie semantyczne (np. „znajdź podobne dokumenty”)

• Rekomendacje (np. „użytkownicy podobni do Ciebie kupili…”)

• Chatboty RAG (Retrieval-Augmented Generation) – pobieranie kontekstu z bazy wiedzy dla modelu LLM

• Analiza obrazów, dźwięku, filmów – porównywanie treści na poziomie cech ukrytych

• Wykrywanie anomalii – poprzez odległość od normalnych przypadków

Jak to działa?

1. Osadzanie danych (embedding):

   • Każdy dokument, obraz czy rekord przechodzi przez model AI (np. BERT, CLIP, OpenAI), który przekształca go w wektor liczb rzeczywistych (np. 768-wymiarowy).

   • Ten wektor reprezentuje znaczenie treści, a nie jej dokładne słowa.

2. Przechowywanie:

   • Wektor trafia do bazy danych wektorowych razem z identyfikatorem i metadanymi (np. kategoria, źródło, użytkownik).

   • Baza indeksuje te dane pod kątem szybkiego wyszukiwania.

3. Wyszukiwanie (query):

   • Nowy wektor zapytania (np. pytanie od użytkownika) porównywany jest z istniejącymi wektorami.

   • Używa się metryk podobieństwa jak:

   • Cosine similarity mierzy kąt między wektorami i ignoruje ich długość — im bliżej 1, tym bardziej podobne.

   • Dot product to iloczyn skalarny dwóch wektorów, który rośnie wraz z ich zgodnością kierunkową i wielkością.

   • Euclidean distance to fizyczna odległość między punktami w przestrzeni — im mniejsza, tym większe podobieństwo.

4. Zwracane są najbardziej podobne rekordy – a niekoniecznie identyczne słowa.

Jakie narzędzia są dostępne?

Najpopularniejsze silniki baz wektorowych:

Narzędzie	Cechy
Pinecone	SaaS, skalowalny, integracja z OpenAI
Weaviate	Open-source + REST/GraphQL API
Qdrant	Wydajny silnik z Rust, JSON API
FAISS	Biblioteka od Meta (do lokalnego użycia)
Milvus	Duży ekosystem, klastrowy
Chroma	Prostota, idealna do aplikacji RAG

 Jak budować model danych?

Zazwyczaj każdy rekord (np. dokument, paragraf, obraz) zawiera:

json
{
  "id": "doc-123",
  "embedding": [0.11, -0.22, ..., 0.03],
  "metadata": {
    "title": "Jak działa GPT",
    "tags": ["AI", "LLM"],
    "language": "pl"
  }
}

Przykład: Wyszukiwanie podobnych dokumentów

1. Użytkownik wpisuje zapytanie: „Co to jest tokenizacja tekstu?”

2. Zapytanie jest osadzane w wektor.

3. Silnik porównuje go z wektorami w bazie i zwraca najbardziej podobne dokumenty.

4. Backend prezentuje wyniki lub przekazuje kontekst do LLM (RAG).

Wydajność i indeksowanie

Wyszukiwanie po setkach tysięcy lub milionach rekordów wymaga specjalnych algorytmów:

• HNSW (Hierarchical Navigable Small World)
  Struktura grafu oparta na wielu warstwach, gdzie najwyższe poziomy łączą tylko najbardziej reprezentatywne punkty, a niższe warstwy szczegółowo łączą bliskie punkty. Umożliwia bardzo szybkie przechodzenie między odległymi wektorami — zbliżone do działania GPS w nawigacji drogowej.

• IVF (Inverted File Index)
  Przestrzeń wektorów dzieli się na klastry (centroidy), a każdy wektor przypisuje do najbliższego klastra. Wyszukiwanie ogranicza się tylko do kilku najbliższych klastrów, co znacząco przyspiesza czas odpowiedzi.

• PQ (Product Quantization)
  Kompresuje wektory, dzieląc je na podprzestrzenie i kodując każdą z nich jako dyskretny indeks. Dzięki temu zamiast przeszukiwać pełne wektory, algorytm porównuje ich zakodowane, uproszczone wersje — drastycznie redukując zużycie pamięci i czas obliczeń.

Silniki bazują na technikach Approximate Nearest Neighbor (ANN), by przyspieszyć wyszukiwanie kosztem dokładności (co często jest akceptowalne).

Bezpieczeństwo i wyzwania

• Zarządzanie aktualizacjami osadzeń (embedding drift)

• Przechowywanie i prywatność danych

• Integracja z bazami metadanych (SQL/NoSQL)

• Skalowanie i replikacja (dla dużych systemów produkcyjnych)

Podsumowanie

Bazy wektorowe nie zastępują klasycznych baz danych — uzupełniają je w kontekście AI i przetwarzania nieustrukturyzowanych danych. Jeśli tworzysz systemy rekomendacyjne, chatboty, aplikacje RAG lub przeszukujące duże zbiory danych – to narzędzie, które powinieneś poznać.

EA - 12-Factor Agents - Nowe podejście, które może zmienić Twoje myślenie o AI

Dlaczego 12-Factor Agents to nie tylko kolejny "best practice"?

Pamiętacie 12-Factor App firmy Heroku z 2011 roku? Te zasady które zrewolucjonizowały sposób budowania aplikacji cloud-native i SaaS? Cóż, w świecie AI mamy teraz podobny przełom - 12-Factor Agents od Dexa Horthyego z HumanLayer.

Ale zanim pomyślimy "kolejny framework", zatrzymajmy się na moment. To nie jest frameworka - to metodologia inspirowana sprawdzoną koncepcją 12-Factor App, ale przełożona na specyficzne wyzwania budowania niezawodnych systemów AI.

Analogie między 12-Factor App a 12-Factor Agents

12-Factor App skupiało się na budowaniu aplikacji które są:

• Przenośne między środowiskami wykonania
• Skalowalne bez większych zmian w architekturze
• Utrzymywalne poprzez jasne separacje odpowiedzialności
• Wdrażalne w sposób ciągły dla maksymalnej elastyczności

12-Factor Agents przenosi te same filozoficzne założenia do świata AI:

• Przewidywalne w działaniu mimo niezdeterministycznej natury LLM
• Modularne zamiast monolitycznych frameworków
• Kontrolowalne z pełną własnością nad kluczowymi komponentami
• Produkcyjne gotowe do wdrożenia u klientów biznesowych

Dlaczego tradycyjne frameworki AI zawodzą?

Tak jak 12-Factor App powstało w odpowiedzi na problemy z monolitycznymi aplikacjami, 12-Factor Agents odpowiada na frustracje z obecnymi frameworkami AI:

Klasyczny przepływ problemów:

1. Decyzja o budowie agenta
2. Szybki start z frameworkiem (LangChain, Crew AI, etc.)
3. Osiągnięcie 70-80% jakości
4. Zdanie sobie sprawy że 80% to za mało dla klientów
5. Próba odwrotnej inżynierii frameworka
6. Rozpoczęcie od nowa - wiadomo że trzeba być elastycznym

Kluczowa obserwacja: Najlepsze "agenty AI" w rzeczywistości to głównie dobrze zaprojektowane oprogramowanie z LLM strategicznie wplecionymi w kluczowych punktach.

12 Czynników - szczegółowo 

Factor 1: Natural Language to Tool Calls (Język naturalny do wywołań narzędzi)

Co to znaczy: Konwersja poleceń w języku naturalnym na ustrukturyzowane wywołania narzędzi.

Przykład praktyczny: Polecenie "utwórz link płatności na 750$ dla Terri" zostaje przekształcone w strukturalne wywołanie API:

{ "tool": "create_payment_link", "amount": 750, "currency": "USD", "customer": "Terri" }

Dlaczego to ważne: LLM świetnie rozumie intencje, ale narzędzia potrzebują strukturalnych danych. Ten factor jest mostem między tymi światami.

Factor 2: Own your prompts (Własność promptów)

Co to znaczy: Nie oddawaj inżynierii promptów w ręce frameworka. Traktuj prompty jako kod pierwszej klasy.

Praktyczne zastosowanie:

• Prompty w plikach, nie ukryte w frameworku
• Wersjonowanie promptów w Git
• A/B testing różnych wersji promptów
• Pełna kontrola nad instrukcjami przekazywanymi agentowi

Dlaczego to krytyczne: Prompt to serce Twojego agenta. Framework może mieć swoje priorytety, Ty masz swoje.

Factor 3: Own your context window (Własność okna kontekstu)

Co to znaczy: Zarządzaj kontekstem rozmowy, historią promptów i stanem, optymalizując wydajność i ograniczając zużycie tokenów.

Techniki zarządzania kontekstem:

• Kompresja historii: Podsumowywanie starszych części konwersacji
• Selektywne przechowywanie: Zachowywanie tylko najważniejszych informacji
• Strategie przycinania: Usuwanie najmniej istotnych fragmentów gdy osiągniesz limit tokenów
• Kontekst hierarchiczny: Różne poziomy szczegółowości dla różnych części historii

Praktyczny przykład: Zamiast przechowywać całą historię 20 kroków workflow, zachowujesz podsumowanie: "Agent wykonał kroki 1-18: analiza danych, generowanie raportu, weryfikacja wyników. Teraz wykonuje krok 19: finalizacja dokumentu".

Factor 4: Tools are just structured outputs (Narzędzia to tylko ustrukturyzowane wyniki)

Co to znaczy: Traktowanie narzędzi jako sposobu na otrzymywanie strukturalnych danych z modeli językowych, nie jako magicznych czarnych skrzynek.

Zmiana perspektywy:

• Zamiast: "Agent wywołuje narzędzie X"
• Myśl: "Agent produkuje JSON który wygląda jak wywołanie narzędzia X"

Korzyści: Łatwiejsze testowanie, debugowanie i mockowanie narzędzi.

Factor 5: Unify execution state and business state (Unifikacja stanu wykonania i stanu biznesowego)

Co to znaczy: Integracja stanu agenta z logiką biznesową aplikacji.

Praktyczne podejście:

• Stan agenta nie żyje w odizolowanym bubble
• Jest częścią modelu domenowego aplikacji
• Pozwala na łatwe przechodzenie między trybem "human" i "agent"
• Umożliwia audyt i compliance

Factor 6: Launch/Pause/Resume with simple APIs (Uruchom/Wstrzymaj/Wznów poprzez proste API)

Co to znaczy: Umożliwienie elastycznego zarządzania cyklem życia agenta.

Przypadki użycia:

• Pauzowanie na zatwierdzenie użytkownika
• Wstrzymywanie przy osiągnięciu limitu kosztów
• Wznawianie po poprawie danych wejściowych
• Scheduled execution w określonych godzinach

Factor 7: Contact humans with tool calls (Kontakt z ludźmi poprzez wywołania narzędzi)

Co to znaczy: Strukturyzowane wywołania narzędzi do uzyskiwania wkładu człowieka w kluczowych sytuacjach.

Przykład: Agent nie wie jak interpretować niejednoznaczne dane i "wywołuje" narzędzie:

{ "tool": "ask_human", "question": "Znalazłem dwie faktury z tą samą datą ale różnymi kwotami. Która jest prawidłowa?", "context": {...}, "options": ["Faktura A: 1500€", "Faktura B: 1800€", "Obie są błędne"] }

Factor 8: Own your control flow (Własność przepływu sterowania)

Co to znaczy: Kontrola nad logiką przepływu agenta, umożliwiająca pauzowanie, cache'owanie wyników czy wdrożenie ograniczeń.

Elementy kontroli:

• Warunki stopu (maksymalny czas, koszt, liczba iteracji)
• Punkty kontrolne wymagające zatwierdzenia
• Mechanizmy rollback w przypadku błędu
• Cache'owanie kosztownych operacji

Factor 9: Compact Errors into Context Window (Kompaktowanie błędów w oknie kontekstu)

Co to znaczy: Efektywne zarządzanie błędami poprzez ich kompresję w kontekście.

Techniki:

• Kategoryzacja błędów zamiast pełnych stack trace'ów
• Agregacja podobnych błędów
• Extraktowanie kluczowych informacji diagnostycznych
• Tworzenie "błędów-podsumowań" dla serii niepowodzeń

Factor 10: Small, Focused Agents (Małe, skoncentrowane agenty)

Co to znaczy: Budowanie wyspecjalizowanych agentów o ograniczonym zakresie odpowiedzialności.

Przykłady:

• Agent do analizy dokumentów PDF
• Agent do schedulowania spotkań
• Agent do monitoring systemów
• Agent do generowania raportów

Korzyści: Łatwiejsze utrzymanie, testowanie, debugging i skalowanie.

Factor 11: Trigger from anywhere, meet users where they are (Wyzwalanie z dowolnego miejsca)

Co to znaczy: Możliwość uruchamiania agentów z różnych punktów w aplikacji i różnych kanałów komunikacji.

Kanały integracji:

• Slack boty
• Email workflows
• Web interfaces
• API endpoints
• Mobile apps
• CLI tools

Factor 12: Make your agent a stateless reducer (Agent jako bezstanowy reduktor)

Co to znaczy: Traktowanie agentów jako czystych funkcji przekształcających kontekst wejściowy w działania wyjściowe.

Funkcyjne podejście:

Agent(currentState, userInput) → (newState, actions)

Korzyści:

• Przewidywalność - te same inputy dają te same outputy
• Testowalność - łatwe unit testy
• Debugowalność - jasny przepływ danych
• Skalowalność - możliwość równoległego przetwarzania

Implementacja podobna do Redux reducerów:

def agent_reducer(state, action): if action.type == 'USER_MESSAGE': return process_user_message(state, action.payload) elif action.type == 'TOOL_RESULT': return process_tool_result(state, action.payload) # ...

Porównanie z 12-Factor App

12-Factor App	12-Factor Agents	Wspólne DNA
Jeden codebase	Własność promptów	Kontrola nad kodem
Jawne dependencies	Własność kontekstu	Brak ukrytych zależności
Config w środowisku	Unifikacja stanów	Separacja konfiguracji od logiki
Backing services	Narzędzia jako struktury	Traktowanie zewnętrznych zasobów jako usług
Bezstanowe procesy	Agent jako reduktor	Funkcyjne, przewidywalne zachowanie

Co dalej z tym wszystkim?

12-Factor Agents to nie kolejny hype - to przeniesienie sprawdzonych zasad inżynierii oprogramowania do nowego domeniu.

Tak jak 12-Factor App stało się standardem dla aplikacji cloud-native, 12-Factor Agents może stać się fundamentem dla niezawodnych systemów AI w produkcji.

Kluczowa lekcja: Najszybszym sposobem na dostarczenie wysokiej jakości oprogramowania AI klientom jest włączenie małych, modułowych koncepcji do istniejącego produktu, zamiast zaczynania od zera z frameworkami.

Zanim pójdziesz do kogoś po pomoc przy budowie agentów AI:

• sprawdź czy 12-Factor Agents nie rozwiąże Twojego problemu
• przyjdź z propozycją architektury, nie z oczekiwaniem że ktoś to zrobi za Ciebie
• upewnij się czy zespół ma wiedzę o LLM i production-ready systemach
• pamiętaj że własność kodu jest lepsza niż vendor lock-in

Bo jak powiedział kiedyś pewien mądry człowiek - najlepsza architektura, specyfikacja i design wyłonią się z zespołu deweloperskiego, który wie co robi.

Links:

• 12-Factor Agents GitHub
• 12-Factor App Methodology
• HumanLayer

EA - OWASP ASVS: Configuration Verification Requirements

 W nowoczesnych środowiskach DevSecOps, kontrola nad zależnościami i komponentami firm trzecich to nie tylko kwestia porządku, ale bezpieczeństwa. Dlatego coraz więcej organizacji decyduje się na wprowadzenie wewnętrznych narzędzi typu artifact repository manager (np. JFrog Artifactory, Sonatype Nexus, GitHub Packages), które pełnią funkcję jednego źródła prawdy dla wszystkich zależności.

Dlaczego to ważne?

• Zależności są wektorami ataku. Większość nowoczesnych aplikacji składa się z setek bibliotek zewnętrznych. Jeśli choć jedna z nich ma lukę — system jest podatny.

• Brak centralizacji to chaos. Pobieranie zależności „na żywioł” (z różnych mirrorów, nieautoryzowanych źródeł) to ryzyko.

• Potrzebujemy zgodności z politykami bezpieczeństwa. ASVS jasno wskazuje, że zarządzanie komponentami i ich kontrola to obowiązek każdej świadomej organizacji.

Czym jest artifact repository manager?

To narzędzie, które:

• Przechowuje zależności w bezpieczny sposób,

• Ogranicza dostęp tylko do zatwierdzonych pakietów,

• Umożliwia skanowanie artefaktów pod kątem podatności (np. przez integrację z NVD – National Vulnerability Database),

• Może pełnić funkcję lokalnego cache dla publicznych rejestrów (npm, Maven Central, PyPI itp.),

• Umożliwia śledzenie wersji i aktualizacji w jednym miejscu.

Przykładowy scenariusz

1. Developer dodaje zależność do projektu – ale tylko z repozytorium wewnętrznego.

2. CI/CD pipeline pobiera zależności z artifact repository.

3. Zintegrowany skaner sprawdza artefakty pod kątem CVE z bazy NVD.

4. W przypadku zagrożenia – pipeline zostaje przerwany lub trafia alert do zespołu.

5. Repozytorium pozwala też na szybkie usunięcie lub zablokowanie konkretnej wersji biblioteki.

Powiązanie z OWASP ASVS v5

Funkcje artifact repository managera pokrywają m.in.:

ASVS Punkt	Opis
5.2.1	Weryfikacja znanych podatności w zależnościach
5.2.2	Używanie tylko zaufanych zależności z oficjalnych repozytoriów
14.1.1	Polityka zatwierdzania komponentów firm trzecich
14.2.2	Integracja skanowania bezpieczeństwa w CI/CD

Korzyści

• Standaryzacja pobierania zależności,

• Większa kontrola nad tym, co trafia do aplikacji,

• Automatyczne wykrywanie podatnych wersji bibliotek,

• Zgodność z wymaganiami ASVS, a także np. ISO/IEC 27001 i SOC2,

• Przyspieszenie audytów i przeglądów bezpieczeństwa.

Podsumowanie

Wdrożenie artifact repository managera jako centralnego źródła zależności to nie tylko ułatwienie życia developerom, ale realny krok w stronę bezpieczeństwa aplikacji.

W świetle OWASP ASVS, taka praktyka nie jest „nice-to-have” — to konieczność w dojrzałym procesie wytwarzania oprogramowania.

Jeśli jeszcze nie masz takiego rozwiązania – warto zacząć od audytu zależności i wybrania repozytorium zgodnego z potrzebami zespołu oraz wymaganiami standardów bezpieczeństwa.