# Lokalna modyfikacja kodu za pomocą modeli generatywnych

Canonical HTML: https://aogavrilov.com/pl/research-notes/localized-code-modification-generative-models/

Document language: pl

NOTA BADAWCZA

Jak zapobiegać zbędnemu przepisywaniu całej funkcji, a zarazem pozostawić modelowi generatywnemu dość swobody, by wprowadził żądaną zmianę w kodzie.

Opublikowano 30 lipca 2026 [Alexey Gavrilov](https://aogavrilov.com/about/)

ODPOWIEDŹ BEZPOŚREDNIA

## Jak model generatywny może modyfikować kod bez przepisywania całej funkcji?

Przed generowaniem wyznacz obszary chronione i edytowalne, ponownie wykorzystaj lub ogranicz reprezentację chronioną, generuj wyłącznie proponowane zmiany i odrzucaj wyniki, które modyfikują chroniony kod albo nie przechodzą kontroli właściwych dla zadania. Lokalność i powodzenie zadania należy mierzyć łącznie.

## Dlaczego to rozróżnienie jest istotne

Metoda i deklarowana gwarancja muszą odnosić się do tej samej obserwowalnej granicy.

Lokalna modyfikacja kodu jest problemem edycji, a nie jedynie krótszym poleceniem generowania kodu. Dane wejściowe zawierają już artefakt, który warto zachować, dlatego metoda wymaga jawnej granicy zachowania między obszarem dopuszczonym do zmiany a właściwościami, które muszą pozostać stabilne.

Granicę zachowania może wyznaczać fragment kodu źródłowego, węzeł składniowy, sygnatura API, zachowanie testu, kontrakt zależności lub wyuczona pozycja w przestrzeni ukrytej. Wybory te nie są zamienne: każdy chroni inną obserwowalną właściwość i wymaga odpowiedniego etapu weryfikacji.

## Praktyczna procedura

1. Określ kontrakt zachowania Wskaż obszar podlegający edycji oraz dokładny tekst, strukturę, interfejs lub zachowanie, które muszą pozostać niezmienione.
2. Wybierz najwęższy użyteczny interfejs sterowania Ponownie wykorzystuj niezmienione fragmenty kodu źródłowego, stosuj uzupełnianie luk lub dekodowanie ukierunkowane na edycję, nakładaj ograniczenia formalne albo blokuj wybrane pozycje ukryte stosownie do wymaganej właściwości.
3. Generuj wyłącznie tam, gdzie zmiana jest dozwolona Pozostaw w obszarze podlegającym edycji dość swobody, aby rozwiązać zadanie; skopiowanie całości danych wejściowych jest lokalne, lecz nie prowadzi do postępu.
4. Weryfikuj łącznie lokalność i powodzenie Odrzuć rozwiązania kandydujące, które zmieniają chronione regiony, nie przechodzą analizy składniowej lub kompilacji, naruszają niezmienniki strukturalne bądź nie realizują żądanej zmiany.

## Dowody, których należy wymagać

Wiarygodność twierdzenia jest ograniczona wiarygodnością właściwości zmierzonej po wygenerowaniu lub zdekodowaniu.

- Różnica poza wyznaczonym obszarem lub inna bezpośrednia miara stabilności obszaru chronionego.
- Powodzenie zadania w obszarze edytowalnym.
- Stosownie do przypadku: parsowanie, kompilacja, testy, analizy statyczne lub niezmienniki właściwe dla zadania.
- Odsetek zmian w obszarze edytowalnym, aby kopiowania nie mylić z kontrolą.
- Unikatowość kandydatów i zmienność między powtórzeniami, aby lokalności nie mylić z zapadaniem się modów.

### Jakie wyniki przedstawia podlinkowane badanie

- Powiązany eksperyment kompresuje 64-tokenowe funkcje w języku Python do hierarchicznych pozycji dyskretnych i regeneruje wybrane pozycje w przestrzeni ukrytej przy częściowych ograniczeniach.
- Zablokowanie czterech kodów najwyższego poziomu zwiększyło odsetek poprawnego parsowania z 0.453 do 0.591, podczas gdy odsetek zmian w niezablokowanych pozycjach wyniósł 0.936, a udział unikatowych próbek warunkowych pozostał na poziomie 0.998.
- Pomiary te ujawniają ponad poziomem tokenów kompromis między stabilnością a swobodą; nie dowodzą dokładnego zachowania fragmentu kodu źródłowego, AST, semantyki ani działania programu.

[Przeczytaj omówienie publikacji](https://aogavrilov.com/pl/publications/inspectable-control/) [Przeszukaj pełny tekst artykułu](https://aogavrilov.com/publications/inspectable-control/full-text/)

## Granica zakresu

- Zablokowany kod ukryty nie staje się automatycznie węzłem AST, chronionym zakresem kodu źródłowego ani formalnym niezmiennikiem.
- Odsetek poprawnego parsowania potwierdza poprawność składniową, lecz nie poprawność funkcjonalną ani skuteczną naprawę.
- Przedstawione dowody pochodzą z krótkich, wstępnie przetworzonych funkcji w języku Python i nie pozwalają wnioskować o zachowaniu w skali repozytorium.

## Źródła podstawowe i pokrewne

Opis oryginalnych metod, pomiarów i wskazanych ograniczeń znajduje się w podlinkowanych artykułach.

1. [Inspectable Control for Structure-Preserving Software Regeneration](https://aogavrilov.com/pl/publications/inspectable-control/) Główna publikacja oraz eksperyment z ograniczonym hierarchicznym reprezentowaniem ukrytym.
2. [EfficientEdit: Accelerating Code Editing via Edit-Oriented Speculative Decoding](https://arxiv.org/abs/2506.02780) Dekodowanie ukierunkowane na edycję, które ponownie wykorzystuje niezmienione obszary kodu źródłowego.
3. [PAFT: Preservation Aware Fine-Tuning for Minimal-Edit Program Repair](https://arxiv.org/abs/2604.03113) Jawnie uwzględnia zachowanie i minimalny zakres zmian w uczeniu naprawy programów.

Utrzymywane przez Alexey Gavrilov . Na tej stronie podsumowano istniejące dowody; nie przedstawiono żadnych wyników eksperymentalnych wykraczających poza cytowane źródła.