The Ultimate Knowledge Base: Bring YouTube Into Your AI Second Brain

2026-07-30 Cole Medin AI zagraniczne tutorial waga 4/5 15 min czytania

Jak zamienić cały kanał YouTube w przeszukiwalną bazę wiedzy w formacie OKF i wpiąć ją w swój drugi mózg. Dla osób budujących osobiste bazy wiedzy z agentami AI.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

O czym jest ten film

  1. Autor pokazuje, jak zbudował bazę wiedzy w formacie OKF (Open Knowledge Format) obejmującą wszystkie ~200 filmów z jego kanału YouTube.
  2. OKF to standard tworzenia baz wiedzy dla osobistych agentów i „drugich mózgów” — odpowiednik MCP i A2A, tyle że dla warstwy wiedzy.
  3. Gotową bazę można zainstalować u siebie jednym promptem wklejonym do dowolnego agenta (Claude Code, Hermes, OpenCode itp.).
  4. Baza pozwala zadawać złożone pytania i dostawać odpowiedzi z cytowaniem konkretnych filmów i znaczników czasu, zamiast oglądać wielogodzinne materiały.
  5. Struktura: README, plik indeksu z „tematami”, oraz pliki koncepcji i encji — wszystko w czystym Markdownie.
  6. Cały graf wiedzy da się przeglądać w Obsidianie lub VS Code; połączenia między dokumentami budują graf automatycznie.
  7. Pipeline budowy: ekstrakcja transkryptów → kanonikalizacja (wyłuskanie powtarzających się encji i koncepcji) → zapis połączonych plików.
  8. Kanonikalizacja wymaga rozumowania LLM: to samo pojęcie bywa nazywane różnie w różnych filmach i trzeba je scalić (fuzzy matching, nie dopasowanie słów kluczowych).
  9. Autor udostępnia trzy „skille”, które robią cały pipeline dla dowolnego kanału na podstawie jednego URL — różnią się tylko sposobem pobierania transkryptów.
  10. Proces jest tokenochłonny i długi, ale — zdaniem autora — wart zachodu przy kanałach z setkami filmów.

Redakcyjne tłumaczenie

OKF — kolejny standard, który udostępnia AI

Kilka tygodni temu omawiałem nowy, otwarty format wiedzy od Google. To standard tworzenia baz wiedzy dla naszych osobistych agentów i drugich mózgów. Jest ważny, bo bierze ideę „LLM wiki” Karpathy’ego — która swego czasu podbiła świat — i daje nam uniwersalny format, dzięki któremu możemy budować bazy wiedzy nie tylko dla siebie, ale i do dzielenia się z innymi. OKF definiuje specyfikację. Tak jak MCP stworzyło standard „agent–narzędzie”, a A2A standard „agent–agent”, tak OKF tworzy dla nas standard „agent–baza wiedzy”.

(Informacja dodatkowa: OKF to skrót od Open Knowledge Format; MCP to Model Context Protocol, a A2A to Agent-to-Agent — to protokoły opisujące, jak agenci AI łączą się odpowiednio z narzędziami i między sobą. Andrej Karpathy, były badacz OpenAI i Tesli, spopularyzował ideę „LLM wiki” jako osobistej bazy wiedzy dla modeli.)

Uwielbiam takie standardy, bo każdy kolejny to krok ku temu, by AI było jak najbardziej dostępne. Pomyślcie, jak rewolucyjne było MCP dla wszystkich w zeszłym roku. Zastanawiałem się więc, jak najprościej pokazać wam siłę OKF. A gdybym tak zbudował bazę wiedzy tak użyteczną, że od razu będziecie chcieli jej spróbować? I zrobiłem właśnie to: stworzyłem bazę wiedzy OKF — czyli „bundle” — dla całego mojego kanału YouTube. Dobrze słyszycie: 200 filmów spakowanych i gotowych, byście mogli zadawać nad nimi dowolne pytania. Porozmawiamy też o tym, jak zrobić to samo dla innych kanałów, bo oczywiście nie zakładam, że skończycie na moim.

Baza wiedzy w akcji

Przejdźmy do Claude Code. Na start zadałem celowo złożone pytanie: „Jaki jest mój pełny, kompletny proces budowania nowej funkcji z agentami do kodowania AI?”. To rzecz, na którą normalnie trzeba by obejrzeć cały długi film albo nawet kilka. Ja jednak proszę agenta, by przeprowadził mnie przez to krok po kroku i przy okazji zacytował konkretne filmy, w których każdy etap wyjaśniam.

Agent chwilę szuka. Ma skonfigurowaną całą „LLM wiki” wraz z plikiem indeksu, więc wie, gdzie zacząć i gdzie szukać, a potem daje bardzo wyczerpującą odpowiedź. Czytałem ją wcześniej poza kamerą — jest idealna. Cytuje wszystkie źródła: koncepcje, a nawet konkretne filmy ze znacznikami czasu, z których zaczerpnął odpowiedź.

Kilka innych pytań na szybko. „Kiedy RAG jest martwy, a kiedy nadal niezbędny?” — pytanie, które pewnie sami sobie zadawaliście. Nie zawsze chce się oglądać cały film tylko po to, by poznać odpowiedź. Możemy dostać ją ogólnie, a potem wejść w konkretny materiał, jeśli chcemy zgłębić temat.

(Informacja dodatkowa: RAG — Retrieval-Augmented Generation — to technika, w której model przed odpowiedzią pobiera fragmenty dokumentów z zewnętrznej bazy.)

Podobnie: „Jak właściwie działa mój drugi mózg od podszewki? Jakie ma kluczowe komponenty i które filmy wyjaśniają każdą z części?”. Dostajemy podsumowanie i możemy wejść głębiej. Bazy wiedzy używamy więc nie tylko do ogólnych przeglądów i szybkich odpowiedzi, ale też do nawigacji po większych kanałach. Większość kanałów, które śledzicie, ma pewnie setki filmów — trudno za tym nadążyć. Taka baza wiedzy w połączeniu z waszym drugim mózgiem to sposób, by sobie z tym poradzić.

Instalacja: jeden prompt

Żeby zacząć korzystać z tej bazy, wystarczy wysłać do agenta jeden prompt. Może macie drugi mózg zbudowany na Claude Code, używacie Hermesa albo OpenCode — nieważne. Wystarczy jeden prompt. W opisie podlinkuję repozytorium na GitHubie z pełną bazą wiedzy mojego kanału. W README, po przewinięciu w dół, kopiujecie ten prompt, wysyłacie go do agenta i gotowe. Agent nauczy się OKF, jeśli wasz drugi mózg jeszcze nie zna tego formatu, sklonuje bazę wiedzy i od razu będzie gotów odpowiadać na pytania.

Jak jest zbudowana baza wiedzy

Zanim opowiem, jak ją zrobiłem, dam wam ogólny przegląd struktury. Zaczynamy od README — służy tylko do tego, byście zrozumieli bazę i mieli prompt instalacyjny. Pierwszym plikiem, który przegląda agent, jest indeks. Tak działa każda wiki. Jeśli agent zna już OKF, wie, jak nawigować po całości. Ważniejsza część indeksu to „tematy” — to one dają agentowi ogólny obraz wiedzy, która się tu znajduje: na jakie pytania możemy odpowiedzieć. Agent startuje stąd, a potem — w zależności od pytania — przechodzi przez różne koncepcje i encje rozpisane w dokumencie indeksu.

Wszystko, co tu mamy — koncepcje, encje, sam indeks — to po prostu Markdown. To filmy z YouTube zamienione w transkrypty w Markdownie, z których wyłuskano wszystkie kluczowe koncepcje i encje. Ponieważ wszystko jest Markdownem, i nam, i naszym agentom łatwo się po tym poruszać. Zwykle po prostu każecie agentowi przeszukać pliki, ale jeśli chcecie przejrzeć je sami, możecie to zrobić w IDE takim jak VS Code albo w narzędziu takim jak Obsidian. Ja używam Obsidiana i często o nim mówię. Daje też lepsze formatowanie, gdy chcemy zajrzeć do informacji — na przykład sprawdzić źródła cytowane przez agenta.

Graf wiedzy w Obsidianie

Warto szybko pokazać „mózg” tej bazy. Patrząc na widok grafu w Obsidianie, widać, ile informacji jest tu ze sobą powiązanych. Widzimy na przykład, jak inżynieria kontekstu wiąże się z „vibe codingiem”, albo jak walidacja łączy się ze wzorcem subagentów. Mamy mnóstwo połączeń, które pozwalają agentowi przesiewać informacje i swobodnie przemierzać graf.

(Informacja dodatkowa: „context engineering” to projektowanie tego, jakie informacje trafiają do kontekstu modelu; „vibe coding” to programowanie w dużej mierze poprzez opisywanie intencji agentowi AI zamiast ręcznego pisania kodu.)

I żeby uprzedzić pytanie: tak, zbudowanie całej tej bazy pochłonęło mnóstwo tokenów LLM. Nie bez powodu zaczynam tylko od własnego kanału. Chętnie wziąłbym listę wszystkich najlepszych kanałów AI i zbudował to wszystko dla was, ale będę to musiał robić stopniowo. Uwielbiam jednak patrzeć, ile informacji się tu składa, bo to pokazuje, że bez LLM-ów nie da się czegoś takiego zbudować. Można zrobić wersję znacznie prostszą, ale to właśnie użycie dużego modelu językowego do skalowania tego, ile informacji da się wydobyć i połączyć, jest istotą „LLM wiki”.

[Materiał sponsorowany: SerpAPI]

(Informacja dodatkowa: poniższy fragment to reklama sponsora — SerpAPI. Zachowana dla wierności, ale nie jest częścią merytorycznego wywodu.)

Jednym z najważniejszych narzędzi dla agentów AI jest wyszukiwanie w sieci — to sposób na dostęp do aktualnych informacji. Nie chcecie jednak budować tej funkcji sami: utrzymywać scraperów, rotować proxy, walczyć z captchami. SerpAPI — sponsor dzisiejszego filmu — to skrót, którego potrzebujecie. To API wyszukiwania, które zamienia żywe wyniki Google, filmy YouTube, Bing i inne wyszukiwarki w ustrukturyzowany JSON dla waszego agenta jednym wywołaniem. Bez kodu do scrapowania, bez zarządzania proxy, bez walki z zabezpieczeniami antybotowymi. Można też sięgnąć po Google Scholar API po recenzowane prace (agent badawczy) albo Google Images API po obrazy z gotowymi tytułami, miniaturami i URL-ami. Wiadomości, trendy, mapy — wszystko wraca w tej samej ustrukturyzowanej formie, niezależnie od modelu i frameworka, a każde zapytanie jest w czasie rzeczywistym. Na start dostajecie 250 darmowych kredytów.

Jak zbudowałem bazę — pipeline

Ten proces możecie odtworzyć także dla czegoś innego niż YouTube — dowolnej bazy wiedzy. Trzeba było przejść przez spory proces, by wydobyć setki filmów i wyciągnąć z nich kluczowe koncepcje.

Pierwszy krok: dla wszystkich filmów z YouTube ekstrahujemy transkrypty. Chcę je jako dokumenty Markdown, bo to najlepszy format dla LLM i format całej bazy. Folder „raw” zawiera transkrypty każdego mojego filmu — po wejściu w dowolny widać dokładne znaczniki czasu dla poszczególnych zdań. To pełny film, mnóstwo tekstu. Surowe transkrypty też mają być w bazie — to najlepsze miejsce, by cytować źródła i podawać dokładne znaczniki czasu, jeśli ktoś chce obejrzeć całość.

Po zebraniu surowych transkryptów przechodzimy przez proces kanonikalizacji (spróbujcie to szybko powiedzieć pięć razy pod rząd). Tu patrzymy na wszystkie transkrypty z lotu ptaka i ustalamy, co się powtarza: jakie są kluczowe encje i koncepcje, które chcemy zapisać jako osobne pliki, a potem łączymy je ze sobą i z oryginalnymi filmami, budując graf wiedzy.

Koncepcje i encje

Transkrypty w folderze „raw” to dopiero punkt wyjścia — nie dotyczą jednego tematu. Zwykle jeden film porusza wiele wątków. Dlatego, by naprawdę się skupić, tworzymy pliki koncepcji (np. „protokół A2A”, „abstraction distraction”) oraz encji — wszystkich narzędzi, o których mówię na kanale, jak metoda BMAD czy bolt.new. Gdy wejdziemy na przykład w AGUI, cała informacja jest zagregowana z różnych filmów, w których o tym mówię — wszystko zebrane w jeden plik encji.

(Informacja dodatkowa: „abstraction distraction” to autorskie określenie autora na framework/bibliotekę, która obiecuje zrobić za nas tak wiele, że ostatecznie odbiera elastyczność, kontrolę i zrozumienie — jako przykład podaje LangChain.)

Podobnie z koncepcjami. „Abstraction distraction” to framework lub biblioteka obiecująca tak wiele, że kosztuje was elastyczność, kontrolę i zrozumienie, których naprawdę potrzebujecie — jak choćby LangChain (baza sama to wychwyciła, tak dobrze mnie „zna”). Mówię o tym w wielu filmach, zwykle przy wyborze właściwego frameworka dla agentów AI — i to wszystko zebrane jest w jednym miejscu. Na dole pliku widać źródła: w których filmach i w których dokładnie momentach o tym mówię. Łączenie tych dokumentów buduje też automatycznie widok grafu w Obsidianie — powstaje on zawsze, gdy z jednego dokumentu odwołuję się do drugiego.

Najtrudniejszy element: scalanie wariantów nazw

Krok kanonikalizacji jest zdecydowanie najbardziej skomplikowany, bo trzeba mocno pokierować agentem, żeby wiedział, jakie encje i koncepcje zasługują na osobny plik. Najtrudniejsze jest to, że te same koncepcje nie zawsze są opisywane tak samo. Na przykład podstawowy workflow kodowania z AI, którego uczę, to „pętla PIV” — od Plan, Implement, Validate (planuj, wdrażaj, waliduj). W jednym filmie nazywam to pętlą PIV, w innym „workflow plan-implement-validate”, „workflow PIV” albo „plan-build-verify”. To trochę wymuszony przykład, ale idea jest jasna: agent musi rozpoznać, że mowa o tym samym, i zagregować to w jednym dedykowanym pliku.

Potrzebujemy więc dopasowania rozmytego wariantów — nie samego dopasowania słów kluczowych. Potrzebny jest LLM, który przeprowadzi rozumowanie i ustali, że to wszystko należy do pliku „piv-loop” w folderze koncepcji. A jeśli coś zostanie zidentyfikowane jako jednorazowo wspomniane narzędzie, pewnie nie zasługuje na miejsce — gdybym umieszczał każde narzędzie wspomniane choćby raz, baza byłaby za duża i by się nie skalowała; agent miałby problem z nawigacją. Bierzemy więc kluczowe koncepcje i encje pojawiające się więcej niż raz i z nich budujemy bazę.

Skille do budowy własnej bazy

Na koniec obiecane skille, które pomogą wam zbudować bazę wiedzy dla własnego kanału YouTube. Leżą w tym samym repozytorium co baza mojego kanału i są opisane w README. Wystarczy wybrać jeden ze skilli i przejdzie on przez cały pipeline, który omówiliśmy, budując bazę na podstawie jednego URL kanału. To jedyny potrzebny wam input.

Trzy skille istnieją dlatego, że chciałem dać wam różne opcje usług do pobierania transkryptów z YouTube. Osobiście od dawna używam Supadata API — jest najbardziej niezawodne w moim doświadczeniu, ale to usługa płatna, a nie oczekuję, że będziecie płacić za budowanie tych baz. Zachęcam, byście zaczęli od jednej z darmowych opcji. Sztuka w tym, że nie da się użyć YouTube Data API bezpośrednio dla niczego poza własnym kanałem, więc trzeba korzystać z podmiotów trzecich — jak YouTube Transcript API czy yt-dlp — by pobrać transkrypty z dowolnego kanału, jeśli budujecie bazę nie ze swojego kanału.

(Informacja dodatkowa: yt-dlp to popularne, otwarte narzędzie wiersza poleceń do pobierania z YouTube; „skill” w Claude Code to spakowany zestaw instrukcji uruchamiany komendą typu /nazwa.)

Weźmy skill „channel-to-KB”. W .claude/skills/channel-to-KB jest skrypt pobierający transkrypty z kanału. Reszta to skill.md — pełna instrukcja dla agenta, prowadząca go przez budowę bazy tak, jak robiłem to ja. Każemy mu przeczytać specyfikację OKF, by zrozumiał format, potem pobrać transkrypty, przejść przez kanonikalizację i zapisać wszystkie pliki encji i koncepcji. Skill jest dość prosty, bo nie musi wiele wyjaśniać — większość wyjaśnień jest w specyfikacji OKF. Jeśli agent ją przeczyta i umie produkować format OKF, to wystarczy, poza odrobiną instrukcji o tym, jak pobieramy informacje i pracujemy w systemie plików.

Żeby to uruchomić, w agencie takim jak Claude Code wpisujecie /channel-to-KB i podajecie pełny URL kanału albo uchwyt, np. @ColeMedin. To długi i tokenochłonny proces — tworzymy dużo dokumentów — ale uważam, że warto poświęcić czas na bazę wiedzy dla każdego kanału, który zwykle śledzicie. Właśnie dlatego zbudowałem bazę mojego kanału dla was: możecie ją od razu pobrać i zacząć zadawać pytania, jak pokazywałem na początku.

Podsumowanie

To wszystko. Zachęcam: zbudujcie bazę wiedzy dla jakiegoś kanału. Skorzystajcie z mojej, zadawajcie pytania — odpowiedzi dostajecie błyskawicznie w porównaniu z oglądaniem każdego filmu. Oczywiście nadal chcę, żebyście oglądali moje materiały — dają głębsze zanurzenie, którego często potrzebujecie — ale to sposób, by skuteczniej nawigować po kanałach.

10 najważniejszych takeaways — z kontekstem zastosowania

1.OKF to standard „agent–baza wiedzy”

Na czym polega: Open Knowledge Format definiuje uniwersalny sposób zapisu osobistej bazy wiedzy w Markdownie, tak by agenci AI potrafili się po niej poruszać — analogicznie do MCP (agent–narzędzie) i A2A (agent–agent).

Jak stosować: Jeśli budujesz „drugi mózg”, przyjmij OKF jako format docelowy — dzięki temu bazy są przenośne między agentami (Claude Code, Hermes, OpenCode) i możliwe do dzielenia się z innymi.

Na co uważać: To wciąż wczesny standard od Google. Zanim mocno w niego zainwestujesz, sprawdź aktualność specyfikacji i adopcję — standardy z początkowej fazy potrafią się zmieniać.

2.Cały kanał YouTube jako przeszukiwalna baza

Na czym polega: Zamiast oglądać setki filmów, zamieniasz kanał w bazę, której zadajesz złożone pytania i dostajesz odpowiedzi zsyntetyzowane z wielu materiałów.

Jak stosować: Wybierz kanał, który realnie śledzisz i który ma dużo materiału (setki filmów), by zwrot z inwestycji w budowę bazy był wysoki. Używaj bazy do szybkich przeglądów, a do filmu wchodź tylko po głębsze detale.

Na co uważać: Baza to synteza, nie oryginał — do decyzji o wysokiej stawce weryfikuj odpowiedź w cytowanym źródle i znaczniku czasu, zamiast ufać samemu streszczeniu.

3.Instalacja jednym promptem

Na czym polega: Gotową bazę OKF wpina się do agenta pojedynczym promptem z README repozytorium — agent w razie potrzeby uczy się OKF, klonuje bazę i jest gotów odpowiadać.

Jak stosować: Trzymaj bazy w repozytoriach Git z README zawierającym prompt instalacyjny — to najprostsza droga dystrybucji i onboardingu dla dowolnego agenta.

Na co uważać: Wklejanie promptu, który klonuje repozytorium i uczy agenta formatu, to wykonywanie cudzych instrukcji — używaj tylko zaufanych źródeł i przejrzyj repo, zanim je podłączysz.

4.Wszystko w czystym Markdownie

Na czym polega: Indeks, koncepcje, encje i surowe transkrypty to zwykłe pliki Markdown — czytelne zarówno dla agenta, jak i dla człowieka.

Jak stosować: Buduj bazę w Markdownie, żeby móc ją przeglądać i edytować ręcznie w VS Code lub Obsidianie oraz łatwo wersjonować w Git. To też najlepszy format wejściowy dla LLM.

Na co uważać: Sam Markdown nie egzekwuje struktury — bez trzymania się konwencji OKF (indeks, tematy, linki) agent straci zdolność nawigacji po dużej bazie.

5.Plik indeksu z „tematami” jako punkt startu

Na czym polega: Agent zawsze zaczyna od indeksu, a kluczowa jest sekcja „tematów” — daje ona ogólny obraz, na jakie pytania baza w ogóle odpowiada, i kieruje do właściwych koncepcji/encji.

Jak stosować: Zainwestuj czas w dobry indeks i listę tematów — to one decydują, czy agent trafnie kieruje zapytania. Traktuj indeks jak mapę, nie spis treści.

Na co uważać: Nieaktualny lub niekompletny indeks sprawi, że agent „nie zobaczy” istniejącej wiedzy — aktualizuj indeks przy każdym powiększeniu bazy.

6.Kanonikalizacja: scalanie encji i koncepcji

Na czym polega: Surowe transkrypty przechodzą etap, w którym z lotu ptaka wyłuskuje się powtarzające pojęcia i zapisuje je jako osobne, wzajemnie połączone pliki koncepcji i encji.

Jak stosować: Odseparuj surowe transkrypty (do cytowań) od plików koncepcji/encji (do odpowiedzi). To rozdzielenie utrzymuje bazę zwięzłą i nawigowalną.

Na co uważać: To najbardziej złożony i najbardziej tokenochłonny etap — wymaga starannego pokierowania agentem, co zasługuje na osobny plik, a co nie.

7.Fuzzy matching wariantów nazw, nie słów kluczowych

Na czym polega: To samo pojęcie bywa nazywane różnie w różnych filmach (np. „pętla PIV”, „plan-implement-validate”, „plan-build-verify”); LLM musi rozumowaniem rozpoznać, że to jedno i scalić to w jeden plik.

Jak stosować: Zdaj to zadanie na model, nie na dopasowanie słów kluczowych. Jeśli sam masz stały słownik pojęć, przekaż go agentowi jako wskazówkę, by ujednolicił nazewnictwo.

Na co uważać: Zbyt agresywne scalanie połączy pojęcia naprawdę odrębne, a zbyt zachowawcze rozdrobni bazę — przejrzyj scalenia ręcznie w kluczowych obszarach.

8.Odsiewaj jednorazowe wzmianki

Na czym polega: Narzędzia i pojęcia wspomniane tylko raz nie dostają własnego pliku — inaczej baza rozrasta się i przestaje się skalować, a agent gubi się w nawigacji.

Jak stosować: Ustaw próg (np. „pojawia się więcej niż raz”) jako kryterium tworzenia dedykowanego pliku. Priorytetyzuj rdzeń wiedzy, nie kompletność.

Na co uważać: Czasem jedna wzmianka jest istotna mimo rzadkości — traktuj próg jako regułę domyślną, nie sztywne prawo, i rób wyjątki świadomie.

9.Trzy skille — różne sposoby pobierania transkryptów

Na czym polega: Autor udostępnia gotowe skille robiące cały pipeline z jednego URL kanału; różnią się tylko źródłem transkryptów. Płatne Supadata jest najniezawodniejsze, ale są też darmowe opcje (YouTube Transcript API, yt-dlp).

Jak stosować: Zacznij od darmowej opcji dla eksperymentów; przejdź na płatną usługę dopiero, gdy niezawodność pobierania stanie się wąskim gardłem.

Na co uważać: YouTube Data API działa bezpośrednio tylko dla własnego kanału — dla cudzych kanałów musisz korzystać z narzędzi trzecich, co bywa zawodne i podlega ograniczeniom platformy.

10.To kosztuje tokeny — planuj budżet

Na czym polega: Budowa bazy dla setek filmów jest długa i mocno tokenochłonna, bo LLM generuje wiele dokumentów i wykonuje niebanalne rozumowanie przy kanonikalizacji.

Jak stosować: Rezerwuj budowę pełnej bazy na kanały o wysokiej wartości i traktuj to jako inwestycję jednorazową; potem baza służy do szybkich zapytań bez ponownego przetwarzania.

Na co uważać: Uruchamiając skill na dużym kanale, licz się z realnym kosztem i czasem — zacznij od mniejszego kanału lub próbki, by oszacować zużycie, zanim puścisz pełny przebieg.