LinkedIn: construindo um produto de GenAI

01 · CONTEXTO

Um assistente dentro do feed e das vagas

O LinkedIn descreve um assistente que transforma cada post do feed e cada vaga em ponto de partida para perguntas. Quando a pessoa clica numa pergunta sugerida, o sistema decide qual agente de IA é o mais adequado para respondê-la.

Esse agente chama uma combinação de APIs internas e do Bing para montar um dossiê que ancora a resposta. Com o material em mãos, o agente escreve a resposta.

1. A pessoa clica numa pergunta sugerida ao lado de um post, e a pergunta entra no pipeline.

2. O roteamento decide se a pergunta está no escopo e para qual agente encaminhá-la.

3. O agente decide quais serviços chamar e reúne material nas APIs internas e no Bing.

4. A geração filtra os dados ruidosos recuperados e produz a resposta final.

5. A resposta sintetizada é transmitida em stream até o cliente.

02 · PIPELINE

Roteamento, recuperação e geração

O pipeline segue o padrão de geração aumentada por recuperação. O roteamento decide se a pergunta está no escopo e para qual agente encaminhá-la; a recuperação é uma etapa orientada a recall, em que o agente decide quais serviços chamar e como; a geração é uma etapa orientada a precisão, que filtra os dados ruidosos e produz a resposta final.

Roteamento e recuperação pareciam problemas de classificação, então a equipe montou conjuntos de desenvolvimento e os ajustou com engenharia de prompt e modelos próprios. Entre as escolhas que funcionaram estão modelos pequenos para roteamento e recuperação e modelos maiores para a geração.

A geração foi diferente: seguiu a regra 80/20. Chegar a 80% foi rápido, mas os 20% finais tomaram a maior parte do trabalho.

A equipe teve 80% da experiência básica no primeiro mês e levou mais quatro meses tentando passar de 95% de conclusão da experiência completa. Os scores de qualidade subiram no início e logo estagnaram, e o trabalho lembrou mais o ajuste de regras em sistemas especialistas.

03 · AGENTES E EQUIPES

Agentes independentes e pods horizontais

Para avançar rápido com várias equipes, o trabalho foi dividido em agentes independentes, desenvolvidos por pessoas diferentes: conhecimento geral, avaliação de vaga e resumo de posts. O ganho de velocidade veio com fragmentação: manter uma experiência uniforme ficou difícil quando as interações seguintes podiam ser tratadas por modelos, prompts ou ferramentas diferentes.

A resposta foi organizacional: um pequeno pod horizontal cuida dos componentes comuns e da experiência como um todo, e vários pods verticais têm autonomia sobre seus agentes.

04 · SKILLS E SAÍDA ESTRUTURADA

Empacotar APIs para o LLM

Os dados exclusivos do LinkedIn sobre pessoas, empresas, habilidades e cursos não fazem parte do treinamento dos LLMs. Eles ficam em APIs RPC, convenientes para humanos mas pouco amigáveis a LLMs; a solução foi envolvê-las em skills, dentro de um padrão RAG.

Cada skill reúne uma descrição amigável ao LLM sobre o que a API faz e quando usá-la, a configuração para chamar a RPC (endpoint, esquemas de entrada e saída), esquemas amigáveis ao LLM com valores primitivos e a lógica que converte entre esses esquemas e os da RPC.

1. O agente pede ao LLM que decida qual skill usar e com quais parâmetros.

2. Os parâmetros voltam em YAML, de forma estruturada, e passam pelo parser defensivo antes de ser interpretados.

3. A skill aplica a lógica que converte entre os esquemas amigáveis ao LLM e os esquemas reais da RPC.

4. A skill chama a API RPC interna com a configuração de endpoint e esquemas.

Os prompts pedem que o LLM decida qual skill usar e, como os parâmetros precisam casar com o esquema de entrada, que os devolva de forma estruturada. A equipe escolheu YAML por ser menos verboso e consumir menos tokens que JSON.

Cerca de 90% das vezes os parâmetros vinham no formato certo, mas em cerca de 10% o LLM errava, devolvendo dados inválidos para o esquema ou até YAML inválido. Re-solicitar o LLM adiciona latência e consome capacidade de GPU, então a equipe escreveu um parser YAML defensivo, que detecta e corrige erros comuns antes do parsing, e acrescentou dicas sobre esses erros aos prompts. Com isso, reduziu os erros para cerca de 0,01%.

05 · AVALIAÇÃO

Medir a qualidade das respostas

Avaliar a qualidade foi mais difícil do que o esperado, em três frentes: diretrizes, escala de anotação e avaliação automática.

Em avaliação de vaga, receber a resposta de que a pessoa é um péssimo encaixe não é muito útil: a resposta deve ser factual, mas também empática, porque alguns membros precisam entender as lacunas e os próximos passos. Detalhes consistentes eram essenciais para a uniformidade das notas dos anotadores.

A equipe linguística interna construiu ferramentas e processos para avaliar até 500 conversas por dia, com métricas como qualidade geral, taxa de alucinação, violação de IA responsável, coerência e estilo. Essa avaliação virou o principal indicador de tendência, para iterar em prompts e garantir que estavam prontos para ir ao ar.

A avaliação automática é descrita como o santo graal, mas ainda em andamento. Sem ela, engenheiros ficam olhando resultados no olho e testando poucos exemplos, com atraso de mais de um dia para saber as métricas. A equipe construía avaliadores baseados em modelo e teve algum sucesso em detecção de alucinação.

06 · LATÊNCIA E CAPACIDADE

Streaming, TTFT, TBT e custo

Capacidade e latência percebida pelo membro estiveram sempre no centro das atenções. Chain of Thought melhora a qualidade e reduz alucinações, mas exige tokens que o membro nunca vê, aumentando a latência percebida.

Todas as requisições usam streaming para reduzir a latência percebida, e isso vale dentro do pipeline, de ponta a ponta: a resposta do LLM que decide quais APIs chamar é interpretada progressivamente, e as chamadas disparam assim que os parâmetros estão prontos. A resposta final sintetizada também é transmitida até o cliente, com processamento incremental, por exemplo, da classificação de confiança e IA responsável.

Também foi construído um pipeline totalmente assíncrono e não bloqueante, sem desperdiçar recursos com threads bloqueadas em I/O.

No início só o TTFT era limitado, pois mapeava direto na latência do membro. Com o Chain of Thought nos prompts, a equipe negligenciou que o TBT pesaria muito mais: para um passo de raciocínio de 200 tokens, 10 ms a mais de TBT significam 2 s extras de latência. Algumas tarefas bateram em timeouts e a equipe teve de aumentar a capacidade rapidamente.

É comum obter 2x ou 3x mais tokens por segundo ao sacrificar TTFT e TBT, e a equipe inicialmente os limitou de forma apertada. Clusters de GPU são difíceis de conseguir e caros, e no início foi preciso definir horários em que era permitido testar o produto.