Machine learning vs sistemas de recomendação com LLM: quando o ML clássico ganha

Para a maioria dos problemas de recomendação, um sistema de recomendação com machine learning — filtragem colaborativa, pontuação baseada em conteúdo ou fatorização de matrizes — ganha a um LLM em todos os eixos que importam para enviar um produto: custo por pedido, latência p99, explicabilidade e comportamento no arranque a frio. Recorra a um LLM apenas quando o resultado for texto genuinamente novo que o utilizador tem de ler. Tudo o resto é ordenar itens conhecidos — e o ML clássico ordena melhor, mais barato e de forma defensável.

Construímos recomendadores para produtos de bem-estar — daqueles que sugerem uma troca de refeição, uma deixa de sono, um exercício ou um suplemento num ecrã que o utilizador abre todas as manhãs. Já enviámos as duas arquiteturas. Esta é a decisão que realmente tomamos, termo a termo, com os números que a sustentam.

Machine learning vs sistema de recomendação com LLM: primeiro, as definições

Metade da confusão nestes debates vem de vocabulário descuidado. Então, com precisão:

• A filtragem colaborativa recomenda itens encontrando utilizadores que se comportaram como o utilizador e mostrando o que esses gostaram. "Quem registou este treino também registou aquele." Precisa de um histórico de interações e de nada sobre os próprios itens.
• A filtragem baseada em conteúdo recomenda itens semelhantes aos que o utilizador já consumiu, usando características do item — os macros de uma receita, as etiquetas de um artigo, o mecanismo de um suplemento. Precisa de metadados dos itens e de nada sobre outros utilizadores.
• A fatorização de matrizes é o motor por trás da filtragem colaborativa moderna. Tem-se uma matriz gigante e quase vazia de avaliações ou interações utilizador-por-item; a fatorização decompõe-a em duas pequenas matrizes densas (vetores de utilizador e vetores de item) cujo produto prevê as células em falta. A Netflix popularizou-a por volta de 2009; continua excelente.
• Um recomendador com LLM usa um modelo de linguagem grande — quer dando-lhe um perfil de utilizador e pedindo sugestões, quer projetando itens e consultas num espaço vetorial comum para recuperação semântica. O primeiro é generativo; o segundo é, na verdade, filtragem baseada em conteúdo vestida de transformer.

A versão curta: uma recomendação quase nunca é um problema de geração de texto. É um problema de ordenação sobre um conjunto finito de candidatos que já é seu. Visto assim, o LLM deixa de parecer a ferramenta óbvia.

Eixo 1 — Custo: a rubrica por pedido

Um ranker com gradient boosting treinado ou um modelo de fatorização de matrizes custa praticamente nada por pedido. É um produto escalar, ou algumas centenas de divisões de árvores, a correr no mesmo processo que serviu a página. Sem salto de rede, sem contador de tokens.

Um recomendador com LLM é um custo recorrente e medido a cada carregamento de ecrã. Tome uma app de bem-estar com 30 000 utilizadores ativos diários que veem sugestões cinco vezes por dia: são 150 000 inferências por dia, 4,5 milhões por mês. Mesmo a uma fração de cêntimo por chamada, depois de contar o contexto de entrada, os tokens de saída e as repetições que vai precisar para JSON malformado, está agora a pagar mensalmente por algo que um modelo de um único ficheiro faz de graça. O custo marginal do modelo clássico é erro de arredondamento; o custo marginal do LLM cresce linearmente com o seu sucesso. O crescimento não devia ser um incidente de custos.

Eixo 2 — Latência: o orçamento que não recupera

Um painel de bem-estar quer renderizar bem abaixo dos 100 ms. Os nossos rankers em-processo devolvem candidatos pontuados e ordenados em menos de um milissegundo — a recomendação não está no caminho crítico, é ruído no orçamento de renderização.

Uma chamada a um LLM demora de centenas de milissegundos a vários segundos, e a cauda é brutal: a p50 pode ser aceitável enquanto a p99 rebenta por completo o orçamento. Pode transmitir tokens para a disfarçar, mas não pode transmitir uma lista ordenada que o utilizador precisa antes de decidir onde tocar. Por isso recorre à cache. Agora está a manter uma estratégia de invalidação de cache para recomendações que mudam a cada refeição registada — a resolver um problema difícil que criou ao escolher a ferramenta errada. O modelo clássico nunca teve o problema.

Eixo 3 — Explicabilidade: a pergunta que todo o utilizador acaba por fazer

"Porque me estão a mostrar isto?" Num contexto regulado ou próximo da saúde, isto não é um luxo — é a diferença entre um produto defensável e uma responsabilidade legal.

Um recomendador por pontuação responde com números. O nosso ranker de bem-estar pontua cada candidato em alguns eixos explícitos — peso de evidência (anotado uma vez por um clínico, ECA > coorte > relato de caso), delta pessoal (quão longe o utilizador está do alvo clínico para a métrica em causa) e custo de adesão (o atrito que a sugestão acrescenta). Multiplicar, ordenar, ficar com o topo. Cada sugestão decompõe-se em três números que podemos mostrar, registar e reproduzir.

Faça a mesma pergunta a um LLM e recebe um parágrafo fluente que soa a uma razão, mas não é a causa real do resultado — é uma racionalização a posteriori gerada pelo mesmo processo estocástico. Não o consegue testar com testes unitários. Não o consegue comparar entre versões do modelo. Não o consegue pôr à frente de um clínico para que assine a lógica, porque não há lógica, só pesos que não lhe pertencem. Para o trabalho acessível e de dispositivos médicos de Classe I que fazemos ao abrigo do MDR 2017/745 da UE, "o modelo disse-o" não é resposta.

Eixo 4 — Arranque a frio: o problema que todos subestimam

O arranque a frio é o momento mais difícil do recomendador: um utilizador novinho sem histórico, ou um item novinho que ninguém tocou. É onde a filtragem colaborativa ingénua se desfaz — sem interações, não há nada para fatorizar.

Eis a nuance que decide a arquitetura:

• Arranque a frio de utilizador novo. A pontuação baseada em conteúdo lida com isto com elegância — pontua o conjunto de candidatos contra o pouco que sabe (respostas de onboarding, uma única métrica registada) e melhora à medida que os dados chegam. Um LLM também consegue raciocinar a partir de um perfil escasso, e é o único sítio onde tem uma vantagem genuína. Mas um ranker baseado em conteúdo afinado à mão dá-lhe 90% desse benefício a 0% do custo, e controla exatamente o que pesa.
• Arranque a frio de item novo. É aqui que LLMs e embeddings brilham e a filtragem colaborativa pura não consegue: uma receita nova com zero interações ainda tem características — ingredientes, macros, etiquetas. Projete-a num embedding e a similaridade baseada em conteúdo coloca-a de imediato. Não precisa de um modelo generativo para isto; um sentence-transformer de 90 MB produz embeddings que batem um LLM de fronteira na maioria dos benchmarks de recuperação, a um milésimo do custo.

A conclusão honesta: a parte do arranque a frio que o tenta a ir para um LLM resolve-se melhor com embeddings mais características de conteúdo, que é ML clássico com um extrator de características moderno — não a interrogar um modelo de chat em cada pedido.

A caixa de ferramentas, por ordem de prioridade

1. Pontuação ponderada com coeficientes afinados à mão. Aborrecida, eficaz, dois fins de semana para enviar. Maximamente explicável. Comece aqui.
2. Árvores com gradient boosting (XGBoost / LightGBM) sobre rótulos de envolvimento. O melhor ROI em ML aplicado da última década. Treina num portátil, capta interações de características não-lineares que os seus pesos manuais perdem.
3. Fatorização de matrizes quando já tem histórico real de utilizador-item. O motor clássico da filtragem colaborativa; ainda o padrão da prática para o recall de "utilizadores como você".
4. Embeddings / sentence-transformers para similaridade semântica e arranque a frio de item novo. É a sua camada de recall baseada em conteúdo.
5. Bandits contextuais quando precisa de explorar além de explorar e aprender online a partir dos cliques.
6. Um LLM — apenas quando o resultado for prosa genuinamente nova que o utilizador tem de ler.

Um recomendador maduro é normalmente geração de candidatos (filtragem colaborativa + recall baseado em conteúdo puxam algumas centenas de candidatos) seguida de uma fase de ordenação (um modelo com gradient boosting pontua-os). Duas fases, ambas ML clássico, ambas explicáveis, ambas rápidas.

Então quando é que o LLM ganha de facto?

Três casos legítimos, e partilham uma forma — o LLM produz texto, não uma decisão:

• Geração aberta. "Escreve-me uma semana de treinos com estas restrições." Não há conjunto finito de candidatos para pré-autorar, por isso a ordenação não se aplica.
• Interface em linguagem natural. O utilizador pergunta em prosa; o LLM traduz para uma consulta a um sistema determinístico; a resposta vem desse sistema. O LLM é o tradutor, não o oráculo.
• Explicação ancorada. O ranker clássico escolhe a sugestão; o LLM escreve a frase que explica porquê, ancorada nos três números do ranker. Uma alucinação agora custa-lhe uma frase desajeitada, não uma recomendação clínica.

Repare no padrão: em todos os casos vencedores, o LLM está a jusante da, ou ortogonal à, decisão de ordenação. Nunca é o recomendador.

Perguntas frequentes

Quando se deve usar ML clássico em vez de um LLM num recomendador?

Use ML clássico (factorização de matrizes, árvores com gradient boosting, retrieval de duas torres) quando tem dados estruturados de interação, precisa de latência inferior a 50ms e serve recomendações em escala. Estes modelos são mais baratos por pedido, determinísticos e fáceis de avaliar offline — um LLM só justifica o seu lugar quando a entrada é texto não estruturado ou quando precisa de raciocínio em linguagem natural sobre contexto escasso.

Um LLM é mais barato ou mais caro do que um recomendador de ML clássico?

Um LLM é quase sempre mais caro por recomendação, muitas vezes em duas ou três ordens de grandeza. Um modelo de ranking treinado serve um pedido por uma fração de cêntimo em CPU comum, enquanto uma chamada a um LLM acarreta custos de tokens, inferência em GPU e maior latência — por isso reserve o LLM para caminhos de baixo volume e alto valor, e não para o ciclo quente de serviço.

Como é que cada abordagem lida com o problema de arranque a frio (cold-start)?

Os LLMs lidam melhor com o arranque a frio porque conseguem raciocinar a partir de descrições de itens e de algumas palavras de intenção do utilizador, sem qualquer histórico de interação. O ML clássico precisa de atributos baseados em conteúdo ou de fallbacks por popularidade até acumular dados comportamentais suficientes — um padrão comum em produção é usar um LLM ou modelo de conteúdo para utilizadores novos e passar para um modelo de filtragem colaborativa assim que existe sinal.

O que é mais explicável para recomendações, ML ou um LLM?

O ML clássico é mais auditável: importância de atributos, valores SHAP e scores de ranking dão-lhe uma razão defensável para cada recomendação. Um LLM consegue produzir explicações fluentes em linguagem natural, mas essas são racionalizações a posteriori, não a verdadeira causa do ranking — em contextos regulados ou ligados à saúde preferimos um modelo cujas decisões possam ser rastreadas e reproduzidas.

Quando é que NÃO se deve usar IA de todo para recomendações?

Dispense tanto ML como LLMs quando heurísticas simples já satisfazem a necessidade — ordenação por popularidade, recência, curadoria editorial ou filtros baseados em regras batem muitas vezes um modelo num catálogo pequeno ou num site de baixo tráfego. Um recomendador só compensa o custo de pipeline de dados, monitorização e re-treino quando há utilizadores e itens suficientes para que as regras feitas à mão falhem de forma visível.

A ordem de envio

Se tem nas mãos uma especificação que diz "sugestões com IA", faça isto:

1. Liste os candidatos. Se não os consegue enumerar, não tem um problema de recomendação — tem um problema de conteúdo. Resolva-o primeiro.
2. Escolha três eixos de pontuação. Afine os pesos à mão durante uma semana. Envie.
3. Registe cada sugestão mostrada e cada uma sobre a qual se agiu. É o seu conjunto de treino; só o obtém enviando.
4. Após quatro a seis semanas de dados, treine um modelo com gradient boosting sobre os registos e reforme os pesos manuais. Acrescente fatorização de matrizes e embeddings à medida que o histórico e o catálogo crescem.
5. Só então, se ainda precisar de prosa nova, acrescente um LLM — para explicar, não para decidir.

Vai enviar mais depressa, gastar menos, dormir melhor e — a parte que importa — vai conseguir responder à única pergunta que conta quando um utilizador pergunta porque recebeu aquela sugestão: aqui estão os três números, e aqui está o que significam. É todo o argumento a favor do machine learning sobre um recomendador com LLM, numa frase.

É a mesma disciplina por trás dos recomendadores de bem-estar que construímos, das análises focadas na privacidade que operamos e da loja de chocolates que enviámos para a Delicious Diamonds: escolher o modelo mais simples que responde à pergunta que lhe podem pedir para defender. Se está a olhar para uma funcionalidade de recomendação e a especificação diz "deixa a IA tratar disso", teremos todo o gosto em demovê-lo.