TL;DR： loop engineeringシリーズ第2回。前回は委任の階段の公式構造を扱った。今回は自分が作った翻訳品質システムTQEFを例に、二つのものが持つ異なる寿命を説明する。harness、つまりものを動かす仕組みは絶えず置き換えられる。criteria、つまり成果が合格かどうかを判断する基準は何度作り直しても積み上がっていく。実際に踏んだいくつかの失敗と、このシステムがまだ完成していない部分を正直に話す。

前回の記事の最後の一文に、一つの借りを残した。「この数か月、自分がどうやって同じ構造にぶつかり続け、どんな失敗を踏んだかは、次の記事で詳しく話す」と。今回はその借りを返す。

結論を先に言い、どうやってたどり着いたかを後で話す。

継続的に動くAIシステムの中に、すぐ消耗するものがある。prompt、ツール、データベース、スケジューラ。システムを動かすこれらの仕組みを、まとめてharnessと呼ぶ。一度の事故、一度のアップグレード、あるいはアーキテクチャの見直し、それだけで作り直しを強いられる。

出力の良し悪しを判断する基準は違う。この層をcriteriaと呼ぶ。定義が十分に具体的であれば、何度作り直しても生き残る。そして失敗のたびに、より完全に近づいていく。

自分が作ったシステムの構造

TQEFは自分が作った翻訳品質評価フレームワークで、正式名称はTranslation Quality Evaluation Framework。対象はアゴラ広場、自分が開発したリアルタイム会議翻訳ツールだ。

このシステムは4層のループで構成されている。

最も内側の層が翻訳を担う。モデルが4系統の音声認識結果を受け取り、段落ごとに訳文を生成する。2層目が検査を担う。TQEFが5つの次元でスコアを出し、合格しなければ問題を差し戻して翻訳をやり直す。3層目は会議単位で動く。会議が終わると訳文がコーパスに入り、後続の改善の材料になる。最外層は複数サイクルの結果を定期的に確認し、繰り返し現れる問題を見つけ出し、promptと辞書にフィードバックする。

アゴラの4層ループ構造：エージェントループ、検証ループ、イベント駆動ループ、hill-climbingループが入れ子になって動いている

TQEFは5つの次元で評価する。

1つ目は術語の正確さで、最も重みが大きい。「半導体」が別の言葉に訳されてしまえば、ほかの文がどれだけ流暢でも意味がないからだ。2つ目は忠実度、訳文が原意からずれていないか。3つ目は重要情報の保持、数字や固有名詞が抜けたり誤訳されたりしていないか。4つ目は自然さ、訳文が人間の言葉として読めるか。最後が重大エラーで、一度でも出ると即不合格だ。

この5つの次元がcriteria層にあたる。前述の翻訳・検査・イベント駆動という具体的な運用はすべてharness層だ。次に話す失敗はすべてharness層で起きた。

harnessはどう消耗したか：実際に踏んだ3つの失敗

最初の失敗が最もドラマチックだった。協働セッションの中でosascriptを使ってファイルに書き込む際、クォートのネストが崩れた。226行のコアスクリプトeval_runner.pyが1行（#!/usr/bin/env python3）だけになって、スクリプト全体が壊れた。「書き直せばいい」という小さな話ではなく、システム的な警告だった。戦略・コーディング・デプロイを同一のセッションで同時に担えば、どこかで事故が起きるのは時間の問題だ。今回たまたまクォートのネストがその引き金になった。その後、協働フローを3軌道に分けた。偵察と戦略専用でコードに触らない軌道、バッチのファイル操作専用の軌道、精密な単ファイル修正とデプロイ専用の軌道。3軌道が同じファイルを同時に触らないルールにし、各フェーズの終わりには変更が保存・コミットされ、ロールバックできるバージョンが残っていることを確認する。この分業は事故が引き出したものであって、最初から設計したわけではない。振り返れば、開発全体を通じて最もリターンの高い意思決定だった。以来、同種のバージョン混乱は一度も起きていない。

2つ目の失敗は静かだった。システムを拡張する際、ドキュメントを参照してデータベースのフィールド名を推測した。実際にクエリを実行したら、データ構造がドキュメントの記述と違っていた。似た状況が2度あったが、どちらも事前確認の段階で食い止め、実際の損害には至らなかった。以来、データベースのフィールドは実際のクエリ結果を唯一の根拠とし、ドキュメントや記憶で推測しないことを鉄則にした。

3つ目は評価スコアの重複登録だ。同じサイクル・同じ文の評価結果がデータベースに2回書き込まれた。最初にUNIQUE constraintを設定していなかったことが原因だ。修正は単純で、constraintを追加して重複データを削除した。

もう一つ、ドラマチックではないが繰り返し現れたパターンがある。「書けたけどつながっていなかった」だ。機能は書き終えたように見えるが、importが抜けていたり、ルーティングが接続されていなかったり、デプロイが走っていなかったり、フロントエンドがまったくレンダリングしていなかったりする。各部品は存在するかもしれないが、全体のフローが一度も実際に通っていない。この教訓から一つの習慣ができた。どんな改変の後も、必ずエンドツーエンドで一度通して確認する。「動いているはずだ」という想定に頼らず、本当に生きているかを自分の目で確かめる。

criteriaはどう複利になったか：原因を明確に語れる一度の改善

前述の失敗と最も対照的なサイクルは、辞書を導入した日に起きた。ベースラインのスコアは4.69（満点5）で、重大エラーが1つあった。そのサイクルで半導体・サーキュラーエコノミー・再生医療・一般ビジネス用語をカバーする3つの産業辞書と1セットのビジネス用語ルールを同時に導入した。次のサイクルの結果、全体スコアが4.97に跳ね上がり、重大エラーがゼロになった。

この向上は辞書の導入に明確にたどれる。スコアの改善が具体的なエンジニアリング改変に対応している。主観的な感覚ではなく、証明できる因果関係だ。これがcriteria層の価値だ。harnessが何度作り直されても、複数のサイクルの結果を同じ基準で比較できる。コアスクリプトがosascriptに吹き飛ばされようと、データベースのフィールド名を実際に確認しようと、重複登録バグがあろうと、5つの評価次元は細部を補い続けてきたが、最初のサイクルから今まで、コアの判断ロジックは変わっていない。どのエンジニアリング改変の効果も、同じ物差しの上で積み上げて比較できる。その物差しは、いかなるharnessの再構築にも壊されなかった。これが複利の意味だ。

その後のサイクルでスコアは4.78から4.90の間で揺れている。これは正常な変動だ。29文というサンプルは小さく、評価モデル自体にもランダム性がある。しかし全体の傾向は上向きで、各サイクルで加えたエンジニアリング改変とその影響を振り返って照合できる。これは前回の記事で触れた原則と呼応する。ループは生成と評価を分離することを助けてくれるが、「一文の翻訳がどうなれば合格か」は、自分が先に言語化し、採点できるレベルまで具体化しておく必要がある。これは完全にモデルに外注できない。

まだ完成していない部分を正直に話す

TQEFで今できているのはPhase 1、単一の評価エンジン、29文のテストコーパス、7サイクルの評価だ。Phase 2は5つの言語データ自動収集チャンネルを設計しているが、現在2つしか完成していない。残りはまだ計画段階だ。さらにStage Bと呼んでいるフェーズを別途計画していて、評価器自体の信頼性を検証するものだ。評価promptを調整するだけでなく、別の指標で交差比較し、人間の専門家によるスコアでキャリブレーションし、同じデータを繰り返しテストして結果が安定しているかを確認する。このフェーズは今も本格的に進んでいない。他の優先順位に押されている。正直に残しておく一つの未完成で、口先だけではない。

この部分は省けない。criteriaはharnessより長持ちして投資する価値があると主張するなら、criteriaもまた一度書いて完成するものではないことを言わなければならない。交差比較、人間によるキャリブレーション、安定性テストが必要だ。違いは、これらの作業が通常は同じ物差しを修正することであって、判断の仕組み全体を毎回交換することではない、という点だ。その検証を、自分自身もまだ終えていない。

この2本の記事で言いたかったこと

前回の記事でloop engineeringの公式構造を説明したあと、一言残した。「loop engineeringは『フローをどう動かすか』を自動化できるが、『どうなれば正しく動いたか』をあなたの代わりに決めることはできない」と。今回は自分が踏んだ失敗を使って、その言葉を地に着かせた。harness層は吹き飛ばし、修正し、再構築した。3軌道の分業はあの事故が引き出したものだ。criteria層は最初の日に定義して以来、すべての再構築を生き抜き、失敗のたびに補われて完全に近づいている。

TQEFのようなシステムを持っていなくても、この対比は使える。継続的に動くあらゆるAIシステムにおいて、動かす仕組みはいつか作り直しを強いられる。これはほぼ必然だ。本当に先に力を注ぐべきは「どうなれば完了か」を考えることだ。基準を十分に具体的に書く。異なる人やモデルがそれを使って成果の合否を判断できるくらいに。これをモデルに完全に外注することは難しい。しかし一度基準を確立すれば、それはどのバージョンのpromptやツールやワークフローよりも長く生き残る。

参考資料

同シリーズの前回記事

  • 迴圈工程到底在教你委派什麼：loop engineeringシリーズ第1回。公式の委任の階段の構造、それが解決する3つの問題、Anthropic自身の実測データとの照合を扱っている。

TQEF関連素材

  • 本記事のすべての評価データ、事故記録、開発経緯はPaulが自ら構築したシステムの一次記録であり、第三者レポートの転載ではない。