A OpenAI publicou em setembro de 2026 um estudo de caso descrevendo como a Fyxer, uma startup de Londres, construiu um assistente executivo de IA que organiza inboxes e escreve rascunhos de email na voz do usu\u00e1rio. O artigo detalha decis\u00f5es concretas de arquitetura: fine-tuning supervisionado, LoRA, Direct Preference Optimization, e uma malha de modelos pequenos em vez de um \u00fanico LLM gigante fazendo tudo.<\/p>\n
A publica\u00e7\u00e3o est\u00e1 em openai.com\/index\/fyxer. Segundo o material, a Fyxer usa fine-tuning supervisionado e Low-Rank Adaptation (LoRA) em seu sistema para criar variantes de modelo espec\u00edficas por tarefa, controlando o custo de treinamento. A base de dados de treinamento vem de uma ag\u00eancia humana que os fundadores operaram por anos antes de lan\u00e7ar o produto de IA: mais de 500.000 horas de fluxos de trabalho executivos anotados, capturando como assistentes reais gerenciam comunica\u00e7\u00e3o profissional.<\/p>\n
N\u00fameros reportados pela empresa e resumidos em cobertura secund\u00e1ria: 53% dos rascunhos s\u00e3o aceitos como escritos, 90% de reten\u00e7\u00e3o em 90 dias, e crescimento de receita de US$ 1M para US$ 32M ARR em 2025. Vou tratar esses n\u00fameros como reportados pela empresa, n\u00e3o como verific\u00e1veis independentemente.<\/p>\n
A decis\u00e3o de arquitetura mais interessante do sistema \u00e9 n\u00e3o usar um LLM gigante para gerar o email inteiro. Segundo cobertura do lan\u00e7amento, o sistema divide as tarefas entre 30 a 50 modelos especializados que lidam com classifica\u00e7\u00e3o, previs\u00e3o de inten\u00e7\u00e3o, recupera\u00e7\u00e3o de mem\u00f3ria e gera\u00e7\u00e3o de rascunho, em vez de um \u00fanico modelo grande de gera\u00e7\u00e3o de texto.<\/p>\n
Pense num restaurante durante o rush do almo\u00e7o. Voc\u00ea pode colocar um \u00fanico chef muito bom fazendo tudo, do risoto ao sushi, do pedido \u00e0 sobremesa. Ele consegue, mas \u00e9 lento, comete erros em pratos que n\u00e3o domina, e voc\u00ea paga caro pelo tempo dele. Ou voc\u00ea pode montar uma linha: algu\u00e9m s\u00f3 recebe o pedido, algu\u00e9m s\u00f3 corta legume, algu\u00e9m s\u00f3 sela prote\u00edna, algu\u00e9m s\u00f3 monta o prato. Cada esta\u00e7\u00e3o \u00e9 mais barata, mais r\u00e1pida e melhor na coisa espec\u00edfica que faz. O prato final \u00e9 montado no fim.<\/p>\n
A analogia quebra num ponto importante: no restaurante os pratos s\u00e3o padronizados. No email, o “prato final” muda a cada thread. Ent\u00e3o a orquestra\u00e7\u00e3o precisa decidir a cada nova mensagem qual conjunto de esta\u00e7\u00f5es ativar e em que ordem. Mas a mec\u00e2nica de base \u00e9 a mesma: cada modelo pequeno faz uma decis\u00e3o bem definida (isto \u00e9 urgente? isto precisa de resposta? qual thread anterior importa? qual tom usar?) e o rascunho final \u00e9 a composi\u00e7\u00e3o dessas decis\u00f5es.<\/p>\n
Do lado pr\u00e1tico da infer\u00eancia, um modelo pequeno especializado costuma ser mais r\u00e1pido, mais barato e mais previs\u00edvel numa tarefa estreita do que um modelo grande generalista fazendo a mesma coisa via prompt. O trade-off \u00e9 ter que treinar e manter cada um deles.<\/p>\n
Aqui entra o LoRA. Fine-tuning tradicional atualiza todos os pesos do modelo, o que exige muita GPU e muito tempo. LoRA (Low-Rank Adaptation) faz uma coisa diferente: congela os pesos originais do modelo e treina apenas matrizes pequenas “por cima”, que representam a diferen\u00e7a entre o comportamento base e o comportamento desejado. Voc\u00ea fica com um adaptador de poucos MB em vez de um modelo inteiro de dezenas de GB. Para servir, o adaptador \u00e9 aplicado sobre o modelo base em tempo de infer\u00eancia.<\/p>\n
Isso explica por que a Fyxer consegue manter dezenas de variantes especializadas: cada uma \u00e9 um adaptador barato de treinar e armazenar, n\u00e3o um modelo inteiro replicado.<\/p>\n
Sobre a infraestrutura de treinamento em si, o material da OpenAI diz que no in\u00edcio do produto a equipe usou a plataforma de fine-tuning da OpenAI para tarefas que exigiam alta acur\u00e1cia, e mais recentemente trabalhou com o time de fine-tuning gerenciado da OpenAI para colocar um novo checkpoint em produ\u00e7\u00e3o. O artigo n\u00e3o detalha quais modelos base espec\u00edficos, o que fica na zona do que n\u00e3o d\u00e1 para afirmar.<\/p>\n
Este \u00e9 o loop que faz o sistema melhorar com uso. Segundo cobertura do lan\u00e7amento, a Fyxer usa fine-tuning supervisionado, LoRA e Direct Preference Optimization derivada das edi\u00e7\u00f5es do usu\u00e1rio para melhorar continuamente os rascunhos, validando mudan\u00e7as atrav\u00e9s de testes A\/B.<\/p>\n
DPO (Direct Preference Optimization) \u00e9 uma t\u00e9cnica que treina o modelo a preferir uma resposta sobre outra a partir de pares (vers\u00e3o A, vers\u00e3o B, humano preferiu B). No caso da Fyxer, o par natural aparece sozinho: a Fyxer gera o rascunho, o usu\u00e1rio edita antes de enviar, e agora voc\u00ea tem dois textos, o gerado e o enviado. O enviado \u00e9 o “escolhido”, o gerado \u00e9 o “rejeitado”. Cada edi\u00e7\u00e3o do usu\u00e1rio vira um sinal de treino sem que ningu\u00e9m precise rotular nada.<\/p>\n
O detalhe importante \u00e9 o A\/B test como port\u00e3o. N\u00e3o \u00e9 porque um novo checkpoint parece melhor nas m\u00e9tricas offline que ele vai para produ\u00e7\u00e3o. Ele \u00e9 servido para um subgrupo, comparado contra o modelo atual em m\u00e9tricas reais (taxa de aceita\u00e7\u00e3o, quantidade de edi\u00e7\u00e3o), e s\u00f3 sobe se ganhar. Isso protege contra o caso comum onde o modelo “melhora” numa m\u00e9trica sint\u00e9tica e piora na experi\u00eancia real.<\/p>\n
A Fyxer n\u00e3o gera o rascunho a partir s\u00f3 da \u00faltima mensagem. A documenta\u00e7\u00e3o de suporte descreve que a Fyxer gera um rascunho quando um thread \u00e9 classificado como “To Respond” e a configura\u00e7\u00e3o de rascunho est\u00e1 ligada. Ou seja, h\u00e1 primeiro um classificador decidindo se aquele email merece rascunho, depois um gerador. E o gerador recebe contexto: o sistema \u00e9 informado por 500 mil horas de experi\u00eancia de EA e se apoia no seu pr\u00f3prio hist\u00f3rico de email conforme cresce, puxando contexto de threads e reuni\u00f5es em vez de apenas a mensagem \u00e0 frente.<\/p>\n
Em termos de fluxo, d\u00e1 para desenhar assim, passo a passo:<\/p>\n
A li\u00e7\u00e3o de arquitetura mais \u00fatil aqui, e que se aplica muito al\u00e9m de email, \u00e9 a de decompor uma tarefa aparentemente monol\u00edtica (“escrever o email certo”) numa sequ\u00eancia de decis\u00f5es pequenas onde cada uma pode ser medida, treinada e substitu\u00edda de forma isolada.<\/p>\n
Numa plataforma de conte\u00fado gerado por LLM em escala de cat\u00e1logo, cheguei a uma conclus\u00e3o parecida por outro caminho: o que estabiliza a qualidade n\u00e3o \u00e9 escolher o modelo maior, \u00e9 ancorar a gera\u00e7\u00e3o em dado estruturado real e rodar valida\u00e7\u00e3o antes de publicar. Um modelo generalista pedindo tudo em um prompt gigante alucina em cascata. Um pipeline que primeiro decide o que buscar, depois busca, depois valida, depois gera, quebra em pontos onde voc\u00ea consegue medir e consertar.<\/p>\n
Uma vers\u00e3o m\u00ednima do padr\u00e3o da Fyxer, aplicada a qualquer dom\u00ednio de resposta assistida, se parece com isto:<\/p>\n
entrada = mensagem_nova\n\n# 1. classificar\ncategoria = classificador_leve(entrada)\nif categoria != \"precisa_resposta\":\n arquivar(entrada, categoria)\n return\n\n# 2. entender inten\u00e7\u00e3o\nintent = modelo_intent(entrada)\n\n# 3. buscar contexto\ncontexto = memoria.buscar(\n remetente=entrada.remetente,\n topico=intent.topico,\n limite=5\n)\n\n# 4. gerar com adaptador do usuario\nrascunho = gerador_base.com_lora(usuario.adaptador_id).gerar(\n mensagem=entrada,\n intent=intent,\n contexto=contexto,\n estilo=usuario.perfil_de_escrita\n)\n\n# 5. entregar como rascunho, nunca enviar\nsalvar_rascunho(rascunho)\n\n# 6. no envio, comparar texto final com rascunho\n# a diferenca vira par (rejeitado, escolhido) para DPO futuro\n<\/code><\/pre>\nNenhum passo aqui \u00e9 novo em separado. A escolha da Fyxer foi tratar cada um como um modelo pequeno especializado em vez de um prompt dentro de um modelo grande.<\/p>\n
Onde quebra<\/h2>\n
Manter 30 a 50 modelos especializados tem um custo operacional real: cada um precisa de dados, avalia\u00e7\u00e3o, deploy, versionamento e monitoramento em produ\u00e7\u00e3o. Uma equipe pequena tentando reproduzir este padr\u00e3o sem os 500 mil horas de dados anotados vai encontrar rapidamente o problema inverso do que motivou a decis\u00e3o: em vez de custo alto de infer\u00eancia num modelo grande, voc\u00ea paga custo alto de manuten\u00e7\u00e3o em muitos modelos pequenos que ningu\u00e9m sabe se ainda est\u00e3o calibrados.<\/p>\n
O feedback loop via edi\u00e7\u00f5es do usu\u00e1rio tamb\u00e9m tem vi\u00e9s inerente. Um usu\u00e1rio que edita muito pode ser exigente com estilo, ou pode ser que o modelo esteja consistentemente errando em um segmento espec\u00edfico de emails, e voc\u00ea n\u00e3o distingue os dois s\u00f3 olhando a m\u00e9trica agregada. Aqui o A\/B test ajuda, mas n\u00e3o resolve o caso do usu\u00e1rio que edita menos por cansa\u00e7o, aceita rascunhos ruins e ensina o modelo que “ruim” \u00e9 aceit\u00e1vel.<\/p>\n
Sobre a captura da voz do usu\u00e1rio: o material da pr\u00f3pria Fyxer \u00e9 honesto em dizer que a qualidade do rascunho melhora conforme a Fyxer v\u00ea mais dos seus emails enviados. Traduzindo: nas primeiras semanas, os rascunhos s\u00e3o fracos. Isso \u00e9 limita\u00e7\u00e3o estrutural de qualquer sistema baseado em fine-tuning por usu\u00e1rio, n\u00e3o bug.<\/p>\n
Existe tamb\u00e9m o limite do dom\u00ednio. A pr\u00f3pria Fyxer publicou an\u00e1lise reconhecendo que negocia\u00e7\u00e3o e agendamento complexos ainda n\u00e3o s\u00e3o bem atendidos por IA: itiner\u00e1rios internacionais multi-trecho, gerenciar prefer\u00eancias de programas de fidelidade, lidar com mudan\u00e7as de \u00faltima hora quando uma conex\u00e3o cai, manter prefer\u00eancias de assento e requisitos alimentares consistentes entre sistemas, tudo isso ainda \u00e9 largamente manual, e apesar das melhorias, EAs gerenciando viagens complexas para executivos exigentes n\u00e3o deveriam repassar essas tarefas esperando confiabilidade ainda.<\/p>\n
O que n\u00e3o d\u00e1 para afirmar ainda<\/h2>\n
O artigo original da OpenAI, na parte que consegui capturar, descreve as t\u00e9cnicas em n\u00edvel conceitual mas n\u00e3o especifica: qual modelo base \u00e9 usado para o gerador, como exatamente os 30 a 50 modelos s\u00e3o orquestrados, se h\u00e1 um roteador aprendido ou regras determin\u00edsticas, com que frequ\u00eancia os adaptadores LoRA por usu\u00e1rio s\u00e3o retreinados, e como a mem\u00f3ria de longo prazo \u00e9 indexada. As cita\u00e7\u00f5es sobre “30 a 50 modelos” e “DPO derivada de edi\u00e7\u00f5es” v\u00eam de cobertura secund\u00e1ria (daily.dev) que resume o artigo, e eu n\u00e3o confirmei palavra por palavra contra a fonte prim\u00e1ria.<\/p>\n
As m\u00e9tricas de neg\u00f3cio (53% de aceita\u00e7\u00e3o, 90% de reten\u00e7\u00e3o, ARR) s\u00e3o reportadas pela empresa. N\u00e3o s\u00e3o verific\u00e1veis por terceiros a partir do material dispon\u00edvel. Trate-as como marketing bem-fundamentado, n\u00e3o como benchmark.<\/p>\n
Tamb\u00e9m n\u00e3o vi men\u00e7\u00e3o clara a se o DPO \u00e9 rodado por usu\u00e1rio (adaptador de prefer\u00eancia individual) ou agregado entre usu\u00e1rios. Faz diferen\u00e7a enorme para custo e para privacidade, e o material n\u00e3o esclarece.<\/p>\n
Como testar isso voc\u00ea mesmo<\/h2>\n
Se voc\u00ea quer sentir o mecanismo sem reconstruir a Fyxer, um caminho pequeno \u00e9 este:<\/p>\n
\n- Pegue uma pasta com 200 dos seus emails enviados.<\/li>\n
- Escreva um classificador simples (pode ser via prompt em um modelo pequeno) que rotule cada thread recebido em tr\u00eas categorias: precisa resposta, informativo, ignorar.<\/li>\n
- Para os que precisam resposta, fa\u00e7a um gerador (tamb\u00e9m via prompt) que produza rascunho usando os \u00faltimos 3 emails que voc\u00ea enviou para o mesmo destinat\u00e1rio como few-shot de estilo.<\/li>\n
- Compare, \u00e0 m\u00e3o, seus 20 pr\u00f3ximos envios reais com o rascunho gerado. Anote onde o modelo errou: tom, estrutura, tamanho, sign-off.<\/li>\n
- S\u00f3 depois disso, se ainda fizer sentido, considere fine-tuning ou LoRA. Voc\u00ea vai descobrir que quase todo o ganho inicial vem da etapa 2 (o classificador) e da etapa 3 (o contexto certo no prompt), n\u00e3o do modelo em si.<\/li>\n<\/ol>\n
Esse experimento leva um fim de semana e ensina, na pr\u00e1tica, por que a Fyxer decidiu quebrar o problema em vez de jogar tudo em um \u00fanico modelo grande. O aprendizado real fica quando voc\u00ea mede quanto tempo cada etapa consome, quanto ela custa em tokens, e onde o erro se acumula.<\/p>\n","protected":false},"excerpt":{"rendered":"
Como a Fyxer usa fine-tuning supervisionado, LoRA, DPO e uma malha de 30 a 50 modelos especializados para gerar rascunhos de email que soam como voc\u00ea.<\/p>\n","protected":false},"author":2,"featured_media":720,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-721","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/721","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/comments?post=721"}],"version-history":[{"count":0,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/721\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media\/720"}],"wp:attachment":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media?parent=721"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/categories?post=721"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/tags?post=721"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}