Rekurencyjne samodoskonalenie językowe: szlifowanie inteligencji kodu w ~280 językach

Liczby w tym wpisie odzwierciedlają system w momencie publikacji (maj 2026). Aktualne dane znajdziesz na naszej stronie zespołu.

Maguyva ekstrahuje symbole, referencje i graf zależności z kodu źródłowego w około 280 językach. Każdy język to niestandardowy handler tree-sitter — zapytania, heurystyki, przypadki brzegowe — i każdy handler może być subtelnie błędny na swój własny sposób. Wywołanie metody wyemitowane jako odczyt. Funkcja przypisana do niewłaściwego zakresu otaczającego. Relacja, której po prostu nie ma.

Tego nie da się ręcznie zweryfikować. Żaden zespół nie przeczyta wyników ekstrakcji w 280 gramatykach i nie wyłapie złych krawędzi. Więc ciekawym pytaniem nie jest „czy nasza ekstrakcja jest poprawna” — tylko „jak odkryć, że jest błędna, przy tej skali, bez człowieka w każdej pętli”. Naszą odpowiedzią jest rekurencyjne samodoskonalenie językowe: pętla jakości napędzana przez agentów językowych, LLM działający jako sędzia i jedna zasada, której wciąż się na nowo uczymy: zielone nie znaczy poprawne.

Zielone nie znaczy poprawne

Każdy język ma zestaw fixture’ów, a bramka wydania ocenia go w pięciu wymiarach — dokładność, integralność strukturalna, kompletność, jakość i wydajność. Język staje się ZIELONY tylko wtedy, gdy na swoich fixture’ach precyzja ≥ 0,95, recall ≥ 0,99, a F1 ≥ 0,97, przy co najmniej 20 oczekiwanych krawędziach dla wiarygodności statystycznej. Poniżej tego jest ŻÓŁTY lub CZERWONY i nie trafia do wydania.

Ta bramka jest konieczna, ale niewystarczająca. Fixture’y walidują względem fixture’ów które sami napisaliśmy. Kodują przypadki, o których już pomyśleliśmy. Handler może być bezbłędny na swoich fixture’ach i wciąż zniekształcać wzorzec, który pojawia się tylko w prawdziwym kodzie — idiom makra, metodę z ograniczeniem generycznym, cechę języka, dla której nikt nie napisał fixture’a. ZIELONY oznacza, że fixture’y przechodzą. Nie oznacza, że prawdziwe repozytorium ekstrahuje się czysto. Więc pętla musi zostawić fixture’y za sobą i spojrzeć na dziką naturę.

Pętla wewnętrzna: wyrywkowa kontrola, sędzia, naprawa, dowód

Główna pętla działa po jednym języku naraz:

        ┌──────────────────────────────────────────────────────────┐
        │                                                          │
        ▼                                                          │
  1. corpus run ── clone real-world repos, extract relationships   │
        │                                                          │
        ▼                                                          │
  2. spot-check 100 edges (seed 42, then seed 123 to cross-check)  │
        │                                                          │
        ▼                                                          │
  3. LLM judge classifies every sampled edge:                      │
        CORRECT · FALSE_POSITIVE · TYPE_ERROR ·                    │
        SCOPE_ERROR · METADATA_ERROR                               │
        │                                                          │
        ▼                                                          │
  4. fix ONE thing — handler .py, .scm query, or config           │
        │                                                          │
        ▼                                                          │
  5. re-validate — F1 + re-classify + manifest diff (no regressions)│
        │                                                          │
   better? ──no──► revert, try a different fix ────────────────────┤
        │ yes                                                       │
        ▼                                                           │
  6. promote the fix into fixtures (a permanent regression guard) ──┘

Kilka rzeczy sprawia, że to działa, a nie tylko się miota.

Sędzią jest agent, nie wywołanie API. Gdy mówimy „LLM jako sędzia”, mamy na myśli to, że sam agent językowy czyta każdą próbkowaną krawędź na tle prawdziwego źródła i klasyfikuje ją według stałej pięciokategoriowej rubryki: czy ta krawędź jest poprawna, jest fałszywie pozytywna, ma właściwą relację, ale zły typ, jest przypisana do niewłaściwego zakresu, czy niesie błędne metadane? Ta rubryka to cała gra — „23% wskaźnik błędów” nic nie znaczy, dopóki nie wiesz, czy to prawdziwe defekty, czy sędzia się myli w liczeniu.

Napraw jedną rzecz, a potem to udowodnij. Każda iteracja zmienia dokładnie jeden edytowalny zasób, a następnie ponownie uruchamia się względem stałego harnessu i zachowuje zmianę tylko wtedy, gdy F1 się poprawia, a ponowna klasyfikacja wygląda lepiej. Jeśli nie — wraca do poprzedniego stanu. Żadnych partii spekulatywnych edycji, żadnego „powinno być lepiej”. Zmiana zarabia na swoje miejsce albo znika. A gdy naprawa się utrzyma, jest promowana do zestawu fixture’ów — więc błąd, który naprawiła, nigdy po cichu nie wróci. Ten krok promocji jest tym, co czyni pętlę rekurencyjną, a nie tylko powtarzalną: każdy przebieg utwardza wyrocznię, względem której waliduje kolejny przebieg.

Lekcja, której wciąż się na nowo uczymy: metryki zawyżają

Oto pułapka, w którą wpadliśmy prosto. Drugorzędne metryki korpusu — jak często wyekstrahowany cel nie ma rozwiązywalnego symbolu, ile symboli wygląda na „osierocone” i tak dalej — masowo zawyżają problemy. To w większości artefakty paradygmatu, nie błędy.

Najczystszy przykład: llvm pokazał kiedyś 73% wskaźnik „źródła bez symbolu” i został naznaczony jako katastrofalny. Wgłębiliśmy się. Prawdziwa dokładność wynosiła 98,5%. „Brakujące symbole” były niemal wszystkie prawomocnymi referencjami zewnętrznymi — wywołaniami do biblioteki standardowej, do frameworków, do kodu żyjącego poza repozytorium. Metryka mierzyła właściwość języka, nie defekt handlera. Języki takie jak Zig, COBOL i Odin pokazują wskaźniki „osierocenia” na poziomie 65–70% i są całkowicie poprawne; COBOL nie miał ani jednego prawdziwego błędu.

Gdybyśmy pozwolili tym liczbom kierować pracą, spędzilibyśmy tygodnie na „naprawianiu” handlerów, które już były poprawne, ignorując języki z cichymi, prawdziwymi błędami. Wniosek jest brutalny: zagregowane metryki są w najlepszym razie zgrubnym sygnałem triażu. Prawdziwym sygnałem jakości jest wyrywkowa kontrola z klasyfikacją krawędzi — patrzenie na rzeczywiste krawędzie w rzeczywistych repozytoriach i osądzanie ich jedna po drugiej. Dane ponad intuicję, ale dopiero gdy wiesz, które dane mówią prawdę.

Pętla zewnętrzna: flota, nie maraton

Jeden język naraz zająłby wieczność przy 280 z nich, więc pętla wewnętrzna jest owinięta w zewnętrzną, która uruchamia wiele równolegle.

   pick a wave of near-GREEN / high-error languages
        │
        ▼
   fan out 10–15 agents, each ISOLATED in its own git worktree,
   each grinding ONE language, committing to its own branch
        │
        ▼
   orchestrator integrates serially: file-scoped apply, then
   `manifest diff` — any cross-language regression blocks the batch
        │
        ▼
   gated push (reviewed and confirmed) ──► rotate to the next wave

Każdy agent pracuje w jednorazowym worktree, więc nie mogą sobie wchodzić w drogę. Orkiestrator integruje ich poprawki jedna po drugiej, każdą za pełną bramką regresji na całym manifeście: zmiana, która pomaga własnemu językowi, ale po cichu psuje trzy inne, nie trafia do repozytorium. Integracja jest bramkowana i potwierdzona, zanim cokolwiek zostanie wypchnięte — bramka regresji decyduje, co jest bezpieczne, człowiek wciąż decyduje, co trafia do wydania. Następnie pula rotuje do kolejnego zestawu języków i całość uruchamia się od nowa.

Co wciąż jest niedoskonałe

Sędzia może się mylić, a błąd ma kierunek: agent działający z zbyt małym kontekstem zawyża zgłoszenia. W jednej partii osiem języków zostało oznaczonych jako mające 5–20% błędów; po inspekcji tylko jeden był prawdziwym błędem specyficznym dla języka — reszta to pomyłki sędziego wynikające z pominięcia własnej semantyki danego języka (jedna linia źródła legalnie emitująca kilka krawędzi, wiązania parametrów modelowane jako przypisania, języki z jedną referencją na identyfikator). Dlatego próbkujemy z dwoma ziarnami i krzyżowo weryfikujemy, i dlatego niezgodność między sędzią a fixture’ami jest traktowana jako najciekawszy sygnał, nie jako rozstrzygnięty werdykt — czasem to fixture jest tym, co jest błędne.

Jesteśmy też uczciwi co do celu. Celem jest zero prawdziwych błędów, kropka — ale „zero” to kierunek, do którego szlifujemy się język po języku, nie pole do odhaczenia. Zawsze jest kolejne repozytorium z kolejnym idiomem.

Zapracowane, nie zadeklarowane

Wszystko, co Maguyva robi dla agenta — znalezienie symbolu, prześledzenie zależności, odpowiedź na pytanie z cytowanym kodem — opiera się na tym, że leżąca u podstaw ekstrakcja jest poprawna. W 280 językach „poprawność” nie może być zadeklarowana; musi być nieustannie zapracowana na prawdziwym kodzie. Pętla jest sposobem, w jaki na nią pracujemy: autonomiczny cykl wyrywkowej kontroli i naprawy, który podchodzi z podejrzliwością do własnych metryk, dowodzi każdej zmiany i zamienia każdą naprawę w strażnika przed kolejną regresją. To nie jest efektowne. To praca, która pozwala nam powiedzieć „obsługujemy Twój język” i mieć to na myśli. Zielone jest łatwe. Poprawne jest zapracowane.