AI処理の実用化を目指す上では様々なAIのミスを見つけながら改善していく。

様々な出力や参照の間違いは異なる原因から生じていることが多い。。

原因が違えば、当然ながら必要な対策も違う。

良いDXエンジニア、良いFDEはうまく行っていない処理や要素を一色単に扱わない。

• 誤っている原因の分類や仮説の幅広さ
• 処理やデータからの憶測する力
• 原因がわかった上で、どのように現在の実装を変えるべきかの判断

これらがそのスコープを実用化へ導けるPDCAを回す力である。

この記事のキーメッセージ

**AIの実用化は、誤りを正しい層に分類し、

処理・検査・役割分担を分けて設計を見直し続ける必要がある。**

処理の失敗の見つめ方

1.それは本当にハルシネーション？

ハルシネーションとは、本来、入力や参照情報に存在しない内容を、あたかも事実であるかのように生成することである。

前処理で情報が欠落しているなら、どれだけプロンプトを改善しても解決しない。

参照すべき業務ルールを渡していないなら、モデルの性能を上げても正しい変換はできない。

形式の正規化に失敗しているだけなら、そもそも生成AIではなく、通常のプログラムで処理すべきかもしれない。

これを全部ハルシネーションとして扱うと、「プロンプトを強くする」「モデルを変える」という間違った改善に流れます。

2. 一度直ったように見えても、直ったとは限らない

同じ処理を再実行して成功しても、

• 改善によって直ったのか
• 何も直していないが、今回は偶然成功したのか

を区別できません。

したがって、問題の性質を分類せずに改善前後を一回ずつ比較すると、放置した問題を解決済みと誤認する可能性があります。

必要なのは単発の成功確認ではなく、

• 同一条件での反復
• 既存ケースの回帰テスト
• エラー種別ごとの再発率
• 中間処理の比較

です。

実装内容への疑い方

1.見つかった失敗を、1つの処理フローに継ぎ足し続けていないか？

改善を繰り返す中で、処理が継ぎ足されていくことを踏まえられる実装者は強い。

何か原因がわかった場合も、

1. 基本パイプライン自体を変更する
2. 基本パイプラインの各処理を厳密化する
3. 基本処理とは別に、正確性検査に特化した二周目のパイプラインを作る

どういう反映がいいのかは場合による。

重要なのは、目の前の誤りを直すために正常系を複雑化すると、別の場所が悪化したり、分岐が爆発したりするという話です。

2.前処理、出力処理、検査処理を分離していこう。

今作っているものは「本処理」ではなく前処理かもしれない

• 今作っているのは機械的な処理をしていくための前処理として扱うべきで、本当の出力生成や精査や検査のフローがまだ存在していない場合が多い。
• それはプロトタイプの中でも、実用性の検証にはまだ向かっていない段階である。

また、出力や前処理の正確性をセルフチェックするような処理については、検査処理として分離や独立をさせられれば、新しい失敗パターンが見つかったときにも、基本処理を毎回作り替える必要がない。

• まずは検査側へ新しい観点を追加し、問題の発生頻度や影響を確認する。
• そのうえで、基本処理から直さなければ成立しないものだけを、一周目へ戻して厳密化する。

この構造にすると、正常系を必要以上に複雑化させずに、実運用で必要な正確性を高められる。

また、作っている内容が機械的な処理をしていくための前処理として扱うべきで、本当の出力生成や精査や検査のフローがまだ存在していない場合が多い。

• それはプロトタイプの中でも、実用性の検証にはまだ向かっていない段階である。

まとめ

良いDXエンジニア、良いFDEは、

• 失敗している処理を見つめ、失敗を正しく分類・分解することに徹している。
• 先々の処理の膨らみを見据え、把握でき育てられることを踏まえて処理ラインを構造を保った状態で育てている。