LangChain ou LlamaIndex: rapidez custou relevância no teste

Nas implementações avaliadas no experimento de Oliinyk e Ponochovnyy com um contrato de seguro e perguntas idênticas, o sistema com LlamaIndex levou em média 1,51861 segundo para responder, ante 3,60444 segundos com LangChain; sua relevância média foi de 0,69379, ante 0,96362. A implementação mais rápida, portanto, entregou respostas menos alinhadas às perguntas segundo a métrica usada no teste.

Se a prioridade é cobrir bem perguntas sobre documentos semelhantes ao testado, a configuração com LangChain oferece o ponto de partida mais convincente. Se a latência pesa mais, vale avaliar LlamaIndex, medindo também a qualidade das respostas. O resultado compara sistemas completos montados para um corpus restrito; ele não estabelece uma propriedade permanente de velocidade ou relevância das bibliotecas.

O que entrou na comparação

O desenho do experimento permite comparar as respostas às mesmas consultas, mas delimita o alcance da conclusão. Os pesquisadores montaram sistemas básicos de perguntas e respostas, escolheram um contrato de seguro de um conjunto público de dados e calcularam médias para as saídas. Essa arquitetura comparável pode ser lida como uma matriz:

Documento e consultas: o mesmo contrato e as mesmas perguntas para as duas implementações.
Sistemas: uma aplicação básica construída com LangChain e outra com LlamaIndex, cada qual reunindo as etapas necessárias para recuperar contexto e gerar a resposta.
Avaliação: qualidade do contexto recuperado, relevância e fidelidade da resposta, similaridade semântica e tempo de geração.
Resultado comparado: médias das implementações, e não uma medição isolada do código de cada framework.

Compartilhar documento e perguntas elimina duas diferenças importantes, mas não torna todas as demais etapas equivalentes. Extração do contrato, divisão em trechos, embeddings, armazenamento, recuperação e modelo gerador podem influenciar o que chega à resposta e quanto tempo ela demora. O artigo acadêmico não detalha um controle pareado de todos esses componentes para as duas implementações. Por isso, o contraste publicado é útil como observação de sistemas RAG concretos, não como previsão de desempenho para qualquer projeto.

Por que rapidez, relevância e fidelidade deram sinais diferentes

Relevância responde se o texto gerado atende ao que foi perguntado. Nesse indicador, a implementação com LangChain teve vantagem clara. A cobertura do contexto recuperado também foi maior: o sistema trouxe mais das informações consideradas necessárias para responder. Num contrato, uma resposta fluente que ignora a condição decisiva de uma cláusula pode falhar mesmo quando suas frases parecem plausíveis.

Fidelidade mede outra relação: se as afirmações geradas são sustentadas pelos trechos recuperados. Nesse ponto, a implementação com LlamaIndex ficou ligeiramente à frente. As duas medidas podem divergir sem contradição. Uma resposta pode repetir com precisão um trecho do contrato e ainda deixar sem resposta a parte central da pergunta, caso a recuperação tenha selecionado contexto insuficiente.

O tempo médio, por sua vez, informa a espera observada até a resposta, sem identificar sozinho qual etapa produziu a diferença. Se a aplicação atende consultas interativas curtas, esse tempo pode ter grande peso. Para respostas que precisam abranger condições, exceções e referências entre trechos, relevância e cobertura podem pesar mais. A escolha depende de qual falha prejudica mais o usuário: esperar pela resposta ou receber depressa uma resposta incompleta.

Quanto controle cada estrutura oferece à recuperação e aos agentes

A documentação do LangChain separa tutoriais de busca semântica em PDF, agente RAG e agente RAG personalizado com primitivas do LangGraph. Essa progressão é útil quando o fluxo começa com uma consulta documental simples e passa a exigir decisões explícitas: quando buscar, qual ferramenta chamar, como tratar contexto insuficiente e em que ponto encerrar a resposta. O ganho é poder desenhar essas decisões; o custo é manter mais partes da aplicação.

O guia de consultas do LlamaIndex descreve um QueryEngine pronto e a composição separada de recuperação, pós-processamento e síntese da resposta. A recuperação pode variar a quantidade de trechos; o pós-processamento pode filtrar resultados por similaridade; a síntese determina como os trechos entram na resposta. Assim, escolher a abstração pronta não impede ajustar o caminho da consulta quando o corpus exige mais controle.

Para agentes, a distinção prática está em onde a equipe quer expressar as decisões do fluxo. LangGraph oferece um caminho explícito dentro do ecossistema LangChain; LlamaIndex também permite compor workflows RAG com comportamento de agente. O experimento do contrato avaliou sistemas básicos de perguntas e respostas. Suas médias não medem agentes que refazem buscas, encaminham perguntas entre fontes ou usam ferramentas adicionais.

O peso das fontes e dos documentos complexos

O guia de RAG do LlamaIndex descreve consultas sobre texto, PDFs, documentos do Notion e Slack, além de dados estruturados em SQL ou CSV. Também apresenta combinação e encaminhamento de perguntas entre fontes e recursos para PDFs com tabelas, gráficos e imagens. Essas abstrações podem reduzir o trabalho de montar a ingestão e a consulta quando os dados estão espalhados por formatos diferentes.

A lista de fontes aceitas, contudo, não mede a qualidade da recuperação em cada uma delas. Um PDF que mistura texto e tabela exige preservar a relação entre células, títulos e condições; dividir o conteúdo em trechos sem esse vínculo pode retirar justamente a informação necessária. A aplicação com LangChain também pode ser composta para lidar com essas exigências. O esforço de extração e representação dos dados importa tanto quanto a escolha do framework que coordena a busca.

O contrato usado na comparação dá concretude aos resultados, mas é um corpus muito menor e mais uniforme que uma base com arquivos de formatos variados. Nas etapas posteriores do mesmo trabalho, os pesquisadores variaram banco vetorial e fragmentação sobre uma implementação baseada em LangChain. Os ganhos dessas configurações pertencem a essa etapa do estudo e não constituem uma segunda disputa direta com LlamaIndex.

Qual escolha faz sentido para a aplicação

Para perguntas documentais em que omitir informação é caro, comece avaliando a configuração com LangChain que apresentou maior relevância e cobertura no experimento. Para uma experiência em que a espera domina, a configuração com LlamaIndex oferece uma hipótese de menor latência, desde que a relevância obtida no seu corpus continue aceitável. Se o trabalho principal é unir fontes estruturadas, documentos e consultas encaminhadas entre elas, compare o esforço de construir e manter esse fluxo em cada ecossistema.

A decisão fica mais sólida quando as implementações recebem os documentos e as perguntas reais da aplicação. Meça separadamente o contexto recuperado, a resposta produzida e a latência: isso distingue uma cláusula que nunca chegou ao modelo de uma cláusula recuperada que ele interpretou mal. É essa distinção que permite decidir se o próximo ajuste pertence à ingestão, à busca ou à geração.