Na początku projektu ktoś wkleja do czatu strategię, trzy umowy, eksport CRM i prezentację zeszłoroczną. „Żebyś miał kontekst”. Model ma go dużo. Nadal nie wie, co ma zrobić po południu i która decyzja jest aktualna.
Mały pakiet kontekstu nie jest wersją dla oszczędnych. To zestaw wystarczający do konkretnego zadania, z wyraźnymi granicami. Mniej materiału ułatwia odbiór i ogranicza dane, które bez potrzeby zmieniają właściciela.
Zacznij od rezultatu i decyzji
Zapisz jedno zdanie: co powstanie i kto tego użyje. „Przygotuj pięć pytań do rozmowy o migracji dla właściciela operacji” daje kierunek. „Przeanalizuj projekt” zaprasza do produkcji ogólnych spostrzeżeń.
Dodaj decyzję, która ma zostać podjęta po wyniku. Jeżeli nikt nie wie, po co jest raport, większy kontekst nie pomoże. Dopiero zmniejszy szansę na zauważenie braku celu pod stosem cytatów.
Przy zadaniu wieloetapowym rozdziel pakiety. Do diagnozy potrzebujesz źródeł, do propozycji decyzji wcześniejszych ustaleń, do publikacji zatwierdzonej wersji. Nie przenoś całego projektu przez każdy krok.
Siedem pól zamiast archiwum
Praktyczny pakiet zawiera: cel, odbiorcę, zakres, aktualne fakty, ograniczenia, format i sposób odbioru. Czasem dodajesz jeden przykład. Nie ma obowiązku wypełniania każdego pola długim tekstem.
Aktualne fakty powinny mieć datę i źródło. Ograniczenia mówią, czego nie wolno zrobić lub czego nie wiadomo. Format opisuje rezultat, a nie długość za wszelką cenę. Odbiór wskazuje błąd krytyczny i osobę decydującą.
Jeżeli pole nie zmienia wyniku, usuń je. Historia marki bywa potrzebna przy stronie głównej, ale nie przy sprawdzeniu sumy w tabeli. Pakiet ma być nudny i użyteczny, nie pełnić funkcji muzeum projektu.
Źródła wybieraj według pytania
Nie przesyłaj całej dokumentacji, jeżeli pytanie dotyczy jednej reguły. Wybierz właściwy fragment i zachowaj odwołanie. Jeżeli odpowiedź wymaga porównania, dodaj obie wersje z datami oraz statusem.
Oddziel materiał wiążący od inspiracji. Tekst konkurencji może posłużyć do analizy, ale nie jest źródłem twoich funkcji. Stary brief pokazuje historię, nie aktualne zasady. Model powinien wiedzieć, jaką rolę ma każdy dokument.
Przy sprzecznych źródłach nie ukrywaj konfliktu przez wybór jednego pliku. Zapisz pytanie do właściciela. Większy kontekst często tylko dokłada trzecią wersję i sprawia, że odpowiedź brzmi pewniej bez lepszego powodu.
Przykład powinien pokazywać regułę
Jeden dobry przykład wejścia i wyniku bywa skuteczniejszy niż dziesięć podobnych. Wybierz przypadek, który pokazuje nietypową decyzję: brak danych, ograniczenie, konflikt albo wymagany format. Nie tylko idealny scenariusz.
Opisz, dlaczego przykład jest poprawny. Bez tego model może skopiować przypadkową cechę, na przykład długość lub ton, zamiast zasady. Jeżeli przykład zawiera stare dane, oznacz je jako fikcyjne lub zaktualizuj.
Nie używaj prawdziwych danych klienta tylko dlatego, że są pod ręką. Do pokazania struktury wystarczy realistyczny, ale zmyślony przypadek bez powiązania z osobą. To nie jest miejsce na niespodziankę RODO.
Duży kontekst potrafi pogorszyć pracę
Więcej materiału zwiększa koszt odczytu i liczbę konkurencyjnych wskazówek. Model musi zdecydować, co jest ważne, a twoja instrukcja konkuruje z cytatami, starymi komentarzami i przypadkowymi nagłówkami.
Długi pakiet utrudnia także test. Kiedy wynik jest błędny, trudno wskazać wpływ konkretnego źródła. Przy małym zestawie możesz zmienić jeden element i porównać wynik. Przy eksporcie pół firmy diagnostyka przypomina wróżenie z logów.
Nie twierdzę, że duży kontekst jest zawsze zły. Analiza całej umowy lub repozytorium go wymaga. Wtedy zadanie powinno być zaprojektowane wokół pełnego materiału, z mapą i etapami odbioru, a nie udawać prostego pytania.
Kiedy potrzebujesz więcej informacji
Dodaj źródło, gdy odpowiedź zależy od faktu, którego model nie może znać. To może być aktualna cena, wewnętrzna decyzja, wersja interfejsu albo specyficzne ograniczenie klienta. Nie zastępuj go ogólnym opisem branży.
Rozszerz pakiet także wtedy, gdy przypadek testowy pokazuje konkretny brak. Jeżeli model proponuje eksport niedostępny w planie, dodaj aktualne ograniczenie. Nie dokładaj pięciu nowych zasad „na wszelki wypadek”.
Po każdej zmianie sprawdź, czy nowy materiał rzeczywiście poprawia wynik. Jeżeli nie, usuń go. Kontekst nie jest kolekcją, w której wygrywa największa liczba załączników.
Pakiet dla analizy przegranej oferty
Cel: znaleźć moment utraty warunków decyzji. Zakres: jedna oferta i jedna rozmowa. Źródła: komentarz klienta, wersja oferty, decyzje CRM. Ograniczenie: nie przypisywać powodu bez cytatu. Format: fakty, hipotezy, trzy pytania. Odbiór: opiekun sprawdza źródła.
Nie dodajesz historii wszystkich klientów, pełnego cennika ani opisu zespołu. Mogą być potrzebne przy późniejszym porównaniu, ale nie przy pierwszej karcie. Ten wybór pozwala zobaczyć konflikt zamiast go uśrednić.
Pełną metodę opisuje artykuł o analizie przegranej oferty z AI. Pakiet jest jej małym narzędziem roboczym, nie nową metodologią badawczą.
Pakiet dla opisu produktu
Dołącz kartę atrybutów, wariant, pytania klientów i zasady twierdzeń. Nie dodawaj opisów innych produktów jako źródła faktów. Jeden przykład stylu powinien być oznaczony jako styl, nie specyfikacja.
Odbiór sprawdza każdą właściwość z danymi. Jeżeli model dopisuje zasilacz, bo występował w przykładzie, przykład jest źle oddzielony od faktów. Usuń go lub opisz rolę wyraźniej.
Przy takim zadaniu przydatny jest przewodnik o opisach produktów z AI. Mniejszy kontekst ułatwia wykrycie wymyślonej cechy przed publikacją całego katalogu.
Wersjonuj pakiet jak część procesu
Zapisz datę, źródła i właściciela. Kiedy zmienia się reguła lub dokument, pakiet wymaga aktualizacji. Nie wystarczy nowa nazwa pliku „kontekst-ostateczny”. To tylko szybszy sposób na utratę historii.
Przy powtarzalnych zadaniach przechowuj szablon bez danych oraz konkretne wersje z identyfikatorami. Możesz porównać wynik przed i po zmianie źródła. Bez tego nie wiesz, czy poprawę dał nowy prompt, nowy model czy przypadek.
Po zakończeniu projektu zdecyduj o retencji. Nie każdy pakiet musi żyć wiecznie. Zachowaj decyzje i źródła właściwe dla projektu, usuń zbędne kopie robocze zgodnie z zasadami danych.
Odbiór przez osobę spoza zadania
Daj pakiet osobie, która zna proces, ale nie przygotowywała go. Zapytaj, jaki wynik ma powstać, które fakty są wiążące i kiedy należy się zatrzymać. Jeżeli odpowiada inaczej niż autor, kontekst jest niejasny.
Nie testuj tylko na modelu. Człowiek szybciej zauważy brak właściciela, sprzeczny termin lub zbędną sekcję. Model może grzecznie wykonać zadanie mimo tych braków i nagrodzić cię pewniejszym tonem.
Po pierwszym użyciu zapisz, jakich informacji zabrakło i które okazały się zbędne. Skróć pakiet przed kolejnym uruchomieniem. To jest redakcja procesu, nie optymalizacja liczby tokenów dla samej liczby.
Test odejmowania informacji
Przygotuj wersję bazową i usuń jeden dokument lub sekcję. Porównaj wynik według tej samej rubryki. Jeżeli nic się nie zmienia, masz kandydata do skrócenia. Jeżeli pogarsza się konkretny fakt, źródło zostaje, ale być może wystarczy jego fragment.
Nie oceniaj tylko długości odpowiedzi. Krótszy kontekst może sprawić, że model napisze mniej, ale zacznie zgadywać. Sprawdź fakty, ograniczenia i zgodność z celem. Oszczędność tokenów nie jest sukcesem, gdy rośnie czas poprawek.
Powtórz test z kilkoma przypadkami. Materiał zbędny przy typowym zadaniu może być potrzebny przy wyjątku. Wtedy zamiast wysyłania go zawsze przygotuj warunek dodania lub osobny pakiet. Kontekst może reagować na typ pracy, jeżeli reguła jest prosta i sprawdzona.
Pakiet wspólny i pakiet zadaniowy
Wspólna część zawiera stabilne informacje: terminologię, odbiorcę i podstawowe granice. Zadaniowa zawiera aktualne źródła oraz decyzję. Nie duplikuj wspólnych reguł w każdym dokumencie bez wersji, bo po zmianie powstaną różne kombinacje.
Nie upychaj jednak całej polityki do pakietu wspólnego. Wybierz tylko zasady rzeczywiście potrzebne w każdym zadaniu. Jeżeli dotyczy ona jednego kanału, należy do jego wariantu. Ten podział pozwala zachować mały kontekst bez gubienia standardu.
Przy odbiorze sprawdź obie części razem. Konflikt między regułą wspólną a zadaniową powinien być widoczny. Jeżeli wyjątek jest zamierzony, zapisz priorytet i właściciela. Model nie ma zgadywać, którą instrukcję autor uważa za ważniejszą.
Kiedy lepszy jest link niż załącznik
Jeżeli źródło jest duże, ale pytanie dotyczy jednego miejsca, podaj właściwy fragment z odwołaniem. Link bez treści nie wystarczy modelowi, który nie ma dostępu do narzędzia odczytu. Załącznik bez odwołania z kolei utrudnia sprawdzenie. Najlepszy jest fragment i dokładny adres źródła.
Przy pracy agenta z narzędziami ogranicz zakres odczytu. Możliwość otwarcia całego repozytorium nie oznacza, że każde zadanie powinno z niego korzystać. Zapisz dozwolone kolekcje i sposób wyboru. To ogranicza koszt oraz ryzyko pobrania niewłaściwej wersji.
Nie przekazuj linków wymagających szerokiego logowania tylko po to, by ułatwić sobie przygotowanie. Techniczne konto agenta powinno odpowiadać zakresowi zadania. Mały pakiet jest również decyzją o uprawnieniach.
Odbiór kosztu całego zadania
Porównaj czas przygotowania pakietu, wywołania, odbioru i poprawek. Bardzo mały kontekst przygotowywany ręcznie przez godzinę może kosztować więcej niż dobrze zautomatyzowany wybór źródeł. Nie optymalizuj wyłącznie rozmiaru promptu.
Zanotuj, ile razy trzeba otworzyć dodatkowy dokument. Jeżeli dzieje się to przy każdym zadaniu, pakiet nie jest wystarczający. Dodaj konkretny brak i sprawdź skutek. Jeżeli odpowiedź jest stabilna, a odbiór krótki, masz dobry punkt wyjścia do powtarzalnego procesu.
Nie porównuj pakietów wyłącznie na jednym przykładzie. Mały zestaw może działać dla standardowego przypadku i zawodzić przy wyjątku. Dodaj jedno zadanie z brakiem danych oraz jedno z konfliktem źródeł. Oczekiwany wynik powinien pokazywać ograniczenie zamiast pewnego zgadywania.
Jeżeli wyjątek wymaga dużego kontekstu, przygotuj osobną ścieżkę zamiast rozbudowywać każdy pakiet. To zachowuje prostotę typowej pracy i nie ukrywa kosztu trudnych przypadków. Użytkownik powinien wiedzieć, dlaczego dane zadanie przechodzi do szerszej analizy.
Zapisz próg przejścia w instrukcji. Może nim być konflikt wersji, poufny dokument albo potrzeba porównania kilku stron. Dzięki temu wybór pakietu nie zależy od nastroju ani od tego, kto akurat przygotowuje zadanie. Po teście sprawdź, czy próg nie kieruje zbyt wielu spraw do kosztownej ścieżki.
Aeneia Audit pomaga ograniczyć kontekst do źródeł i decyzji. Przy rejestrowaniu ustaleń sprawdza się rejestr decyzji projektowych Aeneia Signal.
Wyjątek nie musi trafiać do tego samego pakietu co każde zwykłe zadanie. Nazwij sytuację, która wymaga dodatkowego źródła, oraz osobę decydującą o rozszerzeniu kontekstu.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
