Context Window: co Copilot widzi przy generowaniu

Czego się nauczysz

• Co naprawdę oznacza context window w pracy z Copilotem
• Jak VS Code składa kontekst z plików, historii rozmowy i wyników narzędzi
• Dlaczego zły kontekst psuje odpowiedzi nawet wtedy, gdy model jest dobry

Najczęstszy błąd w pracy z Copilotem

Wielu osobom wydaje się, że jeśli Copilot odpowiada słabo, to problemem jest model.

Bardzo często problem leży gdzie indziej: model po prostu nie widzi tego, co powinien widzieć.

To jest sedno context window.

Model nie odpowiada na “rzeczywistość Twojego projektu”. Odpowiada tylko na to, co zostało mu w danym momencie pokazane.

Jeśli w promptcie nie ma właściwych plików, nie ma aktualnego fragmentu kodu, nie ma istotnych błędów albo wyników narzędzi, to nawet mocny model będzie zgadywał.

Context to nie tylko tekst, który wpisujesz

W dokumentacji VS Code kontekst jest opisany szeroko. To nie jest tylko Twoje pytanie z chatu.

Do pojedynczego requestu mogą wejść między innymi:

• systemowe instrukcje agenta
• Twoje custom instructions i inne customizations
• aktualna wiadomość użytkownika
• historia bieżącej sesji
• implicit context z edytora
• explicit references, na przykład #file albo #fetch
• wyniki narzędzi, na przykład odczytu plików, terminala albo searcha

To ważne, bo jakość odpowiedzi jest pochodną całego tego pakietu, a nie samego promptu wpisanego ręcznie.

Implicit context: to, co VS Code dorzuca samo

VS Code automatycznie dodaje część kontekstu na podstawie tego, co robisz tu i teraz.

Najczęściej będą to:

• aktywny plik
• zaznaczony fragment kodu
• nazwa pliku lub notebooka
• widoczne błędy
• część stanu repo albo historii sesji

To dlatego to samo pytanie zadane w pustym oknie chatu i zadane przy otwartym właściwym pliku może dać dwie zupełnie różne odpowiedzi.

W dokumentacji jest też ważne rozróżnienie między trybami. W Ask aktywny plik trafia do kontekstu automatycznie. W Agent decyzja może być podejmowana bardziej dynamicznie zależnie od zadania i narzędzi.

Explicit context: to, czym sterujesz świadomie

To jest poziom, na którym zaczynasz naprawdę używać Copilota dobrze.

Zamiast liczyć, że model “domyśli się projektu”, dopinasz kontekst samodzielnie:

• #file, gdy chcesz pokazać konkretny plik
• zaznaczenie, gdy pytanie dotyczy konkretnego fragmentu
• #fetch, gdy chcesz dodać aktualną dokumentację z internetu
• odwołania do workspace, gdy potrzebujesz szerszego kontekstu projektu

To zmienia jakość odpowiedzi bardziej niż kosmetyczne poprawianie promptu.

Jeżeli pytasz: “jak działa autoryzacja?” bez kontekstu, dostaniesz teorię. Jeżeli pytasz: “jak działa autoryzacja w tym projekcie?” i dopinasz właściwe pliki, dostajesz analizę Twojej implementacji.

Workspace indexing nie oznacza, że model widzi całe repo

To jest jedno z najczęstszych nieporozumień.

VS Code korzysta z indeksu workspace, żeby szybciej i trafniej znajdować istotne fragmenty kodu. To może być indeks zdalny albo lokalny, zależnie od środowiska i konfiguracji.

Ale indeks nie jest równoznaczny z tym, że cały projekt magicznie trafia do promptu.

Indeks pomaga znaleźć dobrą część kodu. Potem dopiero odpowiednie fragmenty mogą wejść do kontekstu konkretnego requestu.

To praktyczna różnica:

• indexing pomaga znaleźć
• context window decyduje, co model realnie zobaczy

Jeśli pomylisz te dwa poziomy, zaczniesz oczekiwać od Copilota wiedzy, której on po prostu nie ma w bieżącym żądaniu.

Historia rozmowy też zjada kontekst

Każda sesja ma własne okno kontekstu i własną historię.

Im dłużej ciągniesz jedną rozmowę przez kilka tematów, tym więcej starego kontekstu konkuruje z nowym zadaniem. W pewnym momencie zaczyna się szum:

• agent odwołuje się do starego celu
• model miesza pojęcia z poprzednich pytań
• odpowiedzi są poprawne lokalnie, ale już nietrafione dla nowego zadania

Dlatego dokumentacja słusznie rekomenduje nową sesję dla nowego problemu. To nie jest formalność. To jedna z najtańszych optymalizacji jakości.

Narzędzia rozszerzają kontekst w locie

W pracy agentowej kontekst nie jest statyczny.

Agent czyta pliki, odpala search, wykonuje komendy, pobiera wyniki i dokleja je do następnego kroku pętli. To oznacza, że output narzędzi staje się częścią kolejnego requestu do modelu.

To jest bardzo mocny mechanizm, ale ma koszt: każde dodatkowe wywołanie narzędzia generuje kolejne tokeny i może wypychać z kontekstu rzeczy ważniejsze.

Dlatego dobry workflow nie polega na “wrzuć wszystko”. Polega na dobraniu tylko tego kontekstu, który realnie pomaga rozwiązać problem.

Jak pracować z kontekstem praktycznie

Jeśli masz wyrobić sobie trzy nawyki, to niech będą te:

• zaczynaj nową sesję dla nowego zadania
• dopinaj konkretne pliki zamiast liczyć na domysły modelu
• ograniczaj kontekst do tego, co naprawdę potrzebne

To brzmi banalnie, ale właśnie to odróżnia pracę skuteczną od chatbotowego błądzenia.

Dobry prompt bez kontekstu daje przeciętny wynik.

Przeciętny prompt z dobrze dobranym kontekstem często daje wynik zaskakująco dobry.

Ćwiczenie praktyczne

Wybierz jedną funkcję albo moduł w swoim repo i wykonaj trzy próby:

1. Zadaj pytanie bez żadnego dodatkowego kontekstu.
2. Zadaj to samo pytanie z dołączonym konkretnym plikiem albo zaznaczeniem.
3. Zadaj to samo pytanie jeszcze raz, ale dodaj dokumentację przez #fetch albo szerszy kontekst projektu.

Porównaj:

• czy odpowiedź jest bardziej konkretna
• czy model odwołuje się do realnych nazw i plików
• czy mniej zgaduje i mniej tłumaczy ogólników

Po takim ćwiczeniu zwykle bardzo szybko widać, że jakość nie zależy tylko od modelu. Zależy od tego, co model widzi.

Kluczowe wnioski

• Context window to cały pakiet informacji widocznych dla modelu w danym requestcie.
• VS Code składa kontekst z historii, plików, zaznaczeń, customizations i wyników narzędzi.
• Workspace indexing pomaga znaleźć kod, ale nie oznacza automatycznie, że model widzi całe repo.
• Zbyt długa sesja obniża jakość, bo stary kontekst zaczyna konkurować z nowym zadaniem.
• Świadome sterowanie kontekstem daje większy zysk niż kosmetyczne dopieszczanie promptu.

Co dalej

Skoro wiesz już, że liczy się nie tylko model i nie tylko prompt, pora rozdzielić jeszcze jedną rzecz: co robi sam model, co robią narzędzia i gdzie zaczyna się prawdziwa praca agenta.