AIコーディング：翻訳機のループエンジニアリング

約1〜2週間前、「プロンプトエンジニアリング」や「エージェンティックワークフロー」だけでは不十分になり、新たな抽象化として「ループエンジニアリング」という用語が浮上してきた。著者は2024年12月、ローカルのRTX 3060（12GB VRAM）上で韓国語の大規模文書を英語に翻訳するため、初めてLLMを利用した。当時ChatGPTのコンテキストウィンドウは小さすぎ、翻訳が10%で停止したため、文書を自動分割する方法を考案した。エージェントについて無知だった著者は、独自のアーキテクチャを考案した。生の韓国語書き起こしを「計画→実行→批評→修復」のループで英語に変換するパイプラインである。NLLBによる逐語訳を公平な参照とし、翻訳メモリで用語の一貫性を保つ。コンポーネントは、KSSによる文分割、TextChunkerによるチャンク分割、qwen3:14bプランナー、aya:8b実行機、qwen3:14b批評機、facebook/nllb-200-distilled-600M参照モデル、Python辞書による翻訳メモリ、オプションのフォーマッター、出力ライターからなる。プランナーは入力の一部を読み、JSON形式のグローバル戦略（コンテンツタイプ、話し方スタイル、用語、コンポーネントごとの指示）を生成する。実行機は各チャンクを翻訳し、批評機からの修正指示に基づき修復を実行する。批評機はソース、実行機出力、NLLB参照の3方向比較により翻訳を検証し、ステータス、問題、修正指示、抽出された用語/スタイルを返す。NLLBは逐語的な参照翻訳を提供し、批評機のみが参照可能で、実行機の幻覚を防止する。翻訳メモリは用語とスタイルを蓄積し、実行機が文脈として読み、批評機が抽出したものを書き込む。著者は教育用YouTubeビデオの文字起こし翻訳という実需要から数週間取り組んだ。単純なループから始めたが、ローカルモデルの品質が低かったため批評機を導入し、そのフィードバックをプロンプトに反映させた。その後、用語の翻訳が文書全体で異なる「ドリフト」が発生したため、メモリを追加。チャンクのオーバーラップウィンドウなど多くの小最適化も行った。しかし結局、批評機とメモリは翻訳品質向上に寄与せず、批評機が不十分と判定してループが続き、実行機は批評機を満足させる翻訳ができなかった。微調整で品質を有意に改善できず、数週間後に断念。より良いローカル翻訳モデルを待つことにしたが、その頃にはこのループ工学自体が不要になっているかもしれない。