Converse com 1000+ PDFs localmente: RAG em escala além dos exemplos de teste

Por que o RAG padrão falha com mais de 1.000 documentos

• Índice fora da RAM: LanceDB, ChromaDB e FAISS começam todos residindo em memória. Quando o índice excede a RAM disponível (tipicamente 5–8 GB de vetores em um notebook de 16 GB), caem para leituras em disco e a latência p95 da consulta salta de ~300 ms para 1–3 segundos.
• O cosseno puro falha em termos raros: os embeddings densos subponderam nomes próprios incomuns, nomes de medicamentos, números de estatutos e identificadores de código. Uma consulta por "Section 230(c)(1)" recupera chunks sobre "Section 9" porque o embedding não consegue distinguir a especificidade numérica. BM25 captura; a busca pura por cosseno perde.
• Top-K de 4 é muito estreito em escala: com 1.000 chunks, top-4 tem recall decente. Com 50.000 chunks, o melhor chunk costuma estar no rank 12–30, fora da janela top-4. A recuperação parece funcionar (as respostas são plausíveis) mas se baseia em trechos incorretos.
• Sem filtragem de metadados o índice é desperdiçado: perguntar "o que Smith disse sobre X?" em um corpus de 10.000 documentos busca em todos os chunks do índice, quando o sistema deveria pré-filtrar primeiro para "documentos escritos por Smith". O RAG básico não tem conceito de pré-filtragem por metadados.
• O tamanho de chunk padrão de 512/0 fragmenta contextos longos: parágrafos de PDF e seções jurídicas raramente cabem em 512 tokens. O overlap padrão de 0 perde significado entre fragmentos. O ajuste 1.000/200 resolve isso para corpus médios; é necessário chunking hierárquico além de 5.000 documentos.
• Drift de embedding na atualização: ao adicionar 1.000 novos PDFs três meses após o índice original, as versões do modelo de sentence-transformer podem ter mudado. Misturar embeddings de duas versões de modelo em um mesmo índice degrada silenciosamente a recuperação — todas as arquiteturas forçam uma reindexação completa ao trocar o embedder.

Árvore de decisão de arquitetura: escolha primeiro pelo tamanho do corpus

• Menos de 1.000 documentos (menos de ~5.000 chunks): AnythingLLM Desktop com chunk size 1.000 / overlap 200 e nomic-embed-text-v1.5 como embedder. Sem código personalizado. Consulte o guia passo a passo de 30 minutos para a configuração.
• 1.000–5.000 documentos (5k–25k chunks): LlamaIndex em modo local com índices hierárquicos (DocumentSummaryIndex + VectorStoreIndex), Ollama como provedor LLM, nomic-embed-text-v1.5 como embedder, LanceDB ou ChromaDB como vector store. ~150 linhas de Python, funciona como processo de longa duração.
• 5.000–10.000 documentos (25k–50k chunks): Stack personalizado com Ollama, ChromaDB, busca híbrida BM25 via Whoosh ou Tantivy, e um reranker BGE-reranker-v2-m3 sobre os 50 melhores candidatos. ~300–400 linhas de Python. O reranker é indispensável nessa escala.
• 10.000+ documentos (50k+ chunks): Ollama + Qdrant em modo single-node com filtragem de metadados baseada em payload, busca híbrida usando vetores sparse nativos do Qdrant, BGE-reranker-v2-m3 e índice de resumos hierárquico por IDs de documento. Configuração de grau produção para usuário único.
• Multiusuário (qualquer escala): Open WebUI na frente de qualquer uma das anteriores, ou um pequeno wrapper FastAPI ao redor do mesmo backend Qdrant + Ollama. O multiusuário muda o foco operacional (autenticação, isolamento, rate limiting) mas não a arquitetura de recuperação.

Tabela comparativa de arquiteturas

Opção 1: AnythingLLM ajustado (100–1.000 docs)

• LLM: Llama 3.3 8B Q4_K_M via Ollama (5 GB de RAM durante a inferência). Em sistemas com 24 GB+, o Qwen 3 14B Q4 melhora notavelmente a síntese.
• Embedder: troque do padrão do AnythingLLM para nomic-embed-text-v1.5 via Ollama. O embedder padrão é a principal razão por trás dos relatos de "AnythingLLM não escala".
• Chunking: 1.000 tokens com overlap de 200 tokens, configurado por workspace nas configurações do Vector Database. O padrão 512/0 está errado para qualquer corpus maior que algumas dezenas de documentos.
• Top-K: aumente do padrão 4 para 6–8. Com 1.000 documentos, o melhor chunk costuma estar no rank 5–7, e o LLM consegue ignorar chunks fracos melhor do que consegue inventar os que estão faltando.
• Particionamento por workspace: crie um workspace por categoria de documento (artigos, contratos, notas). Cada workspace tem um LanceDB indexado separadamente; as consultas entre workspaces não são suportadas, mas o recall por workspace é muito maior do que em um único pool grande.

Opção 2: LlamaIndex local (1.000–5.000 docs)

• Stack: Ollama + LlamaIndex + LanceDB (ou ChromaDB) + nomic-embed-text-v1.5 via o adaptador OllamaEmbedding. Persistido em disco; funciona como um processo Python de longa duração com o qual você interage via CLI ou um pequeno wrapper FastAPI.
• DocumentSummaryIndex sobre VectorStoreIndex: o LlamaIndex constrói um resumo por documento no tempo de indexação, e então a recuperação primeiro seleciona documentos relevantes (busca de resumos) e só então busca chunks dentro desses documentos. É o padrão de recuperação hierárquica mais econômico.
• Roteamento de consultas: RouterQueryEngine envia consultas de recuperação de fatos ao índice de chunks e consultas de síntese ao índice de resumos. ~30 linhas de código; duplica a qualidade da resposta em corpus de documentos longos.
• Recuperação por janela de sentenças: um segundo índice opcional que recupera uma sentença alvo mais N sentenças circundantes. Útil para corpus jurídicos e acadêmicos onde a resposta é uma sentença, mas seu significado depende do parágrafo ao redor.
• Persistência: index.storage_context.persist(persist_dir=...) salva tudo. O tempo de recarga em um índice de 5.000 documentos é de 10–30 segundos em SSD NVMe.

# Minimal LlamaIndex local RAG with hierarchical indices (~30 lines)
from llama_index.core import VectorStoreIndex, DocumentSummaryIndex, SimpleDirectoryReader
from llama_index.embeddings.ollama import OllamaEmbedding
from llama_index.llms.ollama import Ollama
from llama_index.core import Settings

Settings.llm = Ollama(model="llama3.3:8b-instruct-q4_K_M", request_timeout=120)
Settings.embed_model = OllamaEmbedding(model_name="nomic-embed-text:latest")
Settings.chunk_size = 1000
Settings.chunk_overlap = 200

docs = SimpleDirectoryReader("./pdfs").load_data()

# Summary index for routing + chunk index for retrieval
summary_index = DocumentSummaryIndex.from_documents(docs)
chunk_index = VectorStoreIndex.from_documents(docs)

summary_index.storage_context.persist("./storage/summary")
chunk_index.storage_context.persist("./storage/chunks")

# At query time, route by question type
response = chunk_index.as_query_engine(similarity_top_k=8).query(
    "What sample size did Smith et al. use?"
)
print(response)

Opção 3: Ollama + ChromaDB personalizado (5.000–10.000 docs)

• Stack: Ollama + ChromaDB (modo servidor) + Whoosh ou Tantivy para BM25 + BGE-reranker-v2-m3 (~570 MB, funciona em CPU a 50–100 candidatos/seg). Hospedado como um único processo Python ou dividido em workers de ingest + consulta.
• Busca híbrida no tempo de recuperação: execute BM25 e recuperação densa por vetor em paralelo, pegue os top-25 de cada um, desduplique e então reordene o top-50 combinado com o cross-encoder. O top-K final de 6–8 vai ao LLM.
• Campos de metadados do ChromaDB: preencha source_filename, page_number, document_type, author, year em cada chunk no tempo de indexação. A filtragem no tempo de consulta (where={"document_type": "contract"}) reduz o espaço de busca de recuperação em 5–10 vezes sem perda de qualidade.
• Indexação em lotes: o ChromaDB gera embeddings em lotes de 32–128 chunks. Em uma RTX 4070, o BGE-reranker é o gargalo (50–100 candidatos/seg em CPU; 400+/seg em GPU).
• Persistência: o ChromaDB escreve em um diretório SQLite + Parquet. Um índice de 50.000 chunks em disco é ~3–5 GB. O backup é uma cópia do diretório.

Opção 4: Ollama + Qdrant (10.000+ docs)

• Stack: Ollama + Qdrant (Docker, single-node) + vetores sparse nativos (equivalente BM25 integrado no Qdrant 1.10+) + BGE-reranker-v2-m3 + uma pequena camada de orquestração Python.
• Híbrido nativo: o Qdrant suporta vetores densos + sparse na mesma coleção, com fusão ponderada no tempo de consulta. Sem processo BM25 separado para manter.
• Ajuste HNSW: com 50.000+ vetores, aumente ef_construct para 200 e m para 32 na construção do índice, e use ef=128 no tempo de consulta. Os padrões funcionam mas trocam ~10% de recall por velocidade de construção.
• Esquemas de payload para filtragem: o Qdrant trata payloads como cidadãos de primeira classe. Indexe author, document_type, year e tags como keyword payloads para habilitar pré-filtragem em submilissegundos.
• Recuperação hierárquica: mantenha duas coleções — summaries (um vetor por documento) e chunks (os habituais). Roteie as consultas primeiro pela coleção de resumos, depois busque chunks dentro dos IDs de documento correspondentes.
• Persistência: o Qdrant escreve em um único volume montado. Uma coleção de 100.000 chunks ocupa ~6–12 GB em disco conforme o tamanho do payload e as configurações HNSW.

# Qdrant collection with dense + sparse vectors and metadata filtering
from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, SparseVectorParams, SparseIndexParams
)

client = QdrantClient(host="localhost", port=6333)

client.create_collection(
    collection_name="docs",
    vectors_config={
        "dense": VectorParams(size=768, distance=Distance.COSINE),  # nomic-embed-text-v1.5
    },
    sparse_vectors_config={
        "bm25": SparseVectorParams(index=SparseIndexParams(on_disk=False)),
    },
)

# Query: hybrid search + payload filter, no separate BM25 process needed
from qdrant_client.models import Filter, FieldCondition, MatchValue, Prefetch

results = client.query_points(
    collection_name="docs",
    query=dense_vec,
    using="dense",
    prefetch=[
        Prefetch(query=sparse_vec, using="bm25", limit=25),
        Prefetch(query=dense_vec, using="dense", limit=25),
    ],
    query_filter=Filter(
        must=[FieldCondition(key="document_type", match=MatchValue(value="contract"))]
    ),
    limit=50,  # before rerank
)

Busca híbrida: BM25 + Vetor supera cada um separadamente

• Por que o denso puro falha: os embeddings subponderam tokens raros. Consultas como "RFC 9110 seção 7.4" ou "MNDA-2024-0143" se incorporam perto de chunks IETF/contrato genéricos. BM25 captura o identificador exato; a busca pura por cosseno o perde.
• Por que o BM25 puro falha: a correspondência lexical perde paráfrases. Uma consulta "Como cancelamos?" contra um chunk intitulado "Procedimentos de rescisão" corresponde no espaço denso mas pontua 0 no BM25.
• Reciprocal Rank Fusion (RRF) é o combinador padrão: para cada chunk que aparece em qualquer uma das listas de resultados, pontue como 1/(60+rank_dense) + 1/(60+rank_bm25). Ordene de forma descendente. O 60 é uma constante de suavização; valores entre 30–100 funcionam na prática.
• Receita prática: recupere os top-25 de cada método, combine via RRF, pegue os top-50, envie a um reranker e depois os top-6–8 ao LLM. Este é o pipeline padrão de produção em qualquer escala além de 1.000 documentos.
• Custo de armazenamento: os índices BM25 são pequenos (~50–150 MB por 10.000 documentos) em comparação com os índices densos (~500 MB–2 GB na mesma escala). Adicionar BM25 a um store denso existente é econômico.

Reranking: a etapa de refinamento Top-N

• BGE-reranker-v2-m3 (~570 MB, multilíngue, Apache 2.0) é a escolha padrão em maio de 2026. Funciona a 50–100 candidatos/seg em uma CPU moderna; 400+ /seg em GPU. O custo de latência para reranking de top-50 é ~200–500 ms em CPU, ~80–150 ms em GPU.
• Por que os cross-encoders ganham em recuperação: os embeddings densos codificam a consulta e o documento independentemente, então o modelo nunca os vê juntos. Um cross-encoder lê `[CLS] consulta [SEP] candidato [SEP]` conjuntamente e pontua o par diretamente. O Recall@5 tipicamente salta 15–25 pontos.
• Onde injetar o reranker: depois da busca híbrida, antes do LLM. Pegue os top-50 do híbrido, reordene para top-6–8, e envie esses ao LLM como contexto.
• Alternativa — API Cohere Rerank: maior qualidade mas requer uma chamada à nuvem. Para stacks completamente locais, o BGE-reranker-v2-m3 é o padrão prático. O mxbai-rerank-base-v2 é um forte candidato alternativo.
• Omitir o reranker é aceitável abaixo de 1.000 documentos: o ganho de qualidade não justifica o custo de latência. Além de 5.000 documentos, omiti-lo deixa ~15–25% das respostas baseadas nos chunks errados.

Filtragem de metadados: pré-reduza o espaço de busca

• Campos de payload universais a preencher no tempo de indexação: source_filename, page_number, document_type (artigo / contrato / nota / wiki), author, year, language, mais tags específicas do domínio (ex.: case_number, project_id, client_id).
• Pré-filtro no tempo de consulta: "O que a ata do conselho do T3 2024 disse sobre preços?" → filtre document_type=board_minutes AND year=2024 AND quarter=3 primeiro, depois busca vetorial dentro de ~12 documentos em vez dos 10.000.
• Suporte do vector store: os payloads do Qdrant, as propriedades do Weaviate, os metadados do ChromaDB e as colunas de esquema do LanceDB suportam todos a filtragem. O desempenho varia — a filtragem de payload do Qdrant em campos indexados é submilissegundo; a filtragem de metadados do ChromaDB em >100k chunks pode adicionar 50–150 ms.
• Auto-extração de metadados: para corpus jurídicos, uma pequena etapa de LLM no tempo de indexação pode extrair números de caso, datas e nomes de partes por documento. Custa ~30 segundos por documento em Llama 3.3 8B; executa uma vez por ingest.
• Combine com busca híbrida: o filtro de payload reduz o universo → recuperação BM25 + densa dentro do conjunto filtrado → rerank. O filtro de payload é a aceleração mais barata de 5–10 vezes em qualquer sistema RAG grande.

Recuperação hierárquica: resumo primeiro, chunks depois

• Resumos por documento: no tempo de indexação, peça ao LLM para escrever um resumo de 100–200 tokens de cada documento. Gere embeddings desses resumos em uma coleção summaries separada. O custo é ~30–90 segundos por documento em Llama 3.3 8B.
• Recuperação em dois estágios: (1) gere o embedding da consulta, busque em summaries, pegue os top-5 documentos; (2) dentro desses 5 documentos, recupere os top-8 chunks via busca híbrida; (3) aplique reranking se necessário; (4) envie ao LLM.
• Quando ajuda mais: consultas de síntese e multidocumento ("compare como esses artigos abordam X"). A recuperação de fatos ("qual valor Smith reportou?") funciona bem apenas com o índice de chunks — o desvio pelo resumo adiciona latência sem ganho de qualidade.
• Troca de custo: dobra o armazenamento do índice (os resumos são pequenos mas o índice em si é infraestrutura duplicada). Dobra a latência para consultas não roteadas. O ganho está na redução de ruído a partir de 10.000+ documentos.
• O LlamaIndex incorpora: DocumentSummaryIndex mais RouterQueryEngine é uma implementação de 30 linhas. Python personalizado com ChromaDB ou Qdrant é ~80–120 linhas.

Benchmarks medidos a 100, 1.000 e 10.000 documentos

Dimensionamento de armazenamento e requisitos de hardware

• Texto bruto por 1.000 PDFs (~12 páginas cada): ~50–150 MB de texto extraído. Altamente variável conforme a densidade.
• Vetores a 1.000 docs: ~300–400 MB em disco incluindo o overhead do índice HNSW. ~120–180 MB se omitir o índice HNSW e usar busca por força bruta (aceitável abaixo de 5.000 docs).
• Vetores a 10.000 docs: ~3–5 GB em disco. A construção HNSW leva 10–30 minutos em uma CPU moderna.
• Vetores a 50.000 docs: ~15–25 GB em disco. O tempo de construção do índice é o gargalo — planeje 2–4 horas de trabalho de CPU único.
• RAM durante a consulta: a recuperação densa precisa de ~30–50% do índice em memória de trabalho para consultas de baixa latência. Um índice de 5 GB é consultado confortavelmente com 8–16 GB de RAM com HNSW; a força bruta precisa do índice completo em memória.
• RAM durante a indexação: sobe para 2–3 vezes o tamanho do modelo de embedding (~600 MB para nomic-embed-text) mais o texto por lote. 8 GB de RAM livre é suficiente para a etapa de indexação.
• GPU vs CPU: o throughput de embedding é 4–8 vezes mais rápido em uma GPU discreta ou Apple Silicon. Para indexação de uma única passagem com 10.000+ documentos, a GPU economiza 1–3 horas. Para o embedding no tempo de consulta (uma consulta por vez), a CPU é suficiente.
• O tipo de disco importa: SSD NVMe é o mínimo prático a partir de 5.000+ documentos. SSD SATA adiciona 30–100% à latência de consultas frias; disco giratório é inutilizável além de ~2.000 documentos.

Indexação incremental e deduplicação

• Dedup exato baseado em hash no ingest: SHA-256 dos bytes brutos do arquivo. Pule arquivos cujo hash já está no índice. Barato, captura arquivos idênticos mas perde quase-duplicados (diferentes passagens OCR do mesmo escaneamento, conversões de formato).
• Dedup por hash de conteúdo: SHA-256 do texto simples extraído após remover espaços em branco. Captura o mesmo documento em diferentes formatos de arquivo. Adiciona ~5 ms por arquivo no ingest.
• MinHash para quase-duplicados: para corpus jurídicos e acadêmicos onde múltiplos rascunhos do mesmo documento se acumulam, calcule uma assinatura MinHash (~128 bytes por documento) e pule arquivos dentro de um limiar de similaridade Jaccard de uma entrada existente.
• Os IDs de documento são permanentes: nunca reutilize um ID de documento após excluí-lo. Os vector stores frequentemente retêm vetores órfãos brevemente; reutilizar IDs causa confusão silenciosa. Use UUIDs ou IDs baseados em hash.
• Re-embedding ao trocar o embedder: todas as arquiteturas forçam uma reindexação completa quando você troca o modelo de embedding. Planeje uma escolha de embedder à qual você se comprometa por pelo menos um ano antes de indexar 10.000 documentos.
• Exclusões: ChromaDB e Qdrant suportam a exclusão de pontos por ID. LanceDB requer uma etapa de compactação para recuperar espaço em disco — planeje isso semanalmente se você excluir mais de ~5% do corpus por mês.

Monitoramento da qualidade RAG em escala

• Construa um conjunto dourado pequeno: 30–50 consultas para as quais você conhece a resposta correta, extraídas de uso real. Inclua recuperação de fatos (5–10), síntese (5–10), entre documentos (5–10), casos extremos (5–10) e consultas de miss conhecido (5–10) onde a resposta não está no corpus.
• Rastreie três métricas por consulta: recall de recuperação (o chunk correto apareceu no top-K?), fidelidade de geração (a resposta corresponde ao chunk?) e taxa de rejeição (o sistema diz corretamente "não está no corpus" para consultas de miss conhecido?).
• Re-execute a cada mudança significativa: novos lotes de ingest, trocas de embedder, mudanças de tamanho de chunk, ajustes de prompt. Compare os resultados com a execução anterior; marque qualquer consulta cujo recall de recuperação ou resposta mudou.
• Trulens ou RAGAS para frameworks de avaliação automatizada. Ambos rodam localmente e se integram com LlamaIndex. A pontuação manual de 30–50 consultas também é válida e frequentemente mais precisa.
• Orçamentos de latência: rastreie a latência de consulta p50 e p95 ao longo do tempo. Um salto de 50% no p95 tipicamente significa que o índice excedeu a RAM — o sinal precoce de que você precisa avançar para o próximo nível de arquitetura.

Perguntas frequentes

Leituras relacionadas

• AnythingLLM vs PrivateGPT vs Open WebUI: O melhor RAG local em 2026 — contexto base para escolher a plataforma RAG de desktop antes de escalar.
• Os melhores modelos de embedding para RAG local em 2026 — a escolha do embedder é a decisão individual mais importante antes de indexar 10.000 documentos.
• RAG local para dados empresariais privados — escalonamento natural quando o RAG em escala pessoal encontra requisitos de conformidade empresarial.
• Construa RAG local nos seus PDFs em 30 minutos (Ollama + AnythingLLM) — a configuração de nível básico antes de atingir o penhasco de escalonamento.
• RAG explicado: Como ancorar as respostas da IA em dados reais (2026) — autoridade conceitual sobre o que é RAG e por que cada componente de recuperação importa.
• Guia de hardware para LLM local 2026 — referência de dimensionamento de hardware para corpus de 10.000+ documentos.
• Hub Power Local LLM — biblioteca completa de guias do cluster.