DeepSeek entende documentos longos em português? Teste de contexto do V4

Resposta curta: sim, dentro deste teste controlado de API. DeepSeek V4 Flash e V4 Pro acertaram estritamente 162 de 162 respostas em documentos sintéticos de 15.999, 128.001 e 512.001 tokens. O resultado inclui extração, ligação entre trechos e recusa de dados ausentes em posições próximas de 10%, 50% e 90% do texto — mas não prova desempenho em PDFs reais, OCR, tabelas, imagens ou todo documento em português.

Teste executado em 8 de agosto de 2026: 162 chamadas Chat Completions, todas HTTP 200, sem retry, sem divergência de model ID e sem conteúdo de raciocínio. Os resultados valem somente para os corpora, prompts, rota, modelos e data registrados.

O objetivo foi responder a uma pergunta prática: quando a informação está no começo, no meio ou no fim de um documento longo em português brasileiro, o DeepSeek consegue encontrar o registro certo, ignorar um identificador quase igual, combinar fatos distantes e dizer “não encontrado” sem inventar? Para tornar a resposta verificável, geramos os textos de forma determinística, fixamos o tokenizer e publicamos protocolo, resultados e hashes.

Resultado principal do teste de documentos longos

DeepSeek V4 Flash

  • Aprovação estrita: 81/81
  • Tokens de entrada: 17.731.233
  • Tokens de saída: 1.968
  • Custo observado: US$ 0,051414738
  • Model ID devolvido: deepseek-v4-flash

DeepSeek V4 Pro

  • Aprovação estrita: 81/81
  • Tokens de entrada: 17.731.233
  • Tokens de saída: 2.159
  • Custo observado: US$ 0,069978189
  • Model ID devolvido: deepseek-v4-pro
Resultado por tamanho do teste DeepSeek V4 com documentos longos em português

Somados, os dois modelos passaram em 162/162 respostas avaliadas (100%): 27 condições, dois modelos e três repetições. Isso inclui 54 extrações, 54 ligações entre dois trechos e 54 recusas de campos ausentes. O custo observado total foi US$ 0,121392927. Não houve vantagem de acurácia do Pro neste corpus; na rodada completa, dominada por cache hits, o Flash custou menos e teve mediana de latência menor nos três tamanhos.

Latência e custo observados na rodada completa

Documento de 15.999 tokens

  • Flash: 27/27; mediana de 1.449 ms; custo de US$ 0,001813566.
  • Pro: 27/27; mediana de 1.727 ms; custo de US$ 0,003425103.

Documento de 128.001 tokens

  • Flash: 27/27; mediana de 2.380 ms; custo de US$ 0,010285806.
  • Pro: 27/27; mediana de 2.672 ms; custo de US$ 0,014423643.

Documento de 512.001 tokens

  • Flash: 27/27; mediana de 6.525 ms; custo de US$ 0,039315366.
  • Pro: 27/27; mediana de 6.597 ms; custo de US$ 0,052129443.

Latência é uma observação desta conta e desta janela, não um SLA. Rede, fila, região, cache e backend podem mudar o tempo. Os tamanhos são contagens do documento; o prompt_tokens da API também inclui instruções, pergunta e overhead.

Latência mediana e taxa de cache observadas por tamanho no teste de documentos longos do DeepSeek V4

O piloto registrou uma única chamada inicial sem cache por modelo e tamanho. Em 512 mil tokens, ela custou US$ 0,07172158 no Flash e US$ 0,222856155 no Pro; as latências foram 41.410 ms e 16.120 ms, respectivamente. Como existe só uma observação inicial por célula, esses números mostram o impacto possível de uma primeira leitura, mas não sustentam uma conclusão estável de velocidade.

Por que o custo ficou muito abaixo da projeção conservadora?

Para cada modelo, a API informou 17.722.368 tokens de entrada em cache e 8.865 sem cache — cerca de 99,95% dos tokens de entrada foram classificados como cache hit. O protocolo agrupou perguntas do mesmo documento e modelo para manter um prefixo comum, mas o cache foi apenas observado, não controlado. Ele não é garantido em outra conta, horário ou ordem.

A projeção de segurança antes da rodada tratava toda entrada como cache miss e estimava até US$ 10,26. O custo calculado foi US$ 0,1214 porque a API informou tokens em cache e sem cache, aos quais aplicamos os preços oficiais de 8 de agosto de 2026. Não use esse valor como orçamento sem testar sua própria carga. A página de preços do DeepSeek explica a fórmula e seus limites.

Como construímos os documentos

Os três corpora contêm registros administrativos fictícios em português brasileiro, sem pessoas ou eventos reais. A geração usa a seed fixa deepseek-portugues-long-context-v1-2026-08-08. Cada documento tem fontes principais aproximadamente em 10%, 50% e 90% dos tokens, seguidas por um “decoy”: um registro com identificador quase igual, mas código e quantidade diferentes.

A posição realizada ficou muito próxima de cada alvo. Por exemplo, no corpus de 512.001 tokens, as fontes começaram em 9,9998%, 49,9997% e 90,0000%. Cada corpus e cada pergunta têm SHA-256 próprio; o runner recusaria misturar resultados com outro manifesto.

Como contamos os tokens

A contagem local usa o tokenizer oficial de DeepSeek V4 Pro, fixado no commit 0e1a0e5e52aea73055f50fef6f2423db370265b6. O arquivo tokenizer.json tinha 6.367.146 bytes e SHA-256 8f9f37ca37fdc4f5fd36d5cf4d3b0e8392edb4e894fd10cc0d70b4957c8633cf. O adaptador local também foi fixado por hash.

  • Alvo 16K: 15.999 tokens realizados.
  • Alvo 128K: 128.001 tokens realizados.
  • Alvo 512K: 512.001 tokens realizados.

Esses números descrevem somente o texto do documento. A contagem retornada pela API é maior porque o request inclui system prompt, contrato JSON e pergunta. Para entender o efeito do português brasileiro sobre tokenização, consulte Quantos tokens o português brasileiro usa?.

Matriz de perguntas: localizar, cruzar e não inventar

1. Extração

Em cada tamanho, três perguntas pediam o código de confirmação de um ID exato nas posições de 10%, 50% e 90%. O modelo precisava ignorar o registro quase igual com sufixo. Foram 54/54 aprovações considerando modelos e repetições.

2. Ligação entre trechos

Três perguntas por tamanho exigiam somar quantidades de duas fontes distantes e devolver os dois IDs na ordem pedida: 10% + 50%, 50% + 90% e 90% + 10%. Foram 54/54 aprovações.

3. Ausência de informação

As perguntas pediam CPF, diagnóstico médico ou cartão bancário que não existiam no corpus. A única resposta válida era status: not_found, answer: null e lista de fontes vazia. Foram 54/54 aprovações, sem invenção nos campos avaliados.

Configuração da rodada ao vivo

  • Endpoint: https://api.deepseek.com/chat/completions.
  • Modelos: deepseek-v4-flash e deepseek-v4-pro.
  • Volume: 27 condições × 2 modelos × 3 repetições = 162 chamadas.
  • Parâmetros: temperature: 0, stream: false, Thinking desativado, resposta JSON e máximo de 256 tokens de saída.
  • Contrato: exatamente três chaves: status, answer e source_ids.
  • Validação: HTTP 200, término stop, model ID exato, JSON válido, chaves exatas e valores iguais ao gold.
  • Repetição automática: nenhuma das 162 chamadas precisou de retry.

O endpoint e a configuração seguem a documentação oficial de Chat Completions. Modelos, contexto e preços foram conferidos em Models & Pricing da DeepSeek. Para diferenças entre V4 Flash e Pro, veja o nosso guia do DeepSeek V4.

Dados, hashes e reprodução

O pacote abaixo reúne protocolo, manifesto, perguntas e respostas esperadas, resultados CSV/JSONL, resumo e checksums. Os resultados não contêm chave, headers de autorização, request completo nem o corpus repetido em cada linha. Os textos sintéticos brutos ficam no pacote de reprodução para que a posição e os hashes possam ser verificados.

SHA-256 do manifesto executado: 012d32fb9987f725837015681a017d688cb25cbd36f38037bca546ad7c05d7dc. SHA-256 do ZIP publicado: 751a83e7c890521a69353e1792ead6e01d477a2f94711b3f0fe47304877eaa44.

O que o resultado permite concluir

  • Ambos os modelos recuperaram os fatos exatos nos três tamanhos e nas três posições do corpus.
  • Ambos ligaram duas fontes distantes e preservaram a ordem dos IDs em todas as repetições.
  • Ambos recusaram os campos ausentes no formato exato, sem usar os decoys.
  • Neste corpus, o V4 Pro não adicionou aprovações ao Flash; o Flash foi mais econômico.
  • A API aceitou documentos de 512.001 tokens neste endpoint, conta e data, com respostas HTTP 200.

O que o resultado não permite concluir

  • Não testamos upload de PDF, DOCX ou imagem. O documento foi enviado como texto na API.
  • Não medimos OCR, layout, tabelas, gráficos, notas de rodapé, referências jurídicas ou linguagem técnica real.
  • Não testamos 1 milhão de tokens. Sucesso em 512K não confirma o limite máximo anunciado.
  • Não testamos o aplicativo, o chat público, pesquisa na web, memória ou ferramentas.
  • Os textos são sintéticos e o conjunto é público, não uma amostra privada de documentos brasileiros.
  • Três repetições mostram estabilidade observada, mas não sustentam uma afirmação universal.
  • O cache foi observado, não controlado; custo e latência podem mudar substancialmente.
  • Não houve revisão humana. O campo de revisão manual permanece N/A; o score é automático e exato.

Como aplicar isso a um documento real

  1. Converta o arquivo para texto preservando títulos e referências. Se houver OCR, avalie seus erros separadamente.
  2. Crie perguntas com respostas verificáveis no documento e inclua casos de informação ausente.
  3. Espalhe fatos no começo, meio e fim; adicione termos parecidos para testar confusão.
  4. Exija uma saída estruturada com fontes e valide cada campo automaticamente.
  5. Teste primeiro uma amostra pequena, registre model ID e uso, defina um teto de custo e só depois aumente o lote.
  6. Faça revisão humana adequada ao risco antes de usar a resposta em decisão jurídica, médica, financeira ou operacional.

Para implementar a rota com segurança, consulte o guia da API DeepSeek e o material sobre Thinking Mode. Esta rodada desativou o raciocínio deliberado para isolar recuperação e formato.

Perguntas frequentes

DeepSeek leu 512 mil tokens em português?

Sim, neste teste de API: os corpora tinham 512.001 tokens segundo o tokenizer oficial fixado, e Flash e Pro passaram em 27/27 respostas cada nesse tamanho. Isso não equivale a testar todos os PDFs ou o limite de 1 milhão.

Foi feito upload de PDF?

Não. Enviamos texto sintético diretamente ao endpoint Chat Completions. OCR, imagens, tabelas e diagramação ficaram fora do escopo.

V4 Flash ou V4 Pro foi melhor?

Empataram em acurácia estrita: 81/81 cada. O Flash teve menor custo total e menor mediana de latência em 16K, 128K e 512K nesta sessão. Outros documentos podem favorecer outra escolha.

Como os tokens foram contados?

Com o tokenizer oficial do DeepSeek V4 Pro em uma revisão imutável, conferida por SHA-256. A API também informou os tokens de uso em cada request; o custo apresentado foi calculado com os preços oficiais da data.

Houve revisão humana?

Não. Todos os resultados foram avaliados por checks automáticos pré-definidos; a revisão humana permanece N/A. Como as respostas eram JSON fechado, o teste não atribui nota de naturalidade.


Última verificação: 8 de agosto de 2026. Este é um estudo independente e não representa a DeepSeek. O protocolo será repetido no mesmo URL quando houver mudança material de modelo, rota, tokenizer ou preço.