Agent to nie czat z ambicjami. To oprogramowanie działające w Waszym imieniu

Ciekawą częścią inżynierii agentów nie jest model. Jest nią rozstrzygnięcie, czego agent może dotknąć, o co musi zapytać, co robi, gdy nie jest pewien, i jak ktokolwiek odtworzy jego decyzję trzy tygodnie później. Te cztery pytania oddzielają agenta, którego można postawić przed procesem, od pokazu.

  • Agent wykonujący prawdziwe zadanie od początku do końca. Jeden proces, realizowany na Waszych prawdziwych systemach, a nie pokaz według scenariusza.
  • Jawne granice. Co może czytać, co zmieniać, do jakiej wartości i co musi eskalować — spisane i egzekwowane w kodzie, a nie w promptcie.
  • Rejestr decyzji. Co zobaczył, co wywnioskował, co zrobił i kto zatwierdził. Trzymany trwale, czytelny dla człowieka i będący powodem, dla którego całość da się obronić.
  • Ścieżka ograniczenia. Zdefiniowany sposób zawężenia tego, co agent może robić bez nadzoru — pierwsza reakcja na cokolwiek, co pójdzie źle.
Porozmawiajmy o tym

Co przekazujemy

  • Definicja zadania i granicy

    Zadanie w kategoriach operacyjnych i granica wokół niego: dozwolone działania, limity wartości, dane, które może widzieć, i przypadki zawsze idące do człowieka.

  • Warstwa narzędzi

    Agent rozmawia z Waszymi systemami przez jawne, otypowane narzędzia z uprawnieniami, a nie przez ogólny dostęp. Stąd bierze się większość bezpieczeństwa i tam idzie większość pracy.

  • Zestaw ewaluacyjny

    Prawdziwe przypadki ze znanymi poprawnymi odpowiedziami, łącznie z niewygodnymi, żeby zmianę dało się ocenić, a nie odczuć. Budowany przed agentem, nie po nim.

  • Zatwierdzanie i eskalacja

    Gdzie potwierdza człowiek, jak agent pyta i co zawiera dobra eskalacja. Zaprojektowane tak, żeby sprawdzanie było szybkie — bo wolne sprawdzanie zamienia się w przyklepywanie.

  • Obserwowalność

    Rejestry decyzji, koszt i czas na zadanie oraz monitoring zbudowany pod system psujący się po cichu, a nie pod taki, który się wywala.

  • Runbook

    Co robić, gdy się myli: jak zawęzić zakres, jak się wycofać i kogo się wzywa. Spisane, zanim będzie potrzebne.

Jak to przebiega

  1. 01

    Zawęź jedno zadanie

    Wąskie, o dużym wolumenie i ze sprawdzalnym wynikiem. Szerocy agenci padają w sposób, którego nikt nie zdebuguje; wąscy zarabiają na prawo do rozrostu.

  2. 02

    Zbuduj narzędzia

    Najpierw integracje i uprawnienia, potem zachowanie agenta. Agent jest tak dobry, jak to, do czego może bezpiecznie sięgnąć.

  3. 03

    Oceń uczciwie

    Na zestawie ewaluacyjnym łącznie z wyjątkami, z opublikowanym poziomem błędów zamiast wygładzonego.

  4. 04

    Wypuść za bramką

    Na produkcję z człowiekiem potwierdzającym działania wychodzące, a potem poszerzaj granice w miarę tego, co pokazują dowody.

Dobre dopasowanie, gdy

  • Zadanie o dużym wolumenie, ze sprawdzalnym wynikiem i jasnymi regułami kciuka.
  • Praca, która dziś wymaga przeczytania nieustrukturyzowanego wejścia i przygotowania ustrukturyzowanego działania.
  • Próbowaliście już czatu i okazało się, że umie odpowiadać, ale nie działać.
  • Ślad audytowy jest Wam potrzebny tak samo jak automatyzacja.

To nie ta usługa, gdy

  • Proces nie jest zdefiniowany i każdy robi go inaczej. Najpierw to — automatyzacja niezdefiniowanego procesu utrwala jedną jego wersję z dużą prędkością.
  • Zadanie ma mały wolumen i duże konsekwencje. Lista kontrolna będzie lepsza i tańsza.
  • Chcecie autonomii bez bramek zatwierdzania przy działaniach nieodwracalnych. Tego nie zbudujemy.

Najczęstsze pytania

Jakich modeli używacie?
Takich, które pasują do zadania, reguł dotyczących danych i budżetu — a wybór jest świadomie wymienialny. Dostawcy modeli zmieniają się szybko, więc architektura trzyma model za interfejsem, zamiast budować Wasz proces wokół jednego dostawcy.
Czy agent może działać bez człowieka?
Przy działaniach odwracalnych i ograniczonych tak, gdy pozwalają na to dowody. Przy czymkolwiek nieodwracalnym — wychodzące pieniądze, kontakt z klientem, zaciągnięte zobowiązanie — zatwierdza człowiek. Ta granica jest projektem, a nie ograniczeniem pierwszego wydania.
Co, gdy agent jest pewny siebie i błędny?
Czasem będzie, bo tak zachowuje się system probabilistyczny na krawędziach. Zaprojektowane jest to, żeby zostało szybko zauważone, uczciwie opisane i ograniczone tak, by koszt pomyłki pozostał mały. Pierwszą reakcją zawsze jest zmniejszenie autonomii, a potem dochodzenie.
Jak zapobiegacie prompt injection i wyciekom danych?
Głównie architekturą, a nie instrukcjami: otypowane narzędzia z wąskimi uprawnieniami, treść niezaufana nigdy traktowana jako polecenie, walidacja wyjścia i dane, których agent nie potrzebuje, po prostu poza jego zasięgiem. Same zabezpieczenia na poziomie promptu nie są modelem bezpieczeństwa.
Jak szybko coś zadziała?
Wąski pierwszy agent na produkcji za bramką zatwierdzania to zwykle tygodnie. Poszerzanie granic trwa dłużej i powinno, bo każde poszerzenie potrzebuje dowodów z poprzedniego.

Czytaj dalej

Pozostałe usługi