最近こんなのばっかりですが、以前AIに機能を捏造されていた記事を書きましたが、今回はデータの捏造です。しかも完全にデタラメの値ではなく、取り込んだ値を使って何か勝手なロジックにより勝手な値を算出するというもので、それによってパッと見の傾向がなんとなく正しそうに見えて、気づくのに遅れました。コイツほんとにそれらしさを作る天才だな。
よくもぼくをォ!!だましたなァ!!
対象アプリケーションは、私がダイエット日誌のために作り始めたHealth Dashboardという自作Webアプリです。体重などは私が元々つけていたスプレッドシートを読み込ませ、また手動による入力をしていました。これは問題ありませんでした。
問題が生じたのは、Fitbitのデータを、APIとGoogleからのエクスポートしたCSVで過去分のデータを取り込もうとした時です。特に歩数および睡眠時間のデータを取り込もうと考えました。これは指示するとなんとなくそれらしいものが出来たように見えました。
嘘でした。確認できただけで、以下のような複数の問題がありました。
- 睡眠スコアを勝手に独自のアルゴリズムで捏造する
- 睡眠時間の解釈が独特
- 時計をしなかった時などのデータゼロを勝手な値で補完する
- データ取り込み経路のみ、JSTとUTCで混ざっている(API経由のときは問題ない)
これらはけっこう厄介で、パッと見はけっこうそれっぽいんです。睡眠スコアは一応睡眠時間にもとづきます。睡眠時間の解釈は独特ですが一貫しているため傾向はあっています。ゼロデータの時はレアだしいつ歯抜けがあるべきかなんて覚えちゃいませんので、そこをそれらしく補完されているとどうにもなりません。また過去の値はCSV取り込みだが最新値はAPIなど経路が異なっており、かつCSV取り込みのみで起きる不具合(フォーマッタの不具合)についても、これも最新値はそれっぽいので騙されやすい。
やめて…森の中に木を隠すのやめて…
破綻に気づいたのは直近の睡眠スコアの捏造というホームラン級のファウルがあったからですね。直近の値はさすがに確認するでしょう。で、明らかに数値が異なるので、これは気づきました。そしてその原因調査の過程で、過去データなども直接参照・比較するなどして、芋づる式におかしさに気づいた、という感じです。こっちが指摘するまでAI言わないこと多いですよ本当に。でも全然言わないわけでもないんです。だから余計に気づきづらい。木を隠すなら森の中メソッドやめろ。
ついでに調べている中で、データベース設計自体が正規化されていないクソ設計であることも発覚しました。これも「なんで正規化されてないのか」と言って「おっしゃるとおりです!正規化しますか?」と返され確かな殺意を感じました。
この部分の直接的な原因は、元々の体重入力データと、あとからきたFitbit経由の歩数・睡眠時間データの考え方をあわせる調整が必要だったから、という感じでしたかね。実際、再設計にあたって固定カラムにするかEAVにするか…ということはちょっと考えさせられました。まぁAIの「固定カラムのテーブルいっぱい作ってアプリケーションでなんか適当に帳尻あわせってそれっぽくするぞ💪」は許されませんが…設計悩むところは聞いてくれ…。
実はちょっと大丈夫かなぁと思ってはいたんですけどね。以前DB設計は見るべきとか言ってましたがめんどくさくなってた🥺
こんな感じでパンドラの箱でも開けたのかというほど悍ましい何かが次々と飛び出てきたので、対応はだいぶ時間がかかりました。内部設計の抜本的な変更、さらにその確認、その適用に、3日くらいわけでやったと思います。疲れました。仕事かよ。まぁ仕事だったら許されんエラーなのですが…。
そんな過去は嘘である
しかし思ったことは、恐らく仕事でも同じことになっている現場、けっこうあるんじゃないですかね。特にエンジニアのいない、少ない現場だと本当にありそう。しかもこれ、時限爆弾ですからね。
このAIによるデータ捏造問題はけっこう深刻ですよ。ロジックは修正できますが、データの修正は必ずしもできません。たとえばデータにする過程で、計算した結果を正規データとして保存し計算元を破棄するようなものだと、あとで嘘だったとわかったときにもはや再現不可能です。
理想的にはデータの入力元はすべて残せ!となりますが膨大なデータになる可能性もあり、その負荷は必ずしも現実的ではありませんし、場合によっては物理的に不可能です。またデータの取得プログラムレベルで混入されていたら終わりです。とはいえ、可能な限り入力ソースは可能な限り信頼できるところからの一次データを残すべきでしょう。
しかしそうした対応をしたところで、何をどうしても、間違えたデータにもとづいて決断されたアクションを巻き戻すことはできません。時間ばかりは不可逆です。自分一人なら罪も自分一人で引き受ければいいですけれど、これが他人を巻き込んだものだと、どうにもなりませんやね。
真面目な話、データを取り込む系の機能をAIに書かせたやつ、一度ちゃんと見たほうがいいと思いました。特に仕様改修を重ねているものなんかは、前の仕様に引きずられる可能性が高くなるので、要注意ですね。
一応軽く対応をまとめますと、チェックポイントは以下ですかね。
- 入力ソースはどこからどう取得したか。どこで保存されるか
- 直近のデータと過去のデータでそれぞれ、1単位でズレがないか
- 欠損や異常値が再現するか
- 入力経路が複数ある場合それぞれ実行し、再現性と同一性はあるか
- (エンジニアは)DB設計の適切さ
- (エンジニアは)システムの入力と出力を完全に、処理を定性的に説明できるか
まぁ基本といえばそうなんですが、これの実行は言うは易しでめんどくさいですよ本当に。結局最後は手間をどれだけかけるかなんだなぁ……。
<関連記事>


コメント