Como escolhemos a IA certa para cada função

Quando se projeta uma funcionalidade baseada em inteligência artificial, a pergunta "que modelo uso" parece ter de ser respondida uma única vez, 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 diferentes entre si que um único fornecedor, por muito bom que fosse, não conseguia servi-las bem a todas. Este artigo conta porquê, e como está feito hoje o sistema que daí nasceu.

O problema que motivou a escolha

No início, a Scintilla — a assistente de escrita da NovLore — juntava dois trabalhos diferentes num único canal: a conversa com o utilizador e a geração do painel da obra (personagens, lugares, enredo) a partir dessa conversa. Pareciam ligados, mas tinham necessidades opostas: a conversa precisa de responder depressa, enquanto gerar dados estruturados coerentes precisa de tempo para pensar. Um único fornecedor, otimizado para uma das duas necessidades, penalizava sistematicamente a outra.

A solução não foi procurar um fornecedor que fizesse bem as duas coisas. Foi deixar de as tratar como a mesma tarefa.

Seis âmbitos, não um

Hoje, cada função de IA da NovLore declara o seu próprio âmbito — correção, reescrita, chat, estrutura, capítulo, transcrição — e cada âmbito pode ter um fornecedor 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 utilizador lança já a contar com a espera, usa antes um modelo escolhido pela qualidade da prosa num trabalho longo.

Âmbito	O que faz	O que mais conta
Chat	conversa com a assistente	velocidade de resposta
Correção	gralhas e coerência gramatical	precisão, custo baixo
Reescrita	alteração de um texto selecionado	qualidade estilística
Estrutura	dados estruturados sobre personagens/enredo	fiabilidade do formato
Capítulo	geração de um capítulo inteiro	qualidade em texto longo
Transcrição	preparado, ainda não ativo	—

Nenhuma destas escolhas é definitiva: um painel de administração permite mudar o fornecedor e a reserva de cada âmbito sem tocar no código, porque o custo e a qualidade relativa dos modelos mudam com o tempo mais depressa do que o software.

Porquê sete fornecedores e não um "suficientemente bom"

Com um único fornecedor, cada interrupção de serviço dele — e acontece a todos, mesmo aos melhores — torna-se 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 deve passar pelo mesmo canal da primeira escolha. Se a primeira escolha e a reserva forem dois encaminhamentos diferentes para o mesmo fornecedor a montante, uma indisponibilidade desse fornecedor derruba as duas ao mesmo tempo.

Por isso, quando a primeira escolha de um âmbito é um agregador que dá acesso a vários modelos com uma única chave, a reserva vai deliberadamente para um fornecedor direto e independente. É uma redundância real, não só no papel.

O que vê o utilizador quando a reserva entra em ação

Nada, se o sistema funcionar como deve. Se o fornecedor de primeira escolha para um âmbito não responder, a passagem para a reserva é transparente: o pedido é concluído na mesma, e só um dado técnico interno regista que quem respondeu foi a segunda escolha. No streaming — as respostas que aparecem palavra a palavra, como no chat — a reserva só pode entrar em ação antes de chegar o primeiro pedaço de texto: uma vez começada a resposta, mudar de fornecedor a meio produziria um texto costurado a partir de dois estilos diferentes, pior do que esperar mais alguns segundos.

A transparência da reserva não é um pormenor técnico para apaixonados por infraestrutura: é a diferença entre um utilizador que nota uma lentidão ocasional e um utilizador que vê um erro enquanto escreve o seu romance.

O router como único ponto de passagem

Para que este sistema se aguente ao longo do tempo, cada função de IA do produto — incluindo as de saída estruturada e as de streaming — passa por um único router interno, nunca diretamente pelos fornecedores. É uma escolha que custa disciplina (nenhum atalho, nem sequer para uma função "temporária") mas que compensa de uma forma precisa: quando um fornecedor muda as suas condições, ou surge um novo que vale a pena acrescentar, a mudança faz-se num único sítio, não em dez endpoints diferentes escritos em momentos diferentes.

Perguntas frequentes

Porque não usar sempre o modelo mais potente disponível?

Porque "mais potente" não é a mesma coisa que "mais adequado à tarefa". Um modelo excelente em texto longo e criativo pode ser lento e caro para um chat que tem de responder num segundo; usá-lo em todo o lado faria parecer lenta até a parte do produto que devia ser instantânea.

O utilizador pode escolher que IA usar?

Não diretamente em cada mensagem: a escolha é por âmbito e é gerida por quem administra o produto, com base na qualidade e fiabilidade observadas ao longo do tempo. É uma escolha deliberada — deixá-la ao utilizador transferiria para ele uma decisão técnica que exige monitorizar continuamente sete fornecedores diferentes.

O que acontece se também a reserva não responder?

A operação falha com um erro explícito, e no caso de uma ação a créditos o débito é anulado automaticamente sobre o mesmo lote de onde tinha sido retirado: o utilizador não paga por um pedido que não recebeu resposta.

Este sistema atrasa o desenvolvimento de novas funções de IA?

A curto prazo sim, ligeiramente: acrescentar uma função exige passar pelo router em vez de chamar uma API diretamente. A médio prazo é o contrário, porque cada nova função herda de graça a gestão de erros, a reserva e o rastreio de custos já construídos uma única vez.