Problema de localização de faltas após redução de custos em roteamento multimodelo

A primeira vez que senti que algo estava errado online foi uma reclamação difícil de explicar: o mesmo usuário fez a mesma pergunta três vezes em 5 minutos. Na primeira vez ele respondeu bem, na segunda vez começou a falar bobagens e na terceira vez voltou ao normal.

Não há anormalidades nos logs, a latência é estável e o uso do token não aumentou. A única mudança que pode ser vista é que acabamos de ativar o “roteamento multimodelo” e usamos modelos mais baratos para cobrir parte do tráfego.

Naquela época, a intuição da equipe era muito consistente: o modelo é uma distribuição de probabilidade e as flutuações são normais. Além disso, o roteamento é apenas uma camada do gateway, então quais grandes problemas podem ocorrer?

Nas duas semanas seguintes, sofremos muitas vezes com essa sentença.

Julgamento central

O principal custo do roteamento multimodelo é alterar o comportamento da mesma solicitação de “reprodutível” para “distribuição de probabilidade”.

Na era do modelo único, não importa quão difícil seja um problema on-line, contanto que você obtenha a entrada, o prompt, o contexto e o número da versão, provavelmente poderá reproduzi-lo em um determinado ambiente e, em seguida, seguir a cadeia de chamadas para identificar a causa raiz.

Uma vez envolvido o roteamento, o problema se tornará:

-Qual modelo, qual versão e qual conjunto de parâmetros usei desta vez?

• Por que a rota foi escolhida desta forma e quais características o limiar atingiu?
• Você percorreu caminhos diferentes duas vezes na mesma sessão?
• Quando ocorre uma falha, é possível repetir a “decisão tomada naquele momento”?

Se não houver logs rastreáveis ​​e mecanismos de reversão, as falhas online serão atualizadas de “modelo impreciso” para “causa raiz não localizável”.

Como as coisas ficam mais difíceis passo a passo

Adotamos apenas a estratégia mais simples no início: usar modelos pequenos sempre que possível e atualizar para modelos grandes apenas quando eles “parecerem complicados”.

A chamada “aparência complexa” são alguns recursos baratos: comprimento de entrada, se contém blocos de código, se há múltiplas rodadas de diálogo e a confiança de um pequeno classificador.

A primeira onda de problemas depois de ficar online foi a falha dos métodos de solução de problemas.

O mesmo prompt não pode ser reproduzido por colegas de teste no ambiente de escala de cinza e não pode ser reproduzido localmente pelos desenvolvedores. No final, apenas usuários online podem acioná-lo de forma estável.

Certa vez, suspeitamos que fosse um bug na emenda de contexto, no cache ou em algum pós-processamento. Só quando capturamos a entrada completa de uma solicitação é que descobrimos que desta vez um modelo pequeno foi usado on-line, e o modelo grande foi usado por padrão quando o reproduzimos.

Esta é uma “mudança de caminho”.

As mudanças de caminho alteram a solução de problemas de “entradas recorrentes” para “decisões recorrentes”. As decisões não podem ser repetidas naquele momento.

Mal-entendido 1: trate o roteamento como pura otimização de custos

O que você vê na tabela de custos é:

• 30% do tráfego vai para modelos pequenos
• O custo médio por chamada caiu 18%

Mas o que você não pode ver na tabela de falhas é:

• Cada problema de qualidade levará 1-2 dias extras para determinar se é causado pelo roteamento.
• A reprodução online requer um “contexto de tomada de decisão” mais completo
• A reversão não é mais um “modelo de reversão”, mas uma “estratégia de reversão + limite de reversão + lógica de extração de recursos de reversão”

Quando você trata o roteamento como uma mudança leve, como “mudar de fornecedor”, definitivamente terá que pagar juros mais tarde na solução de problemas.

Mal-entendido 2: Interpretando a instabilidade como “LLM é inerentemente aleatório”

A maioria dos problemas causados pela aleatoriedade de um único modelo é “amostrar a mesma entrada várias vezes com saídas diferentes”.

O problema causado pela aleatoriedade do roteamento é que “a mesma entrada vai para sistemas diferentes”.

Ambos parecem flutuações, mas são diagnosticados de maneiras completamente diferentes.

O primeiro frequentemente ajusta a temperatura, avisa o sistema e adiciona restrições; este último deve primeiro responder: Será que desta vez seguiram o caminho errado?

Sem rotear os logs de decisão, a equipe adquirirá um péssimo hábito: atribuir todas as anomalias à “instabilidade do modelo”, de modo que a estratégia se torne cada vez mais agressiva e a qualidade se torne cada vez mais parecida com um dado.

Três tipos de rastreabilidade que realmente precisam ser concluídos

Para tornar o roteamento um sistema “solucionável”, pelo menos três tipos de registros devem ser preenchidos e devem poder ser agrupados em uma dimensão de solicitação.

1) Registro de decisão de roteamento (registro de decisão)

Não apenas registre “qual modelo foi selecionado”, mas também registre:

• Conjunto de candidatos (quais modelos disponíveis estão disponíveis naquele momento)
• Pontuação ou julgamento limite para cada candidato
• Valores de recursos usados (comprimento de entrada, contagem de múltiplas rodadas, saída do classificador, etc.)
• Número da versão da política (muito crítico)

Só assim poderemos responder “Por que escolhi desta vez?”

2) Solicitar instantâneo (reproduzir instantâneo)

Pelo menos o seguinte deve estar disponível em caso de falha:

• Entrada bruta do usuário
• O prompt realmente enviado ao modelo (incluindo palavras de prompt do sistema, contexto combinado e resultados da ferramenta)
• Configuração de chaves (temperatura, top_p, max_tokens, stop e seu próprio switch de pós-processamento)

Sem instantâneos, as recorrências são apenas suposições.

3) Reversão de roteamento (primitiva de reversão)

A reversão deve ser bastante “áspera” e pode ser executada com um clique:

• Forçar todos os jogadores a seguirem um determinado modelo estável
• Ou consertar uma determinada versão da estratégia

Não espere alterar temporariamente o limite em caso de acidente. O que é necessário em um acidente é certeza.

Caso de falha: “limiar adaptativo” aparentemente inteligente

Posteriormente, tentamos uma abordagem mais “inteligente”: ajustar dinamicamente o limite com base na qualidade do sinal dos últimos 10 minutos para permitir que o modelo pequeno engolisse mais tráfego.

O resultado é uma autooscilação muito típica:

• Modelos pequenos engolem mais e a qualidade do sinal piora
• O limite é aumentado, modelos grandes engolem mais e a qualidade do sinal melhora.
• O limite é reduzido e os modelos pequenos engolem mais

Externamente parece “bons e maus momentos”, mas internamente a estratégia está vacilante.

Se não houver um número de versão da política e um registro de decisões para esse tipo de problema, é basicamente impossível explicá-lo claramente e muito menos corrigi-lo.

Limites aplicáveis

O roteamento multimodelo não é impossível, mas é mais adequado para equipes que atendem aos seguintes pré-requisitos:

• É aceitável pagar custos adicionais de armazenamento e conformidade de privacidade pela rastreabilidade?
• Tenha métricas e avisos de qualidade claros, em vez de depender de reclamações de usuários
• A estratégia pode ser mantida como um “sistema online” com versões, escalas de cinza e reversões?

Se a observabilidade atual ainda estiver limitada a “volume de solicitação, atraso, código de erro”, não se apresse em fazer roteamento complexo ainda. O dinheiro economizado pode ser perdido no tempo de solução de problemas.

Resumo

A coisa mais subestimada sobre o roteamento multimodelo é que ele altera os objetos de solução de problemas.

O que antes era reproduzido era input, mas agora o que precisa ser reproduzido é a tomada de decisão. Sem logs de decisão, instantâneos de solicitação e primitivas de reversão, as falhas on-line se tornarão “aleatórias” e não poderão ser explicadas e reparadas.

As contas de redução de custos são fáceis de calcular, enquanto as contas recorrentes são as mais difíceis de calcular, mas com certeza aparecerão na revisão do acidente no final.