6. Aplikacje GenAI i RAG: Budowanie Inteligentnych Systemów¶

🧠 Czym są Duże Modele Językowe (LLM)?¶

W najprostszym ujęciu, duży model językowy (LLM) to głęboka sieć neuronowa (ang. "Deep Neural Network") wytrenowana na ogromnych ilościach danych tekstowych (nazywanych "datasetem" czy "corpusem"). Jej podstawowym zadaniem jest przewidywanie następnego słowa (a dokładniej: tokenu) w sekwencji. Ta z pozoru prosta zdolność, przeskalowana do miliardów parametrów i terabajtów danych treningowych, prowadzi do wyłaniania się (ang. emergence) złożonych zachowań, takich jak odpowiadanie na pytania, tłumaczenie, streszczanie tekstów czy pisanie kodu.

Polecane zasoby do głębszego zrozumienia¶

Aby efektywnie pracować z LLM, warto zrozumieć, co dzieje się "pod maską". Poniższe materiały są absolutnie najlepszym punktem startowym.

• Teoria dla każdego (Intuicja wizualna): Jeśli chcesz zrozumieć, jak naprawdę działa deep learning i modele językowe AI, koniecznie zobacz serię 3Blue1Brown o sieciach neuronowych. To jedne z najlepszych istniejących materiałów, które w sposób wizualny i przystępny tłumaczą podstawowe idee stojące za nowoczesnymi modelami AI i machine learningiem. Idealne na start, by zbudować intuicję i "poczuć" jak myśli sieć neuronowa oraz (dalej) modele językowe.

• Wszystko w jednym wykładzie: Wykład Andrieja Karpathy'ego *"Intro to Large Language Models"* to jedno z lepszych wprowadzeń w temat, jakie istnieje. Karpathy, jako jeden z czołowych ekspertów w dziedzinie, w przystępny sposób wyjaśnia architekturę Transformerów, proces treningu i skalowania - wszystko w formie jednego, długiego i interaktywnego wykładu.

• Bieżące nowości: Świat GenAI zmienia się z tygodnia na tydzień. Kanał YouTube bycloud to doskonałe źródło podsumowań najnowszych prac badawczych i przełomowych modeli, prezentowanych w technicznym, ale zrozumiałym, atrakcyjnym wizualnie formacie.

🗺️ Krajobraz Modeli (stan na maj 2026)¶

Rynek modeli językowych zmienia się ekstremalnie szybko. Poniższe zestawienie jest aktualne na maj 2026, ale potraktuj je jako migawkę.

Modele zamknięte (frontier, dostępne przez API)¶

Modele open-weight (otwarte wagi, możliwy self-hosting)¶

Obok modeli zamkniętych dynamicznie rozwija się ekosystem modeli open-weight - takich, których wagi są publicznie dostępne i które możesz uruchomić na własnej infrastrukturze. To kluczowe dla zastosowań wymagających suwerenności danych, niskiej latencji lub kontroli kosztów.

• Meta Llama 4 - rodzina (warianty Scout i Maverick) w architekturze MoE z ekstremalnie długim oknem kontekstu.

• DeepSeek V4 (wersja zapoznawcza) - kolejna generacja wysoko ocenianych modeli o bardzo dobrym stosunku jakości do kosztu.

• Alibaba Qwen3 - silna, wielojęzyczna rodzina z dobrymi wariantami wyspecjalizowanymi (m.in. kodowanie).

• Google Gemma 3 - otwarta rodzina Google, dobrze dopasowana do uruchamiania lokalnego.

• Mistral - europejski dostawca z portfolio wydajnych modeli open-weight.

✅ Mocne i Słabe Strony LLM-ów¶

Jako inżynier musisz traktować LLM jak każde inne narzędzie – ze świadomością jego zalet i ograniczeń. Myślenie o LLM jako o "magicznej czarnej skrzynce" prowadzi do frustracji i zawodnych aplikacji.

📚 Czym jest RAG (Retrieval-Augmented Generation)?¶

RAG to obecnie najważniejszy wzorzec architektoniczny w budowie rzetelnych aplikacji opartych na LLM. W prostych słowach, RAG zmienia zadanie z "egzaminu z pamięci" na "egzamin z otwartą książką".

Zamiast polegać wyłącznie na wiedzy "zamrożonej" w parametrach modelu, proces RAG wygląda następująco:

1. Retrieval (Wyszukanie): Gdy użytkownik zadaje pytanie, system najpierw przeszukuje zewnętrzną bazę wiedzy (np. Twoją firmową dokumentację, bazę produktów) w poszukiwaniu najbardziej relevantnych fragmentów informacji.
2. Augmentation (Wzbogacenie): Znalezione fragmenty są dołączane do oryginalnego zapytania użytkownika jako kontekst, tworząc nowy, wzbogacony prompt.
3. Generation (Generowanie): Ten wzbogacony prompt jest wysyłany do LLM, który ma teraz wszystkie potrzebne informacje, aby wygenerować precyzyjną, opartą na faktach odpowiedź.

Dlaczego to jest kluczowe? RAG bezpośrednio rozwiązuje dwa największe problemy LLM w zastosowaniach biznesowych: halucynacje i nieaktualną wiedzę. Model jest "uziemiony" (ang. grounded) w konkretnych, zaufanych danych.

Naiwny RAG to dopiero początek¶

Opisany wyżej schemat (wyszukaj → dołącz → generuj) to tzw. naiwny RAG (naive RAG). Działa na demach, ale w produkcji szybko zawodzi: czyste wyszukiwanie wektorowe gubi dopasowania słów kluczowych, zwraca zbyt dużo nietrafionych fragmentów, a pytania wymagające łączenia wielu źródeł ("multi-hop") pozostają bez dobrej odpowiedzi. Dlatego nowoczesny RAG to pipeline z kilkoma etapami poprawiającymi jakość retrievalu.

flowchart TD
    Q[Zapytanie użytkownika] --> R{Adaptive RAG:<br/>router wg złożoności}
    R -->|proste| DIRECT[Odpowiedź<br/>bezpośrednia z LLM]
    R -->|wymaga wiedzy| HYBRID[Hybrid search]

    subgraph HYBRID[Hybrid Search]
        BM25[BM25<br/>słowa kluczowe]
        VEC[Wyszukiwanie<br/>wektorowe]
        BM25 --> RRF[Reciprocal<br/>Rank Fusion]
        VEC --> RRF
    end

    RRF --> TOP50[Top-50<br/>kandydatów]
    TOP50 --> RERANK[Re-ranking<br/>cross-encoder]
    RERANK --> TOP5[Top 3-5<br/>najtrafniejszych]
    TOP5 --> AUG[Wzbogacenie promptu]
    AUG --> LLM[Generacja LLM]
    LLM --> CHECK{Agentic RAG:<br/>czy odpowiedź<br/>wystarczająca?}
    CHECK -->|nie, doprecyzuj| HYBRID
    CHECK -->|tak| ANS[Odpowiedź]
    DIRECT --> ANS

Nowoczesne techniki RAG¶

• Hybrid search (wyszukiwanie hybrydowe) - łączy klasyczne wyszukiwanie leksykalne BM25 (dopasowanie słów kluczowych, świetne dla nazw własnych, kodów, akronimów) z wyszukiwaniem wektorowym (podobieństwo semantyczne). Wyniki obu metod scala się zwykle przez Reciprocal Rank Fusion (RRF) - algorytm łączący rankingi na podstawie pozycji, a nie surowych wyników. Hybryda jest niemal zawsze lepsza niż każda z metod osobno.

• Re-ranking - wyszukiwanie wektorowe jest szybkie, ale niezbyt precyzyjne. Schemat dwuetapowy: najpierw tani retrieval pobiera szeroką listę (np. top-50), następnie cross-encoder (model oceniający parę zapytanie–dokument razem, dokładniej niż porównanie embeddingów) przesortowuje ją i wybiera 3–5 najtrafniejszych fragmentów, które trafiają do LLM. Mniej, ale lepszego kontekstu = mniej halucynacji i niższy koszt.

• Agentic RAG - retrieval nie jest jednorazowy. Wokół niego buduje się pętlę rozumowania: agent analizuje pobrane fragmenty, ocenia, czy wystarczają, w razie potrzeby przeformułowuje zapytanie, dzieli pytanie na pod-pytania i ponawia wyszukiwanie. To RAG, który "myśli", zamiast wykonywać sztywny pipeline.

• GraphRAG - zamiast (lub obok) bazy wektorowej wykorzystuje graf wiedzy. Sprawdza się przy pytaniach multi-hop, wymagających połączenia faktów z wielu dokumentów ("Którzy klienci firmy X są też dostawcami firmy Y?"). Warto znać Microsoft GraphRAG oraz jego lżejszy wariant LazyGraphRAG, który drastycznie obniża koszt indeksowania, budując strukturę grafu dopiero w momencie zapytania.

• Adaptive RAG - nie każde pytanie wymaga pełnego pipeline'u. Lekki klasyfikator routuje zapytanie wg złożoności: proste pytania trafiają wprost do LLM, średnie - do zwykłego retrievalu, złożone - do agentic RAG lub GraphRAG. Optymalizuje to koszt i latencję.

Modele embeddingów - fundament retrievalu¶

Jakość RAG zaczyna się od jakości embeddingów - to model embeddingów decyduje, czy semantycznie podobne teksty wylądują blisko siebie w przestrzeni wektorowej. Wybór modelu embeddingowego ma często większy wpływ na jakość niż wybór LLM-a generującego odpowiedź.

📝 Prompt Engineering: Sztuka Rozmowy z LLM¶

Prompt engineering to praktyka projektowania i optymalizowania zapytań (promptów) do modeli językowych, aby uzyskać jak najlepsze, najbardziej spójne i użyteczne odpowiedzi. To kluczowa umiejętność każdego inżyniera GenAI – od jakości promptu zależy nie tylko trafność odpowiedzi, ale też bezpieczeństwo, powtarzalność i niezawodność całej aplikacji.

Najważniejsze techniki promptowania¶

Poniżej znajdziesz najważniejsze techniki, które warto znać i stosować w praktyce (szczegółowe przykłady i omówienia znajdziesz na Prompting Guide):

• Zero-shot prompting – po prostu zadajesz pytanie lub wydajesz polecenie bez dodatkowych przykładów.

• Few-shot prompting – podajesz kilka przykładów poprawnych odpowiedzi, aby model "nauczył się" wzorca.

• Chain-of-Thought (CoT) – prosisz model, by rozwiązywał zadanie krok po kroku. Technika historycznie przełomowa (2022–2024): ujawnienie "toku rozumowania" wyraźnie poprawiało trafność na zadaniach wymagających logiki. Uwaga na nieaktualną poradę produkcyjną: w 2026, w erze modeli rozumujących (reasoning models)⁶, wymuszanie długiego, jawnego "toku myślenia" w każdej odpowiedzi nie jest już dobrą praktyką - zwiększa koszt i latencję, a samą odpowiedź zaszumia. Lepiej: (a) użyć modelu rozumującego, który prowadzi rozumowanie wewnętrznie, albo (b) poprosić o zwięzłe uzasadnienie, plan lub wynik z kontrolą kroków zamiast rozwlekłego monologu. CoT pozostaje ważnym pojęciem edukacyjnym i bywa przydatny przy słabszych/mniejszych modelach - ale w produkcji stosuj go świadomie, nie odruchowo.

• Role prompting – nadajesz modelowi rolę (np. "Jesteś ekspertem od prawa podatkowego...").

• Instruction-based prompting – bardzo precyzyjne, jasne instrukcje, często z określeniem formatu odpowiedzi.

• Reflexion/self-correction – prosisz model, by sam ocenił i poprawił swoją odpowiedź.

• Structured output prompting – wymuszasz konkretny format odpowiedzi (np. JSON, tabela, lista punktów).

Więcej technik i praktycznych przykładów znajdziesz na stronie: https://www.promptingguide.ai/techniques

Dobre praktyki i typowe błędy¶

• Formułuj polecenia jasno, jednoznacznie i bez niedopowiedzeń.

• Unikaj zbyt ogólnych pytań – im bardziej szczegółowy prompt, tym lepsza odpowiedź.

• Testuj różne warianty promptów i porównuj wyniki.

• W przypadku złożonych zadań – dziel je na mniejsze kroki (dekompozycja problemu).

• Wymuszaj format odpowiedzi, jeśli to możliwe (np. "Zwróć wynik jako JSON z polami: ...").

• Używaj przykładów (few-shot), gdy zależy Ci na powtarzalności i spójności.

Typowe błędy: - Zbyt ogólne lub nieprecyzyjne polecenia.

• Brak określenia formatu odpowiedzi.

• Zbyt długie prompty (model może "zgubić" kontekst).

• Brak testowania różnych wariantów.

Narzędzia wspierające inżynierię promptów¶

• Instructor – biblioteka do wymuszania struktury odpowiedzi LLM, bardzo podobna do BAML, ale oparta o Pydantic. Pozwala łatwo wymusić, by model zwracał dane w określonym schemacie (np. klasie Pydantic), co znacznie zwiększa niezawodność i bezpieczeństwo aplikacji.

• BAML (Basically a Made-up Language): BAML to specjalistyczny język dziedzinowy (DSL, ang. "Domain Specific Language") zaprojektowany do generowania ustrukturyzowanych odpowiedzi z LLM – z naciskiem na najlepsze doświadczenie deweloperskie. Pozwala budować niezawodnych agentów, chatboty z RAG, ekstrakcję danych z PDF i wiele więcej. BAML w znacznej części eliminuje typowe problemy pracy z promptami (brak type safety, konieczność ręcznego testowania, trudności z walidacją) i pozwala skupić się na logice biznesowej, a nie na walce z formatem odpowiedzi modelu.

• Pydantic – kluczowy komponent do walidacji i wymuszania schematów odpowiedzi w Pythonie.

Więcej o Instructor i praktycznych przykładach znajdziesz tu: https://python.useinstructor.com/prompting/

🗄️ Bazy Wektorowe: Sercem nowoczesnych aplikacji GenAI i RAG¶

Bazy wektorowe to wyspecjalizowane systemy bazodanowe do przechowywania i szybkiego wyszukiwania tzw. wektorów osadzeń (embeddings), czyli liczbowych reprezentacji tekstu, obrazów czy innych danych. Są one niezbędne w architekturze RAG, gdzie umożliwiają błyskawiczne znajdowanie najbardziej podobnych fragmentów wiedzy do zapytania użytkownika.

Najważniejsze bazy wektorowe wykorzystywane w 2026 roku:

• pgvector – rozszerzenie do PostgreSQL. ⭐ Rozsądny domyślny wybór dla większości projektów (workloady poniżej ~10 mln wektorów): trzymasz wektory obok danych relacyjnych, bez wprowadzania osobnego systemu do utrzymania (patrz szerszy opis niżej).

• Qdrant – szybka, open-source’owa baza napisana w Rust. ⭐ Lider open-source pod względem stosunku wydajności do kosztu - bardzo dobry wybór, gdy potrzebujesz dedykowanej bazy wektorowej i chcesz uniknąć vendor lock-inu.

• Weaviate – open-source’owa baza z bogatym API, szczególnie mocna w wyszukiwaniu hybrydowym (wektorowym + tekstowym BM25) oraz integracją z popularnymi narzędziami AI.

• Pinecone – w pełni zarządzana, skalowalna baza wektorowa, szeroko stosowana w produkcyjnych systemach GenAI; wybierana, gdy zależy Ci na braku obsługi infrastruktury.

• Milvus – bardzo wydajna, open-source’owa baza, skalująca się do miliardów wektorów, z szerokim wsparciem dla różnych przypadków użycia (RAG, wyszukiwanie obrazów, rekomendacje).

• Chroma – lekka, open-source’owa baza, często wykorzystywana w prototypowaniu i mniejszych projektach.

• Redis – popularna baza NoSQL z modułem do wyszukiwania wektorowego.

• FAISS – biblioteka Facebooka do wyszukiwania podobieństw w dużych zbiorach wektorów, często używana jako silnik pod spodem innych rozwiązań.

• Vespa – platforma do wyszukiwania i rekomendacji z natywnym wsparciem dla wektorów.

Dodatkowo, coraz większą rolę odgrywają: - Elasticsearch – najpopularniejsza na świecie baza do wyszukiwania tekstowego, która od wersji 8.x natywnie wspiera wyszukiwanie wektorowe (HNSW, ANN, hybrydowe zapytania, integracja z Lucene, wsparcie dla GPU, kompresja, skalowalność, bezpieczeństwo, szeroka dokumentacja). Elasticsearch pozwala łączyć klasyczne wyszukiwanie pełnotekstowe z semantycznym, co jest kluczowe w nowoczesnych aplikacjach RAG. Więcej: blog Elastic

• LanceDB – nowoczesna, open-source’owa baza zoptymalizowana pod multimodalne AI (tekst, obrazy, audio). Wyróżnia się bardzo wydajnym, kolumnowym formatem danych (Lance), wsparciem dla indeksów IVF+PQ, HNSW, pełnotekstowego wyszukiwania, hybrydowych zapytań, wersjonowania i integracji z Pandas, DuckDB, PyArrow. LanceDB jest lekka, szybka, pozwala na pracę zarówno lokalnie, jak i w chmurze, a jej architektura umożliwia obsługę miliardowych zbiorów na tanim sprzęcie. Więcej: dokumentacja LanceDB

• pgvector – rozszerzenie do PostgreSQL, które pozwala przechowywać i wyszukiwać wektory bezpośrednio w relacyjnej bazie danych. Obsługuje indeksy HNSW, IVF, operatory podobieństwa (cosine, L2, dot), integruje się z klasycznymi zapytaniami SQL i pozwala łączyć wyszukiwanie semantyczne z relacyjnymi filtrami, joinami i transakcjami. Idealne do budowy hybrydowych aplikacji, gdzie dane wektorowe i klasyczne współistnieją. Więcej: dokumentacja pgvector

Pozostałe uwagi: Elasticsearch i pgvector są świetne do integracji z istniejącymi systemami, LanceDB do multimodalnych i dużych zbiorów, Pinecone/Weaviate/Milvus do skalowalnych, dedykowanych rozwiązań GenAI.

Źródła i więcej informacji: - Elasticsearch – blog o wydajności i architekturze wektorowej

• LanceDB – dokumentacja i porównania

• pgvector – porównanie z innymi rozwiązaniami

🕸️ Bazy Grafowe: Alternatywa i Uzupełnienie dla Baz Wektorowych¶

Bazy grafowe to wyspecjalizowane systemy bazodanowe, które przechowują dane jako węzły (obiekty) i krawędzie (relacje). Pozwalają one modelować i analizować złożone powiązania między danymi, co jest nieocenione w zastosowaniach takich jak: - budowa knowledge graphów (grafów wiedzy),

• eksploracja relacji (np. powiązania osób, firm, produktów),

• rekomendacje,

• wykrywanie oszustw,

• zaawansowane systemy RAG (GraphRAG, hybrydowe RAG).

Najważniejsze bazy grafowe wykorzystywane w 2026 roku: - Neo4j – najpopularniejsza baza grafowa na świecie, szeroko stosowana w knowledge graphach, rekomendacjach, fraud detection, z bogatym ekosystemem narzędzi (Cypher, Graph Data Science, integracje z LLM, GraphRAG, LlamaIndex, LangChain, Google GenAI Toolbox).

• Memgraph – wydajna, open-source’owa baza grafowa, kompatybilna z Cypher, wykorzystywana m.in. przez NASA do budowy knowledge graphów i GraphRAG. Mocno wspiera integracje z Pythonem i narzędziami AI.

• NebulaGraph – rozproszona, skalowalna baza grafowa, zoptymalizowana pod bardzo duże zbiory danych (triliony krawędzi), z własnym językiem zapytań nGQL i wsparciem dla chmury.

Zalety baz grafowych: - Naturalne modelowanie złożonych relacji i powiązań (np. multi-hop reasoning, śledzenie powiązań, eksploracja sieci).

• Wydajne zapytania oparte o relacje (np. "znajdź wszystkich znajomych znajomych", "wykryj cykle").

• Możliwość łączenia danych strukturalnych, relacyjnych i wektorowych (np. Neo4j Vector Index, GraphRAG, hybrydowe wyszukiwanie).

• Przejrzystość i wyjaśnialność odpowiedzi (łatwo pokazać ścieżkę uzasadniającą wynik).

• Integracja z narzędziami GenAI (LangChain, LlamaIndex, Google GenAI Toolbox, GraphRAG, agentic architectures).

Wady baz grafowych: - Mniej wydajne w czysto semantycznym wyszukiwaniu na bardzo dużych zbiorach tekstów (tu lepsze są bazy wektorowe).

• Krzywa uczenia się (nowe języki zapytań, np. Cypher, nGQL).

• Wysoki koszt wdrożenia przy bardzo dużej skali (np. Neo4j w wersji enterprise).

• Często wymagają przemyślanego modelowania danych (nie zawsze "wrzucisz wszystko jak leci").

Przykłady frameworków bazujących na bazach grafowych: - Microsoft GraphRAG - oraz LazyGraphRAG, wariant budujący strukturę grafu dopiero przy zapytaniu (znacznie tańsze indeksowanie)

• LightRAG

• Graphiti

• Nano GraphRAG

• R2R

Porównanie: Bazy Wektorowe vs. Bazy Grafowe

Kiedy wybrać bazę grafową? - Gdy kluczowe są relacje, powiązania, ścieżki, multi-hop reasoning.

• Gdy budujesz knowledge graph, system rekomendacji, analizę sieci społecznych, fraud detection.

• Gdy chcesz łączyć dane relacyjne, wektorowe i semantyczne (GraphRAG, hybrydowe RAG).

Kiedy wybrać bazę wektorową? - Gdy kluczowa jest szybkość i skalowalność wyszukiwania podobieństw semantycznych (np. RAG na dużych zbiorach dokumentów).

• Gdy nie potrzebujesz złożonych relacji między danymi.

Więcej o GraphRAG i agentic RAG: - Neo4j GraphRAG – dokumentacja i przykłady

• Memgraph GraphRAG – blog i przykłady NASA

• Porównanie GraphRAG vs. klasyczny RAG (Neo4j)

• NebulaGraph RAG – dokumentacja

🤖 Agenci i Wzorce Agentowe¶

Jeśli rok 2023 był rokiem chatbotów, a 2024–2025 - rokiem RAG, to 2026 jest powszechnie nazywany "rokiem agentów". Agent AI to coś więcej niż pojedyncze wywołanie LLM: to system, w którym model działa w pętli, samodzielnie decydując o kolejnych krokach aż do osiągnięcia celu.

Kluczowe wzorce agentowe (agentic patterns):

• Pętla rozumowania (reasoning loop) - agent nie generuje odpowiedzi za jednym razem. Wykonuje cykl: pomyśl → zdecyduj o akcji → wykonaj → zaobserwuj wynik → pomyśl ponownie - aż uzna zadanie za ukończone (znany schemat ReAct: Reasoning + Acting).

• Tool use (użycie narzędzi) - agent ma dostęp do zestawu narzędzi (funkcji): wyszukiwarki, interpretera kodu, zapytań do bazy, wywołań API. LLM sam wybiera, które narzędzie wywołać i z jakimi argumentami. To właśnie tool use przełamuje ograniczenia modelu (np. słabą matematykę - patrz tabela mocnych/słabych stron wyżej).

• Planowanie wieloetapowe (multi-step planning) - agent rozbija złożone zadanie na sekwencję pod-zadań, wykonuje je i scala wyniki.

• Multi-agent - zamiast jednego "wszechstronnego" agenta buduje się zespół wyspecjalizowanych agentów (np. planner, researcher, coder, reviewer), które współpracują i przekazują sobie zadania.

Sednem agenta jest pętla rozumowania - model nie odpowiada za jednym razem, lecz krąży między myśleniem a działaniem aż do osiągnięcia celu:

flowchart LR
    A["Zadanie użytkownika"] --> B["Model rozumuje"]
    B --> C{"Potrzebne narzędzie?"}
    C -->|tak| D["Wywołanie narzędzia"]
    D --> E["Obserwacja wyniku"]
    E --> B
    C -->|nie| F["Odpowiedź końcowa"]

🔌 MCP - Model Context Protocol¶

Wraz z rozwojem agentów pojawił się problem integracyjny: jak połączyć dowolny model z dowolnym narzędziem czy źródłem danych, bez pisania osobnego connectora dla każdej pary? Odpowiedzią jest MCP (Model Context Protocol).

MCP to otwarty standard (protokół) łączący LLM-y i agentów z zewnętrznymi narzędziami, danymi i usługami. Często opisuje się go jako "USB-C dla AI" - uniwersalne złącze: raz napisany serwer MCP (np. dla Twojej bazy danych, systemu plików, API firmowego) może być użyty przez dowolnego klienta MCP, niezależnie od dostawcy modelu.

Najważniejsze fakty:

• Wprowadzony przez Anthropic w listopadzie 2024 r.⁵, szybko stał się standardem branżowym - przyjęty m.in. przez OpenAI, Google i Microsoft.

• Dostępne oficjalne SDK dla wielu języków (Python, TypeScript, Java, C#, Go i inne).

• Istnieją już setki publicznych serwerów MCP - gotowych integracji do baz danych, narzędzi deweloperskich, usług chmurowych itd.

• W grudniu 2025 r. projekt został przekazany pod opiekę Linux Foundation⁴, co cementuje jego status jako neutralnego, otwartego standardu.

Idea MCP to jeden klient i wiele wymiennych serwerów - każdy serwer udostępnia narzędzia lub dane, niezależnie od dostawcy modelu:

flowchart LR
    H["Host AI - agent, IDE, chatbot"] --> CL["Klient MCP"]
    CL <-->|protokół MCP| S1["Serwer MCP - system plików"]
    CL <-->|protokół MCP| S2["Serwer MCP - baza danych"]
    CL <-->|protokół MCP| S3["Serwer MCP - API firmowe"]

🛠️ Frameworki i Narzędzia dla GenAI¶

SDK dostawców modeli¶

Najniższy, podstawowy poziom integracji - bezpośrednie biblioteki klienckie do API poszczególnych dostawców.

• OpenAI SDK - oficjalna biblioteka do API OpenAI. Warto znać kierunek rozwoju: oprócz klasycznego Chat Completions API, OpenAI promuje Responses API jako przyszłościowy interfejs do budowy agentów (zastępuje wcześniejsze, wycofywane Assistants API). Dla bardziej złożonych systemów dostępny jest też dedykowany OpenAI Agents SDK.

• Anthropic SDK - oficjalna biblioteka do API modeli Claude. Do budowy agentów Anthropic udostępnia Claude Agent SDK (przemianowany z wcześniejszego "Claude Code SDK") - framework do tworzenia agentów korzystających z narzędzi i MCP.

• google-genai SDK - oficjalna, aktualna biblioteka Google do modeli Gemini (zastąpiła starszy pakiet google-generativeai).

Frameworki orkiestracji i agent SDK¶

Gdy prosta aplikacja typu "prompt → odpowiedź" przestaje wystarczać, potrzebujesz warstwy do orkiestracji wielu wywołań LLM, narzędzi i źródeł danych.

• LangChain / LangGraph - LangChain to kompleksowy, dojrzały framework do budowy łańcuchów (chains) wywołań LLM. LangGraph ewoluował i pozycjonuje się dziś jako agent SDK - pozwala budować agentów jako cykliczne grafy stanów, z kontrolą nad pętlą rozumowania.

• PydanticAI - dojrzały framework agentowy od zespołu Pydantic. Jego siłą jest spójność z ekosystemem Pythona, który już znasz: typowane wejścia/wyjścia, walidacja przez Pydantic, dependency injection, czytelny i testowalny kod. Dobry domyślny wybór, gdy zależy Ci na produkcyjnej jakości i type safety.

• Google ADK (Agent Development Kit) - framework Google do budowy agentów, dobrze zintegrowany z modelami Gemini i ekosystemem Google Cloud.

• LlamaIndex / Haystack - frameworki wyspecjalizowane w RAG. LlamaIndex skupia się na wczytywaniu, indeksowaniu i odpytywaniu danych (m.in. wysokiej jakości parser dokumentów LlamaParse); Haystack oferuje kompletne narzędzia do produkcyjnych pipeline'ów RAG.

• Inne, w tym wieloagentowe - CrewAI, Microsoft AutoGen.

Narzędzia pomocnicze¶

• Pydantic - w kontekście GenAI kluczowe narzędzie do definiowania schematu odpowiedzi oczekiwanej od LLM. Zamiast prosić o "JSON z imieniem i wiekiem", definiujesz klasę Pydantic i wymuszasz na modelu zwrócenie danych dokładnie w tej strukturze - z automatyczną walidacją typów i wartości. To radykalnie zwiększa niezawodność: niepoprawna odpowiedź jest wychwytywana od razu, a nie kaskadowo psuje dalszą logikę aplikacji.

• Instructor - biblioteka nakładana na SDK dostawców, która opakowuje wywołania LLM tak, by zwracały gotowe, zwalidowane obiekty Pydantic (z automatycznym ponawianiem przy błędzie walidacji). Upraszcza structured outputs do kilku linii kodu.

• BAML - opisany wyżej w sekcji o prompt engineeringu DSL do generowania ustrukturyzowanych odpowiedzi z LLM.

• LiteLLM - uniwersalna warstwa proxy/SDK dająca jednolity interfejs do ponad stu modeli różnych dostawców. Praktyczna realizacja zasady "nie wiąż się z jednym dostawcą" - zmiana modelu sprowadza się do zmiany jednego stringa.

• Frameworki ewaluacji - np. Ragas (ewaluacja pipeline'ów RAG) czy DeepEval - pozwalają mierzyć jakość odpowiedzi systemu w sposób powtarzalny, co jest niezbędne wobec niedeterministyczności LLM.

🛡️ Od prototypu do produkcji - bezpieczeństwo i niezawodność aplikacji LLM¶

Działające demo a działająca produkcja to dwa różne światy. Aplikacja LLM otwiera klasę problemów, których nie ma w zwykłym CRUD-zie: niezaufane dane sterują modelem, model steruje narzędziami, a każde wywołanie kosztuje i może zawieść. Poniżej świadomościowy przegląd zagadnień, które musisz mieć na radarze, zanim wpuścisz aplikację do produkcji.