CAMEL, agenci grający role i dane

CAMEL, czyli agenci, którzy rozmawiają w rolach

CAMEL wyrósł z pytania badawczego, a nie z potrzeby produkcyjnej, i to widać w jego konstrukcji. Pierwotna teza brzmiała: dwa modele językowe, z których jeden gra zleceniodawcę, a drugi wykonawcę, rozwiążą zadanie lepiej niż jeden model dostający polecenie wprost.

Brzmi jak sztuczka, a okazało się kierunkiem, którym poszła cała branża. Rozdzielenie ról na tego, kto formułuje kolejne kroki, i tego, kto je wykonuje, zmniejsza skłonność modelu do pomijania etapów i daje zapis rozumowania, który da się przeczytać.

Dziś projekt jest czymś więcej niż tą jedną koncepcją. To biblioteka do budowania systemów wieloagentowych, zestaw narzędzi do generowania danych treningowych oraz zaplecze do prowadzenia symulacji. Ta wielość zastosowań jest jego siłą i zarazem powodem, dla którego bywa mylnie oceniany.

Trzy rzeczy, do których się nadaje

Warto rozdzielić je na początku, bo materiały o projekcie zwykle mieszają je ze sobą, a decyzja o użyciu zależy od tego, którą z nich masz na myśli.

Pierwsza to budowa agentów wykonujących zadania, czyli to samo, co robią inne biblioteki tej klasy. Tutaj projekt jest jednym z wielu wyborów i nie ma szczególnej przewagi.

Druga to generowanie danych syntetycznych. Dwa agenty prowadzące rozmowę w rolach wytwarzają zapis, który nadaje się na materiał treningowy albo testowy. To jest zastosowanie, w którym projekt ma realną przewagę nad konkurencją, bo powstał właśnie do tego.

Trzecia to symulacje. Kilkudziesięciu agentów z przypisanymi rolami, celami i możliwością komunikacji pozwala badać, co się dzieje w grupie. To zastosowanie badawcze, rzadko trafiające do produktu, natomiast ciekawe przy modelowaniu zachowań.

Jeśli szukasz biblioteki do zbudowania agenta obsługującego zgłoszenia klientów, druga i trzecia pozycja są dla Ciebie nieistotne, a przy pierwszej warto porównać go z narzędziami nastawionymi wprost na produkcję.

Pojedynczy agent

pip install "camel-ai[all]"

from camel.agents import ChatAgent
from camel.messages import BaseMessage

agent = ChatAgent(
    system_message=BaseMessage.make_assistant_message(
        role_name="Analityk",
        content="Analizujesz dane sprzedazowe. Odpowiadasz liczbami i wnioskami.",
    ),
)

odpowiedz = agent.step("Ktory kwartal mial najwyzsza marze i dlaczego?")
print(odpowiedz.msg.content)

Pojęcie roli jest tu obecne od pierwszej linijki i to odróżnia bibliotekę od konkurencji. Agent nie jest po prostu modelem z instrukcją, tylko postacią o nazwanej funkcji, co ma znaczenie, gdy za chwilę zestawisz kilka takich postaci ze sobą.

Obsługiwane są modele różnych dostawców oraz uruchamiane lokalnie, a także narzędzia podłączane przez powszechnie przyjęty protokół, więc integracja z istniejącymi systemami nie wymaga pisania własnych łączników.

Rozmowa w rolach

To jest mechanizm, od którego wszystko się zaczęło.

from camel.societies import RolePlaying

sesja = RolePlaying(
    assistant_role_name="Programista Python",
    user_role_name="Analityk danych",
    task_prompt="Zbuduj raport sprzedazy z podzialem na regiony.",
)

wejscie = sesja.init_chat()
for _ in range(15):
    odp_asystenta, odp_uzytkownika = sesja.step(wejscie)
    if odp_asystenta.terminated or odp_uzytkownika.terminated:
        break
    wejscie = odp_asystenta.msg

Agent w roli zleceniodawcy formułuje kolejne polecenia, agent w roli wykonawcy je realizuje, a rozmowa toczy się do rozwiązania zadania albo do limitu tur. Nikt tego nie planuje z góry: podział zadania na kroki powstaje w trakcie.

Zaleta jest realna przy zadaniach otwartych, gdzie nie wiesz z góry, z ilu kroków się składają. Wada również: przy zadaniu o znanej kolejności ten mechanizm dodaje niepewność i koszt, nie dając nic w zamian.

Limit tur jest tu zabezpieczeniem, a nie formalnością. Dwa agenty potrafią wpaść w wymianę uprzejmości albo zapętlić się na doprecyzowaniu, a każda tura to dwa wywołania modelu, więc rachunek rośnie w tempie, którego nie widać, dopóki go nie policzysz.

Warto też wiedzieć, skąd bierze się rzeczywisty koszt takiej rozmowy. Każda tura niesie ze sobą całą dotychczasową historię, więc piętnasta wypowiedź kosztuje wielokrotnie więcej niż pierwsza, mimo że wygląda tak samo. Przy dwudziestu turach koszt jednego zadania potrafi przekroczyć wartość, przy której cały pomysł przestaje mieć sens ekonomiczny, i to jest właśnie moment, w którym warto sprawdzić, czy zadanie faktycznie wymaga rozmowy.

Praktyczna wskazówka wynika z tego wprost. Zanim uruchomisz odgrywanie ról na tysiącu przypadków, uruchom je na dziesięciu i zsumuj zużyte tokeny. Ta jedna liczba pomnożona przez planowaną skalę mówi więcej niż jakikolwiek szacunek z góry.

Zespół agentów

Nowszy moduł pozwala złożyć zespół, w którym zadanie jest dzielone i rozdzielane między wykonawców o różnych specjalizacjach.

from camel.societies.workforce import Workforce

zespol = Workforce("Zespol analityczny")
zespol.add_single_agent_worker("Analityk danych", worker=analityk)
zespol.add_single_agent_worker("Redaktor raportu", worker=redaktor)

wynik = zespol.process_task(zadanie)

Koordynator rozbija zadanie na części, przydziela je i składa wyniki, a przy niepowodzeniu potrafi wrócić do podziału. To bliższe temu, czego oczekuje się od biblioteki produkcyjnej niż swobodna rozmowa dwóch agentów.

Warto natomiast zachować ostrożność w ocenie. Układ z koordynatorem jest kosztowny, bo planowanie i składanie wyników to dodatkowe wywołania modelu poza samą pracą. Przy zadaniu, które da się opisać trzema krokami po kolei, prostszy przepływ wypada lepiej pod każdym względem.

Zysk pojawia się dopiero wtedy, gdy części zadania są od siebie niezależne i mogą wykonać się równolegle. Wtedy czas odpowiedzi spada do najwolniejszej części zamiast rosnąć do sumy wszystkich, a koszt planowania rozkłada się na coś, co faktycznie się opłaciło. Przy częściach zależnych od siebie koordynator staje się wąskim gardłem i dokłada opóźnienie bez żadnej rekompensaty.

Dane syntetyczne, czyli realna przewaga

Tu projekt robi rzecz, której konkurencja nie robi wcale albo robi przy okazji.

Rozmowa dwóch agentów w rolach to gotowy zapis dialogu z podziałem na wypowiedzi, kroki i wynik. Puszczona na tysiącu wariantów zadania daje zbiór, który nadaje się jako materiał do dostrajania mniejszego modelu albo jako zestaw przypadków testowych.

Zastosowanie, które sprawdza się najlepiej, wygląda tak. Masz drogi model radzący sobie z zadaniem i chcesz tańszy model o zbliżonej skuteczności w tym jednym zastosowaniu. Generujesz kilka tysięcy rozmów, filtrujesz je pod kątem poprawności i dostrajasz na nich mniejszy model.

Trzy zastrzeżenia warto postawić uczciwie. Pierwsze: dane wygenerowane przez model niosą jego błędy i uprzedzenia, więc filtrowanie i sprawdzanie poprawności jest częścią procesu, a nie dodatkiem. Drugie: warunki korzystania z modelu bywają ograniczeniem, bo część dostawców zabrania trenowania konkurencyjnych modeli na wynikach swoich, więc warto je przeczytać przed rozpoczęciem. Trzecie: zbiór wygenerowany z jednego wzorca zadania jest mało różnorodny, a różnorodność decyduje o jakości dostrajania bardziej niż liczba przykładów.

Jak zbudować dobry zbiór danych

Skoro to główna przewaga tego projektu, warto opisać, jak wygląda cały proces, bo samo wygenerowanie rozmów jest tu najłatwiejszą częścią.

Zacznij od zdefiniowania, co ma umieć model docelowy. Nie „obsługiwać zgłoszenia", tylko konkretnie: przypisać zgłoszenie do jednej z ośmiu kategorii, wyciągnąć numer zamówienia i zaproponować odpowiedź w jednym z trzech wariantów. Im węższe zadanie, tym lepiej działa dostrajanie mniejszego modelu.

Potem zadbaj o różnorodność wsadu, bo to ona decyduje o jakości. Tysiąc rozmów wygenerowanych z jednego wzorca zadania jest mniej wart niż dwieście rozmów z dwustu różnych realnych przypadków. Najlepszym źródłem różnorodności są Twoje własne dane historyczne, użyte jako punkty startowe rozmów.

Trzecim krokiem jest filtrowanie, i tu odpada zwykle spora część zbioru. Sprawdzenie automatyczne wyłapie odpowiedzi w złym formacie, niepełne albo sprzeczne z danymi wejściowymi. Przegląd ręczny na próbce stu przykładów pokaże błędy, których żadna reguła nie złapie, i jest wart poświęconej godziny.

Czwartym jest podział na zbiór treningowy i zbiór oceniający, przy czym ten drugi warto zbudować z realnych przypadków, a nie z wygenerowanych. Ocenianie modelu na danych pochodzących z tego samego procesu, który go uczył, daje wynik zawyżony i bezużyteczny.

Piątym jest porównanie. Model dostrojony wygrywa wtedy, gdy przy zbliżonej skuteczności kosztuje wyraźnie mniej albo odpowiada wyraźnie szybciej. Jeśli różnica w koszcie wynosi kilkanaście procent, cały wysiłek zwykle się nie opłaca i lepiej zostać przy większym modelu z lepszym promptem.

Tę ostatnią drogę warto rozważyć wcześniej, bo lepszy prompt też da się wypracować mechanicznie. DSPy optymalizuje instrukcję i dobór przykładów wstawianych do zapytania, kierując się miarą jakości, którą sam definiujesz. Zbiór zebrany na potrzeby dostrajania nadaje się do tego bez zmian, a wynik dostajesz w godzinach zamiast w dniach, więc rozsądna kolejność to najpierw optymalizacja promptu, a dostrajanie dopiero wtedy, gdy ona nie wystarczy.

Symulacje wieloagentowe

Trzecie zastosowanie zasługuje na kilka zdań, bo bywa mylone z budową systemów produkcyjnych, a to zupełnie inna praca.

Symulacja polega na uruchomieniu wielu agentów z przypisanymi rolami, celami i możliwością wymiany wiadomości, a potem obserwowaniu, co się wyłania. Nie ma tu poprawnej odpowiedzi ani metryki sukcesu w zwykłym sensie, bo przedmiotem badania jest samo zachowanie grupy.

Zastosowania są głównie badawcze: sprawdzenie, jak podział ról wpływa na jakość rozwiązania, jak informacja rozchodzi się w grupie, kiedy pojawia się zapętlenie i co się dzieje, gdy jeden agent dostaje sprzeczne polecenia. To jest wartościowe przy projektowaniu własnego systemu wieloagentowego, bo pokazuje granice, na które i tak trafisz później.

Warto natomiast pamiętać o dwóch rzeczach. Pierwsza to koszt: symulacja z dwudziestoma agentami przez sto tur to dwa tysiące wywołań modelu, więc limit wydatku ustawiony z góry jest tu obowiązkowy. Druga to ostrożność we wnioskach. Zachowanie modeli językowych w symulacji mówi o modelach, a niekoniecznie o ludziach, i mylenie tych dwóch rzeczy jest najczęstszym błędem interpretacyjnym w tej dziedzinie.

CAMEL kontra alternatywy

Rozstrzygnięcie jest tu prostsze niż zwykle, bo projekty celują w różne rzeczy. Do systemu obsługującego prawdziwych użytkowników sięgnij po jedną z pozycji nastawionych na produkcję, bo mają lepszą obserwowalność, punkty kontrolne i wsparcie.

Do wytwarzania danych treningowych, badania zachowań grup agentów albo eksperymentów z podziałem ról ta biblioteka daje narzędzia, których w pozostałych po prostu nie ma.

Typowe błędy

Pierwszy to używanie odgrywania ról do zadania o znanej kolejności kroków. Mechanizm dodaje wtedy koszt i niepewność, nie dając nic w zamian.

Drugi to brak limitu tur i limitu kosztu. Każda tura to dwa wywołania modelu, więc zapętlona rozmowa kosztuje szybciej, niż podpowiada intuicja.

Trzeci to traktowanie danych wygenerowanych przez model jako gotowych. Filtrowanie i sprawdzanie poprawności są częścią procesu, bo model powiela własne błędy.

Czwarty to generowanie zbioru z jednego wzorca zadania. Różnorodność decyduje o jakości dostrajania bardziej niż liczba przykładów.

Piąty to pominięcie warunków korzystania z modelu przed generowaniem danych treningowych. Część dostawców ogranicza trenowanie konkurencyjnych modeli na wynikach swoich.

Szósty to wybór tej biblioteki do systemu produkcyjnego wyłącznie dlatego, że dobrze wypadła w opisie. Do produkcji liczą się punkty kontrolne, obserwowalność i przewidywalność przebiegu, a tu nacisk historycznie leży gdzie indziej i widać to w zestawie dostępnych narzędzi.

FAQ

Czym CAMEL różni się od CrewAI?

Celem. CrewAI nastawia się na procesy o jasno przypisanych rolach i zadaniach, z myślą o produkcji. CAMEL wyrósł z badań nad tym, jak agenci rozmawiają ze sobą, i mocniej wspiera generowanie danych oraz symulacje. Przy typowej automatyzacji pierwszy jest prostszy, przy badaniach drugi daje więcej.

Do czego naprawdę się nadaje?

Do trzech rzeczy: wytwarzania danych syntetycznych z rozmów agentów, badania zachowań grup agentów oraz budowy agentów wykonujących zadania. W pierwszych dwóch ma przewagę, w trzeciej jest jednym z wielu wyborów.

Czy dane wygenerowane przez agentów nadają się do trenowania?

Po filtrowaniu i sprawdzeniu poprawności tak, i to jest sprawdzony sposób na uzyskanie tańszego modelu o zbliżonej skuteczności w jednym zastosowaniu. Bez tego etapu zbiór powiela błędy modelu, który go wytworzył.

Czy działa z modelami innymi niż jeden dostawca?

Tak, obsługiwani są różni dostawcy oraz modele uruchamiane lokalnie, na przykład przez Ollamę. Narzędzia podłącza się również przez powszechnie przyjęty protokół, więc integracja z istniejącymi systemami nie wymaga własnych łączników.

Czy nadaje się na produkcję?

Do prostych zastosowań tak, natomiast biblioteki projektowane wprost pod produkcję dają lepszą obserwowalność, punkty kontrolne i przewidywalność przebiegu. Jeśli zależy Ci na powtarzalności i łatwej diagnozie, warto zacząć od nich.

Dokumentacja stoi na stronie projektu, a kod w repozytorium na GitHubie.