Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Приложения могут использовать модели из разных служб вывода для различных поворотов беседы. Например, приложение может изменять модели на основе выбора пользователей, возможностей модели, доступности или стоимости.
Изменение назначения для следующего запроса — это только одна часть маршрутизации. Новой модели также требуется предыдущий разговор, чтобы продолжить его в том же контексте. Может ли он получать этот контекст, зависит от того, где хранится журнал чата и кто его управляет.
Хранилище журнала чата определяет переносимость
Сервисы инференса поддерживают различные подходы к состоянию диалога. Некоторые API ожидают, что вызывающий объект предоставляет соответствующий журнал сообщений с каждым запросом. Другие API сохраняют разговор в сервисе инференса и позволяют вызывающей стороне продолжить его, передав идентификатор.
| Модель истории | Где хранятся сообщения | Что отправляет вызывающая сторона |
|---|---|---|
| Управляемый вызывающим абонентом | В управляемом приложением памяти или устойчивом хранилище | Соответствующий журнал сообщений и все новые сообщения с каждым запросом |
| Управляемый службой логического вывода | В хранилище, управляемом службой вывода | Идентификатор беседы или ответа для конкретной службы, а также любые новые сообщения. |
Некоторые службы вывода поддерживают оба подхода через различные API или параметры. Например, в ответах OpenAI есть параметр store, который можно установить в значение true для истории чата, управляемой службой инференса, и в значение false — для истории, управляемой вызывающей стороной.
История, управляемая вызывающей стороной, поддерживает маршрутизацию
Когда вызывающая сторона управляет историей, она имеет доступ к сообщениям из предыдущих шагов диалога. Маршрутизатор может выбрать другую модель или сервис инференса, а вызывающая сторона может отправить эти сообщения в следующем запросе.
История не обязана оставаться в памяти процесса. Он может поступать из устойчивого хранилища, принадлежащее приложению, если приложение может загрузить его и отправить его в выбранную службу. Конечная точка назначения также должна поддерживать содержимое сообщения и функции, использовавшиеся ранее в беседе.
Маршрутизация с ограничениями истории, управляемыми сервисом инференса
Когда служба вывода управляет историей, это источник истины для беседы. Вызывающая сторона обычно хранит непрозрачный идентификатор вместо самих сообщений.
Этот идентификатор относится к состоянию, удерживаемом исходной службой. Доступ также может зависеть от учетной записи или проекта, конечной точки и учетных данных, используемых для создания беседы. Клиент другой службы не может использовать идентификатор для получения сообщений. Другой клиент для того же сервиса также может не иметь доступа к беседе, если использует другую область действия.
Сервис может поддерживать смену моделей в одном из своих сохранённых диалогов. Это поведение характерно именно для этой службы, а не для переносимой маршрутизации. Общий маршрутизатор не может передать беседу на стороне службы другому поставщику без первого извлечения или восстановления сообщений.
| Сценарий маршрутизации | Модель истории | Result |
|---|---|---|
| Переключайтесь между моделями одного провайдера | Управляемый вызывающим абонентом | Вызывающая сторона может повторно передать историю новой модели. Новая модель должна поддерживать типы сообщений и контента, используемые в предыдущих поворотах. |
| Переключение между различными поставщиками вывода | Управляемый вызывающим абонентом | Вызывающая сторона может повторно передать историю новому провайдеру. Новый поставщик должен принимать роли, типы контента, сообщения с вызовом инструментов и сообщения результатов инструментов, используемые в предыдущих поворотах. |
| Изменение моделей в одной беседе на стороне службы | Управляемый сервисом вывода | Переключение работает только в том случае, если сервис инференса позволяет продолжить существующий диалог уже с новой моделью. Клиент маршрутизации не может включить это поведение. |
| Переключение на другую службу вывода | Управляемый службой логического вывода | Новая служба не может получить доступ к идентификатору беседы в исходной службе. Извлеките или восстановите сообщения и запустите новый маршрут с историей, управляемой вызывающей стороной. |
Дополнительные сведения об этих моделях хранения см. в разделе "Хранилище".
Как Agent Framework реализует маршрутизацию среды выполнения
Agent Framework может предоставить историю, управляемую вызывающей стороной, необходимую для переносимой маршрутизации вызовов. В этом шаблоне маршрутизации провайдер истории чата является единым источником достоверных данных о разговоре. Он может хранить сообщения в сеансе агента или в хранилище, принадлежащее приложению.
В платформе Agent Framework история, управляемая вызывающей стороной, включает состояние локального сеанса и настраиваемое хранилище истории чата. История, управляемая сервисом инференса, соответствует хранилищу, управляемому сервисом.
Для ChatClientAgent клиент чата для маршрутизации находится на уровне чат-клиента в конвейере агента. Агент и его сеанс остаются неизменными, а клиент маршрутизации выбирает один из нескольких именованных IChatClient экземпляров для каждого запроса.
Маршрутивный запрос следует следующей последовательности:
- Поставщик журнала чата загружает журнал бесед.
- Агент объединяет историю с входными данными для текущего шага.
- Клиент маршрутизации выбирает активный клиент чата для сеанса.
- Выбранный клиент получает полный запрос.
- Поставщик истории чата сохраняет новые сообщения после запуска.
Так как выбранный клиент получает журнал, загруженный поставщиком, приложение может изменять маршруты без перестроения беседы вручную.
SDK .NET предоставляет экспериментальный RoutePersistingRoutingChatClient. Задайте начальный маршрут с помощью RoutePersistingRoutingChatClientOptions.DefaultRoute, проверьте маршрут сеанса с помощью GetActiveRoute и измените его с помощью SetActiveRoute. Если вы не задаете маршрут по умолчанию, клиент использует первый маршрут, предоставленный при построении.
В Microsoft.Extensions.AI имеются и другие клиенты маршрутизации, поддерживающие дополнительные стратегии маршрутизации.
См. пример маршрутизации с несколькими моделями для полной реализации C#.
Important
Каждый чат-клиент, зарегистрированный как маршрут, должен использовать историю, управляемую вызывающей стороной и предоставляемую поставщиком истории чата. Поставщик может хранить эту историю в сеансе или в хранилище приложения. Не регистрируйте маршрут, использующий журнал бесед, управляемый службой вывода.
в настоящее время поддержка Python недоступна.
Поддержка Go в настоящее время недоступна.