Orkiestracja modeli: jak system AI wybiera i łączy modele | Biblioteka

Złota zasada: Nie orkiestruj modeli dlatego, że brzmi to mądrze. Rób to wtedy, gdy różne rodzaje pracy mają wyraźnie odmienne wymagania, a ty potrafisz zmierzyć, kiedy tańsza ścieżka wystarcza, kiedy powinna przekazać zadanie silniejszej i kiedy system powinien się zatrzymać.

Czym jest orkiestracja modeli, a czym nie jest

Orkiestracja modeli to warstwa operacyjna, która dla każdego etapu zadania wybiera model, konfigurację i dalszy krok. Może zdecydować między małym szybkim modelem, droższym modelem klasy frontier, modelem lokalnym albo kodem deterministycznym. Pilnuje budżetu, czasu odpowiedzi, wrażliwości danych, jakości wyniku i zachowania w razie błędu.

Nie jest synonimem systemu wieloagentowego. Stały workflow może używać trzech modeli i nadal pozostać workflow. Nie jest też uniwersalnym proxy, które jedynie podmienia nazwy endpointów. Modele różnią się obsługą narzędzi, limitem kontekstu, wynikiem strukturalnym, zachowaniem bezpieczeństwa i sposobem awarii. Nie jest również powodem, by jeden prosty prompt rozdzielać między pięć modeli.

Najpierw zbuduj punkt odniesienia oparty na jednym rozsądnie wybranym modelu. Orkiestrację dodaj dopiero wtedy, gdy logi pokażą konkretny problem: rutynowe zadania kosztują za dużo, określona klasa zadań działa słabo, część danych musi pozostać lokalnie albo wynik wymaga niezależnego sprawdzenia.

Drzewo decyzji dla routingu

Router nie musi od razu być kolejnym LLM-em. Pierwszą wersję zwykle łatwiej zrozumieć jako kilka reguł:

Czy zadanie jest deterministyczne?
├─ tak → kod, SQL, wyszukiwanie albo walidator bez LLM-a
└─ nie
   Czy dane muszą pozostać w regionie lub na urządzeniu?
   ├─ tak → model lokalny albo zatwierdzony dla danego regionu
   └─ nie
      Czy wynik jest nieodwracalny albo obarczony dużym ryzykiem?
      ├─ tak → silniejszy model + weryfikacja + ewentualnie człowiek
      └─ nie
         Czy tańszy model przechodzi evale dla tej klasy zadań?
         ├─ tak → tańszy model
         └─ nie → silniejszy model

Po każdym kroku:
- błąd schematu lub narzędzia → jedna naprawa, potem przekazanie
- niska, możliwa do sprawdzenia pewność → retrieval, silniejszy model lub człowiek
- timeout lub awaria dostawcy → zgodna ścieżka zapasowa
- problem bezpieczeństwa → zatrzymanie zamiast improwizacji

Sygnały routingu powinny być dostępne przed wywołaniem drogiego modelu: typ żądania, język, rozmiar wejścia, źródło danych, wymagane narzędzia, tenant, SLA i klasa ryzyka. Samoocena modelu może być jednym z sygnałów, ale nie jedynym dowodem. Model potrafi z przekonaniem zatwierdzić własny błąd.

Praktyczny schemat architektury

Użyteczna architektura ma niewiele, ale za to jawnych warstw:

Normalizacja wejścia usuwa zbędne dane, przypisuje tenant i tworzy identyfikator przebiegu.
Brama polityk określa dozwolonych dostawców, region, klasyfikację danych, maksymalny koszt i działania wymagające zatwierdzenia.
Router wybiera ścieżkę na podstawie wersjonowanych reguł lub klasyfikatora. Zwraca też powód decyzji.
Adapter modelu mapuje wewnętrzny format wiadomości, narzędzi i wyników strukturalnych na API dostawcy.
Warstwa wykonawcza uruchamia modele i narzędzia z timeoutem, limitem kroków i kluczem idempotencji.
Weryfikator sprawdza schemat, cytowania, reguły biznesowe albo inny wynik możliwy do sprawdzenia maszynowo.
Kontroler przekazania wybiera naprawę, eskalację, inny model, kontrolę człowieka albo zatrzymanie.
Obserwowalność i repozytorium evali zapisują wersję promptu, model, powód routingu, czas, koszt, wynik weryfikacji i stan końcowy.

Logika domenowa nie powinna znać nazw dostawców. Prosty kontrakt wewnętrzny może zawierać task, risk, data_class, allowed_tools, output_schema i budget. Adaptery obsługują różnice między dostawcami. Abstrakcja nie może jednak sprowadzić wszystkiego do najmniejszego wspólnego mianownika. Jeśli jeden model ma funkcję, która w mierzalny sposób poprawia wynik, udostępnij ją przez jawną flagę możliwości i utrzymuj ścieżkę zapasową.

Przekazywanie zadań i fallbacki bez cichego chaosu

Przekazanie kieruje pracę na inną ścieżkę z konkretnego powodu: wejście okazało się trudniejsze, weryfikacja nie przeszła albo potrzebna jest inna zdolność. Przekazuj stan strukturalny, a nie cały surowy zapis rozmowy. Następny model potrzebuje pierwotnego celu, sprawdzonych faktów, wyników narzędzi, informacji o wcześniejszych błędach i pozostałego budżetu.

Fallback obsługuje niedostępność albo znany rodzaj awarii. Kolejność musi być ustalona z góry. Przykład: ponów ten sam model tylko po przejściowym błędzie sieci; napraw wynik po naruszeniu schematu; użyj silniejszego modelu po nieudanej kontroli faktów; zmień dostawcę podczas awarii; przekaż człowiekowi działanie nieodwracalne. Nieskończony łańcuch ponowień nie jest odpornością. Jest ukrytym rachunkiem.

Każde przejście musi zachować politykę bezpieczeństwa. Model zapasowy nie może dostać danych, których model podstawowy nie mógł otrzymać z powodu wymogów lokalizacji. Fallback nie może zamienić reguły „wymaga zatwierdzenia” na „spróbuj automatycznie”.

Evale i koszt udanego zadania

Cena za milion tokenów to informacja zakupowa, a nie metryka systemu. Użyteczna miara to koszt skutecznie ukończonego zadania:

koszt wszystkich przebiegów + retrieval + narzędzia + weryfikacja + poprawki ludzi
──────────────────────────────────────────────────────────────────────────────
liczba zadań, które spełniły zdefiniowane kryterium sukcesu

Zestaw evali powinien obejmować prawdziwe klasy zadań, przypadki brzegowe, długie wejścia, różne języki i scenariusze bezpieczeństwa. Dla każdej ścieżki śledź skuteczność, czas odpowiedzi, liczbę prób, częstość przekazań, interwencje ludzi i typy błędów. Porównuj orkiestrator z punktem odniesienia opartym na jednym modelu. Router optymalizowany wyłącznie pod koszt nauczy się tanio zawodzić; optymalizowany tylko pod średnią jakość wyśle wszystko do modelu frontier.

Zmieniaj jedną decyzję routingową naraz i odtwarzaj ten sam zestaw evali. Produkcję obserwuj oddzielnie, ponieważ zmiana struktury żądań może unieważnić starą politykę. Publiczne benchmarki nie są dowodem dla twojego produktu. Liczy się wynik na twoich zadaniach i według twojej definicji sukcesu.

Bezpieczeństwo i lokalizacja danych

Router jest elementem wrażliwym z punktu widzenia bezpieczeństwa. Widzi metadane, na podstawie których decyduje, dokąd trafią dane. Klasyfikacja danych musi więc nastąpić przed wyborem dostawcy i być wymuszona przez warstwę polityk, a nie tylko zapisana w prompcie.

Dla każdego modelu zapisuj dozwolone regiony, zasady retencji, politykę wykorzystania danych do treningu, obsługiwane szyfrowanie, możliwości audytu i dozwolone narzędzia. Dane osobowe i sekrety minimalizuj lub usuwaj przed wywołaniem modelu. Logi nie mogą ponownie tworzyć wycieku przez zapis całego promptu. Dane dostępowe narzędzi trzymaj poza kontekstem modelu, a każde narzędzie autoryzuj dla konkretnego przebiegu.

Model lokalny nie jest automatycznie bezpieczny, a chmurowy nie jest automatycznie niebezpieczny. Liczy się cały przepływ: gdzie odbywa się inferencja, dokąd trafia telemetria, co pozostaje w pamięci podręcznej, kto widzi logi i czy działania da się audytować.

Typowe awarie

Routing według przeczucia: „trudne” zadania nie mają definicji. Naprawa: taksonomia zadań, zestaw evali i wersjonowana reguła.
Model frontier do wszystkiego: zakłada się wartość jakości premium również tam, gdzie nic nie wnosi. Naprawa: tańszy punkt odniesienia i pomiar kosztu udanego zadania.
Najtańszy model do wszystkiego: oszczędność znika w ponowieniach i poprawkach ludzi. Naprawa: licz cały przebieg, nie pierwsze wywołanie API.
Cichy fallback: incydent wygląda jak sukces. Naprawa: zapisuj powód, ścieżkę i stan końcowy oraz pokazuj tryb ograniczonego działania.
Utrata stanu przy przekazaniu: drugi model powtarza pracę lub wierzy w niesprawdzone twierdzenie. Naprawa: strukturalny pakiet przekazania.
Model ocenia sam siebie: ta sama ślepa plamka przechodzi dwa razy. Naprawa: kontrola deterministyczna, niezależny oceniający albo człowiek, zależnie od ryzyka.
Abstrakcja jest właścicielem workflow: produkt zależy od wizualnego Agent Buildera, jego pamięci i zastrzeżonych definicji narzędzi. Gdy usługa znika, znika też droga wyjścia. Naprawa: stan, prompty, schematy, evale i reguły trzymaj we własnym wersjonowanym formacie.
Zmiana dostawcy bez evali: zgodny JSON nie oznacza zgodnego zachowania. Naprawa: przed zmianą odtwórz reprezentatywne zadania.

Przykład: obsługa zgłoszeń klientów

Firma odbiera e-maile do wsparcia w kilku językach. System ma przypisać kategorię, znaleźć odpowiedni fragment dokumentacji i przygotować projekt odpowiedzi. Zmiana umowy lub zwrot pieniędzy wymagają udziału człowieka.

Kod usuwa podpisy, wykrywa załączniki i oznacza dane osobowe.
Mały model lokalny klasyfikuje język, temat i ryzyko w stałym schemacie JSON.
Brama polityk nie pozwala wysłać wrażliwych załączników do zewnętrznego API. Dla zwykłego pytania dopuszcza zatwierdzonego dostawcę chmurowego.
Tańszy model otrzymuje znalezione artykuły i tworzy projekt odpowiedzi z cytowaniami.
Weryfikator sprawdza, czy cytowane dokumenty istnieją, odpowiedź nie zawiera zakazanej obietnicy, a każde twierdzenie o produkcie ma oparcie w źródle.
Błąd schematu dostaje jedną ukierunkowaną próbę naprawy. Przy niezgodności merytorycznej silniejszy model otrzymuje pierwotny cel, źródła i wynik kontroli. Sprawa wysokiego ryzyka trafia od razu do człowieka.
System zapisuje wybraną ścieżkę, powód, pełny koszt oraz to, czy człowiek zaakceptował, poprawił czy odrzucił projekt.

Po kilku cyklach evali zespół może odkryć, że tańszy model bezpiecznie obsługuje rutynowe pytania, ale przy niejasnych reklamacjach często wymaga poprawki. Router eskaluje więc nie według długości e-maila, lecz na podstawie połączenia tematu, ryzyka i wyniku retrieval. To orkiestracja oparta na dowodach, a nie hierarchii marek.

Źródła

Building effective agents (Anthropic) - praktyczne rozróżnienie prostych workflow i systemów agentowych oraz mocny argument za najprostszym działającym projektem.
RouteLLM (LMSYS) - badanie routerów, które zależnie od zapytania wybierają między silniejszą i tańszą ścieżką.
FrugalGPT (Stanford University) - wczesna praca o kaskadach modeli, budżetach i optymalizacji jakości względem kosztu.
NIST AI Risk Management Framework - ramy mapowania, mierzenia i zarządzania ryzykiem AI, w tym odpowiedzialnością operacyjną.
OWASP Top 10 for LLM Applications - katalog ataków i ryzyk operacyjnych, które muszą uwzględniać routery, narzędzia i fallbacki.
OpenAI Evals - otwarte narzędzie i przykłady opisywania zadań ewaluacyjnych oraz porównywania zachowania modeli.

Co zapamiętać

Orkiestracja nie jest kolekcją modeli. To warstwa sterująca decyzjami, przekazywaniem zadań, weryfikacją i zatrzymaniem. Zacznij od jednego modelu i mierzalnego punktu odniesienia. Routing opieraj na dowodach, nie na prestiżu marki. Licz koszt udanego zadania, uwzględniając ponowienia i pracę ludzi. Politykę bezpieczeństwa egzekwuj przed modelem i zachowuj ją we fallbackach. Stan, evale i kontrakty narzędzi trzymaj w formacie, który kontrolujesz. Dobra orkiestracja jest nudna, audytowalna i wymienna.