Já há algum tempo que a ideia de ter um parceiro de programação de IA diretamente num notebook Jupyter tem sido vista como o santo graal para cientistas de dados e programadores. Quando ferramentas como o GitHub Copilot começaram a fazer sucesso, isso só fez com que todos quisessem ainda mais esse mesmo poder dentro dos seus notebooks. O motor por trás dessas ferramentas iniciais era o OpenAI Codex, um modelo que prometia transformar inglês simples em código funcional.
Este guia irá conduzi-lo pela história do Codex e da sua jornada com o Jupyter, analisar as ferramentas modernas que tomaram o seu lugar e defender por que os verdadeiros ganhos de produtividade vêm de olhar para além do notebook, para uma IA que compreende toda a base de conhecimento da sua equipa.
O que foi o OpenAI Codex?
O OpenAI Codex foi um sistema de IA que conseguia receber prompts em linguagem natural e produzir código. Era um derivado do GPT-3, treinado numa quantidade massiva de texto e milhares de milhões de linhas de código público. Foi isto que alimentou a primeira versão do GitHub Copilot.
O Codex era bastante versátil, lidando com mais de uma dúzia de linguagens como Python, JavaScript e Ruby. Fazia mais do que apenas autocompletar; conseguia explicar o que um bloco de código fazia, traduzir código entre linguagens e até ajudar a refatorar o seu trabalho.
Mas aqui está uma peça crucial do puzzle: os modelos originais do OpenAI Codex foram oficialmente descontinuados em março de 2023. Embora a tecnologia subjacente tenha evoluído e os seus sucessores estejam agora integrados nos modelos mais recentes da OpenAI, a API específica do Codex na qual todas as integrações iniciais foram construídas desapareceu. Essa única mudança praticamente remodelou todo o cenário para as ferramentas de IA no Jupyter.
O esforço da comunidade para integrar o OpenAI Codex no Jupyter
Antes de surgirem quaisquer ferramentas oficiais, a comunidade de programadores já estava a trabalhar arduamente para tentar levar a IA para o seu ambiente de notebook favorito. Muitos cientistas de dados e engenheiros de ML vivem no Jupyter, e o fluxo de trabalho iterativo, célula a célula, é simplesmente a forma como pensam. Ter de saltar para o VS Code apenas para usar o Copilot parecia uma interrupção "incómoda" e desajeitada.
Soluções iniciais criadas pela comunidade
Esta frustração desencadeou uma série de projetos de código aberto. Ferramentas como "gpt-jupyterlab" e "jupyterlab-codex" surgiram, permitindo aos programadores enviar o conteúdo de uma célula do notebook para a API da OpenAI. A configuração era geralmente bastante simples: "pip install" um pacote, inserir a sua chave de API da OpenAI nas configurações do JupyterLab, e obteria um novo botão para gerar código. Estas ferramentas foram um ótimo exemplo da comunidade a construir o que precisava.
Desafios e limitações das integrações iniciais
Apesar de promissoras, estas integrações iniciais tiveram a sua quota-parte de dores de cabeça que as tornaram difíceis de confiar a longo prazo:
-
As dores de cabeça na configuração: Os utilizadores encontravam frequentemente obstáculos durante a instalação, especialmente em servidores remotos. Muitos destes plugins necessitavam de um reinício completo do servidor JupyterLab para funcionar, e descobrir por que a sua configuração não estava a funcionar podia consumir uma boa parte da sua tarde.
-
Modelos desatualizados: A maioria destas ferramentas foi construída especificamente para os modelos Codex originais. Assim que estes foram descontinuados, as extensões basicamente deixaram de funcionar, a menos que fossem completamente reformuladas para usar modelos mais recentes (e com preços diferentes) da OpenAI.
-
O maior ponto cego: falta de contexto: O problema mais fundamental era que estas ferramentas estavam a trabalhar no vácuo. Conseguiam ver o código numa célula, mas não tinham acesso algum à documentação do projeto no Confluence, às especificações nos Google Docs, ou àquele esclarecimento crucial que o seu gestor publicou no Slack. A IA conseguia escrever código, mas não sabia porquê o estava a escrever.
O cenário atual
As coisas definitivamente amadureceram desde os dias dos simples plugins do Codex. O foco passou de hacks de modelo único para frameworks mais sólidos e flexíveis que se podem conectar a uma variedade de diferentes fornecedores de IA.
A ascensão do "jupyter-ai"
O principal interveniente hoje é o "jupyter-ai", um projeto oficial da equipa do Jupyter. Ele coloca a IA generativa diretamente dentro do JupyterLab e dos Jupyter Notebooks. Em vez de estar preso a um modelo antigo, o "jupyter-ai" é mais como um adaptador universal, para toda uma gama de modelos modernos de fornecedores como OpenAI, Anthropic, Cohere, e até modelos de código aberto da Hugging Face.
Ele vem com uma interface de chat integrada onde pode fazer perguntas sobre o seu código, além de práticos "comandos mágicos" "%%ai"". Estes permitem gerar código, corrigir erros, ou até criar funções inteiras a partir de um simples prompt dentro de uma célula do notebook.
Considerações sobre preços e configuração
Embora o "jupyter-ai" seja de código aberto, os modelos poderosos aos quais se conecta não são gratuitos. Precisará de uma chave de API de um fornecedor como OpenAI ou Anthropic, e será cobrado pelo que utiliza, geralmente com base em "tokens" (os pedaços de palavras que a IA processa). Os dias das betas gratuitas acabaram; ter acesso a modelos bons o suficiente para programação é agora um serviço pago. Por exemplo, os modelos mais recentes da OpenAI estão disponíveis através da sua API ou como parte de planos como o ChatGPT Team ou Enterprise.
| Fornecedor | Modelos de Exemplo | Ideal para |
|---|---|---|
| OpenAI | "gpt-4o", "gpt-3.5-turbo" | Geração de código de propósito geral, explicação |
| Anthropic | "claude-3-sonnet" | Raciocínio complexo, manipulação de grandes contextos |
| Hugging Face | Vários modelos de código aberto | Tarefas especializadas, execução em infraestrutura própria |
Para além da conclusão de código: As limitações da IA no notebook
Mesmo com uma ferramenta sofisticada como o "jupyter-ai", ainda há uma grande limitação: a IA está presa dentro do ambiente de programação do programador. Um bom programador faz mais do que apenas escrever código. Ele precisa de compreender os objetivos do negócio, ler especificações técnicas e falar com a sua equipa. Um assistente de IA que não consegue ver nenhuma dessas informações está a resolver apenas metade do problema.
Pense em quanto do dia de um programador é gasto a trocar de contexto. Está focado num notebook, depois tem de parar, abrir um novo separador, pesquisar no Confluence por documentação da API, percorrer um canal do Slack para encontrar uma decisão que alguém tomou, ou abrir um Google Doc para verificar um design. Cada uma dessas pequenas interrupções quebra o seu foco e abranda o seu ritmo.
Unificar as suas ferramentas com um assistente de IA interno
É aqui que precisamos de pensar para além de um simples assistente de programação e começar a pensar numa plataforma de IA consciente do conhecimento. Enquanto o "jupyter-ai" traz um modelo para o seu notebook, uma ferramenta como a eesel AI traz todo o conhecimento disperso da sua empresa para a IA.
Com o chat interno da eesel AI, pode configurar um assistente que é treinado com os dados da sua própria organização. Ele conecta-se diretamente com as ferramentas nas quais a sua equipa já confia, como Notion, SharePoint e Microsoft Teams.
Imagine que um programador está a trabalhar no Jupyter e tem uma pergunta sobre um esquema de dados. Em vez de largar tudo para ir procurar na documentação, ele pode simplesmente perguntar ao bot da eesel AI no Slack: "Quais são os campos obrigatórios para a tabela "user_profiles"?" O bot dá-lhes uma resposta instantânea e precisa, retirada diretamente dos documentos oficiais da equipa. É isso que unificar o seu conhecimento faz: reduz a constante troca de contexto e permite que os programadores continuem com o seu trabalho.
Primeiros passos: Mudar para um fluxo de trabalho consciente do conhecimento
O caminho desde as primeiras integrações do OpenAI Codex com o Jupyter até onde estamos hoje mostra um padrão claro. Passámos de plugins básicos para assistentes flexíveis no notebook. O próximo passo lógico é um fluxo de trabalho de IA totalmente conectado e consciente do conhecimento. O futuro da produtividade dos programadores não se resume apenas a produzir código mais rapidamente; trata-se de ajudar os programadores a tomar melhores decisões com menos complicações.
E não precisa de um projeto enorme de meses para lá chegar. Com uma plataforma projetada para ser simples, pode começar rapidamente. Por exemplo, a eesel AI é construída para ser radicalmente self-service, o que significa que pode entrar em funcionamento em minutos, não em meses. Pode conectar as suas fontes de conhecimento e lançar um assistente de IA interno para a sua equipa sem ter de assistir a demos intermináveis ou projetos de implementação personalizados.
Construa de forma mais inteligente, não apenas mais rápida
A conclusão de código alimentada por IA no Jupyter é uma ferramenta fantástica que mudou a forma como muitos de nós trabalhamos. Mas ela realmente brilha quando a IA tem a imagem completa, o contexto da documentação, conversas e objetivos de negócio da sua equipa. Ao conectar todo o seu conhecimento interno, pode criar um assistente que não apenas escreve código, mas ajuda os seus programadores a construir o código certo, mais rapidamente.
Pronto para dar aos seus programadores uma IA que realmente entende o seu negócio? Experimente a eesel AI para unificar o seu conhecimento e dar um verdadeiro impulso à produtividade da sua equipa.
Perguntas frequentes
As integrações do OpenAI Codex com o Jupyter ainda são ativamente suportadas ou recomendadas para novos projetos de desenvolvimento hoje em dia?
Os modelos originais do OpenAI Codex, que alimentaram as primeiras integrações, foram oficialmente descontinuados em março de 2023. Embora a sua tecnologia subjacente tenha evoluído para novos modelos da OpenAI, a API específica do Codex já não está disponível, tornando as "integrações diretas do OpenAI Codex com o Jupyter" desatualizadas para novos projetos.
Se as integrações originais do OpenAI Codex com o Jupyter já não são suportadas, qual é a alternativa moderna para trazer IA para os notebooks Jupyter?
A principal alternativa moderna é o "jupyter-ai". Este projeto oficial do Jupyter funciona como um adaptador universal, conectando o JupyterLab e os Jupyter Notebooks a uma variedade de modelos de IA generativa atuais de fornecedores como OpenAI, Anthropic e Hugging Face.
Quais foram as principais limitações das primeiras integrações do OpenAI Codex com o Jupyter criadas pela comunidade?
As primeiras integrações sofriam frequentemente de complexidades na configuração, tornaram-se rapidamente desatualizadas quando os modelos Codex foram descontinuados e, crucialmente, não tinham acesso a um contexto de projeto mais amplo, como documentação ou discussões da equipa, operando num vácuo de conhecimento.
Existem custos associados à utilização de ferramentas modernas que evoluíram das integrações do OpenAI Codex com o Jupyter, como o "jupyter-ai"?
Sim, embora o "jupyter-ai" em si seja de código aberto, os poderosos modelos de IA aos quais se conecta geralmente exigem uma chave de API de um fornecedor (por exemplo, OpenAI, Anthropic) e implicam custos baseados no uso, geralmente cobrados por "tokens".
Como posso superar a limitação inerente de contexto que afetou as primeiras integrações do OpenAI Codex com o Jupyter e que ainda impacta a IA no notebook?
Para superar as limitações de contexto, precisa de uma plataforma de IA consciente do conhecimento que unifique toda a informação dispersa da sua equipa de ferramentas como Confluence, Slack e Google Docs. Isto permite que a IA forneça respostas e assistência com base em toda a base de conhecimento da sua organização, indo além do simples código num notebook.
Quais são os benefícios de ir além das integrações básicas do OpenAI Codex com o Jupyter para um fluxo de trabalho de IA abrangente e consciente do conhecimento?
Mudar para um fluxo de trabalho de IA consciente do conhecimento reduz significativamente a troca de contexto, ajuda os programadores a tomar melhores decisões, fornecendo acesso instantâneo ao conhecimento organizacional, e, em última análise, aumenta a produtividade geral para além da simples geração de código mais rápida.
