Ugruntowany agent AI na stronie firmy doradczej

Agent czatowy na stronie firmowej ma jedno zadanie, które naprawdę się liczy: nigdy nie zaszkodzić reputacji firmy. Bycie pomocnym to łatwa część — pomocny jest każdy model z promptem systemowym. Prawdziwy problem inżynierski polega na tym, żeby trzymać się prawdy, gdy anonimowi odwiedzający celowo próbują agenta z niej sprowadzić.

Agenta na stronie naszej firmy (mgcuk.tech) zbudowałem wokół trzech decyzji, które warto opisać.

Wiedza z plików

Agent wie tylko to, co znajduje się w wersjonowanym katalogu content/knowledge/: pliki markdown opisujące usługi, proces, historie klientów, najczęstsze pytania i dane kontaktowe. Te same pliki mógłby przeczytać człowiek. Bez dostrajania modelu i bez bazy wektorowej — przy korpusie tej wielkości nie są potrzebne. Cała baza wiedzy jest kompilowana do promptu systemowego podczas builda.

Najciekawszy jest scenariusz awarii. Moduł wczytujący wiedzę pilnuje limitu 12 000 tokenów; kiedy korpus go przekroczy, build kończy się błędem — głośno, w CI, zanim cokolwiek trafi na produkcję. Wygodniejsza alternatywa, czyli ciche przycinanie wiedzy, dałaby agenta, który z pełnym przekonaniem nie zna połowy firmy, a dowiedzielibyśmy się o tym od zdezorientowanego klienta. Gdy w grę wchodzi czyjaś reputacja, lepiej, żeby system zatrzymał się głośno, niż żeby psuł się po cichu.

Limity, które w razie wątpliwości się zaostrzają

Publiczny adres, anonimowi użytkownicy, opłata za każdy token — koszty łatwo wymykają się spod kontroli. Upstash Redis pilnuje limitu 20 zapytań na 10 minut dla każdego odwiedzającego. Najbardziej zależy mi na jednym szczególe: gdy identyfikacja użytkownika zawiedzie, mechanizm nie przepuszcza zapytania bez ograniczeń. Kieruje je do wspólnej puli „nieznani", która ma limit ostrzejszy niż zwykła ścieżka. W razie awarii system daje mniej dostępu, nigdy więcej. Ta sama zasada ogranicza długość odpowiedzi do 600 tokenów, a historię rozmowy do 12 wiadomości: koszty i pole ataku pozostają ograniczone.

Testować odmowy, nie tylko odpowiedzi

Testy agenta obejmują cztery obszary: wczytywanie wiedzy (łącznie z przekroczeniem limitu tokenów), trasę odpowiedzi strumieniowych, limitowanie zapytań i zbieranie zgłoszeń kontaktowych. Najbardziej cenię testy sprawdzające to, czego agent nie zrobi: nie odpowie na pytanie spoza tematu, nie przekroczy limitu, nie poprowadzi rozmowy ponad ustalone granice. Scenariusz idealny potrafi pokazać każdy; o wartości publicznego agenta decydują ścieżki odmowy.

Co doradziłbym każdemu, kto buduje coś podobnego

Traktować agenta jak część produktu, z konkretnymi zobowiązaniami, a nie jak pokaz możliwości. Oprzeć go na plikach objętych kontrolą wersji. Zadbać, żeby każdy limit w razie awarii ograniczał dostęp. Napisać testy na rozmowy, które najlepiej, żeby nigdy się nie wydarzyły. Nic z tego nie wymaga wyszukanej infrastruktury: u nas to jedna trasa w Next.js, licznik w Redisie i katalog plików markdown.

Agent mojej własnej strony — ten, który będzie mnie wychwalał ponad miarę, pozostając przy tym wiernym faktom — powstaje dokładnie na tym fundamencie. Osobowość to najłatwiejsza część.