Ferramentas para LLMs

O que “Ferramentas para LLMs” Significa

Ferramentas para LLMs (LLM tooling) é o conjunto de sistemas e bibliotecas usados para construir, executar e operar aplicações impulsionadas por modelos de linguagem de grande porte (large language models, LLMs). Em comparação com aplicações “clássicas” de aprendizado de máquina (machine learning, ML), aplicações de LLM tendem a ser:

  • Pesadas em composição (composition-heavy): instruções (prompts) + recuperação (retrieval) + ferramentas + saída estruturada (structured output) + pós-processamento (post-processing)
  • Sensíveis a latência e custo (latency- and cost-sensitive): cada token (token) custa dinheiro e tempo
  • Sensíveis a segurança e confiabilidade (safety- and reliability-sensitive): a saída é probabilística e pode ser insegura ou errada
  • Centradas em dados de novas maneiras: recuperação sobre corpus privados (private corpora), gestão de instruções/versões (prompt/version management), avaliação por cenários (evaluation-by-scenarios)

Este artigo se concentra em três pilares:

  1. Bancos de dados vetoriais (vector databases) (busca semântica e recuperação)
  2. Frameworks de orquestração (orchestration frameworks) (cadeias (chains), agentes (agents), fluxos de trabalho (workflows))
  3. Infraestrutura de aplicações de LLMs (LLM application infrastructure) (serving, observabilidade (observability), avaliação, governança (governance))

Ao longo do caminho, vamos nos conectar a tópicos relacionados do ecossistema, como Harnesses de Avaliação, Ferramentas de Experimentos, Dados, Hubs e Registros de Modelos, Modelos Abertos e Licenças e Frameworks.

Por que as Ferramentas Importam: de “Instrução” a “Produto”

Uma demonstração mínima de LLM pode ser apenas “enviar instrução → receber resposta”. Sistemas em produção geralmente adicionam:

  • Recuperação sobre documentos internos (Geração Aumentada por Recuperação (Retrieval-Augmented Generation, RAG))
  • Chamada de ferramentas (tool calling) (bancos de dados, web, sistemas de tickets, execução de código)
  • Estado (memória de conversa, estado do fluxo de trabalho, contexto do usuário)
  • Barreiras de segurança (guardrails) (verificações de política, redação de PII, tratamento de recusas)
  • Avaliação e monitoramento (qualidade, deriva, alucinações, custo)
  • Implantação (deployment) (roteamento, escalonamento, cache, fallbacks)

O ecossistema de “ferramentas para LLMs” existe para tornar essas adições confiáveis e fáceis de manter.

Fundamentos Conceituais

LLMs como Programas Probabilísticos (Probabilistic Programs)

Modelos de linguagem de grande porte (tipicamente baseados na Arquitetura Transformer) geram tokens modelando (p(\text{token} \mid \text{context})). Isso tem duas implicações práticas:

  • Não determinismo (non-determinism): mesmo com a mesma instrução, as saídas podem variar.
  • Lacuna de especificação (specification gap): você não consegue “testar unitariamente” linguagem natural do jeito que testa código puro.

As ferramentas lidam com isso ao viabilizar saídas estruturadas, ancoragem por recuperação, rastreamento (tracing) e harnesses de avaliação.

Embeddings e Similaridade Semântica

Muitas aplicações de LLM dependem de representações vetoriais (embeddings): vetores que representam o significado de um texto. Com representações vetoriais, você pode encontrar trechos de texto “similares” a uma consulta usando métricas de distância como a similaridade do cosseno (cosine similarity).

Representações vetoriais habilitam:

  • Busca semântica (“encontrar documentos sobre política de PTO mesmo que a formulação da consulta seja diferente”)
  • Geração Aumentada por Recuperação
  • Agrupamento, deduplicação, recomendação

Bancos de dados vetoriais tornam representações vetoriais utilizáveis em escala.

Bancos de Dados Vetoriais

Um banco de dados vetorial armazena vetores (representações vetoriais) e oferece busca do vizinho mais próximo (nearest neighbor search) rápida — muitas vezes com filtragem por metadados e ranqueamento híbrido (hybrid ranking).

Quais Problemas Bancos de Dados Vetoriais Resolvem

Se você tem 1 milhão de segmentos de texto (text chunks) e quer os 10 mais similares a uma representação vetorial de consulta, a força bruta é lenta. Bancos de dados vetoriais usam índices especializados para tornar isso rápido o suficiente para aplicações interativas.

Fluxo típico de RAG:

  1. Dividir documentos em segmentos
  2. Calcular representações vetoriais para cada segmento
  3. Armazenar vetores + texto + metadados em um banco de dados vetorial
  4. No momento da consulta:
    • gerar a representação vetorial da consulta
    • recuperar os top-k segmentos similares
    • passar os segmentos para o modelo de linguagem de grande porte como contexto

Este é um padrão central em Geração Aumentada por Recuperação.

Conceitos-Chave

Métricas de distância

Medidas comuns de similaridade:

  • Similaridade do cosseno (cosine similarity): compara o ângulo entre vetores (comum para representações vetoriais normalizadas)
  • Produto escalar (dot product): muitas vezes equivalente ao cosseno se os vetores estiverem normalizados
  • Distância euclidiana (Euclidean distance): distância geométrica

Escolha o que o seu modelo de representações vetoriais recomendar.

Vizinho Mais Próximo Aproximado (Approximate Nearest Neighbor, ANN)

A maioria dos sistemas reais usa busca de vizinho mais próximo aproximado, trocando uma quantidade mínima de precisão por grandes ganhos de velocidade. Famílias comuns de índices:

  • HNSW (Hierarchical Navigable Small World graphs): ótimo trade-off de latência/recall, amplamente usado
  • IVF (Inverted File Index): particiona o espaço vetorial; pode ser combinado com compressão
  • PQ (Product Quantization): comprime vetores para reduzir memória

Essas escolhas importam para latência, memória e revocação (recall).

Filtragem por metadados

A recuperação prática frequentemente precisa de restrições:

  • tenant_id = “acme-corp”
  • doc_type = “policy”
  • created_at dentro dos últimos 90 dias
  • permissões de ACL/usuário

Um bom banco de dados vetorial suporta filtragem rápida sem destruir a qualidade da recuperação.

Busca híbrida e reclassificação

A similaridade semântica por si só pode perder correspondências exatas. Muitos sistemas combinam:

  • BM25 / busca por palavras-chave (keyword search) (correspondência lexical)
  • Busca vetorial (vector search) (correspondência semântica)
  • Reclassificação (reranking) (codificador cruzado (cross-encoder) ou baseada em LLM) para a ordenação final

Isso é comum em busca corporativa e em RAG de alta precisão.

Opções Comuns de Armazenamento Vetorial

Na prática, “banco de dados vetorial” pode significar:

  • BDs vetoriais dedicados: Pinecone, Weaviate, Milvus, Qdrant
  • Mecanismos de busca com vetores: Elasticsearch/OpenSearch, Vespa
  • Extensões de BD relacional: PostgreSQL + pgvector (popular para pilhas mais simples)

A seleção depende de escala, restrições operacionais, necessidades de recursos (filtragem, multilocação (multitenancy)) e a infraestrutura padrão da sua organização.

Exemplo Prático: Índice + Consulta RAG Minimalistas (Python)

Abaixo está um exemplo simplificado usando uma interface genérica de armazenamento vetorial (vector store interface). Em sistemas reais, você conectaria um SDK do provedor (provider SDK) e um modelo de representações vetoriais.

from typing import List, Dict
import numpy as np

def cosine_sim(a: np.ndarray, b: np.ndarray) -> float:
    a = a / (np.linalg.norm(a) + 1e-12)
    b = b / (np.linalg.norm(b) + 1e-12)
    return float(a @ b)

class TinyVectorStore:
    def __init__(self):
        self.items = []  # each: (id, vector, text, metadata)

    def upsert(self, _id: str, vector: np.ndarray, text: str, metadata: Dict):
        self.items.append((_id, vector, text, metadata))

    def query(self, qvec: np.ndarray, k: int = 5, where: Dict = None):
        where = where or {}
        filtered = []
        for _id, vec, text, md in self.items:
            if all(md.get(key) == val for key, val in where.items()):
                filtered.append((_id, vec, text, md))

        scored = [(_id, cosine_sim(qvec, vec), text, md) for _id, vec, text, md in filtered]
        scored.sort(key=lambda x: x[1], reverse=True)
        return scored[:k]

# Example usage (pretend embed() gives real embedding vectors)
def embed(text: str) -> np.ndarray:
    rng = np.random.default_rng(abs(hash(text)) % (2**32))
    return rng.normal(size=(384,)).astype(np.float32)

store = TinyVectorStore()
store.upsert("doc1", embed("Company PTO policy and holidays"), "PTO policy ...", {"tenant": "acme", "type": "policy"})
store.upsert("doc2", embed("Expense reimbursement guidelines"), "Expenses ...", {"tenant": "acme", "type": "policy"})
store.upsert("doc3", embed("How to deploy the service"), "Deployment ...", {"tenant": "acme", "type": "engineering"})

q = "How many vacation days do we get?"
results = store.query(embed(q), k=2, where={"tenant": "acme", "type": "policy"})
for _id, score, text, md in results:
    print(_id, score, md)

Implementações reais adicionam persistência, índices de vizinho mais próximo aproximado, controle de concorrência e verificações de controle de acesso.

Preocupações Operacionais para Recuperação Vetorial

  • Estratégia de segmentação (chunking strategy): segmentos pequenos demais perdem contexto; segmentos grandes demais reduzem revocação e desperdiçam tokens.
  • Escolha do modelo de representações vetoriais: modelos específicos de domínio podem superar os de propósito geral.
  • Atualizações e exclusões: lidar com atualização de documentos e versionamento de representações vetoriais.
  • Multilocação e listas de controle de acesso (Access Control Lists, ACLs): aplicar permissões no momento da recuperação, não apenas na interface.
  • Monitoramento de deriva (drift monitoring): mudanças no conteúdo e nas consultas podem degradar a qualidade da recuperação ao longo do tempo.

Bancos de dados vetoriais são tão bons quanto o pipeline que os alimenta — frequentemente construído com ferramentas de dados abordadas em Dados.

Frameworks de Orquestração

Orquestração (orchestration) é como você constrói comportamentos de LLM em múltiplas etapas: recuperação, chamadas de ferramentas, ramificações, tentativas (retries), parsing estruturado e gestão de estado.

Dois Estilos Amplos: Cadeias e Agentes

Cadeias (workflows)

Uma cadeia é um pipeline majoritariamente determinístico:

  1. Normalizar a entrada do usuário
  2. Recuperar contexto
  3. Chamar o modelo de linguagem de grande porte com um template de instrução (prompt template)
  4. Fazer parsing de saída estruturada (por exemplo, JSON)
  5. Validar e executar lógica de negócio

Cadeias são mais fáceis de testar e monitorar.

Agentes (loops orientados por política)

Um agente decide o que fazer em seguida com base no estado atual:

  • “Devo buscar? Qual ferramenta devo chamar? Devo pedir uma pergunta de esclarecimento?”
  • Executa em loop até atingir um objetivo ou bater um limite.

Agentes podem ser poderosos, mas são mais difíceis de controlar e avaliar.

O que Frameworks de Orquestração Oferecem

Recursos comuns:

  • Templates de instruções (prompt templating) e formatação de mensagens
  • Wrappers de chamada de ferramentas/funções
  • Componentes de recuperação (conectores para bancos de dados vetoriais)
  • Abstrações de memória/estado (histórico de chat, estado de sessão)
  • Parsing de saída estruturada (esquema JSON (JSON schema), validadores (validators))
  • Políticas de repetição e fallback (retry/fallback policies) (por exemplo, trocar de modelo em falha)
  • Execução assíncrona (async execution) e streaming de tokens (streaming tokens)
  • Hooks de rastreamento para observabilidade

Exemplos no ecossistema incluem LangChain, LlamaIndex, Haystack, Semantic Kernel e motores de workflow que integram chamadas a modelos de linguagem de grande porte.

Exemplo Prático: Um Padrão Simples de “Cadeia RAG”

Abaixo está um esboço intencionalmente agnóstico a frameworks. Ele destaca interfaces que você vai querer independentemente da biblioteca escolhida.

from dataclasses import dataclass
from typing import List, Dict

@dataclass
class RetrievedChunk:
    text: str
    source: str

def retrieve(query: str) -> List[RetrievedChunk]:
    # query vector DB + rerank
    return [
        RetrievedChunk(text="PTO policy: Full-time employees get 20 days/year ...", source="handbook.pdf#p12"),
        RetrievedChunk(text="Carry-over rules: up to 5 days ...", source="handbook.pdf#p13"),
    ]

def build_prompt(question: str, chunks: List[RetrievedChunk]) -> str:
    context = "\n\n".join([f"[{c.source}]\n{c.text}" for c in chunks])
    return f"""You are an HR assistant. Answer using only the provided sources.
If the answer is not in sources, say you don't know.

Question: {question}

Sources:
{context}
"""

def call_llm(prompt: str) -> str:
    # call an LLM API or local model server
    return "Full-time employees receive 20 PTO days per year, with up to 5 days carry-over. [handbook.pdf#p12][handbook.pdf#p13]"

def answer_question(question: str) -> str:
    chunks = retrieve(question)
    prompt = build_prompt(question, chunks)
    return call_llm(prompt)

print(answer_question("How many PTO days do I get and can I carry them over?"))

Em um framework de produção, cada etapa seria um componente com tentativas, métricas e rastreamentos.

Chamada de Ferramentas e Saídas Estruturadas

Plataformas modernas de LLMs suportam “chamada de função (function calling)” / “chamada de ferramentas (tool calling)”, em que o modelo emite uma requisição estruturada como:

{ "tool": "lookup_invoice", "arguments": { "invoice_id": "INV-10291" } }

Frameworks de orquestração gerenciam:

  • registro de ferramentas e esquemas
  • validação de argumentos
  • execução e tratamento de erros
  • devolução de resultados ao modelo
  • limitação de acesso às ferramentas (segurança)

Saídas estruturadas reduzem parsing frágil e tornam modelos de linguagem de grande porte mais confiáveis dentro de sistemas de software.

Testando Orquestrações

Orquestração de LLM é engenharia de software: você quer testes unitários, testes de integração e testes por cenário.

Boas práticas incluem:

  • Casos de teste de referência (golden test cases) para instruções representativas
  • Mocking de ferramentas (mocking tools) para isolar falhas
  • Controles de determinismo (determinism controls) (temperatura (temperature), sementes fixas (fixed seeds) quando suportado)
  • Suites de avaliação integradas com Harnesses de Avaliação

Infraestrutura de Aplicações de LLMs

“Infraestrutura de LLM” cobre tudo o que é necessário para executar recursos de LLM com confiabilidade em produção.

Servir Modelos: API vs Auto-hospedagem

Dois caminhos comuns de implantação:

  • APIs gerenciadas de modelos (managed model APIs) (por exemplo, provedores de LLM hospedados, plataformas de modelos na nuvem)

    • Prós: começo rápido, alta confiabilidade, atualizações contínuas do modelo
    • Contras: preocupações de governança de dados, custo recorrente, dependência de fornecedor

  • Inferência auto-hospedada (self-hosted inference) (modelos com pesos abertos (open-weight models) nas suas GPUs)

    • Prós: controle de dados, potencialmente menor custo marginal em escala, customização
    • Contras: operação de GPUs, complexidade de escalonamento, trabalho de otimização de modelos

Essa escolha interage com Modelos Abertos e Licenças e Hubs e Registros de Modelos.

Componentes comuns de serving incluem:

  • Servidores de modelos (model servers) (por exemplo, vLLM, TGI, TensorRT-LLM)
  • Balanceadores de carga (load balancers) e autoescalonamento (autoscaling)
  • Loteamento/enfileiramento (batching/queueing) para vazão (throughput)
  • Suporte a streaming para UX de chat

Gateways, Roteamento e Fallbacks

Pilhas de produção frequentemente introduzem um gateway de LLM (LLM gateway):

  • Padroniza chamadas de API entre provedores/modelos
  • Aplica autenticação (auth), limites de taxa (rate limits) e cotas (quotas)
  • Acompanha custo e uso de tokens
  • Implementa regras de roteamento:
    • “Usar modelo mais barato para sumarização”
    • “Usar modelo mais forte para jurídico ou geração de código”
    • “Usar fallback se houver timeout ou recusa por segurança”

O roteamento pode ser dinâmico (com base em latência/custo) ou semântico (com base em classificação de tarefas (task classification)).

Cache: O Token Mais Barato É Aquele Que Você Não Gera

Cache (caching) pode reduzir drasticamente custo/latência:

  • Cache de instrução+resposta (prompt+response cache) (correspondência exata (exact match))
  • Cache semântico (semantic cache) (reutiliza respostas para consultas similares usando representações vetoriais)
  • Cache de recuperação (retrieval cache) (cache dos top-k segmentos recuperados)
  • Cache de resultados de ferramentas (tool result cache) (por exemplo, consultas caras ao banco de dados)

Tenha cuidado com:

  • privacidade (não vazar respostas em cache entre locatários)
  • obsolescência (invalidar quando os dados subjacentes mudarem)

Observabilidade: Rastros, Métricas e Logs

A observabilidade de LLMs é mais ampla do que logs típicos de web. Sinais úteis incluem:

  • instrução e resposta (frequentemente redigidas ou com hash)
  • contagem de tokens, decomposição de latência (recuperação vs geração)
  • rastros de chamadas de ferramentas (argumentos, erros)
  • sinais de qualidade de recuperação (quais documentos foram usados)
  • taxas de recusa, flags de segurança
  • sinais de feedback do usuário (“joinha para cima/baixo”)

Muitas equipes instrumentam com rastreamento no estilo OpenTelemetry mais ferramentas especializadas de monitoramento de LLM.

Barreiras de Segurança e Controles de Segurança

Barreiras de segurança podem ser aplicadas em múltiplas etapas:

  • Filtragem de entrada (input filtering): detectar injeção de prompt (prompt injection), PII, violações de política
  • Restrições de recuperação: aplicação de ACL, filtragem de documentos sensíveis
  • Validação de saída:
    • validação de esquema JSON para saídas estruturadas
    • checagens de alucinação (por exemplo, exigir citações)
    • classificadores de política (policy classifiers) para conteúdo proibido
  • Isolamento em sandbox de ferramentas (tool sandboxing): restringir acesso a sistema de arquivos/rede para ferramentas de código

Nenhuma barreira de segurança é perfeita; defesas em camadas são o padrão.

Avaliação no Loop

Como o comportamento de LLM muda com instruções, recuperação e versões do modelo, a avaliação precisa ser contínua:

  • Avaliação offline (offline evaluation): testes de regressão em conjuntos de dados curados
  • Monitoramento online (online monitoring): detecção de deriva, feedback de usuários, triagem de falhas
  • Testes A/B (A/B tests): comparar instruções, recuperadores, reclassificadores e modelos

As ferramentas frequentemente se conectam a Ferramentas de Experimentos para rastrear versões de instruções, conjuntos de dados e métricas, e a Harnesses de Avaliação para benchmarking repetível.

Pipelines de Dados para RAG

RAG requer pipelines de ingestão (ingestion pipelines):

  • conectores (Google Drive, Confluence, SharePoint, S3, bancos de dados)
  • parsing (parsing) (PDF/HTML), reconhecimento óptico de caracteres (OCR) quando necessário
  • segmentação e enriquecimento de metadados (metadata enrichment)
  • geração de representações vetoriais e indexação (indexing)
  • agendamento de atualizações (refresh scheduling) e exclusões

Isso se sobrepõe à engenharia de dados clássica coberta em Dados e à distribuição de conjuntos de dados em Conjuntos de Dados e Hospedagem.

Juntando Tudo: Uma Arquitetura de Referência

Uma aplicação típica de LLM (por exemplo, “assistente interno de conhecimento”) se parece com isto:

  1. Cliente/UI (aplicativo web, bot do Slack)
  2. Backend de API
  3. Orquestrador (cadeia/agente) que:
    • chama o recuperador (banco de dados vetorial + filtros + reclassificador)
    • chama o modelo de linguagem de grande porte (via gateway)
    • chama ferramentas (ticketing, CRM, bancos de dados)
  4. Banco de dados vetorial contendo representações vetoriais + metadados
  5. Armazenamento de documentos (documentos originais)
  6. Observabilidade (rastreamento, logs, métricas)
  7. Pipeline de avaliação (regressão offline + monitoramento online)

Essa separação mantém as responsabilidades administráveis: a qualidade de recuperação pode ser melhorada sem mudar a hospedagem do modelo, e trocas de modelo podem ocorrer sem reescrever a ingestão.

Como Escolher Ferramentas (Orientação Prática)

Checklist de seleção de banco de dados vetorial

  • Qualidade de recuperação: método de vizinho mais próximo aproximado, busca híbrida, integrações de reclassificação
  • Filtragem: velocidade e expressividade (consultas por intervalo, filtros booleanos)
  • Padrões de multilocação e ACL
  • Modelo operacional: gerenciado vs auto-hospedado
  • Metas de latência/vazão e tempos de construção do índice
  • Modelo de custos (armazenamento, consultas, réplicas)

Checklist de seleção de framework de orquestração

  • Adequação ao seu estilo: workflows determinísticos vs loops agentivos
  • Ergonomia de chamada de ferramentas e saída estruturada
  • Facilidade de depuração: rastros, inspeção de etapas intermediárias
  • Conectores do ecossistema (armazenamentos vetoriais, carregadores de documentos, serviços de nuvem)
  • Testabilidade: mocking fácil e execuções reprodutíveis
  • Risco de manutenção: estabilidade de API, suporte da comunidade

Checklist de seleção de infraestrutura

  • Governança de dados: onde instruções e documentos são processados/armazenados
  • Necessidades de confiabilidade: fallbacks, SLAs, limitação de taxa
  • Segurança: gestão de segredos, sandboxing, logs de auditoria
  • Controles de custo: cache, roteamento, batching
  • Maturidade de avaliação: suíte de regressão + monitoramento

Modos de Falha Comuns (e Respostas das Ferramentas)

  • Alucinações (hallucinations): mitigue com RAG, citações, engenharia de instruções (prompting) mais rígida, validadores de saída e conjuntos de avaliação direcionados.
  • Injeção de prompt: isole texto não confiável, use filtragem de entrada, restrinja acesso a ferramentas e aplique verificações de política.
  • Recuperação ruim: melhore segmentação, adicione busca híbrida, reclassificadores, metadados e avalie recuperação separadamente da geração.
  • Picos de latência: adicione cache, batching, modelos menores para tarefas simples e timeouts com fallbacks graduais.
  • Regressões silenciosas: integre avaliação contínua e versionamento de instruções/modelos (veja Ferramentas de Experimentos).

Resumo

Ferramentas para LLMs são a camada prática que transforma um modelo generativo poderoso em um sistema confiável:

  • Bancos de dados vetoriais tornam a recuperação semântica rápida e escalável, habilitando RAG e aplicações ancoradas em conhecimento.
  • Frameworks de orquestração gerenciam comportamento em múltiplas etapas (recuperação, chamadas de ferramentas, ramificações, tentativas) e tornam aplicações de LLM mais fáceis de manter.
  • Infraestrutura de aplicações de LLMs fornece os “essenciais de produção”: serving, roteamento, cache, observabilidade, avaliação e controles de segurança.

À medida que as capacidades de LLM evoluem, essas ferramentas definem cada vez mais o desempenho no mundo real: não apenas qual modelo você usa, mas quão bem você recupera dados, restringe comportamento, mede qualidade e opera o sistema ao longo do tempo.