---
title: "Budowanie knowledge badawczej LLM: Jak przekształciłem 3000 stron filozofii w żywy system wiedzy"
source: "https://medium.com/@paulo.deassis/building-an-llm-research-knowledge-how-i-turned-3-000-pages-of-philosophy-into-a-living-knowledge-609de9935cd9"
author:
  - "[[Paulo de Assis]]"
published: 2026-04-17
created: 2026-06-08
description: "More"
tags:
  - "clippings"
---
*Jak artysta-badacz zaadaptował wzór LLM Knowledge Base Andreja Karpathy'ego, aby zbudować uporządkowaną bazę wiedzy w filozofii kontynentalnej, ontologii muzyki i posthumanizmie — wykorzystując Claude'a Code jako dedykowanego agenta wywiadu badawczego.*

—

![](https://miro.medium.com/v2/resize:fit:1400/format:webp/1*yIc1Tyhlj3RhS1AciawJvw@2x.jpeg)

Otwartoźródłowe repozytorium LLM Research Knowledge Base na GitHubie.

### Iskra

Na początku kwietnia 2026 roku Andrej Karpathy opublikował [podsumowanie](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) opisujące to, co nazwał "LLM Knowledge Base" — ideę, że zamiast używać RAG (Retrieval-Augmented Generation) do ponownego pozyskiwania wiedzy z surowych dokumentów przy każdym zapytaniu, LLM powinien stopniowo budować i utrzymywać **trwałą, uporządkowaną knowledge**, która kumuluje się z czasem. Surowe źródła są wprowadzane; Na jawie wychodzi uporządkowana, powiązana wiedza. Knowledge Base staje się mądrzejsza niż twoja pamięć o powiązaniach między czytaniem.

Od razu się zainteresowałem. Jako artysta-badacz pracujący z filozofią kontynentalną, kompozycją muzyczną i posthumanizmem, mam do czynienia z gęstymi, powiązanymi źródłami pierwotnymi — Deleuze'em, Simondonem, Rancièrem, Stieglerem, Baradem — gdzie to właśnie powiązania między pojęciami między książkami a autorami sprawiają, że badania są produktywne. Tradycyjne narzędzia do notowania i zarządzania referencjami nie rejestrują tych powiązań. Przechowują dokumenty; Nie *myślą ponad* nimi.

Wzór Karpathy został zaprojektowany z myślą o potrzebach inżyniera oprogramowania (oparty na Obsidianie, skupiony na dokumentacji technicznej). Potrzebowałem czegoś dla badacza humanistycznego pracującego z 300-stronicowymi monografiami filozoficznymi, gdzie pojedynczy koncept mógł pojawić się u pięciu różnych autorów o pięciu różnych znaczeniach. Postanowiłem więc ją zaadaptować.

### Faza projektowania

Zacząłem od wzięcia podstawowego wglądu Karpathy'ego — surowych źródeł jako niezmiennej prawdy, knowledge jako żywej warstwy syntezy, uporządkowanych przepływów pracy do pobierania/zapytań/lintowania — i od zastanowienia się, jak dostosować je do badań naukowych. Użyłem ChatGPT, aby opracować początkową architekturę: Jakie typy stron potrzebuje knowledge humanistyczne? Jak powinny być zorganizowane koncepcje, autorzy i debaty? Jaki rodzaj frontu umożliwia szybką nawigację?

Ta eksploracja zaowocowała pierwszym szkicem schematu: sześciostronicowe typy (przypisy źródłowe, koncepcje, autorzy, debaty, syntezy, projekty), konwencje YAML frontmatter oraz architektura trójwarstwowa (surowa → knowledge → schemat).

Następnie przeszedłem do Claude Code — terminalowego agenta kodującego Anthropic — do faktycznej implementacji. Kod Claude działa bezpośrednio w twoim systemie plików, czytając i zapisując pliki markdown, a także zachowuje kontekst przez długie sesje. Dzięki temu był idealnym narzędziem do budowania i utrzymania knowledge: mógł czytać 300-stronicowy PDF, tworzyć 15 połączonych stron knowledge i aktualizować indeks — wszystko to w jednej sesji konwersacyjnej.

Ważny szczegół: początkowa wersja nie była operacją pojedynczego agenta. Wcześniej stworzyłem trzech wyspecjalizowanych agentów w Claude Code, a sesja konfiguracyjna zaaranżowała wszystkich trzech:

**Agent A** — Zorganizował pełne przygotowanie; Zadania przekierowane do pozostałych dwóch agentów

**Agent B** — Zbadał strategię wdrożenia dużych istniejących kolekcji (problem "5 000 notatek / 4 000 PDF-ów")

**Agent C** — Zbudował strukturę folderów, stworzył schemat CLAUDE.md i wszystkie pliki szablonów oraz wykonał pierwsze pobieranie — co wygenerowało 38 stron knowledge w jednym przejściu

Ten wieloagentowy podział pracy oznaczał, że cały system — schemat, foldery, szablony, strategia onboardingu oraz w pełni obsadzony pierwszy ingest — był budowany w jednej sesji. Po tym agencie nie byli już potrzebni: sam schemat CLAUDE.md stał się stałym operatorem, odczytywanym przez Claude'a Code na początku każdej kolejnej sesji.

Nie spodziewałem się jednak, że Claude Code stanie się nie tylko twórcą, ale *także operatorem* knowledge. Plik CLAUDE.md u podstaw projektu działa jako stały zestaw instrukcji: za każdym razem, gdy rozpoczyna się nowa sesja, Claude ją odczytuje i działa jako dedykowany agent ds. inteligencji badawczej — podążając za przepływem workflow ingest, zapytań i lint zdefiniowanym w schemacie.

### Architektura

System składa się z trzech warstw:

**surowe/** — Niezmienne dokumenty źródłowe (PDF, transkrypcje, notatki). *Napisane przez badacza.*

**knowledge/** — Ustrukturyzowane strony z wyznaczaniem (koncepcje, autorzy, debaty, syntezy, przypisy źródłowe, projekty). *Napisane przez LLM.*

**Schemat** — CLAUDE.md (instrukcje operacyjne), index.md (indeks główny), log.md (dziennik zmian). *Napisane przez obu autorów.*

Surowa warstwa jest święta — pliki źródłowe nigdy nie są modyfikowane po umieszczeniu tam. Warstwa knowledge/to żywa synteza, która rośnie z każdym przyjmianiem. Warstwa schematu rządzi wszystkim.

### Sześć typów stron

Każda strona knowledge korzysta z jednego z sześciu szablonów, z których każdy ma konkretne materiały YAML:

- **Przypisy źródłowe** — jedna na każdy przyjęty dokument. Streszczenie, kluczowe twierdzenia (z numerami stron), bezpośrednie cytaty, powiązania z innymi stronami, otwarte pytania.
- **Strony koncepcyjne** — po jednej na każdą koncepcję (np. "asamblaż", "transdukcja", "haecceity"). Definicje, kluczowi myśliciele, powiązane pojęcia, źródłowe poparcie z wielu tekstów.
- **Strony autorów** — jedna na każdego kluczowego myśliciela. Szkic biograficzny, kluczowe prace, koncepcje, znaczenie dla moich badań.
- **Strony debat** — przedstawione intelektualne nieporozumienia w całej literaturze.
- **Strony syntezy** — ewoluujące przeglądy argumentacyjne na skupisku powiązanych stron.
- **Strony projektowe** — aktywne badania lub projekty pisarskie z ich inwentarzem koncepcji/źródeł.

### Epistemiczne markery

Z tej cechy jestem szczególnie dumny: każde twierdzenie w knowledge ma epistemiczny znacznik rejestru.

- *(brak znacznika)* — Bezpośrednio przypisane do nazwanego źródła
- **\[W\]** — Synteza Knowledge Base: integracja redakcyjna LLM w wielu źródłach
- **\[P\]** — Moje własne stanowisko badawcze: nie to, co mówi źródło, lecz to, co ja argumentuję
- **\[?\]** — Niepewne: data, przypisanie lub twierdzenie, którego knowledge nie może jednoznacznie zweryfikować

To ma znaczenie, ponieważ w badaniach humanistycznych rozróżnienie między "co mówi Deleuze", "tym, co mówi Sauvagnargues i Deleuzem" oraz "tym, co twierdzę o obu" ma filozoficzne znaczenie. Znaczniki utrzymują te rejestry widoczne.

### Projektowanie nawigacji

Po około 50 stronach napotkałem problem ze skalowaniem: płaski indeks alfabetyczny staje się zbyt wolny do nawigacji. Rozwiązaniem była trzywarstwowa kaskada nawigacyjna:

1. **Skupiska pojęciowe** w index.md — grupowania tematyczne (4–6 na dziedzinę), które najpierw sprawdza zapytanie
2. **Strony syntezy** — wstępnie przygotowane przeglądy argumentacyjne dla każdego klastra (jedna strona zamiast sześciu)
3. **powiązane: pola YAML** — każda strona koncepcji/autora zawiera 3–5 wskaźników do najbliższych sąsiadów

Kaskada oznacza, że przy 185 stronach koszt zapytań jest mniej więcej taki sam jak przy 50.

### Liczby

Po około dwóch tygodniach intensywnej pracy (6–17 kwietnia 2026) knowledge wygląda tak:

- **Pobrane dokumenty źródłowe:** 70
- **Łączna liczba stron knowledge:** 185 (65 koncepcji, 39 autorów, 70 przypisów źródłowych, 4 debaty, 2 syntezy, 5 projektów)
- **Łączna liczba odnośników krzyżowych (linków markdown):** 1 592
- **Łączna liczba słów w knowledge:** 233 881
- **Strony materiałów źródłowych czytają:** ~3 200
- **Wpisy w dzienniku:** 73

Liczba debat i syntez jest niska — te typy stron rozwijają się wolniej, ponieważ wymagają prawdziwej argumentacyjnej integracji między wieloma źródłami, a nie tylko wyodrębniania z jednego tekstu. Będą rosnąć wraz z dojrzewaniem knowledge. Strony koncepcji i autora, w przeciwieństwie do nich, są już gęste: każda strona koncepcyjne ma co najmniej 2 wpisy wsparcia źródłowego, a najbogatsze mają ich 17.

### Mnożnik Spożycia

Średnio każde przejęte źródło generuje **2,6 strony knowledge** (1 przypis źródłowy + aktualizacje do ~1,6 istniejących stron). Jednak ta średnia skrywa dużą różnorodność:

- **Krótki artykuł** (5–20 stron) zazwyczaj generuje 1 przypis źródłowy + aktualizacje 2–3 istniejących stron = **operacje 3–4 strony**
- **Duża monografia** (200+ stron) może przynieść 1 przypis źródłowy + aktualizacje do 8–10 istniejących stron = **10–12 operacji** stron
- **Największe pojedyncze pobieranie** — *Deleuze i Sztuka* Sauvagnarguesa (187 stron) — stworzyło 7 nowych stron (6 nowych zalążków koncepcyjnych + 1 przypis źródłowy) i zaktualizowało 10 istniejących stron = **17 operacji** stronicowych

Prawdziwa siła nie tkwi w tworzeniu nowych stron, lecz *w aktualizacji* istniejących. Gdy pobieram rozdział 4 *Deleuze'a "Różnica i powtórzenia* ", LLM nie tylko tworzy przypis źródłowy — dodaje źródłowe źródło do strony koncepcji *multiplicity*, aktualizuje stronę *różnicowania*, wzbogaca stronę *jednoznacznych bytów* i dodaje ją do strony autora Deleuze'a. Każde nowe spożycie sprawia, że każde poprzednie jest bardziej wartościowe.

### Najgęstsze węzły

Niektóre strony koncepcji stały się niezwykle bogate dzięki zgromadzonym doświadczeniom:

**Assemblage** — 17 haseł źródłowych, obejmujących Deleuze-Guattariego, DeLandę (4 książki), Sauvagnargues (2 książki), moje własne teksty, Beistegui, Haraway, Rancière, Simondon

**Posthumanizm** — 13 wpisów, obejmujących Hassana, Harawaya, Haylesa, Braidottiego (2 książki), Ferrando (2 źródła), Wolfe'a, Tomlinsona, mój opis grantu ERC

**Transdukcja** — 9 wpisów, obejmujących Simondona (2 źródła), Stieglera, Hui (2 źródła), Beisteguiego, Sauvagnarguesa (2 książki), mój własny artykuł o transdukcji performatywnej

To właśnie te mocno wspierane strony knowledge staje się naprawdę użyteczne jako narzędzie badawcze. Na przykład strona *z asamblażem* zawiera teraz rozróżnienie własności/zdolności DeLandy, definicję tetrawalentną Deleuze-Guattariego, maszynowy asamblaż Sauvagnarguesa, moje własne sześć warstw muzycznych oraz genealogię problemu *agencement/asambler* — wszystko na jednej stronie, z cytowaniami źródeł pierwotnych. Żadna książka ani artykuł nie zawiera tego wszystkiego. Tylko knowledge to robi.

### Problem wdrożenia

Jeśli jesteś uznanym badaczem, prawdopodobnie masz tysiące notatek i tysiące plików PDF. Najważniejszą lekcją, jaką wyniosłem — zanim zacząłem korzystać z jednego źródła — jest to:

**Knowledge Base NIE jest biblioteką. To starannie wyselekcjonowana synteza tego, co ważne TERAZ.**

Podczas fazy projektowania zidentyfikowaliśmy pięć pułapek, których należy unikać:

1. **Fantazja migracji** — nigdy nie próbuj pochłaniać wszystkiego. Twoja obecna biblioteka zostaje tam, gdzie jest.
2. **Przedwczesna kategoryzacja** — nie twórz 50 pustych stubów przed spożyciem jednego źródła.
3. **Pobieranie wszechowe zanim pojawi się kręgosłup** — potrzebujesz 5–10 starannie nadzorowanych pojęć, zanim knowledge będzie miało wystarczającą strukturę, by się nimi kierować.
4. **Zaczynając od najbardziej złożonego źródła** — zacznij od własnej mapy badań, a nie od *Różnicy i Powtórzenia*.
5. **Traktowanie sur/jak kopii twojej biblioteki PDF** — sur/ to wyselekcjonowany folder wejściowy, a nie lustro.

Podejście fazowe, które u mnie się sprawdziło:

- **Faza 0:** Napisz mapę badawczą własnymi słowami — 2–3 strony opisujące twoją obecną konstelację badawczą. Najpierw go połknąć. To zaszczepia knowledge twoje ramy koncepcyjne.
- **Faza 1 (źródła 1–5):** W pełni nadzorowane, jedno źródło na raz, rozłożone na twoje projekty. Trenujesz zarówno knowledge, jak i siebie.
- **Faza 2 (źródła 6–20):** Nadal pod nadzorem, ale można zrobić 2–3 na sesję. Schemat i zgromadzony kontekst knowledge zaczynają kierować decyzjami LLM.
- **Faza 3 (źródła 20+):** Lżejsza nadzór. Pobieranie wsadowe staje się możliwe. Knowledge Base ma wystarczającą gęstość, by wyłapać własne błędy przez kłaczki.

W przypadku istniejących kolekcji: zachowaj swoje 5 000 notatek i 4 000 plików PDF tam, gdzie są. Skopiuj źródło do surowej wersji dotychczas, gdy będziesz gotowy je wchłonąć. W przypadku książek przyjmuj rozdziały, a nie całe tomy. Test priorytetowy: *"Czy cytuję to w czymś, co teraz piszę?"*

Trajektoria wzrostu, którą zaobserwowałem:

- **5 źródeł / ~20 stron** — Podstawowe pytania i odpowiedzi dotyczące źródeł przyswajonych
- **20 źródeł / ~80 stron** — Pierwsze prawdziwe syntezy opłacalne
- **50 źródeł / ~200 stron** — Fragmenty roboczej pracy z zapytań
- **100 źródeł / ~400 stron** — Knowledge Base mądrzejsza niż pamięć o połączeniach krzyżowych

Punkt rentowności przypada na źródło 20–30: gdy zapytanie zwraca cytowaną odpowiedź w 30 sekund zamiast 20 minut przeszukiwania PDF.

### Trzy procesy w praktyce

### PRZYSWAJANIE

Mówię: *wnikaj Deleuze'a, Gilles. 1968 \[1994\] Różnica i powtarzalność. 4.pdf ROZDZIAŁU*

Claude czyta cały rozdział (54 strony gęstej filozofii), a następnie:

1. Omawia ze mną kluczowe wskazówki przed napisaniem czegokolwiek
2. Tworzy notatkę źródłową z 13 kluczowymi twierdzeniami, 10 bezpośrednimi cytatami i 4 otwartymi pytaniami
3. Aktualizuje stronę koncepcji *mnogości* (dodaje "źródło filozoficzne pierwotne")
4. Aktualizuje stronę *różnicowania* (dodaje źródło pierwotne, degraduje Beisteguiego do "drugorzędnego")
5. Rozwiązuje problem "cienkiego wsparcia źródła" w *onto-heterogenezie* i *byciu jednorazowym*
6. Aktualizuje stronę autora Deleuze'a
7. Aktualizacje index.md i log.md

Łącznie: 1 strona utworzona, 5 zaktualizowanych stron, 2 problemy z cienkim źródłem rozwiązane. Czas: około 10 minut.

### ZAPYTANIE

Mogę zapytać: "Jak działa koncepcja linii ucieczki politycznie?"

Claude sprawdza index.md, identyfikuje Klaster C, czyta stronę koncepcyjną *linii lotu* (która zawiera 3 wpisy wspierające źródło: ATP Ch. 1, Sauvagnargues 2013 i Thornton 2020), podąża za powiązanymi polami do *składania* i *stawania* się, a następnie konstruuje odpowiedź na podstawie syntetycznego knowledge — cytując konkretne strony i fragmenty bez konieczności ponownego czytania oryginalnych PDF-ów.

### LINT

Mówię: *kłaczki*

Claude przeprowadza audyt wszystkich 185 stron według 8 kryteriów: strony sierot, niedziałające linki, brakujące epistemiczne znaczniki, słabe wsparcie źródłowe, przestarzałe strony, notatki źródłowe nieobecne w indeksie, pojęcia brakujące w indeksie. Ostatni powrót kłaczków: 0 sierot, 0 brakujących markerów, 0 cienkich stron źródłowych, 0 zerwanych linków koncepcyjnych, 1 592 nienaruszone odnośniki krzyżowe. Każda strona koncepcyjna ma 2+ źródła.

### Czego się nauczyłem

### 1\. Knowledge Base to coś więcej niż suma źródeł

Najcenniejsze strony to te, które łączą źródła pomiędzy źródłami, których żaden z autorów nie połączył. Strona *z asamblażem* — czerpiąca z filozoficznej koncepcji Deleuze-Guattariego, ontologii społecznej DeLandy, estetyki Sauvagnarguesa oraz mojego własnego zastosowania muzycznego — zawiera wiedzę, której nie ma nigdzie indziej w formie opublikowanej. Knowledge Base *generuje* wiedzę poprzez akt uporządkowanego gromadzenia.

### 2\. Nadzór ma znaczenie na początku, później już mniej

Pierwsze 10–15 przyjmowań wymagało ścisłego nadzoru: sprawdzania, czy pojęcia są poprawnie identyfikowane, czy połączenia są autentyczne, a nie powierzchowne, czy znaczniki epistemiczne są stosowane poprawnie. Następnie schemat i zgromadzony kontekst knowledge prowadziły LLM ku coraz dokładniejszym i spójniejszym aktualizacjom stron. Knowledge Base szkoli własnego operatora.

### 3\. Workflow usuwania kłaczków jest kluczowy

Bez regularnego lintingu knowledge dryfowałaby: strony osierocone, uszkodzone linki, niespójne znaczniki. Procedura usuwania kłaczków wykrywa te problemy, zanim się kumulują. Uruchamiam go co 10–15 porcji. Zajmuje to 2 minuty i zapobiega godzinom sprzątania.

### 4\. Obsydian jest naturalnym towarzyszem

Po zbudowaniu knowledge całkowicie przez Claude Code otworzyłem folder w Obsidian. Wszystko zadziałało natychmiast — widok wykresu, panel linków, wyszukiwanie. Bez migracji, bez konwersji. Obsidian czyta te same pliki markdown, które pisze Claude. Oba narzędzia są uzupełniające: Claude do operacji strukturalnych (wchłanianie, zapytanie, kłaczki), Obsidian do eksploracji wizualnej i przypadkowego odkrywania.

### 5\. Schemat jest rzeczywistym produktem

Strony knowledge są cenne, ale produktem wielokrotnego użytku jest schemat CLAUDE.md — zestaw instrukcji, który zamienia dowolnego agenta kodującego LLM w operatora knowledge badawczego. Jest [otwartoźródłowe na GitHubie](https://github.com/MetamusicX/llm-research-knowledge). Każdy może go sklonować, edytować kontekst domeny dla swojego pola i zacząć pobierać dane.

### Spróbuj sam

Repozytorium znajduje się na [github.com/MetamusicX/llm-research-knowledge](https://github.com/MetamusicX/llm-research-knowledge).

Czego potrzebujesz:

- [Kod Claude'a](https://claude.ai/code) (rozszerzenie terminal, desktop lub VS Code)
- Plik CLAUDE.md z repozytorium — to schemat, który sprawia, że wszystko działa
- Twoje własne dokumenty źródłowe (PDF-y, notatki do markowania, transkrypcje)
- Brak bazy danych, brak osadzeń, brak wtyczek — tylko pliki i foldery markdown

Zacznij od własnej mapy badawczej jako pierwszego wejścia. To zasiewa knowledge twoim konceptualnym ramą. Potem dodawaj źródła pojedynczo. Nadzoruj pierwsze 10. Kłaczki odprowadzaj co 15 minut. Po 50 źródłach będziesz miał prawdziwe narzędzie badawcze. Po 100 jest niezbędna.

— -

*Paulo de Assis jest artystą-badaczem specjalizującym się w kompozycji, wykonawstwie fortepianowym, filozofii kontynentalnej, studiach nad nauką i technologią* oraz *epistemologii. Jest autorem książki* Logic of Experimentation: Rethinking Music Performance through Artistic Research *(Leuven University Press, 2018). Knowledge Base opisane w tym artykule zostało stworzone w ramach jego trwającego projektu ERC Advanced Grant PosthumanMusic (2026–2030).*

*Wzór LLM Research Knowledge Base jest otwarty na* [*github.com/MetamusicX/llm-research-knowledge*](https://github.com/MetamusicX/llm-research-knowledge)*.*