Graphify, OKF i RAG: Która warstwa kontekstowa jest potrzebna w twojej bazie kodu?
Testy porównawcze pokazują, że Graphify dorównuje pod względem dokładności rozwiązaniu vector RAG. Oto jak Graphify, OKF firmy Google oraz vector RAG współgrają ze sobą, wraz z mechanizmami wykrywania błędów i macierzą decyzyjną.
Własny plik benchmarkowy Graphify zawiera wynik, który w zgiełku wokół tego projektu często jest pomijany. Pod względem dokładności w zadawaniu pytań i odpowiadaniu na nie jest na poziomie z technologią dense vector RAG, natomiast pod względem powtarzalności wyników jest nieco gorszy. Mimo to w blogach programistów nazywany jest „zabójcą RAG”, a zespoły korporacyjne w tym samym miesiącu instalują go razem z formatem Open Knowledge Format (OKF) firmy Google w swoich agentach do programowania opartych na sztucznej inteligencji. Dlaczego?
Ponieważ to błędne postrzeganie. Graphify i OKF nie konkurują ze sobą o zastąpienie RAG. Oba stanowią specjalistyczne warstwy – jedna strukturalną, a druga narracyjną – które działają obok indeksu wektorowego, przy czym każda z nich ma sens tylko w kontekście określonego problemu w systemie. Jeśli będziemy je traktować jako zamienniki RAG, stracimy czas inżynierski na utrzymywanie grafów wiedzy oraz skompilowanych plików Markdown dla problemów, których w ogóle nie mamy.
Następna część omawia, jakie funkcje pełni każda warstwa, dlaczego prawdziwą przewagą Graphify jest koszt przetwarzania danych, a nie lepsza możliwość wyszukiwania, oraz macierz decyzyjną dla bazy kodu z 2026 roku.
Co faktycznie mówi plik benchmarkowy
Otwórz plik BENCHMARKS.md w repozytorium Graphify – tam znajdują się liczby, których nie podano w opisach testów.
Najpierw rozważmy test LongMemEval-S z 50 próbkami. Tryb rozszerzania grafu w Graphify osiąga dokładność 76% oraz współczynnik odnalezienia 0,844@10. Bazowy model RAG oparty na wektorach o podobnych parametrach (Kimi K2.6), tym samym narzędziu do embedowania BGE-m3 oraz równych budżetach tokenów również osiąga 76% dokładności, ale współczynnik odnalezienia wynosi 0,848@10. Zatem grafy wiedzy nie przewyższają tu konkurencji: dokładność jest identyczna, a współczynnik odnalezienia nieco niższy. Co gorsza, sam dostawca poinformował o zestawie danych i zweryfikował go w sposób ślepy (zgodność ocen 90,6%, współczynnik Kappa Cohena 0,81), więc żaden zewnętrzny ekspert nie wybrał przypadkowo złego wyniku.
W przypadku LOCOMO (n=300) obraz jest podobny, chociaż kluczowym parametrem staje się koszt przetwarzania danych.
Graphify osiąga dokładność 45,3%, a koszt przetworzenia zestawu danych wynosi około 1,40 dolara. Supermemory ma wyższą dokładność – 49,7% – ale koszt przetworzenia wynosi 15,67 dolara, czyli mniej więcej 11 razy więcej. Zatem Graphify również nie wygrywa w kwestii dokładności; przewyższa inne rozwiązania pod względem kosztów i efektywności.
W obu publicznych testach ten wzorzec się utrzymuje. Graphify nie przewyższa wydajności dobrze dostrojonego pipeline’u typu vector RAG. Dorównuje mu pod względem dokładności, przy czym jego budowa kosztuje znacznie mniej niż innych systemów pamięciowych. Dwie cechy tłumaczą jego przewagę:
- Tani koszt przetwarzania, ponieważ analiza AST w ogóle nie wymaga żadnych wywołań API LLM.
- Ekstrakcja strukturalna bez ryzyka halucynacji, ponieważ deterministyczne parsowanie za pomocą Tree-sitter wyodrębnia dokładne relacje w kodzie (wołania, importy, dziedziczenie klas) bez udziału modelu w tym procesie.
Dla tych, którzy uważają, że Graphify zastępuje bazy danych wektorowych, to zmienia kwestię. Decyzja nie dotyczy tego, który narzędzie wygra, lecz tego, który warstwa kontroluje który kontekst oraz który mechanizm awarii w stosie agentów pozostaje nierozwiązany.
Trzy warstwy zamiast trzech konkurentów
Dobre wybory architektoniczne wymagają oddzielenia technicznej rzeczywistości od języka marketingowego. Współczesne konfiguracje agentów opierają się na trzech odrębnych warstwach kontekstowych.
┌─────────────────────────────────────────────────────────────────┐
│ AI CODING AGENT CONTEXT │
└────────────────────────────────┬────────────────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
▼ ▼ ▼
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ VECTOR RAG │ │ GRAPHIFY │ │ GOOGLE OKF │
│ (Unstructured) │ │ (Structure) │ │ (Narrative) │
├───────────────────┤ ├───────────────────┤ ├───────────────────┤
│ • Docs & Tickets │ │ • AST Call Graphs │ │ • Architecture │
│ • Slack Threads │ │ • Class Hierarchies│ │ • Data Schemas │
│ • Long Tail Text │ │ • Imports/Exports │ │ • Playbooks & Run │
└───────────────────┘ └───────────────────┘ └───────────────────┘
Vector RAG
Vector RAG dzieli tekst niestrukturyzowany na bloki tokenów o stałej wielkości (np. 512 tokenów), umieszcza je w przestrzeni wektorowej, a przy wyszukiwaniu zwraca k najbliższych sąsiadów. Jest szybki, tani i dobrze nadaje się do dokumentacji niezależnej i jednolitej.
Jego podstawowa wada ma charakter strukturalny: uproszcza hierarchię. Analiza z Prism Labs z 2026 roku przedstawia to w ten sposób: gdy przyczyna i skutek nie znajdują się w tym samym bloku 512 tokenów, system nie wie, że są ze sobą powiązane. Lepsze modele embeddingów nie mogą tego naprawić, ponieważ jest to nieodłączna cecha dzielenia tekstu na bloki.
Graphify
Graphify to lokalny, deterministyczny silnik. Wykorzystuje analizę składniową typu tree-sitter AST dla ponad 36 języków programowania, w tym Python, TypeScript, Go, Rust, Java, C/C++, Swift, SQL oraz Terraform/HCL, wyodrębnia elementy kodu i tworzy graf strukturalny z typowanymi krawędziami takimi jak calls, imports, inherits i mixes_in.
Każda krawędź ma swoją etykietę. EXTRACTED oznacza, że została odczytana bezpośrednio z AST z pełną pewnością, natomiast INFERRED oznacza, że została wygenerowana za pomocą heurystyki z mniejszą pewnością. Ponadto Graphify stosuje detekcję społeczności Leiden, aby oddzielić naturalne podsystemy, oraz zaznacza „węzły-boga” – pliki o bardzo wysokim stopniu centralności, które łączą się z wieloma modułami.
Uruchomienie polecenia /graphify . generuje trzy lokalne pliki:
graph.htmlto interaktywna wizualizacja grafu.GRAPH_REPORT.mdto pisemny przegląd podsystemów bazy kodu.graph.jsonto indeks czytelny przez maszyny i poddający się zapytaniom.
Format Open Knowledge
Google Cloud ogłosił OKF w czerwcu 2026 roku. Nie jest to algorytm wyszukiwania ani silnik bazy danych. Jest to neutralna pod względem producenta specyfikacja metadanych w formacie Markdown. Pakiiet to katalog zwykłych plików Markdown w formacie UTF-8 z minimalnym frontmatterem w formacie YAML, gdzie tylko jedno pole, type, jest obowiązkowe. Nagłówek wygląda w ten sposób:
---
type: Architecture Concept
title: Payment Gateway Routing
description: Canonical sequence for multi-tenant payment provider dispatch.
tags: [billing, architecture]
---
Nie ma rejestratora schematów ani ciężkiego środowiska uruchomieniowego. Pakiety powinny znajdować się w Git i być czytane za pomocą zwykłych narzędzi wiersza poleceń, takich jak cat. OKF przechowuje starannie opracowaną pamięć instytucjonalną, stworzoną przez ludzi lub opracowaną przez algorytmy: spójną narrację o tym, dlaczego systemy są budowane w taki sposób, a nie surowe symbole kodu czy nieuporządkowane zapisy rozmów.
Jak warstwy dzielą pracę
W połączeniu dzielą one zadania: Graphify wydobywa to, czym jest kod, OKF rejestruje to, co wiedzą inżynierowie, a vector RAG zajmuje się pozostałą, nieustrukturyzowaną treścią.
Od tweeta do repozytorium z 63 tys. gwiazdek w 90 dni
Pośpiech w przyjmowaniu tych narzędzi nabiera sensu, patrząc na harmonogram, ponieważ cały ekosystem pojawił się w ciągu zaledwie 90 dni.
2026-04-01: Karpathy posts "LLM Wiki / Knowledge Compiler" concept on X
│
2026-04-03: Safi Shamsi launches Graphify on GitHub (YC S26)
│
2026-06-01: Graphify reaches 58.3K GitHub stars & 1.2M PyPI downloads
│
2026-06-12: Google Cloud releases Open Knowledge Format (OKF) spec
│
2026-07-01: Graphify ↔ OKF hybrid integration toolkit ships (71.5x token claim)
│
2026-07-05: Graphify hits ~78K stars; Level Up Coding scrutinizes "70x token" claims
Ta sama sekwencja w prozie:
- 1 kwietnia 2026 roku: Andrej Karpathy publikuje na X eksperyment myślowy: umieścić artykuły badawcze, notatki z kodem, zrzuty ekranu oraz dokumentację architektury w jednej folderze, a następnie przeszukiwać je za pomocą AI, które rozumie ich wzajemne powiązania, przy czym modele językowe pełnią rolę „kompilatorów wiedzy”.
- 3 kwietnia 2026 roku: Safi Shamsi publikuje Graphify na GitHubie, przekształcając tę ideę w projekt w ciągu 48 godzin. Projekt ten dołącza do grupy S26 firmy Y Combinator.
- 1 czerwca 2026 roku: projekt osiąga 58 300 gwiazdek na GitHubie oraz 1,2 miliona pobierania z PyPI.
- 12 czerwca 2026 roku: Google Cloud prezentuje OKF wraz z otwartą specyfikacją, przykładowymi zestawami (GA4 e-commerce, Stack Overflow i Bitcoin) oraz agentem do wydobywania metadanych z BigQuery.
- 15 czerwca 2026 roku: Katalog wiedzy z Google Cloud teraz w sposób natywny przetwarza pliki OKF i przekazuje je agentom AI przeznaczonym do zastosowań korporacyjnych.
- 1 lipca 2026 roku: dostępny staje się zestaw narzędzi łączących Graphify z OKF w obu kierunkach. Grafy kodu z Graphify są eksportowane jako katalogi w formacie markdown OKF poprzez stopniowe ujawnianie informacji, co ma zapewnić oszczędności w postaci tokenów zapytań nawet o 71,5 raza w porównaniu z czytaniem surowych plików.
- 5 lipca 2026 roku: Graphify zbliża się do liczby 78 000 gwiazdek, a publikacje techniczne, w tym Level Up Coding, zaczynają kwestionować deklarowane osiągi efektywności.
Andrus, pisząc w okresie tego dokładnego badania, zauważył, że osiągnięcie oszczędności na poziomie około 70 razy zależy od jednej właściwości projektu, o której prawie żadne późniejsze publikacje otwarcie nie wspominają. Tą właściwością jest topologia korpusu. Test użyty do obliczenia wartości 70 razy opierał się na konkretnym zestawie 52 plików (publiczne repozytoria Karpathy’ego, 5 artykułów badawczych, 4 diagramy), natomiast w bazach kodu przedsiębiorstw o prostych strukturach pakietów lub ogromnych monorepozytoriach oszczędności wynikające z użycia tokenów znacznie się różnią.
Które problemy uzasadniają dodanie któregoś z narzędzi?
Hype nie jest wymogiem architektonicznym, podobnie jak niejasne niezadowolenie z obecnej konfiguracji RAG. Nowa infrastruktura wymaga konkretnego, zaobserwowanego sposobu występowania problemów.
Najpierw sprawdzenie rzeczywistości
Badania przeprowadzone w całej branży wskazują, że udział implementacji RAG w przedsiębiorstwach, które nie spełniły oczekiwań lub całkowicie zawiodły w ciągu roku, wynosi 72%. Większość tych niepowodzeń wynika z niewłaściwego dzielenia danych na fragmenty, przestarzałych indeksów wektorowych lub nieodpowiednich modeli embedding, a nie z braku bazy danych grafowych. Wiedza przechowywana w grafie, podłączona do uszkodzonego procesu wyszukiwania, powoduje dalsze problemy w tym samym procesie oraz konieczność obsługi dodatkowych elementów.
┌─────────────────────────────────────────┐
│ Does your AI coding agent underperform? │
└────────────────────┬────────────────────┘
│
┌──────────────────┴──────────────────┐
▼ ▼
[ Sifting multi-file code ] [ Loss of tribal context ]
[ dependencies & calls ] [ across team silos ]
│ │
▼ ▼
Multi-Hop Reasoning Failure Knowledge Sprawl Failure
│ │
▼ ▼
TRIGGER: Add Graphify TRIGGER: Add Google OKF
(AST Structural Graph) (Curated Narrative Spec)
Pierwszy czynnik wyzwalający: błędy w rozumowaniu wieloetapowym (dodaj Graphify)
Występuje on, gdy odpowiedź wymaga połączenia faktów z różnych plików, które nigdy nie dzielą się tym samym fragmentem tekstu.
Typowy objaw: agent nie potrafi odpowiedzieć na pytania takie jak „co się psuje w warstwie API, jeśli zmieni się schemat w pliku db/migrations/04_users.sql?”
Ponieważ system RAG wektorowy embeduje każdy blok tekstowy niezależnie, nie wie nic o odniesieniach kluczy obcych, implementacjach interfejsów ani wywołaniach między plikami. Lepsze instrukcje lub większe okna kontekstowe nie pomogą, ponieważ te relacje nigdy nie trafiły do przestrzeni wektorowej.
Drugi czynnik wyzwalający: rozproszona wiedza instytucjonalna (dodaj OKF)
Występuje wtedy, gdy ważny kontekst instytucjonalny jest rozproszony między kanałami Slack, przestarzałymi stronami wiki oraz niezapisaną pamięcią programistów.
Czym jest ten objaw? Jest to agent, który tworzy składniowo poprawny kod, który jednak narusza wewnętrzne wytyczne architektoniczne, korzysta z przestarzałych wewnętrznych API lub ignoruje specyficzne dla danej dziedziny zasady biznesowe.
Graphify nie może pomóc, ponieważ parserzy AST czytają jedynie kod źródłowy i nie są w stanie wyodrębnić intencji biznesowej. OKF wypełnia tę lukę lekką strukturą markdown z wersjonowaniem Git, w której inżynierowie zapisują stabilne konwencje systemowe, które agenci mogą wiarygodnie analizować.
Badania nad narzędziami RAG w dziedzinie prawa wykazały, że standardowe narzędzia do wyszukiwania generują błędne wyniki w 17% do 33% złożonych zapytań, ponieważ samo wyszukiwanie nie modeluje logiki obejmującej kilka dokumentów. Wskazówki Atlan podsumowują rozsądny porządek działania: najpierw RAG, a struktura grafowa dopiero wtedy, gdy głównym ograniczeniem stanie się głębokość analizy.
Ile kosztuje każde narzędzie, gdy przestaje działać
Każda dodana warstwa niesie ze sobą własne możliwe błędy. Oba projekty są jeszcze młode, więc ich ryzyka operacyjne wymagają uwagi przed wprowadzeniem ich do użycia produkcyjnego.
Gdzie Graphify odbiega od oczekiwań
- Przestarzałe zrzuty stanu. Indeks grafu jest tworzony tylko raz i pozostaje statyczny. Nie jest aktualizowany, gdy programiści edytują pliki, więc bez hooka typu pre-commit w Git lub kroku CI/CD oddala się on od stanu kodu. Przestarzały graf strukturalny jest gorszy niż żaden, ponieważ agent może dostarczać błędne odpowiedzi w przekonaniu, że są one poprawne.
- Głośne społeczności w aplikacjach monolitycznych. W dużych aplikacjach napisanych w Javie lub C++, detekcja problemów często łączy ze sobą niepowiązane moduły tylko dlatego, że wszystkie one korzystają z wspólnej infrastruktury, takiej jak mechanizmy logowania lub singletony telemetryczne.
- Halucynacje w procesie wzbogacania semantycznego. Etap przetwarzania kodu jest deterministyczny, ale opcjonalny etap semantyczny przeprowadzany na dokumentacji, plikach PDF i obrazach nadal wykorzystuje model językowy. Dlatego relacje wydobyte z niekodowych plików mogą być błędne.
- Niepotwierdzone twierdzenia. Według architekta oprogramowania Saurabha Sharmy nikt poza zespołem projektu nie powtórzył porównania zapytań grafowych Graphify z plikami surowymi ani testów bazowych RAG na wspólnym zbiorze danych. Liczby podane przez dostawców należy traktować raczej jako przybliżone orientacje.
Gdzie OKF odbiega od standardów
- Brak kontroli i weryfikacji. Ten format celowo pomija rejestry schematów oraz ścisłe zasady, więc jakość paczki plików zależy wyłącznie od osoby lub systemu, który je tworzy.
- Cichy upadek. Podstawowy kontrakt nakazuje agentom tolerowanie nieznanych typów metadanych oraz uszkodzonych linków. To przyspiesza wdrożenie, ale pozwala również na to, by pliki trafiały do stanu niepowiązanych, przestarzałych plików bez żadnych błędów kompilacji.
- Obciążenie konserwacją. Dokumenty w formacie Markdown wymagają ciągłej dbałości. Jeśli procesy inżynieryjne nie wymagają aktualizacji OKF równocześnie z zmianami w kodzie, warstwa narracyjna szybko staje się przestarzała.
Kombinowany proces w praktyce
Dla złożonych baz kodu przedsiębiorstw najlepsza konfiguracja na rok 2026 nie polega na wyborze jednego narzędzia. Polega raczej na połączeniu ich w wieloetapowy proces przetwarzania danych.
┌──────────────────────────────────────────────────────────────────┐
│ USER / AGENT QUERY: "What breaks if I modify UserService.py?" │
└─────────────────────────────────┬────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 1: OKF Progressive Disclosure Catalog │
│ Read high-level module narrative & owner specs (~2K tokens) │
└─────────────────────────────────┬────────────────────────────────┘
│ (Targeted node identified)
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 2: Graphify Structural Graph Query │
│ Traverses AST edges: calls, imports, inherits (Zero-LLM cost) │
└─────────────────────────────────┬────────────────────────────────┘
│ (Unstructured edge cases)
▼
┌──────────────────────────────────────────────────────────────────┐
│ STAGE 3: Vector RAG / Sparse Search │
│ Search raw Slack incident logs, GitHub issues, & PR comments │
└──────────────────────────────────────────────────────────────────┘
Krok pierwszy: utworzenie artefaktów strukturalnych Graphify
Zainstaluj Graphify w izolowanym środowisku, a następnie uruchom narzędzie analityczne w odniesieniu do przestrzeni roboczej.
# Install Graphify via uv
uv tool install graphifyy
# Register the skill with your local agent environment (Claude Code, Cursor, Codex, Gemini CLI)
graphify install
# Execute AST graph compilation inside your repository root
/graphify .
# Generated Local Artifacts:
# graph.html --> Interactive visual network representation
# GRAPH_REPORT.md --> Natural language summary of communities & god nodes
# graph.json --> Queryable AST relational graph database
Gdy to zostanie zakończone, lokalny indeks strukturalny można bezpośrednio zapytać w celu sprawdzenia ścieżek relacji.
# Query dependency paths between components
graphify path "UserService" "DatabasePool"
# Trace architectural blast radius before refactoring
graphify query "What components depend on AuthTokenValidator?"
Krok drugi: zapisz starannie przygotowane koncepcje w formacie OKF
Eksportuj to, co zostało znalezione podczas analizy strukturalnej, do pliku zawierającego koncepcje zgodne z formatem OKF, umieszczonego w katalogu .well-known/okf/ lub docs/knowledge/. Minimalny plik koncepcji wykorzystuje zwykłe łącza Markdown, a te łącza bezpośrednio odpowiadają krawędziom grafu wiedzy.
---
type: Database Table Context
title: orders_fact
description: Canonical order transaction table joining billing and fulfillment streams.
resource: bigquery://production-data.commerce.orders_fact
tags: [finance, core-model]
timestamp: 2026-06-20T14:00:00Z
---
# Business Domain Summary
The `orders_fact` table serves as the primary source of truth for revenue calculations.
Modifications to columns must align with the [Customer Profile Spec](./customer_profile.md).
# Schema & Join Constraints
| Column Name | Data Type | Structural Constraint |
|---|---|---|
| `order_id` | STRING | Primary Key; joins with [billing_events](./billing_events.md) |
| `customer_id` | STRING | Foreign Key; see [customers](./customers.md) |
| `status` | STRING | Enum: `pending`, `completed`, `refunded` |
# Related Runbooks
- Incident Protocol: [/runbooks/billing-reconciliation.md](/runbooks/billing-reconciliation.md)
Kopp, specjalista od wyszukiwania i inżynierii kontekstu, podkreśla, że struktura powiązań OKF doskonale pasuje do GraphRAG, ponieważ link z orders_fact.md do customers.md jest już krawędzią w grafie wiedzy.
Dowody z ERPNext
Podchodzenie to zostało przetestowane w ERPNext – otwartym oprogramowaniu korporacyjnym składającym się z ponad miliona linijek kodu w Pythonie i JavaScriptie.
W ocenach użyto Claude Opus 4.8, z ograniczeniem do 14 rund na zadanie:
- Agent kodujący bazowy, wykorzystujący vector RAG i grep, osiągnął 70,8% pokrycia kluczowych faktów.
- Hybrydowy proces Graphify i OKF osiągnął 82,0% pokrycia kluczowych faktów, przy średnich około 140 000 tokenów na sesję zapytania.
Wzrost o 11,2 punktu w tak dużym kodzie oznacza znacznie mniej błędów podczas wykonywania zadań przez agenty. Mówi to więcej o wartości w środowisku produkcyjnym niż liczby dotyczące syntetycznego zmniejszenia liczby tokenów.
Wybór według typu kodu
Znajdź w macierzy swoje środowisko kodowe oraz jego główny sposób awarii, aby wybrać odpowiednią architekturę.
Wersja skrócona
Graphify radzi sobie najlepiej przy deterministycznym analizowaniu struktury bez kosztów związanych z API LLM. OKF oferuje przenośny standard przyjazny dla Git, przeznaczony do przechowywania kontekstu tworzonego zarówno przez ludzi, jak i agenty. Vector RAG pozostaje najskuteczniejszą opcją do wyszukiwania tekstu niestrukturyzowanego. Układanie warstw bez jasnego sposobu awarii zwiększa złożoność i nie poprawia wydajności agentów.
Najpierw zdefiniuj problem
Zanim Graphify lub OKF trafią do procesu rozwoju, należy określić, który z trzech problemów jest rzeczywisty: przestarzały kontekst kodu, błędy związane z wieloetapowymi zależnościami czy rozbite wiedze instytucjonalne.
Oba narzędzia stanowią przydatne uzupełnienie nowoczesnego stacku AI, a wyniki testów ERPNext pokazują ich rzeczywistą wartość w złożonych bazach kodu. Mimo to skok od pojedynczego tweeta do popularnego repozytorium jest powodem do ścisłej analizy. Przeczytaj bezpośrednio dane zawarte w pliku BENCHMARKS.md, przetestuj proponowane architektury na własnym kodzie i stwórz zestaw narzędzi odpowiadający Twoim potrzebom inżynieryjnym. Dobrym punktem wyjścia jest dopasowanie swojej konfiguracji do warunków monolitu, mikrosług lub monorepo przedstawionych w macierzy.
Literatura pokrewna
- Zaawansowane RAG w Milvus: wyszukiwanie hybrydowe, HyDE, przepisywanie zapytań i ponowna klasyfikacja — Budowanie pipeline RAG w Milvus krok po kroku: wektory gęste i BM25, hybrydowe wyszukiwanie RRF, filtry metadanych, przepisywanie zapytań, HyDE, dekompozycja oraz ponowna klasyfikacja za pomocą cross-encodera.
- Użyteczny lokalny LLM w 30 minut: kodowanie, pytania i odpowiedzi w dokumentach oraz obsługa głosu — Stworzenie lokalnego asystenta do kodowania, skryptu do wyszukiwania notatek oraz systemu obsługi głosu offline przy użyciu Ollamy, Qwen3 i Whisper.cpp, wraz z zasadami szerokości pasma pamięci przy doborze rozmiaru modelu.