Jun 9, 2026, 3:31 PM

This commit is contained in:
Paweł Domański
2026-06-09 13:31:56 +00:00
parent 371ae1ae23
commit abca038f50
41 changed files with 0 additions and 0 deletions
@@ -0,0 +1,75 @@
# LLM Wiki
A pattern for building personal knowledge bases using LLMs.
This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.
## The core idea
Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.
The idea here is different. Instead of just retrieving from raw documents at query time, the LLM **incrementally builds and maintains a persistent wiki** — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then *kept current*, not re-derived on every query.
This is the key difference: **the wiki is a persistent, compounding artifact.** The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask.
You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.
This can apply to a lot of different contexts. A few examples:
- **Personal**: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
- **Research**: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.
- **Reading a book**: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like [Tolkien Gateway](https://tolkiengateway.net/wiki/Main_Page) — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.
- **Business/team**: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.
- **Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives** — anything where you're accumulating knowledge over time and want it organized rather than scattered.
## Architecture
There are three layers:
**Raw sources** — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.
**The wiki** — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.
**The schema** — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.
## Operations
**Ingest.** You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.
**Query.** You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: **good answers can be filed back into the wiki as new pages.** A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.
**Lint.** Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.
## Indexing and logging
Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:
**index.md** is content-oriented. It's a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.
**log.md** is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. `## [2026-04-02] ingest | Article Title`), the log becomes parseable with simple unix tools — `grep "^## \[" log.md | tail -5` gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently.
## Optional: CLI tools
At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. [qmd](https://github.com/tobi/qmd) is a good option: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.
## Tips and tricks
- **Obsidian Web Clipper** is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
- **Download images locally.** In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. `raw/assets/`). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can't natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It's a bit clunky but works well enough.
- **Obsidian's graph view** is the best way to see the shape of your wiki — what's connected to what, which pages are hubs, which are orphans.
- **Marp** is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
- **Dataview** is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
- The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.
## Why this works
The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.
The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.
The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.
## Note
This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what's useful, ignore what isn't. For example: your sources might be text-only, so you don't need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.@_in
@@ -0,0 +1,36 @@
---
title: "Accidental DBA (Przypadkowy Administrator)"
type: "concept"
tags: [dba, kariera, zarządzanie-bazami-danych]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/accidental-dba-intro]]"]
confidence: high
---
# Accidental DBA (Przypadkowy Administrator)
## Definition
Osoba, która nie planowała kariery jako administrator baz danych (DBA), ale z racji potrzeb organizacji lub specyfiki projektów (np. jako deweloper lub administrator systemów), przejęła pełną odpowiedzialność za stabilność, bezpieczeństwo i wydajność serwerów bazodanowych.
## How It Works
Zjawisko często zaczyna się od pojedynczego incydentu (awaria produkcji, powolne zapytanie), który wymaga interwencji osoby "najbardziej technicznej" w zespole. Z czasem te interwencje stają się stałym elementem obowiązków, tworząc nieformalną rolę administratora.
## Key Parameters
- **Brak formalnego wykształcenia DBA**: Uczenie się na "żywym organizmie".
- **Reaktywny tryb pracy**: Dominacja gaszenia pożarów nad planowaniem.
- **Dualizm roli**: Łączenie zadań deweloperskich/systemowych z administracją bazą danych.
## When To Use
Termin używany w HR i zarządzaniu IT do identyfikacji luk kompetencyjnych i potrzeb szkoleniowych w zespołach operacyjnych.
## Risks & Pitfalls
- **Wysoki stres**: Odpowiedzialność za dane bez pełnego zrozumienia mechanizmów silnika (np. SQL Server).
- **Zaniedbanie podstaw**: Brak testów backupów lub monitoringu, co prowadzi do katastrofalnych awarii.
- **Dług technologiczny**: Rozwiązania "na szybko" (quick fixes), które utrudniają skalowanie systemu w przyszłości.
## Related Concepts
- [[concepts/proactive-administration]] - Pożądany kierunek ewolucji Accidental DBA.
## Sources
- [[summaries/accidental-dba-intro]]
@@ -0,0 +1,35 @@
---
title: "Halucynacje AI (AI Hallucinations)"
type: "concept"
tags: [AI, bezpieczeństwo, ryzyko]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/ai-impact-on-dba]]"]
confidence: high
---
# Halucynacje AI (AI Hallucinations)
## Definition
Zjawisko, w którym model językowy (LLM) lub system AI generuje informacje, które brzmią przekonująco i logicznie, ale są całkowicie nieprawdziwe, nielogiczne lub niezgodne z faktami.
## How It Works
Wynika z probabilistycznej natury modeli AI, które przewidują kolejny najbardziej prawdopodobny token (słowo), zamiast operować na twardej bazie faktów. W administracji bazami danych może to objawiać się np. sugerowaniem nieistniejących parametrów konfiguracyjnych lub błędnych skryptów SQL.
## Key Parameters
- **Temperatura modelu**: Wyższa temperatura sprzyja kreatywności, ale zwiększa ryzyko halucynacji.
- **Kontekst (Grounding)**: Brak dostępu do aktualnych danych technicznych zwiększa prawdopodobieństwo błędu.
## When To Use
Pojęcie kluczowe przy projektowaniu systemów [[concepts/human-in-the-loop]], gdzie człowiek musi weryfikować wyniki pracy AI.
## Risks & Pitfalls
- **Destabilizacja systemów**: Uruchomienie "halucynowanego" skryptu na produkcji może doprowadzić do utraty danych lub przestoju.
- **Fałszywe poczucie bezpieczeństwa**: Przekonujący ton AI może uśpić czujność administratora.
## Related Concepts
- [[concepts/human-in-the-loop]] - Niezbędny mechanizm obronny przed halucynacjami.
- [[concepts/proactive-administration]] - Ryzyko przy automatycznym dostrajaniu bazy przez AI.
## Sources
- [[summaries/ai-impact-on-dba]]
+43
View File
@@ -0,0 +1,43 @@
---
title: "Rurociągi AI (AI Pipelines)"
type: "concept"
tags: [AI, automatyzacja, workflow, inżynieria-promptów]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/google-nanobanana-workflow]]", "[[summaries/jak-zbudowalem-agenta-newslettera-n8n]]"]
confidence: high
---
# Rurociągi AI (AI Pipelines)
## Definition
Zaawansowany model pracy z AI, w którym zamiast ręcznego wpisywania pojedynczych promptów, buduje się zautomatyzowane ciągi zdarzeń (workflow). Dane wejściowe przechodzą przez serię węzłów (nodes), gdzie są transformowane, wzbogacane i dystrybuowane przez różne modele AI i API.
## How It Works
Typowy rurociąg składa się z:
1. **Triggera**: (np. wiadomość na Telegramie, wrzucenie pliku do `raw/`).
2. **Warstwy wzbogacania**: Jeden model AI (np. GPT-4) poprawia prompt dla innego modelu (np. Gemini Image).
3. **Generacji równoległej**: Tworzenie wielu wariantów jednocześnie.
4. **Dystrybucji**: Automatyczny zapis wyniku w chmurze lub publikacja.
## Key Parameters
- **Szybkość (Throughput)**: Ile zasobów system generuje w jednostce czasu.
- **Koszt (Cost per Asset)**: Wykorzystanie modeli typu "Flash" do obniżenia kosztów masowej produkcji.
- **Powtarzalność**: Zdolność do uzyskania spójnych wyników przy minimalnym udziale człowieka.
## When To Use
- Masowa produkcja treści (social media, newslettery).
- Przetwarzanie dużych zbiorów danych (summarization, data extraction).
- Systemy typu [[concepts/human-in-the-loop]], gdzie człowiek tylko inicjuje proces.
## Risks & Pitfalls
- **Zależność od API**: Zmiany w cennikach lub limitach dostawców mogą zablokować rurociąg.
- **Utrata jakości**: Bez odpowiednich "checkpointów" kontroli jakości, rurociąg może generować treści o niskiej wartości (AI slop).
## Related Concepts
- [[concepts/human-in-the-loop]] - Rurociąg zazwyczaj wymaga człowieka na początku lub końcu.
- [[entities/n8n]] - Główne narzędzie do budowy takich rurociągów.
## Sources
- [[summaries/google-nanobanana-workflow]]
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]
+45
View File
@@ -0,0 +1,45 @@
---
title: "Autoresearch"
type: "concept"
tags: [AI, automatyzacja, machine-learning, karpathy]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/how-to-deploy-autoresearch]]", "[[summaries/karpathy-llm-wiki-breakdown]]"]
confidence: high
---
# Autoresearch
## Definition
Wzorzec projektowy (i konkretne narzędzie autorstwa Andreja Karpathy'ego), w którym agent AI (LLM) autonomicznie prowadzi badania nad poprawą innego modelu AI. Agent modyfikuje kod źródłowy, przeprowadza eksperymenty i uczy się na ich wynikach bez bezpośredniego udziału człowieka.
## How It Works
System działa w pętli zamkniętej:
1. **Instrukcje (Meta-prompt)**: Człowiek definiuje cel i strategię w pliku (np. `program.md`).
2. **Akcja**: Agent AI modyfikuje plik `train.py`.
3. **Eksperyment**: Uruchamiany jest krótki (np. 5-minutowy) proces treningowy.
4. **Ocena**: System porównuje wynik (`val_bpb`) z poprzednim najlepszym rezultatem.
5. **Wersjonowanie**: Udane zmiany są zatwierdzane przez `git`, budując trwały postęp.
## Key Parameters
- **Budżet czasowy**: Stały czas na eksperyment (np. 5 min) wymusza szukanie najbardziej efektywnych rozwiązań.
- **val_bpb**: Obiektywna metryka sukcesu (niższa = lepsza).
- **Autonomia**: Zdolność agenta do podejmowania setek decyzji bez zatwierdzenia przez człowieka.
## When To Use
- Przy optymalizacji hiperparametrów modeli.
- Przy poszukiwaniu nowych architektur sieci neuronowych.
- W badaniach, gdzie przestrzeń poszukiwań jest zbyt duża dla człowieka.
## Risks & Pitfalls
- **Halucynacje w kodzie**: Agent może zaproponować kod, który się nie kompiluje lub daje błędne wyniki (rozwiązywane przez pętlę błędu).
- **Zasoby GPU**: System wymaga ciągłego dostępu do mocy obliczeniowej.
- **Lokalne minima**: Agent może utknąć w jednej strategii poprawy (wymaga dopracowania meta-instrukcji).
## Related Concepts
- [[concepts/ai-pipelines]] - Autoresearch to najbardziej zaawansowana forma rurociągu AI.
- [[concepts/knowledge-compilation]] - Kod modelu jest "kompilowany" przez agenta do coraz lepszej formy.
## Sources
- [[summaries/how-to-deploy-autoresearch]]
- [[summaries/karpathy-llm-wiki-breakdown]]
@@ -0,0 +1,36 @@
---
title: "Kumulowanie Wiedzy (Compounding Knowledge)"
type: "concept"
tags: [produktywność, AI, wiedza, karpathy]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/karpathy-llm-wiki-breakdown]]"]
confidence: high
---
# Kumulowanie Wiedzy (Compounding Knowledge)
## Definition
Właściwość bazy wiedzy (Wiki), dzięki której z każdym nowym dodanym źródłem staje się ona nie tylko większa (więcej plików), ale przede wszystkim gęstsza i bogatsza w powiązania.
## How It Works
Podczas dodawania nowego źródła, LLM nie tworzy izolowanej notatki, ale aktywnie aktualizuje istniejące strony encji i koncepcji. Nowe informacje wzmacniają lub podważają stare twierdzenia, a automatyczne linkowanie krzyżowe buduje gęstą sieć skojarzeń.
## Key Parameters
- **Gęstość sieci (Graph Density)**: Liczba powiązań między stronami.
- **Synteza międzydokumentowa**: Zdolność bazy do odpowiadania na pytania o relacje między autorami/źródłami.
## When To Use
- W długoterminowych projektach badawczych.
- Przy śledzeniu ewoluujących trendów lub tematów (np. rozwój AI).
## Risks & Pitfalls
- **Maintenance Burden**: Bez pomocy AI, koszt utrzymania spójności w gęstej sieci rośnie wykładniczo.
- **Stale Claims**: Ryzyko posiadania nieaktualnych syntez, jeśli LLM nie przeprowadzi poprawnej aktualizacji podczas ingestji.
## Related Concepts
- [[concepts/knowledge-compilation]] - Proces prowadzący do kumulacji.
- [[feynman_problems]] - Narzędzie do ukierunkowania kumulacji wiedzy na konkretne problemy.
## Sources
- [[summaries/karpathy-llm-wiki-breakdown]]
@@ -0,0 +1,36 @@
---
title: "Human-in-the-loop (HITL)"
type: "concept"
tags: [AI, workflow, design-pattern]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/jak-zbudowalem-agenta-newslettera-n8n]]"]
confidence: high
---
# Human-in-the-loop (HITL)
## Definition
Model projektowania systemów AI, w którym człowiek pozostaje integralną częścią procesu, sprawując nadzór nad działaniami sztucznej inteligencji, podejmując ostateczne decyzje lub korygując wyniki.
## How It Works
AI wykonuje "ciężką pracę" (np. zbieranie danych, generowanie szkiców, formatowanie), a człowiek działa jako filtr końcowy (redaktor, zatwierdzający). Proces zazwyczaj kończy się na etapie "Draft", który wymaga manualnej akcji do pełnej realizacji.
## Key Parameters
- **Poziom automatyzacji**: Ile procent pracy wykonuje AI (np. 90% w przypadku newslettera).
- **Punkt kontrolny (Checkpoint)**: Moment, w którym maszyna przekazuje pałeczkę człowiekowi.
## When To Use
- Gdy błędy AI (halucynacje) mają wysoki koszt reputacyjny lub biznesowy.
- Gdy wymagany jest unikalny "głos" lub ton marki.
- W skomplikowanych procesach decyzyjnych, gdzie kontekst pozatechniczny jest kluczowy.
## Risks & Pitfalls
- **Wąskie gardło**: Człowiek może stać się najwolniejszym elementem systemu.
- **Nadmierne zaufanie**: Ryzyko "gumowego stemplowania" wyników AI bez ich faktycznego sprawdzenia.
## Related Concepts
- **Automatyzacja workflow** - Techniczna podstawa realizacji HITL (np. [[entities/n8n]]).
## Sources
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]
@@ -0,0 +1,41 @@
---
title: "Kolizja Pomysłów (Idea Collision)"
type: "concept"
tags: [kreatywność, AI, innowacja, loom]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/loom-thinking-tool]]", "[[summaries/google-nanobanana-workflow]]"]
confidence: high
---
# Kolizja Pomysłów (Idea Collision)
## Definition
Proces twórczy polegający na celowym zderzaniu dwóch lub więcej idei, często pochodzących z zupełnie odległych dziedzin, w celu odkrycia ukrytych podobieństw strukturalnych i wygenerowania nowej, unikalnej wartości.
## How It Works
W systemach wspieranych przez AI (jak [[summaries/loom-thinking-tool]]), proces ten jest zautomatyzowany:
1. System wybiera losowe lub semantycznie odległe notatki z bazy wiedzy.
2. Model językowy analizuje ich treść w poszukiwaniu analogii, wspólnych zasad lub potencjalnych synergii.
3. Wynik prezentowany jest użytkownikowi jako "iskra" do dalszego myślenia lub gotowa synteza.
## Key Parameters
- **Dystans semantyczny**: Im bardziej odległe dziedziny, tym trudniejsza, ale potencjalnie bardziej wartościowa kolizja.
- **Struktura vs Treść**: Najsilniejsze kolizje opierają się na podobieństwie mechanizmów (np. biologia mrówek vs zarządzanie projektami), a nie tylko na słowach kluczowych.
## When To Use
- W fazie generowania pomysłów (ideacji).
- Gdy czujemy, że nasz proces myślowy utknął w rutynie.
- Do budowy unikalnych strategii biznesowych i artystycznych.
## Risks & Pitfalls
- **Puste skojarzenia**: Nie każda kolizja prowadzi do wartościowego wniosku (ryzyko szumu).
- **Zależność od AI**: Ryzyko, że użytkownik przestanie samodzielnie szukać połączeń, polegając wyłącznie na algorytmie.
## Related Concepts
- [[concepts/compounding-knowledge]] - Kolizje przyspieszają gęstnienie sieci wiedzy.
- [[concepts/metacognition-as-a-service]] - Analiza efektów kolizji pomaga zrozumieć własny umysł.
## Sources
- [[summaries/loom-thinking-tool]]
- [[summaries/google-nanobanana-workflow]]
@@ -0,0 +1,36 @@
---
title: "Kompilacja Wiedzy (Knowledge Compilation)"
type: "concept"
tags: [AI, wiedza, architektura, karpathy]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/karpathy-llm-wiki-breakdown]]"]
confidence: high
---
# Kompilacja Wiedzy (Knowledge Compilation)
## Definition
Analogia zapożyczona z inżynierii oprogramowania, gdzie surowe dokumenty źródłowe (PDFy, notatki, artykuły) są traktowane jako "kod źródłowy", który LLM "kompiluje" do postaci trwałej Wiki ("pliku binarnego").
## How It Works
Zamiast przeszukiwać surowe fragmenty tekstów przy każdym pytaniu, LLM przetwarza je raz w momencie ingestji, ekstrahując esencję i integrując ją z istniejącą strukturą. Wynikowa Wiki jest sformatowana tak, aby była optymalna dla przyszłych zapytań i syntez.
## Key Parameters
- **Niezmienność źródeł (Immutability)**: Oryginalne pliki pozostają nienaruszone jako "ground truth".
- **Gęstość informacji**: Skompilowana strona zawiera syntezę wielu źródeł zamiast powielać te same fakty.
## When To Use
- Gdy zależy nam na wysokiej jakości odpowiedzi wymagających łączenia faktów z wielu dokumentów.
- Przy budowie osobistych baz wiedzy na konkretne tematy badawcze.
## Risks & Pitfalls
- **Koszt Ingestji**: Proces kompilacji jest droższy (wymaga więcej tokenów) niż proste indeksowanie RAG.
- **Ryzyko "utrwalenia" błędów**: Halucynacja podczas kompilacji może zostać zapisana w Wiki jako fakt.
## Related Concepts
- [[concepts/compounding-knowledge]] - Rezultat skutecznej kompilacji.
- [[concepts/rag-vs-wiki]] - Alternatywne podejście "interpretowane".
## Sources
- [[summaries/karpathy-llm-wiki-breakdown]]
@@ -0,0 +1,37 @@
---
title: "Metapoznanie jako Usługa (Metacognition as a Service)"
type: "concept"
tags: [AI, psychologia, produktywność, loom]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/loom-thinking-tool]]"]
confidence: medium
---
# Metapoznanie jako Usługa (Metacognition as a Service)
## Definition
Wykorzystanie sztucznej inteligencji do monitorowania, analizowania i dostarczania informacji zwrotnej na temat procesów myślowych użytkownika, jego uprzedzeń, preferencji i ewolucji intelektualnej.
## How It Works
AI skanuje całą bazę wiedzy użytkownika (notatki, dzienniki, artykuły) i identyfikuje:
- **Motywy przewodnie**: Tematy, które powracają w różnych kontekstach.
- **Ślepe plamy (Blind Spots)**: Obszary, o których użytkownik nigdy nie pisze lub pytania, których unika.
- **Zmiany w czasie**: Ewolucję definicji i poglądów (np. co myślałem o pracy 2 lata temu vs dziś).
## Benefits
- **Obiektywne lustro**: Pozwala spojrzeć na własne myślenie z dystansem (percepcja głębi).
- **Wykrywanie uprzedzeń**: AI może wskazać, że nasze wnioski opierają się na niezweryfikowanych założeniach.
- **Wsparcie rozwoju**: Sugeruje nowe ścieżki eksploracji w oparciu o luki w wiedzy.
## When To Use
- W głębokiej pracy intelektualnej (badania, pisanie).
- W procesach samorozwoju i coachingu.
- Przy podejmowaniu strategicznych decyzji (jako "adwokat diabła").
## Related Concepts
- [[concepts/idea-collision]] - Wynik aktywnego metapoznania.
- [[concepts/knowledge-compilation]] - Metapoznanie pomaga w lepszej organizacji kompilowanej wiedzy.
## Sources
- [[summaries/loom-thinking-tool]]
@@ -0,0 +1,37 @@
---
title: "Plain-text Productivity"
type: "concept"
tags: [produktywność, metodyka, plain-text]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/one-file-diary]]"]
confidence: high
---
# Plain-text Productivity
## Definition
Metodyka zarządzania czasem, zadaniami i wiedzą oparta wyłącznie na prostych plikach tekstowych (`.txt`, `.md`). Wyklucza skomplikowane systemy bazodanowe na rzecz plików czytelnych dla człowieka i maszyn.
## How It Works
Użytkownik tworzy proste struktury (listy, nagłówki z datami) w edytorze tekstu. Kluczowe jest używanie standardowych formatów, które nie wymagają specjalistycznego oprogramowania i są łatwe do wersjonowania (np. przez Git).
## Key Parameters
- **Przenośność**: Pliki działają na każdym systemie operacyjnym.
- **Długowieczność**: Tekst będzie czytelny za 50 lat.
- **Szybkość**: Brak czasu ładowania aplikacji, natychmiastowe wyszukiwanie.
## When To Use
- W środowiskach technicznych (CLI, serwery).
- Gdy użytkownik chce uniknąć "prokrastynacji narzędziowej" (ciągłego zmieniania apek do notatek).
- Gdy wymagana jest pełna kontrola nad danymi i ich prywatność.
## Risks & Pitfalls
- **Brak automatycznych przypomnień**: System nie wyśle powiadomienia o deadline.
- **Złożoność przy dużych projektach**: Zarządzanie tysiącami linii w jednym pliku może wymagać dyscypliny w tagowaniu/szukaniu.
## Related Concepts
- [[concepts/work-journaling]] - Prowadzenie dziennika jako podzbiór produktywności tekstowej.
## Sources
- [[summaries/one-file-diary]]
@@ -0,0 +1,39 @@
---
title: "Administracja Proaktywna (Proactive Administration)"
type: "concept"
tags: [dba, metodyka, AI, monitoring]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/ai-impact-on-dba]]", "[[summaries/accidental-dba-intro]]"]
confidence: high
---
# Administracja Proaktywna (Proactive Administration)
## Definition
Podejście do zarządzania systemami (szczególnie bazami danych), w którym główny nacisk kładzie się na przewidywanie i zapobieganie problemom, zamiast jedynie reagowania na już zaistniałe awarie.
## How It Works
Wykorzystuje zaawansowany monitoring, progi ostrzegawcze oraz coraz częściej analitykę predykcyjną opartą na AI. Systemy proaktywne analizują trendy (np. wzrost zajętości dysku, fragmentacja indeksów, wzorce obciążenia CPU) i sugerują działania naprawcze (np. dodanie indeksu, rozszerzenie pamięci) przed wystąpieniem kryzysu.
## Key Parameters
- **Czas do awarii (TTF)**: Identyfikacja ryzyk z wyprzedzeniem.
- **Automatyzacja adaptacyjna**: Zdolność systemu do samonaprawy w bezpiecznych granicach.
- **Analityka trendów**: Porównywanie bieżących metryk z profilami historycznymi.
## When To Use
- W systemach o krytycznym znaczeniu biznesowym (High Availability).
- Przy zarządzaniu dużymi flotami serwerów, gdzie manualny monitoring jest niemożliwy.
- W nowoczesnych strukturach DevOps/SRE.
## Risks & Pitfalls
- **Over-monitoring**: Generowanie zbyt dużej liczby alertów (alarm fatigue).
- **Zaufanie do AI**: Ślepe podążanie za predykcjami AI może prowadzić do niepotrzebnych kosztów lub błędnych zmian konfiguracyjnych (patrz: [[concepts/ai-hallucinations]]).
## Related Concepts
- [[concepts/accidental-dba]] - DBA z przypadku często utykają w trybie reaktywnym; administracja proaktywna to ich cel rozwojowy.
- [[entities/tavily]] - Może być wykorzystywany do proaktywnego wyszukiwania rozwiązań dla znanych błędów.
## Sources
- [[summaries/ai-impact-on-dba]]
- [[summaries/accidental-dba-intro]]
+39
View File
@@ -0,0 +1,39 @@
---
title: "RAG vs LLM Wiki"
type: "concept"
tags: [AI, architektura, RAG, wiki]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/karpathy-llm-wiki-breakdown]]"]
confidence: high
---
# RAG vs LLM Wiki
## Definition
Porównanie dwóch paradygmatów wykorzystania LLM do pracy z dokumentami: Retrieval-Augmented Generation (RAG) oraz persistent LLM Wiki.
## How It Works
- **RAG**: Działa w trybie "bezstanowym". Na każde pytanie wyszukuje fragmenty w surowych plikach i składa z nich odpowiedź "ad hoc".
- **Wiki**: Działa w trybie "stanowym". Wiedza jest wstępnie przetworzona (skompilowana) do struktury Wiki, a odpowiedzi są generowane na podstawie tej syntezy.
## Comparison Table
| Cecha | RAG | LLM Wiki |
| :--- | :--- | :--- |
| **Dane** | Surowe dokumenty | Skompilowane strony wiki |
| **Stanowość** | Bezstanowy (każde zapytanie od zera) | Stanowy (wiedza kumuluje się) |
| **Skala** | Miliony dokumentów | 100-500 wybranych źródeł |
| **Koszt** | Tani ingest, drogie zapytania (tokeny) | Drogi ingest, tanie zapytania |
| **Cel** | Wyszukiwanie faktów (Lookup) | Synteza i zrozumienie (Synthesis) |
## When To Use
- **Wybierz RAG**: Gdy masz ogromne, dynamicznie zmieniające się zbiory danych (np. dokumentacja techniczna firmy, akta prawne).
- **Wybierz Wiki**: Gdy pracujesz nad konkretnym tematem badawczym, piszesz książkę lub budujesz osobistą bazę wiedzy (Second Brain).
## Related Concepts
- [[concepts/knowledge-compilation]]
- [[concepts/compounding-knowledge]]
## Sources
- [[summaries/karpathy-llm-wiki-breakdown]]
+34
View File
@@ -0,0 +1,34 @@
---
title: "Software 1.0"
type: "concept"
tags: [programowanie, architektura, historia-it]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/software-2-0]]"]
confidence: high
---
# Software 1.0
## Definition
Tradycyjny stos oprogramowania, w którym programista tworzy kod poprzez pisanie jawnych instrukcji w językach wysokiego poziomu (C++, Python, Java). Każda linijka kodu definiuje konkretne zachowanie systemu w przestrzeni programu.
## How It Works
Programista identyfikuje algorytmy i reguły logiczne potrzebne do rozwiązania problemu, a następnie implementuje je manualnie. Wynikowy kod jest czytelny dla człowieka (przed kompilacją) i oparty na deterministycznych strukturach sterujących (if/else, pętle).
## Key Parameters
- **Jawność**: Każda funkcja i moduł mają zdefiniowaną logikę.
- **Determinism**: System zachowuje się dokładnie tak, jak został zaprogramowany.
- **Struktura**: Hierarchiczna budowa modułów połączonych przez API.
## When To Use
- W problemach o jasnej, matematycznej lub logicznej strukturze.
- W systemach krytycznych wymagających pełnej weryfikowalności kodu.
- W zadaniach, gdzie dane są rzadkie lub nie istnieją.
## Related Concepts
- [[concepts/software-2.0]] - Następca i uzupełnienie Software 1.0.
- [[concepts/knowledge-compilation]] - Proces zamiany kodu 1.0 na binarny vs trening modelu 2.0.
## Sources
- [[summaries/software-2-0]]
+44
View File
@@ -0,0 +1,44 @@
---
title: "Software 2.0"
type: "concept"
tags: [AI, programowanie, machine-learning, karpathy]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/software-2-0]]", "[[summaries/karpathy-llm-wiki-breakdown]]", "[[summaries/how-to-deploy-autoresearch]]"]
confidence: high
---
# Software 2.0
## Definition
Paradygmat programowania, w którym systemy są tworzone nie przez pisanie instrukcji, ale przez optymalizację parametrów (wag) modelu na podstawie zbioru danych i zdefiniowanego celu.
## How It Works
Zamiast budować algorytm, programista 2.0:
1. Zbiera i przygotowuje dane (Dataset).
2. Definiuje architekturę sieci neuronowej (Szkielet).
3. Uruchamia proces optymalizacji (Trening), który automatycznie dobiera wagi tak, aby zminimalizować błąd.
## Key Parameters
- **Wagi (Weights)**: Miliony parametrów tworzących "kod" 2.0.
- **Funkcja celu (Loss Function)**: Definiuje, co model ma osiągnąć.
- **Dane (Dataset)**: Prawdziwe "źródło prawdy" systemu.
## Benefits
- **Wydajność**: Często przewyższa możliwości człowieka w rozpoznawaniu wzorców (obraz, mowa).
- **Adaptacyjność**: Łatwa zmiana zachowania poprzez dodanie nowych danych.
- **Hardware-friendly**: Optymalne dla procesorów graficznych i dedykowanych układów AI.
## Risks & Pitfalls
- **Brak interpretowalności**: Trudno zrozumieć, dlaczego model podjął konkretną decyzję.
- **Ataki adwersarialne**: Podatność na celowo przygotowane, błędne dane wejściowe.
- **Uprzedzenia**: Model kopiuje błędy i uprzedzenia zawarte w danych treningowych.
## Related Concepts
- [[concepts/software-1.0]] - Tradycyjne podejście.
- [[concepts/knowledge-compilation]] - Trening jako forma kompilacji wiedzy.
- [[concepts/autoresearch]] - Automatyzacja tworzenia oprogramowania 2.0.
## Sources
- [[summaries/software-2-0]]
- [[summaries/karpathy-llm-wiki-breakdown]]
+23
View File
@@ -0,0 +1,23 @@
---
title: "val_bpb (Bits Per Byte)"
type: "concept"
tags: [machine-learning, metryka, AI]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/how-to-deploy-autoresearch]]"]
confidence: high
---
# val_bpb (Bits Per Byte)
## Definition
Metryka stosowana w uczeniu maszynowym (szczególnie w modelach językowych), mierząca jak efektywnie model przewiduje dane. Określa średnią liczbę bitów potrzebną do zakodowania jednego bajtu informacji.
## How It Works
Niższa wartość `val_bpb` oznacza, że model lepiej "rozumie" strukturę danych i potrafi je przewidzieć z mniejszą niepewnością. W projekcie [[concepts/autoresearch]] służy jako główny kompas dla agenta AI każda zmiana w kodzie musi prowadzić do obniżenia tej liczby.
## Why It Matters
W przeciwieństwie do innych metryk, `val_bpb` jest niezależna od rozmiaru słownika (vocabulary size) czy tokenizera, co czyni ją idealną do porównywania bardzo różnych architektur modeli i metod treningowych.
## Sources
- [[summaries/how-to-deploy-autoresearch]]
@@ -0,0 +1,39 @@
---
title: "Work Journaling (Dziennik Pracy)"
type: "concept"
tags: [produktywność, inżynieria, metodyka]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/one-file-diary]]", "[[summaries/jak-zbudowalem-agenta-newslettera-n8n]]"]
confidence: high
---
# Work Journaling (Dziennik Pracy)
## Definition
Praktyka rejestrowania działań, decyzji i incydentów w czasie rzeczywistym podczas dnia pracy. Służy jako "zewnętrzna pamięć" inżyniera.
## How It Works
Pracownik zapisuje kluczowe zdarzenia (np. "09:00 - restart serwera X", "10:30 - spotkanie z zespołem Y") w liniowej strukturze. Wpisuje się nie tylko fakty, ale i uzasadnienia decyzji technicznych.
## Key Parameters
- **Zapis chronologiczny**: Liniowy potok zdarzeń.
- **Audytowalność**: Możliwość odtworzenia przebiegu incydentu po fakcie.
- **Kontekst**: Przechowywanie informacji o "dlaczego" coś zostało zrobione.
## When To Use
- Przy pracy z systemami krytycznymi (DBA, SRE).
- Podczas debugowania długotrwałych problemów.
- Jako podstawa do pisania raportów post-mortem lub tygodniowych podsumowań.
## Risks & Pitfalls
- **Przerwy w logowaniu**: Zapominanie o wpisach podczas stresujących awarii (kluczowe, by pisać "w trakcie").
- **Szum informacyjny**: Zapisywanie zbyt wielu nieistotnych szczegółów.
## Related Concepts
- [[concepts/plain-text-productivity]] - Najczęstszy sposób realizacji dziennika.
- [[concepts/human-in-the-loop]] - Dziennik może być miejscem zapisu interakcji z agentami AI.
## Sources
- [[summaries/one-file-diary]]
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]
+27
View File
@@ -0,0 +1,27 @@
---
title: "n8n"
type: "entity"
tags: [automatyzacja, no-code, workflow]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/jak-zbudowalem-agenta-newslettera-n8n]]"]
confidence: high
---
# n8n
## Overview
Narzędzie typu "workflow automation" (automatyzacja przepływu pracy) o otwartym kodzie źródłowym, pozwalające na łączenie różnych usług i aplikacji bez konieczności pisania dużych ilości kodu.
## Characteristics
- **Architektura**: Węzłowa (node-based), wizualny edytor workflow.
- **Dostępność**: Self-hosted lub SaaS.
- **Możliwości AI**: Natywne węzły dla agentów AI, integracja z modelami językowymi (LangChain).
## Common Strategies
- **HITL Automation**: Implementacja modelu [[concepts/human-in-the-loop]].
- **Batch Processing**: Użycie węzła `SplitInBatches` do przetwarzania dużych zbiorów danych.
## Related Entities
- [[entities/tavily]] - Częsty partner w workflow badawczych.
- **OpenRouter** - Brama do modeli AI wykorzystywana w n8n.
+27
View File
@@ -0,0 +1,27 @@
---
title: "SQL Server"
type: "entity"
tags: [bazy-danych, microsoft, rdbms]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/accidental-dba-intro]]", "[[summaries/one-file-diary]]"]
confidence: high
---
# SQL Server
## Overview
Relacyjny system zarządzania bazami danych (RDBMS) rozwijany przez firmę Microsoft. Kluczowy element stosu technologicznego w wielu przedsiębiorstwach (Enterprise).
## Characteristics
- **Silnik T-SQL**: Rozszerzenie standardu SQL o procedury, funkcje i zaawansowaną logikę.
- **Narzędzia**: SSMS (SQL Server Management Studio), Azure Data Studio.
- **Mechanizmy**: Indeksowanie (Clustered/Non-clustered), plany wykonania (Execution Plans), zarządzanie transakcjami.
## Common Strategies
- **Indeksowanie**: Optymalizacja wydajności zapytań (często wspominana jako ratunek w sytuacjach kryzysowych).
- **Backup & Restore**: Fundament bezpieczeństwa danych (kluczowy punkt dla [[concepts/accidental-dba]]).
## Related Entities
- **Microsoft Azure** - Chmurowa platforma dla SQL Database.
- [[entities/n8n]] - Może integrować się z SQL Server do automatyzacji zadań administracyjnych.
+25
View File
@@ -0,0 +1,25 @@
---
title: "Tavily"
type: "entity"
tags: [AI, research, search-engine, API]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/jak-zbudowalem-agenta-newslettera-n8n]]"]
confidence: high
---
# Tavily
## Overview
Wyspecjalizowany silnik wyszukiwania (Search Engine) zaprojektowany specjalnie dla agentów AI i LLM.
## Characteristics
- **Optymalizacja LLM**: Zwraca dane przygotowane do bezpośredniego przetworzenia przez modele (streszczenia, surowa treść).
- **Filtrowanie**: Zaawansowane opcje ograniczania wyników do konkretnych ram czasowych (np. `past_week`).
- **Raw Content**: Możliwość pobrania pełnego tekstu strony do głębokiej analizy.
## Common Strategies
- **AI Research Pipeline**: Wykorzystanie jako źródła danych w systemach RAG lub agentach newsletterowych.
## Related Entities
- [[entities/n8n]] - Często używany jako integrator dla API Tavily.
+37
View File
@@ -0,0 +1,37 @@
# 12 Ulubionych Problemów Feynmana
Poniższa lista zawiera kluczowe pytania i obszary zainteresowań, które są "testowane" przy każdym nowym źródle wiedzy. Cel: Znalezienie nowych perspektyw, połączeń lub cząstkowych rozwiązań dla tych długoterminowych wyzwań.
## 1. Zarządzanie sobą w czasie
- **Notatki i połączenia**:
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]: Automatyzacja powtarzalnych zadań pozwala zaoszczędzić godziny pracy tygodniowo.
- [[summaries/one-file-diary]]: System jednego pliku tekstowego minimalizuje narzut narzędziowy.
- [[summaries/google-nanobanana-workflow]]: Skrócenie czasu tworzenia zasobów wizualnych o 90% dzięki [[concepts/ai-pipelines]].
- [[summaries/karpathy-llm-wiki-breakdown]]: Wykorzystanie LLM do "księgowości wiedzy" (bookkeeping).
- [[summaries/how-to-deploy-autoresearch]]: Automatyzacja pętli badawczej agent pracuje, gdy człowiek śpi.
## 2. Zarządzanie bazami danych
- **Notatki i połączenia**:
- [[summaries/accidental-dba-intro]]: Przejście od reaktywnego "gaszenia pożarów" do [[concepts/proactive-administration]].
- [[entities/sql-server]]: Główny ekosystem techniczny dla zadań administracyjnych.
- [[summaries/ai-impact-on-dba]]: AI jako narzędzie wspierające DBA w monitoringu i optymalizacji.
- [[summaries/software-2-0]]: Koncepcja "Learned Index Structures" zastąpienie tradycyjnych struktur danych (jak B-Tree) wyuczonymi modelami sieci neuronowych dla większej wydajności.
## 3. Generatywna Sztuczna Inteligencja
- **Notatki i połączenia**:
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]: Wykorzystanie LLM do planowania i pisania treści.
- [[summaries/ai-impact-on-dba]]: Ryzyko [[concepts/ai-hallucinations]] w krytycznych systemach.
- [[summaries/google-nanobanana-workflow]]: Gemini 2.5 Flash jako narzędzie do spójnej generacji obrazów.
- [[summaries/software-2-0]]: Definicja sieci neuronowych jako nowej formy oprogramowania ([[concepts/software-2-0]]).
- [[summaries/loom-thinking-tool]]: Wykorzystanie AI do [[concepts/metacognition-as-a-service]] i [[concepts/idea-collision]].
## 4. Automatyzacja i Agenci AI
- **Notatki i połączenia**:
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]: Workflow n8n jako praktyczny agent redakcyjny.
- [[summaries/ai-impact-on-dba]]: Kierunek ku autonomicznym bazom danych.
- [[summaries/google-nanobanana-workflow]]: [[concepts/ai-pipelines]] integrujące wiele modeli.
- [[summaries/karpathy-llm-wiki-breakdown]]: Model LLM jako "programista" i "maintainer" bazy wiedzy.
- [[summaries/how-to-deploy-autoresearch]]: [[concepts/autoresearch]] najwyższy stopień autonomii agenta AI w procesie badawczym.
---
*Miejsce na kolejne problemy (5-12)...*
+30
View File
@@ -0,0 +1,30 @@
# Wiki Index
Główny katalog wiedzy, podzielony na obszary tematyczne dla łatwiejszej nawigacji.
## Obszary Tematyczne
- [[indices/ai-software]] — **AI & Software 2.0**: LLM, Autoresearch, Software 2.0.
- [[indices/km-productivity]] — **Wiedza i Produktywność**: PKM, Metodyki pracy, Feynman Problems.
- [[indices/dba-sql]] — **Bazy Danych**: Administracja SQL Server, rola DBA w dobie AI.
- [[indices/automation-workflows]] — **Automatyzacja**: n8n, workflowy, rurociągi danych.
---
## Indeksy Typów (Pełna Lista)
Dla osób szukających konkretnego formatu pliku.
### [Podsumowania Źródeł (Summaries)](indices/summaries)
*Zestawienie wszystkich przeczytanych artykułów i obejrzanych materiałów.*
### [Koncepcje (Concepts)](indices/concepts)
*Słownik terminów i modeli mentalnych.*
### [Podmioty (Entities)](indices/entities)
*Katalog narzędzi, technologii i organizacji.*
---
## Log i Administracja
- [[log]] — Historia zmian w Wiki.
- [[feynman_problems]] — Centralne śledzenie problemów.
- [[journal/index]] — Dziennik badawczy.
+21
View File
@@ -0,0 +1,21 @@
# AI & Software 2.0
Zbiór zasobów dotyczących nowej paradygmatu programowania, systemów opartych na LLM oraz autonomicznego researchu.
## Podsumowania
- [[summaries/karpathy-llm-wiki-breakdown]] — Analiza LLM Wiki Karpathy'ego.
- [[summaries/how-to-deploy-autoresearch]] — Przewodnik po Autoresearch.
- [[summaries/software-2-0]] — Manifest Software 2.0.
## Koncepcje
- [[concepts/software-1-0]] — Tradycyjne programowanie (instrukcje).
- [[concepts/software-2-0]] — Nowe programowanie (dane + optymalizacja).
- [[concepts/autoresearch]] — Autonomiczne badania nad AI prowadzone przez agentów.
- [[concepts/ai-pipelines]] — Zautomatyzowane rurociągi przetwarzania AI.
- [[concepts/ai-hallucinations]] — Ryzyko błędów w modelach AI.
- [[concepts/rag-vs-wiki]] — Porównanie podejścia stanowego i bezstanowego.
- [[concepts/human-in-the-loop]] — Model współpracy człowieka z AI.
- [[concepts/val-bpb]] — Metryka jakości modelu (Bits Per Byte).
## Podmioty
- [[entities/tavily]] — Silnik researchu dla AI.
@@ -0,0 +1,16 @@
# Automatyzacja i Workflow
Narzędzia i strategie automatyzacji powtarzalnych zadań oraz łączenia różnych systemów.
## Podsumowania
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]] — Automatyzacja newslettera AI (Amit Kumar).
- [[summaries/google-nanobanana-workflow]] — Workflow Nanobanana (Rahul Gaur).
## Koncepcje
- [[concepts/ai-pipelines]] — Zautomatyzowane rurociągi przetwarzania AI.
## Podmioty
- [[entities/n8n]] — Narzędzie do automatyzacji workflow.
## Syntezy
- [[syntheses/porownanie-strategii-automatyzacji-ai]] — Zestawienie metodologii (n8n, Nanobanana, LLM Wiki).
+20
View File
@@ -0,0 +1,20 @@
# Wszystkie Koncepcje
Słownik terminów i modeli mentalnych zgromadzonych w wiki.
- [[concepts/human-in-the-loop]]
- [[concepts/accidental-dba]]
- [[concepts/plain-text-productivity]]
- [[concepts/work-journaling]]
- [[concepts/proactive-administration]]
- [[concepts/ai-hallucinations]]
- [[concepts/ai-pipelines]]
- [[concepts/knowledge-compilation]]
- [[concepts/compounding-knowledge]]
- [[concepts/rag-vs-wiki]]
- [[concepts/autoresearch]]
- [[concepts/val-bpb]]
- [[concepts/software-1-0]]
- [[concepts/software-2-0]]
- [[concepts/idea-collision]]
- [[concepts/metacognition-as-a-service]]
+14
View File
@@ -0,0 +1,14 @@
# Administracja Bazami Danych (DBA)
Zasoby dotyczące tradycyjnej roli DBA oraz jej ewolucji w dobie AI.
## Podsumowania
- [[summaries/accidental-dba-intro]] — Wprowadzenie do roli Accidental DBA.
- [[summaries/ai-impact-on-dba]] — Wpływ AI na rolę DBA (Craig Mullins).
## Koncepcje
- [[concepts/accidental-dba]] — Syndrom przypadkowego administratora baz danych.
- [[concepts/proactive-administration]] — Administracja zapobiegająca awariom.
## Podmioty
- [[entities/sql-server]] — System bazodanowy Microsoft.
+7
View File
@@ -0,0 +1,7 @@
# Wszystkie Podmioty
Katalog narzędzi, technologii i organizacji.
- [[entities/n8n]]
- [[entities/tavily]]
- [[entities/sql-server]]
@@ -0,0 +1,20 @@
# Zarządzanie Wiedzą i Produktywność
Metodyki gromadzenia wiedzy, budowania własnego PKM (Personal Knowledge Management) oraz narzędzia wspierające myślenie.
## Fundamenty
- [[feynman_problems]] — 12 Ulubionych Problemów Feynmana.
## Podsumowania
- [[summaries/one-file-diary]] — System "One File Diary" (Jeff Huang).
- [[summaries/google-nanobanana-workflow]] — Workflow Nanobanana (Rahul Gaur).
- [[summaries/loom-thinking-tool]] — Narzędzie do kolizji myśli (Klinstar).
- [[summaries/free-blog-seo-strategy]] — Strategia SEO dla darmowego bloga.
## Koncepcje
- [[concepts/plain-text-productivity]] — Produktywność oparta na plikach tekstowych.
- [[concepts/work-journaling]] — Metodyka prowadzenia dziennika pracy.
- [[concepts/knowledge-compilation]] — "Kompilowanie" surowej wiedzy do Wiki.
- [[concepts/compounding-knowledge]] — Wiedza, która staje się gęstsza z czasem.
- [[concepts/idea-collision]] — Zderzanie pomysłów w celu generowania innowacji.
- [[concepts/metacognition-as-a-service]] — AI jako wsparcie analizy własnych procesów myślowych.
+14
View File
@@ -0,0 +1,14 @@
# Wszystkie Podsumowania
Pełna lista streszczeń materiałów źródłowych.
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]
- [[summaries/one-file-diary]]
- [[summaries/accidental-dba-intro]]
- [[summaries/ai-impact-on-dba]]
- [[summaries/google-nanobanana-workflow]]
- [[summaries/karpathy-llm-wiki-breakdown]]
- [[summaries/how-to-deploy-autoresearch]]
- [[summaries/software-2-0]]
- [[summaries/loom-thinking-tool]]
- [[summaries/free-blog-seo-strategy]]
+29
View File
@@ -0,0 +1,29 @@
# Wiki Log
Chronologiczny zapis operacji na wiki.
## [2026-05-14] Ingest | Advanced AI & Knowledge Management
- Przetworzono `Jak wdrożyć autoresearch_.md`: dodano koncepcję `[[autoresearch]]` i metrykę `[[val-bpb]]`.
- Przetworzono `Software 2.0.md`: dodano koncepcje `[[software-1-0]]` i `[[software-2-0]]`.
- Przetworzono `Zbudowałem narzędzie...`: dodano koncepcje `[[idea-collision]]` i `[[metacognition-as-a-service]]`.
- Przetworzono `Jak utworzyć bloga za darmo.pdf`: dodano summary `[[free-blog-seo-strategy]]`.
- Wykonano Feynman Check dla wszystkich nowych źródeł (Problemy #1, #2, #3, #4).
- Zaktualizowano indeks.
## [2026-05-14] Synteza | Strategie Automatyzacji AI
- Utworzono stronę syntezy: `[[syntheses/porownanie-strategii-automatyzacji-ai]]`.
## [2026-05-14] Ingest | Karpathy LLM Wiki Breakdown
- Przetworzono artykuł o LLM Wiki.
## [2026-05-14] Ingest | AI impact & Nanobanana Workflow
- Przetworzono artykuły o wpływie AI na DBA i workflow Nanobanana.
## [2026-05-14] Ingest | One File Diary & Accidental DBA
- Przetworzono artykuły o One File Diary i Accidental DBA.
## [2026-05-14] Refaktoryzacja Schematu
- Zaktualizowano `GEMINI.md` i strukturę katalogów.
## [2026-05-14] Inicjalizacja
- Utworzono fundamenty Wiki LLM.
@@ -0,0 +1,28 @@
---
title: "Zostałem DBA przez przypadek (Accidental DBA Intro)"
type: "summary"
tags: [dba, accidental-dba, bazy-danych, kariera, edukacja]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/wprowadzenie-accidental-dba.md"]
confidence: high
---
# Zostałem DBA przez przypadek
Artykuł wprowadzający na blogu dedykowanym "przypadkowym administratorom baz danych" (Accidental DBAs). Autor opisuje zjawisko przejmowania odpowiedzialności za bazy danych przez osoby niebędące specjalistami (np. deweloperów lub adminów systemowych) w sytuacjach kryzysowych.
## Key Points
- **Syndrom Przypadkowego Administratora**: Sytuacja, w której pracownik (często deweloper) staje się "strażnikiem danych" z konieczności, bez formalnego przygotowania.
- **Przejście od reaktywności do proaktywności**: Celem jest zmiana stylu pracy z "gaszenia pożarów" na świadome zarządzanie wydajnością, bezpieczeństwem i strategią.
- **Kluczowe obszary nauki**: Backup i recovery, optymalizacja zapytań, automatyzacja monitoringu oraz bezpieczeństwo danych.
- **Wspólnota**: Podkreślenie roli dzielenia się doświadczeniami i wspólnego rozwiązywania problemów technicznych.
## Relevant Concepts
- [[concepts/accidental-dba]] - Definicja i charakterystyka roli.
- [[concepts/proactive-administration]] - Model zarządzania systemami zapobiegający awariom.
## Source Metadata
- **Type**: Blog Post (Intro)
- **Author**: Paweł Domański (implied by context/project)
- **Focus**: SQL Server / Database Administration
@@ -0,0 +1,31 @@
---
title: "Wpływ AI na administrację bazami danych"
type: "summary"
tags: [dba, AI, automatyzacja, mssql, zarządzanie-bazami-danych, bezpieczeństwo]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/Wpływ AI na administrację bazami danych - TechChannel.md"]
confidence: high
---
# Wpływ AI na administrację bazami danych
Artykuł Craiga Mullins'a analizuje transformację roli Administratora Baz Danych (DBA) w dobie sztucznej inteligencji. Autor argumentuje, że AI nie zastąpi DBA, ale znacząco zmieni charakter ich pracy, przesuwając fokus z zadań rutynowych na strategiczne.
## Key Points
- **Inteligentna Automatyzacja**: AI wykracza poza proste skrypty, oferując automatyzację adaptacyjną, która uczy się na podstawie kontekstu.
- **Analityka Predykcyjna**: Wykorzystanie AI do przewidywania awarii i wąskich gardeł wydajnościowych zanim wystąpią (proaktywność).
- **Optymalizacja Zapytań**: Ewolucja od optymalizatorów kosztowych do modeli wyuczonych (AI-backed optimizers).
- **Bezpieczeństwo**: AI jako szybszy mechanizm wykrywania anomalii i wzorców ataków cybernetycznych.
- **Wyzwania**: Ryzyko halucynacji AI, kwestie etyczne oraz konieczność "upskillingu" DBA w obszarze uczenia maszynowego i chmury.
## Relevant Concepts
- [[concepts/proactive-administration]] - AI jako główne narzędzie administracji proaktywnej.
- [[concepts/accidental-dba]] - AI może obniżyć próg wejścia dla przypadkowych administratorów, ale wymaga nadzoru eksperckiego.
- [[concepts/ai-hallucinations]] - Ryzyko błędnych rekomendacji generowanych przez modele AI.
## Source Metadata
- **Type**: Artykuł techniczny
- **Author**: Craig Mullins
- **Publication**: TechChannel
- **Key Themes**: DBA Evolution, Intelligent Automation, Database Performance
@@ -0,0 +1,23 @@
---
title: "Jak utworzyć bloga za darmo: Strategia SEO"
type: "summary"
tags: [SEO, blog, marketing, słowa-kluczowe]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/Jak utworzyć bloga za darmo.pdf"]
confidence: high
---
# Jak utworzyć bloga za darmo: Strategia SEO
Dokument zawiera zestawienie słów kluczowych oraz rekomendacje artykułów dla nowo powstającego bloga, skupiając się na darmowych platformach i optymalizacji pod wyszukiwarki.
## Key Points
- **Analiza słów kluczowych**: Identyfikacja fraz o wysokim wolumenie i niskiej konkurencji (np. "blogspot", "blogger").
- **Długi ogon (Long-tail)**: Wykorzystanie fraz instruktażowych (np. "jak założyć blog za darmo na wordpress").
- **Struktura treści**: Rekomendacje dla artykułów filarowych (pillar content) oraz wspierających (supporting content).
- **Intencja wyszukiwania**: Tworzenie treści bezpośrednio odpowiadających na konkretne pytania początkujących użytkowników.
## Source Metadata
- **Type**: Dokument strategiczny / SEO Plan
- **Focus**: Content Marketing, SEO
@@ -0,0 +1,31 @@
---
title: "Workflow Google Nanobanana: Od pomysłu do 10 zasobów"
type: "summary"
tags: [produktywność, AI, gemini, n8n, content-creation, automatyzacja]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/Workflow Google Nanobanana Jak jeden pomysł staje się 10 zasobami w 11 minut autor Rahul Gaur Napisz katalizator Grudzień 2025 Średni.md"]
confidence: high
---
# Workflow Google Nanobanana
Artykuł Rahula Gaura opisuje system "Nanobanana" wysokowydajny proces tworzenia treści wizualnych przy użyciu modelu Google Gemini 2.5 Flash i automatyzacji n8n. System pozwala na przekształcenie jednego artykułu w dziesiątki unikalnych grafik w kilka minut.
## Key Points
- **Nanobanana**: Nazwa społecznościowa dla workflow opartego na modelu Gemini 2.5 Flash, wyróżniającego się szybkością i niskim kosztem.
- **Problem "AI Slop"**: Odbiorcy w 2025 roku odrzucają generyczne zdjęcia stockowe i niskiej jakości grafiki AI. Rozwiązaniem jest "AI z gustem".
- **Spójność wizualna**: Dzięki konwersacyjnemu charakterowi Gemini, użytkownik może modyfikować istniejące obrazy (np. "zmień oświetlenie", "zrób pionowo") zachowując tożsamość wizualną.
- **Workflow n8n**: Automatyzacja procesu (Telegram bot -> Wzbogacanie promptu przez LLM -> Generowanie przez Gemini API -> Zapis na Google Drive).
- **Zasada "Nasiona i Plonów"**: Pisanie artykułu z jedną metaforą wizualną w głowie, która następnie jest przetwarzana na wiele formatów dla różnych platform (Medium, Pinterest, LinkedIn).
## Relevant Concepts
- [[concepts/ai-pipelines]] - Budowanie rurociągów zamiast pojedynczych promptów.
- [[concepts/plain-text-productivity]] - Workflow zaczyna się od prostego promptu tekstowego (np. na Telegramie).
- [[entities/n8n]] - Kluczowy integrator dla workflow Nanobanana.
## Source Metadata
- **Type**: Artykuł (Medium)
- **Author**: Rahul Gaur
- **Date**: Grudzień 2025
- **Focus**: Content Creation, AI Automation, Visual Identity
@@ -0,0 +1,36 @@
---
title: "Jak wdrożyć Autoresearch: Przewodnik po autonomicznym badaczu AI"
type: "summary"
tags: [karpathy, autoresearch, AI, automatyzacja, machine-learning, claude-code, uv]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/Jak wdrożyć autoresearch_.md"]
confidence: high
---
# Jak wdrożyć Autoresearch
Artykuł (bazujący na wątku z X/Twitter) opisuje proces wdrażania projektu "Autoresearch" autorstwa Andreja Karpathy'ego. System ten pozwala na pełną automatyzację procesu trenowania i optymalizacji modeli językowych (LLM) poprzez delegowanie roli badacza do agenta AI (np. Claude Code).
## Key Points
- **Automatyzacja pętli badawczej**: Agent AI przejmuje nudne zadania (zmiana parametrów, uruchamianie testów, analiza wyników), wykonując ok. 100 eksperymentów w ciągu jednej nocy.
- **Mechanizm działania**:
1. Agent czyta meta-instrukcje z `program.md`.
2. Modyfikuje kod treningowy `train.py`.
3. Uruchamia 5-minutowy test na GPU.
4. Mierzy wynik `val_bpb` (Bits Per Byte).
5. Zachowuje zmiany (git commit), jeśli wynik się poprawił, lub odrzuca je w przypadku porażki.
- **Meta-programowanie**: Rola człowieka przesuwa się z prowadzenia eksperymentów na "programowanie organizacji badawczej" poprzez doskonalenie pliku `program.md`.
- **Narzędzia**: `uv` (zarządzanie Pythonem), `Claude Code` lub `Cursor` (mózg eksperymentu), `git` (zarządzanie stanem).
## Relevant Concepts
- [[concepts/autoresearch]] - Autonomiczne badania nad AI.
- [[concepts/ai-pipelines]] - Rozszerzenie rurociągów o pętlę sprzężenia zwrotnego (feedback loop).
- [[concepts/val-bpb]] - Metryka jakości modelu.
- [[concepts/compounding-knowledge]] - Każdy udany eksperyment to trwały postęp w "kodzie źródłowym" modelu.
## Source Metadata
- **Type**: Przewodnik / Tutorial
- **Author**: @hooeem (na podstawie projektu Andreja Karpathy'ego)
- **Repozytorium**: https://github.com/karpathy/autoresearch
- **Key Themes**: Autonomous Research, LLM Optimization, AI Agents
@@ -0,0 +1,30 @@
---
title: "Jak zbudowałem agenta newslettera AI z pomocą n8n"
type: "summary"
tags: [n8n, AI, automatyzacja, newsletter, Tavily, OpenRouter]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/Jak zbudowałem agenta newslettera AI z pomocą n8n (to oszczędza mi godziny co tydzień) autor Amit Kumar Średni.md"]
confidence: high
---
# Jak zbudowałem agenta newslettera AI z pomocą n8n
Artykuł autorstwa Amita Kumara opisujący proces budowy w pełni zautomatyzowanego workflow do tworzenia newsletterów technicznych przy użyciu n8n i agentów AI.
## Key Points
- **Problem**: Tradycyjne tworzenie newslettera jest czasochłonne (research, pisanie, formatowanie, spójność).
- **Rozwiązanie**: System [[concepts/human-in-the-loop]], gdzie AI wykonuje 90% pracy (research, szkic, formatowanie HTML), a człowiek pełni rolę redaktora naczelnego.
- **Efekt**: Oszczędność godzin pracy tygodniowo i utrzymanie wysokiej spójności publikacji.
- **Architektura**: 10-krokowy workflow obejmujący trigger, research (Tavily), planowanie (OpenRouter), pisanie, agregację i edycję.
## Relevant Concepts
- [[concepts/human-in-the-loop]] - Model współpracy człowieka z AI.
- [[entities/n8n]] - Narzędzie automatyzacji.
- [[entities/tavily]] - Silnik researchu.
## Source Metadata
- **Type**: Artykuł (Medium)
- **Author**: Amit Kumar
- **Date**: 2025-08-23
- **URL**: https://medium.com/@amitXD/how-i-built-an-ai-newsletter-agent-with-n8n-c9e4eb252122
@@ -0,0 +1,31 @@
---
title: "Andrej Karpathys LLM Wiki: Create your own knowledge base"
type: "summary"
tags: [karpathy, llm-wiki, knowledge-management, AI, obsidian, RAG]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/Andrej Karpathys LLM Wiki_ Create your own knowledge base.md"]
confidence: high
---
# Andrej Karpathys LLM Wiki: Create your own knowledge base
Artykuł Urvila Joshiego szczegółowo analizuje koncepcję "LLM Wiki" zaproponowaną przez Andreja Karpathy'ego. Tekst wyjaśnia, dlaczego tradycyjne podejście RAG (Retrieval-Augmented Generation) jest niewystarczające do głębokiej syntezy wiedzy i jak budowa trwałej, "skompilowanej" bazy wiedzy rozwiązuje ten problem.
## Key Points
- **Kompilacja wiedzy**: Surowe źródła to "kod źródłowy", a Wiki to "plik binarny" zoptymalizowany pod kątem szybkości i gęstości informacji.
- **Trwałość i kumulacja**: Wiki to artefakt, który staje się bogatszy z każdym nowym źródłem. LLM aktualizuje istniejące strony, zamiast tworzyć izolowane fragmenty.
- **Architektura 3-warstwowa**: Raw Sources (niezmienne), Wiki (zarządzane przez LLM), Schema (zasady postępowania).
- **RAG vs Wiki**: RAG jest lepszy dla milionów dokumentów i wyszukiwania faktów; Wiki jest lepsza dla mniejszych, wyselekcjonowanych zbiorów (~100-500 źródeł), gdzie kluczowa jest synteza i powiązania.
- **Księgowość wiedzy**: LLM przejmuje nudne zadania (linkowanie, aktualizacja indeksów, sprawdzanie spójności), co zapobiega porzucaniu bazy przez ludzi.
## Relevant Concepts
- [[concepts/knowledge-compilation]] - Koncepcja "kompilowania" źródeł do formy syntetycznej.
- [[concepts/compounding-knowledge]] - Budowanie wiedzy, która staje się gęstsza z czasem.
- [[concepts/rag-vs-wiki]] - Porównanie metodologii zarządzania wiedzą z AI.
## Source Metadata
- **Type**: Artykuł / Analiza
- **Author**: Urvil Joshi (na podstawie wpisów Andreja Karpathy'ego)
- **Date**: 2026-04-20
- **URL**: https://medium.com/@urvvil08/andrej-karpathys-llm-wiki-create-your-own-knowledge-base-8779014accd5
@@ -0,0 +1,32 @@
---
title: "Loom: Narzędzie, które myśli razem z Tobą"
type: "summary"
tags: [knowledge-management, AI, kreatywność, metapoznanie, loom, obsidian]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/Zbudowałem narzędzie, które myśli razem z tobą. Oto dlaczego aplikacje do robienia notatek rozwiązują niewłaściwy problem..md"]
confidence: high
---
# Loom: Myślenie ponad zbieranie notatek
Artykuł autorstwa Klinstara opisuje narzędzie "Loom", które rzuca wyzwanie tradycyjnym aplikacjom do robienia notatek (Notion, Obsidian). Autor twierdzi, że branża produktywności skupia się na niewłaściwym problemie: przechwytywaniu informacji, zamiast na ich **kolizji** i **syntezie**.
## Key Points
- **Problem "Biblioteki bez Bibliotekarza"**: Tradycyjne notatki są martwe gromadzimy je, ale rzadko łączymy w nowe idee. Ciężar poznawczy łączenia faktów spoczywa w całości na człowieku.
- **Kreatywność jako Kolizja**: Przełomy twórcze wynikają z łączenia idei z odległych dziedzin. System Loom automatyzuje ten proces.
- **Trzy silniki AI w Loom**:
- **Kolizja (Collision)**: Wybiera losowe notatki i szuka między nimi głębokich struktur wspólnych (serendipity na żądanie).
- **Rozpoznawanie wzorców (Pattern Recognition)**: Skanuje całą bazę w poszukiwaniu powracających motywów i "ślepych plam" w myśleniu użytkownika.
- **Głębia Sokratejska (Socratic Deepening)**: AI zadaje trudne pytania, podważając założenia użytkownika i zmuszając do głębszej analizy.
- **Ewolucja Umysłu**: System śledzi wersje notatek, pozwalając zaobserwować, jak zmieniało się nasze rozumienie danego pojęcia w czasie.
## Relevant Concepts
- [[concepts/idea-collision]] - Zderzanie odległych pomysłów w celu generowania innowacji.
- [[concepts/metacognition-as-a-service]] - Wykorzystanie AI do analizy własnych procesów myślowych.
- [[concepts/compounding-knowledge]] - Loom to narzędzie techniczne realizujące ideę kumulacji wiedzy.
## Source Metadata
- **Type**: Artykuł / Case Study produktu
- **Author**: Klinstar
- **Key Themes**: Knowledge Management, Cognitive Infrastructure, Creative Collision
@@ -0,0 +1,29 @@
---
title: "Jeden plik tekstowy jako dziennik pracy (One File System)"
type: "summary"
tags: [produktywność, time-management, plain-text, worklog, obsidian, vscode]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/One_file_diary.md"]
confidence: high
---
# Jeden plik tekstowy jako dziennik pracy
Artykuł opisuje minimalistyczne podejście do zarządzania czasem i zadaniami oparte na jednym, rosnącym pliku tekstowym (`.txt` lub `.md`), który służy jako jedyne źródło prawdy dla codziennych operacji.
## Key Points
- **Minimalizm**: Jeden plik eliminuje narzut związany z przełączaniem się między narzędziami.
- **Append-only**: Dane są dopisywane na końcu, chronologia jest ważniejsza niż struktura. Brak usuwania starych wpisów zapewnia pełną historię pracy.
- **Przeszukiwalność**: Błyskawiczne wyszukiwanie za pomocą standardowych narzędzi (grep, search).
- **Zastosowanie**: Idealne dla inżynierów (DBA, DevOps, Dev), którzy pracują nad incydentami i potrzebują audytowalnego logu działań.
- **Narzędzia**: Polecane narzędzia to Obsidian, VS Code, a nawet prosty Notatnik czy Org-mode (Emacs).
## Relevant Concepts
- [[concepts/work-journaling]] - Metodyka prowadzenia dziennika pracy.
- [[concepts/plain-text-productivity]] - Produktywność oparta na plikach tekstowych.
## Source Metadata
- **Type**: Artykuł / Poradnik
- **Source Link**: https://jeffhuang.com/productivity_text_file/
- **Key Figure**: Jeff Huang
+37
View File
@@ -0,0 +1,37 @@
---
title: "Software 2.0: Nowy Paradygmat Programowania"
type: "summary"
tags: [karpathy, software-2.0, AI, machine-learning, programowanie, architektura]
created: 2026-05-14
updated: 2026-05-14
sources: ["raw/articles/Software 2.0.md"]
confidence: high
---
# Software 2.0
Przełomowy esej Andreja Karpathy'ego definiujący przejście od tradycyjnego oprogramowania (Software 1.0) do systemów opartych na sieciach neuronowych (Software 2.0). Autor argumentuje, że sieci neuronowe nie są tylko klasyfikatorem, ale fundamentalnie nowym sposobem pisania oprogramowania.
## Key Points
- **Software 1.0 vs 2.0**:
- **1.0**: Kod pisany przez ludzi linia po linii (np. C++, Python). Jawne instrukcje.
- **2.0**: Kod pisany przez optymalizację (trening) na podstawie danych i celu. Abstrakcyjne wagi sieci neuronowej.
- **Kompilacja**: W świecie 2.0 proces treningu jest odpowiednikiem kompilacji. Kodem źródłowym są dane i architektura modelu.
- **Zalety 2.0**:
- Jednorodność obliczeniowa (mnożenie macierzy + ReLU).
- Łatwość implementacji sprzętowej (ASIC).
- Stały czas wykonania i przewidywalne zużycie pamięci.
- Elastyczność (możliwość handlowania dokładnością za szybkość poprzez zmianę rozmiaru sieci).
- **Wyzwania**: Brak interpretowalności ("black box"), nieintuicyjne błędy (ataki adwersarialne), uprzedzenia w danych.
- **Nowe oprzyrządowanie**: Potrzeba nowych "IDE 2.0" skupionych na kuratorstwie danych, etykietowaniu i wizualizacji niepewności modelu.
## Relevant Concepts
- [[concepts/software-1.0]] - Tradycyjne programowanie.
- [[concepts/software-2.0]] - Programowanie przez dane i optymalizację.
- [[concepts/knowledge-compilation]] - Bezpośrednia analogia Karpathy'ego: trening jako kompilacja.
## Source Metadata
- **Type**: Esej / Manifest
- **Author**: Andrej Karpathy
- **Published**: 2017-11-11
- **Key Themes**: Programming Evolution, Neural Networks, AI Infrastructure
@@ -0,0 +1,51 @@
---
title: "Porównanie strategii automatyzacji researchu i tworzenia treści"
type: "synthesis"
tags: [automatyzacja, AI, n8n, newsletter, content-creation, llm-wiki]
created: 2026-05-14
updated: 2026-05-14
sources: ["[[summaries/jak-zbudowalem-agenta-newslettera-n8n]]", "[[summaries/google-nanobanana-workflow]]", "[[summaries/karpathy-llm-wiki-breakdown]]"]
confidence: high
---
# Porównanie strategii automatyzacji researchu i tworzenia treści
Niniejsza synteza zestawia trzy kluczowe podejścia do wykorzystania agentów AI i automatyzacji w procesach pozyskiwania wiedzy i produkcji treści, zidentyfikowane w dotychczasowych analizach.
## Comparison
| Cecha | Agent Newslettera (n8n) | Workflow Nanobanana | LLM Wiki Pattern |
| :--- | :--- | :--- | :--- |
| **Główny cel** | Produkcja cyklicznego tekstu (newsletter) | Produkcja masowa grafik/zasobów wizualnych | Budowa trwałej bazy wiedzy (Second Brain) |
| **Kluczowe narzędzia** | n8n, Tavily, OpenRouter, Gmail | n8n, Gemini 2.5 Flash, Telegram | LLM (np. Gemini/Claude), Obsidian |
| **Model pracy** | [[concepts/human-in-the-loop]] (90% AI) | [[concepts/ai-pipelines]] (Automatyczny rurociąg) | [[concepts/knowledge-compilation]] (Kompilacja) |
| **Paliwo informacyjne** | API Research (Tavily) | Prompt użytkownika / Metafory wizualne | Niezmienne źródła (`raw/`) |
| **Wynik końcowy** | Szkic w Gmailu | Galeria grafik na Google Drive | Sieć połączonych notatek Markdown |
## Analysis
### 1. Różne podejścia do automatyzacji
Analiza wykazuje ewolucję od prostych agentów do złożonych rurociągów:
- **Metoda n8n** skupia się na linearnym procesie: od researchu do tekstu. Jest to klasyczny przykład "asystenta pisarza".
- **Workflow Nanobanana** wprowadza koncepcję "rurociągu" ([[concepts/ai-pipelines]]), gdzie jeden impuls (seed) generuje wielokrotne plony w różnych formatach. Skupia się na szybkości i niskim koszcie (model Flash).
- **LLM Wiki** to podejście najbardziej zaawansowane pod kątem struktury. Nie generuje "produktu" na zewnątrz, ale buduje wewnętrzny "system operacyjny wiedzy".
### 2. Wspólny mianownik: Rola człowieka
We wszystkich trzech strategiach rola człowieka przesuwa się z **wykonawcy** na **architekta i kuratora**:
- Człowiek dostarcza gust, metaforę wizualną lub selekcjonuje źródła prawdy.
- AI zajmuje się "księgowością" (bookkeeping), formatowaniem i żmudnym researchem.
## Recommendations
### Kiedy stosować daną strategię?
- **Wybierz Agenta n8n (Newsletter):** Jeśli Twoim celem jest regularna publikacja ekspercka i potrzebujesz bazy do pisania (tryb "asystent").
- **Wybierz Nanobanana Workflow:** Jeśli budujesz markę osobistą w wielu kanałach social media i potrzebujesz masowej produkcji wizualnej przy zachowaniu spójności stylu.
- **Wybierz LLM Wiki Pattern:** Jeśli Twoim celem jest długoterminowe zrozumienie skomplikowanych tematów (np. badania nad AI, bazy danych) i chcesz, aby Twoja wiedza "kumulowała się" ([[concepts/compounding-knowledge]]), a nie znikała w archiwach.
## Pages Compared
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]]
- [[summaries/google-nanobanana-workflow]]
- [[summaries/karpathy-llm-wiki-breakdown]]
- [[concepts/ai-pipelines]]
- [[concepts/human-in-the-loop]]
- [[concepts/knowledge-compilation]]