AIの開発と技術
こんにちは。いつもの雑談、まじめな技術。略して、いつまじラジオのKです。
それからです。今回は、僕が企画というか持ち込みです。
今日はですね、仕事でAIの組み込み開発みたいなのをやっていまして、
そこで、EM兼PDM、プロダクトマネージャーみたいなこともやっています。
自分たちでモデルを開発するマシンランディングとは違って、汎用モデルに対してプロンプトを投げ、
その結果をプロダクトに反映するみたいな開発ですね。 AIエンジニアリングって呼ばれたりするんですけど。
主にプロンプトエンジニアリングが主で、時々ラグっていう技術を使ったりとかするんですけど、
ファインチューニングとかは、自己学習ですね。というのは全く行っていないような開発です。
一応、ラグの説明を簡単にしてもらってもいいですか?
ラグって汎用モデル、LLMが持ってる情報って絶対確実じゃなかったりとか、ニッチな情報って持ってなかったりするんですよね。
そういった情報の正しさみたいなのを、結構情報の正しさって各種ドメインごとに違ってたりするので、
その情報の正しさっていうのを、LLMに提供するための仕組みが一般的にラグって呼ばれるものです。
答えるためのソースを渡してあげるみたいな。
そうです。逆に考え方、思考方法とかっていうのは、モデルが学習をして身につけるものなので、ラグでは提供できない。
正確な情報っていうのを、これを使って回答してねとか、これを元にここからソースを引っこ抜いてきて、出してねとかっていうのがラグでできること。
逆に思考の方法をドメインごとに、ドメインごとに多分思考の方法っていうのは違ってたりすると思うんですけど、
変わってくるところ、汎用LLMなんで、もっとドメインに、我々のドメインに寄せて、モデルを作り変えたいっていうときは、
いわゆるファインチューニングって呼ばれる、自己学習っていうのをする。
思考の方法っていうのがあんまピンときてなくて、例えばどういうパターンが存在するんですか?思考の方法って。
どういうパターン?まあ思考の方法って言ったんだけど、結局そのLLMがやってるのって、パターンマッチングなんで、
要するに確率。これとこれ、AとBっていうものがあったときに、A-コンテキストだったらAが選ばれるし、
B-コンテキストだったらBが選ばれるみたいな、そういう確率での厳密には中ではやってるんだけど、
その確率をA-コンテキストのときもBが選ばれるようにしたいとか、
だからその確率をそのコンテキストには、なんだろう、ドメインに合わせてチューニングしていくみたいなのがファインチューニングって呼ばれる。
脳みその考え方というか、さっき思考って言ったのは、
思考パターンをチューニングしていく。そのドメインに合わせて、みたいな感じかな。
そんなことをしてます。
価格設定の難航
汎用モデルってトークン量に応じて金額が変わるっていうのは、みんな知ってそうなところなんですけど、
これぶっちゃけ高いんですよ。
ただ、モデル動かすのって相当なコストかかってるのも知っているので、個人的には仕方ない面もあるかなと思っています。
それでも商品、商用の製品に組み込むってなると、ユーザーからすると高いって感じられるだろうなって思っていて、
今って結構エアエンジニアリングって流行ってるけど、まだまだ事例が少ないですと。
そうだってくると価格設定に難航するんですよ。
基本的には定額よりも重量課金の方が失敗しづらいです。
ただし小さな会社は別に重量課金でいいんですけど、大きな会社になると基本的に予算みたいなのを立てないといけなくて、
そうなると重量課金モデルだと予算立てづらいから、定額が好まれるみたいな傾向があったりするんですよね。
最近そういうAI関連とか価格のこととかもやるようになって、なるほどねって思う機会は結構あるんですけど、これは結構面白い。
そうか、だから営業するにしてもどれぐらいかかるんですかって言われて、おっとしないですねって言われても。
結局予算立てるときに重量課金だから分かりません、では許されない世界だから。
なるほどな、確かにな。
このあたりは事業戦略の部分なので、開発サイドとしてはそこまで価格の設定とかに基本踏み込まないじゃないですか。
でもPDMってどこまでかかるべきなのみたいな疑問が残ってきますと。
実際の世間的なところだとViz寄りのPDMとかいたりとか、ビジネスサイド寄りのPDMだとか、開発サイド寄りのPDMだとかっていうのがあって、
結構PDMって守備範囲が広い。
そうですね。
抗議的には。
多分それは会社によって定義が多分違っていて、ビジネス寄りのPDMが定義されているのか、それともデブ寄りのPDMが定義されているのかはちょっと変わってくるし、
多分ビジネス、デブ側のPDMっていう定義にすると、おそらくビジネスサイドにはマーケティング担当みたいな、プロダクトマーケティングマネージャーみたいなPMMって呼ばれるようなポジションもあるんですけど、
そういう人とデブ側のPDMがタッグを組みながらやっていくみたいなスタイルになったりとか、色々多分あるんだと思うんですよ。
ありそう、確かに。
今、我々が所属している会社だと結構ビジネス寄りのPDMみたいなのが定義されている印象を受けています。
でも僕、喫水のエンジニアなんでずっと、今は兼務っていう形で一応PDMもやっているんですけど、
主戦場はやっぱりEMとしての仕事とか、エンジニアとしての仕事が結構メインだし、得意だなとは思っていますし、
事業側の課題まで解決するっていう時間は正直ないし、できるかも分からないみたいな感じなんですよね。
まあ、とはいえ、それはビジネスサイドのことも理解した上でできた方がいいんだろうなと日々思ってはいるんですが、
ぶちっきりやりたいとは思わないけどね。
分析の複雑性
こんな仕事をしていますと、今。
今回話したいのは、重量課金にしろ定額にしろ、AIの価格設定、マジむずいっていう話をしたいんです。
すでにむずそうだなって思ってますけどね、今の話は。
まず大変なのはAIは処理するトークン数に応じて価格が変動するんですよ。
さっき話したと思うんですけど。
たくさん入力を入れればその分増えるし、
相手が出してくる回答の量が多ければそれでもまた増えるってことですよね。
そうそう。
我々が今回AIを組み込もうとした機能っていうのは、
専門家が行っていた分析作業、脳みそで考えるような作業っていうのをAIに任せるっていうもの。
分析対象は、もちろん簡単なものから複雑なものまで千差万別ですと。
それは同じプロダクトの中でもそういうふうに分かれ、そういう違いがある。
同じプロダクトの中でも解決したいものの複雑度っていうか、
持っている情報量が違ったりとかするので、
この簡単と複雑で分かれるみたいな話なんですけど。
対象の、例えばユーザーの情報量が多い人と情報量が少ない人で、
どう分析、どれくらい分析するのかとか、
入力に入れる情報量も違ってきたりとかするので、
どうしても簡単なものと複雑なもののトークン数に違いが出ちゃいましたと。
だから例えば、いろいろ情報があると入力は増えるんだけど、
裏であれこれ考える必要はないから案外トークン量は少ないけど、
情報が少ないとあれこれ考えなきゃいけなくて、
トークン量は増えるみたいな感じになってる。
いや、そうではなくて、
推論量はあまり変わらなかったんですよ、実際のところ。
推論、若干変わるけど、
簡単なものは簡単で済ませる、基本的に。
あれこれ考えないようにプロンプトでチューニングできる。
なるほど。
複雑なものはやっぱりそれだけ情報を総合的に分析していかないといけないから、
なんか相互でこう、なんだろう、関わりがあるようなもの。
ちょっと隠しながら言うの面倒くさくなってきたからあれなんだけど、
患者の情報、患者がどういう薬とかを処方されたとかっていう情報って、
薬ごとの飲み合わせだとか、アレルギーだとかっていうのがあるので、
その情報を掛け合わせて、
正しい情報、正しい分析結果を出さないといけないってなると、
情報が増えれば増えるほどその複雑度が増していくっていう状況にあったと。
一応簡単に補足しておくと、我々薬局向けのサービスを作っております。
その前提で聞いていただければと思います。
隠そうかどうか迷ったけど。
とりあえずそんな感じで、情報量が増えれば増えるほど、
だってその患者さんが飲んでる薬が多ければ多いほど複雑になっていくし、
トークン量も増えていくみたいな状況がありましたと。
で、ここの、だから簡単なものと難しいもので、
価格が変動すると。
2、30円くらい違ってて。
1回に30円?
そう、1回に2、30円くらいの変動が、幅があって。
大きいよな、1回に30円って。
理論値としての中央値は出せるんですよ。
なんか、理論、こういうこれくらいの薬があるよねとか、
これくらいの情報量をインプットとして汎用モデルに渡して、
分析、推論量はこれくらいで、アウトプットはこれくらいみたいなのをベースに、
理論値をベースに、価格を決定することもできますと。
でもさ、実際に売り出して予測が外れていたときに、
言いたいことになる可能性を秘めていると。
それはユーザーが?それともユーザーからの信頼的な意味での?
いや、こっち側の、要するにこの理論値をもとに価格これくらい、
これくらい自分たちは利益欲しいからこれくらいってやったときに、
AIの料金設定の難しさ
実際には複雑なものしかその機能使われなくて、
常に赤字みたいな。
ユーザーから重量課金ってもらうんじゃなくて、
このぐらいになるだろうからこのぐらいの定量課金でベースするってこと?
定額でも重量課金でもそれは一緒のことで、
重量課金で例えば1回30円でしたってやったとして、
30円で提供しますって価格設定したときに、
毎回実行されるのを40円かかってたら赤字じゃん。
だから1回あたりいくらみたいな感じで、
本当にトークン料に応じて請求するわけではないってことですね。
そうそう、1回あたりいくらっていう。
でもトークン料に応じて請求って多分無理だから、
さらに重量課金でもけぎらいされるのに、
さらに複雑な料金待機にしちゃうと、
多分ユーザー使ってくれないから、
落としどころとして定額が一番いいんだけどユーザーにとっては。
でも落としどころとしては1回いくらみたいな価格設定するのが無難だよねっていう話で、
それをじゃあどうやって出すのってなったときに、
じゃあ今の理論値から1回いくらだよっていうのを出したとして、
この予測が外れてたら使われ方とか、
もう誤っていたらすごい損する可能性、赤字になる可能性があるじゃない。
かといって保守的に構えて、
最も複雑な減価、
例えば45円1回減価かかってたってなったときに、
ここを軸に料金設定して、
例えば80円とかに設定したら、
1回80円って、
それだけでユーザーから受けられてもらえずに、
作ったはいいものの使ってもらえない機能みたいになるのが一番悲しい結末だから、
でもどっちのスタンスを取るかってむずいし、
どっちもリスクあるから、
実地試験と情報収集
しかもAI組み込み開発って今回が初めてだったんで、
分かんないし、
今あるこの机上の情報だけだと判断つかない。
どっちにしろリスクしかないから、
だったら最終的に実地で収集された情報を、
実地で収集しようっていう話になって、
さよならことに協力してくれるユーザーも結構多数いたんで、
この策が取れたっていうお話なんですけど、
実際に本当に稼働してる薬局さんに依頼して、
使った結果を元にもう一回練り直すっていうことですかね。
そうそう、使ってもらって、
その時に、何だろう、
ちゃんと集計、情報を収集して、
その結果こういう使われ方することが分かったから、
その時は原価これくらいなんで、
これくらいの価格で提供しようみたいな。
今その準備進めている途中で、
まだ実地試験始まってないんですけど、
より良いものにするために利用時に収集する情報っていうのを、
僕の方で整理していて、
原価を取るのはもちろん、
1回あたりAIでかかったトークン料とか、
それにかかる値段ってどれくらいっていうのを、
収集するのはもちろんのこと、
この機能が実際に、
我々こういう使われ方をすると思っているけど、
実際に使ってみると本当にそうだったのか、
みたいなのもちゃんと分析できる必要があると思っていて、
それ用に取る項目、値って何があるんだっけ、
みたいなのは洗い出したりしています。
なんか、使ってもらうにしても、
例えば小児科のそばにある薬局と、
大きい病院の前にある薬局とでは全然違う、
みたいな話もあるわけですよね。
そうそうそうそう。
来る処方が、
例えばGB、
咽喉科とか、あと眼科とかって、
結構来る、
処方箋の複雑さが、
そんなに複雑じゃなくて、
結構簡単に案内もできる、案内というか複訳指導もできるし、
みたいな感じなんだけど。
逆にそういった精神科とかは、
結構薬いっぱい出るったりするので、
大変だったりしたりするんですけど、
そういう、どのようなユーザーペルソナ、
どういった処方ペルソナ、
何かそういうペルソナなのかっていうのを、
明確にすることによって、
その機能をリリースした時に、
マーケティングとか営業もしやすくなるだろうっていう。
だからこの機会、実地試験というこの期間を、
大切に有効活用しようって思って今、
項目の洗い出しとかでいますと。
ビジネスと熱量の重要性
確かにそれやらないと全然分かんなさそう。
そう。
見当使うんだ。
これやってて思ったのは、
なんかめっちゃPDMっぽいことしてるなって思って。
売るためのデータの収集だとか、
何が事前に必要になるかとか。
この項目とこの項目、
Aって項目が10で、Bって項目が20だったら、
こういうことが言えるよねみたいなのを事前に考えたり、
今してるんだけど。
これまでは何を作るかとか、
どのようなプロセスで開発していくかっていった、
開発寄りのPDMロールみたいなことをしてきたんですけど、
今回のようにビジネスサイドに寄せたPDMの仕事って、
割と初めてで、
改めて振り返ってみると、
ビジネスサイド側のPDMっぽいことをしてるなって思ったっていう話でした。
とはいえAIっていうところがやや開発によっているっていうのは、
まだやりやすさがある部分ではあるのかなとちょっと思ったよ。
そうですね。
ただやっぱ伝えるのが難しいよね。
それは誰に対して?
ビジネスサイドとかに。
社内の人間に。
AIの仕組みってこうだから、
こういうの苦手なんですとか、
今ってやっぱりAIが進化化されてるから、
何でもできるやつになっちゃってて、
実際にAIの勉強とかしてみると、
そんなことなくて得意不得意は、
今は結構いろんな記事でそれ言及されてると思うけど、
その辺りをちゃんとビジネスサイドに伝えていくのって難しいなって思いました。
そうですね。
その辺と、
何だろうな。
言語が違うからなかなかうまく伝えるのって。
今、僕のチームとかも、
ビジネスサイドって言っていいのかな。
サポートとかユーザーに向き合ってサポートしてくれてる方たちとやり取りする機会ってめちゃくちゃ多いけど、
だいぶこちらに寄ってきてくれていて、
こちらを理解しようとしてくれてるからすごくやりやすいけど、
なかなかそうじゃない段階とかだったら、
どこから説明したほうがいいのかなとかからまず考えなきゃいけなくて、
場合によってはその辺知ってるとなるとすげえ冗長の説明になっちゃうしみたいな、
その辺がいつも難しさは感じますね。
お互い歩み寄る気持ちを持って。
歩み寄る気持ちと、やっぱり製品を本当に売りたいとか、
この機能本当に素晴らしいものだと思って、
やっぱ売っていかないといけないなと思って。
じゃないと興味関心が湧かない。
ビジネスサイドも開発サイドも一緒なんだけど、
関心がない人から売り込まれても多分響かないと思っていて、
本当にすごいんですよっていう熱量が伝わるからこそ、
人って結構動くって、心動かされるから、
やっぱこうなんでしょ、薄っぺらい感じで終わってほしくないなって思いますね。
そうですね、そこら辺のホント感が違うと恥ずかしいですもんね。
実際に売りに行くと、僕営業してないからそんな偉そうなこと言えないけど、
買う人たち、使ってくれる人たちって少なくとも選んで、
我々の製品を使ってくれるわけだし、
その選ぶ時っていうのは、
彼らが今課題としているものを少なからず解決、
並べて、製品をいくつか並べた時に、
我々の製品が一番その課題を解決できると思ってくれたから、
選んでくれていると信じてるわけです。
政治的な力が働いてない限りは。
そこに対して、その課題に対してこういうアプローチで、
我々の製品は解決できますよっていうのを伝えるのって、
自分たちの製品に対して熱量を持ってないと無理じゃないっていうんですよね。
確かにな、だから極論営業、
偉そうに僕も喋れないんだけど、
営業って良い製品と熱量があれば売れるのかもなと今の話を聞いてます。
細かいテクニックより。
一応多分戦略とかはいるんだと思うんですよね。
計画立ててとかそういうのは必要だと思うんですけど、
やっぱ一番必要なのはそこなんじゃないですか。
臨機応変に対応できるのって、
例えば課題って多分各社で違うじゃないですか。
各社で違う中でその課題に対して、
でも製品は一つしかないし、各社ごとにチューニングしているわけじゃないから、
要するに各社が課題に抱えているものっていうのをどう解決するかっていうのを、
自分の製品をめちゃくちゃ知ってるから臨機応変に対応できないといけないと思うんですよね。
本当に売りに行くときは。
その臨機応変になるくらいの知識量を持つって、
多分熱量がないと、製品に対する愛がないと無理だと思うから。
そうですね。
熱量を持って接しないとそれに対する疑問もわからないから、
ユーザーからの質問に答えられないとかもありますよね。
熱量の話ってここ半年ぐらい結構してるイメージがあって、
熱量と戦略の重要性
まあ諸事情によりというか。
そうだね諸事情によりそうなんだけど、
でも結局やっぱなんか興味関心を示すって、
そこに熱量があるからだと思うんだよね。
なんか楽しいって思うっていうのもそういうこと一緒だと思うし、
まあ惰性でやるっていうのがやっぱ何よりも良くないし、
肩にはめてやるってそこに興味関心はない。
ただ自分が決められた型通りに物事を進めるっていうのもなんか温度がないじゃん。
冷え切ってる感じがするし。
そんなのよりはやっぱね、みんな熱量を持ってた方が楽しいだろうっていう。
そうだと思ってる。
過言だけど熱量が全てを解決するぐらいに思ってもいいのかもしれない。
そうだね。
まあいろんな多分戦略は、なんかそう熱量って多分やっぱ戦略とかの思考性なのかもしれないね。
計画立てるとか、だからなんか無計画にこう、
あの熱を注いでばっかいてもあんまり物事ってうまくいかないから。
楽しみたいだけなら熱量だけでいいけど、楽しみプラス何か成功を収めたいんなら、
計画性とか戦略みたいなのを持ってた方がいいんだろうなって思う。
でもあの無理やり熱量だけに持ってこうとするんですけど、
熱量があれば、じゃあ売るために、
これユーザー本当にいいものだと思ってるからユーザーに広めたいってなるじゃないですか。
そうすると計画も考えるっていう風になるんじゃないかと思う。
そうだね、それもあると思う。
やっぱ熱量駆動が最強、最強だし、こうあるべきだし、
もう、はい、熱量ですよ。
そうだね、熱量がだから自分が楽しいだけになっちゃうと、
楽しいの向きも変わるけど、
何かに貢献する、組織に貢献するだとかチームに貢献するだとか、
そういう方向性に持っていけるとすごく活躍できると思うけど、
なんか熱量がただ楽しむだけ、自分が何の成果もいらないし、
ただ今これをやってることが楽しいっていうだけだと、
もしかしたら成果には結びつかない可能性があるのかもなって思ったりはする。
なんかちょっと一個思い出した話として、
ちょっと宗教の話なんですけど、どことは言わないんですけど、
とある宗教が、その宗教本人たちはものすごくいいと思っているから、
熱量を持って勧誘するんですよ。
それはノルマとかそういう話じゃなくて、
本当にいいと思っているから勧誘するけど、
相手にその気がないからしつこい勧誘っていう評価を受けてしまうっていう話があるんです。
なるほど。
だから、やっぱ熱量だけが絡まると、
かえって悪い可能性もあるのかもしれないとちょっと思い留まりました。
そうだね、確かに。
だから、もうちょっと周りが見えないといけないかもね。
周りっていうか、もっとこういろんな視野を広げながら、
熱量あると何かに熱中するとさ、視野ってめっちゃ狭くなる。
でもそれが楽しかったりするじゃん。
インザメガチャーチの中でも言ってるんだけど。
ちょっと前読んでないんで。
視野を狭くすると人って楽しめるんだよね。
うん、そうですね。
それはそれ大事だと思うんだけど、
逆に視野が広すぎる、広く持ちすぎると何もできなくなっちゃう可能性がある。
確かにそうかもしれない。
いろんなものが見えちゃうがゆえに先も見えた気になっちゃって、
行動を起こしづらくなっちゃう、逆に。
だから時に人は視野を狭めて何かに集中するって、
没頭するっていうことはすごく大事なんだろうなって僕は思っていて。
でも立ち返りましょうと、振りちょっと立ち止まって、
視野ずっと狭くしてワーって走るのも楽しいけど、
一旦止まる機会を持って一旦俯瞰してみましょうみたいなのが多分大事なんだろうなと。
確かにガーッと何かに向ける時間もいいけど、
そういう俯瞰するタイミングは間違いなく必要ですね。
そう。
そんなところですか?
そんなところですかね、なんか広がっちゃったけど。
全然最後は関係ない熱量の話に。
広がっちゃいましたが、今日はAI価格設定に難航した話でした。
視野の狭さと俯瞰
はい。
ありがとうございます。
ありがとうございました。
