NAJWAŻNIEJSZA ODPOWIEDŹ
Context engineering to projektowanie informacji dostępnych modelowi podczas zadania. Obejmuje wybór źródeł, historii, instrukcji i wyników narzędzi. Celem jest trafny, aktualny kontekst, który pomaga osiągnąć konkretny rezultat.
Co powinno znaleźć się w kontekście?
Oddziel stałe zasady aplikacji, bieżące polecenie użytkownika oraz materiały wykorzystywane do odpowiedzi. Te elementy pełnią różne role. Dokument klienta jest źródłem danych, a nie miejscem definiowania uprawnień aplikacji. Wynik poprzedniej rozmowy może być pomocny, ale nie powinien automatycznie stawać się obowiązującą regułą.
Dla każdego fragmentu zapytaj: jaką decyzję ma wspierać? Jeśli materiał nie wpływa na zadanie, być może nie trzeba go przekazywać. Przykładowo szkic odpowiedzi o terminie dostawy nie wymaga całej historii marketingowej klienta. Mniejszy, celowo dobrany zakres ułatwia również kontrolę nad danymi i diagnozowanie niepożądanej odpowiedzi.
Kontekst i materiały: Anthropic: Effective context engineering for AI agents
Historia rozmowy nie jest bazą prawdy
W długiej rozmowie użytkownik zmienia założenia, a model przedstawia hipotezy. Bez porządku stara propozycja może zostać potraktowana jako zatwierdzona decyzja. Przechowuj ważne fakty w strukturze opisującej ich status: potwierdzone, robocze, odrzucone. Zachowaj odnośnik do źródła, jeśli późniejsza kontrola jest istotna.
Przykład: klient najpierw prosi o wdrożenie w trzech oddziałach, a później ogranicza pilota do jednego. Podsumowanie powinno odzwierciedlać aktualny zakres i wskazywać zmianę. Samo skrócenie rozmowy nie wystarczy, jeśli usunie informację o decyzji. Sprawdzaj podsumowania na zadaniach, w których użytkownik koryguje wcześniejsze ustalenia.
Pobieraj informacje, kiedy są potrzebne
Zamiast wkładać całą bazę wiedzy do każdego zadania, aplikacja może wyszukać właściwe źródła lub uruchomić ograniczone narzędzie. Ważne jest jasne rozróżnienie między brakiem danych a błędem pobrania. Model nie powinien uzupełniać awarii systemu domysłem o statusie zamówienia.
Wyniki narzędzi powinny zawierać jednostki, daty i znaczenie pól. Wartość „120” bez waluty albo identyfikatora nie jest użytecznym kontekstem. Jednocześnie nie wysyłaj niepotrzebnych pól technicznych. Projektuj format na podstawie zadań i błędów, które rzeczywiście występują. Krótsza odpowiedź narzędzia może być bardziej informacyjna niż pełny zrzut rekordu.
Jak ocenić, czy zmiana pomaga?
Porównaj ten sam zestaw zadań przed i po zmianie sposobu doboru kontekstu. Oceniaj zgodność faktów, pominięte wymagania, czas i koszt. Dodaj długie rozmowy, podobne dokumenty oraz sprzeczne wersje. Upewnij się, że poprawa dla krótkiego pytania nie pogorszyła złożonego zadania.
Zapisuj, jakie źródła i wersje trafiły do konkretnej próby, przy rozsądnym ograniczeniu przechowywania danych. Dzięki temu diagnoza nie kończy się na stwierdzeniu, że model „czasem tak ma”. Najpierw ustalisz, czy dostał właściwą informację. Dopiero potem ocenisz, czy potrzebujesz innego modelu, sposobu wyszukiwania albo lepszej instrukcji.
OD CZEGO ZACZĄĆ
Zabierz to do swojego projektu.
- Oddziel instrukcje od materiałów źródłowych.
- Przechowuj status decyzji i aktualne założenia.
- Dodawaj daty, jednostki i pochodzenie danych.
- Porównuj jakość oraz koszt na tych samych zadaniach.
Wybierz jeden punkt, którego dziś brakuje w Twoim procesie. To dobry temat na pierwszą rozmowę z zespołem.
PYTANIA I ODPOWIEDZI
Pytania, które pojawiają się najczęściej.
Czy większe okno kontekstowe rozwiązuje problem?
Daje możliwość przekazania większej ilości informacji, ale nie gwarantuje wyboru właściwej. Nadal trzeba zarządzać sprzecznościami, aktualnością i tym, co jest istotne dla zadania.
Czy context engineering zastępuje prompt engineering?
Obejmuje szerszy zakres. Treść instrukcji pozostaje ważna, ale dochodzą do niej źródła, wyniki narzędzi, historia i sposób aktualizowania stanu pracy. W praktyce te elementy projektuje się razem.
Źródła i kontekst
- Anthropic: Effective context engineering for AI agents ↗
Anthropic omawia dobór i utrzymanie informacji w ograniczonym kontekście agenta. Przykład zmiany zakresu wdrożenia i proponowane kryteria odbioru są autorskie.
Opracowanie: Zespół ALGOV. Stan wiedzy: 8 września 2026. Przykłady opisują możliwe scenariusze i nie są wynikami projektów klientów. Jak powstają nasze poradniki.
