애플리케이션은 서로 다른 대화 턴에 대해 서로 다른 유추 서비스의 모델을 사용할 수 있습니다. 예를 들어 애플리케이션은 사용자 선택, 모델 기능, 가용성 또는 비용에 따라 모델을 변경할 수 있습니다.
다음 요청의 대상을 변경하는 것은 라우팅의 한 부분일 뿐입니다. 또한 새 모델은 동일한 컨텍스트를 계속 진행하기 위해 이전 대화가 필요합니다. 해당 컨텍스트를 받을 수 있는지 여부는 채팅 기록이 저장되는 위치와 해당 컨텍스트를 제어하는 사람에 따라 달라집니다.
채팅 기록 스토리지가 이식성을 결정합니다.
유추 서비스는 대화 상태에 대한 다양한 접근 방식을 지원합니다. 일부 API는 호출자가 모든 요청에 관련 메시지 기록을 제공할 것으로 예상합니다. 다른 API는 유추 서비스에 대화를 저장하고 호출자가 식별자를 전달하여 대화를 계속하도록 합니다.
| 기록 모델 | 메시지가 저장되는 위치 | 호출자가 보내는 내용 |
|---|---|---|
| 호출자 관리형 | 애플리케이션 제어 메모리 또는 지속성 스토리지에서 | 관련 메시지 기록 및 각 요청의 새 메시지 |
| 추론 서비스 관리 | 유추 서비스에 의해 제어되는 스토리지에서 | 서비스별 대화 또는 응답 식별자와 새 메시지 |
일부 유추 서비스는 서로 다른 API 또는 옵션을 통해 두 가지 방법을 모두 지원합니다. 예를 들어 OpenAI Responses에는 store 매개 변수가 있으며, 추론 서비스에서 관리하는 채팅 기록에는 이를 false로, 호출자가 관리하는 경우에는 true로 설정할 수 있습니다.
호출자 관리 기록에서 라우팅을 지원합니다.
호출자가 기록을 관리하는 경우 이전 턴의 메시지에 액세스할 수 있습니다. 라우터는 다른 모델 또는 유추 서비스를 선택할 수 있으며 호출자는 다음 요청과 함께 해당 메시지를 보낼 수 있습니다.
기록은 프로세스 메모리에 남아 있을 필요가 없습니다. 애플리케이션이 로드하여 선택한 서비스로 보낼 수 있는 한 애플리케이션 소유의 지속성 스토리지에서 가져올 수 있습니다. 또한 대상은 대화의 앞부분에서 사용된 메시지 콘텐츠 및 기능을 지원해야 합니다.
추론 서비스에서 관리하는 기록 한도 라우팅
추론 서비스가 대화 기록을 관리하는 경우, 해당 서비스가 그 대화에 대한 신뢰할 수 있는 기준이 됩니다. 호출자는 일반적으로 메시지 자체 대신 불투명 식별자를 유지합니다.
해당 식별자는 원래 서비스에서 보유한 상태를 나타냅니다. 액세스는 대화를 만드는 데 사용되는 계정 또는 프로젝트, 엔드포인트 및 자격 증명에 따라 달라질 수도 있습니다. 다른 서비스에 대한 클라이언트는 식별자를 사용하여 메시지를 검색할 수 없습니다. 동일한 서비스에 대한 다른 클라이언트가 다른 범위를 사용하는 경우 대화에 액세스할 수 없을 수도 있습니다.
서비스는 자체 저장된 대화 중 하나에서 모델 변경을 지원할 수 있습니다. 이 동작은 서비스와 관련이 있으며 이식 가능한 라우팅이 아닙니다. 일반 라우터는 메시지를 먼저 검색하거나 다시 구성하지 않고는 서비스 쪽 대화를 다른 공급자로 전송할 수 없습니다.
| 라우팅 시나리오 | 기록 모델 | Result |
|---|---|---|
| 한 공급자에서 모델 간 전환 | 호출자 관리형 | 호출자는 기록을 새 모델로 재생할 수 있습니다. 새 모델은 이전 턴에서 사용된 메시지 및 콘텐츠 형식을 지원해야 합니다. |
| 서로 다른 유추 공급자 간 전환 | 호출자 관리형 | 호출자는 기록을 새 공급자로 재생할 수 있습니다. 새 공급자는 이전 턴에서 사용된 역할, 콘텐츠 형식, 도구 호출 메시지 및 도구 결과 메시지를 수락해야 합니다. |
| 한 서비스 쪽 대화 내에서 모델 변경 | 추론 서비스 관리 | 스위치는 추론 서비스가 기존 대화가 새 모델로 계속 진행되도록 허용하는 경우에만 작동합니다. 라우팅 클라이언트는 이 동작을 사용하도록 설정할 수 없습니다. |
| 다른 유추 서비스로 전환 | 추론 서비스 관리 | 새 서비스는 원래 서비스의 대화 식별자에 액세스할 수 없습니다. 메시지를 검색하거나 재구성하고 호출자 관리 기록을 사용하여 새 경로를 시작합니다. |
이러한 스토리지 모델에 대한 자세한 내용은 Storage를 참조 하세요.
에이전트 프레임워크에서 런타임 라우팅을 구현하는 방법
에이전트 프레임워크는 이식 가능한 라우팅에 필요한 호출자 관리 기록을 제공할 수 있습니다. 이 라우팅 패턴에서는 채팅 기록 제공자가 대화에 대한 기준 정보원입니다. 에이전트 세션 또는 애플리케이션 소유 스토리지에 메시지를 저장할 수 있습니다.
에이전트 프레임워크에서 호출자 관리 기록에는 로컬 세션 상태 및 사용자 지정 채팅 기록 스토리지가 포함됩니다. 유추 서비스 관리 기록은 서비스 관리 스토리지에 해당합니다.
라우팅 채팅 클라이언트는 ChatClientAgent에이전트 파이프라인의 채팅-클라이언트 계층에 있습니다. 라우팅 클라이언트가 각 요청에 대해 여러 명명된 IChatClient 인스턴스 중 하나를 선택하는 동안 에이전트와 해당 세션은 동일하게 유지됩니다.
라우트된 요청은 다음 시퀀스를 따릅니다.
- 채팅 기록 공급자는 대화 기록을 로드합니다.
- 에이전트는 현재 턴에 대한 입력과 기록을 결합합니다.
- 라우팅 클라이언트는 세션에 대한 활성 채팅 클라이언트를 선택합니다.
- 선택한 클라이언트가 전체 요청을 받습니다.
- 채팅 기록 공급자는 실행 후 새 메시지를 저장합니다.
선택한 클라이언트는 공급자가 로드한 기록을 받기 때문에 애플리케이션은 대화를 수동으로 다시 작성하지 않고도 경로를 변경할 수 있습니다.
.NET SDK는 실험RoutePersistingRoutingChatClient적 기능을 제공합니다. 를 사용하여 초기 경로를 RoutePersistingRoutingChatClientOptions.DefaultRoute설정하고, 세션의 경로를 GetActiveRoute검사하고, 를 사용하여 SetActiveRoute변경합니다. 기본 경로를 설정하지 않으면 클라이언트는 생성 시 제공된 첫 번째 경로를 사용합니다.
추가 라우팅 전략을 허용하는 더 많은 라우팅 클라이언트가 있습니다 Microsoft.Extensions.AI .
전체 C# 구현은 다중 모델 라우팅 샘플을 참조하세요.
Important
경로로 등록된 모든 채팅 클라이언트는 채팅 기록 공급자가 제공하는 호출자 관리 기록을 사용해야 합니다. 공급자는 세션 또는 애플리케이션 소유 스토리지에 해당 기록을 저장할 수 있습니다. 유추 서비스 관리 대화 기록을 사용하는 경로를 등록하지 마세요.
Python 지원은 현재 사용할 수 없습니다.
Go 지원은 현재 사용할 수 없습니다.