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.

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.