Graph engineering: od pętli do grafów wiedzy

18 lipca 2026 roku Peter Steinberger wrzucił na X półżartobliwe pytanie o przejście od pętli do grafów. Hamel Husain podchwycił i opublikował artykuł zatytułowany Loop Engineering Is Dead. Enter Graph Engineering. W tydzień termin był wszędzie.

To był głównie żart z tego, jak szybko ta dziedzina bije nowe dyscypliny — przeszliśmy od prompt engineeringu przez context engineering, harness engineering i loop engineering do graph engineeringu w jakieś osiemnaście miesięcy, a definicje mocno się pokrywają.

Ale żart chwycił, bo wskazuje na coś realnego. Oto część warta zachowania.

Trzy rzeczy, które ludzie nazywają „graph engineeringiem”

Termin przyszedł, niosąc co najmniej trzy odrębne idee. Większość internetowego zamieszania to ludzie kłócący się, przeskakując między nimi.

1. Grafy orkiestracji. Projektowanie systemu wieloagentowego jako jawnego grafu zamiast pętli while: typowane węzły, typowane przejścia, punkty kontrolne do wznowienia. To teren LangGraph i Temporal. To prawdziwa inżynieria — i liczy się głównie, gdy budujecie infrastrukturę agentową.

2. Grafy pętli. Sieci cykli samodoskonalenia obserwujących się nawzajem. Koncepcyjnie ciekawe i, zdaniem większości, dziś najmniej praktyczne.

3. Wiedza i pamięć o strukturze grafu. Wiedza agenta zapisana jako typowane węzły i krawędzie, po których faktycznie może chodzić, zamiast sterty dokumentów, którą co chwilę czyta od nowa i zgaduje na nowo.

Jeśli nie budujecie infrastruktury orkiestracji — a większość z nas nie buduje, łącznie z tymi, którzy patrzą, jak agenci wchodzą do przestrzeni pracy — to numer 3 zmienia wam dzień. Jest też najstarszy i najlepiej udokumentowany z trójki: grafy wiedzy istnieją dekady przed tym terminem.

Dlaczego krawędzie biją wyszukiwanie

Oto przykład, po którym wszystko wskakuje na miejsce.

Zapytajcie agenta: „Dlaczego zrezygnowaliśmy z Redisa w kolejce zadań?”

Wyszukiwanie pełnotekstowe zwróci każdy dokument zawierający „Redis” — po jakimś czasie pracy to dziesiątki plików i żaden nie jest odpowiedzią. Wyszukiwanie wektorowe zwróci dokumenty, które brzmią jak pytanie, co bywa gorsze: semantycznie blisko, przyczynowo nie na temat.

Graf odpowiada w trzech skokach:

kolejka zadań --decided_by--> ADR-007 (kolejka Postgres)
ADR-007       --supersedes--> ADR-003 (kolejka Redis)
ADR-003       --caused------> Incydent 2026-03-11

Odpowiedzi nie ma w żadnym pojedynczym dokumencie. Jest w ścieżce między nimi. Wyszukiwarka nie potrafi zwrócić ścieżki — zwraca węzły i liczy, że połączycie je sami.

I zwróćcie uwagę na kluczowy szczegół: krawędzie są nazwane. supersedes to nie caused, a caused to nie decided_by. Zdejmijcie etykiety, a wracacie do „te pliki jakoś się wiążą”, co zmusza agenta do otwarcia wszystkich i ponownego wnioskowania o relacji — dokładnie tej pracy, której chcieliście uniknąć.

Typowane krawędzie to cała sztuczka. Reszta to hydraulika.

Wasz vault Markdown to już 80 % tego

To niedoceniana obserwacja z całej dyskusji: dobrze utrzymany vault Markdown to już większość indeksu GraphRAG.

Pomyślcie, co daje wam za darmo zbiór notatek z wikilinkami:

• Węzły — jeden plik na ideę, źródło albo decyzję
• Krawędzie — każdy [[wikilink]] to połączenie, które ktoś świadomie ustanowił
• Rozstrzyganie tożsamości bytów rozwiązane z definicji — [[ADR-007]] to ten sam węzeł wszędzie, gdzie się pojawia. Bez dopasowywania rozmytego, bez kolizji embeddingów, bez „czy te dwa wzmiankowania to to samo?”

To ostatnie nie jest drobiazgiem. Rozstrzyganie tożsamości bytów to dokładnie miejsce, w którym większość automatycznych potoków budowy grafów wiedzy rozpada się po cichu. Vault to obchodzi, bo człowiek nazwał byt raz, a link jest tożsamością.

Czego surowemu vaultowi brakuje, to etykiet. [[ADR-007]] mówi, że dwie notatki są połączone. Nie mówi, jak. To pozostałe 20 %.

Jak to wygląda w praktyce

Wokół tej właśnie części zbudowano Minibase Vault, więc lepiej konkretnie o działaniu niż abstrakcyjnie o możliwościach.

Węzły biorą się z czytania. Klikacie rozszerzenie Minibase na czymkolwiek wartym zachowania — stronie dokumentacji, RFC, wątku na X, prelekcji — i ląduje to jako czysty Markdown w lokalnej bazie wiedzy. Bez kopiuj-wklej, bez kroku eksportu, bez karty „przeczytam później”, która ginie przy następnej awarii przeglądarki.

Krawędzie są zapisywane wraz z uzasadnieniem. Vault trzyma _graph.json w katalogu głównym:

{
  "edges": [
    {
      "from": "AI Research/attention-paper-20260405-1200.md",
      "to": "AI Research/transformer-tutorial-20260408-0900.md",
      "reason": "Both explain the attention mechanism in transformers"
    }
  ]
}

Claude zapisuje te krawędzie sam, przez serwer MCP vaultu, gdy czyta w poprzek waszych notatek i zauważa powiązanie. Pojawiają się potem jako linie Related: w pliku _index.md każdej bazy, żeby sieć była widoczna także dla was, nie tylko dla modelu.

Ścieżki zagęszczają się w strony. Gdy skupisko powiązanych notatek zrobi się dość gęste, Claude może je zsyntetyzować w stronę _topic-*.md, która cytuje swoje źródła. Następnym razem, gdy zapiszecie coś z tego skupiska, strona syntezy już czeka na aktualizację. To jest ten krok procentowania: vault robi się mądrzejszy, a nie tylko większy.

Sieroty są oznaczane. Przebieg lint raportuje duplikaty, osierocone notatki, zwietrzałą treść i skupiska dojrzałe do syntezy. Grafy się psują; coś musi to zauważyć.

Wszystko działa lokalnie. Indeks wyszukiwania to SQLite FTS5 z rankingiem BM25, graf to plik JSON, a nic z waszych notatek nie opuszcza maszyny.

Gdzie ostudziłbym zachwyt

Dwa uczciwe zastrzeżenia, bo to termin, który spopularyzował się w tydzień, a popularność wyprzedza treść.

Krawędzie Minibase niosą uzasadnienie, nie formalny typ. "reason": "Both explain the attention mechanism" to zdanie, nie supersedes. Znacznie lepiej niż nieopisany wikilink i znacznie mniej niż ontologia. Jeśli potrzebujecie ściśle typowanych relacji do wieloskokowego wnioskowania na skalę, potrzebujecie prawdziwej bazy grafowej — i warto być z sobą szczerym co do kosztu jej utrzymania.

Większość ludzi nie potrzebuje niczego z tego. Jeśli wasza wiedza to pięćdziesiąt notatek, wyszukiwanie wystarczy. Grafy zaczynają się opłacać, gdy macie dość materiału, by zacząć zapominać, co macie — i gdy wasze pytania są przyczynowe („dlaczego zrobiliśmy”) zamiast leksykalnych („gdzie to czytałem”).

Termin „graph engineering” pewnie nie przeżyje roku. Idea pod nim — że struktura między notatkami jest warta więcej niż liczba notatek — była prawdziwa na długo przed tym, nim dostała nazwę, i będzie po niej.

Zacznijcie od nudnej wersji

1. Zapisujcie to, co czytacie, jako Markdown zamiast dodawać do zakładek. Zakładka to wskaźnik na coś, co gnije; plik to coś, co macie.
2. Trzymajcie lokalnie, w jednym folderze, jeden plik na źródło.
3. Pozwólcie swojej AI przeczytać cały folder — przez MCP, nie kopiuj-wklej — i zadajcie pytania wymagające dwóch dokumentów naraz.
4. Zapisujcie znalezione połączenia. I zapytajcie ponownie za miesiąc.

To graph engineering dla tych, którzy nie wydają frameworków orkiestracji. To context engineering ze spisanymi połączeniami.

---

Minibase zamienia dowolną stronę w czysty Markdown jednym kliknięciem, prosto do lokalnego vaultu, który wasza AI może przeszukiwać i łączyć. Rozszerzenie jest darmowe z nieograniczoną liczbą zapisów; Minibase Plus (5,99 $/mies. lub 34,99 $/rok) dodaje szablony AI, historię i transkrypcję wideo. minibase.md.