Modele AI potrafią dzisiaj naprawdę sporo. Umieją analizować kod, pisać dokumentację, szukać błędów, proponować refaktoryzację, tłumaczyć działanie systemu, a nawet pomagać w planowaniu architektury. Problem w tym, że nawet bardzo dobry model nie dostaje „magicznego wglądu” w cały projekt naraz.

I tu zaczynają się schody.

Bo z jednej strony mamy repozytoria liczące setki albo tysiące plików, dokumentację, historię rozmowy, wyniki poleceń, logi, konfiguracje, zależności i kontekst biznesowy. A z drugiej strony model, który może przetworzyć tylko określoną ilość tekstu w jednym podejściu. Nieważne, czy mówimy o małym modelu lokalnym, czy dużym modelu chmurowym – zawsze istnieje jakiś limit.

To nie jest bug. To jest po prostu cecha działania modeli.

Pytanie więc brzmi: jak sprawić, żeby AI w danym momencie miało przed oczami dokładnie to, co jest potrzebne, bez zalewania go toną nieistotnych danych?

Jak to rozwiązuje Refio:

Problem podstawowy: AI nie widzi całego świata naraz

Najprościej można to porównać do pracy bardzo dobrego konsultanta.

Wyobraź sobie człowieka, który jest szybki, bystry i dobrze rozumie złożone rzeczy, ale ma ograniczoną pamięć roboczą. Nie możesz położyć mu na biurku całego archiwum firmy, bo zwyczajnie się w tym utopi. Musisz mu podać właściwe dokumenty, we właściwym momencie, w odpowiedniej formie.

Z modelami AI jest dokładnie tak samo. Model nie „zna projektu” w taki sposób, jak zna go człowiek, który siedzi nad nim od pół roku. Model zna tylko to, co właśnie dostał w kontekście. Jeżeli nie dostał istotnego fragmentu kodu, to go nie uwzględni. Jeżeli dostał zbyt dużo śmieci, może zgubić to, co najważniejsze. Jeżeli rozmowa jest długa, a historia nie została dobrze zorganizowana, to zacznie tracić wątek.

Dlatego skuteczność AI w pracy nad większym projektem zależy nie tylko od samego modelu, ale od tego, jak zarządza się kontekstem.

I tu właśnie pojawia się Refio.

Refio nie wrzuca wszystkiego do modelu Pierwszy odruch wielu osób jest prosty: „to może po prostu prześlijmy do AI cały projekt”.

Brzmi logicznie, ale w praktyce jest to kiepski pomysł.

Po pierwsze, duże projekty bardzo szybko przekraczają dostępne okno kontekstu. Po drugie, nawet jeśli technicznie dałoby się tam zmieścić bardzo dużo treści, to model nie korzysta dobrze z chaotycznie wrzuconych danych. Po trzecie, koszt takiego podejścia robi się niepotrzebnie wysoki – zarówno czasowo, jak i obliczeniowo.

Znacznie lepiej działa podejście selektywne. Czyli zamiast ładować wszystko, podajemy tylko to, co w danej chwili ma największą wartość. Ale żeby to działało dobrze, trzeba mieć sensowny system organizacji wiedzy o projekcie.

Trzy warstwy kontekstu

Cały mechanizm można rozumieć jako pracę na trzech warstwach informacji.

1. Warstwa stała

To jest zbiór rzeczy, które model powinien znać praktycznie cały czas.

Mogą tam trafić:

• zasady projektu,
• opis struktury repozytorium,
• informacje o dostępnych narzędziach,
• sposób wykonywania operacji,
• reguły bezpieczeństwa,
• ważne instrukcje architektoniczne,
• ustalenia dotyczące stylu pracy.

To trochę jak instrukcja obsługi projektu zawieszona na ścianie. Nie zmienia się co chwilę, ale dobrze, żeby była zawsze pod ręką.

Jeżeli AI ma np. do dyspozycji narzędzia do odczytu plików, wyszukiwania semantycznego, wykonywania komend czy edycji kodu, to powinno rozumieć, czym te narzędzia są, kiedy ich używać i czego się po nich spodziewać. Bez tego zaczyna działać mniej przewidywalnie.

2. Warstwa robocza

To jest pamięć robocza budowana w trakcie całej sesji.

Model czyta pliki, zagląda do klas, analizuje zależności, uruchamia polecenia, sprawdza wyniki, porównuje fragmenty kodu. Gdyby próbować trzymać pełne wyniki wszystkich tych operacji, kontekst zapchałby się błyskawicznie.

Dlatego Refio nie przechowuje wszystkiego 1:1.

Zamiast pełnej treści buduje skondensowaną pamięć faktów. Czyli nie musi pamiętać całego pliku mającego 500 czy 1000 linii. Wystarczy, że zapisze rzeczy typu:

• plik AuthService odpowiada za logowanie użytkownika,
• korzysta z JwtProvider,
• walidacja tokenu odbywa się w middleware,
• zależność do konfiguracji jest pobierana z SecurityConfig,
• w pliku znaleziono metodę odświeżania tokenu,
• występuje powiązanie z modułem uprawnień.

To działa trochę jak notatki robione przez człowieka podczas analizy dokumentacji. Nie przepisujesz wszystkiego słowo w słowo, tylko zapisujesz to, co będzie istotne później.

I to jest bardzo ważne, bo taka pamięć robocza pozwala AI budować rozeznanie w projekcie bez konieczności ciągłego wracania do tych samych źródeł.

3. Warstwa chwilowa

To warstwa składana na nowo przy każdej kolejnej odpowiedzi.

Tutaj trafia:

• bieżące pytanie użytkownika,
• ostatnie wiadomości z rozmowy,
• najnowsze wyniki operacji,
• dobrane fragmenty kodu z wyszukiwania semantycznego,
• ewentualne dodatkowe dane potrzebne do wykonania konkretnego kroku.

To właśnie ta warstwa odpowiada za to, żeby model był „tu i teraz”. Czyli żeby zamiast rozmyślać nad wszystkim naraz, skupił się na aktualnym zadaniu.

W praktyce to trochę jak dokumenty rozłożone na biurku do bieżącej sprawy. Reszta wiedzy istnieje w tle, ale nie musi być w danym momencie cały czas na wierzchu.

Budżet tokenów, czyli pamięć też ma swoją księgowość

Każdy model ma ograniczone okno kontekstu. To znaczy: istnieje limit tekstu, który można mu przekazać na wejściu tak, aby był w stanie go jeszcze efektywnie przetworzyć. Ten limit wyraża się zwykle w tokenach. Upraszczając: tokeny to mniejsze jednostki tekstu, z których model „składa” rozumienie wejścia. Jeżeli mamy ograniczony budżet, to trzeba nim zarządzać rozsądnie. I tu właśnie Refio nie traktuje wszystkich danych jednakowo. Zamiast tego dzieli kontekst na sekcje o różnych priorytetach.

Sekcje krytyczne

To rzeczy, które muszą być obecne praktycznie zawsze. Na przykład:

• instrukcje systemowe,
• zasady działania narzędzi,
• kluczowe reguły bezpieczeństwa,
• podstawowe informacje o środowisku pracy.

Tych elementów nie warto usuwać, bo bez nich model traci fundament działania.

Sekcje wysokiego priorytetu

Tu trafiają rzeczy bardzo ważne dla bieżącej pracy:

• pamięć robocza projektu,
• najważniejsze ustalenia,
• kontekst biznesowy,
• instrukcje projektowe,
• dane dostarczone przez użytkownika.

To są rzeczy, które mogą się lekko zmieniać, ale nadal mają dużą wartość poznawczą.

Sekcje normalne i niskie

Tutaj lądują elementy, które są przydatne, ale nie zawsze muszą być w pełnej postaci:

• starsze operacje,
• wyniki wyszukiwania,
• dłuższa historia rozmowy,
• materiały pomocnicze,
• referencje.

Kiedy kończy się miejsce, właśnie te sekcje są skracane jako pierwsze.

To jest w sumie dość zdroworozsądkowe podejście. Jeżeli na biurku zaczyna brakować miejsca, nie wyrzucasz głównych założeń projektu i aktualnego zadania. Najpierw odkładasz mniej ważne notatki i starsze papiery.

Kompresja nie polega na ślepym obcinaniu

Bardzo ważna rzecz: sensowne zarządzanie kontekstem nie może polegać na brutalnym cięciu tekstu co N znaków. To zwykle kończy się utratą sensu. Refio stosuje bardziej warstwowe podejście do kompresji wyników operacji. Można to uprościć do trzech poziomów.

Poziom 1: pełny wynik

Jeżeli operacja została wykonana właśnie teraz i model ma na jej podstawie podjąć następną decyzję, to dobrze jest zachować pełne dane. Przykład: AI odczytało plik z konfiguracją bezpieczeństwa i zaraz ma odpowiedzieć, czy da się zmienić sposób autoryzacji. W takim przypadku pełny wynik jest potrzebny.

Poziom 2: wynik częściowo skrócony

Starsze operacje nie zawsze wymagają pełnej treści. Można zachować np. początek i koniec wyniku, a środek pominąć z odpowiednią adnotacją. To często daje zaskakująco dobre rezultaty, bo wiele ważnych informacji znajduje się właśnie na początku lub końcu wyników. Taki zabieg nadal pozwala utrzymać orientację, ale kosztuje dużo mniej miejsca.

Poziom 3: streszczenie semantyczne

Najstarsze operacje najlepiej zamienić w zwarte podsumowanie. Tylko nie takie ogólne w stylu „sprawdzono plik”, bo to nic nie wnosi. Dobre streszczenie powinno zależeć od typu narzędzia.

Przykładowo:

• dla odczytu pliku: lista klas, funkcji, odpowiedzialności i zależności,
• dla wyszukiwania: liczba trafień, lokalizacje, najważniejsze dopasowania,
• dla edycji kodu: co zmieniono, w jakim pliku i w jakim celu,
• dla polecenia systemowego: najważniejsze skutki wykonania.

Czyli nie chodzi o skracanie „byle jak”, tylko o zachowanie informacji, które rzeczywiście pomagają kontynuować pracę.

Co z historią rozmowy?

To jest kolejny problem, który szybko wychodzi przy dłuższej pracy z AI. Na początku rozmowy wszystko jest proste. Jest kilka wiadomości, kilka odpowiedzi, jakiś jeden temat. Ale po kilkudziesięciu minutach albo po dłuższej sesji technicznej historia zaczyna rosnąć bardzo szybko. Jeżeli zachowamy wszystko w pełnej formie, to kontekst zacznie się dusić. Jeżeli usuniemy wszystko zbyt agresywnie, model zgubi wątek i zacznie wracać do starych pytań albo proponować rzeczy już wcześniej odrzucone. Dlatego tutaj też przydaje się mechanizm warstwowy.

Gdy historia rozmowy przekracza określony próg swojego budżetu, Refio może:

• zostawić ostatnie wiadomości w pełnej formie,
• starszą część zamienić w jedno zwarte podsumowanie.

I takie podsumowanie nie powinno brzmieć jak szkolne streszczenie. Ono powinno zawierać rzeczy naprawdę użyteczne:

• co zostało już ustalone,
• jakie pliki sprawdzono,
• jakie decyzje podjęto,
• co zostało zmienione,
• jakie są kolejne kroki,
• jakie problemy pozostają otwarte.

W praktyce daje to bardzo dobry efekt. Model nadal rozumie kierunek rozmowy, ale nie musi czytać całej historii od początku.

Skalowanie do różnych modeli

Bardzo sensowne w tym podejściu jest też to, że działa ono dla różnych klas modeli.

Mały model lokalny ma znacznie ciaśniejszy budżet. Duży model chmurowy może przyjąć dużo więcej danych. Ale problem organizacji kontekstu nie znika ani w jednym, ani w drugim przypadku.

Różni się tylko skala.

Mały model dostanie:

• krótsze instrukcje,
• bardziej zwarte streszczenia,
• mniej wyników wyszukiwania,
• mocniej skondensowaną pamięć roboczą.

Duży model może dostać:

• więcej szczegółów,
• szerszy zestaw trafień,
• dłuższą historię w pełnej formie,
• bogatszy kontekst projektowy.

Architektura pozostaje jednak ta sama.