Como escolhemos a IA certa para cada função
Quando se projeta uma função baseada em inteligência artificial, a pergunta "qual modelo eu uso" parece precisar de resposta uma única vez, lá no início. Na prática da NovLore não foi assim: com o tempo percebemos que tarefas diferentes do produto tinham necessidades tão distintas entre si que um único provedor, por melhor que fosse, não conseguia atender bem a todas. Este artigo conta o porquê, e como é feito hoje o sistema que nasceu disso.
O problema que motivou a escolha
No início, Scintilla — a assistente de escrita da NovLore — mantinha juntas duas tarefas diferentes num único canal: a conversa com o usuário e a geração do painel da obra (personagens, lugares, trama) a partir dessa conversa. Pareciam ligadas, mas tinham necessidades opostas: a conversa precisa responder rápido, enquanto gerar dados estruturados coerentes precisa de tempo para pensar. Um único provedor, otimizado para uma dessas necessidades, penalizava sistematicamente a outra.
A solução não foi procurar um provedor que fizesse bem as duas coisas. Foi parar de tratá-las como a mesma tarefa.
Seis áreas, não uma
Hoje, cada função de IA da NovLore declara sua própria área — correção, reescrita, chat, estrutura, capítulo, transcrição — e cada área pode ter um provedor diferente como primeira escolha. O chat da Scintilla, por exemplo, usa um modelo escolhido pela rapidez de resposta; a geração de um capítulo inteiro, que o usuário aciona sabendo que vai esperar, usa em vez disso um modelo escolhido pela qualidade da prosa num texto longo.
| Área | O que faz | O que mais importa |
|---|---|---|
| Chat | conversa com a assistente | velocidade de resposta |
| Correção | erros de digitação e coerência gramatical | precisão, custo baixo |
| Reescrita | edição de um texto selecionado | qualidade estilística |
| Estrutura | dados estruturados sobre personagens/trama | confiabilidade do formato |
| Capítulo | geração de um capítulo inteiro | qualidade em texto longo |
| Transcrição | preparado, ainda não ativo | — |
Nenhuma dessas escolhas é definitiva: um painel administrativo permite trocar o provedor e a reserva de cada área sem tocar no código, porque o custo e a qualidade relativa dos modelos mudam com o tempo mais rápido do que muda o software.
Por que sete provedores e não um "bom o suficiente"
Com um único provedor, cada interrupção de serviço dele — e isso acontece com todos, até com os melhores — vira uma interrupção do produto inteiro. A solução mais comum é ter uma reserva; a menos óbvia, mas mais sólida, é que a reserva não pode passar pelo mesmo canal da primeira escolha. Se a primeira escolha e a reserva são dois caminhos diferentes para o mesmo provedor por trás, uma indisponibilidade desse provedor derruba as duas juntas.
Por isso, quando a primeira escolha de uma área é um agregador que dá acesso a vários modelos com uma única chave, a reserva vai deliberadamente para um provedor direto e independente. É uma redundância de verdade, não só no papel.
O que o usuário vê quando a reserva entra em ação
Nada, se o sistema funcionar como deveria. Se o provedor de primeira escolha de uma área não responde, a mudança para a reserva é transparente: a requisição segue em frente normalmente, e só um dado técnico interno registra que quem respondeu foi a segunda escolha. No streaming — as respostas que aparecem palavra por palavra, como no chat — a reserva só pode entrar antes de chegar o primeiro pedaço de texto: depois que a resposta começa, trocar de provedor no meio produziria um texto costurado com dois estilos diferentes, pior do que esperar mais alguns segundos.
A transparência da reserva não é um detalhe técnico para apaixonados por infraestrutura: é a diferença entre um usuário que percebe uma lentidão ocasional e um usuário que vê um erro enquanto está escrevendo o romance dele.
O roteador como único ponto de passagem
Para que esse sistema se sustente com o tempo, toda função de IA do produto — inclusive as com saída estruturada e as em streaming — passa por um único roteador interno, nunca diretamente pelos provedores. É uma escolha que custa disciplina (nenhum atalho, nem mesmo para uma função "temporária"), mas que se paga de um jeito preciso: quando um provedor muda suas condições, ou surge um novo que vale a pena adicionar, a mudança acontece num único lugar, não em dez endpoints diferentes escritos em momentos diferentes.
Perguntas frequentes
Por que não usar sempre o modelo mais potente disponível?
Porque "mais potente" não é a mesma coisa que "mais adequado à tarefa". Um modelo ótimo para texto longo e criativo pode ser lento e caro para um chat que precisa responder em um segundo; usá-lo em tudo faria até a parte do produto que deveria ser instantânea parecer lenta.
O usuário pode escolher qual IA usar?
Não diretamente, mensagem por mensagem: a escolha é por área e fica a cargo de quem administra o produto, com base em qualidade e confiabilidade observadas ao longo do tempo. É uma escolha deliberada — deixar isso para o usuário jogaria sobre ele uma decisão técnica que exige monitorar continuamente sete provedores diferentes.
O que acontece se a reserva também não responder?
A operação falha com um erro explícito, e no caso de uma ação que consome créditos, o débito é cancelado automaticamente no mesmo lote de onde foi tirado: o usuário não paga por uma requisição que não recebeu resposta.
Esse sistema deixa mais lento o desenvolvimento de novas funções de IA?
No curto prazo, sim, levemente: adicionar uma função exige passar pelo roteador em vez de chamar uma API diretamente. No médio prazo é o contrário, porque toda função nova herda de graça o tratamento de erros, a reserva e o rastreamento de custos já construídos uma única vez.