Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Anwendungen können Modelle aus unterschiedlichen Ableitungsdiensten für verschiedene Wendungen einer Unterhaltung verwenden. Beispielsweise kann eine Anwendung Modelle basierend auf Benutzerauswahl, Modellfunktionen, Verfügbarkeit oder Kosten ändern.
Das Ändern des Ziels für die nächste Anforderung ist nur ein Teil des Routings. Das neue Modell benötigt auch die vorherige Unterhaltung, um mit demselben Kontext fortzufahren. Ob dieser Kontext empfangen kann, hängt davon ab, wo der Chatverlauf gespeichert ist und wer ihn steuert.
Der Speicher des Chatverlaufs bestimmt die Portabilität
Inference-Dienste unterstützen unterschiedliche Ansätze für den Konversationsstatus. Einige APIs erwarten, dass der Aufrufer den relevanten Nachrichtenverlauf mit jeder Anforderung bereitstellt. Andere APIs speichern die Unterhaltung im Rückschlussdienst und lassen den Aufrufer fortfahren, indem er einen Bezeichner übergibt.
| Verlaufsmodell | Wo die Nachrichten gespeichert werden | Was der Anrufer sendet |
|---|---|---|
| Vom Anrufer verwaltet | Im anwendungsgesteuerten Speicher oder dauerhaften Speicher | Der relevante Nachrichtenverlauf sowie alle neuen Nachrichten mit jeder Anforderung |
| Inferenzdienst-verwaltet | In einem vom Inferenzdienst gesteuerten Speicher | Eine dienstspezifische Unterhaltungs- oder Antwort-ID sowie alle neuen Nachrichten. |
Einige Inference-Dienste unterstützen beide Ansätze über verschiedene APIs oder Optionen. Beispielsweise verfügt OpenAI Responses über den Parameter store, den Sie für den inferenzdienstverwalteten Chatverlauf auf false und für den vom Aufrufer verwalteten Chatverlauf auf true festlegen können.
Vom Anrufer verwalteter Verlauf unterstützt Routing
Wenn der Aufrufer den Verlauf verwaltet, hat er Zugriff auf die Nachrichten aus früheren Interaktionen. Ein Router kann ein anderes Modell oder einen Rückschlussdienst auswählen, und der Anrufer kann diese Nachrichten mit der nächsten Anforderung senden.
Der Verlauf muss nicht im Prozessspeicher bleiben. Sie kann aus dem anwendungseigenen dauerhaften Speicher stammen, solange die Anwendung sie laden und an den ausgewählten Dienst senden kann. Das Ziel muss auch den Nachrichteninhalt und die Funktionen unterstützen, die zuvor in der Unterhaltung verwendet wurden.
Routing für vom Inferenzdienst verwaltete Verlaufsgrenzen
Wenn ein Rückschlussdienst die Geschichte verwaltet, ist es die Quelle der Wahrheit für die Unterhaltung. Der Aufrufer behält in der Regel einen undurchsichtigen Bezeichner anstelle der Nachrichten selbst bei.
Dieser Bezeichner verweist auf den Zustand, der vom ursprünglichen Dienst verwaltet wird. Der Zugriff kann auch vom Konto oder Projekt, Endpunkt und den Anmeldeinformationen abhängen, die zum Erstellen der Konversation verwendet wurden. Ein Client für einen anderen Dienst kann den Bezeichner nicht zum Abrufen der Nachrichten verwenden. Ein anderer Client für denselben Dienst kann möglicherweise ebenfalls nicht auf die Konversation zugreifen, wenn er einen anderen Scope verwendet.
Ein Dienst unterstützt möglicherweise das Ändern von Modellen innerhalb einer eigenen gespeicherten Unterhaltung. Dieses Verhalten ist spezifisch für den Dienst und ist kein portables Routing. Ein allgemeiner Router kann die dienstseitige Unterhaltung nicht an einen anderen Anbieter übertragen, ohne zuerst die Nachrichten abzurufen oder zu rekonstruieren.
| Routing-Szenario | Historienmodell | Result |
|---|---|---|
| Wechseln zwischen Modellen von einem Anbieter | Vom Anrufer verwaltet | Der Aufrufer kann den Verlauf für das neue Modell erneut abspielen. Das neue Modell muss die Nachrichten- und Inhaltstypen unterstützen, die in früheren Versionen verwendet werden. |
| Wechseln zwischen verschiedenen Ableitungsanbietern | vom Anrufer verwaltet | Der Anrufer kann den Verlauf an den neuen Anbieter wiedergeben. Der neue Anbieter muss die in früheren Gesprächsrunden verwendeten Rollen, Inhaltstypen, Tool-Call-Nachrichten und Tool-Ergebnisnachrichten akzeptieren. |
| Modelle innerhalb einer serverseitigen Konversation ändern | Inferenzdienst-verwaltet | Der Schalter funktioniert nur, wenn der Inferenzdienst es zulässt, die bestehende Konversation mit dem neuen Modell fortzusetzen. Der Routingclient kann dieses Verhalten nicht aktivieren. |
| Wechseln zu einem anderen Rückschlussdienst | Inferenzdienst-verwaltet | Der neue Dienst kann nicht auf die Konversations-ID des ursprünglichen Dienstes zugreifen. Rufen Sie die Nachrichten ab oder rekonstruieren Sie sie, und starten Sie die neue Route mit dem vom Anrufer verwalteten Verlauf. |
Weitere Informationen zu diesen Speichermodellen finden Sie unter "Speicher".
Wie das Agent-Framework Laufzeitrouting implementiert
Agent Framework kann den anruferverwalteten Verlauf bereitstellen, der für das portierbare Routing erforderlich ist. In diesem Routingmuster ist ein Chatverlaufsanbieter die Source of Truth für die Unterhaltung. Sie kann Nachrichten in der Agentsitzung oder im anwendungseigenen Speicher speichern.
Im Agent Framework umfasst der vom Anrufer verwaltete Verlauf den lokalen Sitzungszustand und den benutzerdefinierten Chatverlaufsspeicher. Der vom Inferenzdienst verwaltete Verlauf entspricht dem vom Dienst verwalteten Speicher.
Bei einem ChatClientAgent befindet sich ein Routing-Chatclient in der Chatclient-Schicht der Agent-Pipeline. Der Agent und seine Sitzung bleiben gleich, während der Routingclient eine von mehreren benannten IChatClient Instanzen für jede Anforderung auswählt.
Eine routingfähige Anforderung folgt dieser Sequenz:
- Der Chatverlaufsanbieter lädt den Konversationsverlauf.
- Der Agent kombiniert den Verlauf mit der Eingabe für die aktuelle Drehung.
- Der Routingclient wählt den aktiven Chatclient für die Sitzung aus.
- Der ausgewählte Client empfängt die vollständige Anforderung.
- Der Chatverlaufsanbieter speichert die neuen Nachrichten nach der Ausführung.
Da der ausgewählte Client den vom Anbieter geladenen Verlauf empfängt, kann die Anwendung Routen ändern, ohne die Unterhaltung manuell neu zu erstellen.
Das .NET SDK stellt das experimentelle RoutePersistingRoutingChatClient bereit. Legen Sie die erste Route mit RoutePersistingRoutingChatClientOptions.DefaultRoute, überprüfen Sie die Route einer Sitzung mit GetActiveRoute, und ändern Sie sie mit SetActiveRoute. Wenn Sie keine Standardroute festlegen, verwendet der Client die erste im Bau bereitgestellte Route.
In Microsoft.Extensions.AI gibt es zusätzliche Routing-Clients, die zusätzliche Routing-Strategien ermöglichen.
Im Multimodellroutingbeispiel finden Sie eine vollständige C#-Implementierung.
Important
Jeder als Route registrierte Chatclient muss den anruferverwalteten Verlauf verwenden, der von einem Chatverlaufsanbieter bereitgestellt wird. Der Anbieter kann diesen Verlauf in der Sitzung oder im anwendungseigenen Speicher speichern. Registrieren Sie keine Route, die den vom Inferenzdienst verwalteten Konversationsverlauf verwendet.
Python Support ist derzeit nicht verfügbar.
Die Unterstützung für Go ist derzeit nicht verfügbar.