Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Aplikacje mogą używać modeli z różnych usług wnioskowania do różnych kolei konwersacji. Na przykład aplikacja może zmieniać modele na podstawie wyboru użytkownika, możliwości modelu, dostępności lub kosztów.
Zmiana miejsca docelowego na następne żądanie jest tylko jedną częścią routingu. Nowy model również potrzebuje wcześniejszej rozmowy, aby zachować ten sam kontekst. To, czy może odbierać ten kontekst, zależy od tego, gdzie jest przechowywana historia czatu i kto go kontroluje.
Przechowywanie historii czatów decyduje o przenośności
Usługi inferencyjne obsługują różne podejścia do zarządzania stanem konwersacji. Niektóre interfejsy API oczekują, że obiekt wywołujący udostępni odpowiednią historię komunikatów przy każdym żądaniu. Inne interfejsy API przechowują rozmowę w usłudze wnioskowania i umożliwiają wywołującemu jej kontynuowanie przez przekazanie identyfikatora.
| Model historii | Gdzie są przechowywane komunikaty | Co wysyła wywołujący |
|---|---|---|
| Zarządzane przez obiekt wywołujący | W pamięci kontrolowanej przez aplikację lub w magazynie trwałym | Odpowiednia historia komunikatów oraz wszelkie nowe komunikaty z każdym żądaniem |
| zarządzane przez usługę inferencji | W pamięci masowej zarządzanej przez usługę inferencyjną | Identyfikator konwersacji lub odpowiedzi specyficzny dla usługi, a także wszelkie nowe wiadomości. |
Niektóre usługi wnioskowania obsługują oba podejścia za pomocą różnych interfejsów API lub opcji. Na przykład w odpowiedziach OpenAI występuje parametr store, który można ustawić na true dla historii czatu zarządzanej przez usługę wnioskowania oraz na false dla historii zarządzanej przez wywołującego.
Historia zarządzana przez wywołującego obsługuje trasowanie
Gdy wywołujący zarządza historią, ma dostęp do wiadomości z poprzednich tur. Router może wybrać inny model lub usługę wnioskowania, a obiekt wywołujący może wysłać te komunikaty przy użyciu następnego żądania.
Historia nie musi pozostawać w pamięci procesowej. Może pochodzić z magazynu trwałego należącego do aplikacji, o ile aplikacja może ją załadować i wysłać do wybranej usługi. Miejsce docelowe musi również obsługiwać zawartość i funkcje wiadomości używane wcześniej w konwersacji.
Kierowanie limitami historii zarządzanymi przez usługę wnioskowania
Gdy usługa inferencyjna zarządza historią, stanowi źródło prawdy w tej konwersacji. Wywołujący zwykle przechowuje nieprzezroczysty identyfikator zamiast samych wiadomości.
Ten identyfikator odwołuje się do stanu przechowywanego przez usługę źródłową. Dostęp może również zależeć od konta lub projektu, punktu końcowego i poświadczeń używanych do tworzenia konwersacji. Klient innej usługi nie może użyć identyfikatora do pobrania komunikatów. Inny klient tej samej usługi również może nie mieć dostępu do rozmowy, jeśli korzysta z innego zakresu.
Usługa może obsługiwać zmienianie modeli w ramach jednej z własnych przechowywanych konwersacji. To zachowanie jest charakterystyczne dla tej usługi i nie jest routingiem przenośnym. Router ogólny nie może przenieść konwersacji po stronie usługi do innego dostawcy bez uprzedniego pobierania ani rekonstruowania wiadomości.
| Scenariusz routingu | Model historii | Result |
|---|---|---|
| Przełączanie między modelami z jednego dostawcy | Zarządzane przez wywołującego | Wywołujący może odtworzyć historię w nowym modelu. Nowy model musi obsługiwać typy wiadomości i treści używane we wcześniejszych turach. |
| Przełączanie między różnymi dostawcami wnioskowania | Zarządzane przez wywołującego | Wywołujący może odtworzyć historię dla nowego dostawcy. Nowy dostawca musi akceptować role, typy treści, komunikaty wywołań narzędzi oraz komunikaty z wynikami narzędzi używane we wcześniejszych turach. |
| Zmienianie modeli w ramach jednej konwersacji po stronie usługi | zarządzane przez usługę inferencji | Przełącznik działa tylko wtedy, gdy usługa wnioskowania umożliwia kontynuowanie istniejącej konwersacji z nowym modelem. Klient routingu nie może włączyć tego zachowania. |
| Przełączanie do innej usługi wnioskowania | zarządzane przez usługę inferencji | Nowa usługa nie może uzyskać dostępu do identyfikatora konwersacji oryginalnej usługi. Pobierz lub zrekonstruuj komunikaty i rozpocznij nową trasę za pomocą historii zarządzanej przez obiekt wywołujący. |
Aby uzyskać więcej informacji o tych modelach pamięci masowej, zobacz Pamięć masowa.
Jak platforma Agent Framework implementuje routing środowiska uruchomieniowego
Platforma agentowa może zapewnić historię zarządzaną przez wywołującego, wymaganą do przenośnego routingu. W tym wzorcu routingu dostawca historii czatów jest źródłem prawdy dla konwersacji. Może przechowywać komunikaty w sesji agenta lub w magazynie należącym do aplikacji.
W strukturze Agent Framework historia zarządzana przez wywołującego obejmuje lokalny stan sesji i niestandardowy magazyn historii czatu. Historia zarządzana przez usługę inferencyjną odpowiada pamięci masowej zarządzanej przez usługę.
W przypadku ChatClientAgent, klient routowania czatu znajduje się w warstwie chat-client w potoku agenta. Agent i jego sesja pozostają takie same, podczas gdy klient routingu wybiera jedno z kilku nazwanych IChatClient wystąpień dla każdego żądania.
Trasowane żądanie przebiega zgodnie z następującą sekwencją:
- Dostawca historii czatów ładuje historię konwersacji.
- Agent łączy historię z danymi wejściowymi w bieżącej turze.
- Klient routingu wybiera aktywnego klienta czatu dla sesji.
- Wybrany klient otrzymuje pełne żądanie.
- Dostawca historii czatów przechowuje nowe wiadomości po uruchomieniu.
Ponieważ wybrany klient odbiera historię załadowaną przez dostawcę, aplikacja może zmieniać trasy bez ręcznego ponownego kompilowania konwersacji.
Zestaw SDK platformy .NET udostępnia eksperymentalny element RoutePersistingRoutingChatClient. Ustaw początkową trasę za pomocą RoutePersistingRoutingChatClientOptions.DefaultRoutepolecenia , sprawdź trasę sesji za pomocą GetActiveRoutepolecenia i zmień ją na SetActiveRoute. Jeśli nie ustawisz trasy domyślnej, klient używa pierwszej trasy podanej w budowie.
W Microsoft.Extensions.AI dostępnych jest więcej klientów routingu, którzy umożliwiają stosowanie dodatkowych strategii routingu.
Zobacz przykład routingu wielomodelowego , aby uzyskać pełną implementację języka C#.
Ważna
Każdy klient czatu zarejestrowany jako ścieżka musi używać historii zarządzanej przez wywołującego, dostarczanej przez dostawcę historii czatu. Dostawca może przechowywać tę historię w sesji lub w magazynie danych aplikacji. Nie rejestruj trasy korzystającej z historii konwersacji zarządzanej przez usługę wnioskowania.
Obsługa języka Python nie jest obecnie dostępna.
Obsługa języka Go jest obecnie niedostępna.