PVL AI
メニューを開く

PVL.AI Tech Blog

二つのAIが正反対の答えを出し、同じ誤りを犯した——なぜ現地語意基準こそがAI時代の堀なのか

実測:同一モデル・同一パイプラインでも、用語ベースの整備前後で誤り率は一桁違った。基準を欠いた状態では、異なるモデルファミリーが同種の誤りを犯す。AIの生産性の上限はモデル性能ではなく、基準のカバレッジである。

BenChen

二つのAIが正反対の答えを出し、同じ誤りを犯した

ごく小さな事故から

私は退屈な作業をしていた。すでに公開した中国語の調査記事を、日本語版に翻訳する作業である。

工程はこう設計されている。中国語の原文を唯一の事実の source とし、英語版を第二の観測点とする。日本語版はその二つから導出する。翻訳後には機械的検査——タグ数、数値の保持、リンクの整合——を実行し、さらに別のAIが独立レビューを行い、意味のずれがないことを確認する。

二十五本を通した。二十四本が合格。合格率九十六パーセントである。

この数字が私を落ち着かなくさせた。低すぎるからではない。高すぎるからである。

そこで私はあることをした。別のモデルファミリーのAIに、すでに「合格」と記録された訳文を再レビューさせたのである。

そのAIは問題を見つけた。私のブランド署名は中国語で四文字だが、日本語版では三文字になっていた。一文字足りない。しかも散発的ではなく、二十五本中十四本が三文字であった。

体系的な文字欠落に見える。第二のAIはこれを誤りと判定した。

ところが第二のAIも間違っていた

ブランド用語ベースを確認した。三文字の形こそが承認済みの日本語ローカライズであり、私自身が数日前に決裁したものであった。中国語の畳語は日本語の語感では自然でないため、公式の日本語表記は三文字なのである。

つまり——

  • 四文字を用いた第一バッチが誤り
  • 三文字を用いた第二バッチが正しい
  • そして誤りを見つけるために呼んだAIは、正しいものを誤りと判定した。しかも方向が正反対である

興味深いのは時系列である。用語ベースの承認は、第一バッチと第二バッチのあいだに行われていた。第二バッチが正しかったのは、モデルが賢くなったからではない。基準が整ったからである。

二つの失敗は、同じ形をしている

起きたことの構造を見てほしい。

第一のAIは、ある記事について「英語版と相互照合し、一致」と報告した。しかしその記事の英語版は完成しておらず、本文の半分近くがまだ中国語であった。実際には照合していないにもかかわらず、「合格」と報告したのである。

第二のAIはブランド名を誤りと判定した。しかし用語ベースを一度も参照していない。中国語の四文字が日本語で三文字になったのを見て、文字が欠けたように感じただけである。基準を持たないまま、「誤り」と報告した。

一方は合格、一方は誤り。答えは正反対である。しかし失敗の形は完全に同じである。

照合すべき基準を持たないまま、確定的な判断を下した。

これはモデルの能力の問題ではない。異なるファミリー、異なる訓練データ、異なるベンダーの二つのモデルが、同種の誤りを犯した。より強いモデルでは解決しない。欠けているのは推論能力ではなく、手元にある照合対象だからである。

モデルの更新より効く、一つの規則

私はこれを一文に収斂させ、すべてのレビュー指示に書き込んだ。

基準がないとき、正しい出力は「検証不能」であって、「合格」ではない。

単純に聞こえるが、これはシステムの性質を変える。

もとの設計では、レビュアーの出口は二つしかなかった。合格か、差し戻しか。この設計には隠れた前提がある——レビュアーは常に判断できるという前提である。しかし現実にはしばしば判断できない。用語ベースが接続されていなければブランド訳語は判断できず、第二言語版そのものが壊れていれば相互照合はできない。

選択肢が合格か差し戻しかの二つしかないとき、基準を持たないレビュアーは合格に傾く。具体的な誤りを指摘できないからである。誤りが見つからないことは誤りがないことと同義ではないが、出力形式が二者択一を強いる。

第三の出口 `unverifiable`(検証不能)を加えると、全体が正直になる。さらに、その記録は基準がどこに欠けているかをそのまま示す。それが作業リストになるのである。

より重要な帰結:上限はモデルにない

以上が成り立つなら、より重要な結論が導かれる。

AIでどこまでできるかは、基準がどこまで届いているかで決まる。

数字は明確である。同じモデル、同じ工程、同じ人間で——

  • 用語ベース整備前:五本中四本にブランド用語の問題
  • 整備後:二十本中三本、しかもうち二本は訳語の誤りではなく内部の不統一

差はモデルではない。基準が存在するか否かである。

これを一般化すると、AI導入をめぐる通常の議論とはかなり違う絵になる。多くの議論はモデル選定、プロンプト設計、エージェント構成についてのものである。だがこれらはいずれも複製可能である。モデルは安く強くなり、プロンプトの技法は拡散し、工程は一週間で再構築できる。

産出品質の上限を実際に決めているのは、誰もやりたがらないもの——検証を経て、継続的に蓄積される現地語意基準である。

では堀はどこにあるのか

三つは商品化し、一つは商品化しない。

資産

三年後

モデル

商品化し、より安くより強くなる

工程とツールチェーン

複製可能、一週間で再構築

コンテンツ

収集され、要約され、書き換えられる

現地語意基準

時間 × 実使用でしか蓄積されない

決定的なのは、その構築方法が複製できないという点である。

良い語意基準は辞書から書き写したものではない。実際のレビュー判断から育つ——ある語が何度修正されたか、なぜ修正されたか、最終的にどう決着し、その根拠は何だったか。これは運用データである。収集できず、購入できず、より大きなモデルで生成することもできない。

そしてあまり語られない性質がある。それは複利で効く唯一の資産である。一バッチ翻訳するごとに基準は精確になり、次のバッチの命中率は上がり、差し戻しは減る。節約されたレビュー工数が、さらに多くを処理する余力になる。

堀がない部分について、正直に

実際より美しく語りたくないので、優位が存在しない箇所を明確にしておく。

一般用語に堀はない。「フリーキャッシュフロー」が日本語でどう表記されるかには業界標準があり、当局や取引所が対照を公開している。この層は誰でも入手できる。

実際に価値があるのは三つの層である。

  1. 自分で定義した概念 — 方法論の名称、フレームワーク名、独自の分析用語。世界に二つとない
  2. 対応づけの判断 — 台湾市場の俗語を日本語にどう訳すか。標準解答はないが、その判断の蓄積が文体資産になる
  3. 蓄積された修正の証跡 — どの訳語が変更され、その理由は何か。実際に量を通さなければ得られないため、最も複製が難しい

三つ目が特に重要である。それが基準を「対照表」から「学習するシステム」へと変える。

二種類のナレッジベース、時間効果は正反対

自分のプロジェクトで、二種類のナレッジベースが並存していることに気づいた。両者は異なる生物種である。

収集型

統治型

データ源

自動収集、一括取込

人手による承認+レビュー回帰

時間効果

古びるほど汚れる

古びるほど精確になる

廃止機構

通常なし

廃止を記録し、履歴を残し、後継を指す

信頼度

なし

修正回数とともに蓄積

収集型は構築が容易である。クローラを走らせ、APIをつなげば、一週間で数万件になる。だが統治層がなければ、どの項目が古いのか、どれが雑音なのか、どれをAIが書き換えてはならないのかを誰も知らない。二年後には誰も使う勇気のないデータの墓場になる。

統治型ははるかに難しい。必要なのは——

  • AIが自ら決定してはならない語の指定
  • 信頼度。新規項目は低い値から始める
  • 修正は十分な証跡が蓄積されてから反映する。単発の主観的判断が全体の標準になることを防ぐ
  • 旧訳は削除せず、廃止として記録し、後継を指す

これらの機構に技術的な難しさはない。難しいのは、見返りがまだ見えない段階で先に作ることを選べるかである。

AIを導入している人への三つの問い

AIを実際の業務に組み込んでいるなら、この三つを問う価値があるかもしれない。

一、あなたのAIは、基準がないとき「わからない」と言うか。 出力形式が合格/不合格の二択なら、わからないと言うべきときに必ず合格と言う。

二、あなたのナレッジベースは、時間とともに精確になるか、汚れるか。 廃止機構と信頼度を欠いたナレッジベースでは、規模の成長は雑音の成長である。

三、工程を丸ごと複製されたら、何が残るか。 答えが「何も残らない」なら、蓄積してきたのは生産量であって、資産ではない。


結び

この一件で、私はある判断を改めた。

もともと私は用語ベースを品質の加点項目と見ていた。あればより良いが、なくても回る、と。今回の異種レビュー対照試験を経て確信したのは逆である。それはレビュー機構が成立するための前提条件である。それがなければ、どのモデルを使い、エージェントを何層重ね、どれほど長いプロンプトを書いても、受け取る「合格」は「誤りが見つからなかった」の言い換えにすぎない。

AI時代に本当に希少なのは、生成する能力ではない。検証できる基準である。

そして基準は生成できない。蓄積するしかない。


本稿で述べた方法と結論は、実際のプロジェクトにおける内部検証に基づくものであり、いかなるツールやサービスの推奨を構成するものではない。