Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Las aplicaciones pueden usar modelos de diferentes servicios de inferencia para distintos turnos de una conversación. Por ejemplo, una aplicación podría cambiar los modelos en función de la elección del usuario, las funcionalidades del modelo, la disponibilidad o el costo.
Cambiar el destino de la siguiente solicitud es solo una parte del enrutamiento. El nuevo modelo también necesita la conversación anterior para continuar con el mismo contexto. Si puede recibir ese contexto depende de dónde se almacene el historial de chat y de quién lo controla.
El almacenamiento del historial de chat determina la portabilidad
Los servicios de inferencia admiten diferentes enfoques para el estado de la conversación. Algunas API esperan que el autor de la llamada proporcione el historial de mensajes pertinente con cada solicitud. Otras API almacenan la conversación en el servicio de inferencia y permiten que el autor de la llamada lo continúe pasando un identificador.
| Modelo del historial | Dónde se almacenan los mensajes | Lo que envía el autor de la llamada |
|---|---|---|
| Administrado por el autor de la llamada | En memoria controlada por la aplicación o almacenamiento duradero | El historial de mensajes pertinente más los mensajes nuevos con cada solicitud |
| Administrado por el servicio de inferencia | En el almacenamiento controlado por el servicio de inferencia | Un identificador de conversación o de respuesta específico de un servicio, además de los mensajes nuevos. |
Algunos servicios de inferencia admiten ambos enfoques a través de diferentes API o opciones. Por ejemplo, OpenAI Responses tiene el parámetro store, que puede establecer en true para el historial de chat gestionado por el servicio de inferencia, y en false para el gestionado por el llamador.
El historial administrado por el autor de la llamada admite el enrutamiento
Cuando el autor de la llamada administra el historial, tiene acceso a los mensajes de turnos anteriores. Un enrutador puede seleccionar otro modelo o servicio de inferencia, y el autor de la llamada puede enviar esos mensajes con la siguiente solicitud.
El historial no tiene que permanecer en la memoria del proceso. Puede proceder del almacenamiento duradero propiedad de la aplicación, siempre que la aplicación pueda cargarla y enviarlo al servicio seleccionado. El destino también debe admitir el contenido del mensaje y las características usadas anteriormente en la conversación.
El historial administrado por el servicio de inferencia limita el enrutamiento
Cuando un servicio de inferencia administra el historial, es la fuente de la verdad para la conversación. El autor de la llamada normalmente conserva un identificador opaco en lugar de los propios mensajes.
Ese identificador hace referencia al estado mantenido por el servicio de origen. El acceso también puede depender de la cuenta o proyecto, el punto de conexión y las credenciales que se usan para crear la conversación. Un cliente para otro servicio no puede usar el identificador para recuperar los mensajes. Otro cliente para el mismo servicio también podría no poder acceder a la conversación si usa un ámbito diferente.
Un servicio podría admitir el cambio de modelos dentro de una de sus propias conversaciones almacenadas. Ese comportamiento es específico del servicio y no se trata de un enrutamiento portátil. Un enrutador general no puede transferir la conversación del lado del servicio a otro proveedor sin recuperar ni reconstruir primero los mensajes.
| Escenario de enrutamiento | Modelo del historial | Result |
|---|---|---|
| Cambiar entre modelos de un proveedor | Administrado por el autor de la llamada | El autor de la llamada puede reproducir el historial en el nuevo modelo. El nuevo modelo debe admitir los tipos de mensaje y contenido usados en turnos anteriores. |
| Cambiar entre distintos proveedores de inferencia | Administrado por el autor de la llamada | El autor de la llamada puede reproducir el historial en el nuevo proveedor. El nuevo proveedor debe aceptar los roles, los tipos de contenido, los mensajes de llamada a herramientas y los mensajes de resultados de herramientas usados en turnos anteriores. |
| Cambiar modelos dentro de una conversación del lado del servicio | Administrado por el servicio de inferencia | El interruptor solo funciona si el servicio de inferencia permite continuar la conversación existente con el nuevo modelo. El cliente de enrutamiento no puede habilitar este comportamiento. |
| Cambiar a un servicio de inferencia diferente | Administrado por el servicio de inferencia | El nuevo servicio no puede acceder al identificador de conversación del servicio original. Recupere o reconstruya los mensajes e inicie la nueva ruta con el historial administrado por el autor de la llamada. |
Para obtener más información sobre estos modelos de almacenamiento, consulte Almacenamiento.
Cómo implementa Agent Framework el enrutamiento en tiempo de ejecución
Agent Framework puede proporcionar el historial gestionado por quien realiza la llamada necesario para el enrutamiento portable. En este patrón de enrutamiento, un proveedor de historial de chat es el origen de la verdad para la conversación. Puede almacenar mensajes en la sesión del agente o en el almacenamiento propiedad de la aplicación.
En Agent Framework, el historial administrado por el autor de la llamada incluye el estado de sesión local y el almacenamiento del historial de chat personalizado. El historial administrado por inferencia-servicio corresponde al almacenamiento administrado por el servicio.
Para un ChatClientAgent, un cliente de chat de enrutamiento se encuentra en la capa de cliente de chat del flujo de trabajo del agente. El agente y su sesión siguen siendo los mismos mientras que el cliente de enrutamiento selecciona una de varias instancias con nombre IChatClient para cada solicitud.
Una solicitud encaminada sigue esta secuencia:
- El proveedor del historial de chat carga el historial de conversaciones.
- El agente combina el historial con los datos de entrada del turno actual.
- El cliente de enrutamiento selecciona el cliente de chat activo para la sesión.
- El cliente seleccionado recibe la solicitud completa.
- El proveedor del historial de chat almacena los nuevos mensajes después de la ejecución.
Dado que el cliente seleccionado recibe el historial cargado por el proveedor, la aplicación puede cambiar las rutas sin volver a generar manualmente la conversación.
El SDK de .NET proporciona el elemento experimental RoutePersistingRoutingChatClient. Establezca la ruta inicial con RoutePersistingRoutingChatClientOptions.DefaultRoute, inspeccione la ruta de una sesión con GetActiveRoutey cámbiela por SetActiveRoute. Si no establece una ruta predeterminada, el cliente usa la primera ruta proporcionada en la construcción.
Existen más clientes de enrutamiento en Microsoft.Extensions.AI que permiten estrategias de enrutamiento adicionales.
Consulte el ejemplo de enrutamiento de varios modelos para obtener una implementación completa de C#.
Importante
Cada cliente de chat registrado como una ruta debe usar el historial administrado por el autor de la llamada proporcionado por un proveedor de historial de chat. El proveedor puede almacenar ese historial en la sesión o en el almacenamiento propiedad de la aplicación. No registre una ruta que use el historial de conversaciones administradas por inference-service.
La compatibilidad con Python no está disponible actualmente.
La compatibilidad con Go no está disponible actualmente.