GitHub Copilot: montagem de contexto

01 · CONTEXTO

Um assistente que precisa adivinhar o contexto

O GitHub Copilot é descrito pelo blog do GitHub como um programador em par com IA. Ele entrou em prévia técnica em junho de 2021 e teve disponibilidade geral em junho de 2022. O modelo por trás é o Codex, um descendente do GPT-3.

O ponto central do caso é o contexto. Os modelos rápidos o bastante para o Copilot processavam, à época do texto, cerca de 6.000 caracteres por vez, e por isso nem todo o código de uma pessoa cabe como contexto. O desafio, nas palavras da fonte, é decidir quais dados enviar ao modelo e em que ordem enviá-los.

02 · MONTAGEM DO PROMPT

O prompt é uma montagem sob orçamento

Segundo a fonte, os prompts são compilações de código da IDE e contexto relevante enviados ao modelo, gerados por algoritmos em segundo plano em qualquer ponto da digitação.

1. Em qualquer ponto da digitação, a IDE aciona a montagem de um novo prompt.

2. A biblioteca de prompt seleciona trechos de código e comentários do arquivo atual e de outras fontes.

3. Os trechos são priorizados, filtrados e montados no prompt final, que precisa caber na janela limitada do modelo.

4. O uso otimizado de cache permite que a montagem funcione em segundo plano sem latência extra.

5. O prompt montado segue para o modelo, que gera a sugestão.

A maior parte desse trabalho acontece no que a GitHub chama de biblioteca de prompt, onde especialistas de ML e algoritmos extraem e priorizam as fontes de informação sobre o contexto da pessoa. A primeira versão considerava só o arquivo em que a pessoa trabalhava.

03 · NEIGHBORING TABS E FIM

Duas técnicas que ampliam o contexto

Neighboring tabs permite processar todos os arquivos abertos na IDE, e não só o arquivo atual: o sistema procura nesses arquivos trechos que casem com o código ao redor do cursor e os adiciona ao prompt.

Nos testes A/B, um limiar muito baixo para incluir uma correspondência deu as melhores sugestões. Segundo o engenheiro Albert Ziegler, citado no texto, incluir a melhor correspondência encontrada, mesmo sem ser perfeita, foi melhor do que não incluir nada.

Antes do FIM, só o código antes do cursor, o prefixo, entrava no prompt. O código depois do cursor, o sufixo, ficava de fora. Com FIM, o prompt informa ao modelo qual parte é prefixo e qual é sufixo, e a sugestão passa a ser o código que deve ficar entre as duas.

Segundo a fonte, graças ao uso otimizado de cache, as duas técnicas funcionam em segundo plano sem latência extra.

04 · RECUPERAÇÃO SEMÂNTICA

O próximo passo, ainda experimental: embeddings do repositório

O texto descreve experimentos com bancos de vetores para uma experiência personalizada em repositórios privados ou com código proprietário. Ferramentas generativas de código usam embeddings para recuperar informação desse tipo de banco.

1. No desenho proposto, o indexador gera embeddings de todos os trechos do repositório, potencialmente bilhões.

2. Os vetores ficam guardados no banco de vetores.

3. Durante a programação, os trechos da IDE também viram embeddings.

4. O banco de vetores busca correspondências aproximadas, e não só exatas, mesmo com bilhões de trechos guardados.

5. No diagrama, o resultado da busca segue para a biblioteca de prompt.

O recurso é pensado para clientes corporativos com repositórios privados que aceitariam usá-lo explicitamente. A fonte usa o condicional, e a análise do ZenML observa que ele é descrito como experimental, sem dados de desempenho.

05 · LIÇÕES

O que levar para um design parecido

A fonte mostra práticas que se repetem: aceitar correspondências fracas em vez de nada, validar cada técnica por teste A/B de aceitação das sugestões e sustentar a baixa latência com cache.