Alternativas ao LangChain: uma comparação das opções

A nossa posição: somos a Geonode e comercializamos proxies, que nada têm a ver com frameworks LLM. Não ganhamos nada, independentemente da sua escolha, o que torna esta comparação uma análise escrita por alguém sem qualquer interesse no resultado — uma posição invulgar numa categoria em que a maioria das comparações provém de um dos fornecedores. Todas as versões, licenças e atividade no repositório abaixo foram verificadas em setembro de 2026.

Por que razão as pessoas procuram alternativas

Vale a pena mencionar as queixas concretas, pois são elas que determinam qual a alternativa mais útil.

Profundidade de abstração. Depurar uma cadeia implica, frequentemente, ler o código-fonte do framework para perceber qual foi, de facto, o prompt enviado. A indireção que torna uma demonstração curta prolonga os incidentes em produção.

Evolução da API. O framework sofreu alterações substanciais ao longo da sua vida útil, e os tutoriais ficam rapidamente desatualizados. O código escrito para uma versão principal precisa de ser revisto.

Peso das dependências. Uma grande área de cobertura implica uma árvore de dependências extensa, o que é relevante em implementações com restrições e na análise de segurança.

Fazer demasiado. Cadeias, agentes, memória, recuperação, ferramentas, avaliação. A maioria dos projetos precisa de dois destes elementos e acaba por herdar todos eles.

Note-se que nenhuma destas críticas se refere às ideias. As abstrações do LangChain são descrições razoáveis do espaço do problema, e foi precisamente por isso que foram copiadas. As críticas dizem respeito ao custo de adotar uma estrutura completa para utilizar apenas uma parte dela.

Também vale a pena referir que o projeto não está parado: langchain está na versão 1.3.18 e langchain-core na 1.6.1, ambas lançadas no final de agosto de 2026, sob licença MIT, com o repositório entre os mais ativos da categoria. Muitas das críticas referem-se a uma versão mais antiga.

O panorama

Todos os dados provêm do PyPI e dos próprios repositórios dos projetos, verificados em setembro de 2026.

Todos em desenvolvimento ativo — cada um destes foi publicado poucos dias após a verificação. Todos com licenças permissivas. As diferenças residem no âmbito e na filosofia, e não na viabilidade.

LlamaIndex: A recuperação em primeiro lugar

A alternativa de uso geral mais próxima, que surge de uma perspetiva diferente.

Enquanto o LangChain começou por compor chamadas a LLMs, o LlamaIndex começou por ligar os LLMs aos seus dados — o seu próprio resumo é «interface entre os LLMs e os seus dados». Essa origem reflete-se naquilo em que se destaca: carregamento de documentos a partir de uma vasta gama de fontes, estratégias de segmentação, construção de índices e padrões de recuperação que vão além da simples similaridade «top-k».

Escolha-o quando a qualidade da recuperação for a parte mais difícil do seu problema. As suas abstrações de índice e motores de consulta são mais sofisticados do que os equivalentes numa estrutura geral, e o ecossistema de carregadores é suficientemente vasto para que ligar-se a uma fonte invulgar seja, normalmente, uma questão de uma única linha de código.

A ressalva é semelhante à do LangChain: tornou-se uma estrutura geral, pelo que a sua adoção para a recuperação traz consigo agentes, fluxos de trabalho e ferramentas que talvez não deseje.

Haystack: Pipelines de produção

A estrutura da Deepset, e a mais explicitamente orientada para a produção do grupo — descreve-se como uma estrutura «para criar aplicações LLM personalizáveis e prontas para produção».

A sua característica distintiva é que os pipelines são grafos explícitos de componentes com entradas e saídas declaradas, serializáveis para YAML. Isso torna o que está a ser executado inspecionável de uma forma que o encadeamento de métodos não permite, e faz com que um pipeline seja algo que se pode versionar, comparar e rever.

Escolha-o quando estiver a construir algo que será operado, em vez de apenas demonstrado — onde a capacidade de ver a estrutura do pipeline, serializá-la e analisá-la durante a revisão é mais importante do que o caminho mais curto para um protótipo funcional.

É também o único projeto sob a licença Apache-2.0 nesta lista, em vez da licença MIT, o que constitui uma distinção sem grande diferença prática — ambas são permissivas — mas que, ocasionalmente, pode ser relevante numa análise jurídica com uma preferência específica.

DSPy: Uma ideia verdadeiramente diferente

A alternativa mais interessante e a única que não é uma variação das outras.

A premissa do DSPy é que os prompts escritos manualmente são uma abstração errada. Declara-se o que um módulo deve fazer em termos de entradas e saídas, e a estrutura otimiza os prompts — incluindo exemplos «few-shot» — em função de uma métrica definida pelo utilizador.

A consequência é um ciclo de desenvolvimento diferente. Em vez de iterar manualmente sobre a formulação das instruções, constrói-se um conjunto de avaliação, define-se uma métrica e deixa-se o otimizador a pesquisar. Isso transforma a engenharia de instruções de um ofício em algo mais próximo de um procedimento de treino.

Escolha-o quando tiver uma tarefa com qualidade mensurável, um conjunto de avaliação e volume suficiente para que a otimização sistemática valha a pena. Classificação, extração e raciocínio estruturado são todos casos adequados.

Não o escolha quando não conseguir definir uma métrica ou quando a tarefa for pontual. Toda a abordagem assenta na capacidade de pontuar os resultados automaticamente, e construir esse conjunto de avaliação é o verdadeiro trabalho.

Com 37 000 estrelas e em desenvolvimento ativo, já ultrapassou há muito a fase experimental — mas exige mais de si à partida do que qualquer outra opção aqui apresentada.

Pydantic AI e Instructor: Deliberadamente Limitados

Dois projetos que, de forma deliberada, resolvem menos.

O Instructor faz uma única coisa: saídas estruturadas. Define-se um modelo Pydantic e ele trata do esquema, da validação e do ciclo de repetição em caso de dados inválidos. É isso que constitui toda a biblioteca.

Uma parte enorme do código das aplicações LLM consiste em «obter do modelo um JSON válido que corresponda a este formato», e o Instructor é a resposta completa para isso em poucas linhas, praticamente sem sobrecarga da estrutura. Se essa é a sua necessidade, adotar uma estrutura geral para a satisfazer é uma má escolha.

O Pydantic AI é mais abrangente — um framework de agentes «à maneira do Pydantic» — que traz segurança de tipos, injeção de dependências e saídas estruturadas para a construção de agentes. É mais recente do que os outros e está a crescer rapidamente, sendo particularmente apelativo para equipas que já investiram no Pydantic e na verificação de tipos.

Opte por estas opções quando o seu problema estiver bem definido e preferir utilizar uma biblioteca em vez de uma estrutura. A distinção é importante: uma biblioteca é algo a que se recorre, uma estrutura é algo que nos obriga a recorrer a ela, e é muito mais difícil abandonar a segunda.

Semantic Kernel: Empresarial e Multilíngue

A estrutura da Microsoft, e a que se deve ter em conta quando o Python não é a única opção.

As suas características distintivas são o suporte de primeira classe em .NET, Python e Java, e uma arquitetura construída em torno de plug-ins e planeadores que se adapta aos padrões de integração empresarial.

Opte por ele quando trabalhar num ambiente .NET, quando precisar dos mesmos conceitos em várias linguagens ou quando as decisões da sua organização em matéria de plataformas apontarem nessa direção. Estas são restrições reais e são frequentemente decisivas, independentemente do mérito técnico.

Para um projeto exclusivamente em Python, sem esse tipo de restrição, as opções nativas do Python têm, geralmente, mais impulso no ecossistema.

LangGraph: A alternativa dentro do LangChain

Vale a pena destacá-lo, porque é frequentemente isto que as pessoas realmente querem quando dizem que procuram uma alternativa.

O LangGraph — da mesma equipa, licenciado pelo MIT, na versão 1.2.11 — descreve-se como sendo destinado à «criação de aplicações com estado e múltiplos atores utilizando LLMs». Trata-se de um modelo de execução em grafo com estado explícito, em vez de uma abstração em cadeia.

Esta distinção é importante porque a maioria das queixas sobre o LangChain diz respeito ao fluxo de controlo oculto. O LangGraph torna o fluxo de controlo aquilo que escreves: nós, arestas, transições condicionais e um objeto de estado que defines. Isso torna-se consideravelmente mais legível quando algo corre mal às três da manhã.

Opte por ele quando a sua aplicação tiver um estado genuíno, ramificações ou ciclos — um agente que entra em loop, um fluxo de trabalho com etapas de aprovação, qualquer situação em que «o que acontece a seguir» dependa do que aconteceu antes. Pode ser utilizado sem adotar o resto do LangChain.

Sem framework: os argumentos a favor

A opção que a maioria dos artigos comparativos omite e a resposta certa para uma parte substancial das aplicações.

Os SDKs dos fornecedores de modelos já são bons. Chamar um diretamente requer apenas algumas linhas de código e é totalmente transparente:

response = client.messages.create(
    model=MODEL,
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}],
)

O que se perde: a abstração do fornecedor, integrações pré-construídas, componentes de recuperação prontos a usar e o ciclo do agente.

O que ganha: consegue ler o seu próprio código. O prompt enviado é o prompt que consta no ficheiro. A depuração consiste em ler um pedido e uma resposta, em vez de rastrear através das camadas da estrutura. A sua árvore de dependências é um único SDK. E as atualizações são as notas de lançamento do fornecedor, em vez do guia de migração de uma estrutura.

Uma posição intermédia razoável: utilize bibliotecas específicas para problemas concretos — o Instructor para saídas estruturadas, um cliente de base de dados vetorial para recuperação, um cliente HTTP para chamadas a ferramentas — e escreva você mesmo a orquestração. A orquestração tem normalmente cinquenta linhas, e cinquenta linhas que escreveu você próprio são mais fáceis de manter do que uma estrutura que não foi da sua autoria.

Quando uma estrutura de trabalho realmente justifica a sua utilização: quando precisa de muitas integrações com fornecedores, quando está a criar agentes com utilização complexa de ferramentas e quer que o ciclo seja gerido, quando uma equipa beneficia de convenções partilhadas, ou quando a velocidade de prototipagem é mais importante do que a legibilidade em produção. Estas são razões reais e aplicam-se a projetos reais.

O erro a evitar é adotar um framework para a demonstração e descobrir, em produção, que não consegue perceber o que ele faz.

Migrar de um framework

Se já tem uma aplicação LangChain e está a pensar mudar, o trabalho é mais previsível do que parece — e a sequência é importante.

Descubra primeiro o que a aplicação está realmente a enviar. Antes de alterar qualquer coisa, registe os prompts e parâmetros reais. A maioria das estruturas disponibiliza uma chamada de retorno ou um sinalizador de depuração para este efeito, e configurá-lo produz o artefacto mais útil de todo o exercício: um registo do que a sua aplicação faz, expresso como pedidos HTTP em vez de chamadas de método. Na metade das vezes, isto por si só revela que a estrutura está a fazer algo que não era a sua intenção.

Mude um componente de cada vez, não a aplicação inteira. As partes são separáveis. Substitua a etapa de recuperação por chamadas diretas do cliente à base de dados vetorial, mantendo o resto no lugar; confirme se a qualidade da saída permanece inalterada; depois, mude a parte seguinte. Uma reescrita radical confunde «o novo código está errado» com «o novo código é diferente», e perde-se a capacidade de distinguir qual das duas situações se verifica.

Mantenha um sistema de comparação de resultados. Execute ambas as implementações com as mesmas entradas e compare os resultados. A recuperação e a geração são suficientemente não determinísticas para que «parece estar tudo bem» não seja prova suficiente, e uma centena de pares de resultados irá revelar-lhe uma regressão que uma verificação pontual não detectaria.

Preveja que os modelos de prompt serão a parte mais difícil. Os modelos de prompt do framework incluem frequentemente código padrão que não escreveu e que talvez nem tenha lido — instruções de formatação, analisadores de saída, estruturas de «few-shot». Reproduzir o comportamento significa reproduzir esses elementos, e é por isso que capturar os prompts efetivamente enviados vem em primeiro lugar.

E seja honesto quanto ao facto de valer a pena ou não. Uma aplicação funcional que considere ligeiramente opaca não é, obviamente, pior do que uma reescrita que compreenda e que tenha novos erros. Os argumentos a favor da migração são fortes quando a estrutura lhe está a causar custos — tempo de depuração, complicações com atualizações, conflitos de dependências — e fracos quando a motivação é estética. As reescritas justificadas por uma questão de gosto têm um historial fraco.

O caminho intermédio realista para a maioria das equipas é deixar de adicionar novos componentes à estrutura, em vez de remover os existentes. Os novos componentes são escritos diretamente, e os antigos são deixados como estão até que seja necessário alterá-los.

Como escolher

Um procedimento breve que resolve a maioria dos casos.

Anote o que realmente precisa. Resultados estruturados? Recuperação? Agentes com várias etapas e ferramentas? Mudança de fornecedor? A maioria dos projetos precisa de um ou dois destes aspetos. É da adoção de uma estrutura geral para um único aspeto que advém o arrependimento.

Experimente primeiro sem uma estrutura. Meio dia a programar diretamente com um SDK permite-lhe perceber qual é realmente a parte mais difícil do seu problema, e essa resposta aponta normalmente para uma biblioteca específica, em vez de uma estrutura geral.

Escolha a ferramenta adequada à parte mais difícil. A qualidade da recuperação aponta para o LlamaIndex. A qualidade mensurável das tarefas com um conjunto de avaliação aponta para o DSPy. A extração estruturada aponta para o Instructor ou o Pydantic AI. Os fluxos de trabalho com várias etapas e estado apontam para o LangGraph ou o Haystack. O ambiente empresarial multilingue aponta para o Semantic Kernel.

Avalie o custo de saída. Quanto do seu código mudaria se o removesse? É fácil abandonar uma biblioteca que utiliza; um framework que controla o seu fluxo de execução, já não. Vale a pena colocar essa questão antes da adoção, e não depois.

E não escolha apenas com base na popularidade. Todas as opções aqui apresentadas são mantidas ativamente e têm licenças permissivas. A dimensão do ecossistema é importante para encontrar exemplos, mas não é sinónimo de adequação ao seu problema.

Perguntas frequentes

Qual é a melhor alternativa ao LangChain?

Depende da funcionalidade de que necessita. O LlamaIndex para aplicações com grande volume de recuperação de dados, o Haystack para pipelines de produção inspecionáveis, o DSPy para tarefas com qualidade mensurável, o Instructor ou o Pydantic AI para resultados estruturados e o LangGraph para fluxos de trabalho com estado. Para muitas aplicações, chamar diretamente o SDK do fornecedor é a melhor opção.

O LangChain ainda é mantido?

Sem dúvida. O langchain estava na versão 1.3.18 e o langchain-core na versão 1.6.1 no final de agosto de 2026, ambos sob licença MIT, com o repositório entre os mais ativos da categoria. Grande parte das críticas que circulam referem-se a versões anteriores.

Preciso de um framework para desenvolver com LLMs?

Não. Os SDKs dos fornecedores são simples, e uma chamada direta consiste em apenas algumas linhas de código, com total transparência sobre o que é enviado. As estruturas justificam a sua existência com muitas integrações, ciclos de agentes complexos ou convenções partilhadas pela equipa — e custam-lhe a capacidade de ver o que está a acontecer.

LangChain ou LlamaIndex?

LlamaIndex se a recuperação for a parte mais difícil: os seus carregadores de documentos, estratégias de fragmentação e abstrações de índice estão mais desenvolvidos. LangChain se precisar de uma ampla composição entre vários fornecedores e ferramentas. Ambos evoluíram para frameworks gerais, pelo que a distinção é menor do que era antigamente.

O que é o DSPy e em que difere?

Trata os prompts como parâmetros a otimizar, em vez de texto a escrever. Declara-se entradas e saídas, define-se uma métrica e a estrutura otimiza os prompts e os exemplos «few-shot» em função do seu conjunto de avaliação. Requer um conjunto de avaliação, o que constitui o verdadeiro custo e também o verdadeiro benefício.

O LangGraph é uma alternativa ao LangChain?

É da mesma equipa e pode ser utilizado de forma independente. Substitui as abstrações de cadeias por um grafo explícito de nós, arestas e estado, o que resolve a queixa mais comum sobre o LangChain — que o fluxo de controlo está oculto. Para aplicações com estado ou ramificações, é frequentemente o que as pessoas realmente queriam.

Qual é a melhor estrutura LLM para produção?

O Haystack é o mais explicitamente orientado para a produção, com pipelines serializáveis que se podem versionar e rever. O LangGraph adapta-se a fluxos de trabalho com estado. Mas a escolha mais adequada para a produção é, muitas vezes, a estrutura mais simples — código que se consegue ler às três da manhã é melhor do que abstrações que é preciso rastrear.

Estas estruturas são gratuitas e de código aberto?

Todas elas. LangChain, LangGraph, LlamaIndex, DSPy, Semantic Kernel, Pydantic AI e Instructor têm licença MIT; o Haystack tem licença Apache-2.0. Todas são permissivas, sem restrições de copyleft, e todas estavam a ser desenvolvidas ativamente em setembro de 2026.

Conclusão

A questão do framework é, na verdade, uma questão de âmbito. Todos os projetos aqui apresentados são bem mantidos e têm licenças permissivas, pelo que a decisão não se prende com a qualidade — trata-se de quanto do fluxo de controlo da sua aplicação pretende delegar.

Se delegar muito, ganha rapidez na obtenção de uma primeira versão funcional, integrações que não escreveu e um ciclo de agente sobre o qual não teve de se preocupar. Se delegar pouco, obtém código legível, uma árvore de dependências que pode auditar e uma depuração que consiste em analisar um pedido e uma resposta.

Vale a pena criar o hábito de passar primeiro meio dia sem utilizar um framework. Isso permite-lhe perceber qual é, na verdade, a parte mais difícil do seu problema — e, normalmente, é a qualidade da recuperação, a validade da saída estruturada ou a avaliação, nenhuma das quais um framework geral resolve melhor do que uma biblioteca especializada.

Depois, escolhe a solução adequada para esse problema específico. O LlamaIndex para a recuperação, o DSPy onde podes medir a qualidade, o Instructor ou o Pydantic AI para saídas estruturadas, o LangGraph ou o Haystack onde o estado e a inspecionabilidade são importantes, e o Semantic Kernel onde a decisão sobre a plataforma já está tomada. E tenha sempre em conta o custo de saída, porque a diferença entre uma biblioteca e uma estrutura não está no que ela faz por si — está na quantidade de código que terá de alterar quando deixar de a utilizar.