Assistente de código (estilo Copilot)

01 · CONTEXTO E REQUISITOS

O que um assistente de código precisa fazer

O Copilot da GitHub é o exemplo usado neste caso. Segundo a fonte, o Codex, descendente do GPT-3, foi o modelo escolhido para movê-lo, e o produto passou de prévia técnica em junho de 2021 para disponibilidade geral em junho de 2022. Projetar um assistente assim é um exercício de design de sistemas de ML.

O objetivo declarado pela equipe é entregar respostas relevantes ao contexto com baixa latência. O desafio, nas palavras dela, é decidir não só quais dados enviar ao modelo, mas também em que ordem e de que forma inseri-los.

02 · DESENHO DO SERVIÇO

Do teclado ao modelo e de volta à telemetria

O desenho abaixo é uma leitura didática para entrevista, montada a partir dos pontos que a fonte descreve.

1. A IDE é quem dispara o processo: segundo a fonte, os prompts são gerados em segundo plano em qualquer ponto da digitação.

2. Neste desenho, o gateway é a porta de entrada do serviço e recebe os pedidos vindos da IDE.

3. A montagem de contexto seleciona trechos do arquivo atual e de outras fontes e depois os prioriza, filtra e monta no prompt final.

4. O cache entra para que a montagem rode em segundo plano sem latência adicional.

5. O servidor do modelo é onde a sugestão é gerada; no Copilot, o modelo que o moveria era o Codex, descendente do GPT-3.

6. A telemetria recebe da IDE as sugestões aceitas ou ignoradas; a fonte avalia as técnicas de contexto justamente pela aceitação das completions mostradas, em testes A/B.

A fonte diz que os prompts são gerados em segundo plano em qualquer ponto da digitação e que, graças ao uso otimizado de cache, as abas vizinhas e o FIM funcionam sem latência adicional. É um caso típico de cuidar de latência no caminho da requisição.

03 · CONTEXTO SOB ORÇAMENTO

Nem todo o código cabe no prompt

Na época do texto, os transformers rápidos o bastante para o Copilot processavam cerca de 6.000 caracteres por vez. Esse limite significa que nem todo o código da pessoa pode virar contexto.

Para escolher o que entra, uma série de algoritmos seleciona trechos de código e comentários do arquivo atual e de outras fontes; esses trechos são depois priorizados, filtrados e montados no prompt final.

1. A primeira versão considerava só o arquivo aberto na IDE como contexto.

2. As abas vizinhas passam a buscar, nos demais arquivos abertos, trechos parecidos com o código ao redor do cursor e os acrescentam ao prompt.

3. A recuperação no repositório é descrita como experimento: embeddings dos trechos ficariam num banco vetorial, com correspondência aproximada em tempo real.

4. A montagem prioriza, filtra e monta o prompt final com o que as fontes entregam.

5. Com o FIM, o prompt indica ao modelo qual parte é prefixo e qual é sufixo, e a sugestão cobre o trecho que deve ficar entre os dois.

Ao desenvolver as abas vizinhas, a equipe concluiu que um critério bem baixo para incluir uma correspondência rendeu as melhores sugestões. Incluir a melhor correspondência encontrada, mesmo imperfeita, foi melhor do que não incluir nada.

04 · FIM E ACEITAÇÃO

Prefixo, sufixo e a métrica que importa

Antes do FIM, só o código anterior ao cursor entrava no prompt. A GitHub chama o código antes do cursor de prefixo e o código depois dele de sufixo; com o FIM, é possível dizer ao modelo qual parte do prompt é qual.

A fonte mede esses ganhos pela aceitação das sugestões: as abas vizinhas elevaram a aceitação relativa em 5%, e o FIM rendeu 10% a mais de completions aceitas nos testes A/B.

05 · RECUPERAÇÃO NO REPOSITÓRIO

O passo seguinte: embeddings e banco vetorial

A fonte descreve, como experimento, o uso de bancos vetoriais para uma experiência personalizada em repositórios privados. Os algoritmos criariam embeddings de todos os trechos do repositório, potencialmente bilhões, e fariam correspondências aproximadas em tempo real com os trechos da IDE.

O recurso era pensado para clientes corporativos que aceitassem usá-lo de forma explícita (opt-in).

06 · PONTOS PARA DISCUTIR

Trade-offs que o entrevistador costuma explorar

Pontos para discutir: tamanho do contexto contra latência, custo de consultar mais fontes contra qualidade da sugestão, e como medir a aceitação sem atrasar a digitação.

Vale também perguntar o que acontece quando o modelo demora: uma sugestão tardia perde o valor, e o cliente pode preferir não mostrar nada.