O que é chunking na IA e por que ele decide sua resposta

Equipe Viver de IA · 2026-07-31

A IA erra a resposta não porque é burra, mas porque você entregou o documento cortado errado. Chunking é o corte que ninguém vê.

O que é chunking na IA e por que a resposta nasce no corte

A Seprorad montou uma plataforma própria de gestão documental que centraliza todos os relatórios de inspeção e ainda garante validade jurídica com certificado A1, gerando R$ 15.000 em economia. Repare no detalhe: o valor de uma solução que lida com documento não está na IA, está em como o documento foi organizado antes da IA chegar perto dele. E é aí que entra a pergunta que quase ninguém faz na hora de contratar um projeto: o que é chunking na IA.

Chunking é o ato de picar um documento grande em pedaços menores antes de entregar pra IA. Simples assim na definição, brutal na consequência. Quando você joga um manual de 80 páginas dentro de um sistema de perguntas e respostas, a IA não lê o manual inteiro toda vez que alguém pergunta algo. Ela busca os pedaços mais parecidos com a pergunta e responde com base neles. Se o pedaço foi cortado no lugar errado, a resposta sai errada. Não é a IA que é ruim. É o corte.

A gente vê isso direto nos projetos. O time monta a base de conhecimento, joga tudo lá, testa três perguntas fáceis, funciona, comemora. Aí chega uma pergunta que depende de duas frases que ficaram em pedaços diferentes, e a IA responde metade certa, metade inventada. O problema nunca aparece no teste bonito. Aparece na pergunta real do cliente às 18h.

Como o corte vira resposta: o caminho por dentro do RAG

Antes de falar de tipo de corte, você precisa entender onde o chunking entra. RAG é a sigla pra dizer que a IA busca informação num acervo seu antes de responder, em vez de inventar da memória. O chunking é o primeiro passo desse caminho, e o mais subestimado.

Documento inteiro → Corte em pedaços → Cada pedaço vira número → Busca por semelhança → IA responde com os pedaços achados

Cada pedaço que você corta vira uma espécie de coordenada matemática (o nome técnico é embedding, mas você não precisa dele pra decidir nada). Quando alguém pergunta, o sistema transforma a pergunta em coordenada também e vai buscar os pedaços mais próximos. Devolve, sei lá, os cinco mais parecidos. A IA lê só esses cinco e responde.

Agora pensa na consequência prática. Se o pedaço certo tem a informação mas está afogado junto com três parágrafos que não têm nada a ver, a busca pode não achar ele, porque a semelhança fica diluída. E se a informação está partida em dois pedaços, o sistema pode trazer um e deixar o outro de fora. A IA responde com meia verdade e soa confiante. Esse é o pior cenário: erro com cara de acerto.

Os quatro jeitos de cortar, e onde cada um se encaixa

Não existe corte universal. Existe o corte certo pro tipo de documento que você tem. Na nossa leitura, dá pra organizar em quatro famílias, da mais burra pra mais inteligente.

1. Corte por tamanho fixo

Você define um número de caracteres ou palavras e corta a cada tanto, sem olhar o conteúdo. É o mais simples e o mais usado por quem está começando. Funciona pra texto corrido homogêneo, tipo um artigo longo ou uma transcrição de reunião.

O problema óbvio: ele corta no meio da frase. No meio de uma tabela. No meio de um passo de um procedimento. Aí o pedaço fica sem sentido sozinho, e a IA tenta responder com um fragmento manco. Use quando o documento é uniforme e você quer velocidade. Não use em contrato, manual técnico ou nada com estrutura.

2. Corte com sobreposição

É o corte por tamanho fixo, mas cada pedaço repete um trechinho do pedaço anterior. Se o corte cai no meio de uma ideia, a sobreposição garante que a ideia inteira apareça em pelo menos um dos pedaços. É um remendo esperto no problema do corte por tamanho fixo.

Quase todo sistema sério de RAG usa alguma sobreposição. O custo é que você guarda mais pedaços (a informação repetida ocupa espaço), mas o ganho em qualidade de resposta compensa quase sempre. É o padrão que a gente recomenda pra quem não quer complicar e quer resultado decente.

3. Corte por estrutura do documento

Aqui você respeita a lógica do próprio documento: corta por título, por seção, por parágrafo, por item de lista. Cada pedaço vira uma unidade que já fazia sentido no original.

Esse é o corte que muda o jogo em documento estruturado. Manual com capítulos e subcapítulos. Contrato com cláusulas numeradas. Base de perguntas frequentes onde cada pergunta é uma unidade. A Seprorad lida com relatórios de inspeção, que têm estrutura de campos e seções; documento assim pede corte por estrutura, não por tamanho cego. Quando o pedaço nasce respeitando a cláusula ou a seção inteira, a busca fica muito mais precisa.

4. Corte por sentido

O mais sofisticado. Em vez de cortar por caractere ou por título, o sistema tenta identificar onde um assunto termina e outro começa, e corta ali. Dois parágrafos que falam da mesma coisa ficam juntos; quando o assunto vira, corta.

É o que entrega a melhor qualidade de resposta e o que dá mais trabalho pra montar. Vale quando o documento mistura muitos assuntos sem separação clara, tipo uma ata longa ou um e-mail extenso com vários temas. Pra 8 em cada 10 empresas começando, é overkill. Comece pelos três primeiros e só suba pra cá se a qualidade não estiver batendo.

O tamanho do pedaço é uma decisão de negócio, não de código

Aqui está o ponto que separa quem entende de quem só configurou. O tamanho do pedaço tem um trade-off que você, dono, consegue enxergar sem saber nada de programação.

+99%: melhoria no tempo operacional da TruckPag

Pedaço pequeno é preciso mas cego. Ele acha exatamente o trecho, mas perde o contexto ao redor. Se a resposta depende do parágrafo anterior pra fazer sentido, o pedaço pequeno falha. Pedaço grande carrega contexto mas dilui: a busca fica menos precisa porque o pedaço fala de várias coisas, e a IA recebe muito ruído junto com o sinal.

A TruckPag reposicionou a inteligência no centro do processo com automações integradas em n8n, ManyChat, CRM e WhatsApp, e chegou a mais de 99% de melhoria no tempo operacional. Não foi só ligar uma IA. Foi organizar a informação pra ela chegar no lugar certo, na hora certa, pro time comercial ser notificado sem esforço manual. A lógica é a mesma do chunking: informação bem cortada chega inteira e no momento útil.

Então a pergunta não é "qual o tamanho ideal". É "qual o tamanho ideal PRA ESTE documento e ESTE tipo de pergunta". Uma FAQ de suporte, onde cada pergunta é curta e autossuficiente, pede pedaço pequeno. Um manual jurídico, onde a cláusula só faz sentido junto com o parágrafo que a define, pede pedaço grande. Mesmo sistema, decisão oposta.

O erro mais comum: tratar todo documento igual

O erro que a gente mais vê não é escolher o corte errado. É escolher UM corte e aplicar em tudo. A empresa define "corta a cada 500 palavras com sobreposição" e passa isso no contrato, no manual, na planilha de preços e na transcrição da reunião, tudo junto.

Aí a resposta sobre o manual sai boa e a resposta sobre o contrato sai furada, e ninguém entende por quê. O motivo é que contrato e manual são documentos de naturezas diferentes e pedem cortes diferentes. Documento com tabela e número precisa de um cuidado; texto corrido precisa de outro.

Na prática, isso quer dizer que montar um RAG bom não é uma configuração única. É separar seus documentos por tipo e definir a regra de corte pra cada tipo. Dá mais trabalho no começo. Poupa meses de "por que a IA errou de novo" depois.

Como saber se o seu chunking está ruim?

O sintoma mais claro: a IA acerta perguntas genéricas e erra perguntas específicas que dependem de um detalhe. Se ela responde bem "qual o horário de atendimento" mas erra "o que a cláusula 8 diz sobre rescisão em caso de atraso", o problema quase sempre é corte, não modelo. A resposta específica exige o pedaço exato, inteiro, com o contexto certo, e é justamente isso que um corte descuidado destrói. Antes de trocar de IA, revise como o documento foi picado.

Um caminho prático pra acertar sem virar engenheiro

Você não precisa programar nada disso. Precisa saber cobrar da pessoa ou da plataforma que vai montar. Um roteiro que funciona:

1. Separe por tipo: agrupe seus documentos em famílias (contratos, manuais, FAQs, planilhas) antes de qualquer coisa
2. Defina o corte por família: estrutura pro que tem seções, sobreposição pro texto corrido, pedaço curto pra FAQ
3. Monte um banco de perguntas reais: liste as 20 ou 30 perguntas que seus clientes de fato fazem, incluindo as difíceis
4. Teste as difíceis primeiro: as fáceis sempre funcionam; a verdade aparece nas específicas
5. Ajuste o tamanho e repita: pedaço grande demais dilui, pequeno demais perde contexto, mexa e reteste

O passo que quase todo mundo pula é o do banco de perguntas reais. Testar com pergunta fácil é enganar a si mesmo. A pergunta que vale é aquela que o cliente faz irritado, que mistura dois assuntos, que depende de um detalhe escondido na página 40. Se o sistema acerta essa, o chunking está bom.

A régua: quando você mesmo resolve e quando chama método

Dá pra decidir com um critério de tamanho. Não de tamanho do pedaço, de tamanho do problema.

• Até uma ou duas fontes simples de documento (uma FAQ, um manual único, texto corrido homogêneo): resolve sozinho com corte por sobreposição e um banco de perguntas de teste. Ferramentas prontas dão conta e você aprende no processo.
• De três a cinco tipos de documento com estruturas diferentes (contrato + manual + planilha + base de atendimento): já pede corte por família e teste organizado. É fazível internamente, mas exige alguém com a rotina de dono do projeto, não um esforço de fim de semana.
• Acima disso, ou com documento crítico (jurídico, financeiro, onde uma resposta errada custa caro): aqui não é lugar pra tentativa e erro solto. Precisa de método, de teste estruturado e de alguém que já errou esse corte antes pra você não errar de novo.

E tem uma terceira via que a gente recomenda de verdade, entre "contratar um projeto fechado que entrega e some" e "montar do zero apanhando sozinho": implementar por dentro, com método e plataforma, usando um consultor de IA que te guia na decisão de corte enquanto a capacidade fica na sua empresa. Exige um dono interno e rotina, isso é honesto dizer. Em troca, quando o próximo documento entrar, você não depende de ninguém pra cortar certo.

Se você ainda não sabe em qual faixa da régua o seu caso cai, comece pelo diagnóstico de IA: ele mostra quantos tipos de documento você tem e onde o corte vai doer.

O chunking é invisível pro cliente final e decisivo pra ele. Ninguém vê o corte. Todo mundo sente a resposta errada. Cuide do corte antes de culpar a IA.

Relacionados

Automação com IA: o guia completo

Soluções de IA prontas para empresas

Mais de 500 cases reais de IA

IA na contabilidade e finanças: fechar o mês em dias

Como um escritório de contabilidade parou de vender hora e começou a vender produto: o caso ACP Contábil