Devo adotar o Langchain?
LangChain é um framework que facilita a criação de aplicações baseadas em LLMs, como o GPT.
O LangChain permite a integração entre os modelos de linguagem e várias fontes de conhecimento, otimizando a maneira como os desenvolvedores constroem agentes inteligentes que utilizam processamento de linguagem natural para responder a perguntas e executar tarefas.
O LangChain tem rapidamente se popularizado na comunidade de desenvolvimento (com mais de 85K ⭐️ no GitHub) e é um dos frameworks mais utilizados no momento para construção de aplicações baseadas em LLMs.
No entanto, o uso do framework tem sido alvo de questionamentos. Parte dessas críticas está relacionado a dificuldade de uso do LangChain. No último Tech Radar de Abril de 2024, a ThoughtWorks sugere inclusive a pausa na adoção do framework, colocando como sugestões outras soluções, como o SemanticKernel, da Microsoft.
Nesse texto, ofereço minhas enviesadas considerações sobre o uso do LangChain.
📚 Você é dev e quer criar aplicações baseadas em LLMs?
No próximo dia 15/06/2024 (sábado), vai rolar um bootcamp online de 3h:30m de duração, sobre desenvolvimento de aplicações baseadas em LLMs. Vai ser super hands on!
Alguns dos tópicos abordados:
🟠 Entendendo sobre LLMs
🟣 Testando prompts e engenharia de prompts
🔵 Entendendo de embeddings
🟢 Comparando dados por similaridade
🟡 Conectando com um banco vetorial
E tem mais! Se inscrevendo no bootcamp, você ganha acesso a três cursos sobre LLMs.
Interessou? Clique aqui e saiba mais:
Meu uso do LangChain
Tenho sido usuário do LangChain há cerca de um ano, e nesse meio tempo acompanhei várias mudanças que aconteceram na estrutura do framework.
Como fui evoluindo meu uso junto com a própria evolução do framework, acompanhei algumas modificações significativas que aconteceram, como por exemplo, a frequente adoção de novos loaders, bem como algumas separações de interfaces em pacotes específicos, como mais recentemente a separação dos splitters em um próprio pacote, chamado langchain-text-splitters.
Mas confesso que eu só percebi as mudanças mais significativas no framework quando eu refiz o treinamento do LangChain oferecido pela DeepLearning.ai. Refazer o treinamento, que possivelmente foi desenhado em alguma versão 0.0.x, mas já utilizando versões 0.1.x, me fez perceber o quanto que o treinamento envelheceu rápido. As APIs que foram usadas no treinamento já estavam depreciadas, ou mesmo removidas. Refazer o treinamento se tornou bem difícil.
Inclusive, com a introdução do LCEL, alguns usos importantes do framework mudaram drasticamente. Acredito que a visão é que o LCEL se torne a forma padrão para uso do framework. No entanto, enquanto o framework migra suas paulatinamente suas interfaces para o LCEL, é preciso conviver com as interfaces antigas junto com as novas.
Problemas observados com o LangChain
Listo aqui alguns problemas observados.
Dificuldade de uso
O LangChain apresenta uma complexidade desnecessária para tarefas simples, incorporando múltiplas classes de objetos e templates de prompts que complicam operações básicas.
Essa abordagem aumenta o esforço de codificação e compreensão, fazendo com que tarefas que poderiam ser realizadas com poucas linhas de código em bibliotecas padrão exigem estruturas mais elaboradas e menos intuitivas no LangChain. Esse excesso de complexidade não apenas dificulta o aprendizado por novos usuários, mas também desencoraja a adoção para projetos menores ou menos complexos.
É verdade que o LCEL simplifica boa parte desse processo, mas, como mencionado anteriormente, o LCEL ainda não cobre amplamente os diversos usos do framework.
Documentação desatualizada
Talvez por conta do desenvolvimento acelerado do framework (vários releases por mês, e até por semana), alguns pontos da documentação não foram atualizados na mesma velocidade.
Por conta disso, não era incomum encontram exemplos de trechos de códigos que não funcionam conforme esperado sem modificações adicionais. Isso acontecia por uso de dependências desatualizadas ou falta de explicações claras. Para um projeto open source, documentação é chave, e alguns pequenos problemas acabam por desencorajar potenciais usuários. Isso era particularmente frustrante quando os demais exemplos de código que encontrava usavam versões diferentes das APIs. Imagina a mistura.
Falta de clareza sobre uso dos Agents
Agents e tools são funcionalidades que tem grande potencial de uso. Agents servem para orquestrar a interação entre diferentes tools e uma LLMs, permitindo descobrir e executar ações complexas em sequência.
No entanto, a documentação sobre como Agents e tools funcionam ainda é vaga, deixando os usuários sem uma compreensão clara de como funcionam ou como implementar de maneira eficaz. Lembro de discutir extensivamente sobre quais são os potenciais cases de uso de Agents com alguns colegas.
O processo de descoberta de tools por um Agent é algo pouco claro. Por exemplo, não sabemos como as tools são selecionadas e utilizadas dentro de um fluxo de Agent, ou como os resultados são gerenciados e apresentados.
O processo de tratamento de exceção de agentes também é confuso; caso uma tool não seja encontrada, ou caso a tool retorne um erro, o usuário tem pouco controle do fluxo excepcional, reduzindo a eficácia geral do sistema.
Mas afinal, devo usar o LangChain?
Apesar das limitações mencionadas acima, ainda acredito que o uso do LangChain é muito benéfico, principalmente para aqueles que estão iniciando sua jornada no processo de criação de aplicações baseadas em LLMs.
O LangChain facilita muito o processo de carregamento de conteúdo externas, processamento dos dados, criação de embeddings, armazenamento de dados em bancos de dados vetoriais, etc. Inclusive, no bootcamp LLM4Devs, nós usamos o LangChain para criar uma aplicação RAG simples, em poucas horas.
Ademais, o problema da complexidade do uso do LangChain deve ser minimizado nas próximas versões, principalmente com a estabilização da LCEL.
Pra finalizar, não custa lembrar que essas são apenas as minhas próprias observações, baseada no meu uso da ferramenta. Aconselho você leitor a avaliar suas próprias percepções, antes de tomar uma decisão sobre usar (ou não) o framework.