Como seres humanos, aprendemos a fazer coisas novas, como balé ou boxe (ambas as atividades que tive a oportunidade de experimentar neste verão!), Através de tentativa e erro. Melhoramos tentando as coisas, aprendendo com nossos erros e ouvindo orientação. Conheço bem esse loop de feedback-parte do meu projeto de estagiário para o verão estava ensinando um modelo de recompensa a identificar melhores correções de código para mostrar os usuários, como parte do esforço do Databricks para criar um assistente de código de primeira linha.
No entanto, meu modelo não foi o único aprendizado por tentativa e erro. Enquanto ensinava meu modelo a distinguir boas correções de código dos ruins, aprendi a escrever código robusto, latência de equilíbrio e preocupações de qualidade para um produto impactante, comunicar claramente a uma equipe maior e, acima de tudo, se divertir ao longo do caminho.
Databricks Assistente de correção rápida
Se você já escreveu código e tentou executá -lo, apenas para obter um erro irritante, então você apreciaria Correção rápida. Notebooks e editores de SQL da Databricks, o Fast Repair foi projetado para correções de alta confiança que podem ser geradas em 1-3 segundos-ideais para erros de sintaxe, nomes de colunas com ortografia e erros de tempo de execução simples. Quando a correção rápida é acionada, ele pega o código e uma mensagem de erro e usa um LLM para gerar uma correção direcionada para resolver o erro.
Que problema meu projeto estagiário abordou?
Embora a correção rápida já existisse e ajudasse os usuários do Databricks a corrigir seu código, havia muitas maneiras de torná -lo ainda melhor! Por exemplo, depois de gerar uma correção de código e fazer algumas verificações básicas de que ela passa convenções de sintaxe, como podemos garantir que a correção que acabamos mostrando a um usuário seja a mais relevante e precisa? Digite a melhor amostragem-Ok-genera várias sugestões de correção possíveis e use um modelo de recompensa para escolher o melhor.
Minha estrutura de projeto
Meu projeto envolveu uma mistura de implementação de again -end e experimentação de pesquisa, que achei divertida e cheia de aprendizado.
Gerando várias sugestões
Expandi o fluxo de again -end do Repair Rick para gerar sugestões diversas em paralelo usando diferentes prompts e contextos. Eu experimentei técnicas como adicionar raciocínio de cadeia de pensamento, raciocínio previsto, variações imediatas do sistema e contexto seletivo do banco de dados para maximizar a qualidade e a diversidade de sugestões. Descobrimos que gerar sugestões com raciocínio adicional aumentou nossas métricas de qualidade, mas também induziu algum custo de latência.
Escolhendo a melhor sugestão de correção para mostrar ao usuário
Depois que várias sugestões são geradas, precisamos escolher o melhor para retornar. Comecei implementando uma simples linha de base de votação majoritária, que apresentou ao usuário a correção mais frequentemente sugerida – operando o princípio de que uma solução mais comumente gerada provavelmente seria a mais eficaz. Essa linha de base teve um bom desempenho nas avaliações offline, mas não teve um desempenho significativamente melhor do que a implementação atual nos testes on -line do usuário A/B, portanto não foi lançado para a produção.
Além disso, desenvolvi modelos de recompensa para classificar e selecionar as sugestões mais promissoras. Treinei os modelos para prever quais correções os usuários aceitariam e executariam com sucesso. Usamos abordagens clássicas de aprendizado de máquina (regressão logística e árvore de decisão aumentada de gradiente usando o Pacote LightGBM) e LLMs de ajuste fino.
Resultados e impacto
Surpreendentemente, para a tarefa de prever o sucesso da aceitação e da execução do usuário das correções candidatas, os modelos clássicos tiveram um desempenho comparável aos LLMs ajustados em avaliações offline. O modelo de árvore de decisão em explicit pode ter um bom desempenho, porque as edições de código que “parecem certas” para os tipos de erros que as alças de correção rápida tendem a estar corretas: os recursos que acabaram sendo particularmente informativos foram os semelhança entre a linha unique de código e a correção gerada, bem como o tipo de erro.
Dado esse desempenho, decidimos implantar o modelo de árvore de decisão (LightGBM) na produção. Outro fator a favor do modelo LightGBM foi seu tempo de inferência significativamente mais rápido em comparação com o LLM ajustado. A velocidade é elementary para a correção rápida, pois as sugestões devem aparecer antes que o usuário edite manualmente seu código, e qualquer latência adicional significa menos erros corrigidos. O tamanho pequeno do modelo LightGBM tornou muito mais eficiente e mais fácil de produzir de recursos – ao lado de algumas otimizações de modelo e infraestrutura, conseguimos diminuir nosso tempo médio de inferência em quase 100x.
Com a melhor abordagem e modelo de recompensa implementada, conseguimos aumentar nossa taxa de aceitação interna, aumentando a qualidade para nossos usuários. Também fomos capazes de manter nossa latência dentro dos limites aceitáveis de nossa implementação unique.
Se você quiser saber mais sobre o Assistente de Databricks, confira o Página de destino ou o Anúncio de correção rápida do assistente.
Minha experiência de estágio
Cultura de Databricks em ação
Este estágio foi uma experiência incrível para contribuir diretamente para um produto de alto impacto. Eu ganhei uma visão em primeira mão sobre como a cultura dos Databricks incentiva um forte preconceito para ação mantendo uma barra alta para a qualidade do sistema e do produto.
Desde o início, notei o quão inteligente e humilde todo mundo period. Essa impressão só ficou mais forte com o tempo, pois vi o quão genuinamente apoia a equipe. Mesmo engenheiros muito seniores se esforçam regularmente para me ajudar a ter sucesso, seja conversando sobre desafios técnicos, oferecendo suggestions atencioso ou compartilhando suas abordagens e aprendizados anteriores.
Gostaria especialmente de dar um grito ao meu mentor Will Tipton, meus gerentes Phil Eichmann e Shanshan Zheng, meus mentores informais Rishabh Singh e Matt Hayes, o editor / equipe assistente, a equipe de IA aplicada e o pessoal da Mosaicml para sua orientação. Aprendi habilidades inestimáveis e lições de vida deles, o que levarei comigo pelo resto da minha carreira.
Os outros estagiários incríveis!
Por último, mas não menos importante, eu me diverti muito conhecendo os outros estagiários! A equipe de recrutamento organizou muitos eventos divertidos que nos ajudaram a conectar – um dos meus favoritos foi a Internation Olympics (na foto abaixo). Seja conversando durante o almoço, experimentando aulas de exercícios locais ou comemorando aniversários com karaokê, eu realmente apreciei o quão solidário e unido period o grupo de estagiários, dentro e fora do trabalho.
Jogos Olímpicos Internacionais! GO EQUIPE 2!
Grite para os outros estagiários que tentaram boxe comigo!
Este verão me ensinou que o melhor aprendizado acontece quando você está resolvendo problemas reais com restrições reais – especialmente quando você está cercado por pessoas inteligentes, motivadas e solidárias. A parte mais gratificante do meu estágio não foi apenas concluir o treinamento do modelo ou apresentar resultados interessantes para a equipe, mas percebendo que cresci na minha capacidade de fazer perguntas melhores, raciocinar através de trade-offs de design e entregar um recurso concreto do início ao fim em uma plataforma tão amplamente utilizada quanto os bancos de dados.
Se você deseja trabalhar em projetos de ponta com companheiros de equipe incríveis, recomendo que você se inscreva para trabalhar no Databricks! Visite o Página de carreiras de banco de dados Para saber mais sobre as vagas de emprego em toda a empresa.