Tę kartę wyciągasz wtedy, gdy projektujesz agenta, który ma odpowiadać na podstawie twoich danych, albo gdy istniejący agent odpowiada źle. Nie tłumaczy teorii. Prowadzi przez decyzję: najpierw pytania, potem dopasowanie metody, na końcu lista tego, co agent musi dostać, i sygnały, że wybór był błędny. Cztery metody na karcie to filtry w bazie danych, zapytania SQL, pełny kontekst i wyszukiwanie wektorowe po fragmentach.
1. Zanim wybierzesz metodę
Odpowiedz na piśmie, nie w głowie. Każda odpowiedź zawęża wybór.
- Wypisz dziesięć prawdziwych pytań, które agent będzie dostawał. Prawdziwych, czyli takich, jakie zadają ludzie, a nie takich, jakie łatwo przetestować.
- Przy każdym pytaniu zapisz, na co musiałby spojrzeć człowiek, żeby odpowiedzieć poprawnie: jeden wiersz, kilka wierszy, całą tabelę, cały dokument, jeden akapit z wielu dokumentów.
- Określ rodzaj danych: tabela z wierszami i kolumnami czy tekst ciągły (procedury, notatki, regulaminy, zapisy rozmów).
- Sprawdź, czy pytanie wymaga liczenia: sumy, średniej, rankingu, porównania okresów.
- Sprawdź, czy liczy się kolejność: chronologia, kroki procesu, przebieg spotkania.
- Oszacuj rozmiar: kilka dokumentów po kilka stron czy setki i tysiące.
- Zaznacz, jak często zmieniają się dane i ich struktura: nowe produkty, nowe kolumny, nowe wersje dokumentów.
Jeśli pytania z listy wskazują na różne odpowiedzi, to normalne. Jeden agent może potrzebować dwóch metod naraz.
2. Macierz: typ pytania → metoda
| Typ pytania | Przykład | Metoda | Reguła kciuka |
|---|---|---|---|
| Konkretne rekordy po znanych polach | „Ile sztuk X sprzedaliśmy w dniu Y?” | filtry | człowiek przefiltrowałby arkusz |
| Sumy, średnie, rankingi, trendy | „Które trzy produkty przyniosły najwięcej przychodu?” | SQL | człowiek zrobiłby tabelę przestawną albo formułę |
| Streszczenie, chronologia, kroki | „Ułóż przebieg tego spotkania po kolei” | pełny kontekst | człowiek przeczytałby cały dokument |
| Jedna informacja w dużym zbiorze tekstu | „Co regulamin mówi o zwrotach?” | wyszukiwanie wektorowe | człowiek znalazłby jedno pytanie na liście najczęstszych |
Dwie zasady, które rozstrzygają przypadki graniczne:
- Pytanie o całość (tabeli albo dokumentu) nigdy nie idzie do wyszukiwania po fragmentach. Agent zobaczy tylko kawałek i odpowie tak, jakby widział wszystko.
- Pytanie o liczby z tabeli nigdy nie idzie do modelu „na oko”. Liczy baza danych, model tylko układa zapytanie i odczytuje wynik.
3. Checklista dla każdej metody
Filtry
- W instrukcji agenta jest pełna lista dopuszczalnych wartości dla każdego pola, po którym filtruje, w dokładnie tej pisowni, jakiej używa baza (wielkie i małe litery też).
- W instrukcji jest format daty, w jakim baza przechowuje daty, z przykładem.
- Wiesz, kto aktualizuje instrukcję, gdy pojawi się nowy produkt, kategoria albo zmieni się format daty.
- Agent ma kalkulator albo inny sposób zsumowania wyników, jeśli pytanie wymaga dodawania.
- Jedno pytanie sprawdzasz ręcznie: ten sam filtr w arkuszu daje ten sam wynik co agent.
SQL
- Agent zna nazwę tabeli, nazwy kolumn, ich znaczenie i przykładowe wartości.
- Jeśli struktura bazy często się zmienia, agent ma narzędzie do sprawdzenia aktualnego schematu przed zapytaniem.
- Agent ma dostęp tylko do odczytu. Zapytanie ułożone przez model nie powinno móc niczego zmienić ani usunąć.
- Obliczenia (sumy, grupowanie, sortowanie) dzieją się w zapytaniu, a nie w modelu po pobraniu wierszy.
- Jeden wynik agenta porównujesz z tabelą przestawną zrobioną ręcznie na tych samych danych.
Pełny kontekst
- Sposób podania jest wybrany: narzędzie, które agent wywołuje sam, tekst wklejony w instrukcję systemową albo dokumenty wstawiane dynamicznie przy każdym pytaniu.
- Jeśli dokumentów jest kilka, a pytania zwykle dotyczą jednego, wybierasz narzędzie. Agent czyta wtedy tylko to, czego potrzebuje.
- Jeśli dokumenty się zmieniają, wstawiasz je dynamicznie, żeby zmiana źródła nie wymagała edycji agenta.
- Wiesz, ile tekstu przetwarza jedno pytanie i czy koszt przy spodziewanej liczbie pytań jest do przyjęcia.
- Wiesz, przy jakim rozmiarze zbioru przestanie się mieścić w oknie kontekstu modelu i co wtedy zrobisz.
Wyszukiwanie wektorowe
- Zbiór jest na tyle duży, że czytanie całości przy każdym pytaniu nie ma sensu.
- Odpowiedzi leżą w pojedynczych miejscach tekstu, a nie w całości dokumentu.
- Liczba fragmentów, które agent pobiera, jest ustawiona i sprawdzona na kilku wartościach. Więcej fragmentów to pełniejszy obraz i wyższy koszt.
- Jeśli agent musi wiedzieć, z którego dokumentu pochodzi fragment, fragmenty mają dopisane metadane: tytuł, datę, miejsce w dokumencie.
- Tabel nie wrzucasz do bazy wektorowej jako tekstu. Zostają w bazie danych i obsługują je filtry albo SQL.
4. Sygnały, że wybrano źle
- Agent pewnie podaje największą albo najmniejszą wartość, która nie zgadza się z tabelą. Liczy na fragmencie. Przejdź na SQL.
- Średnia lub suma od agenta różni się od tej z arkusza. Ten sam problem. Liczenie ma robić baza.
- Filtr zwraca zero wyników, choć dane istnieją. Agent wpisał wartość w innej pisowni albo datę w innym formacie. Uzupełnij instrukcję o listę dopuszczalnych wartości i format daty.
- Streszczenie pomija fragmenty, które na pewno były w dokumencie. Agent streszcza to, co znalazł, nie całość. Przejdź na pełny kontekst.
- Chronologia ma pomieszaną kolejność. Fragmenty nie niosą swojej pozycji w dokumencie. Pełny kontekst albo metadane z pozycją.
- Koszt pojedynczej odpowiedzi rośnie z każdym nowym dokumentem. Pełny kontekst przestał pasować do rozmiaru zbioru. Rozważ wyszukiwanie wektorowe dla pytań o pojedyncze informacje.
- Agent czyta wszystkie dokumenty, choć pytanie dotyczy jednego. Kontekst jest wklejony w instrukcję. Zamień go na narzędzie, które agent wywołuje wybiórczo.
- Po dodaniu nowego produktu agent przestaje go znajdować. Instrukcja ma starą listę wartości. To zadanie dla właściciela agenta, nie dla modelu.
5. Jedno zdanie na koniec
Metodę wybiera pytanie, a nie moda. Zacznij od listy prawdziwych pytań, przy każdym zapisz, na co spojrzałby człowiek, i daj agentowi dokładnie to, ani mniej, ani więcej.