Agenci samodoskonalący się: leczenie, uczenie się i kontrolowane zmiany
Agenty samodoskonalące się bez zagrożeń: samoregeneracja w trakcie działania, uczenie się podczas kolejnych wykonywań oraz zmiany wprowadzane wyłącznie po ocenach i testach kanaryjskich, w LangGraph.
Źródła: Self-improving Agentic AI Applications — Feedback loop integration
Agent w stylu ReAct dobrze planuje, wykorzystuje narzędzia, pozyskuje informacje i kończy zadania wieloetapowe. Problemy pojawiają się w momencie, gdy agent trafia do produkcji, a ktoś pyta, co się dzieje, gdy popełni błąd. Czy potrafi to zauważyć? Czy może się odzyskać bez restartowania całego procesu? Czy potrafi zapamiętać, co zadziałało, uczyć się na błędach użytkowników i w końcu poprawić swoje zachowanie?
Ludzie łączą te pytania pod nazwą „pętla informacyjna agenta”, ale ta nazwa jest myląca. Poniższa architektura łączy LangGraph z MongoDB, Gemini w Vertex AI oraz Arize Phoenix i obejmuje odzyskiwanie po awariach, uczenie się na doświadczeniach, ciągłą ocenę oraz kontrolowaną poprawę.
Dlaczego prosta pętla jest niebezpieczna
Kusząca wersja pętli informacyjnej jest krótka:
Agent produces answer
↓
LLM reflects on answer
↓
Agent learns
Jest atrakcyjny, ponieważ jest prosty, ale jednocześnie niesie ze sobą ryzyko. Gdy model językowy ocenia swój własny wynik i natychmiast zmienia swoje dalsze zachowanie, błąd może stać się lekcją, lekcja może stać się pamięcią, a ta pamięć może następnie wpłynąć na tysiące późniejszych decyzji.
Bardziej bezpieczny projekt opiera się na innym zasadzie: agent naprawia błędy w bieżącej realizacji, platforma uczy się na podstawie wielu realizacji, a warstwa kontrolna decyduje, co stanie się standardowym zachowaniem.
Przykład z życia: agent poleca kody dotyczące wypłat lub odliczeń. Podczas jednej realizacji wybiera niewłaściwy kod, ponieważ nigdy nie pobrał polityki wypłat specyficznej dla danego stanu. Prosty proces uczenia się wygląda w ten sposób:
Agent made mistake
↓
Agent reflects
↓
"Always retrieve state policy"
↓
Write lesson to memory
↓
Future agents use lesson
W tym przypadku może wystąpić kilka problemów. Diagnoza może być błędna. Zasada może odnosić się tylko do jednego typu transakcji płacowych. Późniejsza zmiana zasad może sprawić, że ta lekcja stanie się przestarzała. Złośliwe dane wprowadzone przez użytkownika mogą wpłynąć na wynik analizy. Ponadto lekcja może być przydatna w niektórych przypadkach, a szkodliwa w innych.
Dlatego lepszy projekt traktuje lekcję jako hipotezę, a nie jako prawdę.
Production failure
↓
Capture evidence
↓
Evaluate the run
↓
Identify recurring failure
↓
Generate lesson candidate
↓
Gather supporting and contradicting evidence
↓
Validate
↓
Canary test
↓
Activate
Zmiana jest subtelna. Agent nie przepisuje się ciągle. Platforma wokół niego stale ocenia i rozwija agenta.
Trzy poziomy o różnej władzy
Pomaga wyobrazić sobie trzy połączone poziomy.
+------------------------------------------------+
| RUNTIME PLANE |
| |
| plan -> act -> validate -> repair -> respond |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| LEARNING PLANE |
| |
| evaluate -> diagnose -> cluster -> learn |
+-----------------------+------------------------+
|
v
+------------------------------------------------+
| CONTROL PLANE |
| |
| test -> approve -> canary -> rollout -> rollback|
+------------------------------------------------+
Każda warstwa działa we własnym tempie i posiada różny stopień uprawnień. Warstwa czasu wykonywania funkcjonuje w ciągu milisekund lub sekund, a jej jedynym zadaniem jest niezawodne sprostanie bieżącej prośbie. Warstwa uczenia się analizuje liczne próby przeprowadzone w ciągu minut, godzin lub dni i określa, co wskazują zebrane dane. Warstwa sterowania decyduje, czy proponowana poprawka jest na tyle bezpieczna, by zostać wdrożona w praktyce. Niewiele decyzji projektowych w platformie agentów adaptacyjnych ma większe znaczenie niż oddzielenie tych trzech warstw.
1. Samoregeneracja w czasie wykonywania
Zacznijmy od bezpośredniego problemu: nie udaje się wywołać narzędzia. Prosta implementacja po prostu próbuje ponownie.
Tool failed
↓
Retry
↓
Retry
↓
Retry
Jednak ponawianie prób nie jest sposobem na samorekompensację. Aby to osiągnąć, trzeba wiedzieć co się nie udało i wybrać odpowiednią strategię naprawczą. Silniejszy proces pracy LangGraph bardziej przypomina to podejście:
User Request
|
v
Clarification Gate
|
v
Retrieve Context
|
v
Plan
|
v
Proposed Action
|
v
Action Guard
|
v
Execute Tool
|
v
Sanitize Tool Result
|
v
Validate Tool Result
|
v
Reason
|
v
Validate Answer
|
+------ uncertain ------> Critic
| |
| v
| Policy Router
| / | | \
| PASS REPAIR HUMAN FAIL
| |
+---------------------------+
|
v
Response
Kilka elementów na tym wykresie zasługuje na uwagę.
Waliduj przed podjęciem działań
Załóżmy agenta, który może wykonywać działania o skutkach ubocznych: aktualizować dane pracowników, tworzyć potrącenia z pensji, wysyłać transakcje, modyfikować konta lub przesyłać powiadomienia. Sprawdzanie wyniku później jest zbyt późne. Architektura wymaga zabezpieczenia działań przed jakąkolwiek zmianą o konsekwencjach. To zabezpieczenie bierze pod uwagę uprawnienia, zasady biznesowe, dostępne dowody, to, czy działanie można odwrócić, poziom ryzyka oraz to, czy ktoś musi je zatwierdzić. Dopiero wtedy narzędzie może zostać uruchomione.
To zmienia sposób postrzegania walidacji. Pytanie przestaje brzmieć „czy działanie było poprawne?” i staje się znacznie bezpieczniejsze: „czy mamy wystarczająco dowodów i uprawnień, aby to zezwolić?”
Wyniki narzędzia również nie są godne zaufania
Kolejne zagrożenie pozostaje pomijane. Agenci czytają treści z stron internetowych, dokumentów, API, silników wyszukiwania, baz danych oraz innych agentów, a te materiały trafiają do kontekstu LLM. Wyniki narzędzi stanowią zatem kolejną drogę do iniekcji promptów, dlatego pomiędzy wykonywaniem narzędzia a procesem rozumowania powinien znajdować się deterministyczny sanitizator wyników narzędzi.
External Tool
|
v
Tool Result
|
v
Sanitizer
|
v
Validator
|
v
LLM
Typowe zadania sanitizatora obejmują egzekwowanie typu i długości wyjścia, odrzucanie nieprawidłowych struktur, escapeowanie tekstu, który wygląda jak instrukcje, oraz wykrywanie prawdopodobnych prób iniekcji. Istnieje jedno ścisłe ograniczenie: nie wolno używać modeli LLM do sprawdzania tekstu, który może mieć charakter atakujący.
Trzymaj walidator oddzielnie od krytyka
Powszechnym wzorcem jest zadawanie modelowi LLM na każdą prośbę pytania „Czy ta odpowiedź jest poprawna?”. To powoduje opóźnienia i wyższe koszty, a także nadaje modelowi zbyt dużą władzę. Najpierw powinna nastąpić deterministyczna walidacja, na przykład:
Schema correct?
Required fields present?
Allowed value?
Business invariant satisfied?
Evidence exists?
Policy satisfied?
Known contradiction detected?
Jeśli oprogramowanie może udowodnić, że odpowiedź jest błędna, nie ma powodu, by pytać inny model. Tylko prawdziwa niejednoznaczność semantyczna dociera do krytyka, a nawet wtedy krytyk nie kieruje procesem pracy. Jego rolą jest diagnoza, w następujący sposób:
{
"correctness": 0.61,
"groundedness": 0.92,
"uncertainty": 0.73,
"defects": [
"missing_authoritative_evidence"
]
}
Router polityki deterministycznej wybiera następnie spośród czterech możliwych wyników:
PASS
REPAIR
HUMAN REVIEW
SAFE FAIL
Rozdział jest jasny: LLM dostarcza dowodów i oceny, natomiast polityka oprogramowania posiada władzę decyzyjną.
Naprawa powinna zmienić strategię
Ponowna próba ma sens tylko wtedy, gdy coś się zmieniło. Weźmy agenta, który to robi:
Search policy
↓
Generate recommendation
↓
Fail validation
Jeśli naprawa powtarza poniższą sekwencję przy użyciu tej samej zapytania, tych samych dowodów i tego samego podejścia rozumowania, to nie jest to przywrócenie. To jest powtórzenie.
Search policy
↓
Generate recommendation
Niezawodny agent śledzi kilka pól.
failure signature
strategy fingerprint
attempt ID
repair strategy
remaining budget
quality delta
Wtedy obowiązuje prosta zasada.
same failure
+
same strategy
+
same evidence
=
do not retry
Gdy ta sama awaria wystąpi po raz drugi przy tej samej strategii, agent powinien zmienić strategię, przekazać zadanie osobie lub bezpiecznie ponieść porażkę. Sam retry_count nie obejmuje tego przypadku, dlatego samonaprawa w środowisku produkcyjnym wymaga budżetów naprawczych. Mogą one ograniczać liczba wywołań modeli językowych, narzędzi, upływający czas, wydatki oraz próby napraw semantycznych. Celem nie jest wytrwałość do chwili, aż coś zadziała – celem jest wykorzystanie ograniczonej ilości zasobów na strategie naprawcze, które rzeczywiście się różnią.
Sprawdzenie, czy naprawa pomogła
Różne próby mogą nadal nie przynieść efektu. Załóżmy, że oceniający ocenia początkowy wynik:
quality score = 0.54
Po pierwszej naprawie:
quality score = 0.55
Po drugim:
quality score = 0.56
Na papierze to jest poprawa, a w praktyce to stagnacja. Repair delta gate temu zapobiega.
delta = score_after_repair - score_before_repair
Gdy kilka napraw przynosi zaledwie znikome korzyści, przepływ zasobów ustaje.
small delta
+
small delta
=
human review or safe failure
To chroni przed jedną z najczęstszych awarii agentów – kosztownym pętlem rozumowania, który wydaje się aktywny, ale w rzeczywistości nie osiąga prawie nic.
Przegląd przez człowieka to wybór strategii
Przegląd przez człowieka nie powinien być uważany za awarię. W przypadku niektórych zadań jest to po prostu właściwa ostateczna decyzja. A „przegląd przez człowieka” obejmuje kilka różnych wyników.
Human
|
+-----------+-----------+
| | |
Approve Edit Reject
| | |
Continue Validate Safe Fail
Request Repair
|
v
Repair
Każdy wynik rozwija się inaczej, więc każdy z nich powinien być wyraźnie pokazany na wykresie. Model przerwania i wznowienia w LangGraph doskonale temu służy, ponieważ proces może być zatrzymany w określonym momencie, a następnie wznowiony po otrzymaniu odpowiedzi od recenzenta.
2. Uczenie się na podstawie doświadczeń z różnych prób
Rozwiązywanie problemów w trakcie wykonywania zadania odpowiada na pytanie, jak uratować tę prośbę. Uczenie się na podstawie doświadczeń dotyczy tego, czego ta prośba uczy nas na temat przyszłych zapytań. Zazwyczaj odbywa się to w tle. Gdy agent już udzielił odpowiedzi:
run_completed
|
v
Evaluation worker
|
v
Gather feedback
|
v
Reflection
|
v
Candidate lesson
Nikt nie musi czekać, aż jedno LLM zastanowi się nad tym, czego mogło się nauczyć inne LLM. Opóźnienia pozostają niskie, a ocena offline może być znacznie bardziej szczegółowa.
Komentarze to nie prawda
Sygnały przychodzą z różnych kierunków. Użytkownik naciska przycisk odrzucenia. Ekspert w danej dziedzinie poprawia odpowiedź. API odrzuca transakcję. Audyt zgodności wykrywa błąd po dwóch tygodniach. Nie wszystkie one są równoważne. Rozważmy pierwsze dwa przypadki, w których równoważność nie zachodzi:
thumbs up != correct
thumbs down != incorrectuser correction != authoritative rule
W związku z tym informacje zwrotne powinny być traktowane jako surowe dowody i sklasyfikowane według wiarygodności, mniej więcej w ten sposób:
Authoritative business outcome
>
Expert human label
>
Deterministic rule
>
Calibrated evaluator
>
User feedback
>
Agent self-confidence
To zapobiega mylzeniu się sentymentu z rzeczywistymi danymi.
Część najlepszych informacji zwrotnych przychodzi późno
Agenci często rozpoczynają procesy, których sukces nie jest od razu widoczny.
Agent recommends payroll code
|
v
Payroll system accepts
|
v
Two weeks later
|
v
Audit rejects transaction
Przydatny sygnał przychodzi długo po zakończeniu wykonywania LangGraph, co oznacza, że każda ważna decyzja wymaga określenia jej przyczynowej ścieżki. Należy przekazać run_id do systemów poniżej w łańcuchu, aby późniejsze wyniki można było powiązać z decyzją, która je spowodowała. W przeciwnym razie system uczenia się dowiaduje się, że coś się nie udało, ale nie potrafi określić która decyzja agenta zasługuje na uznanie lub winę. To klasyczny problem przydziału zasług.
Pamięć wymaga zarządzania
Gdy agenci uczą się podczas kolejnych wykonywań, pamięć staje się jednocześnie potężna i niebezpieczna. Warto odróżnić trzy rodzaje pamięci.
- Pamięć profilowa przechowuje preferencje użytkownika lub entity, np. preferencję dla zwięzłych wyjaśnień.
- Pamięć epizodyczna rejestruje to, co się wydarzyło, na przykład to, że wykonywanie nr 182 nie powiodło się z powodu braku pobrania polityki stanu.
Pamięć proceduralna najbardziej wpływa na zachowanie, dlatego wymaga najściślejszej kontroli. Jeden nieudany próbny proces nigdy nie powinien stworzyć reguły proceduralnej używanej w produkcji. Ścieżka powinna wyglądać mniej więcej tak:
Observation
↓
Candidate lesson
↓
Supporting evidence
+
Counterexamples
↓
Validation
↓
Active lesson
Lekcję lepiej przedstawić jako hipotezę wraz z dowodami, zakresem, zaufaniem i cyklem życia, a nie jako tekst umieszczony w pamięci wektorowej.
Pamięć nabytej nie może przewyższyć autorytatywnej wiedzy
Agenty pobierają dwa rodzaje informacji. Autoritytatywna wiedza oznacza polityki, regulacje, konfigurację, dane referencyjne oraz umowne zasady biznesowe. Wiedza nabyta to preferencje, doświadczenia, wcześniejsze strategie, obserwacje i wnioski. Powinny one pozostać logicznie oddzielone, przy zachowaniu rozsądnej kolejności:
Authoritative policy
>
Tenant configuration
>
Approved procedural lesson
>
Episodic example
>
User preference
>
Unverified claim
>
LLM reflection
W przeciwnym razie lekcja dobrze zapamiętana może po cichu zastąpić rzeczywistą politykę.
Lekcje tracą aktualność
To, co było przydatne sześć miesięcy temu, może teraz być błędne. Polityki, produkty, API, zachowanie użytkowników oraz modele stale się zmieniają. Aktywne lekcje wymagają zarządzania ich cyklem życia.
candidate
↓
validated
↓
active
↓
pending revalidation
↓
deprecated
↓
retired
Daj każdej lekcji datę ważności oraz, gdy to ma sens, zasadę wygaśnięcia lub ponownej walidacji. Zmiana zasad może wtedy spowodować ponowną ocenę wszystkich lekcji opartych na tych zasadach, dzięki czemu pamięć staje się uporządkowaną wiedzą, a nie zbiorem coraz większej liczby danych wejściowych.
3. Plan uczenia się offline
Następna warstwa agreguje dane z wielu sesji produkcyjnych.
Runs
+
User Feedback
+
Human Reviews
+
Downstream Outcomes
+
Evaluation Scores
|
v
Failure Classification
|
v
Failure Clustering
Powiedzmy, że tydzień biegów ujawnia taką rozkładność:
missing state policy 178
wrong tool selected 63
bad tool argument 52
unsupported inference 41
output schema failure 11
Teraz platforma może zidentyfikować, które problemy są systemowe. To coś zupełnie innego niż proszenie pojedynczego, nieudanego agenta o refleksję nad jednym nieudanym procesem. System uczenia się dostrzega wzorce.
Nie każda awaria jest problemem z promptem
Inżynieria promptów nie zawsze jest rozwiązaniem. Jeśli agent ciągle zapomina pobrać autorytatywną politykę przed zaleceniem czegoś, dodanie linijki do promptu systemowego z prośbą o jej zapamiętanie może pomóc. Silniejszym rozwiązaniem może być reguła strukturalna:
Graph rule:
Policy retrieval must occur before this decision.
Inne powtarzające się awarie mogą wymagać zmian w tych obszarach:
retrieval
tool schema
validator rule
routing
memory policy
clarification logic
action guard
model configuration
Zaawansowany silnik ulepszeń proponuje kilka możliwych rozwiązań i nie przepisuje automatycznie instrukcji.
Ocena jest w centrum
Jeśli system potrafi tworzyć ulepszenia, ale nie może ocenić, czy są one lepsze, nie ma pętli uczenia się, tylko pętla mutacji. Ocena stanowi filar tej architektury.
Correctness
Groundedness
Retrieval relevance
Completeness
Tool selection
Tool arguments
Trajectory efficiency
Repair effectiveness
Safety
Latency
Cost
Business outcome
Ocena musi obejmować ostateczną odpowiedź oraz drogę, którą została ona osiągnięta. Dwa agenci mogą dostarczyć tę samą odpowiedź. Agent A robi to w następujący sposób:
Agent A
search -> answer
podczas gdy Agent B robi to:
Agent B
search
-> wrong tool
-> retry
-> timeout
-> second search
-> repair
-> answer
Patrząc tylko na ostateczną odpowiedź, są równoważne. Ocena trajektorii pokazuje, że wyraźnie tak nie jest.
Jeden sędzia w postaci LLM nie wystarcza
Skorzystanie z Gemini do napisania odpowiedzi, a następnie oceny jej przez inne Gemini jest przydatne, ale niesie ze sobą ryzyko błędów korelowanych, ponieważ oceniający może mieć te same słabe punkty co generator. Silniejsza warstwa oceny łączy kilka źródeł.
Deterministic checks
+
Business outcomes
+
Human labels
+
Multiple evaluator rubrics
+
LLM judges
Osoby oceniające LLM powinny być od czasu do czasu porównywane z przykładami oznaczonymi przez ludzi. To pokazuje, w jakim stopniu można ufać ocenie, zanim jej wyniki wpłyną na to, które lekcje zostaną promowane.
Obserwowalność jest częścią procesu uczenia się
Tradycyjne monitorowanie sprawdza, czy usługa jest dostępna. Obserwowalność agenta musi również wyjaśniać, dlaczego agent podjął określoną decyzję. Dobry setup produkcyjny rejestruje ślad całego procesu wykonywania LangGraph.
Agent Run
|
+-- Retrieve Context
|
+-- Planner
|
+-- Tool Call
|
+-- Tool Result Validator
|
+-- Repair
|
+-- Critic
|
+-- Final Answer
Każda sesja powinna również mieć stabilną tożsamość łączącą kilka rekordów.
LangGraph execution
MongoDB events
Vertex AI calls
Evaluation results
Human feedback
Downstream outcomes
To powiązanie stanowi surowiec dla pętli. Obserwowalność przestaje być jedynie narzędziem do naprawiania błędów i staje się częścią systemu uczenia się.
Dlaczego pomocne są wydarzenia typu append-only
Kuszące jest umieszczenie całej ścieżki wykonywania w jednym dokumencie run w MongoDB. Na początku to działa, ale w większych skali staje się to problematyczne. Lepiej utrzymywać dokument run w kompaktowej formie.
run_id
agent
release
outcome
latency
tool count
repair count
cost
Następnie zapisz wykonywanie jako wydarzenia typu append-only.
run.started
retrieval.completed
tool.called
validation.failed
repair.started
human_review.requested
run.completed
To zachowuje kolejność przyczynowo-skutkową, zapobiega ogromnemu rozrastaniu się dokumentów, upraszcza śledzenie działań w środowisku rozproszonego oraz sprawia, że analiza awarii jest dokładniejsza.
Aby uzyskać możliwość odtworzenia, potrzeba czegoś więcej niż tylko wersji promptu
Behawior agenta zależy od czegoś więcej niż tylko od jego promptu systemowego.
model
generation settings
graph version
tool definitions
validator rules
critic rubric
retrieval configuration
memory rules
security rules
Każda seria produkcji powinna zatem używać niezmiennej wersji agent release. Koncepcyjnie:
agent_release_43
|
+-- graph v12
+-- prompt v43
+-- Gemini configuration
+-- tools v17
+-- validator v11
+-- retrieval config v9
+-- memory policy v5
+-- evaluation suite v8
Nieudaną próbę można następnie odtworzyć później. Bez tego debugowanie sprowadza się do pytania, która wersja dała odpowiedź, po czym następuje cisza.
Płaszczyzna sterowania: ulepszenia otwierają dostęp do produkcji
W końcu system uczenia się wykrywa powtarzające się błędy i opracowuje propozycję ulepszenia. Najgorszą reakcją jest natychmiastowe wdrożenie tego rozwiązania. Zamiast tego należy je sprawdzić poprzez odpowiednie procedury:
Candidate Improvement
|
v
Historical Replay
|
v
Regression Evaluation
|
v
Shadow Production
|
v
Canary
|
v
Progressive Rollout
|
v
Production
Na każdym etapie należy porównać kandydata z obecną wersją. Może to poprawić poprawność działania, ale zwiększyć opóźnienia, zmniejszyć ilość halucynacji i zwiększyć konieczność interwencji człowieka, albo pomóc w jednym typie zadań, szkodząc przy tym innym. Dlatego promocja wymaga kilku zabezpieczeń.
Lekcje również potrzebują „kanary”
Długoterminowa pamięć ma ciekawy skutek. Gdy aktywowana zostaje nowa lekcja proceduralna i wprowadzona do kontekstu przyszłych agentów, ich zachowanie się zmienia, więc wprowadzanie lekcji jest w rzeczywistości zmianą promptu. Aktywację należy traktować jako eksperyment, a nie od razu stosować w każdym dostępnym przypadku.
Historical replay
↓
5% canary
↓
Measure outcome
↓
25%
↓
Measure
↓
100%
Jeśli lekcja pogarsza wydajność, cofnij ją. Wtedy pamięć przestaje być tajemniczym mechanizmem adaptacyjnym i staje się mierzalną częścią wersji oprogramowania.
Ostateczna architektura
W całości platforma agenta adaptacyjnego wygląda mniej więcej tak:
USER
|
v
+------------------------------------------------------+
| RUNTIME |
| |
| clarify -> retrieve -> plan -> action guard |
| | |
| v |
| tool |
| | |
| sanitize |
| | |
| validate |
| | |
| reason |
| | |
| answer validate |
| | |
| critic if needed |
| | |
| policy router |
| / | \ |
| repair human pass |
+--------------------------+---------------------------+
|
agent events
|
v
+------------------------------------------------------+
| LEARNING |
| |
| traces + feedback + outcomes |
| | |
| v |
| evaluate |
| | |
| classify failures |
| | |
| cluster |
| / \ |
| lessons improvement candidates |
+--------+----------------------+----------------------+
| |
v v
+------------------------------------------------------+
| CONTROL |
| |
| validate -> replay -> shadow -> canary -> rollout |
| | |
| monitor |
| | |
| rollback |
+------------------------------------------------------+
Granice odpowiedzialności są celowo wyraźne. Agent w czasie wykonywania naprawia błędy w procesie działania. System uczenia się generuje hipotezy. Warstwa sterująca decyduje, co stanowi wiarygodne zachowanie.
Przemyślenie koncepcji „samodoskonalącego się”
Słysząc „agent samodoskonalący się”, wielu ludzi wyobraża sobie sztuczną inteligencję, która przepisuje swój własny prompt systemowy lub aktualizuje się po każdej rozmowie. Dla systemów produkcyjnych to błędny model myślowy. Lepszym jest cykl:
Observe
↓
Measure
↓
Diagnose
↓
Propose
↓
Test
↓
Promote
↓
Monitor
Inteligencja w tym przypadku nie ogranicza się tylko do LLM. Różne elementy systemu ją zawierają:
- Graph LangGraph określa kolejność wykonywania zadań.
- Walidatory zwykłego kodu egzekwują już znane zasady.
- LLM zajmuje się wszystkim, co jest niejednoznaczne.
- MongoDB przechowuje stan oraz zgromadzone doświadczenie.
- System śledzenia zbiera dowody.
- Ewaluatorzy oceniają jakość.
- Ludzie podejmują decyzję, gdy ryzyko jest wysokie, a odpowiedź niejasna.
- Płaszczyzna sterowania kontroluje wszelkie zmiany w zachowaniu.
Taka struktura rozproszenia przekształca agenta w adaptacyjny system agentów.
Rozsądna kolejność budowy
Nikt nie musi budować całego cyklu za jednym razem. Skuteczna sekwencja zaczyna się od niezawodnej eksploatacji oraz rejestrowania działań przy każdym uruchomieniu. Dodatkowo stosuje się mechanizmy ochronne, weryfikację wyników i odpowiedzi, ograniczone naprawy oraz ludzką kontrolę. Kolejnym krokiem jest pomiar jakości: rejestracja działań, ocena i klasyfikacja awarii oraz zbieranie danych do analizy regresji. Doświadczenie zdobywane jest dopiero wtedy, gdy jakość można mierzyć z pewnością, co umożliwia identyfikację wniosków, zarządzanie pamięcią, agregację dowodów, kontrolę aktualności informacji oraz opóźnioną informację zwrotną. Ostatecznym etapem jest kontrolowane udoskonalanie, obejmujące grupowanie awarii, generowanie rozwiązań, ocenę ponownego uruchomienia, symulację ruchu oraz stopniowe wdrażanie nowych rozwiązań.
Kolejność ma znaczenie:
Reliability
↓
Observability
↓
Evaluation
↓
Learning
↓
Controlled adaptation
Przejście od razu do „samouczki” przed przeprowadzeniem oceny zazwyczaj skutkuje systemem, który zmienia się szybciej, niż inżynierowie są w stanie za tym nadążyć.
Cel
Nikt nie powinien dążyć do agenta, który sam siebie edytuje. Lepszym celem jest platforma zdolna do pokazania, kiedy agent powinien się zmienić. Pamiętanie wcześniejszych rozmów nie wystarcza, by taki cykl zasłużył na zaufanie. Potrzebuje on uporządkowanej łańcuchowej struktury łączącej te etapy:
production behavior
↓
evidence
↓
evaluation
↓
learning
↓
experimentation
↓
controlled production change
To właśnie ta łańcuchowa struktura stanowi podstawę systemu adaptacyjnych agentów opartych na dowodach, a jest to architektura niezbędna sztucznej inteligencji agentowej, jeśli ma przejść od demonstracyjnych przykładów do niezawodnego oprogramowania produkcyjnego.