LlamaIndex: orquestrando seus dados com LLMs

Um LLM sozinho é um ótimo raciocinador com amnésia. Ele não conhece os seus PDFs, o seu banco de dados, o seu Notion nem o ticket que o cliente abriu ontem. O problema central das aplicações de IA não é "qual modelo usar" — é como levar o dado certo até o modelo no momento certo.

É exatamente esse o trabalho do LlamaIndex: um framework de orquestração entre os seus dados e os LLMs.

O problema que ele resolve

A jornada de qualquer feature séria de IA passa por três etapas que ninguém mostra nos demos:

1. Ingestion — ler dados de fontes heterogêneas (PDF, SQL, APIs, Slack, Notion).
2. Indexing — transformar isso em algo consultável (embeddings, índices vetoriais, grafos).
3. Querying — recuperar o trecho relevante e entregar ao modelo com contexto.

LlamaIndex dá uma abstração para cada etapa, sem te prender a um único vector DB, modelo de embedding ou provedor de LLM.

O fluxo mínimo

O famoso "5 linhas de RAG" existe pra mostrar o conceito:

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
 
documents = SimpleDirectoryReader("data").load_data()
index = VectorStoreIndex.from_documents(documents)
 
query_engine = index.as_query_engine()
response = query_engine.query("O que o relatório diz sobre churn no Q1?")
print(response)

Por baixo disso acontece muita coisa: chunking dos documentos, geração de embeddings, armazenamento no índice e, na query, busca por similaridade + montagem do prompt com os trechos recuperados. O valor do framework é justamente esconder esse encanamento — sem te impedir de abrir cada camada quando precisar.

Os blocos de construção

• Documents & Nodes — o Document é a fonte bruta; o Node é o pedaço (chunk) indexável com metadados. Quase toda decisão de qualidade de RAG vive aqui: tamanho do chunk, overlap, e quais metadados anexar.
• Indexes — VectorStoreIndex (busca semântica), SummaryIndex (varredura sequencial), KnowledgeGraphIndex (relações), PropertyGraphIndex. Você escolhe conforme o tipo de pergunta.
• Retrievers — a estratégia de o que trazer de volta. Dá pra combinar busca vetorial com keyword (hybrid), reranking e filtros por metadado.
• Query Engines — orquestram retriever + LLM + pós-processamento numa interface de pergunta-resposta.
• Agents — quando uma resposta exige múltiplos passos, ferramentas e decisão. Cada query engine vira uma tool que o agente decide quando chamar.

RAG é o começo, não o fim

O erro comum é tratar RAG como "joga tudo num vector DB e reza". Onde o LlamaIndex brilha de verdade é nos padrões além do RAG ingênuo:

• Routing — um RouterQueryEngine decide se a pergunta vai pro índice de docs, pro SQL ou pra um sumário.
• Sub-questions — quebra uma pergunta complexa ("compare a receita de 2024 e 2025") em sub-perguntas, consulta cada fonte e sintetiza.
• Agentic retrieval — o agente reformula a query, busca de novo, valida e só então responde. Mais lento, bem mais robusto.

from llama_index.core.tools import QueryEngineTool
from llama_index.core.agent.workflow import FunctionAgent
from llama_index.llms.openai import OpenAI
 
tools = [
    QueryEngineTool.from_defaults(
        finance_engine,
        name="financeiro",
        description="Relatórios financeiros e métricas de receita",
    ),
    QueryEngineTool.from_defaults(
        support_engine,
        name="suporte",
        description="Tickets e histórico de atendimento",
    ),
]
 
agent = FunctionAgent(tools=tools, llm=OpenAI(model="gpt-4.1"))
response = await agent.run("Quais clientes que abriram ticket também caíram em receita?")

LlamaIndex vs. LangChain (a pergunta inevitável)

Ambos orquestram, mas com centros de gravidade diferentes:

• LlamaIndex nasceu obcecado por dados e retrieval. Se o seu problema é "conectar uma base de conhecimento a um LLM com qualidade", ele tem as abstrações mais maduras.
• LangChain é mais amplo em composição de cadeias e agentes genéricos.

Na prática, não é religião: muita gente usa LlamaIndex para a camada de ingestion/retrieval e pluga em outro orquestrador. As abstrações são interoperáveis.

Quando usar (e quando não)

Use quando:

• você tem dados privados que o modelo precisa conhecer;
• a qualidade da resposta depende de recuperar o trecho certo;
• você quer trocar de vector DB / LLM / embedding sem reescrever a aplicação.

Talvez seja overkill quando:

• a tarefa é puramente generativa, sem base de conhecimento;
• você precisa de uma única chamada simples a um LLM — aí o SDK do provedor já basta.

Resumindo

LlamaIndex não é "mais um wrapper de LLM". É a camada de orquestração que transforma dados bagunçados e espalhados em contexto consultável — e te dá uma rampa que vai do RAG de 5 linhas até agents multi-fonte sem trocar de ferramenta no meio do caminho.

O modelo continua sendo o raciocinador. O LlamaIndex é a memória e os sentidos que você dá pra ele.