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

技術要約：失敗を考慮した長文翻訳（Failure-Aware Long-Form Translation）

問題提起
本論文は、長文機械翻訳システムにおける決定的なギャップ、すなわち「APIレベルの成功」と「アプリケーションレベルの成功」の区別について論じている。翻訳リクエストがプロバイダーから構文的に有効で空ではないストリームを返したとしても、その結果が使用不可能なものである場合がある。一般的な失敗モードには、出力が空である、途中で切れている、ソーステキストやプロンプトの漏洩が支配的である、あるいは一部の内容のみを生成して中断されるといったものがある。従来の「リクエスト失敗」という抽象化では、これらのニュアンスを捉えることができない。それらは、使用不可能なテキストや機密性の高い内部テキストをユーザーに露出させるか、あるいは高価な部分的な成果物を破棄してしまうかのいずれかである。長文においては、これらのエラーはコスト（フルリスタートによる増大）を増幅させ、アライメントのリスク（破損した接尾辞の盲目的な保持によるリスク）を導入する。

手法
著者は、ヘテロジニアスな入力（手動テキスト、URL、ファイル、PDF、OCR）および多様なプロバイダーAPIに対応した、リカバリ可能な翻訳システムを設計・実装した。コアとなる手法は、ガード付きストリーミング・アーキテクチャと境界付きリカバリ・プロトコルに基づいている。

1. ガード付きストリーミングと封じ込め（Guarded Streaming and Containment）:

   • リーディング・ウィンドウ・ガード（Leading-Window Guard）: テキストがユーザーに表示される前に、システムは最初の64文字をバッファリングする。このウィンドウの間、システムはプロンプトマーカーとソース言語の残存物をチェックする。失敗が検出された場合、リリースされる前に試行を中止する。
   • 状態の区別: システムは、テキストに対して3つの異なる状態を維持する：バッファリング済み（表示されない）、可視（リーディング・ガードを通過したが、フル出力チェックに失敗した場合に置換の対象となる）、およびコミット済み（すべてのチェックを通過し、記録された）。
   • 境界安全な保持（Boundary-Safe Retention）: ストリームがリリース後に中断された場合、システムは単にリスタートするのではない。代わりに、ソースと受信された出力から「境界安全な」プレフィックスを導出する。このプレフィックスは、ソースに構造的に整合させることができる完全な段落および文のような単位のみを保持し、未完成の断片は破棄する。

2. 運用失敗マトリクス（Operational Failure Matrix）:
   システムは、失敗条件（転送エラー、クォータ制限、ポリシーフィルター、空の出力、ソースの残存、および壊滅的な欠落）の行列を利用する。検出は、プロトコルチェックと実装固有のヒューリスティック（例：日本語および韓国語のための言語特有の残存物検出）を組み合わせて行う。

   • 欠落ガード（Omission Guard）: モデルが流暢な結末を返しつつ、ほとんどの入力段落を脱落させる「サイレントな欠落」を特に対象とする。これは、段落の保持率が0.70未満であり、かつ出力対ソースの文字比率が0.15未満の場合にのみトリガーされる。

3. ルーティングとフォールバック（Routing and Fallback）:

   • 安定したモデル順序: リカバリは、決定論的かつセッション固有のモデル順序に従う。無限ループを防ぐため、各モデルの試行は1つのチャンクにつき最大1回までとする。
   • 階層型フォールバック: LLMモデルプールが枯渇するか、共有デッドライン（ストリーミングおよびフォールバック層の特定のキャップを含む合計240秒）に達した場合、システムはフォールバックパスに入る。これには、互換性モデル、外部機械翻訳、および緊急機械翻訳パスが含まれる。
   • プロベナンス（Provenance）: すべてのフォールバックは、型付きのServer-Sent Events (SSE) とクライアントラベルでマークされ、機械翻訳（非LLM）が使用されているのかLLMの試行が行われているのかをユーザーが確実に把握できるようにする。

主な貢献
本論文は、主に3つの貢献を提示している：

1. ストリーミング・アーキテクチャ: アクティブなリカバリ中に、バッファリング、可視、境界安全、およびコミットされたテキストを区別する設計。
2. 運用失敗マトリクス: 検出の信頼性とアクションの安全性によって失敗を分類した、デプロイされた実装から導出された境界付きルーティング・ポリシー。
3. サニタイズされた実行可能アーティファクト: プロトコルを実装したプロバイダー中立のコンパニオン・アーティファクト。これは38の公開テストに合格しており、リリース、保持、試行、イベント、およびプロベナンスに関する固定ケースを含んでいる。

結果
評価は、翻訳の質や失敗の発生頻度ではなく、制御フローの決定を実行するシステムの能力に焦点を当てている。

• 固定ケース・テスト: アーティファクトは、構成された全14種類の完了ラベルを正常に再現した。
• 封じ込め: 4つの初期無効プレフィックスのケースにおいて、リーディング・ウィンドウにより、235文字の無効なコンテンツが可視化されるのを防いだ。
• リカバリ: 4つの中断されたストリーム・シナリオにおいて、境界安全メカニズムにより、フルリスタートでは破棄されていた31文字が保持され、同時にソースへの正しい整列が行われた。
• プロトコル遵守: 2つのエンドツーエンドのシナリオにより、試行回数の上限、レジューム・イベント、またはプロベナンス・ルールの違反がゼロであることが確認された。
• 結果の限界: 著者は、これらが公開された制御フローの実行可能なチェックであることを明示している。本研究は、自然に発生する出力に対する検出器のリコール、偽陽性率、または翻訳の質を推定するものではない。

意義と主張
本論文は、長文翻訳において「テキストを生成することは、それをコミットすることと同じではない」と主張している。その意義は、リリース、リカバリ、およびフォールバックを、モノリスな成功/失敗のバイナリではなく、個別の、観察可能な決定として扱うことにある。

• 運用の安全性: システムは、翻訳の起源がサイレントに変更されることなく、リカバリが可視化されること（型付きイベントを介して）を保証する。
• コストとレイテンシの管理: 境界安全なプレフィックスを保持することで、システムはドキュメントのフルリスタートに伴うレイテンシとコストを回避しつつ、部分的な破損の永続化を防ぐ。
• 限定的な範囲: 著者は、本研究が翻訳の質を最適化することを主張しているのではなく、またルーティング順序の最適性を評価するものでもないことを明示している。本研究は、長文のコンテキストにおける「成功したAPIレスポンスの失敗」を扱うための、構造的かつ運用的な貢献である。評価は、出力の意味的な質ではなく、リカバリ・プロトコルのロジックに限定されている。