Od zera do systemu AI w kwartał. Część 12: Przeszukiwanie wiedzy.

W części 5 zbudowaliśmy bazę wiedzy na Zettelkastenie. W części 11 ustawiliśmy proces przepływu, który dolewa do niej nową wiedzę codziennie.

Po trzech miesiącach masz trzysta notatek. Po pół roku siedemset. Po roku spokojnie ponad tysiąc, u mnie aktualnie około półtora tysiąca i wciąż rośnie.

I pojawia się nowy problem.

AI ma okno kontekstowe. Duże, ale skończone. Nie czyta wszystkich Twoich notatek przy każdym pytaniu. Czyta tylko te, które dostaje. Pytanie brzmi: jak wybrać te właściwe z całego zbioru?

Jeśli podasz mu za mało notatek, odpowiedź będzie wyjęta z kapelusza. Jeśli podasz za dużo, zagłuszysz sygnał szumem. Trzeba dać mu to, co naprawdę się liczy dla aktualnego pytania.

Są trzy warstwy wyszukiwania, które razem dają AI oczy na Twoją bazę wiedzy. Pokażę każdą z nich, na praktycznych przykładach.

Zastrzeżenie: to co opisuję w tym cyklu bazuje na moim stacku technologicznym, czyli macOS i Claude jako główny model językowy. Zasady i podejście działają na każdym systemie operacyjnym i z każdym modelem AI, ale konkretne kroki i skróty klawiszowe opisuję pod Maca. Jeśli pracujesz na Windows lub Linux, większość rzeczy zrobisz tak samo, ale powyższe systemy mogą się różnić detalami, które musisz dostosować.

Ważne: opisuję tu model uproszczony, czyli idealny obraz tego, jak działa ten fragment systemu. W praktyce mój obecny system ma więcej warstw, wyjątków i automatyzacji. Na potrzeby tego cyklu pokazuję wersję, którą najłatwiej zrozumieć i odtworzyć u siebie.

Problem: dlaczego zwykłe wyszukiwanie nie wystarcza

Obsidian ma wbudowaną wyszukiwarkę. Działa świetnie, gdy wiesz, czego szukasz. Wpisujesz frazę, dostajesz listę plików, w których to słowo występuje.

Problem w tym, że wiedza rzadko leży pod dokładną frazą, którą zadajesz.

Pytasz: “Jak prowadzić rozmowę z trudnym klientem?” Twoja notatka, która naprawdę odpowiada na to pytanie, może mieć tytuł “Obiekcja cenowa to pytanie o wartość”. Nie ma w niej frazy “trudny klient”, ale dokładnie ten problem opisuje. Tradycyjna wyszukiwarka jej nie znajdzie.

To jest moment, kiedy potrzebujesz czegoś więcej. Wyszukiwarki, która rozumie sens, a nie tylko dopasowuje słowa.

Warstwa 1: tagi kontekstowe (szybkie filtrowanie)

Zacznijmy od najprostszej warstwy, już częściowo zbudowanej w części 5. Tagi kontekstowe w formacie #gdy-[sytuacja].

Tagi nie pełnią tu roli wyszukiwania w sensie technicznym. Pełnią rolę filtra kontekstowego.

Gdy mówisz AI: “Mam jutro spotkanie z klientem. Przygotuj mi listę rzeczy do poruszenia”, AI w pierwszym kroku filtruje bazę wiedzy po tagu #gdy-rozmawiam-z-klientem. Z tysiąca notatek dostaje sto, może dwieście. To jest w miarę bezpieczny rozmiar dla pełnego czytania.

Tagi działają szybko, bo są binarne. Notatka ma tag albo go nie ma. Nie trzeba liczyć podobieństwa. Nie trzeba analizować znaczenia. Tytuł pliku i jedna linia w stopce wystarczą.

Ograniczenie jest jedno. Tagi wymagają dyscypliny. Jeśli zapomnisz oznaczyć notatkę, nie znajdziesz jej przez ten kanał.

AI może tu pomóc. Raz na miesiąc używam takiego polecenia:

Przejrzyj moje atomowe notatki w WIEDZA/NOTATKI/ z ostatnich 30 dni. Znajdź te, które nie mają żadnego tagu kontekstowego. Dla każdej zaproponuj jeden lub dwa tagi z listy, której używam (gdy-piszę-ofertę, gdy-rozmawiam-z-klientem, gdy-planuję-kampanię, gdy-podejmuję-decyzję, gdy-planuję-projekt, gdy-buduję-automatyzację, gdy-konfiguruję-ai, gdy-optymalizuję-workflow). Uzasadnij jednym zdaniem dla każdej propozycji.

Dziesięć minut i baza jest oczyszczona. AI uzupełnia tagi. Ja zatwierdzam.

Warstwa 2: semantic search (wyszukiwanie przez sens)

Druga warstwa jest poważniejsza. Semantic search rozumie znaczenie, nie tylko słowa.

Mechanizm pod spodem jest prosty w idei, choć techniczny w realizacji. Każda notatka zostaje zamieniona na listę liczb (wektor), które reprezentują jej znaczenie. Pytanie zadawane do systemu też zostaje zamienione na wektor. Szukamy notatek, których wektor jest podobny do wektora pytania.

W praktyce wygląda to tak. Pytasz: “Jak reagować na klientów, którzy targują się o cenę?” System szuka notatek, których sens jest bliski Twojemu pytaniu. Znajduje “Obiekcja cenowa to pytanie o wartość”, “Transparentność cen buduje zaufanie szybciej niż case study”, “Klient nie kupuje usługi, kupuje spokój”. Żadna z tych notatek nie zawiera słowa “targować się”. Ale wszystkie dotyczą tego problemu.

Dla uruchomienia semantic search masz kilka opcji. Lokalne, darmowe silniki oparte na Metal GPU na Macu. Płatne chmurowe usługi. Wbudowane funkcje w niektórych edytorach wiedzy.

U mnie działa lokalny silnik, który indeksuje cały vault. Dziś to około półtora tysiąca dokumentów i kilka tysięcy wektorów. Wszystko liczone lokalnie na Macu, bez wysyłania treści do chmury. Indeksacja robi się raz dziennie w tle. Wyszukiwanie jest natychmiastowe.

Lokalny silnik daje jeszcze jedną korzyść: trzy tryby pytania pod różne potrzeby. Tryb słowny (zachowanie się jak klasyczne BM25 z operatorami), tryb znaczeniowy (semantic) i tryb hipotezy (najpierw wyobrażasz sobie, jak ma wyglądać odpowiedź, dopiero potem szukasz notatek do niej podobnych). W praktyce hipoteza znajduje rzeczy, których same słowa kluczowe by nie wybrały.

Gdy AI dostaje pytanie, które wymaga wiedzy z bazy, uruchamia semantic search jako pierwszy krok. Wybiera piętnaście najlepiej dopasowanych notatek. Czyta je. Dopiero potem odpowiada.

Z mojej codziennej praktyki polecenie wygląda tak:

Chcę napisać post na LinkedIn o uczciwości w sprzedaży B2B. Przeszukaj moją bazę wiedzy semantycznie. Daj mi dziesięć notatek, które są najbliższe temu tematowi. Podaj dla każdej tytuł, krótki opis, i ocenę (1-10), jak bardzo ta konkretna notatka jest istotna dla tego posta. Nie pisz jeszcze samego posta. Najpierw pokaż mi, na czym będziesz się opierał.

Widzę, na czym AI się opiera. Jeśli wybór notatek mnie nie przekonuje, mówię: “Dodaj też notatki z tagiem #gdy-piszę-ofertę, pomiń te o cold mailingu”. Doprecyzowuję. Dopiero wtedy proszę o napisanie.

Warstwa 3: graf powiązań (kontekst przez linki)

Trzecia warstwa bazuje na tym, co zbudowałeś w części 5. Linki między notatkami. Każda atomowa notatka linkuje do innych notatek, z którymi jest powiązana.

Te linki tworzą graf. Nie widziany na pierwszy rzut oka, ale istniejący w strukturze wiedzy. Dziś mam tu już dwie warstwy pracy. Pierwsza to lokalny semantic search po plikach. Druga to warstwa grafowa, która patrzy na relacje między dokumentami i pomaga, gdy samo podobieństwo znaczeniowe nie wystarcza.

Gdy AI dostaje notatkę, nie czyta jej w izolacji. Pyta: “Jakie notatki ta notatka linkuje? Jakie notatki linkują do niej?” I dodaje te powiązane do kontekstu.

Prosty przykład. Notatka “Klient nie kupuje usługi, kupuje spokój” linkuje do “Pierwsze spotkanie to diagnoza, nie prezentacja”, która linkuje do “Kwalifikacja wyklucza złe dopasowania”. Trzy notatki, jeden łańcuch myślowy. AI, czytając pierwszą, może zahaczyć o dwie kolejne i dostać pełniejszy obraz.

Graf działa bez osobnego silnika. Po prostu linki w Markdown. W zaawansowanej wersji systemu używam bazy Neo4j, która pozwala pytać o wzorce w grafie (np. “które notatki są w centrum, czyli mają najwięcej połączeń”, albo “które notatki są wyspami bez linków”). Ale to jest dodatek dla ludzi, którzy mają setki powiązań i chcą widzieć wzorce. Na start wystarczą zwykłe linki w Obsidian.

Polecenie, z którego korzystam:

Znalazłeś w moim vault notatkę o tytule “[nazwa]”. Przejrzyj też wszystkie notatki, które ta notatka linkuje, i wszystkie notatki, które linkują do niej. Pokaż mi graf: notatka centralna, jej sąsiedzi, ich sąsiedzi. Na tej podstawie powiedz mi, jaki jest szerszy kontekst tej idei w mojej bazie wiedzy. Co jeszcze o tym myślałem w innym miejscu?

AI zwraca mi sieć. Widzę, jak moje myśli łączą się ze sobą. Często to pokazuje luki: notatka, która powinna linkować do trzech innych, linkuje do zera. Sygnał do pracy.

Warstwa 4 (opcjonalnie): zewnętrzna dokumentacja przez MCP

Trzy warstwy wyżej dotyczą Twojej wiedzy. Ale czasem AI potrzebuje wiedzy spoza Twojej bazy: aktualnej składni biblioteki, konkretnej opcji konfiguracji frameworka, niuansu API, którego nie miałeś nigdy w notatkach.

Tu pomaga oddzielne narzędzie: Context7 MCP (Model Context Protocol). To jest most między Twoją sesją AI a aktualną dokumentacją popularnych bibliotek (Astro, React, Tailwind, n8n, Shoper API i setek innych).

Mechanizm: piszesz w pytaniu use context7 i AI zamiast zgadywać z pamięci, najpierw sięga po aktualną dokumentację bibliotek, potem odpowiada. Daje to przewagę przy pisaniu kodu i konfigurowaniu integracji, bo każda popularna biblioteka ma w sobie historię zmian, których model nie zna.

To dodatek, nie zamiennik własnej bazy. Twoja wiedza to Twój kontekst biznesowy. Context7 to powszechny stos technologiczny. Razem AI ma i jedno, i drugie.

Trzy warstwy razem

Najmocniejszy efekt wychodzi z kombinacji.

Gdy zadaję AI trudne pytanie, kolejność jest taka:

Tag filtruje szerokość. Z tysiąca notatek zostaje dwieście oznaczonych jako przydatne w tej sytuacji
Semantic search wybiera jakość. Z dwustu zostaje piętnaście najbliższych tematowi
Graf dodaje kontekst. Te piętnaście notatek otwiera dostęp do kolejnych pięćdziesięciu przez linki

Na wejście do sesji AI dostaje kilkadziesiąt precyzyjnie wybranych fragmentów wiedzy. Nie tysiąc, w którym tonąłby. Nie pięć, z których odpowiedź byłaby powierzchowna. Wystarczająco, żeby odpowiedzieć z kontekstem.

To jest moment, w którym system AI przestaje być “asystentem, który pyta o kontekst”. Staje się partnerem, który ma kontekst w kieszeni i używa go, zanim Ty poprosisz.

Kiedy która warstwa wystarczy

Nie zawsze trzeba wszystkich trzech. W praktyce korzystam tak:

Tagi wystarczą, gdy: potrzebujesz szybkiego przeglądu (“pokaż mi wszystkie notatki przydatne w rozmowie z klientem”). Filtr, nie odpowiedź.

Semantic search wystarczy, gdy: wiesz o czym chcesz dostać informację, ale nie znasz dokładnej frazy. Najbardziej codzienne użycie.

Graf potrzebujesz, gdy: chcesz zobaczyć, jak temat łączy się z innymi. Przy tworzeniu contentu, planowaniu strategii, głębokiej refleksji.

Na starcie wystarczą tagi i wbudowana wyszukiwarka Obsidian. To jest kilkadziesiąt notatek. Tyle ogarniesz pamięcią.

Semantic search zaczyna mieć sens przy około stu notatkach. Wcześniej to przerost formy nad treścią.

Graf staje się naprawdę użyteczny przy około trzystu atomowych notatkach, gdzie sieć linków jest gęsta. Wcześniej linków jest za mało, żeby widzieć wzorce.

Dlaczego to działa lepiej niż RAG (Retrieval-Augmented Generation) na dokumentach firmowych

Powszechne jest popularne podejście do pracy z AI: wrzucasz do niego stertę dokumentów firmowych (PDFy, Worda, prezentacje) i pozwalasz mu przeszukiwać wektorowo. To się nazywa RAG.

Działa średnio. Dokumenty są długie, nieustrukturyzowane, pełne redundancji. Jedna strona dokumentu ma pięć różnych myśli, które semantic search próbuje potraktować razem.

System, który opisuję, działa inaczej. Każda notatka to jedna myśl. Zettelkasten celowo zakłada atomowość. Gdy semantic search zwraca notatkę, zwraca jedną konkretną ideę, a nie fragment dokumentu, z którego dopiero trzeba ekstraktować sens.

Ta różnica wygląda abstrakcyjnie, ale w praktyce jest ogromna. Dziesięć atomowych notatek daje lepszą bazę do odpowiedzi niż pięćdziesiąt stron dokumentu. Mniej danych, więcej użytecznego sygnału.

Czego unikać

Budowania infrastruktury przed wiedzą. Nie stawiaj Neo4j, semantic search i dashboardów, zanim masz sto notatek. Najpierw baza wiedzy, potem narzędzia jej przeszukiwania. Inaczej spędzisz tygodnie konfigurując wyszukiwarkę, która nie ma czego szukać.

Ufania semantic search ślepo. Nie każdy rezultat jest trafny. AI pokazuje Ci 10 notatek, ale jedna z nich może być w temacie przypadkowa, a prawdziwie ważna jest na pozycji dwunastej. Zawsze szybkim okiem przejrzyj, co AI wybrał, zanim poprosisz o rezultat.

Ignorowania tagów przy każdym pytaniu. Tagi są szybkie i tanie, semantic search jest wolniejszy. Jeśli filtr tagowy da Ci dobre wyniki, nie uruchamiaj semantic search. Nie wszystko musi działać przez najcięższy mechanizm.

Pomijania kroku weryfikacji. AI na podstawie dziesięciu notatek może napisać wszystko brzmiące spójnie, nawet jeśli żadna z notatek tego konkretnego wniosku nie zawiera. Jeśli odpowiedź Cię zaskakuje, sprawdź, z której notatki pochodzi. Prośba “cytuj źródło” powinna być standardem, nie opcją.

Czego nauczyłeś się na tym etapie?

Przeszukiwanie wiedzy to nie jedno narzędzie, to trzy warstwy, które działają razem.

Tagi kontekstowe (#gdy-[sytuacja]) filtrują szerokość. Szybki filtr binarny, który z tysiąca notatek zostawia dwieście. Wymaga dyscypliny w oznaczaniu, ale daje natychmiastowe efekty.

Semantic search rozumie znaczenie. Z dwustu zostawia piętnaście najbliższych tematowi. Znajduje notatki, które nie zawierają dokładnej frazy, ale dotyczą tego samego problemu. Działa od około stu notatek.

Graf powiązań dodaje kontekst przez linki. Pozwala zobaczyć, jak dana idea łączy się z innymi. Przydatny przy tworzeniu contentu i strategii, gdy masz około trzystu atomowych notatek.

Razem: tag filtruje szerokość, wektor wybiera jakość, graf dodaje kontekst. AI dostaje kilkadziesiąt precyzyjnie wybranych notatek zamiast tysiąca.

Zettelkasten z atomowymi notatkami działa lepiej niż RAG na długich dokumentach. Jedna myśl per notatka daje lepszy sygnał niż pięć myśli na jednej stronie.

Czwarta warstwa (Context7 MCP) to dodatek do tego systemu. Twoja baza to wiedza biznesowa, lokalny semantic search daje szybkie wyszukiwanie, warstwa grafowa dokłada relacje, a Context7 dostarcza aktualną dokumentację popularnych bibliotek. Razem AI ma kompletny kontekst: i Twój, i powszechny.

W następnej części otwieram czwarty blok cyklu: automatyzacje. Pokażę, jak zastąpić abonamenty, które płacisz co miesiąc, prostymi skryptami i workflow’ami AI. Pierwsza droga od oszczędzania na narzędziach do budowania własnej infrastruktury.

Twój następny krok: zadanie na dzisiaj

Dwie rzeczy.

1. Zrób audyt tagów w bazie wiedzy. Jeśli masz już atomowe notatki, otwórz w Obsidian listę tagów (Ctrl+Cmd+T lub sidebar po prawej). Sprawdź, które tagi kontekstowe używasz i czy jest między nimi równowaga. Jeśli #gdy-piszę-ofertę ma dwie notatki, a #gdy-konfiguruję-ai ma pięćdziesiąt, zapytaj siebie: czy ja piszę oferty rzadko, czy po prostu nie zapisuję z nich wiedzy?

2. Uruchom prosty semantic search w sesji AI. Jeśli jeszcze nie masz infrastruktury do semantic search, zrób to ręcznie w sesji. Wyślij polecenie:

Mam folder WIEDZA/NOTATKI/ w moim vault. Przejrzyj nazwy plików (nie otwieraj wszystkich, tylko tytuły). Zadaję pytanie: [konkretne pytanie z Twojej pracy]. Wybierz 10 notatek, których tytuły najbliższe są temu pytaniu. Dla każdej napisz jedno zdanie, dlaczego ją wybrałeś. Potem otwórz te dziesięć i na ich podstawie odpowiedz na moje pytanie. Cytuj fragmenty z konkretnych notatek.

To jest ręczny zamiennik semantic search. Wolniejszy, ale działa. I uczy Cię, na czym tym narzędzie polega, zanim zbudujesz infrastrukturę.

Zasoby

Dokumentacja Obsidian: Search — oficjalna dokumentacja wbudowanej wyszukiwarki. Mało znane operatory (tag:, path:, file:) potrafią zaoszczędzić godziny ręcznego przeglądania.
Dokumentacja Neo4j i pojęcie grafów wiedzy — jeśli chcesz zrozumieć, jak graf wiedzy działa pod spodem. Zbyt techniczne na start, ale dobre do zrozumienia, co się dzieje, gdy AI “chodzi” po Twoich linkach między notatkami.
Artykuły o RAG (Retrieval-Augmented Generation) — wzorzec łączenia bazy wiedzy z modelem językowym. Temat techniczny, ale dobrze wiedzieć, jaka jest nomenklatura, gdy będziesz czytał o narzędziach AI. Każdy większy model LLM ma dziś jakiś wariant RAG.

Ten artykuł jest częścią cyklu “Od zera do kompletnego systemu AI w kwartał”. Krok po kroku opisuję jak zbudowałem system AI do zarządzania firmą i rozwojem osobistym, żebyś mógł wdrożyć podobny u siebie. W następnej części: automatyzacje, czyli jak zastąpić miesięczne abonamenty własną infrastrukturą. Masz pytania? Napisz. Odpowiadam osobiście.

Żeby nie przegapić kolejnych części, zaobserwuj mój profil. Nowe artykuły publikuję regularnie.

Marcin Atamańczuk, Technologia w służbie życia, nie odwrotnie.