Testei LLMs locais, gratuitos e pagos para traduzir PDFs via BabelDOC (E parei de gastar com modelos flagship) · Oletros

Meus 2 cents,

Estou trabalhando em um sistema de RAG (mais sobre isso no final do post), mas a questao eh que precisei de um pipeline para traduzir documentos PDF de EN para PT-BR para alimentar o sistema.

A parte de extrair o texto foi ate simples (converto PDF para Markdown/MD) e envio para um LLM (via OmniRoute e openrouter) fazer a traducao - nada fora do comum aqui.

Mas durante a atividade me surgiu a duvida:

Sera possível traduzir o PDF sem precisar "desmontar" o arquivo e mantendo o layout original ?

Apos algumas pesquisas e testes, achei o app que eh o centro deste post: BabelDOC

Baseado em Python, eh um app extremamente poderoso, facil de usar e com integracao nativa com LLMs para traducao.

O que chamou muito a atencao foram dois pontos:

a capacidade de manter o layout do PDF apos a traducao (dentro do possivel, claro)

- O modo "dual", onde ele gera um PDF com os dois textos simultaneos (original e a traducao)

Neste modo "dual" cada pagina vira duas com os textos aparecendo lado a lado (original e traduzido) - eh particularmente legal ler um documento traduzido com o acesso ao original simultaneo o que facilita comparar os termos e detalhes que as vezes uma traducao pode tornar um pouco obscuros ou imprecisos.

A instalacao do BabelDOC

No meu caso optei por clonar o repositorio localmente (seguindo os passos da documentacao):

# clone the project
git clone https://github.com/funstory-ai/BabelDOC

# enter the project directory
cd BabelDOC

# install dependencies and run babeldoc
uv run babeldoc

Rodando com LLM via openrouter e prompt customizado

Executei o BabelDOC com algumas configuracoes que achei praticas:

Openrouter como proxy para LLM (na pratica uso o OmniRoute, mas tirei neste exemplo para simplificar a explicacao),

Basta indicar a URL, API KEY e modelo, como se fosse da openAI - uma vez que a chamada eh compativel

Neste exemplo deixei o "modelo google/gemini-3.1-flash-lite", mas pode ser qualquer um - inclusive gratuitos

--openai --openai-base-url "https://openrouter.ai/api/v1" --openai-model "google/gemini-3.1-flash-lite" --openai-api-key "sk-or-v1-2A...g5"
Prompt de traducao customizado

--custom-system-prompt "<persona>You are an expert technical translator specializing in data engineering and distributed systems.</persona><constraints>1. Translate the text ensuring a natural, fluid, and technically accurate tone within the domain context. 2. DO NOT translate industry-standard technical terms; keep them in English (e.g., NoSQL, Sharding, Throughput, Cloud, Datastores).</constraints>"

Porque um prompt customizado ? Nos meus testes o prompt acima com o ajuste de persona ("...specializing in data engineering and distributed systems...") e constraints ("...DO NOT translate industry-standard technical terms...") melhorou levemente a analise de termos, traduzindo o idioma mas preservando razoavelmente bem os termos tecnicos. Nao eh essencial, mas gostei do resultado (pode ser efeito placebo ? pode - vou realizar mais testes sobre esta questao no futuro).
Indico o idioma de origem (ingles) e o de saida (portugues-brasil)

--lang-in "en-US" --lang-out "pt-BR"

O comando final

O comando que executo no meu terminal ficou:

uv run babeldoc --files dddv2.pdf --openai --openai-model "google/gemini-3.1-flash-lite" --openai-base-url "https://openrouter.ai/api/v1" --openai-api-key "sk-or-v1-2A...g5" --lang-in "en-US" --lang-out "pt-BR" --watermark-output-mode=no_watermark --disable-rich-text-translate --custom-system-prompt "<persona>You are an expert technical translator specializing in data engineering and distributed systems.</persona><constraints>1. Translate the text ensuring a natural, fluid, and technically accurate tone within the domain context. 2. DO NOT translate industry-standard technical terms; keep them in English (e.g., NoSQL, Sharding, Throughput, Cloud, Datastores).</constraints>"

PDF exemplo do resultado

Abaixo segue o link dos PDFs (original, traduzido dual e traduzido mono) para quem quiser comparar:

Exemplo de traducao entre LLMs

Usei diversos modelos para comparar os resultados de traducao, com LLMs flagship (no caso, Claude Opus 4.6) e tambem modelos de baixo custo, gratuitos e locais (via ollama)

Texto Original

O texto original que usei para servir de benchmark foi este:

Terminology: Declarative Query Languages

Many of the query languages discussed in this chapter (such as SQL, Cypher, SPARQL, and Datalog) are declarative, which means that you specify the pattern of the data you want — what conditions the results must meet and how you want the data to be transformed (e.g., sorted, grouped, and aggregated)—but not how to achieve that goal. The database system’s query optimizer can decide which indexes and join algorithms to use and in which order to execute various parts of the query.

In contrast, with most programming languages (such as Python and Java), you would have to write an algorithm telling the computer which operations to perform in which order. A declarative query language is attractive because it is typically more concise and easier to write than an explicit algorithm. More importantly, it hides implementation details of the query engine, which makes it possible for the database system to introduce performance improvements without requiring any changes to queries [1, 2].

For example, a database might be able to execute a declarative query in parallel across multiple CPU cores and machines, without you having to worry about how to implement that parallelism [3]. In a handcoded algorithm, it would be a lot of work to implement such parallel execution yourself.

Texto Traduzido (yinw1590/gemma4-e2b-text) GRATUITO / RODANDO LOCAL VIA OLLAMA

Texto traduzido por um LLM rodando localmente via Ollama

Terminologia: Linguagens de Consulta Declarativas

Muitas das linguagens de consulta discutidas neste capítulo (como SQL, Cypher, SPARQL e Datalog) são declarativas, o que significa que você especifica o padrão dos dados que deseja — quais condições os resultados devem atender e como você deseja que os dados sejam transformados (por exemplo, ordenados, agrupados e agregados) — mas não como alcançar esse objetivo. O query optimizer do sistema de banco de dados pode decidir quais indexes e quais join algorithms usar e em que ordem executar as várias partes da consulta.

Em contraste, com a maioria das linguagens de programação (como Python e Java), você teria que escrever um algoritmo dizendo ao computador quais operações realizar e em que ordem. Uma linguagem de consulta declarativa é atraente porque é tipicamente mais concisa e mais fácil de escrever do que um algoritmo explícito. Mais importante ainda, ela esconde os detalhes de implementação do query engine, o que permite que o sistema de banco de dados introduza melhorias de desempenho sem exigir quaisquer alterações nas consultas [1, 2].

Por exemplo, um banco de dados pode ser capaz de executar uma consulta declarativa em paralelo através de múltiplos CPU cores e máquinas, sem que você precise se preocupar com como implementar essa paralelização [3]. Em um algoritmo codificado manualmente (handcoded algorithm), seria muito trabalho implementar essa execução paralela por conta própria.

Texto Traduzido (translategemma) GRATUITO / RODANDO LOCAL VIA OLLAMA

Texto traduzido por um LLM rodando localmente via Ollama

Terminologia: Linguagens de Consulta Declarativas

Muitas das linguagens de consulta discutidas neste capítulo (como SQL, Cypher, SPARQL e Datalog) são declarativas, o que significa que você especifica o padrão dos dados que deseja – quais condições os resultados devem atender e como você deseja transformar os dados (por exemplo, ordenar, agrupar e agregar) – mas não como alcançar esse objetivo. O sistema de gerenciamento de banco de dados pode decidir quais índices e algoritmos de junção usar e em que ordem executar as várias partes da consulta.

Em contraste, com a maioria das linguagens de programação (como Python e Java), você teria que escrever um algoritmo que instruisse o computador sobre quais operações realizar e em que ordem. Uma linguagem de consulta declarativa é atraente porque geralmente é mais concisa e fácil de escrever do que um algoritmo explícito. Mais importante, ela esconde os detalhes de implementação do mecanismo de consulta, o que torna possível para o sistema de gerenciamento de banco de dados introduzir melhorias de desempenho sem exigir alterações nas consultas [1, 2].

Por exemplo, um banco de dados pode ser capaz de executar uma consulta declarativa em paralelo em vários núcleos de CPU e máquinas, sem que você precise se preocupar com a implementação dessa paralelização [3]. Em um algoritmo codificado manualmente, seria muito trabalhoso implementar tal execução paralela.

Texto Traduzido (claude opus 4.6) (PAGO)

Texto traduzido por um LLM flagship pago via openrouter

Terminologia: Declarative Query Languages

Muitas das query languages discutidas neste capítulo (como SQL, Cypher, SPARQL e Datalog) são declarativas, o que significa que você especifica o padrão dos dados que deseja — quais condições os resultados devem satisfazer e como você quer que os dados sejam transformados (por exemplo, ordenados, agrupados e agregados) — mas não como atingir esse objetivo. O query optimizer do sistema de banco de dados pode decidir quais indexes e algoritmos de join utilizar e em qual ordem executar as diversas partes da query.

Em contrapartida, com a maioria das linguagens de programação (como Python e Java), você precisaria escrever um algoritmo dizendo ao computador quais operações executar e em qual ordem. Uma declarative query language é atraente porque, em geral, é mais concisa e mais fácil de escrever do que um algoritmo explícito. Mais importante ainda, ela oculta os detalhes de implementação do query engine, o que torna possível ao sistema de banco de dados introduzir melhorias de desempenho sem exigir nenhuma alteração nas queries [1, 2].

Por exemplo, um banco de dados pode ser capaz de executar uma declarative query em paralelo, distribuindo-a entre múltiplos cores de CPU e máquinas, sem que você precise se preocupar em como implementar esse paralelismo [3]. Em um algoritmo codificado manualmente, implementar essa execução paralela por conta própria exigiria um esforço considerável.

Texto Traduzido (gemma 4 31b) (PAGO)

Texto traduzido por um LLM pequeno pago via openrouter

Terminologia: Declarative Query Languages

Muitas das linguagens de consulta discutidas neste capítulo (como SQL, Cypher, SPARQL e Datalog) são declarative, o que significa que você especifica o padrão dos dados desejados — quais condições os resultados devem atender e como você deseja que os dados sejam transformados (ex: sorted, grouped e aggregated) — mas não como atingir esse objetivo. O query optimizer do sistema de banco de dados pode decidir quais indexes e join algorithms utilizar e em qual ordem executar as diversas partes da query.

Em contraste, com a maioria das linguagens de programação (como Python e Java), você teria que escrever um algoritmo instruindo o computador sobre quais operações realizar e em qual ordem. Uma declarative query language é atraente porque geralmente é mais concisa e fácil de escrever do que um algoritmo explícito. Mais importante ainda, ela oculta os implementation details do query engine, o que permite que o sistema de banco de dados introduza melhorias de performance sem exigir qualquer alteração nas queries $[1, 2]$ .

Por exemplo, um banco de dados pode ser capaz de executar uma declarative query em paralelo entre múltiplos CPU cores e machines, sem que você precise se preocupar em como implementar esse parallelism $[3]$ . Em um handcoded algorithm, seria necessário um esforço considerável para implementar tal execução paralela por conta própria.

Texto Traduzido (Qwen 3.7 Max) (PAGO)

Texto traduzido por um LLM pago via openrouter

Terminologia: Linguagens de Query Declarativas

Muitas das linguagens de query discutidas neste capítulo (como SQL, Cypher, SPARQL e Datalog) são declarativas, o que significa que você especifica o padrão dos dados que deseja — quais condições os resultados devem atender e como você quer que os dados sejam transformados (por exemplo, ordenados, agrupados e agregados) —, mas não como alcançar esse objetivo. O query optimizer do sistema de banco de dados pode decidir quais índices e algoritmos de join usar e em que ordem executar as diversas partes da query.

Em contraste, na maioria das linguagens de programação (como Python e Java), você teria que escrever um algoritmo dizendo ao computador quais operações executar e em que ordem. Uma linguagem de query declarativa é atraente porque geralmente é mais concisa e mais fácil de escrever do que um algoritmo explícito. Mais importante ainda, ela oculta os detalhes de implementação da query engine, o que possibilita ao sistema de banco de dados introduzir melhorias de performance sem exigir nenhuma alteração nas queries [1, 2].

Por exemplo, um banco de dados pode conseguir executar uma query declarativa em paralelo em múltiplos CPU cores e máquinas, sem que você precise se preocupar em como implementar esse paralelismo [3]. Em um algoritmo codificado manualmente, seria muito trabalho implementar essa execução paralela por conta própria.

Texto Traduzido (gpt-oss-120b) GRATUITO

Texto traduzido por um LLM grauito via openrouter

Terminologia: Linguagens de Consulta Declarativas

Muitas das linguagens de consulta abordadas neste capítulo (como SQL, Cypher, SPARQL e Datalog) são declarativas, ou seja, você define o padrão dos dados que deseja — quais condições os resultados devem atender e como os dados devem ser transformados (por exemplo, ordenados, agrupados e agregados) — mas não como alcançar esse objetivo. O otimizador de consultas do sistema de banco de dados pode decidir quais indexes e algoritmos de join usar e em que ordem executar as diferentes partes da consulta.

Em contraste, na maioria das linguagens de programação (como Python e Java), seria necessário escrever um algoritmo que informe ao computador quais operações executar e em que sequência. Uma linguagem de consulta declarativa é atraente porque costuma ser mais concisa e mais fácil de escrever do que um algoritmo explícito. Mais importante ainda, ela oculta detalhes de implementação do motor de consulta, permitindo que o sistema de banco de dados introduza melhorias de desempenho sem exigir alterações nas consultas [1, 2].

Por exemplo, um banco de dados pode ser capaz de executar uma consulta declarativa em paralelo sobre múltiplos núcleos de CPU e máquinas, sem que você precise se preocupar em como implementar esse paralelismo [3]. Em um algoritmo escrito manualmente, seria muito esforço implementar essa execução paralela por conta própria.

Texto Traduzido (Owl Alpha) GRATUITO

Texto traduzido por um LLM grauito via openrouter (modelo de avaliacao)

Terminology: Declarative Query Languages

Muitas das linguagens de consulta discutidas neste capítulo (como SQL, Cypher, SPARQL e Datalog) são declarativas, o que significa que você especifica o padrão de dados que deseja — quais condições os resultados devem atender e como deseja que os dados sejam transformados (por exemplo, ordenados, agrupados e agregados) — mas não como atingir esse objetivo. O query optimizer do sistema de banco de dados pode decidir quais indexes e join algorithms usar e em qual ordem executar as diversas partes da consulta.

Em contraste, com a maioria das linguagens de programação (como Python e Java), você teria que escrever um algoritmo instruindo o computador sobre quais operações executar e em que ordem. Uma linguagem de consulta declarativa é atraente porque normalmente é mais concisa e mais fácil de escrever do que um algoritmo explícito. Mais importante ainda, ela oculta os detalhes de implementação do query engine, o que torna possível que o sistema de banco de dados introduza melhorias de desempenho sem exigir qualquer alteração nas consultas [1, 2].

Por exemplo, um banco de dados pode ser capaz de executar uma consulta declarativa em paralelo em múltiplos CPU cores e máquinas, sem que você precise se preocupar em como implementar esse paralelismo [3]. Em um algoritmo escrito à mão (handcoded), seria muito trabalho implementar essa execução paralela por conta própria.

Conclusao

Todos os LLMs testados retornaram traducoes uteis
Mesmo LLM pequenos e rodando localmente produziram uma boa traducao, MAS tem o problema da velocidade (tokens/s)
Modelos gratuitos tambem produziram boa traducao, MAS tem o problema de quotas e rate-limit
Modelos pagos comuns tambem produziram boa traducao, sem problemas de velocidade ou rate-limit
Nao ha necessidade do uso de modelos flagship (Claude, Gemini, chatGPT) para traducao - eh um gasto desproporcional e nao houve melhora significativa no texto produzido
O uso do proxy OmniRoute ajuda na construcao de "combos" juntando diversos providers e modelos de LLM, o que especialmente util em caso de quotas/limits
O BabelDOC mantem (dentro do razoavel) a estrutura do PDF original, o que eh util.
O modo "dual" produz o PDF com as duas traducoes, permitindo comparar lado-a-lado

Sobre o sistema RAG

Como comentei no inicio do post, os testes com o BabelDOC foram um efeito colateral positivo do novo livro que estou escrevendo, onde entrego um sistema RAG funcional e pronto para colocar em producao, alem de descrever passo-a-passo como o mesmo foi desenvolvido.

Saude e Sucesso !

Este post foi favoritado via extensão TABNEWS FAVORITOS

Tem curiosidade sobre IA ? Da uma olhada no meu LIVRO: IA PARA ENGENHEIROS