RAG: como dividir documentos para um vector database

--- queue_position: 35 title: "RAG: como dividir documentos para um vector database" slug: rag-dividir-documentos-vector-database site_key: host-yousecure canonical: https://yousecure.io/blog/rag-dividir-documentos-vector-database category: vector-databases cluster: rag-ingestao search_intent: informacional-pratica funnel_stage: meio author: "Host You Secure Team" created_at: "2026-09-09T11:29:43-03:00" planned_scheduled_at: null status: queued-review meta_description: "Aprenda a dividir documentos para RAG: preservar contexto, usar metadados, testar overlap e medir recuperação no vector database." excerpt: "Chunking não é cortar texto a cada N caracteres; é preservar unidades que façam sentido para a pergunta do usuário." quick_answer: "Divida por estrutura semântica, mantenha metadados de origem, aplique overlap moderado e avalie retrieval com perguntas reais antes de ajustar o tamanho." featured_image: images/35-rag-chunking.png featured_image_alt: "Documentos divididos em blocos semânticos e enviados a um índice vetorial" tags: [rag, embeddings, vector-database, ia, busca-semantica] evidence_type: reproducible_procedure evidence_environment: Pipeline de ingestão de documentos e banco vetorial em ambiente de teste evidence_procedure: "Criar chunks por parágrafo/seção, indexar metadados, recuperar top-k e avaliar perguntas anotadas." evidence_observed_result: "A avaliação por perguntas mostra se os trechos recuperados preservam resposta e fonte." evidence_limitation: "Resultado varia com modelo de embedding, idioma, domínio, top-k e conteúdo." information_gain: "Prioriza contexto, metadados e avaliação de retrieval, não um tamanho mágico de chunk." primary_cta: "Ver VPS para IA" landing: /hosting_vps --- # RAG: como dividir documentos para um vector database ## Resposta rápida Chunking deve preservar a unidade de sentido que responde à pergunta. Comece por títulos, seções e parágrafos; mantenha metadados de documento e posição; use overlap apenas quando necessário; depois avalie a recuperação com perguntas reais. Não existe um tamanho universal que funcione para manuais, contratos e artigos ao mesmo tempo. ## Por que cortes ruins prejudicam o RAG Um chunk que separa título de tabela perde contexto. Um bloco enorme mistura assuntos e reduz precisão. O retriever pode encontrar palavras certas, mas sem condição, versão ou exceção. A geração então parece fluente e responde errado. ## Preserve a estrutura Extraia título, seção, subtítulo, página, URL, versão e permissões. Divida primeiro por cabeçalhos e parágrafos; só quebre um parágrafo longo quando necessário. Para tabelas, preserve cabeçalho e unidade junto das linhas que dependem deles. Para código, mantenha assinatura, imports relevantes e explicação próxima. ## Metadados e rastreabilidade Cada vetor deve apontar para `source_id`, seção, posição e URL ou arquivo de origem. Esses campos permitem filtros, citações e depuração. Não indexe documentos que o usuário não pode acessar; filtre autorização no retrieval, não apenas na interface. ## Teste tamanho e overlap Crie duas ou três variantes, não dezenas. Para cada uma, execute um conjunto de perguntas anotadas: resposta esperada, documento correto e trecho suficiente. Compare recall, precisão, latência e custo. Overlap aumenta contexto, mas também duplica vetores e pode aumentar ruído. Uma avaliação mínima: ```text pergunta → top-k trechos → fonte esperada encontrada? → contexto suficiente? → resposta correta? ``` Registre versão do parser, embedding, índice e dataset. Sem isso, uma mudança parece melhoria apenas porque o conjunto mudou. ## Operação Faça ingestão incremental, remova versões antigas quando necessário e trate documentos muito grandes em etapas. Monitore falhas de parsing, filas e crescimento do índice. [Uma VPS para workloads de IA](https://yousecure.io/hosting_vps) deve ser dimensionada para CPU, memória, armazenamento e concorrência do pipeline. ## Checklist - [ ] Corte respeita seções e tabelas. - [ ] Metadados e permissões preservados. - [ ] Cada chunk tem fonte rastreável. - [ ] Retrieval foi avaliado com perguntas reais. - [ ] Versões do pipeline estão registradas. ## FAQ ### Chunks maiores sempre têm mais contexto? Mais texto pode significar mais ruído. O tamanho adequado é o que entrega contexto suficiente para o tipo de pergunta. ### Embedding resolve qualquer erro de chunking? Não. Um embedding não recupera contexto que foi cortado ou metadado que não foi preservado. ## Avalie o retrieval antes da geração Separe o teste em duas etapas. Primeiro, verifique se os trechos corretos aparecem no top-k; depois avalie se o modelo respondeu somente com esse contexto e citou a origem. Se o retrieval falha, trocar o prompt final mascara o problema. Mantenha um pequeno conjunto de perguntas difíceis, incluindo negações, versões e tabelas. Ele funciona como uma regressão para cada alteração no parser, no embedding ou no índice.