You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
91 lines
2.8 KiB
Markdown
91 lines
2.8 KiB
Markdown
# Separacao Entre Modelo Do Atendimento E Modelo De Geracao De Tools
|
|
|
|
## Objetivo
|
|
|
|
Definir a fronteira entre o runtime de modelo usado no atendimento ao cliente e o runtime de modelo usado para gerar e validar novas tools.
|
|
|
|
Esta etapa consolida uma regra importante da arquitetura: os dois perfis de modelo nao podem compartilhar configuracao nem ciclo de publicacao.
|
|
|
|
## Decisao
|
|
|
|
O sistema passa a tratar esses runtimes como perfis independentes.
|
|
|
|
Perfis:
|
|
|
|
1. `atendimento_runtime_profile`
|
|
2. `tool_generation_runtime_profile`
|
|
|
|
A separacao formal fica em `shared/contracts/model_runtime_separation.py`.
|
|
|
|
## Regras obrigatorias
|
|
|
|
### 1. Configuracoes distintas
|
|
|
|
Cada runtime possui sua propria `config_key`.
|
|
|
|
Portanto:
|
|
|
|
- o atendimento usa `atendimento_runtime_profile`
|
|
- a geracao de tools usa `tool_generation_runtime_profile`
|
|
- uma mudanca de configuracao nunca reutiliza a mesma chave para os dois contextos
|
|
|
|
### 2. Catalogos com alvo separado
|
|
|
|
Os modelos homologados precisam carregar o alvo funcional correto.
|
|
|
|
Portanto:
|
|
|
|
- modelos homologados para atendimento entram sob `runtime_target = atendimento`
|
|
- modelos homologados para geracao entram sob `runtime_target = tool_generation`
|
|
- um modelo pode existir nos dois catalogos, mas a selecao continua independente
|
|
|
|
### 3. Publicacao independente
|
|
|
|
Os dois runtimes possuem publicacao independente.
|
|
|
|
Consequencia pratica:
|
|
|
|
- publicar uma mudanca no atendimento nao publica a geracao de tools
|
|
- publicar uma mudanca na geracao de tools nao muda o bot que responde ao cliente
|
|
- cada perfil pode ter sua propria auditoria e versao ativa
|
|
|
|
### 4. Rollback independente
|
|
|
|
Cada runtime precisa poder voltar ao estado anterior sem afetar o outro.
|
|
|
|
Consequencia pratica:
|
|
|
|
- rollback do atendimento nao mexe no runtime de geracao
|
|
- rollback da geracao nao mexe no atendimento em producao
|
|
|
|
### 5. Sem propagacao implicita
|
|
|
|
Nao e permitido que uma alteracao em um runtime seja espelhada automaticamente no outro.
|
|
|
|
Isso impede:
|
|
|
|
- trocar o modelo do bot e, por efeito colateral, trocar o modelo de geracao
|
|
- usar defaults compartilhados para empurrar mudancas silenciosas nos dois fluxos
|
|
- misturar SLO, custo e risco do atendimento com o pipeline de tools
|
|
|
|
## Responsabilidade por runtime
|
|
|
|
### Atendimento
|
|
|
|
- alvo funcional: responder ao cliente final
|
|
- servico consumidor: `product`
|
|
- impacto direto: experiencia do atendimento e fluxo conversacional
|
|
|
|
### Geracao de tools
|
|
|
|
- alvo funcional: gerar e validar novas tools
|
|
- servico consumidor: `admin`
|
|
- impacto direto: pipeline de governanca, geracao e validacao
|
|
|
|
## Consequencias positivas
|
|
|
|
- protege o atendimento de experimentos de geracao de codigo
|
|
- permite escolher modelos diferentes para custo, latencia e qualidade em cada fluxo
|
|
- simplifica auditoria e rollback de configuracao
|
|
- prepara as futuras telas e rotas de configuracao do sistema sem ambiguidade
|