May 17, 2026, 11:40 PM
This commit is contained in:
Paweł Domański
@@ -0,0 +1,90 @@
|
||||
# LLM Wiki Schema: Personal Technical Knowledge Base
|
||||
|
||||
This document defines the structure, conventions, and workflows for maintaining the LLM Wiki in this repository.
|
||||
|
||||
## Overview
|
||||
This wiki is an LLM-maintained knowledge base focused on **AI, Databases, Programming, and Knowledge Management**, integrated with **Feynman's 12 Favorite Problems** framework.
|
||||
The LLM writes and maintains all files under `wiki/`. The human curates raw sources and directs queries.
|
||||
|
||||
## Directory Layout
|
||||
- `raw/` — Immutable source documents (transcripts, articles, notes). Never modify these.
|
||||
- `wiki/` — LLM-generated markdown files.
|
||||
- `wiki/summaries/` — One summary page per raw source document.
|
||||
- `wiki/concepts/` — Concept, strategy, and framework pages.
|
||||
- `wiki/entities/` — Entity pages (tools, technologies, organizations, products).
|
||||
- `wiki/syntheses/` — Comparison tables, decision frameworks, cross-cutting analyses.
|
||||
- `wiki/journal/` — Research or session journal entries.
|
||||
- `wiki/presentations/` — Marp slide decks generated from wiki content.
|
||||
- `wiki/feynman_problems.md` — Central tracking of long-term problems.
|
||||
- `wiki/index.md` — Master catalog. Every wiki page must appear here.
|
||||
- `wiki/log.md` — Append-only activity log.
|
||||
|
||||
## File Naming & Format
|
||||
- **Naming**: All lowercase, hyphens for word separation: `concept-name.md`. No spaces or special characters.
|
||||
- **Frontmatter**:
|
||||
```yaml
|
||||
---
|
||||
title: "Page Title"
|
||||
type: concept | entity | summary | synthesis
|
||||
tags: [tag1, tag2]
|
||||
created: YYYY-MM-DD
|
||||
updated: YYYY-MM-DD
|
||||
sources: ["[[Source Link]]"]
|
||||
confidence: high | medium | low
|
||||
---
|
||||
```
|
||||
|
||||
## Required Sections by Page Type
|
||||
|
||||
### Summary pages (`wiki/summaries/`)
|
||||
- `## Key Points` — Bulleted list of main claims/ideas.
|
||||
- `## Relevant Concepts` — Links to concept pages this source touches.
|
||||
- `## Source Metadata` — Type of source, author/speaker, date, URL or identifier.
|
||||
|
||||
### Concept pages (`wiki/concepts/`)
|
||||
- `## Definition` — One-paragraph plain-English definition.
|
||||
- `## How It Works` — Mechanics, process, or structure of the concept.
|
||||
- `## Key Parameters` — Important variables, dimensions, or factors.
|
||||
- `## When To Use` — Situations and contexts where this concept applies.
|
||||
- `## Risks & Pitfalls` — Known failure modes, common mistakes, limitations.
|
||||
- `## Related Concepts` — Wiki links to related pages.
|
||||
- `## Sources` — Which raw sources inform this page.
|
||||
|
||||
### Entity pages (`wiki/entities/`)
|
||||
- `## Overview` — What this entity is.
|
||||
- `## Characteristics` — Key properties, attributes, structure.
|
||||
- `## Common Strategies` — Links to concept pages for strategies or methods associated with this entity.
|
||||
- `## Related Entities` — Links to related entity pages.
|
||||
|
||||
## Feynman's 12 Problems Framework
|
||||
We maintain a list of ~12 "Favorite Problems" in `wiki/feynman_problems.md`. Every new piece of information is checked against this list to see if it offers a new insight or connection.
|
||||
|
||||
## Workflows
|
||||
|
||||
### 1. Ingest
|
||||
When the user says "ingest [source]" or adds a file to `raw/`:
|
||||
1. Read the raw source completely.
|
||||
2. Create `wiki/summaries/<source-slug>.md` with full summary.
|
||||
3. Identify all concepts, entities, and strategies mentioned.
|
||||
4. **Feynman Check**: Compare against `wiki/feynman_problems.md` and update it if connections are found.
|
||||
5. Create/Update concept and entity pages using the required sections.
|
||||
6. Add cross-links in both directions between all touched pages.
|
||||
7. Update `wiki/index.md` and `wiki/log.md`.
|
||||
8. Flag any contradictions with existing content.
|
||||
|
||||
### 2. Query
|
||||
1. Read `wiki/index.md` to find relevant pages.
|
||||
2. Synthesize an answer citing specific pages with wiki links.
|
||||
3. If new insight is found, create a synthesis page in `wiki/syntheses/`.
|
||||
|
||||
### 3. Lint
|
||||
1. Check for orphan pages, stale claims, contradictions, and missing cross-links.
|
||||
2. Fix automatically where possible; report others.
|
||||
3. Suggest new sources or topics.
|
||||
|
||||
## Rules
|
||||
- Never modify files in `raw/`.
|
||||
- All dates in ISO 8601 format: YYYY-MM-DD.
|
||||
- Use Obsidian-style links: `[[concepts/concept-name]]`.
|
||||
- Confidence levels: **high** (multiple sources), **medium** (single source), **low** (speculative).
|
||||
- Polish language for content, English/Technical slugs for filenames.
|
||||
@@ -0,0 +1,47 @@
|
||||
# LLM Wiki: System Zarządzania Wiedzą (Karpathy Pattern)
|
||||
|
||||
Ten projekt to osobista baza wiedzy (Wiki), która jest **aktywnie utrzymywana przez LLM**. Zamiast tylko przechowywać dokumenty, system ten incrementally buduje i syntetyzuje wiedzę w strukturę połączonych plików Markdown.
|
||||
|
||||
## 🧠 Filozofia
|
||||
System opiera się na połączeniu dwóch idei:
|
||||
- **Karpathy Pattern**: Wiki jako "codebase" wiedzy utrzymywany przez LLM.
|
||||
- **12 Problemów Feynmana**: Metoda polegająca na trzymaniu w pamięci (i tutaj - w pliku `wiki/feynman_problems.md`) 12 kluczowych pytań. Każde nowe źródło jest testowane pod kątem tego, czy pomaga rozwiązać lub zrozumieć któryś z tych problemów.
|
||||
|
||||
## 📂 Struktura Katalogów
|
||||
- `raw/`: **Źródła Prawdy**. Tu trafiają Twoje materiały (PDF, Markdown, notatki). Są one niemodyfikowalne.
|
||||
- `articles/`: Artykuły z sieci, blogi.
|
||||
- `notes/`: Twoje własne przemyślenia i surowe notatki.
|
||||
- `wiki/`: **Warstwa Syntezy**. Pliki generowane i utrzymywane przez LLM.
|
||||
- `sources/`: Analizy konkretnych dokumentów z `raw/`.
|
||||
- `entities/`: Strony konkretnych narzędzi, osób i technologii (np. `n8n`).
|
||||
- `concepts/`: Głębokie analizy idei i teorii (np. `human-in-the-loop`).
|
||||
- `index.md`: Katalog całej treści (Mapa Wiki).
|
||||
- `log.md`: Dziennik zdarzeń (Co i kiedy zostało dodane).
|
||||
- `GEMINI.md`: Zasady i instrukcje dla Gemini CLI.
|
||||
|
||||
## 🚀 Jak korzystać z systemu?
|
||||
|
||||
### 1. Ingest (Dodawanie wiedzy)
|
||||
Wrzuć nowy plik do folderu `raw/` i wydaj polecenie:
|
||||
> *"Przetwórz nowe dokumenty z katalogu raw"*
|
||||
|
||||
**Co zrobi LLM:** Przeczyta plik, stworzy podsumowanie w `wiki/sources/`, zaktualizuje powiązane encje i koncepcje, oraz dopisze informację do indeksu i logu.
|
||||
|
||||
### 2. Query (Zadawanie pytań)
|
||||
Zadaj dowolne pytanie techniczne lub teoretyczne:
|
||||
> *"Jakie narzędzia do automatyzacji researchu mamy w bazie?"*
|
||||
|
||||
**Co zrobi LLM:** Najpierw sprawdzi `wiki/index.md`, przeczyta odpowiednie strony z `wiki/` i przygotuje odpowiedź z cytowaniami.
|
||||
|
||||
### 3. Lint (Sprzątanie)
|
||||
Raz na jakiś czas poproś o przegląd bazy:
|
||||
> *"Wykonaj lint wiki i znajdź brakujące połączenia"*
|
||||
|
||||
**Co zrobi LLM:** Znajdzie "sieroty" (pliki bez linków), sprzeczności między starymi a nowymi źródłami lub zasugeruje stworzenie nowej strony koncepcyjnej dla często pojawiającego się tematu.
|
||||
|
||||
## 🛠️ Narzędzia polecane
|
||||
- **Obsidian**: Najlepsze narzędzie do przeglądania tej bazy. Użyj "Graph View", aby zobaczyć jak Twoja wiedza się łączy.
|
||||
- **Gemini CLI**: Twój asystent, który wykonuje całą "brudną robotę" edytorską.
|
||||
|
||||
---
|
||||
*System zainicjalizowany: 2026-05-14*
|
||||
@@ -0,0 +1,224 @@
|
||||
---
|
||||
title: "The 5 Core Mental Models for AI Agents: Harness & Memory (Deep Dive + Action Plan) - BPMS Team"
|
||||
source:
|
||||
author:
|
||||
published:
|
||||
created: 2026-05-14
|
||||
description:
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This page distills the five consensus mental models expert teams use to take agents from demos to production, then maps them to a concrete fraud-analysis use case built with Gemini CLI, MCP tools, and BigQuery. Use it as a reference for design reviews, implementation planning, and capability audits.
|
||||
|
||||
Table of Contents
|
||||
|
||||
## Mental Model 1 — The Model Is the CPU. The Harness Is the OS.
|
||||
|
||||
> "Strip away the harness and you have a raw language model guessing its way through your codebase. Add the right harness and you have a system that ships production code."
|
||||
|
||||
## Core Idea
|
||||
|
||||
LLMs are powerful but general-purpose reasoning engines. Quality emerges from the harness (the “OS”) that shapes inputs/outputs, tools, policies, and runtime controls. Changing the harness often changes outcomes more than swapping models.
|
||||
|
||||
## Analogy Mapping
|
||||
|
||||
- **Model → CPU:** raw intelligence (e.g., Gemini 2.5 Pro)
|
||||
- **Context Window → RAM:** working memory (MCP context, GEMINI.md)
|
||||
- **Harness → OS:** tools, routers, policies, safety gates
|
||||
- **Agent → Application:** your fraud pipeline (prompts + tools + flow)
|
||||
- **Memory → Disk/SSD:** persistent state across sessions
|
||||
|
||||
## Why It Matters
|
||||
|
||||
- Different harnesses around the same model produce large score deltas on realistic tasks.
|
||||
- Slimmer, better-curated toolboxes often outperform maximalist sets due to lower decision entropy.
|
||||
|
||||
## Design Implications
|
||||
|
||||
- Make the “OS layer” explicit: state store, checkpoints, retries, idempotency, and traceability.
|
||||
- Bias for simple, tight tool catalogs with strong schemas and pre/post-conditions.
|
||||
- Invest early in observability of agent steps, not just final replies (see Observability references below).
|
||||
|
||||
Your Gemini CLI fraud agent already has a proto-harness (MCP tools, GEMINI.md, SQL generation). The missing “OS” capabilities are: state persistence, checkpoint/resume, and run-level tracing.
|
||||
|
||||
## Mental Model 2 — Context Is the Product
|
||||
|
||||
> "Every harness artifact answers the same question: What does the agent need to know before it writes a single line of code?"
|
||||
|
||||
## The Context Stack
|
||||
|
||||
5\. Procedural Memory ("How we do things here")
|
||||
|
||||
4\. Semantic Memory ("What is true right now")
|
||||
|
||||
3\. Episodic Memory ("What happened before")
|
||||
|
||||
2\. Session State ("Earlier this session")
|
||||
|
||||
1\. Working Context ("Right now: last N turns + active tools")
|
||||
|
||||
## The Core Tension
|
||||
|
||||
Trade off in-context stuffing vs. out-of-context retrieval:
|
||||
|
||||
- Full context: zero latency to recall, but costly and “lost-in-the-middle” risks.
|
||||
- Sliding window: cheap, but causes session amnesia.
|
||||
- RAG (vector): good semantic recall; must tune chunking, reranking, and filters.
|
||||
- Hybrid vector + graph: best for entities/relations; requires ontology upkeep.
|
||||
|
||||
## Design Implications
|
||||
|
||||
- Separate “always-in” system context from “retrieve-when-relevant” memory.
|
||||
- Layer vector search (semantic) with graph traversal (relational correctness).
|
||||
- Use LLM-managed memory policies: what to store, how to compress, when to forget.
|
||||
|
||||
For the query “877-417-4551,” persist: (a) semantic fact “shared phone links to 2,097 entities,” (b) episodic trace “investigation run with outcomes,” (c) procedural heuristic “for shared-phone queries use 3-hop traversal.” Your existing ArangoDB graph is a natural semantic + episodic backend.
|
||||
|
||||
## Mental Model 3 — Separate the Doer from the Judge
|
||||
|
||||
> Agents are unreliable self-graders. External verification (computational tests, an evaluator model, or humans) is essential.
|
||||
|
||||
## Verification Spectrum
|
||||
|
||||
- Level 1: Self-check (cheap; catches formatting/syntax; misses subtle issues)
|
||||
- Level 2: Computational checks (schema/type/linters/tests; low cost, medium power)
|
||||
- Level 3: Inferential LLM judge (semantic/design review; medium cost)
|
||||
- Level 4: Adversarial evaluator agent (high cost; highest defect catch rate)
|
||||
- Level 5: Human-in-the-loop (HITL) (doesn’t scale; gold standard)
|
||||
|
||||
## Design Implications
|
||||
|
||||
- Insert feedforward constraints (contracts, schemas, tool preconditions) and feedback sensors (tests, monitors, audits) in the harness.
|
||||
- Never allow the authoring agent to “approve” high-impact actions; split duties.
|
||||
|
||||
Add for your BigQuery SQL agent: (1) pre-exec schema validation, (2) guardrails on result size/runtime; auto-ask for confirmation if estimated rows > threshold, (3) HITL gate for destructive or high-impact ops. Aligns to D&B oversight requirements and internal harness patterns observed in production agents.
|
||||
|
||||
## Mental Model 4 — Memory Is Three Cognitive Tiers, Not One Bucket
|
||||
|
||||
## Three Tiers
|
||||
|
||||
- **Episodic:** past events/traces/outcomes; chronological, bitemporal annotations; ideal in temporal graphs or run logs.
|
||||
- **Semantic:** facts/entities/relationships; hybrid structured rows + embeddings; conflict detection and merging are key.
|
||||
- **Procedural:** instructions, playbooks, heuristics; static files (AGENT.md) or runtime prompt updates with guardrails.
|
||||
|
||||
## Design Implications
|
||||
|
||||
- Pick backends by tier, not “one DB for all.” Graph stores fit semantic and episodic; files or prompt-update APIs fit procedural.
|
||||
- Implement conflict resolution for semantic memory (compare new facts to graph entries, merge/update/flag).
|
||||
- Track “memory provenance” so the harness can justify recalls and updates.
|
||||
|
||||
Mapping for your fraud agent: “2,097 entities linked to 877‑417‑4551 in Florida” → Semantic (ArangoDB). “Last investigation on 23 kwi 2026 found shell factory” → Episodic. “Shared-phone queries → 3-hop traversal first” → Procedural (GEMINI.md or runtime system-prompt rule).
|
||||
|
||||
## Mental Model 5 — Graduated Autonomy: Earn Trust Through Verification
|
||||
|
||||
## Gradient of Autonomy
|
||||
|
||||
- Level 0 Read-only
|
||||
- Level 1 Suggest-only
|
||||
- Level 2 Approve-then-act
|
||||
- Level 3 Act-then-review (audit)
|
||||
- Level 4 Autonomous (bounded)
|
||||
- Level 5 Fully autonomous
|
||||
|
||||
## Design Implications
|
||||
|
||||
- Start lower, promote autonomy based on proven reliability (evals + memory of track record).
|
||||
- Constrain the environment: tight tools, strict contracts, and yardsticks for promotion/demotion.
|
||||
|
||||
D&B’s internal governance aligns to 6 autonomy tiers. Use episodic memory for track record (“47 runs, zero false positives”) to graduate; use semantic memory for sensitivity flags (“touches PII”) to require HITL; use procedural memory to encode newly learned safe behaviors.
|
||||
|
||||
---
|
||||
|
||||
## Applying the 5 Models to Your Gemini CLI + BigQuery Fraud Agent
|
||||
|
||||
## Target Architecture Additions (“OS Layer”)
|
||||
|
||||
- **State & Checkpointing:** Persist per-run state and decisions (e.g., Postgres/Arango + run\_id) so long tasks can resume after failure. See internal examples using LangGraph state + Postgres checkpointing in production agents.
|
||||
- **Observability:** Trace prompts, tool calls, inputs/outputs, token/cost, and branch decisions. Capture row estimates for SQL, retrieval stats for memory calls, and validation outcomes. Align to AI observability guidance: infra + model/agent + quality/safety telemetry with correlation.
|
||||
- **Guardrails:** Schema-aware SQL builder; preflight “EXPLAIN” or dry-run checks; result-size and latency thresholds → evaluator/HITL gates; redaction and policy filters for sensitive fields.
|
||||
|
||||
## Memory Plan (Three Tiers)
|
||||
|
||||
- **Episodic:** Investigation traces with inputs, traversals (e.g., phone → entities → addresses), evidence URIs, outcomes, and evaluator judgments. Store bitemporally to enable regression and “what changed since last run?” analyses.
|
||||
- **Semantic:** Entity facts in ArangoDB: phones, persons, businesses, addresses, edges with weights and recency. Add conflict detection rules when new facts disagree with old; record source and confidence.
|
||||
- **Procedural:** GEMINI.md rules + runtime “policy injects” (e.g., “On shared identifiers: 3-hop traversal; for row estimates > 1M, ask confirmation; for PII tables, require HITL”). Maintain a changelog of procedural updates with who/what justified the change.
|
||||
|
||||
## Harness Hardening (Doer vs. Judge)
|
||||
|
||||
- **Feedforward:** Strict tool schemas, SQL builder with typed columns and table contracts; entity resolver with disambiguation prompts; scope checks before any heavy query.
|
||||
- **Feedback:** Computational checks (lint/validation), evaluator LLM for semantic soundness on traces, targeted HITL for high-impact actions or low-confidence decisions.
|
||||
|
||||
## Graduated Autonomy Rollout
|
||||
|
||||
- **Phase A (L1):** Suggest-only SQL + rationale; mandatory evaluator review for all queries.
|
||||
- **Phase B (L2):** Approve-then-act for read queries under thresholds; HITL for anything exceeding table sensitivity or row/latency caps.
|
||||
- **Phase C (L3):** Act-then-review for non-sensitive reads with strong historical precision; auto-rollback heuristic if evaluator flags anomalies.
|
||||
|
||||
## Context Strategy
|
||||
|
||||
- Working context: last N tool calls + current hypothesis + active graph nodes.
|
||||
- Session state: rolling compressed summary of this investigation run.
|
||||
- Episodic/semantic recall: hybrid retrieval—vector similarity on notes/explanations plus graph traversal for facts; re-rank by provenance and freshness.
|
||||
|
||||
---
|
||||
|
||||
## Implementation Blueprint
|
||||
|
||||
## Milestone 1 — OS Layer Foundations
|
||||
|
||||
- Add run\_id and checkpoint tables; store step-level inputs/outputs and decisions.
|
||||
- Integrate AI tracing (prompts, tool calls, latencies, cost) and expose searchable logs.
|
||||
- Harden SQL tool: typed schema, table allowlist, safe templates, EXPLAIN pre-checks.
|
||||
|
||||
## Milestone 2 — Memory (ArangoDB-first)
|
||||
|
||||
- Design graph schema for phone↔entity↔address relations with edge attrs: weight, recency, source, confidence.
|
||||
- Implement semantic write path with conflict detection/merge rules; provenance is mandatory.
|
||||
- Add episodic store for run traces linked to graph nodes/edges; enable “delta since last run.”
|
||||
|
||||
## Milestone 3 — Doer/Judge Split
|
||||
|
||||
- Introduce computational validators (schema, row-estimate caps, sensitive-table guards).
|
||||
- Add evaluator LLM for semantic quality on investigations (fact sufficiency, alternative explanations, leakage risks).
|
||||
- Wire HITL gates for flagged conditions; log reviewer decisions back into episodic memory.
|
||||
|
||||
## Milestone 4 — Graduated Autonomy
|
||||
|
||||
- Define promotion criteria (precision/recall on eval sets, incident-free runs, operator feedback).
|
||||
- Automate demotion on evaluator regressions or anomaly spikes.
|
||||
- Track autonomy tier in agent state; show in UI with audit trail.
|
||||
|
||||
---
|
||||
|
||||
## Risk Controls and Operational Readiness
|
||||
|
||||
- **Data governance:** Align table access to sensitivity tiers; mask/redact PII in context; retain audit logs.
|
||||
- **Cost control:** Token usage and query-cost meters; context compression; hybrid retrieval to avoid over-stuffing prompts.
|
||||
- **Reliability:** Timeouts, retries with backoff; idempotent tool calls; partial-progress resumes via checkpoints.
|
||||
- **Evaluation:** Seed test sets and continuous evals for accuracy, grounding, and safety; track scorecards per model/tool revision.
|
||||
|
||||
## Quick-Start Artifacts
|
||||
|
||||
- **AGENT.md (procedural seed):** investigation steps, guardrails, escalation criteria.
|
||||
- **Tool contracts:** JSON Schemas for SQL generation, graph traversal, entity resolution.
|
||||
- **Evaluator prompts:** structured critique rubric (soundness, sufficiency, safety, performance impact) with pass/block decision.
|
||||
- **Runbook views:** dashboard panels for per-run trace, thresholds triggered, autonomy tier, and memory writes.
|
||||
|
||||
## FAQ
|
||||
|
||||
No. Start with a single agent and strong harness (tools, validators, evaluator). Add a separate evaluator agent later if quality gaps remain or scale requires parallel critics.
|
||||
|
||||
Use both. Vector for semantic recall of notes/past narratives; graph for factual correctness and relationship traversal. Your ArangoDB gives you a strong graph spine; add vectors for unstructured artifacts with provenance links.
|
||||
|
||||
Define quantitative gates (precision/recall on evals, zero critical incidents over last N runs, latency/cost SLO adherence) plus qualitative operator feedback. Store outcomes in episodic memory as evidence.
|
||||
|
||||
## Follow-ups
|
||||
|
||||
- Create a 1-page “Mental Models Notebook” PDF with diagrams for team onboarding.
|
||||
- Deliver a gap analysis specifically for your Gemini CLI + BigQuery fraud agent with a 30–60–90 day plan.
|
||||
- Deep-dive design for “ArangoDB as memory backend” (schema, indices, traversal templates, conflict-resolution rules, and retrieval orchestration).
|
||||
|
||||
## References
|
||||
@@ -0,0 +1,334 @@
|
||||
---
|
||||
title: "Andrej Karpathy’s LLM Wiki: Create your own knowledge base"
|
||||
source: "https://medium.com/@urvvil08/andrej-karpathys-llm-wiki-create-your-own-knowledge-base-8779014accd5"
|
||||
author:
|
||||
- "[[Urvil Joshi]]"
|
||||
published: 2026-04-20
|
||||
created: 2026-05-14
|
||||
description: "Ty Wyróżnienie"
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
Andrej Karpathy [**tweeted**](https://x.com/karpathy/status/2039805659525644595) something that quietly broke the AI community’s understanding of how we should be using LLMs to manage knowledge.
|
||||
|
||||
Two days later, he followed up with a GitHub gist called [**llm-wiki.md**](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). The idea isn’t a product. It’s not code. It’s a *pattern* a special one that might make will help you create a small scale personal knowledge base in few minutes.
|
||||
|
||||
Let’s break this down.
|
||||
|
||||
## 🍥The Tweet That Started It
|
||||
|
||||
Karpathy’s original tweet:
|
||||
|
||||
> “Something I’m finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating…”
|
||||
>
|
||||
> *— @karpathy, April 2, 2026*
|
||||
|
||||
And that’s what he published a single markdown file on GitHub Gist. Something he calls an **idea file**: a document meant to be copy-pasted into an LLM agent like Claude Code, OpenAI Codex or any agent, where *your* agent then instantiates the pattern for *your* specific needs.
|
||||
|
||||
## ✨The Core Idea: Stop Retrieving. Start Compiling.
|
||||
|
||||
Here’s the insight in one sentence: **instead of having the LLM re-read your raw documents every time you ask a question, build a persistent, structured wiki once and keep it updated forever.**
|
||||
|
||||
Karpathy used an analogy from software engineering: **compilation**.
|
||||
|
||||
```c
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ SOFTWARE ENGINEERING │
|
||||
│ │
|
||||
│ Source Code ──[ compile once ]──► Binary │
|
||||
│ (readable) (runs fast every │
|
||||
│ single call) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
⇕ same idea ⇕
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ LLM WIKI │
|
||||
│ │
|
||||
│ Raw Sources ──[ LLM compiles ]──► Wiki │
|
||||
│ (PDFs, notes, (pre-synthesized, │
|
||||
│ articles) interlinked, │
|
||||
│ always ready) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
You don’t execute source code every time you want to run a program. You compile it once into a binary and run *that*. Karpathy says: treat knowledge the same way. Your PDFs and notes are the source code. The wiki is the binary.
|
||||
|
||||
Every time you add a new document, the LLM doesn’t just index it. It **reads it, extracts the key information, updates existing pages, revises summaries, flags contradictions, and strengthens cross-links**. The wiki is a persistent, compounding artifact.
|
||||
|
||||
In Karpathy’s own words, the line that captures the whole philosophy:
|
||||
|
||||
> “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.”
|
||||
|
||||
You rarely write the wiki yourself. You curate sources, ask questions, and think. The LLM handles the whole work summarizing, cross-referencing, filing, and bookkeeping.
|
||||
|
||||
## 🔍The Three-Layer Architecture
|
||||
|
||||
```c
|
||||
╔══════════════════════════════════════════════════════════════╗
|
||||
║ LAYER 3 — THE SCHEMA ║
|
||||
║ (CLAUDE.md / AGENTS.md) ║
|
||||
║ ║
|
||||
║ Rules • Conventions • Workflows • How to ingest/query ║
|
||||
║ ║
|
||||
║ ↕ tells the LLM HOW to behave ║
|
||||
╠══════════════════════════════════════════════════════════════╣
|
||||
║ LAYER 2 — THE WIKI ║
|
||||
║ (LLM owns this entirely) ║
|
||||
║ ║
|
||||
║ ┌──────────┐ ┌──────────┐ ┌──────────┐ ║
|
||||
║ │ Entity │──│ Concept │──│ Overview │ index.md ║
|
||||
║ │ pages │ │ pages │ │ pages │ log.md ║
|
||||
║ └──────────┘ └──────────┘ └──────────┘ ║
|
||||
║ ↑ LLM creates, links, updates, maintains ║
|
||||
╠══════════════════════════════════════════════════════════════╣
|
||||
║ LAYER 1 — RAW SOURCES ║
|
||||
║ (IMMUTABLE) ║
|
||||
║ ║
|
||||
║ 📄 PDFs 📰 Articles 🎧 Podcast notes 🖼️ Images ║
|
||||
║ ║
|
||||
║ LLM reads • NEVER modifies • source of truth ║
|
||||
╚══════════════════════════════════════════════════════════════╝
|
||||
```
|
||||
|
||||
**Layer 1 — Raw sources.** Your curated collection. Articles, papers, meeting notes, images. Immutable. The LLM reads them but *never* modifies them. This is your ground truth. The fact that they’re immutable is a deliberate design choice: you can always re-compile the wiki from scratch if needed.
|
||||
|
||||
**Layer 2 — The wiki.** A directory of markdown files the LLM owns completely. Entity pages, concept pages, summaries, an index, a log. You read it. The LLM writes it.
|
||||
|
||||
**Layer 3 — The schema.** This is a CLAUDE.md (for Claude Code) or AGENTS.md (for Codex) file. It’s the config that turns a generic agent into a *disciplined wiki maintainer*. It defines how pages are structured, how new sources get ingested, how answers get formatted.
|
||||
|
||||
## 🧰The Three Operations
|
||||
|
||||
```c
|
||||
┌──────────────────────┐
|
||||
│ YOU (Human) │
|
||||
│ curates & asks │
|
||||
└──────────┬───────────┘
|
||||
│
|
||||
┌────────────────────┼────────────────────┐
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌────────────┐ ┌────────────┐ ┌────────────┐
|
||||
│ 1. INGEST │ │ 2. QUERY │ │ 3. LINT │
|
||||
├────────────┤ ├────────────┤ ├────────────┤
|
||||
│ Drop new │ │ Ask a │ │ Health- │
|
||||
│ source → │ │ question → │ │ check wiki │
|
||||
│ LLM reads, │ │ LLM reads │ │ → find │
|
||||
│ summarises,│ │ wiki & │ │ contra- │
|
||||
│ updates │ │ synthesises│ │ dictions, │
|
||||
│ 10–15 wiki │ │ answer │ │ orphans, │
|
||||
│ pages │ │ w/ cites │ │ stale data │
|
||||
└─────┬──────┘ └─────┬──────┘ └─────┬──────┘
|
||||
│ │ │
|
||||
└────────────────────┴────────────────────┘
|
||||
│
|
||||
▼
|
||||
┌──────────────────────┐
|
||||
│ WIKI COMPOUNDS │
|
||||
│ (every op makes it │
|
||||
│ richer over time)│
|
||||
└──────────────────────┘
|
||||
```
|
||||
|
||||
**Ingest.** You drop a source into the raw folder. The LLM reads it, writes a summary page, and touches some related pages updating, cross-linking, flagging contradictions. A single article becomes a web of updates across your entire knowledge base.
|
||||
|
||||
**Query.** You ask a question. The LLM doesn’t search raw documents it reads the already synthesized wiki and answers. And here’s the compounding trick: **good answers can be filed back into the wiki as new pages**. Your explorations become permanent knowledge.
|
||||
|
||||
**Lint.** Periodically, you ask the LLM to audit the whole wiki. Find contradictions. Find orphan pages with no links pointing in. Find concepts that are mentioned but missing their own page. The wiki stays healthy because the LLM does the maintenance no human ever wants to do.
|
||||
|
||||
## ✨Let’s Actually Build One
|
||||
|
||||
Let’s build a working LLM Wiki together.
|
||||
|
||||
### What you need
|
||||
|
||||
1. **Claude Code** (or OpenAI Codex, or any agent) the brain
|
||||
2. **Obsidian** (free, [obsidian.md](https://obsidian.md/)) — the viewer
|
||||
3. A folder on your computer — your vault
|
||||
|
||||
### Step 1: Create the folder structure
|
||||
|
||||
Open your terminal:
|
||||
|
||||
bash
|
||||
|
||||
```c
|
||||
mkdir llm-wiki-demo && cd llm-wiki-demo
|
||||
mkdir raw
|
||||
```
|
||||
|
||||
Masz teraz:
|
||||
|
||||
```c
|
||||
llm-wiki-demo/
|
||||
├── raw/ (your immutable sources go here)
|
||||
```
|
||||
|
||||
### Krok 2: Otwórz Claude Code w tym folderze i wklej tę pojedynczą wiadomość
|
||||
|
||||
> =="Chcę, żebyś przeczytał ten plik pomysłów autorstwa Andreja Karpathy'ego i pomógł mi założyć Wiki LLM w tym katalogu. Zanim cokolwiek zrobisz, zapytaj mnie, o czym będzie ta wiki i jakich źródeł zamierzam ją podać. Gdy odpowiem, napisz mi plik schematu CLAUDE.md na podstawie mojej odpowiedzi".==
|
||||
|
||||
Tutaj wklej pełną treść [oryginalnego smysłu Karpathy'ego](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
|
||||
|
||||
### Krok 3: Claude odpowie kilkoma pytaniami wyjaśniającymi
|
||||
|
||||
Claude odpowie kilkoma pytaniami wyjaśniającymi, takimi jak:
|
||||
|
||||
- Jaki temat będzie poruszać ta wiki?
|
||||
- Jakie źródła będziesz mu dostarczać?
|
||||
- Ile mniej więcej chcesz pochłonąć?
|
||||
- Jakie typy stron chcesz?
|
||||
|
||||
### Krok 4: Odpowiedz szczerze
|
||||
|
||||
Do tego dema tworzę wiki o **AI i filozofii oprogramowania**. Moja odpowiedź:
|
||||
|
||||
> "Wiki obejmuje badania nad AI i filozofię oprogramowania. Dam mu krótkie eseje i wpisy na blogu od takich osób jak Rich Sutton i Andrej Karpathy. Prawdopodobnie 10–20 źródeł. Chcę stron koncepcyjne, streszczeń esejów i stron autorów."
|
||||
|
||||
Claude teraz napisze plik dostosowany do tego zastosowania, inicjalizuje i, i powie coś w stylu *"Gotowy do pobrania twojego pierwszego źródła."* `CLAUDE.md` `wiki/index.md` `wiki/log.md`
|
||||
|
||||
Po prostu zbudowałeś cały schemat bez napisania choćby jednej linii kodu. To jest wzorzec Karpathy'ego, który działa dokładnie tak, jak zamierzono.
|
||||
|
||||
### Krok 5: Pobieranie źródeł
|
||||
|
||||
Do mojej demonstracji mam dwa źródła
|
||||
|
||||
**#1 "Gorzka lekcja" Richa Suttona**
|
||||
|
||||
Wrzuć "Gorzką lekcję" Richa Suttona do.`raw/` `bitter-lesson.pdf`
|
||||
|
||||
Powiedz Claude'owi:
|
||||
|
||||
> "Połykanie." `raw/bitter-lesson.pdf`
|
||||
|
||||
Zobacz, co się stanie. Claude czyta dwustronicowy esej i generuje coś w stylu:
|
||||
|
||||
```c
|
||||
wiki/
|
||||
├── index.md (updated)
|
||||
├── log.md (new entry appended)
|
||||
├── sources/
|
||||
│ └── bitter-lesson.md (summary page)
|
||||
├── concepts/
|
||||
│ ├── search.md
|
||||
│ ├── learning.md
|
||||
│ ├── moores-law.md
|
||||
│ ├── general-methods.md
|
||||
│ └── human-knowledge-approaches.md
|
||||
├── examples/
|
||||
│ ├── computer-chess.md
|
||||
│ ├── computer-go.md
|
||||
│ ├── speech-recognition.md
|
||||
│ └── computer-vision.md
|
||||
└── people/
|
||||
└── rich-sutton.md
|
||||
```
|
||||
|
||||
Jeden dwustronicowy PDF stał się ~10 połączonych stron. Każda strona odwołuje się do pozostałych w stylu Obsidian.`[[wikilinks]]`
|
||||
|
||||
**#2 — "Oprogramowanie 2.0" Karpathy'ego**
|
||||
|
||||
**Wpadnij "Software 2.0" Karpathy'ego** do.`raw/` `*software-2-0.pdf*`
|
||||
|
||||
Powiedz Claude'owi:
|
||||
|
||||
> "Połykanie." `raw/software-2-0.pdf`
|
||||
|
||||
Claude nie zaczyna od zera. Najpierw czyta twoją istniejącą wiki, rozpoznaje, że esej Karpathy'ego "Software 2.0" argumentuje czymś ściśle związanym z Gorzką Lekcją, i robi coś niezwykłego: **aktualizuje istniejące strony**, dodając ramy Karpathy'ego, wzmacnia odniesienia krzyżowe i tworzy nowe strony tylko tam, gdzie jest to potrzebne.
|
||||
|
||||
Strona teraz zawiera link zwrotny, ponieważ LLM wykrył koncepcyjny związek między dwoma esejami, link, który *nie dodał nikt inny*.`software-2-0.md` `[[bitter-lesson]]`
|
||||
|
||||
**Twoja wiki stała się gęstsza, nie tylko większa.** To jest właściwość złożenia, na którą wskazuje Karpathy.
|
||||
|
||||
### Krok 6: Zadaj pytanie syntetyczne
|
||||
|
||||
A teraz efekt:
|
||||
|
||||
> "Jak Sutton i Karpathy zgadzają się co do przyszłości oprogramowania i gdzie mogą się nie zgadzać?"
|
||||
|
||||
==Claude nie otwiera ponownie PDF-ów. Odczytuje dwie strony wiki, które właśnie stworzyłeś, podąża za== ==`[[linkami]]`== między nimi i w kilka sekund daje ugruntowaną syntezę międzyautorów. Ta odpowiedź, która opiera się na połączeniach, które nie istniały 60 sekund temu, jest teraz plikiem leżącym w twoim skarbcu na zawsze.
|
||||
|
||||
To właśnie ma na myśli Karpathy, mówiąc, że wiedza *się kumuluje*.
|
||||
|
||||
### Krok 7: Otwórz Obsidian i skieruj go na folder
|
||||
|
||||
Zainstaluj [Obsidian](https://obsidian.md/), stwórz nowy skarbiec, skieruj go na swój folder i kliknij **w widok grafu**.`llm-wiki-demo/`
|
||||
|
||||
Teraz patrzysz na swoją wiedzę jako na sieć. Węzły to strony. Krawędzie to ogniwa, które Claude dodawał automatycznie. Każde dodane źródło sprawia, że wykres staje się gęstszy.
|
||||
|
||||
To właśnie wtedy wykres jest wyrenderowany po raz pierwszy, wtedy większość ludzi to rozumie.
|
||||
|
||||
## 🔍RAG vs LLM Wiki: Szczere porównanie
|
||||
|
||||
Pytanie, które wszyscy zadają: czy to faktycznie lepsze niż RAG?
|
||||
|
||||
Szczera odpowiedź: **żadne z nich nie wygrywa. Rozwiązują różne problemy.**
|
||||
|
||||
```c
|
||||
┌─────────────────────────────────┬─────────────────────────────────┐
|
||||
│ RAG │ LLM WIKI │
|
||||
├─────────────────────────────────┼─────────────────────────────────┤
|
||||
│ │ │
|
||||
│ 📄 Raw docs stay raw │ 📄 Raw docs compiled into │
|
||||
│ │ structured wiki pages │
|
||||
│ │ │
|
||||
│ 🔍 Retrieves chunks per query │ 📖 Reads pre-synthesized pages │
|
||||
│ │ │
|
||||
│ 🔁 Stateless — every query │ 📈 Stateful — knowledge │
|
||||
│ starts from scratch │ compounds over time │
|
||||
│ │ │
|
||||
│ 🧩 Answers assembled from │ 🔗 Answers drawn from already- │
|
||||
│ fragments at runtime │ connected concepts │
|
||||
│ │ │
|
||||
│ 🕒 Cheap per query │ 💰 Expensive ingest, │
|
||||
│ │ cheap query │
|
||||
│ │ │
|
||||
│ ✅ Perfect traceability to │ ⚠️ Answers 1–2 steps removed │
|
||||
│ source (which chunk?) │ from raw source │
|
||||
│ │ │
|
||||
│ ❌ No cross-time synthesis │ ✅ Links March article to │
|
||||
│ │ October article naturally │
|
||||
│ │ │
|
||||
│ ✅ Fresh data always re-read │ ⚠️ Updates require re-ingest │
|
||||
│ │ │
|
||||
│ ✅ Hallucinations stay local │ ⚠️ Hallucinations can get │
|
||||
│ to one answer │ baked in as "facts" │
|
||||
│ │ │
|
||||
│ 🎯 Best for: large, changing │ 🎯 Best for: ~100–500 curated │
|
||||
│ corpora, fact lookup, │ sources, research projects, │
|
||||
│ millions of docs │ personal knowledge, books │
|
||||
│ │ │
|
||||
└─────────────────────────────────┴─────────────────────────────────┘
|
||||
```
|
||||
|
||||
**RAG** jest świetny, gdy masz miliony dokumentów, które ciągle się zmieniają i potrzebujesz precyzyjnych cytowań do konkretnego fragmentu. Pomyśl o obsłudze klienta, wyszukiwarce prawne, wyszukiwaniu faktów w firmie.
|
||||
|
||||
**Wiki LLM** jest świetna, gdy masz ograniczony, wyselekcjonowany korpus, może kilkaset źródeł na temat, którym się zajmujesz. Projekty badawcze. Książka, którą studiujesz. Kurs, który wybierasz. Twój własny dziennik. Sytuacje, w których **synteza ma większe znaczenie niż wyszukiwanie**, gdzie wartościowe odpowiedzi wymagają połączenia pięciu źródeł, a nie szukania jednego.
|
||||
|
||||
Jest prawdziwa krytyka wzorca LLM Wiki, którą warto traktować poważnie: ponieważ LLM podsumowuje i skrada źródła na stronach wiki, istnieje ryzyko, że halucynacje zostaną wplecione jako *"fakty".* W czystym RAG błędna odpowiedź to po prostu jedna błędna odpowiedź. W przypadku wiki LLM drobne nieporozumienie może cicho rozprzestrzenić się na powiązanych stronach.
|
||||
|
||||
Dlatego Karpathy podkreśla okresowe audyty **stopniowe usuwania kłaczków** i dlaczego każda poważna implementacja powinna dokładnie sprawdzać generowane strony względem surowych źródeł.
|
||||
|
||||
## 🧰Dlaczego to naprawdę ma znaczenie
|
||||
|
||||
To nie tak naprawdę chodzi o wiki. Karpathy wskazuje na coś znacznie starszego – wizję Vannevara Busha z 1945 roku, zwaną **Memex**: osobistym, kuratorowanym magazynem wiedzy, gdzie *powiązania między dokumentami* są równie cenne jak same dokumenty.
|
||||
|
||||
|
||||
|
||||
Wizja Busha była bliższa temu niż temu, czym stał się internet: prywatny, aktywnie kuratorowany, z powiązanymi ścieżkami między ideami. Powód, dla którego Memex nigdy tak naprawdę nie powstał, nie jest techniczny. Chodzi o to, że nikt nie chce prowadzić *księgowości*, aktualizować odnośników, utrzymywać aktualne streszczenia, zauważać, gdy nowe dane przeczą starym twierdzeniom.
|
||||
|
||||
Jak pisze Karpathy w ogóle:
|
||||
|
||||
> "Żmudną częścią utrzymania bazy wiedzy nie jest czytanie ani myślenie, lecz księgowość. Ludzie porzucają wiki, ponieważ obciążenie związane z utrzymaniem rośnie szybciej niż wartość. LLM się nie nudzi, nie zapominają zaktualizować referencji krzyżowych i mogą obsłużyć 15 plików na raz."
|
||||
|
||||
**Nużąca część wiedzy zostaje w końcu rozwiązana.**
|
||||
|
||||
Twoja praca zmienia się z *archiwizowania na* *myślenie*. Od *organizacji* po *kuratorstwo*. Od *wyszukiwania* po *zadawanie lepszych pytań*. LLM zajmuje się całą resztą.
|
||||
|
||||
## 🎗️Bibliografia
|
||||
|
||||
- **Tweet Karpathy'ego:** [https://x.com/karpathy/status/2039805659525644595](https://x.com/karpathy/status/2039805659525644595)
|
||||
- **Oryginalna koncepcja Karpathy'ego:** [gist.github.com/karpathy/442a6bf555914893e9891c11519de94f](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)
|
||||
- **Kod Claude'a:** [claude.com/claude-code](https://claude.com/claude-code)
|
||||
- **Obsydian:** [obsidian.md](https://obsidian.md/)
|
||||
- **Źródło demo 1 — "Gorzka lekcja" Suttona:** [incompleteideas.net/IncIdeas/BitterLesson.html](http://www.incompleteideas.net/IncIdeas/BitterLesson.html)
|
||||
- **Demo źródło 2 — "Software 2.0" Karpathy'ego:** [karpathy.medium.com/software-2–0-a64152b37c35](https://karpathy.medium.com/software-2-0-a64152b37c35)
|
||||
- **Wiki LLM Karpathy'ego zmienia wszystko:** [https://youtu.be/04z2M\_Nv\_Rk](https://youtu.be/04z2M_Nv_Rk)
|
||||
Binary file not shown.
@@ -0,0 +1,756 @@
|
||||
---
|
||||
title: "Jak wdrożyć autoresearch:"
|
||||
source: "https://x.com/hooeem/status/2030720614752039185"
|
||||
author:
|
||||
- "[[@hooeem]]"
|
||||
published: 2026-03-07
|
||||
created: 2026-05-14
|
||||
description: "Chcesz wdrożyć autoresearch Andrew Karpathy'ego, który pozwala agentom prowadzić eksperymenty badawcze, podczas gdy śpisz, z dowolnym prompt..."
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
|
||||
|
||||
Chcesz wdrożyć autoresearch Andrew Karpathy'ego, który pozwala agentom prowadzić eksperymenty badawcze, podczas gdy śpisz, z dowolnym promptem, ale nie wiesz jak, przeczytaj to.
|
||||
|
||||
Więc, sprawa wygląda tak, Karpathy ([@karpathy](https://x.com/@karpathy)) wydał coś świetnego:
|
||||
|
||||
> 7 marca
|
||||
>
|
||||
> Zapakowałem projekt "autoresearch" do nowego, samodzielnego repozytorium minimalnego, jeśli ktoś chciałby zagrać w weekend. To w zasadzie rdzeń treningowy nanochat LLM oszczącony do pojedynczej wersji GPU, jednego pliku ~630 linii kodu, a następnie: - człowiek iteruje na
|
||||
|
||||
Teraz ja, około 18 tysięcy innych, którzy dodaliśmy ten post do zakładek, i chociaż są instrukcje na [github](https://github.com/karpathy/autoresearch) link ([tutaj](https://github.com/karpathy/autoresearch)):
|
||||
|
||||
|
||||
|
||||
help me
|
||||
|
||||
Potrzebuję, żeby te informacje były podsumowane z jasnymi, krok po kroku instrukcjami do przestrzegania, a poza tym nie mam karty graficznej Nvidia, tylko Maca, potrzebowałem pomocy, więc poprosiłem supergrok, opus 4.6 i GPT 5.4, żeby POMOGLI BRATU...
|
||||
|
||||
Pomyślałem (bo jest 18 tysięcy innych, którzy dodali artykuł do zakładek), że inni czują dokładnie to samo (jeśli nie, nie czytaj tego artykułu), więc pomyślałem, że przynajmniej podzielę się tym tutaj:
|
||||
|
||||
## CZĘŚĆ 1: Co to jest i dlaczego powinno cię to obchodzić?
|
||||
|
||||
7 marca 2026 roku Andrej Karpathy, jeden z najsłynniejszych badaczy AI (były dyrektor AI w Tesli, współzałożyciel OpenAI), opublikował aktualizację projektu o nazwie **autoresearch**.
|
||||
|
||||
Oto pomysł w najprostszych możliwych słowach:
|
||||
|
||||
Wyobraź sobie, że masz małą AI, malutki model językowy, który ledwo potrafi łączyć słowa. Aby było mądrzej, ludzki badacz zwykle siedziałby przy komputerze godzinami: zmieniał ustawienie, przeprowadzał test, sprawdzał, czy pomagał, i powtarzał. Raz za razem. To nużące.
|
||||
|
||||
**Autoresearch zastępuje ludzkiego badacza agentem AI.** Proste instrukcje piszesz prostym angielskim w pliku tekstowym. Następnie agent AI robi to w pętli automatycznie, przez całą noc:
|
||||
|
||||
1. Przeczyta twoje instrukcje
|
||||
2. Zmienia kod treningowy (pojedynczy plik zwany [train.py](https://train.py/))
|
||||
3. Uruchamia 5-minutowy test treningowy na GPU twojego komputera (potężny układ obsługujący ciężką matematykę)
|
||||
4. Mierzy wynik, czyli wynik zwany **val\_bpb** (niższa liczba = mądrzejszy model)
|
||||
5. Jeśli wynik się poprawi, reszta zostaje zapisana. Jeśli nie, to wyrzuca go
|
||||
6. Powtarza około **12 eksperymentów na godzinę**, około **100 w nocy**
|
||||
|
||||
Budzisz się z prawdziwym, mierzalnym postępem, nie kiwając palcem.
|
||||
|
||||
Karpathy opisuje to jako "częściowo kod, częściowo science fiction i szczyptę psychozy." Każda kropka na jego wykresie postępu to jeden kompletny, pięciominutowy eksperyment, a model stopniowo się poprawia, gdy kropki się kumulują.
|
||||
|
||||
**Dlaczego to ma znaczenie poza samym eksperymentem:** To jest przedsmak tego, dokąd zmierzają badania nad AI. Zamiast ludzi ręcznie dostosowujących ustawienia, agenci AI prowadzą eksperymenty autonomicznie. Nie tylko prowadzisz fajną demonstrację, ale doświadczasz, jak w praktyce wyglądają zautomatyzowane badania AI.
|
||||
|
||||
Dobrze, reszta tego artykułu (Część 2,3,4,5,6,7,8,9,10,11,12,13) przedstawi wszystko z dużą ilością szczegółów. Chciałem też przedstawić uproszczoną wersję, którą umieszczę w tym kodzie markdown, który możecie skopiować i wkleić, co przechodzi od razu do sedna. Możesz przewinąć do części 2, ale chciałem dać ci taką opcję tutaj:
|
||||
|
||||
```markdown
|
||||
# Run Karpathy's Autoresearch Today
|
||||
|
||||
### An AI runs experiments on your computer all night while you sleep. Here's how to set it up.
|
||||
|
||||
---
|
||||
|
||||
## Step 0: Can Your Computer Do This?
|
||||
|
||||
**You need one of these:**
|
||||
|
||||
- **A Windows or Linux PC with an NVIDIA graphics card** (like an RTX 3060, 4070, or 4090)
|
||||
- **A Mac with an M1, M2, M3, or M4 chip** (any Mac bought since late 2020)
|
||||
|
||||
**To check on Windows:** Press the Windows key, type "Command Prompt", open it, type \`nvidia-smi\`, press Enter. If you see your GPU name, you're good.
|
||||
|
||||
**To check on Mac:** Click the Apple menu → About This Mac. Look for "Chip." If it says M1, M2, M3, or M4 (or any variant like M2 Pro, M3 Max), you're good. If it says Intel, this won't work.
|
||||
|
||||
**If you don't have either of these, stop here** — this project requires a powerful GPU to run.
|
||||
|
||||
---
|
||||
|
||||
## Step 1: Open Your Terminal
|
||||
|
||||
This is a text window where you type commands. Every computer has one.
|
||||
|
||||
- **Mac:** Press \`Cmd + Space\`, type **Terminal**, press Enter
|
||||
- **Windows:** Press the Windows key, type **PowerShell**, press Enter
|
||||
- **Linux:** Press \`Ctrl + Alt + T\`
|
||||
|
||||
You'll use this window for every step below.
|
||||
|
||||
---
|
||||
|
||||
## Step 2: Install Two Small Tools
|
||||
|
||||
**Install uv** (this handles Python and all dependencies automatically):
|
||||
|
||||
Mac/Linux:
|
||||
|
||||
curl -LsSf https://astral.sh/uv/install.sh | sh
|
||||
|
||||
Windows (PowerShell):
|
||||
|
||||
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
|
||||
|
||||
**Install Claude Code** (the AI agent that runs experiments for you — requires a Claude Pro or Max subscription at $20–100/month):
|
||||
|
||||
Mac/Linux:
|
||||
|
||||
curl -fsSL https://claude.ai/install.sh | bash
|
||||
|
||||
Windows (PowerShell):
|
||||
|
||||
irm https://claude.ai/install.ps1 | iex
|
||||
|
||||
**Now close your Terminal and open a fresh one.** This is essential — skip it and the next steps will fail.
|
||||
|
||||
> **Don't want to pay for Claude Code?** Download Cursor for free from cursor.com instead. It does the same job but with a visual interface rather than the Terminal. The rest of this guide still applies — you'll just use Cursor's chat panel instead of Claude Code.
|
||||
|
||||
---
|
||||
|
||||
## Step 3: Install Git (If You Don't Have It)
|
||||
|
||||
Git tracks all the experiments. Check if you already have it:
|
||||
|
||||
git --version
|
||||
|
||||
If you see a version number, skip ahead. If not:
|
||||
|
||||
- **Mac:** It will prompt you to install Xcode Command Line Tools — click Install
|
||||
- **Windows:** Download from https://git-scm.com/download/win and run the installer (accept all defaults)
|
||||
- **Linux:** \`sudo apt install git\`
|
||||
|
||||
---
|
||||
|
||||
## Step 4: Download the Project
|
||||
|
||||
**Mac users** — you need the Mac-compatible version:
|
||||
|
||||
cd ~/Desktop
|
||||
git clone https://github.com/miolini/autoresearch-macos.git
|
||||
cd autoresearch-macos
|
||||
|
||||
**Windows/Linux users** — you need the original:
|
||||
|
||||
cd ~/Desktop
|
||||
git clone https://github.com/karpathy/autoresearch.git
|
||||
cd autoresearch
|
||||
|
||||
> On Windows, replace \`~/Desktop\` with \`%USERPROFILE%\Desktop\`
|
||||
|
||||
---
|
||||
|
||||
## Step 5: Set Everything Up
|
||||
|
||||
Run these three commands one at a time:
|
||||
|
||||
uv sync
|
||||
|
||||
*(Installs Python and all packages. Takes a few minutes the first time.)*
|
||||
|
||||
uv run prepare.py
|
||||
|
||||
*(Downloads training data. Takes about 2 minutes. Only needed once.)*
|
||||
|
||||
uv run train.py
|
||||
|
||||
*(Runs one 5-minute test. If it finishes and shows a number next to "val_bpb" — you're ready.)*
|
||||
|
||||
**If you get a red error:** Copy the entire error message, paste it into claude.ai, and ask "What does this mean and how do I fix it?" You'll get a direct answer.
|
||||
|
||||
---
|
||||
|
||||
## Step 6: Let the AI Run All Night
|
||||
|
||||
Make sure you're in the project folder, then launch Claude Code:
|
||||
|
||||
claude
|
||||
|
||||
It will ask you to log in the first time — follow the browser prompt.
|
||||
|
||||
Once you see the Claude Code prompt, type this:
|
||||
|
||||
Hi have a look at program.md and let's kick off a new experiment! Let's do the setup first.
|
||||
|
||||
**That's it.** Claude will start reading the project, modifying the training code, running 5-minute experiments, keeping what works, discarding what doesn't, and repeating. Minimise the window and go to sleep.
|
||||
|
||||
You'll wake up to dozens of successful experiments and a smarter model than you started with.
|
||||
|
||||
> **Using Cursor instead?** Open the project folder in Cursor (File → Open Folder), then type the same message into Cursor's AI chat panel on the right side.
|
||||
|
||||
---
|
||||
|
||||
## Quick Answers
|
||||
|
||||
**What is val_bpb?** A score measuring how smart the model is. Lower = better.
|
||||
|
||||
**What is train.py?** The single file containing all the AI training code. The AI agent modifies this file during experiments.
|
||||
|
||||
**What is program.md?** Your instruction file for the AI agent. This is the only file you ever need to edit — it tells the agent what to try.
|
||||
|
||||
**Is the Mac version safe?** Yes. Karpathy links to it from his own project page. The developer (Artem Andreenko) has 167 public projects on GitHub and a years-long public track record. The fork announcement got 70,000+ views on X. The entire codebase is about 630 lines — you can read the whole thing in 20 minutes.
|
||||
|
||||
**How many experiments will it run overnight?** About 100 (roughly 12 per hour).
|
||||
|
||||
**Do most experiments succeed?** No. Most fail. That's normal. The agent automatically keeps the wins and throws away the losses. Out of 100 experiments, maybe 10–20 will be improvements.
|
||||
|
||||
**What does it cost?** The code is free. Claude Code requires Claude Pro ($20/month) or Max ($100/month). Cursor has a free tier if you run experiments manually.
|
||||
|
||||
---
|
||||
|
||||
## If Something Goes Wrong
|
||||
|
||||
| Problem | Fix |
|
||||
|---|---|
|
||||
| \`command not found: uv\` | Close Terminal, open a new one |
|
||||
| \`command not found: git\` | Install git (see Step 3) |
|
||||
| CUDA / GPU error (Windows/Linux) | Search YouTube: "install CUDA toolkit [your GPU]" |
|
||||
| MPS / Metal error (Mac) | Make sure you downloaded the Mac fork, not the original |
|
||||
| Out of memory | Your GPU needs more VRAM. The agent usually adapts automatically |
|
||||
| Claude Code won't authenticate | You need a paid Claude subscription ($20/month minimum) |
|
||||
|
||||
---
|
||||
|
||||
**Links:**
|
||||
Original (Windows/Linux): https://github.com/karpathy/autoresearch
|
||||
Mac version: https://github.com/miolini/autoresearch-macos
|
||||
Cursor: https://cursor.com
|
||||
Claude Code: https://code.claude.com
|
||||
|
||||
---
|
||||
|
||||
*Total setup time: about 30 minutes. Then it runs by itself.*
|
||||
```
|
||||
|
||||
## CZĘŚĆ 2: Czy masz odpowiedni komputer?
|
||||
|
||||
To jest najważniejsza część. **Jeśli Twój komputer nie spełnia tych wymagań, projekt nie będzie działał.** Przeczytaj to uważnie przed instalacją czegokolwiek.
|
||||
|
||||
Użytkownicy Windows lub Linux
|
||||
|
||||
Potrzebujesz:
|
||||
|
||||
- **Karta graficzna NVIDIA (GPU):** przykłady: RTX 3060, RTX 3070, RTX 4070, RTX 4090 lub dowolna karta NVIDIA z ostatnich kilku lat
|
||||
- **Co najmniej 10–20 GB wolnej przestrzeni na dysku**
|
||||
- **Połączenie internetowe**
|
||||
- **Windows 10 lub 11** albo dystrybucję **Linuksa**, jak Ubuntu
|
||||
|
||||
**Jak sprawdzić, czy masz kartę graficzną NVIDIA (Windows):**
|
||||
|
||||
1. Naciśnij **klawisz Windows** na klawiaturze
|
||||
2. Wpisz **Command Prompt** i otwórz go (to czarne okno, w którym wpisujesz tekst)
|
||||
3. Wpisz dokładnie to i naciśnij Enter: nvidia-smi
|
||||
4. Jeśli pokazuje nazwę GPU i wersję sterownika, wszystko w porządku, kontynuuj
|
||||
5. Jeśli pojawi się komunikat "polecenie nie znalezione" lub pojawi się błąd, to albo nie masz karty graficznej NVIDIA, albo musisz najpierw zainstalować sterowniki NVIDIA
|
||||
|
||||
**Brak karty graficznej NVIDIA?** Oryginalny projekt autoresearch nie zadziałał dla ciebie na Windows/Linux. Ale jeśli masz Maca, przeczytaj następną część.
|
||||
|
||||
Użytkownicy Maca
|
||||
|
||||
Oryginalny kod Karpathy obsługuje tylko karty graficzne NVIDIA, których Maci nie posiadają. Jednak deweloper o imieniu Artem Andreenko stworzył **wersję kompatybilną z Maciem**, która działa z własnymi układami Apple.
|
||||
|
||||
Potrzebujesz:
|
||||
|
||||
- **Apple Silicon Mac,** każdy Mac z układem M1, M2, M3 lub M4
|
||||
- **Minimum 16 GB pamięci** (32 GB lub więcej to lepsze dla większych eksperymentów)
|
||||
- **Co najmniej 10–20 GB wolnej przestrzeni na dysku**
|
||||
- **Połączenie internetowe**
|
||||
|
||||
**Jak sprawdzić chip w Macu:**
|
||||
|
||||
1. Kliknij **menu Apple** (ikona Apple w lewym górnym rogu ekranu)
|
||||
2. **Kliknij O tym Macu**
|
||||
3. Szukaj **"Chip",** powinno być tam M1, M2, M3, M4 lub jakiś wariant jak M2 Pro, M3 Max itd.
|
||||
4. Jeśli zamiast tego pojawi **się "Intel",** niestety ten projekt nie będzie dla ciebie dobrze działał
|
||||
|
||||
**Każdy MacBook Air, MacBook Pro, Mac Mini, iMac, Mac Studio i Mac Pro sprzedawany od końca 2020 roku posiada układ Apple Silicon.** Jeśli kupiłeś Maca w ciągu ostatnich 5 lat, prawie na pewno wszystko jest w porządku.
|
||||
|
||||
**Ważne:** Na Macu pobierasz z innego linku (fork macOS) zamiast oryginalnego Karpathy. Polecenia konfiguracyjne są niemal identyczne, zmienia się tylko źródło pobierania.
|
||||
|
||||
Tabela szybkiego dostępu
|
||||
|
||||
|
||||
|
||||
## CZĘŚĆ 3: "Czy wersja na Maca jest bezpieczna?"
|
||||
|
||||
Mądre pytanie. Zawsze warto dwa razy się zastanowić, zanim uruchomisz kod z internetu. Oto, co sprawdziłem:
|
||||
|
||||
**Sam Karpathy do niego odwołuje linki.** Jego własna strona autoresearch README bezpośrednio wspomina fork macOS (miolini/autoresearch-macos) w sekcji platform. Zaprosił społeczność do stworzenia forków dla innych platform i podlinkował tę platformę. To najbliższe oficjalnemu rekomendacji, jakie można dostać.
|
||||
|
||||
**To prawdziwy fork GitHuba.** GitHub publicznie oznacza to jako "rozgałęzione z karpathy/autoresearch." Każda zmiana wprowadzona przez dewelopera względem oryginału jest widoczna i łatwa do śledzenia. Nic nie jest ukryte.
|
||||
|
||||
**Deweloper to prawdziwa, ugruntowana osoba.** Artem Andreenko (nazwa użytkownika: miolini) ma 167 publicznych projektów na GitHub, siedzi w San Diego i prowadzi firmę o nazwie SentientWave. Ma wieloletnie doświadczenie w programowaniu publicznym, narzędziach Go, rozszerzeniach do przeglądarek, testach sieciowych. To nie jest anonimowe ani jednorazowe konto.
|
||||
|
||||
**Ogłoszenie forku było bardzo publiczne.** Jego ogłoszenie na X (Twitter) było bezpośrednią odpowiedzią na oryginalny post Karpathy'ego i zdobyło około 70 000 wyświetleń, 58 retweetów i 781 polubień. Tysiące programistów zobaczyło i dokładnie przeanalizowało kod.
|
||||
|
||||
**Zmiany są niewielkie i dobrze** zrozumiane. Fork zastępuje bibliotekę wyłącznie dla NVIDIA (FlashAttention-3) na wbudowaną wersję PyTorch oraz dodaje specyficzne dla Apple Metal poprawki pamięci i kompilacji. To standardowe, nudne adaptacje, nie egzotyczne czy podejrzane.
|
||||
|
||||
**Cały kod jest malutki.** Plik treningowy ma około 630 linii Pythona. Możesz przeczytać wszystko w 20 minut. Nie ma gdzie ukryć się złośliwy kod.
|
||||
|
||||
**Dodatkowy krok bezpieczeństwa:** Po pobraniu otwórz folder w Claude Code i zapytaj: "Przeczytaj każdy plik w tym repozytorium. Czy jest coś podejrzanego, jakieś ukryte wywołania sieciowe, zbieranie danych lub kod, który robi coś więcej niż tylko trenowanie modelu językowego?" W tak małym projekcie audyt trwa około 30 sekund.
|
||||
|
||||
**Podsumowując:** To legalny, popierany przez społeczność fork powiązany z Karpathy przez prawdziwego dewelopera z publiczną historią. To tak bezpieczne, jak można znaleźć oprogramowanie open source dla czegoś tak nowego.
|
||||
|
||||
## CZĘŚĆ 4: Żargonowy łamacz (Przeczytaj to)
|
||||
|
||||
Zanim cokolwiek zainstalujesz, oto słownik w prostym języku, żeby nic cię nie zaskoczyło:
|
||||
|
||||
**Terminal:** Okno tekstowe, w którym wpisujesz polecenia zamiast klikać przyciski. Każdy komputer ma taki wbudowany. Na Macu nazywa się to "Terminal". Na Windows nazywa się to "Wiersz poleceń" lub "PowerShell". Pomyśl o tym jak o pisaniu SMS-a do komputera, a on odpisuje.
|
||||
|
||||
**GPU:** Jednostka przetwarzania grafiki. Potężny układ scalony w twoim komputerze, który obsługuje ciężką matematykę. Trening AI w dużej mierze opiera się na GPU. Twój zwykły procesor (CPU) to mózg; GPU to siła napędowa.
|
||||
|
||||
**CUDA:** Oprogramowanie NVIDIA pozwalające programom korzystać z kart NVIDIA do matematyki. Potrzebujesz tego na Windows/Linux. Pomyśl o tym jak o tłumaczu między kodem treningowym a sprzętem NVIDIA.
|
||||
|
||||
**Metal / MPS:** Wersja CUDA od Apple. Jest wbudowany w każdego Maca z Apple Silicon. Nie musisz nic instalować, po prostu działa.
|
||||
|
||||
**Git:** System śledzenia zmian w plikach w czasie. Pomyśl o tym jak o "punktach zapisu" w grze wideo. Za każdym razem, gdy agent AI znajduje poprawę, tworzy punkt zapisu. Jeśli kolejny eksperyment się nie powiedzie, można wrócić do ostatniego dobrego zapisu.
|
||||
|
||||
**uv:** Małe, darmowe narzędzie, które automatycznie instaluje Pythona (język programowania używany w tym projekcie) oraz całe inne oprogramowanie potrzebne przez projekt. To znacznie ułatwia przygotowanie. Bez UV trzeba by zainstalować kilka rzeczy osobno.
|
||||
|
||||
**val\_bpb:** "Bity walidacyjne na bajt." Jeden wynik, który mierzy, jak inteligentny jest model AI. **Niższe liczby = mądrzejszy model.** To jest liczba, którą agent AI próbuje obniżyć z dnia na dzień.
|
||||
|
||||
[train.py](https://train.py/)**:** Pojedynczy plik Pythona, który zawiera cały kod treningowy AI. To jedyny plik, który agent AI modyfikuje podczas eksperymentów. Zawiera architekturę modelu, ustawienia optymalizatorów, pętlę treningową, wszystko.
|
||||
|
||||
**program.md:** Plik instrukcji, który piszesz dla agenta AI. To jedyny plik, który ty (człowiek) musisz kiedykolwiek edytować. Mówi agentowi, jakie eksperymenty ma wypróbować, co priorytetowo traktować i jak się zachowywać. Pomyśl o tym jak o odprawie misji, którą przekazujesz swojemu niestrudzonemu asystentowi laboratoryjnemu przed snem.
|
||||
|
||||
**Repozytorium / Repozytorium:** Folder projektów na GitHubie. Kiedy ludzie mówią "pobierz repozytorium", mają na myśli "pobierz folder projektu".
|
||||
|
||||
**Fork:** A copy of someone else's project that you can modify independently. The Mac version is a "fork" of Karpathy's original, same foundation, adapted for different hardware.
|
||||
|
||||
**Clone:** Downloading a copy of a project from GitHub to your computer using a Terminal command.
|
||||
|
||||
## PART 5: What You Need to Install
|
||||
|
||||
You need exactly **three free tools** plus **one AI tool** (which requires a paid subscription). Here's each one and how to get it.
|
||||
|
||||
**Tool 1: Terminal (You Already Have This)**
|
||||
|
||||
Every computer comes with a Terminal built in. You just need to open it.
|
||||
|
||||
- **Mac:** Press Cmd + Space (this opens Spotlight search), type **Terminal**, press Enter. A window with a blinking text cursor will appear
|
||||
- **Windows:** Press the **Windows key**, type **Command Prompt** or **PowerShell**, press Enter. A window (usually black or blue) with a blinking text cursor will appear
|
||||
- **Linux:** Press Ctrl + Alt + T. A terminal window will appear
|
||||
|
||||
This is where you'll type all the commands in this guide. When this guide says "open Terminal," it means open this window.
|
||||
|
||||
**Tool 2: Git**
|
||||
|
||||
Git is the save-point system that tracks every experiment. You need it installed.
|
||||
|
||||
**Mac:** Git usually comes pre-installed. To check, open Terminal and type:
|
||||
|
||||
```markdown
|
||||
git --version
|
||||
```
|
||||
|
||||
If you see a version number like git version 2.39.0, you're done. If macOS asks you to install "Xcode Command Line Tools," click **Install** and wait a few minutes. That will install git for you.
|
||||
|
||||
**Windows:**
|
||||
|
||||
1. Go to [https://git-scm.com/download/win](https://git-scm.com/download/win) in your web browser
|
||||
2. Download the installer
|
||||
3. Run it and **accept all the default settings** (just click Next, Next, Next, Install)
|
||||
4. When it's done, close and reopen Command Prompt
|
||||
5. Type git --version to confirm it worked
|
||||
|
||||
**Linux (Ubuntu/Debian):** Open Terminal and type:
|
||||
|
||||
```markdown
|
||||
sudo apt install git
|
||||
```
|
||||
|
||||
Enter your password when asked.
|
||||
|
||||
**Tool 3: uv (The Automatic Installer)**
|
||||
|
||||
This tiny tool will install Python and every package the project needs, automatically. You do not need to install Python separately. uv handles everything.
|
||||
|
||||
**Mac or Linux:** Open Terminal and paste this exact command, then press Enter:
|
||||
|
||||
```markdown
|
||||
curl -LsSf https://astral.sh/uv/install.sh | sh
|
||||
```
|
||||
|
||||
**Windows:** Open PowerShell (not Command Prompt) and paste:
|
||||
|
||||
```markdown
|
||||
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
|
||||
```
|
||||
|
||||
**Critical step after installing uv:** Close your Terminal/PowerShell window completely. Then open a brand new one. This is essential, the new window will recognise the uv command. If you skip this step, your computer won't know uv exists yet.
|
||||
|
||||
To verify it worked, type in the new window:
|
||||
|
||||
```markdown
|
||||
uv --version
|
||||
```
|
||||
|
||||
You should see a version number.
|
||||
|
||||
Tool 4: Your AI Agent (The Brain That Runs the Experiments)
|
||||
|
||||
The AI agent is the intelligence that actually reads your instructions, modifies the code, runs experiments, and decides what to keep or discard. You need one of the following options:
|
||||
|
||||
Option A: Claude Code, Best for Full Autopilot
|
||||
|
||||
**What it is:** A command-line tool made by Anthropic (the company behind Claude). It runs directly in your Terminal, can read and write files, run commands, and use git, exactly what autoresearch needs for the fully autonomous loop.
|
||||
|
||||
**What it costs:** Requires a paid subscription, Claude Pro ($20/month) or Claude Max ($100 or $200/month). A free Claude account will not work with Claude Code.
|
||||
|
||||
**How to install (Mac or Linux):**
|
||||
|
||||
```markdown
|
||||
curl -fsSL https://claude.ai/install.sh | bash
|
||||
```
|
||||
|
||||
**How to install (Windows or PowerShell):**
|
||||
|
||||
```markdown
|
||||
irm https://claude.ai/install.ps1 | iex
|
||||
```
|
||||
|
||||
After installing, close and reopen your Terminal. Then type:
|
||||
|
||||
```markdown
|
||||
claude --version
|
||||
```
|
||||
|
||||
If you see a version number, the installation worked.
|
||||
|
||||
**First time you run it:** When you type claude for the first time, it will open your web browser and ask you to log in to your Anthropic account. Follow the prompts to authenticate. This only happens once.
|
||||
|
||||
Option B: Cursor, Best for Visual Learners
|
||||
|
||||
**What it is:** A free AI-powered code editor. It looks like a normal text editor but has an AI chat panel built into the right side. Under the hood, it uses Claude or other AI models.
|
||||
|
||||
**What it costs:** Has a free tier with limited AI usage. Pro plan is $20/month for heavier use.
|
||||
|
||||
**How to install:**
|
||||
|
||||
1. Go to [https://cursor.com](https://cursor.com/) in your web browser
|
||||
2. Download the installer for your operating system
|
||||
3. Install it like any other app (drag to Applications on Mac, run the installer on Windows)
|
||||
|
||||
Cursor is easier if you like seeing files visually and chatting with the AI in a sidebar. However, the fully autonomous overnight loop works more smoothly with Claude Code.
|
||||
|
||||
Option C: [Claude.ai](https://claude.ai/) Chat, Manual Only (What You're Reading This In)
|
||||
|
||||
You can use the [Claude.ai](https://claude.ai/) chat interface to troubleshoot errors, get explanations, or ask for code change suggestions. But you cannot automate the loop, you'd have to copy-paste code and results back and forth manually. This works for learning, but it's not what the project was designed for.
|
||||
|
||||
**Can you use Claude with autoresearch?** Yes, Karpathy says so himself. His README explicitly says: "Simply spin up your Claude/Codex or whatever you want in this repo."
|
||||
|
||||
This bit is up to you, you can use Claude Code, Codex, Cursor etc. The choice is yours here.
|
||||
|
||||
## PART 6: Step-by-Step Setup
|
||||
|
||||
Pick your operating system below and follow every command exactly. Copy-paste is your friend, don't try to type these from memory.
|
||||
|
||||
> Setup for Mac (Apple Silicon)
|
||||
|
||||
**Step 1: Open Terminal**
|
||||
|
||||
Press Cmd + Space, type **Terminal**, press Enter.
|
||||
|
||||
**Step 2: Download the Mac version of autoresearch**
|
||||
|
||||
Type these commands one at a time, pressing Enter after each:
|
||||
|
||||
```markdown
|
||||
cd ~/Desktop
|
||||
git clone https://github.com/miolini/autoresearch-macos.git
|
||||
cd autoresearch-macos
|
||||
```
|
||||
|
||||
What this does: Goes to your Desktop, downloads the Mac-compatible version of the project, and enters the project folder.
|
||||
|
||||
**If you'd rather not use git:** Go to [https://github.com/miolini/autoresearch-macos](https://github.com/miolini/autoresearch-macos) in your web browser, click the green **Code**button, click **Download ZIP**, unzip it to your Desktop. Then in Terminal type:
|
||||
|
||||
```markdown
|
||||
cd ~/Desktop/autoresearch-macos-master
|
||||
```
|
||||
|
||||
**Step 3: Install all the software the project needs**
|
||||
|
||||
```markdown
|
||||
uv sync
|
||||
```
|
||||
|
||||
This downloads and installs Python, PyTorch, and everything else automatically. The first time takes a few minutes, you'll see progress bars. Be patient.
|
||||
|
||||
**Step 4: Download the training data**
|
||||
|
||||
```markdown
|
||||
uv run prepare.py
|
||||
```
|
||||
|
||||
This downloads the text data the model will learn from and builds a tokenizer (a tool that chops text into small pieces the model can process). Takes about 2 minutes. You only ever need to do this once.
|
||||
|
||||
**Step 5: Run one test training to make sure everything works**
|
||||
|
||||
```markdown
|
||||
uv run train.py
|
||||
```
|
||||
|
||||
This runs a single 5-minute training session on your Mac's GPU using Metal. You should see:
|
||||
|
||||
- Numbers scrolling by (this is normal, it's showing training progress)
|
||||
- After about 5–7 minutes (including startup time), it finishes
|
||||
- It displays a val\_bpb score at the end
|
||||
|
||||
**If it finishes without big red error messages, your setup is complete.** You're ready for the fun part.
|
||||
|
||||
**If you see errors:** Copy the entire red error text, paste it into [Claude.ai](https://claude.ai/) (this chat), and ask: "What does this error mean and how do I fix it on a Mac?" You'll get a direct answer.
|
||||
|
||||
> Setup for Windows (NVIDIA GPU)
|
||||
|
||||
**Step 1: Open Command Prompt or PowerShell**
|
||||
|
||||
Press the **Windows key**, type **Command Prompt**, press Enter.
|
||||
|
||||
**Step 2: Download autoresearch**
|
||||
|
||||
```markdown
|
||||
cd %USERPROFILE%\Desktop
|
||||
git clone https://github.com/karpathy/autoresearch.git
|
||||
cd autoresearch
|
||||
```
|
||||
|
||||
**If you'd rather not use git:** Go to [https://github.com/karpathy/autoresearch](https://github.com/karpathy/autoresearch) in your browser, click the green **Code** button, click **Download ZIP**, unzip to your Desktop, then:
|
||||
|
||||
```markdown
|
||||
cd %USERPROFILE%\Desktop\autoresearch-master
|
||||
```
|
||||
|
||||
**Step 3: Install all the software the project needs**
|
||||
|
||||
```markdown
|
||||
uv sync
|
||||
```
|
||||
|
||||
**Step 4: Download the training data**
|
||||
|
||||
```markdown
|
||||
uv run prepare.py
|
||||
```
|
||||
|
||||
**Step 5: Run one test training**
|
||||
|
||||
```markdown
|
||||
uv run train.py
|
||||
```
|
||||
|
||||
If it finishes after about 5 minutes and shows a val\_bpb score, you're good.
|
||||
|
||||
**If you get a CUDA error or GPU error:** This means your NVIDIA drivers or CUDA toolkit aren't set up correctly. Search YouTube for "install NVIDIA CUDA toolkit \[your GPU model\] Windows" and follow a video tutorial. This is a one-time setup, and there are excellent step-by-step videos available.
|
||||
|
||||
> Setup for Linux (NVIDIA GPU)
|
||||
|
||||
**Step 1: Open Terminal**
|
||||
|
||||
Press Ctrl + Alt + T.
|
||||
|
||||
**Step 2: Download autoresearch**
|
||||
|
||||
```markdown
|
||||
cd ~/Desktop
|
||||
git clone https://github.com/karpathy/autoresearch.git
|
||||
cd autoresearch
|
||||
```
|
||||
|
||||
**Step 3–5: Same as Windows**
|
||||
|
||||
```markdown
|
||||
uv sync
|
||||
uv run prepare.py
|
||||
uv run train.py
|
||||
```
|
||||
|
||||
If it finishes and shows a val\_bpb score, your setup is complete.
|
||||
|
||||
## PART 7: Let the AI Do the Research
|
||||
|
||||
You've confirmed the test training works. Now it's time to hand the keys to the AI agent and let it run all night.
|
||||
|
||||
Full Autopilot with Claude Code (Recommended)
|
||||
|
||||
**Step 1:** Open Terminal and go to your project folder:
|
||||
|
||||
Mac:
|
||||
|
||||
```markdown
|
||||
cd ~/Desktop/autoresearch-macos
|
||||
```
|
||||
|
||||
Windows:
|
||||
|
||||
```markdown
|
||||
cd %USERPROFILE%\Desktop\autoresearch
|
||||
```
|
||||
|
||||
Linux:
|
||||
|
||||
```markdown
|
||||
cd ~/Desktop/autoresearch
|
||||
```
|
||||
|
||||
**Step 2:** Launch Claude Code:
|
||||
|
||||
The first time, it will ask you to authenticate in your browser. Follow the prompts and log in to your Anthropic account. Once you see the Claude Code prompt (a cursor waiting for your input), type this exact message:
|
||||
|
||||
```markdown
|
||||
Hi have a look at program.md and let's kick off a new experiment! Let's do the setup first.
|
||||
```
|
||||
|
||||
**Step 3:** Claude Code will now automatically:
|
||||
|
||||
- Read the program.md instruction file
|
||||
- Read all the project files to understand the codebase
|
||||
- Create a git branch (a separate save-point track) for the experiment run
|
||||
- Start modifying [train.py](https://train.py/) with its first experimental idea
|
||||
- Run the 5-minute training
|
||||
- Check the val\_bpb score
|
||||
- If the score improved, save the change with git. If not, discard it
|
||||
- Move on to the next experiment and repeat
|
||||
|
||||
**Step 4:** Minimise the window and go to bed. Or go cook dinner. Or watch a film. The AI agent will keep running experiments all night without you.
|
||||
|
||||
**Pro tip:** To make it fully autonomous without pausing to ask you questions, you can tell it at the start: "Run fully autonomously. Don't ask for confirmation between experiments. Keep going until I come back."
|
||||
|
||||
Semi-Manual with Cursor (Good for Learning)
|
||||
|
||||
**Step 1:** Open Cursor. Click **File → Open Folder** and navigate to your autoresearch folder on the Desktop.
|
||||
|
||||
**Step 2:** In the file list on the left, click on program.md to open it. Read through it, it's written in plain English.
|
||||
|
||||
**Step 3:** In Cursor's AI chat panel (usually on the right side), type:
|
||||
|
||||
```markdown
|
||||
Hi have a look at program.md and let's kick off a new experiment! Let's do the setup first.
|
||||
```
|
||||
|
||||
**Step 4:** The AI will suggest changes to [train.py](https://train.py/). Click the accept/apply button to make the changes.
|
||||
|
||||
**Step 5:** Open Terminal, navigate to your project folder, and run:
|
||||
|
||||
```markdown
|
||||
uv run train.py
|
||||
```
|
||||
|
||||
**Step 6:** When it finishes (about 5 minutes), tell the AI in Cursor's chat what the val\_bpb score was. It will decide whether to keep or discard the change, then suggest the next experiment.
|
||||
|
||||
**Step 7:** Repeat. As you get comfortable, Cursor's AI can handle more of the loop automatically.
|
||||
|
||||
Fully Manual with [Claude.ai](https://claude.ai/) Chat
|
||||
|
||||
If you don't have Claude Code or Cursor:
|
||||
|
||||
1. Run uv run [train.py](https://train.py/) in your Terminal
|
||||
2. Copy the output (especially the val\_bpb score) and paste it into [Claude.ai](https://claude.ai/)
|
||||
3. Ask Claude to suggest the next experiment, what to change in [train.py](https://train.py/) and why
|
||||
4. Make the change in a text editor (any text editor works, TextEdit on Mac, Notepad on Windows)
|
||||
5. Run uv run [train.py](https://train.py/) again
|
||||
6. Repeat
|
||||
|
||||
This is the slowest option but works perfectly for understanding how the process works.
|
||||
|
||||
## PART 8: What You'll See When You Wake Up
|
||||
|
||||
After a night of autonomous experiments, here's what you'll find in your project folder:
|
||||
|
||||
**A git history full of commits.** Each commit is one successful experiment where the agent found an improvement. View it by opening Terminal, navigating to your project folder, and typing:
|
||||
|
||||
```markdown
|
||||
git log --oneline
|
||||
```
|
||||
|
||||
**A lower val\_bpb score.** The model has genuinely gotten smarter compared to where it started. The starting baseline is around 0.9979, anything lower means progress.
|
||||
|
||||
**A heavily modified** [train.py](https://train.py/)**.** The agent will have changed the training code in ways that improve performance, architecture tweaks, different optimiser settings, adjusted hyperparameters, modified batch sizes, and more.
|
||||
|
||||
**A results.tsv file.** This is a spreadsheet-style log of every experiment with its score, memory usage, and whether it was kept or discarded.
|
||||
|
||||
**An analysis.ipynb notebook.** You can open this in Cursor or Jupyter Notebook to see graphs showing how the score improved over time, each dot is one experiment.
|
||||
|
||||
## Part 9: Understanding What's Happening (Optional but Interesting)
|
||||
|
||||
You don't need to understand any of this to use autoresearch. But if you're curious:
|
||||
|
||||
**What does the agent actually change?** Everything inside [train.py](https://train.py/) is fair game. The agent might change the model's architecture (how the neural network is shaped), the optimiser (how the model learns from mistakes), the learning rate (how big the adjustments are), the batch size (how much data it looks at per step), and more.
|
||||
|
||||
**Why 5 minutes?** A fixed time budget means every experiment is directly comparable. Whether the agent tries a huge model or a tiny one, it always gets exactly 5 minutes. This forces the agent to find the most efficient configuration for your specific hardware.
|
||||
|
||||
**Why is val\_bpb the metric?** Bits per byte is a vocabulary-independent measure of how well the model predicts text. Unlike some other metrics, it works fairly even when the agent changes the tokeniser vocabulary size, making it ideal for comparing wildly different configurations.
|
||||
|
||||
**What's program.md doing?** It's the "meta-prompt", the instructions that tell the AI agent how to behave. Improving this file is your job as the human. Better instructions lead to faster research progress. Karpathy's insight is that the human is now programming the research organisation, not running individual experiments.
|
||||
|
||||
## PART 10: Tips for Getting the Best Results
|
||||
|
||||
**Start simple.** Get one manual run working first (uv run [train.py](https://train.py/)). If that doesn't work, the autonomous loop won't either. Fix the basics before going autopilot.
|
||||
|
||||
**Your one job is to improve program.md.** This is the leverage point. Add instructions like: "Try small improvements first. Focus on making val\_bpb go down. Think step by step and explain every change before making it. If an experiment direction hasn't worked after 3 attempts, try something completely different."
|
||||
|
||||
**Don't panic when experiments fail.** Most experiments will not improve the score. Out of 100 overnight experiments, maybe 10–20 will be keepers. This is completely normal, it's how research works. The agent discards failures and keeps successes automatically.
|
||||
|
||||
**Check in periodically at first.** Before trusting the full overnight run, watch the first 3–4 experiments to make sure the loop is working. If the agent is stuck or confused, adjust your program.md instructions and restart.
|
||||
|
||||
**More memory helps.** If you have a Mac with 32 GB or 64 GB of unified memory, or a GPU with lots of VRAM (like the RTX 4090 with 24 GB), the agent can explore larger models and more complex architectures within each 5-minute window.
|
||||
|
||||
## PART 11: Troubleshooting
|
||||
|
||||
**"command not found: uv"** Close your Terminal window completely and open a fresh one. After installing uv, you must start a new Terminal session for it to be recognised.
|
||||
|
||||
**"command not found: git"** You need to install git first. See Part 5, Tool 2.
|
||||
|
||||
**"CUDA error" or "no CUDA-capable device" (Windows/Linux)** Your NVIDIA drivers or CUDA toolkit aren't installed or configured. Search YouTube for "install CUDA toolkit \[your GPU model\]" and follow a step-by-step video. This is a one-time setup.
|
||||
|
||||
**"MPS error" or Metal-related error (Mac)** Make sure you downloaded the **macOS fork** (miolini/autoresearch-macos), not Karpathy's original repo. The original does not support Mac.
|
||||
|
||||
**"Out of memory" or "OOM"** Your GPU doesn't have enough memory for the model size the agent is trying. The agent should handle this automatically by trying smaller configurations, but if it keeps happening, you may need a GPU with more VRAM or more unified memory on Mac.
|
||||
|
||||
**"uv sync" is very slow or seems stuck** This is normal on the first run. It's downloading PyTorch, which is a large package (several gigabytes). Make sure your internet connection is stable and just wait.
|
||||
|
||||
**Claude Code says "authentication required" or won't start** You need a paid Claude subscription. Claude Pro is $20/month and is the minimum required. Free accounts do not work with Claude Code.
|
||||
|
||||
**The test training works but Claude Code doesn't start the experiment loop** Make sure you're in the right folder when you launch claude. Use cd to navigate to your autoresearch folder first. If Claude Code seems confused, try being more explicit: "Read the file program.md in this directory, then follow its instructions to set up and run autonomous experiments on [train.py](https://train.py/)."
|
||||
|
||||
**"Permission denied" errors** On Mac/Linux, you might need to make files executable. Try: chmod +x [train.py](https://train.py/) [prepare.py](https://prepare.py/). On Windows, make sure you're running PowerShell or Command Prompt normally (not as Administrator unless specifically needed).
|
||||
|
||||
## PART 12: What Everything Costs
|
||||
|
||||
|
||||
|
||||
**Minimum cost to run full autopilot:** $20/month for a Claude Pro subscription (for Claude Code).
|
||||
|
||||
**Minimum cost to run manually:** $0 (use Cursor's free tier and run experiments by hand).
|
||||
|
||||
## PART 13: Links and Resources
|
||||
|
||||
Original repo:
|
||||
|
||||
(Windows/Linux) [https://github.com/karpathy/autoresearch](https://github.com/karpathy/autoresearch)
|
||||
|
||||
Mac fork (Apple Silicon) [https://github.com/miolini/autoresearch-macos](https://github.com/miolini/autoresearch-macos)
|
||||
|
||||
Karpathy's announcement on X [https://x.com/karpathy/status/2030371219518931079](https://x.com/karpathy/status/2030371219518931079)
|
||||
|
||||
Mac fork announcement on X [https://x.com/miolini/status/2030402705374728218](https://x.com/miolini/status/2030402705374728218)
|
||||
|
||||
Cursor (AI code editor) [https://cursor.com](https://cursor.com/)
|
||||
|
||||
Claude Code documentation [https://code.claude.com](https://code.claude.com/)
|
||||
|
||||
uv (Python package manager) [https://astral.sh/uv](https://astral.sh/uv)
|
||||
|
||||
Git for Windows [https://git-scm.com/download/win](https://git-scm.com/download/win)
|
||||
|
||||
[Claude.ai](https://claude.ai/) (chat interface) [https://claude.ai](https://claude.ai/)
|
||||
|
||||
## OKAY I HOPE THAT HELPED! THANK YOU!
|
||||
+658
@@ -0,0 +1,658 @@
|
||||
Historia tylko dla członków
|
||||
|
||||
## Jak zbudowałem agenta newslettera AI z n8n (który oszczędza mi godziny co tydzień)
|
||||
|
||||
## Od świeżych badań po wersje Gmaila — oto jak pozwolić AI wykonać ciężką pracę, jednocześnie zachowując ludzki kontakt.
|
||||
|
||||
[
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
](https://medium.com/@amitXD?source=post_page---byline--c9e4eb252122---------------------------------------)
|
||||
|
||||
20 min czytania
|
||||
|
||||
23 sierpnia 2025
|
||||
|
||||
Jeśli kiedykolwiek próbowałeś pisać newsletter, wiesz, jak to jest trudne. Godziny marną na poszukiwaniu najnowszych wiadomości, burzy mózgów, pisaniu sekcji i formatowaniu wszystkiego, by nie wyglądało to jak niechlujny wpis na blogu w skrzynce odbiorczej subskrybentów. Gdy klikasz "Wyślij", już obawiasz się kolejnej edycji.
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
Obraz wygenerowany przez autora
|
||||
|
||||
Teraz pomyśl, czy większość tego ciężkiego dźwigania mogłaby odbywać się automatycznie. Badania przysłysły do ciebie, wygenerowane tematy, napisane sekcje, a ostateczna wersja trafiła do twojego Gmaila — już w HTML i czekająca na twoją akceptację. To nie jest futurystyczne marzenie. Dzięki **automatyzacji opartej na AI i przepływom pracy n8n** jest to dziś możliwe.
|
||||
|
||||
W tym przewodniku przedstawimy prosty, ale potężny system, który automatyzuje tworzenie newsletterów od początku do końca. Oto ogólny obraz:
|
||||
|
||||
- **Raz** w tygodniu uruchamia się wyzwalacz pracy.
|
||||
- **Agent AI** znajduje aktualne tematy i pisze sekcje.
|
||||
- **Agent redaktor** formatuje wszystko schludnie w HTML.
|
||||
- Ostateczny szkic pojawia się w **Twoim Gmailu**, gotowy do wysłania.
|
||||
|
||||
A najlepsze w tym? Cała konfiguracja działa na stosie lean tech:
|
||||
|
||||
Oto stos technologii, którego użyjemy:
|
||||
|
||||
- **N8N** — Workflow Builder.
|
||||
- **Tavily** — API badawcze.
|
||||
- **OpenRouter** — modele AI (GPT-5, Claude, GPT-4o-mini).
|
||||
- **Gmail** — do wysłania szkicu.
|
||||
|
||||
Pod koniec tego artykułu dokładnie zobaczysz, jak workflow się układa — i jak możesz zaoszczędzić godziny tygodniowo, jednocześnie dostarczając profesjonalne, angażujące newslettery.
|
||||
|
||||
## Dlaczego automatyzować tworzenie newsletterów?
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
Pisanie newslettera wydaje się proste, dopóki nie usiądziesz do tego w praktyce. Nagle żonglujesz tym:
|
||||
|
||||
- **Badania**: przeszukiwanie artykułów, wpisów na blogach i raportów.
|
||||
- **Burza mózgów**: znalezienie unikalnego punktu widzenia lub tematu, który będzie interesujący czytelników.
|
||||
- **Szkicowanie**: zamienianie notatek w dopracowane fragmenty.
|
||||
- **Formatowanie**: dbanie o to, by wyglądało to profesjonalnie w czyjejś skrzynce odbiorczej.
|
||||
|
||||
Kiedy kończysz, godziny już minęły. A jeśli prowadzisz biznes lub projekt poboczny, to czas, którego nie zawsze masz. Co gorsza, proces jest niespójny — niektóre tygodnie masz dużo energii, inne tygodnie możesz całkowicie pominąć wysyłanie. To spójność utrzymuje zaangażowanie czytelników, a ręczne procesy często przerywają ten rytm.
|
||||
|
||||
To właśnie tutaj **automatyzacja zmienia zasady** gry. Przy odpowiednim systemie:
|
||||
|
||||
- Badania odbywają się w tle, przyciągając tylko świeże i istotne treści.
|
||||
- Agenci AI generują tytuły, tematy i sekcje, więc nigdy nie zaczynasz od pustej strony.
|
||||
- Edytor AI formatuje wszystko w czysty, profesjonalny newsletter HTML.
|
||||
- Ostateczna wersja pojawia się w twoim Gmailu, gotowa do ostatnich poprawek.
|
||||
|
||||
Zamiast godzin, patrzysz na minuty — tylko przeglądasz, poprawiasz i naciskasz wyślij. Efektem **są szybsze badania, regularne publikacje i profesjonalny newsletter, który sprawia wrażenie bezwysiłkowego.**
|
||||
|
||||
## Przegląd przepływu pracy (krok po kroku)
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
10-stopniowy workflow, który przekształca badania w dopracowany szkic Gmaila.
|
||||
|
||||
Jak więc powstaje biuletyn napędzany sztuczną inteligencją? Podzielmy workflow na jasne kroki.
|
||||
|
||||
1. **Wyzwalacz — Harmonogram pracy (tygodniowo)**
|
||||
Wszystko zaczyna się od prostego wyzwalacza. Ustawiasz workflow na raz w tygodniu (na przykład w każdą niedzielę o północy). Dzięki temu proces newslettera jest spójny bez konieczności pamiętania czy ręcznego uruchamiania.
|
||||
2. **Research Past Week — Tavily pobiera najnowsze wiadomości**
|
||||
System wykorzystuje **Tavily**, narzędzie badawcze, aby przeskanować najnowsze wiadomości i artykuły z minionego tygodnia. Zamiast spędzać godziny na googlowaniu, od razu otrzymujesz wyselekcjonowany zestaw źródeł do pracy.
|
||||
3. **Utwórz tytuł i tematy — agent**
|
||||
planowania AI Następnie agent AI "planisty" przegląda badania i generuje:
|
||||
|
||||
> Kreatywny, angażujący tytuł newslettera.
|
||||
>
|
||||
> Trzy tematy skupione, które staną się głównymi sekcjami.
|
||||
|
||||
Ten krok eliminuje nielubiany problem pustych stron.
|
||||
|
||||
**4\. Badania 3 Tematy — Głębsze wglądy**
|
||||
Workflow następnie jest głębszy. Dla każdego z trzech tematów Tavily pozyskuje bardziej szczegółowe treści i surowe artykuły. Dzięki temu Twój newsletter ma głębię, a nie tylko nagłówki.
|
||||
|
||||
**5\. Write Newsletter Sections — agent**
|
||||
AI writer Agent Każdy temat trafia do dedykowanego agenta AI writer, który tworzy **osobną sekcję** newslettera. Są to następujące sekcje:
|
||||
|
||||
- Informacyjne
|
||||
- Profesjonalnie napisane
|
||||
- Cytowane z prawdziwych źródeł
|
||||
|
||||
**6\. Łączenie sekcji (3 → 1) — agregacja**
|
||||
Trzy oddzielne sekcje są połączone w jeden szkic. Teraz masz uporządkowany newsletter z wieloma segmentami, gotowy do dopracowania.
|
||||
|
||||
1. **Stylizuj i edytuj — Edytor AI**
|
||||
Tutaj dzieje się magia. Agent AI "redaktor" przyjmuje połączony szkic i:
|
||||
|
||||
- Dodaje wprowadzenie i zakończenie.
|
||||
- Wszystko formatuje w czystym HTML (nagłówki, pogrubiony tekst, klikalne linki).
|
||||
- Na dole dodaje sekcję źródeł.
|
||||
|
||||
Efektem jest profesjonalny, atrakcyjny wizualnie szkic biuletynu.
|
||||
|
||||
**8\. Send Draft — integracja**
|
||||
z Gmailem Na koniec szkic jest przesyłany do **Gmaila** jako gotowy do wysłania e-mail. Temat wiadomości jest już ustawiony (z tytułu planera AI), a treść jest sformatowana w HTML. Wystarczy, że przejrzysz, poprawisz i klikniesz "Wyślij".
|
||||
|
||||
**9\. Koniec procesu — Człowiek w pętli**
|
||||
System nie usuwa twojego głosu — po prostu odbiera powtarzalną pracę. Wciąż przeglądasz ostateczny szkic, dostosowujesz ton w razie potrzeby i zatwierdzasz przed wysłaniem.
|
||||
|
||||
## Tech stack, którego będziesz potrzebować
|
||||
|
||||
Piękno tego systemu polega na tym, że nie wymaga on ogromnej, skomplikowanej konfiguracji. Stos technologiczny jest szczupły, niezawodny i przyjazny początkującym. Oto, czego będziesz potrzebować:
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
Zdjęcie autora
|
||||
|
||||
1. **n8n — Workflow Builder**
|
||||
n8n jest kręgosłupem automatyzacji. To platforma no-code/low-code, gdzie łączysz wszystkie elementy — badania, agentów AI, formatowanie i dostarczanie e-maili. Pomyśl o tym jak o centrum sterowania, gdzie każdy etap przepływu pracy żyje.
|
||||
2. **Tavily — Research Engine**
|
||||
Tavily napędza te etapy badawcze. Pobiera najnowsze artykuły, wiadomości i treści internetowe, które agenci AI wykorzystują do generowania pomysłów i pisania sekcji. Zamiast ręcznego wyszukiwania w Google, Tavily co tydzień dostarcza systemowi świeże, istotne dane.
|
||||
3. **OpenRouter — Modele**
|
||||
AI OpenRouter daje dostęp do różnych modeli AI (GPT-5, Claude, DeepSeek i inne). W tym procesie pracy różni agenci AI wykonują specjalistyczne zadania:
|
||||
|
||||
- **Planner AI:** tworzy tytuły i tematy newsletterów.
|
||||
- **Writer AI:** tworzy szkice sekcji.
|
||||
- **Editor AI:** dopracowuje i formatuje wszystko w HTML.
|
||||
|
||||
Elastyczność tutaj pozwala eksperymentować z różnymi modelami, aż znajdziesz styl pisania najlepiej pasujący do Twojej marki.
|
||||
|
||||
4\. **poczta — Dostawa**
|
||||
Gdy newsletter jest gotowy, Gmail jest używany do stworzenia szkicu e-maila z tematem i sformatowanym treścią HTML. Możesz wysłać go do swojego zespołu do weryfikacji lub bezpośrednio do subskrybentów po szybkim sprawdzeniu.
|
||||
|
||||
- **Hosting (opcjonalne, ale zalecane)**
|
||||
Jeśli chcesz, aby ten system działał automatycznie co tydzień (np. w niedzielę o północy), twoja instancja N8n musi być online 24/7. I tu właśnie wkracza prowadzenie.
|
||||
|
||||
Można:
|
||||
|
||||
> Uruchom go na własnym serwerze, albo
|
||||
>
|
||||
> Korzystaj z dostawcy hostingu, takiego jak **Hostinger**, który oferuje konfigurację n8n za pomocą jednego kliknięcia, codzienne kopie zapasowe i nieograniczone uruchomienia workflow.
|
||||
|
||||
Jeśli tylko eksperymentujesz, możesz uruchomić N8N lokalnie na komputerze. Ale dla stałej, bezwzględnej automatyzacji zaleca się hosting.
|
||||
|
||||
## Jak to wszystko się łączy
|
||||
|
||||
Teraz, gdy znasz kroki i narzędzia, połączmy fakty.
|
||||
|
||||
Oto ogólny obraz:
|
||||
|
||||
1. **Cotygodniowy wyzwalacz** uruchamia wszystko automatycznie.
|
||||
2. **Tavily** dostarcza najświeższe artykuły i spostrzeżenia z ostatniego tygodnia.
|
||||
3. **Agent AI w planowaniu** czyta te badania i tworzy tytuł oraz trzy kluczowe tematy.
|
||||
4. Tavily zagłębia się w każdy temat, dostarczając szczegółową treść kontekstową.
|
||||
5. **Agent AI pisarza** zamienia tę treść w trzy oddzielne sekcje newslettera.
|
||||
6. **Węzeł agregowany** łączy te sekcje w jeden szkic.
|
||||
7. **Agent AI edytora** dodaje dopracowanie: wstęp, zakończenie, formatowanie HTML i linki źródłowe.
|
||||
8. Na koniec szkic trafia na **twoje konto Gmail**, wraz z tematem i sformatowanym tekstem.
|
||||
|
||||
Otrzymujesz **gotowy do wysłania szkic newslettera** — badany, napisany i stylizowany — dostarczany prosto na Twoją skrzynkę odbiorczą.
|
||||
|
||||
Najlepsze w tym? Twoja rola zmienia się z **bycia twórcą wszystkiego** na **redaktora naczelnego**. Spędzasz minuty na przeglądaniu i poprawianiu, zamiast godzin na analizie i formatowaniu.
|
||||
|
||||
Innymi słowy, proces pracy cię nie zastępuje — on **cię wzmacnia**. Nadal ustalasz kierunek, upewniasz się, że ton pasuje do Twojej marki i decydujesz, kiedy jest gotowy do wysłania. System po prostu radzi sobie z powtarzalnymi, ciężkimi zadaniami.
|
||||
|
||||
To połączenie automatyzacji i ludzkiego podejścia sprawia, że proces jest trwały. Uzyskujesz spójność automatyzacji wraz z kreatywnością i osobowością własnego głosu.
|
||||
|
||||
## Przewodnik krok po kroku po budowie
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
zrzut ekranu autorstwa autora
|
||||
|
||||
### Krok 1: Ustaw szkielet workflow
|
||||
|
||||
Zanim zaczniemy dodawać zaawansowanych agentów AI, potrzebujemy kręgosłupa automatyzacji — szkieletu workflow. To właśnie tutaj podłącza się wszystko inne.
|
||||
|
||||
### 1\. Stwórz nowy workflow w n8n
|
||||
|
||||
- Otwórz **swój dashboard n8n**.
|
||||
- Kliknij **"Nowy przepływ pracy."**
|
||||
- Nadaj temu jasną nazwę, na przykład _"AI Newsletter Automation"._
|
||||
|
||||
> Pomyśl o tym jak o cyfrowej tablicy, na której wszystkie elementy się łączą.
|
||||
|
||||
### 2\. Dodaj wyzwalacz harmonogramu
|
||||
|
||||
To właśnie sprawia, że Twój newsletter działa na autopilocie, tydzień po tygodniu.
|
||||
|
||||
- Kliknij przycisk **"+",** aby dodać węzeł.
|
||||
- Wyszukaj **"Schedule Trigger".**
|
||||
- W ustawieniach:
|
||||
- Wybierz **powtarzanie co → tygodnia.**
|
||||
- Wybierz dzień i godzinę, o której chcesz, aby workflow działał (np. _niedziela o północy_).
|
||||
|
||||
> 💡 **Wskazówka:** Jeśli tylko testujesz, możesz tymczasowo ustawić "Co 5 minut", żeby nie czekać cały tydzień na wyniki. Później zmień ją z powrotem na tygodniową.
|
||||
|
||||
### 3\. Zapisz i (w końcu) aktywuj
|
||||
|
||||
Na tym etapie Twój workflow to tylko szkielet:
|
||||
|
||||
- Jeden węzeł wyzwalający.
|
||||
- Nic innego jeszcze nie połączyło.
|
||||
|
||||
Gdy skończysz budować całą automatyzację, **aktywujesz ją**, aby działała zgodnie z harmonogramem. Ale na razie trzymaj **go w trybie szkicu**, podczas gdy dodamy resztę kroków.
|
||||
|
||||
👉 To wszystko — twoja fundacja jest gotowa.
|
||||
|
||||
### Krok 2: Przeprowadz wstępne badania z Tavily
|
||||
|
||||
Teraz, gdy szkielet Twojego workflow jest gotowy, czas dać mu coś przydatnego do pracy — świeże treści. Zamiast spędzać godziny na googlowaniu najnowszych wiadomości, pozwolimy **Tavilly'emu** zająć się badaniami za nas.
|
||||
|
||||
Tavily to API badawcze, które pobiera odpowiednie artykuły, streszczenia i metadane z internetu. Wykorzystamy go do przeglądania wiadomości z minionego tygodnia w wybranej przez Ciebie niszy, dzięki czemu newsletter zawsze będzie aktualny.
|
||||
|
||||
### 1\. Dodaj węzeł Tavily
|
||||
|
||||
- W swoim workflow kliknij **przycisk "+".**
|
||||
- Wyszukaj **Tavily** (jeśli zainstalowałeś go jako węzeł społecznościowy).
|
||||
- Jeśli go nie widzisz, użyj **węzła HTTP Request** — Tavily działa perfekcyjnie przez wywołania API.
|
||||
|
||||
### 2\. Konfiguruj wyszukiwanie
|
||||
|
||||
W ustawieniach węzłów:
|
||||
|
||||
- **Zapytanie:** wpisz szeroki temat swojego newslettera. Przykład:
|
||||
|
||||
```
|
||||
<span id="fddb" data-selectable-paragraph="">AI adoption <span>for</span> <span>small</span> businesses</span>
|
||||
```
|
||||
|
||||
- **Opic/Tryb:** wybierz tak, aby priorytetowo traktował najnowsze aktualizacje.`news`
|
||||
- **Zakres czasu:** ustaw tak, żeby pobierać tylko świeżą zawartość.`past_week`
|
||||
- **Maksymalny wynik:** zacznij od 3 (wystarczająco, by planować tematy bez przytłoczenia AI).
|
||||
- **Dodaj surowe treści:** na **razie wyłącz to** — streszczenia wystarczą do planowania. Pełny tekst wyciągniemy później, w kroku 5.
|
||||
|
||||
## 3\. Uwierzytelnienie w Tavily
|
||||
|
||||
Jeśli to Twój pierwszy raz:
|
||||
|
||||
- Wejdź na **tavily.com** i załóż darmowe konto.
|
||||
- Wygeneruj klucz API.
|
||||
- Wklej go do n8n, gdy pojawi się poproszona.
|
||||
|
||||
## Przetestuj węzeł
|
||||
|
||||
Kliknij **Wykonaj węzeł** i poczekaj na wyniki. Powinieneś zobaczyć:
|
||||
|
||||
- Tytuły artykułów
|
||||
- Krótkie streszczenia
|
||||
- Adresy URL
|
||||
- Daty publikacji
|
||||
|
||||
Powinno to wyglądać mniej więcej tak (uproszczony przykład):
|
||||
|
||||
```
|
||||
<span id="184b" data-selectable-paragraph=""><span>[</span><br> <span>{</span><br> <span>"title"</span><span>:</span> <span>"Small Businesses Bridge the AI Gap"</span><span>,</span><br> <span>"summary"</span><span>:</span> <span>"SMBs are exploring automation but remain cautious about AI..."</span><span>,</span><br> <span>"url"</span><span>:</span> <span>"https://example.com/article1"</span><span>,</span><br> <span>"published_date"</span><span>:</span> <span>"2025-08-15"</span><br> <span>}</span><span>,</span><br> ...<br><span>]</span></span>
|
||||
```
|
||||
|
||||
## 5\. Przypnij dane
|
||||
|
||||
Oto mała, ale mocna wskazówka:
|
||||
|
||||
- W n8n kliknij na węzeł i kliknij **"Przypni dane".**
|
||||
- To zapisuje wyniki badań lokalnie, więc nie marnujesz wywołań API za każdym razem, gdy poprawiasz kolejne kroki.
|
||||
|
||||
✅ Na tym etapie Twój workflow może już generować **świeże, cotygodniowe badania**. To twoje surowe paliwo do newslettera. Następnie wykorzystamy AI, aby **przekształcić te badania w chwytliwy tytuł i trzy tematy skupione.**
|
||||
|
||||
## Krok 3: Wygeneruj tytuł i tematy newslettera za pomocą AI
|
||||
|
||||
Na tym etapie mamy surowe badania od Tavily — ale surowe dane to nie biuletyn. Teraz potrzebujemy **wyraźnego tematu, chwytliwego tytułu i trzech skoncentrowanych tematów,** wokół których zbudujemy numer. I tu właśnie wkracza AI.
|
||||
|
||||
Użyjemy **OpenRoutera** (brama API dla wielu modeli AI) do uruchomienia "agenta planowania". Pomyśl o tym jak o asystencie redakcyjnym swojego newslettera: czyta badania, a potem informuje cię, _o czym powinien być ten numer._
|
||||
|
||||
### 1\. Dodaj węzeł OpenRouter
|
||||
|
||||
- Kliknij **"+" → OpenRouter (Chat Model)"** w swoim workflow.
|
||||
- Jeśli nie masz węzła, użyj **HTTP Request** i wywołaj bezpośrednio API OpenRouter.
|
||||
|
||||
### 2\. Konfiguruj model AI
|
||||
|
||||
- **Model:** Wybierz coś mocnego do podsumowywania i strukturyzowania informacji, jak , **gpt-4o-mini, claude-3.5-sonnet** lub **gpt-5**, jeśli jest dostępne.
|
||||
- **Temperatura:** Ustaw na **0,7** (zrównoważona kreatywność).
|
||||
|
||||
### 3\. Stwórz prompt
|
||||
|
||||
Oto prosty, ale skuteczny komunikat systemowy, który możesz wkleić do n8n:
|
||||
|
||||
```
|
||||
<span id="65f2" data-selectable-paragraph="">You are a newsletter planning assistant. <br><span>You will be given research <span>results</span> (<span>article titles, summaries, <span>and</span> URLs</span>). <br>From <span>this</span>, create: <br>1. A single engaging newsletter title. <br>2. Exactly 3 topics that could become newsletter sections. <br><br>Return the output <span>in</span> **valid JSON** <span>with</span> <span>this</span> structure:</span> <br><br>{<br> <span>"title"</span>: <span>"string"</span>,<br> <span>"topics"</span>: [<br> {<span>"topic"</span>: <span>"string"</span>},<br> {<span>"topic"</span>: <span>"string"</span>},<br> {<span>"topic"</span>: <span>"string"</span>}<br> ]<br>}</span>
|
||||
```
|
||||
|
||||
### 4\. Odwzorowanie wejścia
|
||||
|
||||
- W **Input**, przekaż wyniki Tavily z kroku 2 do węzła AI.
|
||||
- Upewnij się, że dostarczasz **podsumowania + tytuły** (jeszcze nie pełna, surowa zawartość — to przyjdzie później).
|
||||
|
||||
### 5\. Przetestuj węzeł
|
||||
|
||||
Kliknij **Wykonaj węzeł.** Jeśli wszystko pójdzie dobrze, powinieneś mieć czysty JSON w ten sposób:
|
||||
|
||||
```
|
||||
<span id="ad1e" data-selectable-paragraph=""><span>{</span><br> <span>"title"</span><span>:</span> <span>"How AI is Powering the Next Wave of Small Business Tools"</span><span>,</span><br> <span>"topics"</span><span>:</span> <span>[</span><br> <span>{</span><span>"topic"</span><span>:</span> <span>"Affordable AI platforms for startups"</span><span>}</span><span>,</span><br> <span>{</span><span>"topic"</span><span>:</span> <span>"Case studies: SMBs adopting automation"</span><span>}</span><span>,</span><br> <span>{</span><span>"topic"</span><span>:</span> <span>"Challenges small businesses face with AI adoption"</span><span>}</span><br> <span>]</span><br><span>}</span></span>
|
||||
```
|
||||
|
||||
### 6\. Przypnij i zweryfikowaj
|
||||
|
||||
- **Przypiń wyjście** (żeby nie uruchamiać Tavilly za każdym razem).
|
||||
- Zweryfikowaj JSON (n8n czasem wymaga uruchomienia węzła "Set", aby go czysto przeanalizować).
|
||||
|
||||
✅ Gratulacje — teraz masz **już plan redakcyjny** swojego newslettera:
|
||||
|
||||
- Temat gotowy do użycia.
|
||||
- Trzy tematy skupione, które w kolejnych krokach zgłębisz w swoich kolejnych etapach.
|
||||
|
||||
Następnie podzielimy **te tematy na osobny** mini proces badawczy + pisarski.
|
||||
|
||||
### Krok 4: Podziel tematy na osobne elementy
|
||||
|
||||
Obecnie Twój planer AI podał **ci 3 tematy** w jednym obiekcie JSON. To przydatne, ale jest haczyk:
|
||||
kolejne kroki (głębokie badania + pisanie) wymagają przetworzenia każdego tematu _osobno_.
|
||||
|
||||
Oznacza to, że musimy "rozłożyć" tematy tak, aby każdy przechodził przez własny mini-pipeline. W n8n właśnie do tego służy węzeł **SplitInBatches** (lub Split Out Items).
|
||||
|
||||
### 1\. Dodaj węzeł SplitInBatches
|
||||
|
||||
- Po węźle **OpenRouter AI (agent planowania)** kliknij **"+"** i dodaj **SplitInBatches**.
|
||||
- Podłącz do niego wyjście węzła AI.
|
||||
|
||||
### 2\. Konfiguruj ustawienia podziału
|
||||
|
||||
- **Rozmiar partii:** ustaw to na .`1`
|
||||
- Dzięki temu każdy temat przechodzi przez proces pracy pojedynczo.
|
||||
- **Wprowadzanie przedmiotów:** wskaż na to z wyjścia JSON twojego planera AI.`topics`
|
||||
|
||||
💡 Przykładowe wejście z kroku 3 wyglądało tak:
|
||||
|
||||
```
|
||||
<span id="f91f" data-selectable-paragraph=""><span>{</span><br> <span>"title"</span><span>:</span> <span>"How AI is Powering the Next Wave of Small Business Tools"</span><span>,</span><br> <span>"topics"</span><span>:</span> <span>[</span><br> <span>{</span><span>"topic"</span><span>:</span> <span>"Affordable AI platforms for startups"</span><span>}</span><span>,</span><br> <span>{</span><span>"topic"</span><span>:</span> <span>"Case studies: SMBs adopting automation"</span><span>}</span><span>,</span><br> <span>{</span><span>"topic"</span><span>:</span> <span>"Challenges small businesses face with AI adoption"</span><span>}</span><br> <span>]</span><br><span>}</span></span>
|
||||
```
|
||||
|
||||
> Po podziale workflow będzie traktował **każdy {"temat": "..."}** jako osobny element.
|
||||
|
||||
### 3\. Przetestuj węzeł
|
||||
|
||||
- Uruchom workflow do tego etapu.
|
||||
- Powinieneś zobaczyć, że **pierwszy temat tylko** przechodzi.
|
||||
- Kliknij "Następna partia", aby przejść przez pozostałe dwa tematy.
|
||||
|
||||
Dzięki temu n8n zapewnia, że każdy temat samodzielnie przejdzie przez **dogłębne badania** i **etapy pisania sekcji**.
|
||||
|
||||
### 4\. Zachowaj tytuł bezpieczeństwa
|
||||
|
||||
Oto subtelny, ale ważny szczegół:
|
||||
|
||||
- Tytuł nie jest uwzględniony w podziale.
|
||||
- Aby użyć go później (w temacie wiadomości), albo:
|
||||
- Zapisz go w **węźle Set** przed podziałem, lub
|
||||
- Użyj funkcji **"Keep Only Set"** w n8n, aby przenieść go w metadanych.
|
||||
|
||||
Dzięki temu nie "tracisz" tytułu newslettera, gdy wszystko się rozwinie.
|
||||
|
||||
✅ Dzięki temu etapowi Twój workflow traktuje każdy temat jak **osobny mini-projekt**. Następnie każdy z tych tematów ponownie przekażemy Tavily do **głębszych i skoncentrowanych badań.**
|
||||
|
||||
## Krok 5: Zrób dogłębne badania dotyczące każdego tematu
|
||||
|
||||
Jak dotąd masz trzy obiecujące tematy — ale to tylko nagłówki. Aby faktycznie pisać wartościowe sekcje newslettera, potrzebujemy **szczegółowych treści wspierających**. Tu Tavily wraca, ale tym razem powiemy: _"Nie dawajcie mi tylko streszczeń — dajcie mi surowy materiał."_
|
||||
|
||||
### 1\. Dodaj kolejny węzeł Tavily
|
||||
|
||||
- Po węźle **SplitInBatches** kliknij **"+"** i dodaj **wyszukiwanie Tavily** (lub HTTP Request z API Tavilly).
|
||||
- Połącz go tak, aby każdy podzielony temat płynął z tym węzłem badawczym.
|
||||
|
||||
### 2\. Konfiguruj wyszukiwanie
|
||||
|
||||
Tym razem zagłębimy się głębiej. W ustawieniach:
|
||||
|
||||
- **Zapytanie:** mapuj tekst tematu z węzła Split. Przykład:
|
||||
|
||||
```
|
||||
<span id="cc1c" data-selectable-paragraph=""><span>{</span><span>{</span>$json<span>[</span><span>"topic"</span><span>]</span><span>}</span><span>}</span></span>
|
||||
```
|
||||
|
||||
- **Zakres czasowy:** ustaw na lub (w zależności od tego, jak szerokie chcesz badanie).`past_week``past_month`
|
||||
- **Maksymalna liczba wyników:** 5–7 artykułów to dobry balans.
|
||||
|
||||
**Dodaj surową treść:** ✅ **ustaw to na true**.
|
||||
|
||||
- Dzięki temu otrzymujesz nie tylko tytuły i streszczenia, ale także **fragmenty treści artykułu**.
|
||||
- Te fragmenty to właśnie twoja AI pisarza wykorzysta do tworzenia pełnych sekcji.
|
||||
|
||||
### 3\. Przykładowe wyjście
|
||||
|
||||
Po wykonaniu zobaczysz takie (uproszczone wyniki):
|
||||
|
||||
```
|
||||
<span id="5833" data-selectable-paragraph=""><span>[</span><br> <span>{</span><br> <span>"title"</span><span>:</span> <span>"AI Platforms Lower Costs for Small Startups"</span><span>,</span><br> <span>"url"</span><span>:</span> <span>"https://example.com/article1"</span><span>,</span><br> <span>"content"</span><span>:</span> <span>"Startups are finding affordable AI solutions for customer support, marketing, and workflow automation..."</span><br> <span>}</span><span>,</span><br> <span>{</span><br> <span>"title"</span><span>:</span> <span>"The Rise of DIY AI Tools"</span><span>,</span><br> <span>"url"</span><span>:</span> <span>"https://example.com/article2"</span><span>,</span><br> <span>"content"</span><span>:</span> <span>"Low-cost AI apps are enabling small teams to automate tasks without hiring full-time developers..."</span><br> <span>}</span><br><span>]</span></span>
|
||||
```
|
||||
|
||||
Teraz zamiast płytkich notatek, masz **szczegółowe badania** — surową glinę, którą autor AI ukształtuje w sekcji newslettera.
|
||||
|
||||
### 4\. Przypin i test
|
||||
|
||||
- Jak zawsze, **przypiń te dane** w n8n, żeby nie przepalić wywołań API podczas debugowania w kolejnych etapach.
|
||||
- Sprawdź dokładnie, czy Twoje wyniki zawierają pola — to właśnie wpłyniemy na AI pisarza.`content`
|
||||
|
||||
✅ Na tym etapie Twój workflow jest potężny: każdy temat jest teraz dołączony do **szczegółowych fragmentów badań**. Następnie przekażemy to agentowi AI, który przekształca badania w dopracowaną sekcję newslettera.
|
||||
|
||||
## Krok 6: Napisz sekcje newslettera za pomocą AI
|
||||
|
||||
Teraz, gdy masz surową zawartość do każdego tematu, czas pozwolić AI wykonać ciężką robotę. Właśnie tutaj pojawia się **Agent Pisarza Sekcji**. Jego zadaniem: przekształcić fragmenty badań w dopracowaną sekcję biuletynu z nagłówkiem, treścią i listą źródeł.
|
||||
|
||||
### 1\. Dodaj węzeł OpenRouter
|
||||
|
||||
- Po węźle **Tavily (deep research)** kliknij **"+"** → **OpenRouter Chat Model** (lub HTTP Request → OpenRouter API).
|
||||
- Podłącz go bezpośrednio do węzła Tavilly.
|
||||
|
||||
### 2\. Konfiguruj model AI
|
||||
|
||||
- **Model:** Wybierz taką skoncentrowaną na pisaniu, jak , , lub jeśli jest dostępna.`gpt-4o-mini``claude-3.5-sonnet``gpt-5`
|
||||
- **Temperatura:** → sprawia, że pisanie jest profesjonalne, ale lekko angażujące.`0.6`
|
||||
|
||||
### Stwórz prompt
|
||||
|
||||
Wklej coś takiego do swojego systemowego promptu:
|
||||
|
||||
```
|
||||
<span id="7f16" data-selectable-paragraph="">You are <span>a</span> newsletter <span>section</span> writer. <br>You will be given <span>a</span> topic and research <span>content</span>. <br><br>Write <span>a</span> <span>section</span> in plain, professional language with these rules: <br>- Start with a short, catchy heading (<span>1</span> line). <br>- Write a clear, engaging body (<span>150</span>–<span>200</span> words). <br>- Include bullet points if useful. <br>- End with <span>2</span>–<span>3</span> source URLs in a <span>"Sources"</span> list. <br><br>Return ONLY valid JSON in this structure: <br><br>{<br> "heading": <span>"string"</span>,<br> <span>"body"</span>: <span>"string"</span>,<br> <span>"sources"</span>: [<span>"url1"</span>, <span>"url2"</span>, <span>"url3"</span>]<br>}</span>
|
||||
```
|
||||
|
||||
### 4\. Odwzorowanie danych wejściowych
|
||||
|
||||
- **Temat:** `{{$json["topic"]}}`
|
||||
- **Treść badań:** (od Tavily).`{{$json["content"]}}`
|
||||
|
||||
### 5\. Przetestuj węzeł
|
||||
|
||||
Efekt powinien wyglądać tak:
|
||||
|
||||
```
|
||||
<span id="e495" data-selectable-paragraph=""><span>{</span><br> <span>"heading"</span><span>:</span> <span>"Affordable AI Platforms Reshape Startups"</span><span>,</span><br> <span>"body"</span><span>:</span> <span>"Small businesses are increasingly adopting low-cost AI tools to handle customer service, marketing, and internal workflows. These platforms, often costing less than traditional enterprise software, allow startups to scale without major hiring costs..."</span><span>,</span><br> <span>"sources"</span><span>:</span> <span>[</span><br> <span>"https://example.com/article1"</span><span>,</span><br> <span>"https://example.com/article2"</span><br> <span>]</span><br><span>}</span></span>
|
||||
```
|
||||
|
||||
✅ Powtarzaj ten proces dla każdego tematu — SplitInBatches zapewnia, że każdy przechodzi osobno. Na koniec będziesz miał **3 dopracowane sekcje w formacie JSON.**
|
||||
|
||||
## Krok 7: Połącz wszystkie sekcje w jeden szkic
|
||||
|
||||
Obecnie Twój workflow ma trzy oddzielne sekcje, które krążą po kolei. Zanim wyślemy je do Edytora AI, musimy **połączyć je w jeden ładunek danych.**
|
||||
|
||||
### 1\. Dodaj węzeł agregowany / scalający
|
||||
|
||||
- Po **węźle Section Writer AI** wrzuć **węzeł Aggregate**.
|
||||
- Skonfiguruj go tak, aby **łączył wszystkie elementy w jedną tablicę.**
|
||||
|
||||
2\. Konfiguruj pola
|
||||
|
||||
Upewnij się, że połączony obiekt wygląda tak:
|
||||
|
||||
```
|
||||
<span id="4fb4" data-selectable-paragraph=""><span>{</span><br> <span>"sections"</span><span>:</span> <span>[</span><br> <span>{</span><br> <span>"heading"</span><span>:</span> <span>"..."</span><span>,</span><br> <span>"body"</span><span>:</span> <span>"..."</span><span>,</span><br> <span>"sources"</span><span>:</span> <span>[</span><span>"..."</span><span>]</span><br> <span>}</span><span>,</span><br> <span>{</span><br> <span>"heading"</span><span>:</span> <span>"..."</span><span>,</span><br> <span>"body"</span><span>:</span> <span>"..."</span><span>,</span><br> <span>"sources"</span><span>:</span> <span>[</span><span>"..."</span><span>]</span><br> <span>}</span><span>,</span><br> <span>{</span><br> <span>"heading"</span><span>:</span> <span>"..."</span><span>,</span><br> <span>"body"</span><span>:</span> <span>"..."</span><span>,</span><br> <span>"sources"</span><span>:</span> <span>[</span><span>"..."</span><span>]</span><br> <span>}</span><br> <span>]</span><br><span>}</span></span>
|
||||
```
|
||||
|
||||
Dzięki temu AI redaktora (pojawiające się w Kroku 8) otrzymuje **pełny szkic newslettera natychmiast.**
|
||||
|
||||
### 3\. Dbaj o bezpieczeństwo metadanych
|
||||
|
||||
Pamiętasz **tytuł newslettera** z Step 3?
|
||||
|
||||
- Użyj **węzła Merge**, aby przywrócić zapisany tytuł tutaj.
|
||||
- Końcowy ładunek powinien obejmować zarówno , jak i .`title``sections`
|
||||
|
||||
Przykładowy końcowy wynik:
|
||||
|
||||
```
|
||||
<span id="6768" data-selectable-paragraph="">{<br> <span>"title"</span>: <span>"How AI is Powering the Next Wave of Small Business Tools"</span>,<br> <span>"sections"</span>: [<br> { <span>"heading"</span>: <span>"..."</span>, <span>"body"</span>: <span>"..."</span>, <span>"sources"</span>: [...] },<br> { <span>"heading"</span>: <span>"..."</span>, <span>"body"</span>: <span>"..."</span>, <span>"sources"</span>: [...] },<br> { <span>"heading"</span>: <span>"..."</span>, <span>"body"</span>: <span>"..."</span>, <span>"sources"</span>: [...] }<br> ]<br>}</span>
|
||||
```
|
||||
|
||||
✅ Teraz masz **kompletny szkic**: trzy sekcje plus tytuł newslettera, wszystko starannie zebrane w jednym obiekcie JSON. Następnie przekażemy to **agentowi AI Editora**, aby dopracował, wystylizował i sformatował w odpowiedni e-mail HTML.
|
||||
|
||||
### Krok 8: Szlifowanie i formatowanie z agentem montażowym
|
||||
|
||||
Obecnie masz uporządkowany JSON: **tytuł** i **trzy sekcje.** Jest dobra, ale nadal wygląda jak surowe dane. Teraz potrzebujemy **dopracowanego, profesjonalnego e-maila HTML**.
|
||||
|
||||
I tu właśnie wkracza **Editor AI Agent**. Pomyśl o tym jak o swoim wewnętrznym korektorze — dodaje ostatnie szlify i zamienia Twoje treści w coś, co subskrybenci naprawdę polubią czytać.
|
||||
|
||||
### 1\. Dodaj węzeł OpenRouter
|
||||
|
||||
- Po **węźle Aggregate** (Krok 7) wstaw nowy węzeł **OpenRouter (model Chat).**
|
||||
- Połącz go bezpośrednio z połączonym szkiczem.
|
||||
|
||||
### 2\. Konfiguruj model
|
||||
|
||||
- **Model:** Wybierz taką mocną w formatowaniu i strukturze długiego tekstu: , , lub .`gpt-4o-mini``claude-3.5-sonnet``gpt-5`
|
||||
- **Temperatura:** (utrzymuje ją na stałym poziomie, mniej "kreatywnego wędrowania").`0.5`
|
||||
|
||||
### 3\. Stwórz prompt
|
||||
|
||||
Oto wiarygodny szablon promptu:
|
||||
|
||||
```
|
||||
<span id="9d34" data-selectable-paragraph="">You are a newsletter editor. <br>You will receive a newsletter title <span>and</span> three sections. <br><br>Your job <span>is</span> to: <br>- Create a final newsletter draft <span>with</span>: <br> <span>1.</span> <span>Subject <span>line</span> (<span>based <span>on</span> the title</span>). <br> 2. HTML email body <span>with</span> intro, section formatting, <span>and</span> conclusion. <br> 3. Sources list at the end <span>with</span> clickable links. <br><br>Return ONLY valid JSON <span>in</span> <span>this</span> structure:</span> <br><br>{<br> <span>"subject"</span>: <span>"string"</span>,<br> <span>"html_content"</span>: <span>"string"</span>,<br> <span>"sources"</span>: [<span>"url1"</span>, <span>"url2"</span>, <span>"url3"</span>]<br>}</span>
|
||||
```
|
||||
|
||||
### 4\. Odwzorowanie danych wejściowych
|
||||
|
||||
- **Tytuł:** z kroku 3 (planer newslettera).
|
||||
- **Sekcje:** z kroku 7 (zagregowany JSON).
|
||||
|
||||
### 5\. Przykładowe wyjście
|
||||
|
||||
Oto, co powinieneś zobaczyć:
|
||||
|
||||
```
|
||||
<span id="1eff" data-selectable-paragraph="">{<br> "subject": "How AI is Reshaping Small Business",<br> "html_content": "<span><<span>h1</span>></span>How AI is Reshaping Small Business<span></<span>h1</span>></span><span><<span>p</span>></span>Welcome to this week’s edition...<span></<span>p</span>></span><span><<span>h2</span>></span>Affordable AI Platforms Reshape Startups<span></<span>h2</span>></span><span><<span>p</span>></span>Small businesses are adopting...<span></<span>p</span>></span><span><<span>h2</span>></span>Case Studies: SMBs Adopting Automation<span></<span>h2</span>></span><span><<span>p</span>></span>Examples show how...<span></<span>p</span>></span><span><<span>h2</span>></span>Challenges of AI Adoption<span></<span>h2</span>></span><span><<span>p</span>></span>Despite progress...<span></<span>p</span>></span><span><<span>p</span>></span><span><<span>strong</span>></span>Sources:<span></<span>strong</span>></span><span><<span>br</span>></span><span><<span>a</span> <span>href</span>=<span>'https://example.com/article1'</span>></span>Source 1<span></<span>a</span>></span><span><<span>br</span>></span><span><<span>a</span> <span>href</span>=<span>'https://example.com/article2'</span>></span>Source 2<span></<span>a</span>></span><span></<span>p</span>></span>",<br> "sources": [<br> "https://example.com/article1",<br> "https://example.com/article2"<br> ]<br>}</span>
|
||||
```
|
||||
|
||||
## Krok 9: Wyślij wersję roboczą do Gmaila
|
||||
|
||||
Mając w ręku ostateczny szkic HTML, ostatnim krokiem jest dostarczenie. Wyślemy wszystko do Gmaila jako **szkic e-maila**, abyś mógł szybko przejrzeć przed kliknięciem "Wyślij".
|
||||
|
||||
### 1\. Dodaj węzeł Gmail
|
||||
|
||||
- Kliknij **"+" → Gmail → utworzenie szkicu.**
|
||||
- Połącz go za węzłem AI Editor.
|
||||
|
||||
### 2\. Konfiguruj szkic
|
||||
|
||||
- **Temat:** mapa z wyjścia AI → `{{$json["subject"]}}`
|
||||
- **Treść:** mapa z wychodu AI → `{{$json["html_content"]}}`
|
||||
- **Typ treści:** ustawiony na `HTML`
|
||||
|
||||
### 3\. Uwierzytelnij Gmaila
|
||||
|
||||
- Jeśli to Twój pierwszy raz z Gmailem w n8n, skonfiguruj OAuth2.
|
||||
- Po połączeniu zobaczysz swoje konto Google w węźle.
|
||||
|
||||
### 4\. Przetestować węzeł
|
||||
|
||||
Uruchom workflow, a potem sprawdź Gmaila. Powinieneś zobaczyć szkic z napisem:
|
||||
|
||||
- Twój **temat wygenerowany** przez AI
|
||||
- **Pełny tremień newslettera HTML**
|
||||
- **Sekcja źródeł** starannie sformatowana
|
||||
|
||||
✅ I to wszystko! Zbudowałeś kompletny kanał automatyzacji newsletterów:
|
||||
|
||||
- Od surowych badań → tematów → sekcji → dopracowanego HTML → szkicu Gmaila.
|
||||
- Teraz wystarczy poprawić i kliknąć "Wyślij".
|
||||
|
||||
## Krok 10: Test, debugowanie i pin danych
|
||||
|
||||
Budowanie złożonych workflowów w n8n jest ekscytujące... aż coś się zepsuje. I uwierz mi, coś _się zepsuje_ przy pierwszych kilku próbach. Może odpowiedź API wygląda inaczej, może formatowanie JSON jest nieprawidłowe, może Gmail krzyczy o uprawnieniach.
|
||||
|
||||
Dlatego Step 10 polega na **inteligentnym debugowaniu**, żeby nie tracić czasu (ani tokenów).
|
||||
|
||||
### 1\. Testuj węzły indywidualnie
|
||||
|
||||
- W n8n nie musisz za każdym razem uruchamiać całego workflow.
|
||||
- Kliknij **"Wykonaj węzeł"** na dowolnym pojedynczym węźle, aby przetestować _tylko ten fragment_.
|
||||
- Przykład: jeśli Tavily zawodzi, testuj tylko węzeł Tavilly, zamiast uruchamiać pełny, 10-stopniowy łańcuch.
|
||||
|
||||
To oszczędza ogromną ilość czasu podczas rozwiązywania problemów.
|
||||
|
||||
### 2\. Pin danych do zapisu tokenów
|
||||
|
||||
Każde połączenie AI + research API kosztuje pieniądze. Jeśli testujesz formatowanie lub węzły downstream, nie chcesz ciągle korzystać z Tavily czy OpenRoutera.
|
||||
|
||||
- Po pomyślnym uruchomieniu węzła kliknij **"Pin Data".**
|
||||
- To blokuje wyjście, dzięki czemu węzły kolejne mogą dalej używać tych samych wyników.
|
||||
- Przykład: Przypnij swoje badania Tavilly, aby móc testować Writer AI wielokrotnie bez ponownego pobierania danych internetowych.
|
||||
|
||||
💡 Profesjonalna wskazówka: Odpinaj, gdy będziesz gotowy na "prawdziwy bieg".
|
||||
|
||||
### 3\. Typowe wskazówki dotyczące debugowania
|
||||
|
||||
Oto kilka pułapek, na które prawdopodobnie natrafisz — i jak je rozwiązać:
|
||||
|
||||
- **Błędy parsowania JSON:**
|
||||
Jeśli wyjście AI łamie format JSON (dodatkowe przecinki, brakujące nawiasy), dodaj **węzeł Code** lub **węzeł parsowania JSON**, aby go zweryfikować i wyczyścić.
|
||||
Wyrażenie AI komunikatu "Zwróć tylko ważny JSON" również zmniejsza liczbę błędów.
|
||||
- **Problemy z harmonogramem:**
|
||||
Jeśli wyzwalacz harmonogramu się nie uruchamia, sprawdź, czy instancja N8n jest **aktywna i** odpowiednio hostowana. Pamiętaj, że lokalny N8N kończy się, gdy komputer się zatrzymuje. Rozważ użycie Hostingera, Kolei lub n8n.cloud dla dostępności 24/7.
|
||||
- **Błędy Gmaila:**
|
||||
Typowe to brakujące tokeny OAuth lub niewyrenderowanie treści HTML.
|
||||
- Sprawdź dokładnie, czy Gmail jest połączony przez OAuth2.
|
||||
- Zawsze ustaw **typ treści = HTML** w węźle Gmail.
|
||||
|
||||
✅ Gdy przetestujesz każdy element, przypinasz dane i naprawisz drobne błędy, będziesz mieć solidny workflow, który działa na autopilocie co tydzień.
|
||||
|
||||
🎉 **Gratulacje — właśnie stworzyłeś Agenta Newslettera opartego na AI!**
|
||||
To, co kiedyś zajmowało godziny googlowania, szkicowania i formatowania, stało się teraz jedną automatyzacją: badanie → tematów → pisanie → edytowanie → szkicu Gmaila.
|
||||
|
||||
Możesz tu przerwać lub rozwinąć temat:
|
||||
|
||||
- Wysyłaj automatycznie zamiast szkicu.
|
||||
- Dodaj linki do śledzenia analityki.
|
||||
- Zapisuj każdy newsletter do Google Sheets lub Notion.
|
||||
|
||||
## Poza buildem: wskazówki, triki i kolejny krok
|
||||
|
||||
Właśnie przeszedłeś przez budowanie pełnego **agenta newslettera opartego na AI** od podstaw — od badań po szkic Gmaila. Ale zanim zakończymy, dodajmy kilka ostatnich szlifów i dodatkowych pomysłów, by pójść dalej.
|
||||
|
||||
### 🔹 Dodatkowe wskazówki
|
||||
|
||||
- **Strojenie promptów:**
|
||||
Jeśli styl pisania AI wydaje się zbyt suchy lub zbyt kreatywny, zmodyfikuj prompty. Na przykład dodaj: _"Pisz w profesjonalnym, ale konwersacyjnym tonie, jak w biuletynie biznesowym."_ Małe zmiany = duże różnice w produkcji.
|
||||
- **Rejestrowanie newsletterów:**
|
||||
Nie pozwól, by twoje najlepsze treści zniknęły. Użyj węzła Notion lub Google Sheets, aby zarejestrować każdy utworzony tytuł + sekcję. Z czasem staje się to przeszukiwalną bazą wiedzy dotyczącą treści newslettera.
|
||||
- **Obsługa błędów:**
|
||||
Dodaj **workflow błędów** w n8n, który wykrywa nieudane uruchomienia. Możesz wysłać sobie alert ze Slacka lub Gmaila, jeśli coś się zepsuje w trakcie działania (limit API, zły JSON, błąd Gmaila).
|
||||
|
||||
**Alternatywne narzędzia badawcze:**
|
||||
Tavily jest świetne, ale możesz eksperymentować z:
|
||||
|
||||
- **Perplexity API** do badań konwersacyjnych.
|
||||
- **SerpAPI** dla surowych wyników Google.
|
||||
- **NewsAPI** dla szerszego zasięgu medialnego.
|
||||
|
||||
To sprawia, że Twój newsletter jest jeszcze bardziej rozbudowany.
|
||||
|
||||
## Podsumowanie
|
||||
|
||||
Ręczne biuletyny są powolne, niespójne i szczerze mówiąc wyczerpujące. Automatyzując z **użyciem agentów n8n + AI**, odblokowałeś system, który:
|
||||
|
||||
- **Oszczędza to godziny** tygodniowo.
|
||||
- Tworzy **spójne, uporządkowane szkice.**
|
||||
- To wciąż zostawia miejsce **dla Ci jako redaktora**, by dodać ludzki akcent przed wysłaniem.
|
||||
|
||||
Zamiast patrzeć w pustą stronę w niedzielny wieczór, teraz otworzysz Gmaila i znajdziesz gotowy do przeglądu szkic.
|
||||
|
||||
## Kolejne kroki
|
||||
|
||||
Teraz, gdy zbudowałeś fundament, możesz:
|
||||
|
||||
- Spróbuj różnych modeli AI (, , ) i porównaj wyniki.`Claude 3.5``GPT-5``Mistral Large`
|
||||
- Eksperymentuj z promptami stylizacyjnymi (minimalistycznymi, dziennikarskimi, a nawet zabawnymi tonami newslettera).
|
||||
- Dodaj personalizację: pobieraj dane użytkowników i podziel newslettery na segmenty.
|
||||
|
||||
Kluczowa lekcja: **automatyzacja nie zastępuje twojego głosu — daje ci więcej czasu na jego użycie.**
|
||||
|
||||
🎉 I tym samym skończyłeś nie tylko artykuł — ale działający automatyzujący workflow newslettera, który może działać co tydzień.
|
||||
|
||||
**Możesz przeczytać to więcej.**
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,90 @@
|
||||
---
|
||||
title: "Software 2.0"
|
||||
source: "https://karpathy.medium.com/software-2-0-a64152b37c35"
|
||||
author:
|
||||
- "[[Andrej Karpathy]]"
|
||||
published: 2017-11-11
|
||||
created: 2026-05-14
|
||||
description: "60K"
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
Czasem widzę, że ludzie nazywają sieci neuronowe po prostu "kolejnym narzędziem w twoim zestawie narzędzi uczenia maszynowego". Mają swoje plusy i minusy, działają tu i tam, a czasem można ich wykorzystać, by wygrać konkursy Kaggle. Niestety, ta interpretacja całkowicie pomija las dla drzew. ==Sieci neuronowe to nie tylko kolejny klasyfikator, ale stanowią początek fundamentalnej zmiany w sposobie, w jaki tworzymy oprogramowanie. To Oprogramowanie 2.0.==
|
||||
|
||||
"Klasyczny stos" **Software 1.0** to to, co wszyscy znamy — jest napisany w językach takich jak Python, C++ itd. Składa się z jawnych instrukcji dla komputera napisanych przez programistę. Pisząc każdą linijkę kodu, programista identyfikuje konkretny punkt w przestrzeni programu o pożądanym zachowaniu.
|
||||
|
||||
|
||||
|
||||
Dla porównania, **Software 2.0** jest napisane w znacznie bardziej abstrakcyjnym, nieprzyjaznym dla człowieka języku, takim jak wagi sieci neuronowej. Żaden człowiek nie bierze udziału w pisaniu tego kodu, bo jest dużo wag (typowe sieci mogą mieć ich miliony), a kodowanie bezpośrednio w wagach jest dość trudne (próbowałem).
|
||||
|
||||
|
||||
|
||||
Zamiast tego nasze podejście polega na określeniu celu dotyczącym zachowania pożądanego programu (np. "spełnienie zbioru danych par przykładów wejściowych i wyjściowych" lub "wygranie gry w Go"), napisanie szkieletu kodu (czyli architektury sieci neuronowej), który identyfikuje podzbiór przestrzeni programowej do przeszukiwania, oraz wykorzystanie dostępnych zasobów obliczeniowych do przeszukania w tej przestrzeni w poszukiwaniu działającego programu. W przypadku sieci neuronowych ograniczamy przeszukiwanie do ciągłego podzbioru przestrzeni programowej, gdzie proces wyszukiwania można uczynić (co nieco zaskakujące) efektywnym dzięki wstecznej propagacji i stochastycznemu zejściu gradientu.
|
||||
|
||||
|
||||
|
||||
Aby to wyjaśnić jednocześnie, w Software 1.0 kod źródłowy stworzony przez człowieka (np. niektóre pliki.cpp) jest kompilowany w formę binarną, która wykonuje użyteczną pracę. W Programowaniu 2.0 kod źródłowy najczęściej składa się z 1) zbioru danych definiującego pożądane zachowanie oraz 2) architektury sieci neuronowej, która daje przybliżony szkielet kodu, ale z wieloma szczegółami (wagami) do uzupełnienia. Proces trenowania sieci neuronowej kompiluje zbiór danych do systemu binarnego — ostatecznej sieci neuronowej. W większości praktycznych zastosowań architektury sieci neuronowych i systemy treningowe są coraz bardziej standaryzowane do standardu, więc większość aktywnego "rozwoju oprogramowania" polega na kuratorstwie, uprawiaaniu, masowaniu i czyszczeniu oznaczonych zbiorów danych. To zasadniczo zmienia paradygmat programowania, w którym iterujemy nasze oprogramowanie, ponieważ zespoły dzielą się na dwie części: programiści 2.0 (labelerzy danych) edytują i rozwijają zbiory danych, podczas gdy kilku programistów 1.0 utrzymuje i iteruje otaczającą infrastrukturę kodu treningowego, analitykę, wizualizacje i interfejsy etykietowania.
|
||||
|
||||
Okazuje się, że duża część rzeczywistych problemów ma tę cechę, że znacznie łatwiej jest zebrać dane (lub bardziej ogólnie zidentyfikować pożądane zachowanie) niż jawnie napisać program. Z powodu tego i wielu innych korzyści płynących z programów Software 2.0, o których opowiem poniżej, jesteśmy świadkami ogromnej transformacji w branży, gdzie wiele kodu 1.0 jest przenoszonych do kodu 2.0. Oprogramowanie (1.0) pożera świat, a teraz AI (Oprogramowanie 2.0) pożera oprogramowanie.
|
||||
|
||||
## Trwająca transformacja
|
||||
|
||||
Przyjrzyjmy się krótko kilku konkretnym przykładom tej trwającej transformacji. W każdym z tych obszarów zaobserwowaliśmy postępy w ostatnich latach, gdy rezygnowaliśmy z prób rozwiązania złożonego problemu poprzez pisanie kodu jawnego i zamiast tego przenieśliśmy go do stosu 2.0.
|
||||
|
||||
**Rozpoznawanie wizualne** kiedyś składało się z funkcji inżynieryjnych z odrobiną uczenia maszynowego na końcu (np. SVM). Od tego czasu odkryliśmy znacznie potężniejsze cechy wizualne, zdobywając duże zbiory danych (np. ImageNet) i przeszukując architektury splotowych sieci neuronowych. Ostatnio nawet nie ufamy sobie w ręcznym kodowaniu architektur i zaczęliśmy [je również przeszukiwać](https://arxiv.org/abs/1703.01041).
|
||||
|
||||
**Rozpoznawanie mowy** kiedyś wymagało wielu procesów wstępnych, modeli mieszanek Gaussa i ukrytych modeli Markowa, ale [dziś](https://github.com/syhw/wer_are_we) składa się niemal wyłącznie z sieci neuronowej. Bardzo powiązany, często cytowany humorystyczny cytat przypisywany Fredowi Jelinekowi z 1985 roku brzmi: "Za każdym razem, gdy zwalniam lingwistę, wydajność naszego systemu rozpoznawania mowy rośnie".
|
||||
|
||||
**Synteza mowy** była historycznie realizowana za pomocą różnych mechanizmów zszywania, ale obecnie najnowocześniejszymi modelami są duże sieci konwersacyjne (np. [WaveNet](https://deepmind.com/blog/wavenet-launches-google-assistant/)), które generują surowe sygnały dźwiękowe.
|
||||
|
||||
**Tłumaczenie maszynowe** zwykle opierało się na technikach statystycznych opartych na frazach, ale sieci neuronowe szybko stają się dominujące. Moje ulubione architektury są trenowane w [wielojęzycznym środowisku](https://arxiv.org/abs/1611.04558), gdzie jeden model tłumaczy się z dowolnego języka źródłowego na dowolny język docelowy, oraz w słabo nadzorowanych (lub całkowicie [nienadzorowanych](https://arxiv.org/abs/1710.11041)) środowiskach.
|
||||
|
||||
**Gry.** Od dawna rozwijane są jawnie ręcznie kodowane programy do gry Go, ale [AlphaGo Zero](https://deepmind.com/blog/alphago-zero-learning-scratch/) (ConvNet, który analizuje surowy stan planszy i wykonuje ruch) stał się zdecydowanie najsilniejszym graczem w tej grze. Spodziewam się, że zobaczymy bardzo podobne efekty w innych obszarach, np. [w DOTA 2](https://blog.openai.com/more-on-dota-2/) czy [StarCraft](https://deepmind.com/blog/deepmind-and-blizzard-open-starcraft-ii-ai-research-environment/).
|
||||
|
||||
**Bazy** danych. Tradycyjne systemy poza sztuczną inteligencją również pojawiają się pierwsze oznaki przejścia. Na przykład " [The Case for Learned Index Structures](https://arxiv.org/abs/1712.01208) " zastępuje kluczowe komponenty systemu zarządzania danymi siecią neuronową, przewyższając zoptymalizowane pod względem pamięci podręcznej drzewa B-Trees nawet o 70% szybkości, jednocześnie oszczędzając rząd wielkości w pamięci.
|
||||
|
||||
Zauważysz, że wiele moich powyższych linków dotyczy pracy wykonanej w Google. ==Wynika to z faktu, że Google obecnie jest na czele przepisywania dużych fragmentów siebie w kod Software 2.0==. " [Jeden model, który rządzi wszystkimi](https://arxiv.org/abs/1706.05137) " daje wczesny szkic tego, jak to mogłoby wyglądać, gdzie statystyczna siła poszczególnych dziedzin jest połączona w jedno spójne rozumienie świata.
|
||||
|
||||
## Korzyści płynące z Oprogramowania 2.0
|
||||
|
||||
Dlaczego mielibyśmy woleć przenosić złożone programy do Oprogramowania 2.0? Oczywiście, łatwa odpowiedź brzmi: lepiej sprawdzają się w praktyce. Jednak istnieje wiele innych wygodnych powodów, by preferować ten stos. Przyjrzyjmy się niektórym zaletom Software 2.0 (pomyśl: ConvNet) w porównaniu z Software 1.0 (pomyśl: baza kodu C++ na poziomie produkcyjnym). Oprogramowanie 2.0 to:
|
||||
|
||||
**Obliczeniowo jednorodny**. Typowa sieć neuronowa składa się w pierwszym rzędzie z kanapki składającej się tylko z dwóch operacji: mnożenia macierzy i progowania przy zerze (ReLU). Porównaj to z zestawem instrukcji klasycznego oprogramowania, który jest znacznie bardziej heterogeniczny i złożony. Ponieważ implementacja oprogramowania 1.0 jest dostępna tylko dla niewielkiej liczby podstawowych prymitywów obliczeniowych (np. mnożenie macierzy), znacznie łatwiej jest tworzyć różne gwarancje poprawności i wydajności.
|
||||
|
||||
**Proste do pieczenia z silikonem**. W konsekwencji, ponieważ zestaw instrukcji sieci neuronowej jest stosunkowo niewielki, znacznie łatwiej jest zaimplementować te sieci znacznie bliżej krzemu, np. za pomocą [niestandardowych ASIC,](https://www.forbes.com/sites/moorinsights/2017/08/04/will-asic-chips-become-the-next-big-thing-in-ai/#7d6d7c0511d9) [układów neuromorficznych](https://spectrum.ieee.org/semiconductors/design/neuromorphic-chips-are-destined-for-deep-learningor-obscurity) i tak dalej. Świat się zmieni, gdy niskomocowa inteligencja stanie się wszechobecna wokół nas. Na przykład małe, tanie układy mogłyby mieć prewytrenowany ConvNet, rozpoznawacz mowy i sieć syntezy mowy WaveNet, wszystko zintegrowane w małym protomózgu, który można podłączyć do urządzeń.
|
||||
|
||||
**Stały czas trwania**. Każda iteracja typowego przejścia sieci neuronowej wymaga dokładnie tyle samo FLOPS. Nie ma żadnej zmienności w zależności od różnych ścieżek wykonania, które Twój kod może przeprowadzić przez rozległą bazę kodu C++. Oczywiście można mieć dynamiczne grafy obliczeniowe, ale przepływ wykonania jest zazwyczaj nadal znacznie ograniczony. W ten sposób niemal na pewno nigdy nie znajdziemy się w niezamierzonych, nieskończonych pętlach.
|
||||
|
||||
**Ciągłe korzystanie z pamięci**. W związku z powyższym, nie ma dynamicznie przydzielonej pamięci nigdzie, więc jest też niewielka możliwość przełączenia na dysk lub wycieków pamięci, które trzeba szukać w kodzie.
|
||||
|
||||
**Jest bardzo przenośny**. Ciąg mnożeń macierzy jest znacznie łatwiejszy do wykonania na dowolnych konfiguracjach obliczeniowych niż klasyczne binarki lub skrypty.
|
||||
|
||||
**Jest bardzo zwinny**. Jeśli miałbyś kod w C++ i ktoś chciałby, żebyś zrobił go dwa razy szybszego (kosztem wydajności, jeśli trzeba), to dostosowanie systemu do nowej specyfikacji byłoby bardzo niebanalne. Jednak w Software 2.0 możemy wziąć naszą sieć, usunąć połowę kanałów, przeprogramować i tam — działa dokładnie z dwukrotną prędkością i działa trochę gorzej. ==To magia. Z drugiej strony, jeśli masz więcej danych/obliczeń, możesz od razu poprawić działanie programu, dodając więcej kanałów i przeszkoleniając program.==
|
||||
|
||||
==**Moduły mogą się łączyć w optymalną całość**====.== Nasze oprogramowanie często jest rozkładane na moduły komunikujące się za pośrednictwem funkcji publicznych, API lub punktów końcowych. Jednak jeśli dwa moduły Software 2.0, które pierwotnie były trenowane osobno, wzajemnie współdziałają, możemy łatwo cofać się przez całość. Pomyśl, jak niesamowite mogłoby być, gdyby Twoja przeglądarka mogła automatycznie przeprojektować niskopoziomowe instrukcje systemowe o 10 warstw niżej, aby osiągnąć większą efektywność ładowania stron internetowych. Albo czy biblioteka komputerowego widzenia (np. OpenCV), którą zaimportowałeś, mogłaby być automatycznie dostrojona do twoich konkretnych danych. W wersji 2.0 to jest domyślne zachowanie.
|
||||
|
||||
**To lepsze niż ty**. Wreszcie, i co najważniejsze, sieć neuronowa to lepszy kawałek kodu niż cokolwiek, co ty czy ja możemy wymyślić w dużej części wartościowych pionów, które obecnie przynajmniej obejmują wszystko, co związane z obrazami/wideo i dźwiękiem/mową.
|
||||
|
||||
## Ograniczenia oprogramowania 2.0
|
||||
|
||||
Stos 2.0 ma też swoje wady. Na końcu optymalizacji zostajemy z dużymi sieciami, które działają dobrze, ale trudno powiedzieć jak. W wielu obszarach zastosowań możemy wybrać model w 90% dokładny, który rozumiemy, ==albo model w 99% dokładny, którego nie rozumiemy.==
|
||||
|
||||
Stos 2.0 może zawodzić [w nieintuicyjny i kompromitujący sposób](https://motherboard.vice.com/en_us/article/nz7798/weve-already-taught-artificial-intelligence-to-be-racist-sexist), a co gorsza, może "cicho zawiódć", np. poprzez ciche przyjmowanie uprzedzeń w danych treningowych, które są bardzo trudne do właściwej analizy i badania, gdy ich rozmiary w większości przypadków sięgają milionów.
|
||||
|
||||
Wreszcie, wciąż odkrywamy niektóre osobliwe właściwości tego stosu. ==Na przykład istnienie przykładów== ==i== ==[ataków](https://github.com/yenchenlin/awesome-adversarial-machine-learning)== ==[adwersarialnych](https://blog.openai.com/adversarial-example-research/)== ==podkreśla nieintuicyjny charakter tego stosu.==
|
||||
|
||||
## Programowanie w stosie 2.0
|
||||
|
||||
Oprogramowanie 1.0 to kod, który piszemy. Software 2.0 to kod napisany przez optymalizację opartą na kryterium oceny (np. "poprawnie sklasyfikuj te dane treningowe"). Prawdopodobne jest, że każde ustawienie, w którym program nie jest oczywiste, ale można wielokrotnie oceniać jego wydajność (np. — czy poprawnie sklasyfikowałeś niektóre obrazy? czy wygrywasz w grach Go?), podlegnie tej zmianie, ponieważ optymalizacja może znaleźć znacznie lepszy kod niż ten, który napisałby człowiek.
|
||||
|
||||
|
||||
|
||||
Ma znaczenie soczewka, przez którą obserwujemy trendy. Jeśli uznamy Software 2.0 za nowy i wyłaniający się paradygmat programowania, zamiast traktować sieci neuronowe jako całkiem dobry klasyfikator w klasie technik uczenia maszynowego, ekstrapolacje stają się bardziej oczywiste i widać, że jest jeszcze wiele pracy do zrobienia.
|
||||
|
||||
W szczególności zbudowaliśmy ogromną ilość narzędzi wspierających ludzi w pisaniu kodu 1.0, takich jak potężne IDE z funkcjami takimi jak podświetlanie składni, debugery, profilery, go to def, integracja z gitem itd. W stosie 2.0 programowanie odbywa się poprzez gromadzenie, masowanie i czyszczenie zbiorów danych. Na przykład, gdy sieć zawodzi w trudnych lub rzadkich przypadkach, nie naprawiamy tych przewidywań przez pisanie kodu, lecz przez dodanie większej liczby oznaczonych przykładów tych przypadków. Kto opracuje pierwsze IDE Software 2.0, które pomogą we wszystkich procesach gromadzenia, wizualizacji, czyszczenia, etykietowania i pozyskiwania danych? Być może IDE generuje obrazy, które sieć podejrzewa o błędne oznakowanie na podstawie utraty na przykład, albo pomaga w oznaczaniu, zasiewając etykiety z przewidywaniami, albo sugeruje przydatne przykłady do etykietowania na podstawie niepewności prognoz sieci.
|
||||
|
||||
Podobnie Github jest bardzo udanym miejscem dla kodu Software 1.0. Czy jest miejsce na Software 2.0 na Githubie? W tym przypadku repozytoria to zbiory danych, a commity składają się z dodawania i edycji etykiet.
|
||||
|
||||
Tradycyjne menedżery pakietów oraz powiązana infrastruktura serwisowa, taka jak pip, conda, docker itp., pomagają nam łatwiej wdrażać i komponować pliki binarne. Jak skutecznie wdrażać, udostępniać, importować i pracować z plikami binarnymi Software 2.0? Jaki jest odpowiednik conda dla sieci neuronowych?
|
||||
|
||||
W krótkim okresie oprogramowanie 2.0 stanie się coraz bardziej powszechne w każdej dziedzinie, gdzie wielokrotna ocena jest możliwa i tania, a sam algorytm trudno jest zaprojektować wprost. Istnieje wiele ekscytujących okazji, by rozważyć cały ekosystem tworzenia oprogramowania i to, jak można go dostosować do tego nowego paradygmatu programowania. A w dłuższej perspektywie przyszłość tego paradygmatu jest jasna, ponieważ coraz bardziej oczywiste jest, że ==gdy opracujemy AGI, z pewnością zostanie ono napisane w Software 2.0.==
|
||||
+275
@@ -0,0 +1,275 @@
|
||||
## Workflow Google Nanobanana: Jak jeden pomysł staje się 10 zasobami w 11 minut
|
||||
|
||||
[
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
](https://medium.com/@InsightfulEdge?source=post_page---byline--e75fca420d87---------------------------------------)
|
||||
|
||||
7 min czytania
|
||||
|
||||
12 godzin temu
|
||||
|
||||
Praktyczny system, którego twórcy używają, pozwala zamienić jeden artykuł w wizualizacje gotowe na platformę — bez projektantów, zdjęć stockowych czy wypalenia.
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
Obraz stworzony za pomocą Gemini
|
||||
|
||||
Patrzysz na pusty szablon Canva o 23:00. Znowu.
|
||||
|
||||
Już zrobiłeś trudną część. Napisałeś solidny artykuł o trendach pracy zdalnej. Zajęło to cztery godziny. Teraz nadchodzi część, przed którą nikt cię nie ostrzega: obraz w nagłówku Medium, pięć pinów na Pinterest, bo algorytm chce "świeżych" wizualizacji, grafikę LinkedIn, może post na Instagramie.
|
||||
|
||||
Masz dwie opcje.
|
||||
Spędź kolejne cztery godziny na projektowaniu.
|
||||
Albo zdobądź zdjęcie stockowe, którego używa już 10 000 innych artykułów.
|
||||
|
||||
Żadna z tych opcji już nie działa.
|
||||
|
||||
Zdjęcia stockowe są ignorowane. Czytelnicy przewijają je jak reklamy banerowe. Ale projektowanie własnych wizualizacji dla każdej platformy sprawia, że tworzenie treści staje się drugą pełnoetatową pracą.
|
||||
|
||||
To jest paradoks treści 2025 roku: odbiorcy oczekują oryginalności, platformy nagradzają świeżość, a twórcy są przytłoczeni produkcją.
|
||||
|
||||
Rozwiązanie nie działa szybciej. To budowanie mądrzejszych systemów.
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
Obraz stworzony za pomocą Gemini
|
||||
|
||||
## Dlaczego to teraz jest ważne
|
||||
|
||||
Trzy zmiany cicho sprawiły, że stary workflow treści stał się przestarzały.
|
||||
|
||||
Po pierwsze, algorytmy platformy się zmieniły. Pinterest wyraźnie priorytetowo traktuje _świeże przypinki_, czyli nowe obrazy nawet wtedy, gdy adres URL pozostaje taki sam. Wykorzystywane wizualizacje są ograniczane. Program partnerski Medium nagradza retencję czytelników, a oryginalne wizualizacje konsekwentnie korelują z niższymi wskaźnikami odbijania niż zwykłe zdjęcia stockowe.
|
||||
|
||||
Po drugie, reakcja na "AI slop" jest realna. Gartner prognozuje, że większość treści cyfrowych będzie generowana przez AI w ciągu najbliższych kilku lat, ale teraz odbiorcy mogą natychmiast zauważyć efekty o niskim wysiłku. Pasek nie brzmi "używaj AI". To "używaj AI z gustem".
|
||||
|
||||
Po trzecie, różnica w wynikach zysków się powiększyła. Badania gospodarki twórców konsekwentnie pokazują, że osoby dystrybuujące na wielu platformach zarabiają około 2–3 razy więcej niż twórcy korzystający z jednej platformy. Haczyk to egzekucja. Ręczne dostosowanie jednego pomysłu na wiele platform zajmuje godziny, a nie minuty.
|
||||
|
||||
To właśnie wtedy twórcy zaczęli używać czegoś, co nazywają **Nanobanana**.
|
||||
|
||||
## Wielka Rzeczywistość
|
||||
|
||||
Przyszłość tworzenia treści nie należy do osób, które piszą lepsze prompty.
|
||||
Należy do osób, które budują lepsze rurociągi.
|
||||
|
||||
## Czym jest nanobanan (i dlaczego jest inny)
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
Obraz stworzony za pomocą Gemini
|
||||
|
||||
Wyobraź sobie średniowiecznych skrybów przepisujących książki ręcznie. Jedna kopia może zająć miesiące. Potem pojawiła się prasa drukarska. Jeden rękopis przekształcił się w tysiące książek przy tym samym wysiłku.
|
||||
|
||||
Nanobanana pełni podobną rolę w treściach wizualnych.
|
||||
|
||||
To nie jest oficjalna nazwa produktu. "Nanobanana" to przezwisko społecznościowe dla workflow **Google Gemini 2.5 Flash Image**. Nazwa ta przytrzymała się po tym, jak model osiągnął wyjątkowe wyniki w ślepych ocenach i testach twórców.
|
||||
|
||||
To, co ją wyróżnia, to nie jakość obrazu RAW. Tak działa model.
|
||||
|
||||
Starsze generatory obrazów traktują każdy prompt jako reset. Jeśli chcesz małej zmiany, zaczynasz od nowa.
|
||||
|
||||
Nanobanana działa w rozmowach.
|
||||
|
||||
Generujesz obraz.
|
||||
Potem mówisz: "Zmień oświetlenie."
|
||||
A potem: "Zrób to bardziej minimalistyczne."
|
||||
Następnie: "Zachowaj wszystko bez zmian, ale przełącz na układ pionowy."
|
||||
|
||||
Każda instrukcja rozwija poprzednią. To mniej przypomina dawanie promptów maszynie, a bardziej jak przekazywanie informacji zwrotnej projektantowi.
|
||||
|
||||
To również rozwiązuje długoletni problem AI: **spójność**. Gdy już ustalisz temat lub styl, model może go utrzymać w dziesiątkach wariantów. Ten sam wzrok. Ta sama tożsamość. Różne formaty.
|
||||
|
||||
Według dokumentacji Google, Gemini 2.5 Flash generuje obrazy w zaledwie kilka sekund i kosztuje kilka centów za zdjęcie. W porównaniu do miesięcznych retainerów projektantów czy niekończących się poprawek w Canvie, matematyka zmienia się szybko.
|
||||
|
||||
## Problem ludzki: Dlaczego ręczne procesy zawodzą
|
||||
|
||||
Większość twórców uważa, że mają problem z projektem. Nie mają. Mają problem z przepływem pracy.
|
||||
|
||||
### **Mit 1: Zdjęcia stockowe są "wystarczająco dobre".**
|
||||
|
||||
Wiele badań content marketingu pokazuje, że oryginalne wizualizacje korelują z 30–40% wyższymi wskaźnikami konwersji i zaangażowania. Duplikaty obrazów również syggują niską jakość dla wyszukiwarek.
|
||||
|
||||
### **Mit 2: Jedna treść działa wszędzie.**
|
||||
|
||||
Każda platforma nagradza różne formaty. To, co działa na Pinterest, niekoniecznie musi działać na Medium czy LinkedIn. Kopiowanie i wklejanie grafiki między platformami konsekwentnie nie osiąga żadnych rezultatów.
|
||||
|
||||
### **Mit 3: Więcej treści oznacza więcej pieniędzy.**
|
||||
|
||||
Ponad połowa twórców nadal zarabia poniżej 15 tys. dolarów rocznie, mimo ciągłego publikowania. Najlepsi nie publikują więcej pomysłów. Lepiej się przerabiają.
|
||||
|
||||
Prawdziwym wąskim gardłem nie jest kreatywność. To egzekucja. Większość twórców spędza więcej czasu na zmianie rozmiaru, eksportowaniu i dopracowywaniu wizualizacji niż na faktycznym myśleniu.
|
||||
|
||||
## Jak faktycznie działa workflow nanobanana
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
Obraz stworzony za pomocą Gemini
|
||||
|
||||
Pinterest działa teraz jak silnik świeżości. Osiągnięcie progów wzrostu często oznacza produkcję dziesiątek unikalnych zdjęć miesięcznie. Medium stawia na oryginalne wizualizacje. Zatrudnianie projektantów na taką skalę nie jest realistyczne.
|
||||
|
||||
Więc twórcy budowali pipeline'y.
|
||||
|
||||
Zamiast traktować projektowanie jako pracę ręczną, automatyzują go za pomocą narzędzi takich jak **n8n**, platforma automatyzacji przepływu pracy, połączona z API obrazów Gemini.
|
||||
|
||||
## Krok 1: Wprowadzanie przez bota Telegrama
|
||||
|
||||
Wysyłasz jedną wiadomość:
|
||||
|
||||
`"Cozy home office with plants; soft morning light, shallow depth of field"`
|
||||
|
||||
Średnik dzieli prompt.
|
||||
Pierwsza część definiuje temat.
|
||||
Druga część definiuje modyfikatory stylu i oświetlenia.
|
||||
|
||||
## Krok 2: Wzbogacenie promptu
|
||||
|
||||
AI dopracowuje ten wstępny pomysł w profesjonalny kierunek kreatywny. Pomyśl o kącie kamery, oświetleniu, fakturze, kompozycji.
|
||||
|
||||
## Krok 3: Generowanie równoległe
|
||||
|
||||
Wzbogacony prompt jest wysyłany do wielu modeli obrazów, w tym do Gemini. W ciągu kilku minut pojawia się galeria wariantów.
|
||||
|
||||
## Krok 4: Przechowywanie zasobów
|
||||
|
||||
Obrazy są automatycznie zapisywane w uporządkowanych folderach na Google Drive, gotowe do publikacji.
|
||||
|
||||
**Porównanie czasowe:**
|
||||
|
||||
- Ręczny przepływ pracy: 4–6 godzin na pomysł
|
||||
- Automatyczny przepływ pracy: 10–15 minut od początku do końca
|
||||
|
||||
To około 90% redukcji.
|
||||
|
||||
## Prosty workflow, który każdy pisarz może stosować (bez technicznych ustawień)
|
||||
|
||||
Jeśli jesteś pisarzem, który nie chce jeszcze korzystać z botów, API czy narzędzi automatyzacji, oto **zwykła wersja tego samego systemu**, z którego możesz korzystać już dziś.
|
||||
|
||||
To jest zmiana nastawienia, którą większość pisarzy pomija: nie projektuje się obrazów _po_ pisaniu. Planujesz wizualizacje _podczas_ pisania.
|
||||
|
||||
### Krok 1: Pisz z jednym wizualnym pomysłem na głowie
|
||||
|
||||
Zanim otworzysz Medium, odpowiedz na jedno pytanie:
|
||||
|
||||
**"Gdyby ten artykuł był jednym obrazem, co by pokazał?"**
|
||||
|
||||
Przykłady:
|
||||
|
||||
- Praca zdalna → spokojny kontrast między domowym biurem a chaotycznym biurem
|
||||
- Wypalenie → przeciążonym biurku powoli się opróżniającym
|
||||
- Produktywność → jedno wejście rozgałęziające się na wiele wyjść
|
||||
|
||||
Wystarczy **jedna mocna wizualna metafora**.
|
||||
|
||||
### Krok 2: Użyj jednego głównego promptu (a potem go zmodyfikuj)
|
||||
|
||||
Zamiast za każdym razem wymyślać prompty na nowo, użyj **jednego wielokrotnego użytku głównego promptu** i zamieniaj tylko temat.
|
||||
|
||||
Oto wersja, którą każdy pisarz może skopiować i wkleić do narzędzi Gemini, Canva AI lub podobnych:
|
||||
|
||||
**Główny obraz / Prompt ilustracyjny**
|
||||
|
||||
> _"\[TEMAT LUB SCENA\], wyraźny punkt centralny, niezagracona kompozycja. Styl ilustracji redakcyjnej, spokojny i czytelny. Naturalne oświetlenie, delikatny kontrast, neutralna paleta kolorów. Zaprojektowany, by wyjaśnić pomysł, a nie dekorować. Bez tekstu, bez logotypów, bez znaków wodnych."_
|
||||
|
||||
Teraz zmieniasz **tylko temat**:
|
||||
|
||||
- "Spokojne domowe biuro kontra chaotyczne biuro, podzielona scena"
|
||||
- "Przeciążone biurko stopniowo się opróżnia, przed i po"
|
||||
- "Jedna centralna idea rozgałęziająca się na wiele wyników, prosty schemat"
|
||||
|
||||
To wszystko. Bez żargonu kamery. Brak terminów technicznych. Tylko jasność.
|
||||
|
||||
### Krok 3: Stwórz 3 celowe wariacje
|
||||
|
||||
Użyj tego samego promptu, ale lekko zmodyfikuj _intencję_:
|
||||
|
||||
- **Wersja A (neutralna):** zrównoważone oświetlenie, spokojny ton
|
||||
- **Wersja B (wysoki kontrast):** ciemniejsze tło, mocniejsze skupienie
|
||||
- **Wersja C (Minimalna):** mniej elementów, więcej białej przestrzeni
|
||||
|
||||
Nie gonisz za perfekcją. Tworzysz opcje.
|
||||
|
||||
### Krok 4: Generuj wariacje, a nie perfekcję
|
||||
|
||||
Używaj dowolnego narzędzia do obrazowania, z którym czujesz się komfortowo (Gemini, Canva AI lub podobne).
|
||||
|
||||
Wygeneruj 3–5 wariantów, a następnie zatrzymaj się.
|
||||
|
||||
Twoim celem nie jest idealny obraz. To wybór.
|
||||
|
||||
### Krok 5: Dopasuj zdjęcia do platform
|
||||
|
||||
Użyj tego samego pomysłu, ale w innej stylizacji:
|
||||
|
||||
1. **Medium**: czysta, redakcyjna, spokojna
|
||||
2. **Pinterest**: wyraźny kontrast, wyraźny temat
|
||||
3. **LinkedIn**: minimalistyczny, profesjonalny
|
||||
4. Instagram: styl życia, **atmosfera**
|
||||
|
||||
Nie tworzysz nowych pomysłów. Przeformułowujesz jeden pomysł.
|
||||
|
||||
### Krok 6: Ponownie wykorzystaj zwycięzców
|
||||
|
||||
Obserwuj, co działa.
|
||||
|
||||
Obraz, który zapisuje się na Pinterest lub wydłuża czas czytania na Medium, staje się twoim domyślnym stylem na przyszłe artykuły.
|
||||
|
||||
Tak właśnie pisarze po cichu budują tożsamość wizualną, nie zatrudniając projektantów.
|
||||
|
||||
## Jedno nasiono, wiele plonów
|
||||
|
||||
Naciśnij enter lub kliknij, aby zobaczyć obraz w pełnym rozmiarze
|
||||
|
||||
|
||||
|
||||
Obraz stworzony za pomocą Gemini
|
||||
|
||||
1. Napisz jedną kluczową treść
|
||||
2. Zidentyfikuj centralną ideę wizualną
|
||||
3. Generuj wiele stylów wizualnych
|
||||
4. Zaplanuj każdą wersję tak, jak najlepiej pasuje
|
||||
|
||||
To ten sam pomysł. Ten sam adres URL. Świeże wizualizacje wszędzie.
|
||||
|
||||
## Budowanie własnego workflow
|
||||
|
||||
**Faza 1: Konfiguracja**
|
||||
, załóż bota na Telegramie. Ustaw n8n. Zdobądź dostęp API do Gemini i LLM do doprecyzowania promptów. Połącz Google Drive.
|
||||
|
||||
**Faza 2: Automatyzacja**
|
||||
Twój workflow obejmuje węzeł wyzwalający, parser promptu, wzbogacanie promptów oraz generowanie obrazów.
|
||||
|
||||
**Faza 3: Iteracja**
|
||||
Generuj wariacje. Osiągi na torze. Dopracuj prompty.
|
||||
|
||||
Przestajesz myśleć: "Muszę zaprojektować 20 obrazów."
|
||||
Zaczynasz myśleć: "Potrzebuję czterech dobrych promptów."
|
||||
|
||||
## Nieintuicyjna prawda o przepływach pracy AI
|
||||
|
||||
Szybkość nie zastępuje smaku. Umożliwia eksperymentowanie.
|
||||
|
||||
Gdy obrazy zajmują minuty zamiast godzin, testujesz pomysły zamiast zgadywać. Platformy decydują, co działa. Ty zatrzymasz zwycięzców.
|
||||
|
||||
Klienci nie płacą za piksele. Płacą za szybkość, konsekwencję i wyniki.
|
||||
|
||||
## Dokąd to dalej
|
||||
|
||||
Mamy już za sobą fazę nowości AI. Przyszłość należy do infrastruktury: systemów, które cicho zamieniają pomysły w zasoby, nie wypalając przy tym ludzi.
|
||||
|
||||
Dla pisarzy oznacza to wyższą retencję.
|
||||
Dla marketerów – lepsza dystrybucja.
|
||||
Dla agencji – szybsza realizacja.
|
||||
|
||||
**Która część twojego workflow pochłania teraz najwięcej czasu: pisanie, wizualizacje czy dystrybucja?**
|
||||
Jeśli będzie zainteresowanie, opublikuję kontynuację z dokładnym workflow n8n, strukturą promptów i parametrami Gemini, których używam.
|
||||
@@ -0,0 +1,66 @@
|
||||
## Wpływ AI na administrację bazami danych
|
||||
|
||||
Ekspert ds. baz danych Craig Mullins wyjaśnia, jak DBA mogą ewoluować wraz z AI, gdy technologia ta coraz bardziej wpływa na ich miejsca pracy
|
||||
|
||||
|
||||
|
||||
AI to technologia transformacyjna, która w końcu osiągnęła poziom dojrzałości, na którym zaczęła wpływać na wiele tradycyjnych stanowisk zawodowych. Jedną z tych ról jest administrator baz danych, czyli DBA. W rzeczywistości, w miarę jak organizacje nadal tworzą i przetwarzają coraz więcej danych oraz polegają na nich przy podejmowaniu decyzji, rola DBA staje się coraz ważniejsza, aby zapewnić, że dane pozostają dokładne, dostępne i użyteczne. Integracja automatyzacji opartej na AI i inteligentnej analityki w zarządzaniu bazą danych zmienia podejście DBA do pracy, zwiększając efektywność i wprowadzając nowe wyzwania.
|
||||
|
||||
## **Ulepszona automatyzacja**
|
||||
|
||||
DBA stają przed rosnącymi wymaganiami. Co roku organizacje dodają dane, które muszą być zarządzane, co wpływa na obciążenie DBA. Oprócz większych ilości danych, dostęp do większej liczby danych jest również szybszy i z większej liczby źródeł niż kiedykolwiek wcześniej. Każda aktywność dotycząca danych musi być wykonywana bez dłuższych przestojów, jednocześnie uwzględniając nowe typy i możliwości baz danych oraz korzystając z mniejszej liczby DBA niż kiedykolwiek wcześniej.
|
||||
|
||||
Co można więc zrobić? DBA mogą automatyzować rutynowe zadania, takie jak kopie zapasowe baz danych, monitorowanie wydajności i utrzymanie systemu. I tak jest od lat, ale obietnicą AI jest inteligentna automatyzacja, w której podjęte działania mogą się zmieniać na podstawie dodatkowych informacji, a oprogramowanie może nauczyć się, które operacje mają największy sens w danej konkretnej sytuacji i implementacji.
|
||||
|
||||
Gdy oprogramowanie potrafi reagować i dostosowywać się do sytuacji, zamiast rutynowo automatyzować konkretne zadanie, DBA uwolnia więcej czasu, pozwalając im skupić się na bardziej złożonych zadaniach.
|
||||
|
||||
## **Poprawa wydajności i niezawodności**
|
||||
|
||||
DBA mogą zmniejszyć przestoje i poprawić niezawodność systemu, korzystając z narzędzi opartych na AI do monitorowania i optymalizacji wydajności baz danych. Należy jednak pamiętać, że to dopiero rozwijająca się dziedzina i nie jest jeszcze rozsądnym rozwiązaniem, by całkowicie oddać optymalizację wydajności baz danych narzędziom AI. W miarę dojrzewania narzędzi do wydajności baz danych AI, DBA będą mogli ich wykorzystywać do znaczącej poprawy wydajności baz danych i aplikacji.
|
||||
|
||||
Jednym z ważnych obszarów, które DBA muszą uwzględnić, jest analityka predykcyjna. Wykorzystanie algorytmów AI do analizy historycznych danych wydajności i identyfikowania wzorców pozwala im przewidywać potencjalne problemy z wydajnością zanim się pojawią. Dzięki temu DBA mogą proaktywnie zapobiegać przestojom i poprawiać niezawodność systemu.
|
||||
|
||||
Kolejną nową możliwością zarządzania bazami danych jest optymalizacja zapytań oparta na AI. Są dwa aspekty tej zdolności: jeden reaktywny, drugi proaktywny. Reaktywna zdolność analizy zapytań może analizować istniejące plany dostępu do zapytań i udzielać porad dotyczących optymalizacji na podstawie rzeczywistych wskaźników wykonania i statystyk bazy danych. Drugim aspektem jest proaktywność, czyli osadzenie AI w optymalizatorze baz danych. Jest to ewolucja od tradycyjnego optymalizatora opartego na kosztach na optymalizator wspierany przez AI, w którym optymalizator opiera się na wyuczonym modelu danych i zapytań, dzięki czemu może poprawić wydajność dla Twojego konkretnego użytku.
|
||||
|
||||
Inne obszary, w których AI może wspomóc administrację bazą danych, to analiza alokacji zasobów z wykorzystaniem AI, inteligentne indeksowanie oparte na rzeczywistym użyciu zapytań oraz automatyczne dostrajanie. Zaawansowane algorytmy AI baz danych mogą automatycznie dostosowywać parametry i ustawienia konfiguracji, aby zoptymalizować wydajność w oparciu o rzeczywiste wzorce obciążenia.
|
||||
|
||||
Narzędzia oparte na AI mogą znacząco poprawić wydajność baz danych poprzez:
|
||||
|
||||
- Automatyzacja zadań monitorujących i optymalizacyjnych
|
||||
- Przewidywanie potencjalnych problemów z wydajnością
|
||||
- Optymalizacja alokacji zasobów
|
||||
- Inteligentne indeksowanie danych na podstawie rzeczywistych zapytań bazowych
|
||||
|
||||
Korzystając z zalet AI, DBA mogą poprawić wydajność baz danych, skrócić przestoje i poprawić doświadczenia użytkowników.
|
||||
|
||||
## **Rozwiązywanie problemów**
|
||||
|
||||
AI może również wspierać DBA w identyfikacji i rozwiązywaniu problemów, wykorzystując dane historyczne i informacje w czasie rzeczywistym, aby dostarczać wglądy i rekomendacje dotyczące naprawy. Tego typu ulepszone informacje mogą umożliwić DBA podejmowanie lepiej świadomych decyzji dotyczących tradycyjnych zadań DBA, takich jak projektowanie baz danych, alokacja zasobów i optymalizacja wydajności.
|
||||
|
||||
Ta lepsza informacja, w połączeniu z możliwością narzędzi opartych na AI na analizie ogromnych ilości danych i wdrażania potencjalnych działań naprawczych, może pomóc DBA poprawić swoje umiejętności rozwiązywania problemów. Powinno to skutkować szybszym wykrywaniem i rozwiązywaniem problemów, mniejszą liczbą spowolnień wydajności oraz skróconym czasem przestojów.
|
||||
|
||||
## **Dodatkowe implikacje**
|
||||
|
||||
Kolejnym obszarem, w którym AI może wpłynąć na DBA, jest poprawa bezpieczeństwa baz danych. Zagrożenia cybernetyczne stale rosną na bardziej zaawansowanych poziomach, wymagając proaktywnych działań bezpieczeństwa. Rozwiązania bezpieczeństwa oparte na AI potrafią wykrywać nietypowe wzorce dostępu, identyfikować potencjalne słabości i reagować na zagrożenia szybciej niż tradycyjne podejścia bezpieczeństwa. Modele uczenia maszynowego mogą analizować ogromne ilości danych logowych, aby przewidzieć potencjalne naruszenia zanim do nich dojdą, wzmacniając ochronę wrażliwych informacji. Pozwala to DBA odejść od reaktywnych środków bezpieczeństwa i zamiast tego przyjąć bardziej predykcyjne podejście, które minimalizuje ryzyko, zanim się rozwinie.
|
||||
|
||||
Ewolucja AI w administracji baz danych objęła także integrację i migrację danych. Organizacje coraz częściej wdrażają środowiska hybrydowe i wielochmurowe, co czyni ważne zapewnienie płynnego przepływu danych między platformami. Narzędzia oparte na AI wspomagają te przejścia, automatyzując konwersje schematów, optymalizując procesy transferu danych i zapewniając spójność w różnych środowiskach. Zamiast ręcznie mapować struktury danych i rozwiązywać problemy z kompatybilnością, DBA mogą wykorzystać AI do upraszczania tych złożonych operacji, redukcji błędów i przyspieszania harmonogramu migracji.
|
||||
|
||||
Wzrost rozwoju AI zapoczątkował także transformację w projektowaniu i architekturze baz danych. Tradycyjne relacyjne systemy baz danych były budowane z myślą o danych strukturalnych, ale rosnące wykorzystanie danych niestrukturalnych i półstrukturalnych wymaga nowych lub zmodyfikowanych podejść. Analizy oparte na AI umożliwiają organizacjom projektowanie bardziej elastycznych i adaptacyjnych architektur baz danych, które mogą obsłużyć różnorodne typy danych. Dostępne są hybrydowe systemy bazodanowe łączące relacyjne, NoSQL oraz bazy graficzne, aby zoptymalizować przechowywanie i pobieranie danych. Oznacza to, że DBA muszą nauczyć się poruszać i zarządzać tą złożoną nową rzeczywistością, wybierając odpowiednie technologie bazodanowe w oparciu o wymagania dotyczące obciążenia i analitykę opartą na AI.
|
||||
|
||||
## **Wymagane są poprawy umiejętności i wiedzy o AI**
|
||||
|
||||
W miarę rozwoju automatyzacji opartej na AI, DBA będą musieli zdobyć głębsze zrozumienie działania AI. Chociaż AI może dostarczyć cennych informacji na temat optymalizacji baz danych i aplikacji, nie jest nieomylna. W rzeczywistości istnieje zjawisko zwane halucynacją AI, w której AI generuje wyniki nielogiczne lub całkowicie niedokładne. DBA muszą umieć interpretować rekomendacje generowane przez AI, wykrywać potencjalne uprzedzenia i halucynacje, wykrywać nieścisłości oraz podejmować działania, gdy jest to konieczne. Kluczowe jest, aby rekomendacje oparte na AI były stale oceniane, aby organizacje nie podążały ślepo za automatycznymi decyzjami, które mogą mieć niezamierzone konsekwencje.
|
||||
|
||||
Kolejnym potencjalnym wyzwaniem polegającym na AI jest etyka. Skupienie się na etyce powinno być rosnącym wymogiem dla DBA, ponieważ organizacje wdrażają AI i coraz częściej polegają na danych jako podstawie podejmowania decyzji. Zapewnienie systemom AI dostępu do dużych ilości wrażliwych danych budzi obawy dotyczące prywatności i zgodności danych. DBA muszą być częścią zespołu (wraz z biznesem, prawem i audytorami), który zapewnia, że procesy oparte na AI spełniają wymogi regulacyjne i standardy etyczne. Obejmuje to utrzymanie przejrzystości w podejmowaniu decyzji AI, ochronę danych użytkowników oraz zwalczanie potencjalnych uprzedzeń w systemach automatycznych. Ostatecznie kluczowe jest, aby organizacje polegające na AI dla zwiększenia efektywności również zadbały o ustalenie i przestrzeganie etycznych praktyk dotyczących danych.
|
||||
|
||||
DBA muszą zdobyć większą wiedzę na temat AI i jej możliwości. Gdy automatyzacja oparta na AI może obsłużyć wiele tradycyjnych zadań DBA, DBA muszą ewoluować, aby zdobyć wiedzę z zakresu uczenia maszynowego, chmury obliczeniowej i analizy danych. DBA, którzy przyjmują ciągłe uczenie się i dostosowują się do nowych technologii, znajdą się w dobrej pozycji w tym zmieniającym się otoczeniu. Zrozumienie algorytmów AI, rozwijanie biegłości w narzędziach automatyzacji oraz współpraca z data scientistami to podstawowe wymagania dla następnej generacji DBA.
|
||||
|
||||
Współpraca między DBA a specjalistami AI to kolejny obszar zainteresowania, ponieważ AI wpływa na zarządzanie bazami danych. Rośnie zapotrzebowanie na zespoły międzyfunkcyjne, które integrują wiedzę bazową z możliwościami AI. DBA współpracujący z inżynierami danych, badaczami AI i data scientistami mogą pomóc zapewnić, że rozwiązania oparte na AI są wdrażane skutecznie i zgodne z celami biznesowymi. Takie podejście zachęca do innowacji i w pełni wykorzystuje AI w administracji bazą danych.
|
||||
|
||||
## **Sedno sprawy**
|
||||
|
||||
Przyszłość administracji bazami danych w erze AI będzie polegać na ciągłej adaptacji i rozwoju. Chociaż AI będzie wykorzystywana do automatyzacji wielu rutynowych zadań, rola DBA pozostanie ważna nie tylko w zapewnieniu integralności, bezpieczeństwa i zgodności danych, ale także w nadzorowaniu zaleceń i działań związanych z AI.
|
||||
|
||||
Wdrożenie zarządzania bazami danych opartych na AI powinno przynieść organizacjom przewagę konkurencyjną poprzez poprawę efektywności baz danych, obniżenie kosztów operacyjnych oraz odblokowanie nowych wniosków z ich danych. DBA, którzy rozwijają się wraz z postępem w AI, zdobywając nowe umiejętności i traktując AI jako asystentkę, a nie zagrożenie, będą się rozwijać w tym nowoczesnym, nasyconym AI i skoncentrowanym na danych świecie pełnym AI.
|
||||
|
||||
___
|
||||
+126
@@ -0,0 +1,126 @@
|
||||
---
|
||||
title: "Zbudowałem narzędzie, które myśli razem z tobą. Oto dlaczego aplikacje do robienia notatek rozwiązują niewłaściwy problem."
|
||||
source: "https://medium.com/@a18355692523/i-built-a-tool-that-thinks-with-you-heres-why-note-taking-apps-are-solving-the-wrong-problem-d60662eece46"
|
||||
author:
|
||||
- "[[Klinstar]]"
|
||||
published: 2026-03-11
|
||||
created: 2026-05-14
|
||||
description: "More"
|
||||
tags:
|
||||
- "clippings"
|
||||
---
|
||||
## Prawdziwym wąskim gardłem nie jest przechwytywanie informacji. To połączenie z nim.
|
||||
|
||||
Trzy lata temu przeczytałem książkę o japońskim projektowaniu ogrodów. Gdzieś w rozdziale czwartym miałem wgląd, który naprawdę zmienił moje podejście do rozwoju produktu. Autor opisał, że mistrzowie ogrodnicy nie układają kamieni — słuchają, czym kamienie chcą się stać.
|
||||
|
||||
Pamiętam to uczucie. Pamiętam, że odłożyłem książkę. Pamiętam, że myślałem, że *to zmienia wszystko.*
|
||||
|
||||
Nie pamiętam szczegółów.
|
||||
|
||||
Zniknęło. Rozpuszczone w rzece informacji, która przepływa przez moje życie każdego dnia. I żadne przeszukiwanie moich notatek, zakładek, podkreśleń — nic tego nie przywraca. Bo nigdy nie zapisywałem tego w sposób, który łączyłby to z czymkolwiek innym.
|
||||
|
||||
To też się zdarza tobie. Wiem, że tak jest.
|
||||
|
||||
## Błędna diagnoza za 5 miliardów dolarów
|
||||
|
||||
Branża narzędzi do produktywności jest ogromna. Notion, Obsidian, Roam Research, Logseq, Apple Notes, Google Keep — setki aplikacji konkurują o to, by pomóc Ci *zbierać* informacje. I wszyscy są w tym zadziwiająco dobrzy.
|
||||
|
||||
Ale oto czego nikt z nich nie robi: **myśli razem z tobą.**
|
||||
|
||||
Każda aplikacja do robienia notatek opiera się na tym samym założeniu: najtrudniejsze jest *wprowadzenie informacji.* Oznacz go, zarchiwuj, podlinkuj, a znajdziesz go później, gdy będziesz potrzebować. Problem polega na tym, że ten model nakłada na *ciebie* cały ciężar poznawczy — musisz wiedzieć, czego szukać, musisz pamiętać, że istnieje powiązanie, zanim będziesz mógł je sprawdzić, i musisz wykonać kreatywną pracę łączącą idee między dziedzinami całkowicie we własnej głowie.
|
||||
|
||||
To jak budowanie biblioteki z milionem książek i bez bibliotekarza. Książki tam są. Po prostu nie możesz znaleźć tego, czego potrzebujesz w danym momencie.
|
||||
|
||||
Prawdziwym problemem nigdy nie było schwytanie. To **była kolizja**.
|
||||
|
||||
## Czym naprawdę jest kreatywność
|
||||
|
||||
W 1996 roku badaczka Margaret Boden opublikowała ramy, które zmieniły sposób, w jaki naukowcy kognitywni myślą o kreatywności. Twierdziła, że przełomy twórcze niemal zawsze wynikają z jednego z trzech procesów: eksploracji przestrzeni konceptualnej, transformacji reguł tej przestrzeni lub — najczęściej — **połączenia idei z odległych dziedzin**.
|
||||
|
||||
Steve Jobs słynnie powiązał kaligrafię z typografią komputerową. Darwin łączył ekonomię maltuzjańską z obserwacją biologiczną. Chirurg z Indii powiązał techniki składania origami z nową metodą chirurgii rekonstrukcyjnej.
|
||||
|
||||
Schemat jest zawsze ten sam: ktoś, kto przyswoił pomysły z zupełnie różnych dziedzin, nagle dostrzega strukturalne podobieństwo między nimi. Połączenie zawsze istniało. Ludzki mózg po prostu nie jest stworzony do długoterminowego asocjacyjnego wyszukiwania setek niezwiązanych tematów przechowywanych przez miesiące lub lata.
|
||||
|
||||
Ale maszyna jest.
|
||||
|
||||
## Więc zbudowałem krosno
|
||||
|
||||
Loom to to, co nazywam *osobistą infrastrukturą poznawczą*. To nie jest aplikacja do robienia notatek. Nie drugiego mózgu. Coś innego.
|
||||
|
||||
Główna idea: co jeśli twoje narzędzie myślowe nie tylko przechowuje twoje myśli, ale aktywnie próbuje je zderzyć?
|
||||
|
||||
Oto jak to działa.
|
||||
|
||||
**Zbierasz myśli.** Pomysły, notatki z czytania, fragmenty rozmów, obserwacje, refleksje — cokolwiek. Każdy z nich jest oznaczany, kategoryzowany i wpleciony w żywy wykres wiedzy. Możesz zobaczyć topologię własnego myślenia przedstawioną jako interaktywną sieć kierowaną siłą. Węzły grupują się i łączą na podstawie semantycznego nakładania się. Dziwnie pięknie jest obserwować, jak twój umysł nabiera kształtu na ekranie.
|
||||
|
||||
**Potem naciskasz na Kolidzie.**
|
||||
|
||||
Loom losowo wybiera dwie lub trzy twoje myśli — często z zupełnie różnych kategorii i okresów — i przekazuje je silnikowi AI. Nie podsumowujmy ich. Nie po to, by je organizować. **By odnaleźć ukryte strukturalne powiązanie między nimi**, którego sam byś nigdy nie dostrzegł.
|
||||
|
||||
Wyniki często są zaskakujące. Notatka o tym, jak kolonie mrówek podejmują decyzje + refleksja, dlaczego spotkania zespołowe wydają się nieproduktywne = wgląd w rozproszone systemy decyzyjne i dlaczego scentralizowany proces zatwierdzania w firmie jest wąskim gardłem, a nie ludzie.
|
||||
|
||||
To wyraz z książki o improwizacji jazzowej + frustracja dotycząca procesu wdrażania produktu = uświadomienie sobie, że świetny onboarding, podobnie jak świetny jazz, wymaga silnej, *niewidocznej* struktury dla osoby, która go doświadcza.
|
||||
|
||||
To nie są przypadkowe skojarzenia. To strukturalnie głębokie powiązania ujawnione przez AI, która może jednocześnie przechowywać całą twoją historię myśli w pamięci roboczej. Coś, czego twój biologiczny mózg dosłownie nie jest w stanie zrobić.
|
||||
|
||||
## Trzy silniki AI, nie jeden
|
||||
|
||||
Po setkach godzin badań odkryłem, że zderzenie poznawcze to dopiero początek. AI może robić trzy zasadniczo różne rzeczy z twoimi myślami:
|
||||
|
||||
**Kolizja** — flagowa funkcja. Połącz odległe pomysły, znajdź mostek. To tutaj żyje serendip. Za każdym razem, gdy naciśniesz przycisk, pojawia się inna kombinacja. Niektóre kolizje to niewypałki. Niektóre zmieniają sposób, w jaki postrzegasz problem. Wskaźnik trafień jest zaskakująco wysoki.
|
||||
|
||||
**Rozpoznawanie wzorców** — oddalenie perspektywy. Zamiast łączyć dwie myśli, AI skanuje *całą* twoją bibliotekę i identyfikuje motywy, o których nie wiedziałeś, że je posiadasz. Preferencje myślenia. Powracające metafory. Ślepe punkty — kategorie, o których nigdy nie piszesz, pytania, których nigdy nie zadajesz. To jest metapoznanie jako usługa. Z zewnątrz pokazuje kształt twojego własnego umysłu.
|
||||
|
||||
**Pogłębianie Socratic —** przybliż obraz. Wybierz dowolną myśl, a SI zagra Sokratesem. Zadaje pytania, których sam sobie nie zadałeś. Ujawnia ukryte założenia. To przesuwa ideę do jej logicznego ekstremum i pokazuje, co się psuje. Wykorzystałem to, by testować strategie biznesowe, dopracowywać argumenty esejów i odkrywać, że połowa moich "oryginalnych" pomysłów to tak naprawdę odziedziczone założenia, których nigdy wcześniej nie analizowałem.
|
||||
|
||||
## Czym nie jest Krosno
|
||||
|
||||
|
||||
|
||||
Loom to nie kolejna otoczka chatbota AI. Nie wpisujesz promptów w pole i nie dostajesz akapitów z powrotem. AI działa *na podstawie twojego własnego myślenia* — to lustro z percepcją głębi.
|
||||
|
||||
Loom nie zastępuje Notion ani Obsidian. Nie zarządza projektami, nie śledzi zadań ani nie organizuje twojego życia. Robi jedno: poprawia jakość twojego myślenia.
|
||||
|
||||
Loom nie jest platformą SaaS. To jeden komponent Reacta. Jesteś właścicielem kodu, jesteś właścicielem danych, możesz wyeksportować wszystko jako JSON lub Markdown w dowolnym momencie. Nie ma serwera. Nie ma żadnego konta. Nie ma subskrypcji. Kupujesz go raz.
|
||||
|
||||
## Historia wersji umysłu
|
||||
|
||||
W Loom jest cichsza funkcja, którą pokochałem bardziej niż silnik AI.
|
||||
|
||||
Za każdym razem, gdy edytujesz myśl, Loom zapisuje poprzednią wersję. Automatycznie. Niewidzialnie. Jak Git, ale dla pomysłów.
|
||||
|
||||
Z czasem tworzy to coś niezwykłego: możesz zobaczyć, jak *ewoluowało* twoje rozumienie danego pojęcia. Co myślałeś o przywództwie sześć miesięcy temu w porównaniu do dziś. Jak twoja definicja "dobrego designu" zmieniła się w trzech projektach. Moment, gdy twoje niejasne przeczucie dotyczące pozycjonowania na rynku przerodziło się w jasną tezę.
|
||||
|
||||
To niezwykle rzadkie. Ludzie prawie nigdy nie mają okazji obserwować własnego rozwoju poznawczego w czasie rzeczywistym. Po prostu budzimy się pewnego dnia z innymi przekonaniami i nie potrafimy wyznaczyć tej drogi. Loom śledzi ścieżkę.
|
||||
|
||||
## Kto naprawdę tego potrzebuje
|
||||
|
||||
Krosno nie jest dla każdego. Jeśli robisz trzy notatki tygodniowo i głównie używasz telefonu do sprawdzania pogody, to nie jest twoje narzędzie.
|
||||
|
||||
Loom jest dla osób, które myślą zawodowo. Pisarze, którzy czerpią z tuzina dziedzin. Założyciele, którzy muszą połączyć badania klientów z trendami rynkowymi i ograniczeniami technicznymi. Badacze, którzy czytają różne dziedziny. Strategi, którzy potrzebują własnych pomysłów, by ich zaskoczyć.
|
||||
|
||||
To dla każdego, kto kiedykolwiek czuł, że jego najlepsze pomysły utknęły w lukach między nutami — w powiązaniach, które potrafią wyczuć, ale nie potrafią wyrazić.
|
||||
|
||||
## Niewygodna prawda o produktywności
|
||||
|
||||
Branża produktywności przez dwie dekady optymalizowała *produkcję*. Więcej zadań wykonanych. Więcej treści powstało. Zaplanowane kolejne spotkania. Wysłano więcej maili.
|
||||
|
||||
Prawie nikt nie optymalizuje *myślenia*.
|
||||
|
||||
A jednak — każdy przełomowy produkt, każdy przełomowy artykuł, każda strategia definiująca firmę zaczynała się od myśli. Zazwyczaj myśl łącząca dwie rzeczy, których nikt wcześniej nie połączył.
|
||||
|
||||
Narzędzia kształtują sposób myślenia. Obecnie nasze narzędzia kształtują nas ku płytkiemu, fragmentarycznemu, liniowemu myśleniu. Złap, archiwizuj, zapomnij. Złap, archiwizuj, zapomnij.
|
||||
|
||||
Loom to próba odwrócenia tego trendu. Zbudować narzędzie, które nagradza głębię zamiast szybkości. Połączenie ponad zbieranie danych. Myślę o przesadzeniu z działaniem.
|
||||
|
||||
## Spróbuj
|
||||
|
||||
Loom jest już dostępny na Gumroad. 29 dolarów za dożywotni dostęp. Pełny kod źródłowy. Brak subskrypcji. Brak lock-in. Eksportuj swoje dane w dowolnym momencie.
|
||||
|
||||
Jeśli dotarłeś aż tutaj, prawdopodobnie jesteś osobą, która coś z tego wyniesie.
|
||||
|
||||
[**Zdobądź Loom →**](https://klinstar.gumroad.com/l/loom)
|
||||
|
||||
*Jeśli to Cię zainteresowało, piszę o narzędziach myślenia, infrastrukturze poznawczej oraz przecięciu AI i ludzkiej kreatywności. Śledź po więcej.*
|
||||
|
||||
*Pytania? Jakieś przemyślenia? Przeczytałem każdą odpowiedź.*
|
||||
@@ -0,0 +1,24 @@
|
||||
# Zostałem DBA przez przypadek. I Ty pewnie też.
|
||||
|
||||
Czy kiedykolwiek obudziłeś się rano, spojrzałeś w lustro i zadałeś sobie pytanie: "Jak, u licha, zostałem administratorem baz danych?"
|
||||
|
||||
Jeśli tak, to witaj w klubie. Nie jesteś sam.
|
||||
|
||||
To "Syndrom Przypadkowego Administratora", zjawisko, które obserwuję od lat. Choć sam ukończyłem studia kierunkowe i od 25 lat zawodowo zajmuję się bazami danych, widziałem ten scenariusz dziesiątki razy. Zaczyna się niewinnie: jesteś deweloperem, który "zna się na SQL-u", albo administratorem systemów, który "ogarnia serwery". Nagle krytyczna baza danych zaczyna sprawiać problemy, a wszystkie oczy zwracają się na Ciebie. Obok swoich codziennych obowiązków, dostajesz nowy, niepisany etat: "strażnika danych".
|
||||
|
||||
Doskonale rozumiem to uczucie. Widziałem panikę w oczach ludzi, gdy produkcyjna baza zwalniała do tempa ślimaka. Wspierałem ich podczas nocnych poszukiwań odpowiedzi, dlaczego backup się nie odtworzył. Pomagałem im radzić sobie z presją, gdy bali się zepsuć system, od którego zależy działanie firmy. Obserwowałem, jak działają reaktywnie, gasząc pożary, bo brakowało im czasu i specjalistycznej wiedzy, by zająć się wydajnością, bezpieczeństwem i strategią długoterminową.
|
||||
|
||||
**Dlatego założyłem tego bloga.**
|
||||
|
||||
To miejsce dla wszystkich "przypadkowych administratorów". Dla tych, którzy zostali rzuceni na głęboką wodę i uczą się pływać, jednocześnie próbując utrzymać statek na powierzchni.
|
||||
|
||||
Moim celem jest stworzenie praktycznego przewodnika, który pomoże nam wspólnie przejść drogę od "przypadkowego" do w pełni świadomego i proaktywnego administratora baz danych. Będę dzielił się tutaj konkretnymi wskazówkami, sprawdzonymi rozwiązaniami i lekcjami wyciągniętymi z własnych błędów. Poruszymy tematy takie jak:
|
||||
|
||||
* **Podstawy, które ratują życie:** backup, odtwarzanie danych i plany awaryjne, które faktycznie działają.
|
||||
* **Optymalizacja dla opornych:** jak sprawić, by baza działała szybciej, nie posiadając doktoratu z informatyki.
|
||||
* **Automatyzacja i monitoring:** jak zmusić serwer, by sam informował Cię o problemach, zanim zadzwonią zdenerwowani użytkownicy.
|
||||
* **Bezpieczeństwo:** jak spać spokojnie, wiedząc, że dane są bezpieczne.
|
||||
|
||||
Ten blog to nie tylko zbiór technicznych artykułów. To zaproszenie do społeczności. Do dzielenia się doświadczeniami, zadawania pytań (nawet tych, które wydają się "głupie") i wspólnego rozwoju.
|
||||
|
||||
Bo administrowanie danymi nie musi być samotną walką. Uczmy się razem, jak przekuć przypadek w prawdziwą pasję i ekspertyzę.
|
||||
@@ -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]]
|
||||
@@ -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]]
|
||||
@@ -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]]
|
||||
@@ -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]]
|
||||
@@ -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]]
|
||||
@@ -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]]
|
||||
@@ -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]]
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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)...*
|
||||
@@ -0,0 +1,47 @@
|
||||
# Wiki Index
|
||||
|
||||
Katalog całej wiedzy zgromadzonej w wiki.
|
||||
|
||||
## Strategia i Metodyka
|
||||
- [[feynman_problems]] - 12 Ulubionych Problemów Feynmana (Kluczowe pytania).
|
||||
|
||||
## Podsumowania Źródeł (Summaries)
|
||||
- [[summaries/jak-zbudowalem-agenta-newslettera-n8n]] - Automatyzacja newslettera AI (Amit Kumar).
|
||||
- [[summaries/one-file-diary]] - System "One File Diary" (Jeff Huang).
|
||||
- [[summaries/accidental-dba-intro]] - Wprowadzenie do roli Accidental DBA.
|
||||
- [[summaries/ai-impact-on-dba]] - Wpływ AI na rolę DBA (Craig Mullins).
|
||||
- [[summaries/google-nanobanana-workflow]] - Workflow Nanobanana (Rahul Gaur).
|
||||
- [[summaries/karpathy-llm-wiki-breakdown]] - Analiza LLM Wiki Karpathy'ego (Urvil Joshi).
|
||||
- [[summaries/how-to-deploy-autoresearch]] - Przewodnik po Autoresearch (Karpathy).
|
||||
- [[summaries/software-2-0]] - Manifest Software 2.0 (Andrej Karpathy).
|
||||
- [[summaries/loom-thinking-tool]] - Narzędzie do kolizji myśli (Klinstar).
|
||||
- [[summaries/free-blog-seo-strategy]] - Strategia SEO dla darmowego bloga.
|
||||
|
||||
## Podmioty (Entities)
|
||||
- [[entities/n8n]] - Narzędzie do automatyzacji workflow.
|
||||
- [[entities/tavily]] - Silnik researchu dla AI.
|
||||
- [[entities/sql-server]] - System bazodanowy Microsoft.
|
||||
|
||||
## Koncepcje (Concepts)
|
||||
- [[concepts/human-in-the-loop]] - Model współpracy człowieka z AI.
|
||||
- [[concepts/accidental-dba]] - Syndrom przypadkowego administratora baz danych.
|
||||
- [[concepts/plain-text-productivity]] - Produktywność oparta na plikach tekstowych.
|
||||
- [[concepts/work-journaling]] - Metodyka prowadzenia dziennika pracy.
|
||||
- [[concepts/proactive-administration]] - Administracja zapobiegająca awariom.
|
||||
- [[concepts/ai-hallucinations]] - Ryzyko błędów w modelach AI.
|
||||
- [[concepts/ai-pipelines]] - Zautomatyzowane rurociągi przetwarzania AI.
|
||||
- [[concepts/knowledge-compilation]] - "Kompilowanie" surowej wiedzy do Wiki.
|
||||
- [[concepts/compounding-knowledge]] - Wiedza, która staje się gęstsza z czasem.
|
||||
- [[concepts/rag-vs-wiki]] - Porównanie podejścia stanowego i bezstanowego.
|
||||
- [[concepts/autoresearch]] - Autonomiczne badania nad AI prowadzone przez agentów.
|
||||
- [[concepts/val-bpb]] - Metryka jakości modelu (Bits Per Byte).
|
||||
- [[concepts/software-1-0]] - Tradycyjne programowanie (instrukcje).
|
||||
- [[concepts/software-2-0]] - Nowe programowanie (dane + optymalizacja).
|
||||
- [[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.
|
||||
|
||||
## Syntezy (Syntheses)
|
||||
- [[syntheses/porownanie-strategii-automatyzacji-ai]] - Zestawienie metodologii (n8n, Nanobanana, LLM Wiki).
|
||||
|
||||
## Inne
|
||||
- [[journal/index]] - Dziennik badań.
|
||||
@@ -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 Karpathy’s 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 Karpathy’s LLM Wiki_ Create your own knowledge base.md"]
|
||||
confidence: high
|
||||
---
|
||||
|
||||
# Andrej Karpathy’s 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
|
||||
@@ -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]]
|
||||
Reference in New Issue
Block a user