wszystkie wpisy 2026 Programowanie
Programowanie · Sztuczne sieci neuronowe · 2026-06-21 · 5 min

Jeden mały trik i nie tracisz kontekstu w lokalnych modelach LLM

Ostatnio grzebałem przy pluginie Refio i testowałem go na lokalnych modelach LLM. Teoretycznie wszystko działało: model miał dostać cały kontekst projektu – otwarte pliki z IDE, wyniki z RAG-a, zasady działania z systemowego prompta. No i nic z tego – nie działało.

Zamiast trafnych odpowiedzi – ogólniki, jakby model nic nie widział. A tokenów niby nie brakowało: limit ustawiony na 32k, a kontekst mieścił się spokojnie poniżej tej granicy.

Problem: model ślepy jak developer po kilku głębszych

Scenariusz wyglądał tak:

  1. Użytkownik wrzuca do kontekstu @open_files z IntelliJ – plugin sprawdza, które pliki są otwarte, i dokleja je do kontekstu. Wychodzi 8k+ tokenów.
  2. Zadaje pytanie dotyczące tych plików.
  3. Model odpowiada coś o otwieraniu plików. :P

Model ignorował kontekst. Albo może coś tam „widział” – ze swojej ogólnej wiedzy – ale na pewno nie odpowiadał na temat.

Rozdzielmy to – czyli pomysł, który NIE działa (na lokalnych modelach)

Na początku pomyślałem: może to kwestia struktury prompta?

Spróbowałem klasycznej separacji:

1. system: Policies („Jesteś asystentem AI…”, opisy narzędzi itd.)
2. system: Context (kod, RAG, otwarte pliki)
3. user:   pytanie

Brzmi rozsądnie. I co?

Nic.

Model dalej olewał kontekst. Albo czytał go jak instrukcję pralki po węgiersku – czyli wcale.

Ciekawostka: to samo podejście działało znakomicie na modelach chmurowych. OpenAI, Anthropic, Claude przez OpenRouter – radziły sobie z separacją policies i kontekstu bez problemu, ignorowanie kontekstu praktycznie nie występowało. Czyli problem nie leżał w samym prompcie, tylko w tym, jak lokalne modele radzą sobie z długim kontekstem. I tu zaczyna się ta ciekawsza część.

Co na to badania

Zacząłem kopać i okazało się, że to nie moja fanaberia, tylko zmierzone zjawisko. Trzy rzeczy, które warto znać:

Krzywa z badania „Lost in the Middle

Krzywa z badania „Lost in the Middle” – trafność zależy od tego, gdzie w kontekście siedzi informacja. Początek i koniec model trzyma, środek mu się rozmywa. Slajd z prelekcji „Milion tokenów później”.

1. Lost in the Middle (Liu et al. 2023) – modele najlepiej trzymają początek i koniec kontekstu, a środek im się rozmywa. To krzywa w kształcie litery U: kluczowy szczegół schowany w połowie długiego prompta bywa praktycznie niewidzialny. Model wcale tego nie „gubi” – po prostu skutecznie tego nie używa. Trochę jak ty z 30-stronicowym regulaminem: pierwsza linijka, ostatnia, „akceptuję”.

2. RULER (Hsieh et al. 2024, NVIDIA) – benchmark, który nie głaszcze modeli po głowie, tylko sprawdza, ile kontekstu model realnie ogarnia. Wynik: na 17 modelach tylko połowa trzyma jakość przy 32k – a to dla nich krótkie okno. Deklarowane 128k czy 200k to obietnica pojemności, nie gwarancja jakości na całej długości. Jak „do 1 Gbps” u dostawcy internetu.

3. Context Rot (Chroma 2025) – jakość spada z długością wejścia nawet na trywialnym zadaniu, nie tylko przy trudnym szukaniu igły w stogu. Liczy się nie tylko ile kontekstu wrzucisz, ale jak go ułożysz.

Wniosek dla mnie był prosty: skoro model najlepiej pamięta to, co jest blisko końca, to nie ma sensu zostawiać tam tylko pytania użytkownika.

Prosty trik: zmień kolejność

Zamiast:

1. system: Policies
2. system: Context
3. user:   pytanie

Używam:

1. system: Context   - nawet 8k-20k tokenów
2. system: Policies  - tuż przed pytaniem!
3. user:   pytanie

Tak, to świadomie łamie typową radę „policies na samej górze”. Na chmurze ta rada działa, bo te modele mają większe efektywne okno. Lokalnie – przeszkadza. Kontekst ląduje na początku (model przeskanuje go jak rozdział pierwszy), a zasady i format odpowiedzi siedzą tuż przed pytaniem – dokładnie tam, gdzie uwaga modelu jest najświeższa.

To jak nauka do egzaminu: nie pamiętasz całej książki, ale dwie ostatnie strony przeczytane przed wejściem – te zostają w głowie.

Dlaczego to działa

Lokalne modele mają ograniczone okno realnej uwagi. Mogą teoretycznie przyjąć 32k czy 128k tokenów, ale to nie znaczy, że wszystkie są tak samo ważne – patrz krzywa U z Lost in the Middle. Przekładając kolejność, ustawiasz najważniejsze rzeczy (zasady + pytanie) w strefie, którą model trzyma najlepiej.

TL;DR – dla zapracowanych

  1. Marketing kłamie – realna obsługa długiego kontekstu jest gorsza niż deklarowane 32k czy 128k (RULER).
  2. Kolejność ma znaczenie – model widzi cały kontekst, ale nie używa go równo; środek się rozmywa (Lost in the Middle).
  3. Recency bias – trzy linijki zmiany, a efekt ogromny.
  4. Chmura ≠ lokalnie – to, co działa świetnie na OpenAI czy Claude, offline potrafi być bezużyteczne.

PS. Benchmark obowiązkowy

Jeśli pracujesz z lokalnymi modelami – nie ufaj dokumentacji. Odpal RULER, puść benchmark, zobacz, gdzie twój model się wysypuje. Lepiej dowiedzieć się wcześniej, niż dwa dni frustrować się nad promptem, który niby jest dobry.


To wątek z mojej prelekcji „Milion tokenów później” (deBBug, JUG Bielsko-Biała). Tam rozwijam całość: dlaczego duże okno to nie pamięć, jak KV cache zjada kartę graficzną i jak Refio buduje kontekst warstwami. Slajdy i pomiary – czub.info i benchmark.refio.dev.


Następny wpis →

Niech Claude Code pisze, a Codex go sprawdza

2026-07-05 · 10 min czytania

0 komentarzy

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *