UKA-GYRE 開発記 ― 読み物編 番外
前回の記事:
この記事は「UKA-GYRE 開発記」 読み物編 番外回 です。
シリーズで一番ふざけた回ですが、一番本音で書いています。
ここまでの5回で、AIに性格を教えた話、経験を積ませた話、データの読み方、プロンプトの技術、Human-in-the-Loopの思想を語ってきた。
番外回では、本編に書けなかった話をする。開発者の裏側。恥ずかしい実験、想定外の苦労、そして深夜2時のカップ麺。
1. 開発者、自分のシステムを使ってみる
数ヶ月間、他人の食事データを分析し、他人のためにAIコメントを生成し続けてきた。
カロリーの傾向分析、PFCバランス、曜日パターン。
他人の食生活については、もはや専門家レベルで語れるようになっていた。
ある夜ふと思った。
「自分でも試してみるか」と。
1ヶ月間、自分の食事データをシステムに入力して、AIからコーチングコメントをもらう。
誰よりもこのシステムの仕組みを理解している人間が使うのだから、きっと効果は抜群だろう。
始める前はとても楽しみで自信に満ち溢れていた。この時までは……
2. AIが開発者に送ったコメント集
以下、実際にシステムが生成したコメントの要約と、それを読んだ開発者の心の声。
AI: 「昨日の摂取カロリー3,200kcal。開発に集中していたのは分かりますが、せめてPFCバランスだけでも意識しましょう」
(いやあの日はコードがめちゃくちゃ良い感じに書けてて、気づいたら22時で、そこからコンビニで......言い訳だな、うん)
AI: 「3日連続でタンパク質が目標の50%以下です。タンパク質を取りましょう。」
(カップ麺にも一応タンパク質は入ってるんだが......5gくらい。目標90gに対して5g。なるほど、50%以下どころではない)
AI: 「今週の平均カロリーが目標を500kcal超過しています。原因を一緒に考えましょう」
(原因は分かっている。深夜2時のカップ麺だ。毎晩。考える余地がない)
AI: 「金曜の夜、毎週3,000kcalを超えていますね。パターンが見えます」
(パターンが見える、じゃないんだよ。こっちはそのパターン検出の仕組みを作った本人なんだよ。自分で設計した仕組みに自分でハマるとは思わなかった)
自分が設計したトレンドパターン分析に、自分のトレンドパターンを見抜かれている。
シュールとしか言いようがない。
3. 正しいことと、人が動くことは、全然違う
1ヶ月後の結果。
体重は開始時とほぼ同じ。 グラフにすると見事な横一直線。
AIは完璧なアドバイスをくれた。
「金曜の昼を軽めにしましょう」「深夜の間食を減らすだけで、週平均が目標内に収まります」。
どれもデータに基づいた、論理的で、的確な助言。
でも、正しいことと、人が動くことは、全然違う。
「正しいこと」を言われて素直に行動を変えられるなら、世の中にダイエット本は1冊で十分だ。正論が人を動かすなら、健康診断の結果を見た翌日から全員が運動を始めている。
自分の身体で思い知った。
「良いコメント」と「行動変容」の間には溝がある
AIのコメントは正しかった
でも正しさだけでは人は動かない
必要なのは「正しさ」ではなく「その人にとっての説得力」だ
......これってMBTIパーソナライズを導入した理由そのものじゃないか。
自分で設計した思想に、自分で身をもって証明された。
4. RAGチューニングの泥臭い日々
ここからは自主実験ではなく、開発の苦労話だ。
RAG(検索拡張生成)は、過去の知識をAIに渡してコメントの質を上げる仕組みだ。技術深掘り編で詳しく書いたが、ここでは技術深掘り編に書けなかった泥臭い話をする。
4.1. 「なんでこれが1位なの?」
検索結果を毎日眺めていた時期がある。
クライアントの食事データに対して、過去の成功事例を検索する。上位3件が表示される。
理想は「似たような状況の、参考になる事例」が出てくることだ。
ところが、「カロリー超過のクライアント」に対して「体重が順調に減っている模範事例」が1位に来たりする。
真逆だ。参考にならないどころか、AIがその事例を真似してトンチンカンなコメントを書いてしまう。
原因は、ベクトル検索の「似ている」が人間の「似ている」と違うことだった。
「ベクトル検索は単語ではなく『意味の近さ』を見る。だからこそ厄介で、『順調な減量』と『深刻なリバウンド』は、どちらも『体重の変動』という同じトピックの話題であるため、AIの空間では『非常に似ている意味』としてすぐ隣に配置されてしまうのだ。」
この「なんでこれが1位?」という問いとの戦いが、検索品質の改善の始まりだった。
4.2. 終わりのないチューニング
RAGのチューニングには終わりがない。
- 検索結果を改善すれば、今度はAIの使い方が悪い
- AIの使い方を直せば、今度はナレッジベースのデータが古い
- データを更新すれば、今度は新しいデータが既存のパターンと矛盾する
一つ直すと別の場所が壊れる。モグラ叩きだ。
だが、この「永遠に完成しない感じ」こそが、使えば使うほど良くなるシステムの本質でもある。完成しないのではなく、常に改善し続けるのだ。
......と、自分に言い聞かせている。
5. トレーナーは私ではない
ここからは、実際にトレーナーへ届けてからの苦労話だ。
5.1. 期待値という名の壁
トレーナーに初めてシステムを見せたとき、期待値が天井を突き抜けていた。
「AIが作ったコメント」と聞いた瞬間、相手の中で品質期待が100%に設定される。だから90%の品質でも「あれ、こんなものですか」と言われる。
「AIが下書きを作るので、あなたが仕上げてください」と伝え方を変えた途端、同じ70%の品質でも「これは便利ですね」と言われるようになった。
同じ出力、まったく違う満足度。
技術の品質よりも、期待値の設定のほうがはるかに重要だった。
5.2. 「自然」の定義は人の数だけある
「自然な文章にしてほしい」。
この要望を何度もらったか分からない。
でも「自然」の定義は人によって全然違う。
ある人の「自然」は「です・ます調をやめること」だし、別の人の「自然」は「専門用語を減らすこと」だった。
最初は「どんな文章が理想ですか?」と聞いていたが、答えは常に曖昧だった。
「なんというか......もっとこう、自然な感じで......」。
途中でやり方を変えた。
出力を見せて「ここが嫌だ、という部分はありますか?」と聞くようにした。
すると驚くほど具体的な答えが返ってくる。
「この"ございます"が堅い」「この褒め方がわざとらしい」。
欲しいものを言語化するのは難しい。でも嫌なものを指摘するのは簡単だ。
暗黙知は肯定ではなく、否定から引き出す。
これは開発中に得た最大の学びの一つだった。
5.3. 技術の翻訳という仕事
「Temperatureパラメータで生成の多様性を制御していて......」と説明した瞬間の、相手の目から光が消えていくあの感じ。
「使い続けるほど、AIがあなたの好みを覚えます」。
これで全て伝わった。
正確さと伝わりやすさは、しばしばトレードオフの関係にある。
このプロジェクトで最も鍛えられたのは、コーディング能力ではなくコミュニケーション能力だった。
6. 終わりに
「で、結局痩せたの?」
痩せてない。
なんなら微増している。
ダイエットAIコーチングシステムを作った開発者が、自分のAIのアドバイスに従えなかった。最高に皮肉だ。
でも、深夜2時にカップ麺を食べながらデバッグした日々がなければ、このシステムは生まれなかった。
痩せなかったけど、ダイエットAIは作れた。それで十分だと思うことにしている。
読み物編はこれでおしまい。
技術的な「どうやって」に興味がある方は、ぜひ技術深掘り編へ。
コラム:医者の不養生、プログラマーの不摂生
「医者の不養生」ということわざがある。
人に健康を説く医者ほど、自分の健康管理がいい加減だという皮肉だ。調べてみると、この現象は普遍的らしい。
ファイナンシャルプランナーの貯蓄率は一般人と大差ない。
睡眠研究者の平均睡眠時間は6時間を切っている。
禁煙外来の医師が喫煙者だったという話も珍しくない。そしてここに、ダイエットAIを開発して1グラムも痩せなかった男が加わった。
なぜこうなるのか。仮説はある。
「理解すること」と「実行すること」は、まったく別の能力だからだ。
知識が増えるほど「正しいこと」は見えるようになる。
でも見えることと、やれることは違う。AIは正しいアドバイスをくれる。人間は正しいアドバイスに従わない。
この溝を埋めるのが、結局のところ、Human-in-the-Loopの本当のテーマだったのかもしれない。......まあ、ループの中にいる人間が毎日カップ麺を食べていたら、AIにできることは限られるが。
次回の記事:
「UKA-GYRE」開発記 シリーズ目次
読み物編 --- エンジニアでなくても楽しめる!
- プロローグ ― UKA-GYRE 開発記
- 読み物 第1回 ― ISTJには数字を、ENFPには共感を ― AIに「性格」を与えた日
- 読み物 第2回 ― 深夜3時はAIの経験値稼ぎタイム ― 「昇華」のメカニズム
- 読み物 第3回 ― カロリーの数字の裏にある物語 ― AIが「今日のあなた」を理解するまで
- 読み物 第4回 ― 「何を書くか」より「どう伝えるか」 ― AIを使った大人の実験科学
- 読み物 第5回 ― 「AIが書いた」ではなく「AIと一緒に書いた」 ― Human-in-the-Loopという思想(完結)
- 読み物 番外 ― 自分が作ったAIに食べ過ぎを怒られ続けた話 ― 開発者の裏側(この記事)
技術深掘り編 --- 設計判断と実装の詳細