DBAdmin/inbox/Poprawka Andreja Karpathy'ego dla pamięci LLM działa także na kod.md at master

dexter/DBAdmin

Fork 0

Files

T

Paweł Domański f07f48171b Jul 31, 2026, 10:25 AM

2026-07-31 08:25:06 +00:00

14 KiB

Raw Permalink Blame History

title, source, author, published, created, description, tags

title

source

author

published

created

description

Dwa narzędzia open-source, które zamieniają jego pomysł w graf kodu dla własnej bazy kodu.

Zdjęcie: Kevin Butz na Unsplash

Przeczytaj to za darmo

Prosi swojego agenta programistycznego, by znalazł każdego dzwoniącego daną funkcję, zanim ją dotkniesz. Gregreje repozytorium, otwiera cztery lub pięć plików, przegląda importy, których nie potrzebuje, i daje ci odpowiedź.

Zapytaj jutro ponownie, ten sam repozytorium, to samo pytanie. Zaczyna od zera i robi cały crawl od nowa.

Nic, czego się wczoraj nauczył, nie przeniosło się do niej.

Pisałem o tej dokładnej awarii w kwietniu, tylko nie dla kodu. " RAG, LLM Wiki czy Gbrain? "Jak twój agent pamięta zmienia wszystko " porównał trzy sposoby, w jakie agent może pamiętać: za każdym razem szukać na nowo, skompilować wiki raz i ciągle je zapytać, albo iść dalej i działać na podstawie tego, co wie.

Tweet Andreja Karpathy'ego był kotwicą tego tekstu. Jego argument: przestańcie traktować LLM jako wyszukiwarki, które czytają te same dokumenty na każde pytanie. Skompiluj wiedzę w strukturę raz. Zamiast tego zapytaj strukturę.

Ten tekst dotyczył badań i robienia notatek.

Kod ma ten sam problem.

Więc poszukałem narzędzi, które traktują bazę kodu tak, jak Karpathy traktuje folder badawczy: przeanalizują ją raz, zbudują strukturę, pozwólą agentowi zapytać strukturę zamiast ponownie czytać pliki.

Istnieje kilka takich przypadków. Graphify i codebase-memory-mcp robią wersje tego do szerszych wejść, plików Terraform, notatek ze spotkań, całych zestawów dokumentacji, nie tylko kodu.

Dwa z nich pozostają dedykowane kodowi:

colbymchenry/codegraph to wersja ogólnego przeznaczenia, z ponad 60 000 gwiazdek na GitHub.
tirth8205/code-review-graph zawęża tę samą ideę, by pull request review, z ponad 25 000 gwiazdek dla siebie.

Chciałem się dowiedzieć, czy którykolwiek z tych rozwiązań faktycznie zmienia sposób pracy agenta na co dzień i jak byś go wykorzystał.

Diagram autorstwa autora: RAG, LLM Wiki i GBrain, z dodanym Code Wiki jako odpowiednikiem kodu

Grep traktuje twój kod jak zwykły tekst. Może wskazać każdą linijkę, w której pojawia się imię. Nie potrafi powiedzieć, co faktycznie zależy od tego imienia, ani co przerywa dwa kroki od linii, na którą patrzysz.

Wykres to naprawia, zachowując relacje, a nie tylko słowa. Przeanalizuj kod raz i zamiast wyrzucać właśnie znalezioną strukturę, zapisz ją: ta funkcja wywołuje tamto, ten plik importuje tamten, ta klasa dziedziczy tamtę.

To daje ci dwie rzeczy, które warto nazwać osobno.

Najważniejszą z nich jest niezawodność: agent przestaje brakować zależności bez tych samych słów, ponieważ istnieje krawędź grafu, niezależnie od tego, czy dwa pliki używają tego samego słownictwa.
Koszt to druga, mniejsza rzecz, którą warto znać. Zapytanie wstępnie obliczonego grafu pod kątem "kto to wywołuje" kosztuje kilka wierszy, a nie pięć plików surowego tekstu do przeczytania i rozważania.

Oba narzędzia budują wykres w ten sam sposób.

Parsuj za pomocą tree-sittera, prawdziwego parsera, który rozumie granice funkcji, zamiast zgadywać na podstawie wcięcia czy słów kluczowych.
Zapisz wynik w SQLite: symbole jako węzły, wywołania i importy oraz dziedziczenie jako krawędzie.
Siedź za serwerem MCP, żeby twój agent bezpośrednio zapytywał graf, zamiast gregre i czytać pliki od zera w każdej sesji.

Jeszcze jedna rzecz, którą warto wiedzieć przed instalacją czegokolwiek: oba narzędzia są najpierw lokalne. Brak wywołań sieciowych, brak kluczy API, tylko plik SQLite na twoim komputerze. Żadne dane nie opuszczają laptopa, a koszt za zapytanie nie ma więcej niż jednorazowe składanie.

Diagram autora: Współdzielony potok: tree-sitter parsuje raz, graf znajduje się w SQLite, MCP udostępnia go agentowi

Czym jest Codegraph

Codegraph to narzędzie na pozostałe dziewięćdziesiąt procent czasu spędzonego z agentem kodującym: zrozumienie bazy kodu.

Instalacja to jedno polecenie:. Następnie przelewa go do swojego agenta i buduje indeks.curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh codegraph install codegraph init

Uruchomiłem to na OmniRoute, open-source projekcie ponad 8 000 plików. Indeks kończył się w 34 sekundy i zajmował 325 megabajtów na dysku, nieco więcej niż 233-megabajtowy repozytorium źródłowe, z którego został zbudowany.

Gdy już zostanie zbudowany, agent otrzymuje nowe polecenia zamiast polegać na grepcie i odczytach plików. znajduje, kto coś dzwoni. Ślady się psują, jeśli to zmienisz. Oba zwracają krótką, bezpośrednią odpowiedź zamiast stosu akt do przeczytania.codegraph callers codegraph impact

Oto jak to wyglądało na prawdziwej imprezie. OmniRoute ma kontrolę routingu o nazwie classifyRoute, ukrytą w kodzie uwierzytelniania. Zapytałem codegraph, co by się zmieniło, gdybym to zmienił.

Odpowiedź pojawiła się jednym wywołaniem, 344 bajty: sama classifyRoute, jej jeden bezpośredni wywołujący oraz plik o nazwie proxy.ts. To ostatnie jest ciekawe. proxy.ts nie wywołuje bezpośrednio classifyRoute, lecz funkcję o nazwie runAuthzPipeline, która wywołuje classifyRoute.

Grep, szukając dosłownego tekstu "classifyRoute", znalazł 17 dopasowań w trzech plikach. Nigdy nie wypłynęło proxy.ts. Połączenie jest oddalone o dwa kroki, a grep pasuje tylko do słów.

Codegraph znalazł to, ponieważ wykres śledzi, co faktycznie co nazywa.Wspólne słownictwo nie ma z tym nic do rzeczy.

Odpowiedź Codegraph była o 98,7% mniejsza niż sam grając i czytając trzy pasujące pliki.

To jest codzienna wartość. Zanim dotkniesz funkcji, zapytaj, co od niej zależy, i uzyskaj odpowiedź uwzględniającą pośrednictwo, a nie tylko taką, która wyróżnia to, co dzieje się przy dzieleniu twojego hasła wyszukiwania.

Czym jest Code Review Graph?

code-review-graph istnieje dla węższego momentu: momentu, w którym dokonałeś zmiany i musisz wiedzieć, co ona dotyka, zanim otworzysz pull request.

Instalacja to najpierw w środowisku wirtualnym, jeśli twój system nie ma jeszcze skonfigurowanego PIP. Wtedy i.pip install code-review-graph code-review-graph install code-review-graph build

Zbudowanie tego samego grafu OmniRoute zajęło 2 minuty i 25 sekund, czyli około cztery razy dłużej niż codegraph. Lokalny sklep zajmował 1,4 gigabajta, ponad czterokrotnie większy niż codegraph.

To wymiana za dodatkową głębię, którą uchwyca.

To jednak uchwyca więcej. Zapytanie code-review-graph dla wywołujących classifyRoute zwracało ten sam proxy.ts zależności, jaki znajdował codegraph, plus coś, co odpowiedź codegraph złożyła w jeden ogólny wpis pliku: cztery indywidualne przypadki testowe, każdy nazwany i numerowany linijkami, które konkretnie wykonują classifyRoute.

Taka szczegółowość to właśnie to, czego recenzent naprawdę chce. Zanim zatwierdzisz zmianę, chcesz wiedzieć nie tylko, czy coś w pliku testowym ją obejmuje, ale także które testy są właściwe i czy są właściwe.

code-review-graph przypisuje również ocenę ryzyka do zmienionego kodu i może na niej wyciągnąć pull request. To zestaw czynników ważonych, ile rzeczy nazywa ten kod, czy jest on objęty testami, czy nazwa pasuje do listy słów kluczowych brzmiących bezpiecznie, sumowanych i ograniczonych. To nie jest model wytrenowany na rzeczywistych rezultatach. Potraktuj to jako zachętę do bliższego przyjrzenia się, a nie jako werdykt.

Diagram autora: ocena ryzyka code-review-graph: sześć czynników ważonych zsumowanych i ograniczonych

Poproś o coś szerszego, na przykład pełny promień wybuchu całego pliku zamiast jednej funkcji, a wynik szybko rośnie. Mój test wyniósł 596 kilobajtów, a obcięte do 500 z 5 264 dotkniętych węzłów. Szerokie zapytania zachowaj na momenty, gdy naprawdę potrzebujesz pełnego obrazu, a wąskie na codzienne przeglądy.

Schemat autora: Wąskie zapytanie pozostaje małe; balonki o szerokim promieniu wybuchu do 596KB

codegraph vs code-review-graph

Obok siebie dwa narzędzia dzielą się dokładnie wzdłuż oczekiwanych schematów: jedno stworzone do szybkości i codziennego użytkowania, drugie pod kątem głębi podczas recenzji.

Diagram autora: ocena ryzyka code-review-graph: sześć czynników ważonych zsumowanych i ograniczonych

Używaj Codegraph do pisania i rozumienia kodu, a jeśli potrzebujesz głębszej recenzji kodu, dodaj code-review-graph.

Diagram autora: Używaj codegraphu podczas pisania, przegląd kodu przed scalaniem

Pamiętaj, że żadne z tych narzędzi nie jest gotowym oprogramowaniem i oba mają nierówne krawędzie, które warto znać, zanim na nich polegasz.

Auto-sync, funkcja, która ma utrzymać wykres w aktualności bez zastanowienia się, powoduje problemy z GitHubem na obu repozytoriach opisujące luki. Plik zapisany w trakcie edycji może zostać zindeksowany względem przestarzałego hasha i pozostać nieprawidłowy aż do pełnej rekonstrukcji. Przemianowane pliki mogą pozostawić nieaktualny węzeł pod starą nazwą i nieindeksowany pod nową. Żadne z narzędzi nie ostrzega cię, gdy to się dzieje, więc odbuduj to, zanim zaufasz odpowiedzi, która ma znaczenie.

Zakres języków też nie jest jednolity. Niezależny akademicki benchmark na powiązanym narzędziu, Codebase-Memory, wykazał, że parsowanie oparte na drzewie gwałtownie spada na makro-wysoko obciążonym C, ponieważ parser w ogóle nie reprezentuje makr preprocesora. Kod opierający się na mocnych makr w C napotka tu prawdziwe luki.

Precyzja Code-Review-Graph w analizie wpływu jest niższa niż sugerują liczby nagłówkowe. Według własnych opublikowanych danych, blisko cztery na dziesięć oznaczonych "dotkniętych" plików okazuje się nie. Z tego samego powodu, dla którego zapytania recenzyjne są wąskie, co w ostatniej części.

To wszystko nie czyni żadnego z tych narzędzi bezużytecznymi. Oznacza traktowanie wykresu jako mocnego pierwszego podejścia, a nie jako źródła prawdy, którego nigdy nie trzeba sprawdzać.

Diagram autora: Trzy szczere ograniczenia, które warto sprawdzić, zanim zaufasz któremukolwiek z narzędzi

Ostateczne przemyślenia

Karpathy nigdy nie chodził o wiki. Chodziło o to, żeby remake LLM nie działał, bo już działał.

codegraph i code-review-graph stosują to do kodu: parsują raz, zachowują strukturę, zapytują ją zamiast czytać ponownie.

Zacznij od codegraph. To szybsza konfiguracja i obejmuje to, co robisz najbardziej: rozumienie kodu podczas jego pisania. Dodaj code-review-graph, gdy faktycznie będziesz mieć workflow pull request, który wymaga sprawdzenia promienia wybuchu przed merge.

Następnie uruchom jedno zapytanie na własnym kodzie. Wybierz funkcję, którą zamierzasz zmienić i uruchom. Sprawdź, czy odpowiedź nie wyświetli czegoś, co Grep mógłby przeoczyć. To jedyny punkt odniesienia, który się tu liczy, i możesz go sam przeprowadzić w ciągu najbliższych pięciu minut.codegraph impact <function-name>

Jak sprawić, by Claude w kilka minut zaczął prowadzić badania jak doktorat

Jak STORM Stanforda zamienia temat w cytowany, wieloperspektywiczny brief i jak go przedstawić w Claude.

medium.com

Zanim pójdziesz! 🦸🏻♀️

Jeśli podobała ci się moja historia i chcesz mnie wesprzeć:

Rzuć trochę Medium miłości 💕 (brawa, komentarze i podkreślenia), wasze wsparcie znaczy dla mnie wszystko. 👏
Śledź mnie na Medium i subskrybuj, aby otrzymywać mój najnowszy artykuł🫶

O nim - Yanli Liu - Medium

Przeczytaj teksty Yanli Liu na Medium. Dzienny specjalista finansowy z Luksemburga, doświadczony programista i pasjonat...