"Conversar com os seus documentos" é a funcionalidade que mais gente quer copiar e a que mais gente implementa errado. O erro é sempre o mesmo, e ele é caro.
1. O que tem dentro · 2. O cérebro · 3. Os olhos (OCR) · 4. A memória (documentos) ← você está aqui · 5. Imagem · 6. Vídeo · 7. Voz · 8. Ferramentas e agentes · 9. Juntando tudo e a conta
Primeiro, o mal-entendido
Quando o ChatGPT responde "de acordo com o arquivo que você enviou", não existe nenhum arquivo guardado dentro do modelo. Como vimos na parte 2, o modelo não lembra de nada entre uma chamada e outra.
O que existe é um sistema de busca: o documento foi fatiado e indexado antes; a cada pergunta, os pedaços mais relevantes são recuperados e colados no prompt. O modelo recebe a pergunta e os trechos, e responde. Esse arranjo tem nome — RAG, geração aumentada por recuperação — e é a peça de memória do seu produto.
Por que não mandar o documento inteiro
A pergunta é justa: se o contexto do modelo cabe 1 milhão de tokens, por que não jogar o manual inteiro em toda pergunta e pronto?
Porque você paga por isso em toda pergunta. Um manual de 300 páginas tem uns 210 mil tokens. Um assistente de suporte com mil perguntas por dia:
| Abordagem | Tokens de entrada por pergunta | Custo por dia (mil perguntas) | Custo por mês |
|---|---|---|---|
Manual inteiro em toda pergunta (gpub-plus) | 210.000 | R$ 145 | R$ 4.350 |
Busca, 4 trechos relevantes (gpub-plus) | ~2.200 | R$ 1,52 | R$ 46 |
Noventa e cinco vezes de diferença, e o custo não é nem o pior problema:
- A qualidade piora. Todo modelo perde precisão quando a informação está enterrada no meio de um contexto gigante. Quatro trechos certos produzem resposta melhor que 300 páginas de palheiro.
- A latência explode. Processar 210 mil tokens leva segundos. O usuário encara a tela parada.
- Não escala. Funciona com um manual. Com o acervo inteiro da empresa, não cabe em contexto nenhum.
Como a busca funciona, sem mistério
1. Fatiar
O documento é cortado em pedaços de algumas centenas de palavras. Parece trivial e é a etapa que mais afeta a qualidade final — mais que a escolha do modelo.
Cortar a cada N caracteres é o jeito ruim: parte tabela no meio, separa o título da cláusula do texto dela. O jeito bom é cortar por estrutura — por seção, por cláusula, por artigo — e deixar uma sobreposição de 10% a 15% entre pedaços vizinhos, para que uma frase que ficou na fronteira não se perca.
Tamanho que funciona na maioria dos casos: 300 a 800 tokens por pedaço. Muito pequeno perde contexto; muito grande dilui o significado e encarece a entrada.
2. Transformar em coordenada de significado
Cada pedaço passa por um modelo de embedding, que devolve uma lista de números — uma coordenada num espaço onde textos com significado parecido ficam perto uns dos outros.
É o que permite "férias proporcionais" encontrar um trecho que fala em "período aquisitivo incompleto" sem que nenhuma palavra coincida. Para português, use um modelo multilíngue moderno; ele roda numa placa pequena, e indexar um acervo inteiro é trabalho de uma tarde.
3. Guardar
As coordenadas vão para um banco vetorial — Qdrant é a escolha madura e roda em 1 clique. Ele responde "me dê os 20 pedaços mais próximos desta pergunta" em milissegundos, sobre milhões de trechos.
4. Buscar e responder
A pergunta do usuário vira coordenada pelo mesmo modelo, o banco devolve os vizinhos, e os melhores trechos entram no prompt junto da pergunta. O cérebro faz o resto.
O detalhe que separa o brinquedo do produto
Busca por significado é ótima para conceito e péssima para identificador. Procure pelo contrato "CT-2024-0917", pelo SKU "MX-4410" ou pelo CPF de alguém e a busca vetorial devolve trechos parecidos — outros contratos, outros códigos — porque para o modelo de embedding todos esses códigos são igualmente "um código".
A correção é busca híbrida: rode em paralelo a busca vetorial e uma busca clássica por palavra-chave, e combine as duas listas. É a mudança de maior impacto por linha de código em todo sistema de RAG. Deixar de fazer isso é a causa número um de "o assistente não acha o que eu sei que está lá".
Depois da híbrida, o segundo ganho é a reordenação: pegue os 20 melhores candidatos e passe por um modelo pequeno que os reordena por relevância de verdade, ficando com os 4 primeiros. Custa pouco e melhora bastante a precisão da resposta.
Citar a fonte não é opcional
Toda resposta precisa dizer de onde saiu: documento, seção, página. Por três motivos práticos:
- Confiança. Uma resposta com fonte pode ser conferida em dez segundos; sem fonte, o usuário precisa acreditar.
- Depuração. Quando a resposta sai errada, a citação mostra se o problema foi a busca (trouxe o trecho errado) ou o modelo (recebeu o certo e respondeu mal). São correções completamente diferentes.
- Freio na invenção. Instruir "responda apenas com base nos trechos; se não estiverem lá, diga que não encontrou" reduz muito a alucinação. Não zera — mas reduz.
"Responda exclusivamente com base nos trechos fornecidos. Cite o documento e a seção de cada afirmação. Se a resposta não estiver nos trechos, diga que não encontrou essa informação nos documentos — não use conhecimento próprio para completar."
Simples, e é o que separa um assistente que erra com humildade de um que erra com convicção.
Onde cada peça roda, e o que custa
| Peça | Ferramenta | Onde | Custo típico |
|---|---|---|---|
| Fatiar | Código próprio | CPU | R$ 0 |
| Embeddings (indexação inicial) | Modelo multilíngue aberto | GPU de R$ 1,07/h, algumas horas | poucos reais, uma vez |
| Embeddings (novas perguntas) | Mesmo modelo | Máquina pequena sempre ligada | centavos por dia |
| Banco vetorial | Qdrant | CPU, sempre ligada | baixo e constante |
| Resposta | API por token (gpub-plus) | Por chamada | ~R$ 0,0015 por pergunta |
Repare no padrão de novo: a indexação é uma rajada — liga a GPU, processa o acervo, desliga. A resposta é constante — e é por isso que ela é paga por token.
O caminho sem código
Se você quer o resultado antes de construir a engenharia, o AnythingLLM sobe em 1 clique e entrega o pacote inteiro: upload de arquivos, indexação, interface de conversa e controle de usuários. Aponte-o para a API por token como cérebro e você tem um assistente sobre os seus documentos funcionando na mesma tarde.
É a forma certa de validar se as pessoas vão usar antes de investir semanas montando o pipeline sob medida.
Quando NÃO usar busca
Sendo justo com a alternativa: se o seu acervo é pequeno — um manual de 30 páginas, uma política, um FAQ — mandar tudo em toda pergunta é mais simples e funciona melhor. São uns 20 mil tokens, R$ 0,014 por pergunta no modelo intermediário. Montar RAG para isso é engenharia demais para problema de menos.
A régua prática: acima de umas 100 páginas, ou quando o acervo cresce toda semana, monte a busca. Abaixo disso, não.
A busca é sua; o cérebro é por token
Indexe o seu acervo numa placa por hora e desligue. As respostas do dia a dia são chamadas de API cobradas por token, em reais, com um modelo aberto compatível com o padrão OpenAI.
Ver a API por token →Próxima parte: o pincel — geração de imagens.
Continue: RAG de produção · embeddings em português · Qdrant em 1 clique