Failure-Aware Long-Form Translation: Design and Implementation of a Recoverable LLM Translation System

Resumo Técnico: Tradução de Longo Formato com Consciência de Falhas

Declaração do Problema
O artigo aborda uma lacuna crítica nos sistemas de tradução automática de longo formato: a distinção entre o sucesso ao nível da API e o sucesso ao nível da aplicação. Uma requisição de tradução pode retornar um fluxo sintaticamente válido e não vazio de um provedor, mas produzir um resultado inutilizável. Os modos de falha comuns incluem saídas que são vazias, truncadas, dominadas pelo texto de origem ou vazamento de prompt (prompt leakage), ou interrompidas após gerar apenas conteúdo parcial. As abstrações convencionais de "requisição falha" não conseguem capturar essas nuances; elas ou expõem texto interno sensível ou inutilizável ao usuário, ou descartam trabalho parcialmente válido e caro. Em documentos longos, esses erros amplificam custos (via reinicializações completas) e introduzem riscos de alinhamento (via retenção cega de sufixos corrompidos).

Metodologia
O autor projetou e implementou um sistema de tradução recuperável para entradas heterogêneas (texto manual, URLs, arquivos, PDFs, OCR) e diversas APIs de provedores. A metodologia central baseia-se em uma arquitetura de streaming guardada e um protocolo de recuperação limitado.

1. Streaming Guardado e Contenção:

   • Guarda de Janela de Cabeçalho (Leading-Window Guard): Antes que qualquer texto seja visível para o usuário, o sistema faz o buffer dos primeiros 64 caracteres. Durante esta janela, ele verifica marcadores de prompt e resíduos da língua de origem. Se uma falha for detectada, a tentativa é abortada antes da liberação.
   • Distinção de Estado: O sistema mantém três estados distintos para o texto: Bufferizado (não visível), Visível (passou pela guarda de cabeçalho, mas sujeito a substituição se as verificações de saída completa falharem) e Comprometido (passou por todas as verificações e foi registrado).
   • Retenção Segura de Fronteira (Boundary-Safe Retention): Se um fluxo for interrompido após a liberação, o sistema não simplesmente reinicia. Em vez disso, ele deriva um prefixo "seguro de fronteira" a partir da origem e da saída recebida. Este prefixo retém apenas parágrafos completos e unidades do tipo sentenças que podem ser estruturalmente alinhadas à origem, descartando fragmentos inacabados.

2. Matriz de Falhas Operacionais:
   O sistema utiliza uma matriz de condições de falha (erros de transporte, limites de cota, filtros de política, saídas vazias, resíduo de origem e omissões catastróficas). A detecção combina verificações de protocolo com heurísticas específicas de implementação (ex: detecção de resíduo de idioma específico para japonês e coreano).

   • Guarda de Omissão: Visa especificamente "omissões silenciosas", onde um modelo retorna um final fluente enquanto descarta a maioria dos parágrafos de entrada. Isso é acionado apenas quando a retenção de parágrafos está abaixo de 0,70 e a razão caractere-saída/origem está abaixo de 0,15.

3. Roteamento e Fallback:

   • Ordem de Modelo Estável: A recuperação segue uma ordem determinística e específica da sessão de modelos. Cada modelo é tentado no máximo uma vez por bloco para evitar loops infinitos.
   • Fallback em Camadas: Uma vez que o pool de modelos LLM se esgota ou um prazo compartilhado (240 segundos no total, com limites específicos para camadas de streaming e fallback) é atingido, o sistema entra em um caminho de fallback. Isso inclui modelos de compatibilidade, tradução automática externa e um caminho de tradução automática de emergência.
   • Proveniência: Todos os fallbacks são marcados com Eventos de Servidor Enviados (Server-Sent Events - SSE) tipados e rótulos de cliente, garantindo que o usuário saiba quando uma tradução automática (não-LLM) é usada versus uma tentativa de LLM.

Principais Contribuições
O artigo apresenta três contribuições primárias:

1. Arquitetura de Streaming: Um design que distingue entre texto bufferizado, visível, seguro de fronteira e comprometido durante a recuperação ativa.
2. Matriz de Falhas Operacionais: Uma política de roteamento limitada derivada de uma implementação implantada, categorizando falhas por confiança de detecção e segurança de ação.
3. Artefato Executável Sanitizado: Um artefato companheiro agnóstico de provedor que implementa o protocolo, passando por 38 testes públicos e incluindo casos fixos para liberação, retenção, tentativas, eventos e proveniência.

Resultados
A avaliação foca na capacidade do sistema de executar decisões de fluxo de controle, em vez da qualidade da tradução ou prevalência de falhas.

• Testes de Caso Fixo: O artefato reproduziu com sucesso todos os 14 rótulos de conclusão configurados.
• Contenção: Em quatro casos de prefixo inválido precoce, a janela de cabeçalho impediu que 235 caracteres de conteúdo inválido se tornassem visíveis.
• Recuperação: Em quatro cenários de fluxo interrompido, o mecanismo de fronteira segura reteve 31 caracteres que uma reinicialização completa teria descartado, enquanto os alinhou corretamente à origem.
• Conformidade de Protocolo: Dois cenários de ponta a ponta confirmaram zero violações de limites de tentativa, eventos de retomada ou regras de proveniência.
• Limitações dos Resultados: O autor afirma explicitamente que estes são testes executáveis do fluxo de controle publicado. O estudo não estima o recall do detector, taxas de falsos positivos ou a qualidade da tradução em saídas naturais.

Significância e Alegações
O artigo alega que, para tradução de longo formato, "gerar texto não pode ser o mesmo que comprometê-lo". Sua significância reside em tratar a liberação, a recuperação e o fallback como decisões separadas e observáveis, em vez de um binário monolítico de sucesso/falha.

• Segurança Operacional: O sistema garante que a recuperação permaneça visível (via eventos tipados) em vez de alterar silenciosamente a origem de uma tradução.
• Gestão de Custo e Latência: Ao reter prefixos seguros de fronteira, o sistema evita a latência e o custo de reinicializações completas de documentos, ao mesmo tempo em que evita a persistência de corrupção parcial.
• Escopo Modesto: O autor é explícito ao afirmar que o estudo não pretende otimizar a qualidade da tradução, nem avaliar a otimalidade da ordem de roteamento. O trabalho é uma contribuição estrutural e operacional para lidar com a "falha" de respostas de API bem-sucedidas em contextos de longo formato. A avaliação limita-se à lógica do protocolo de recuperação, não à qualidade semântica da saída.