2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
松田敦義氏(以下、松田):時間になっているので、20分ぐらいQ&Aをやりたいと思っています。どんなことでもかまいませんので、挙手の上、質問をしてもらえればと思います。
質問者1:登壇ありがとうございます。すごく勉強になりました。まずはAPIのモデルに関しての質問です。みなさんわりと、GPT-3.5を使っていることが多いのかなと思うのですが、GPT-4を使っていないのはやはりコスト面が大きな理由だったりするのかどうかを教えていただきたいです。
松本勇気氏(以下、松本):実はそのタスクによって僕は(GPT-4を)使っています。特に文書解析の人の時給が高いというケースでです。例えばフォーム的な知識が必要なドキュメントの下書きを作ってみましょうといったケースの場合は、正確性のほうがある程度勝ります。そこに関して、例えばこのドキュメント1本を作るのに10万円かかっているのであれば「2、3,000円かかってもよくない?」という感じで、GPT-4をガンガン叩くようなかたちで使っています。
一方で、これはレスポンスタイムが必要だというケースでは、GPT-3.5を使います。そのあたりの使い分けは最初の実験段階で、まずGPT-3.5で十分いけるタスクかなというのを実際に組んでみて、チェックして、それをまたGPT-4で試してみる。そうするとレスポンスタイムと出来上がる精度が見えてくるので、そこで見比べながらやっています。
個人的には、ここで本当にお金が湯水のように使えるプロジェクトだったら、GPT-4の32Kモデル。32,000トークンも食わせられるあいつを、最近ちょっと触っているのですが、とてもいいなと感じています。
佐藤将高氏(以下、佐藤):うちの会社ではなく僕自身の話ですが、やはりChatGPTはカジュアルに嘘をついてくるじゃないですか。なので、「嘘をついてもまぁいいかな」とか、自分である程度判断できるやつはGPT-3.5を使っています。正確性がもう少し欲しいなとか、ゆっくりでもいいというパターンであれば、GPT-4を使っています。
あとは最近は、プラグインがWebだとできて、「Bing Chat」と同じような仕組みで情報を取ってこれるので、それを活用してリアルタイムで取れる情報を基に結果を生成するという使い分けをしています。
金杉優樹氏(以下、金杉):うちは、もうGPT-4にお願いをしているというモデルですね。議事録の要約でMapReduceとかをする時に、GPT-3.5だと「そうなるのかぁ」みたいなのがあるので、本当に質とコストとスピードでのトレードオフです。うちはちょっと質を取りたいので、今はもうGPT-4を中心に使っていますね。
松本:1個思い出したんですが、けっこうおもしろいからエージェントを作りたいなという方が多いと思います。あれをまともに動かそうとして、GPT-4以外でやると何だかんだ間違ったアウトプットが返ってきて、そもそもその瞬間にLLMが適切なアウトプットを出さずにエージェントが止まってしまうということがあります。
なので、現行のモデルを見ている限り、エージェントをガッツリ使ってなにか高度なものを作ろうという場合は、僕はGPT-4を使ったほうがそもそも幸せなのかなとは思っています。
質問者1:わかりました、ありがとうございます。参考にさせていただきます。
松田:その他になにか聞いてみたいことはありますか?
(会場挙手)
質問者2:お話ありがとうございました。ここにいるみなさんにも、たぶん同じような悩みがあるのかなと思うんですけれども。先ほどプロンプトインジェクションの話もありましたが、LLM特有のセキュリティマターはけっこう気にしないといけないことがあったり、コードのリファクタリングが便利な反面、「このコードって覚えさせていいんだっけ?」みたいなジャッジの面がけっこう難しいかなと思います。
そういった面で、どういうガイドラインを引いているのか。もしくは社員の方々に教育的な部分をどうやるのか。もしくはシステム的に漏洩が起きないような工夫をされているのか、そのあたりについてうかがえればなと思っています。簡単にプロンプトインジェクションが起きちゃうのがGPT-3.5だと思うので、意図せずにぜんぜん起きるのかなと思っていて、みなさんも、そのあたりがかなりおっかなびっくりするところなのかなと思っています。
金杉:うちはまだ人数が少ないので、コントローラブルみたいなところがある前提ですが、やはりガイドラインは作りました。何をベースにしたかというと、たぶんクラスメソッドさんかな? クラスメソッドさんが、GitHub CopilotとChatGPTに関して「こんなガイドラインを作ります」みたいなものを出したんですよね。
それをけっこう頂戴しました。社内でどんな感じで使うのかに合わせて、うちなりのガイドラインを社内で作って、全員に読んでもらって、時間も30分ぐらいかけて説明をして、さすがに漏洩したらまずいよねというのを入念に説明をして、それに同意をもらった人だけ使用可能な状況にしています。やはりガイドラインなどは、社内で利用するには必須になるのかなと思いました。
佐藤:先ほどのGitHub Copilotの話であれば、エンタープライズのものを使えばそこは一定学習に使われないことが担保できるので、そちらを使います。
それと、実際に内部でGPTのボットなどを活用する場合に大事にしているポイントを言うと、一応ログをいつでも参照できるようにしています。ログを溜め続けると、利用促進もどれぐらいやったほうがいいんだっけ? という解析にも使えますし、実際に問題が起きた場合や、「これはやばいね」みたいなものを視察する上でも、ログをきちんと取っておくのはプラスでやっています。
松本:プロンプトのインとアウトのログを取るのは大事ですよね。最終的には規約を信じるしかありません。例えばCopilot for BusinessやChatGPT APIやAzure OpenAI Serviceなどの規約で、学習に使わないと書いているのであれば、それに対して我々は一定の信頼を置いて使っています。
あとはChatGPTのWebサービスの活用で言うと、我々の組織の場合、今、社内情報がコンフィデンシャル、プライベート、パブリックなど、いくつか情報の管理基準が設けられているので、パブリックの情報は載せてもいいけどそれ以外は絶対ダメよというルールを、ChatGPTを社内で使ってもいいよと通達する段階できちんと作って、そこのルールの共有もした上で「積極的にこうやって活用するといいよね」という話もセットでインプットしました。
質問者2:ありがとうございます。
松田:では、その他になにか質問をしたい方。
(会場挙手)
質問者3:ありがとうございます。1点質問したいのですが、お三方は実際にAzureのChatGPTのAPIを使っているのか、それともOpenAIのAPIを使っているのか、どちらですか? それぞれ使ってみてどういったメリットやコスト、もしくは「高性能が必要だからAzure」みたいなところでいろいろあると思いますが、そのあたりの肌感をお聞かせいただけたら幸いです。
佐藤:うちはまだOpenAIのしか使っていないのですが、先ほどあったようなAPIの安定性でいうと、やはりAzureのほうが良さそうかなというところです。あとは個人情報をより学習に使われなかったり、単独で安全性を保つという意味だとAzureのほうが良いのかなと思っているので、そちらも含めてこれから検証していこうかなという段階です。
質問者3:現在OpenAIを使っているのは、どちらかというとコストや気軽さみたいな感じですか?
佐藤:そうですね。爆速でやることが大事だったので、使えるものを速攻で使えるようにしています。それと、Azureも確か審査が必要なんですかね? そこの時間がもったいなかったので、OpenAIと選択肢を絞り込みました。
質問者3:ありがとうございます。
松本:自分は今、Azure OpenAI Serviceを使っています。理由としては、先ほどの安定性とセキュリティです。日本のマイクロソフトのスタッフの方にいろいろと相談させてもらっていて、そこでけっこう知識もいただけるので、けっこう積極的に活用しています。
ただ、先ほどおっしゃっていたとおり、こちらから申請して先方でレビューをして、実際にAPIが使えるまでに、人によってはけっこう時間がかかるらしいので、例えばマイクロソフトさんに対して「こういうふうに使うので、ぜひ迅速な審査をお願いします」みたいなコミュニケーション取ったりするということを聞いたり聞かなかったりみたいな、何とも言えないところです。
ちょっと準備の時間がかかるかなというところはネックなのですが、個人的にはお客さまに提供するサービスを作るのであれば、基本的にAzure OpenAI Serviceを使うほうが、いろいろ考えることが減るので良いのかなとは思っています。
質問者3:ちなみにどれくらいのお時間がかかりましたか?
松本:どれくらいだったかな? すみません、ちょっと頭から吹き飛んでいるのですが。1週間ぐらいかかっているのかな。あとはGPT-4は未だに降ってこないとおっしゃっている会社のほうが多いですね。
質問者3:降ってきていない。それはAzureのほうですか?
松本:Azureのほうですね。AzureのほうのGPT-4 APIは、今も降ってきていない会社さんが多くて。降ってくると32,000トークンモデルが使えてメチャクチャハッピーみたいな。
質問者3:でも一度動かすと数十万みたいな感じ(笑)。
松本:それでぜんぜんペイするタスクを持ってくればいいやと、そういう発想ですね。使えばいいと思います。
金杉:ありがとうございます。それで言うと(自分は)降ってきてない側の人で、AzureのGPT-4のWaitlist待ちなので担当者をつついてる段階ですね。
質問者3:ちなみにOpenAIのほうのGPT-4は?
金杉:大丈夫です。使えています。
質問者3:(OpenAIのほうは)使えて、Azureのほうがまだという感じなんですか?
金杉:まだですね。そもそもAzureのOpenAIを使うにも審査があって、さらにGPT-4も審査があるので2段階をくぐり抜けなくちゃいけなくて。まだ1段階目で止まっているので、AzureのOpenAIのGPT-4で検証ができない状況です。
質問者3:ちなみにAzureを使っている方たちの肌感でいいのですが、請求金額は月々いくらぐらいになっていますか? それともまだそのあたりの請求書は来ていない感じですか?
松本:手元の実験なので、数万円もいっていない感じのはずです。すみません、僕もそんなにかかっていなかったのでそんなに気にしていなかった感じです。社内利用だと本当にそんなにかからずに使えると思っています。
質問者3:ありがとうございます。
佐藤:追加ですが、内製のLLMをやっていこうとすると、やはりAzureのほうが選択肢として広そうだなというところはあったりします。
質問者3:今、月々いくらぐらいですか?
佐藤:スタートアップだと、マイクロソフトさんから支援も受けられるので、実は1年分だけ、だいたい1,000万円か2,000万円ぐらいはスタートアップでかつ若いアーリーステージの方だとメチャクチャメリットがありますね。
質問者3:ちなみにそれを除いた上ではいくらぐらいだったんですか?
佐藤:うちはAzureのほうはわからないです。
質問者3:ありがとうございました。
松田:予定の時間をちょっと押しているので質問はこちらで……。あ! じゃあ最後に真ん中の方、お願いします。
質問者4:登壇ありがとうございます。2つ質問をしたいです。1つ目はファインディさんで、実際にプロダクトとしてリリースした時に、KPIや目指していたものはありましたか? そして、それに対して良い結果が出たのか、それともそんなにだったのかを聞いてみたいです。
佐藤:ありがとうございます。ものすごく良い効果が出たというのが結論です。リリースしたのが3月の頭だったので、どういうふうに出てくるんだろうというワクワク感がものすごく強かった時期にリリースできました。「このぐらい来たらいいよね」と言っていた5倍から10倍ぐらいは来てくれて、メチャクチャ良い反応だったという結論にはなりました。
質問者4:あと、お三方に最後質問したいのですが、今はたぶんChatGPTやOpenAI ServiceというかたちでOpenAIを使っていると思います。今後、別のGenerative AIに精度的に変えられたりするのかなと思っていて、それを見据えた上での設計で気をつけていることなどがあったら、教えてほしいです。
松本:そうですね。個人的にはなるべくライブラリを噛ませたほうが、その間のアダプタを抽象化してくれるものにはなるので、いいのかなとは思っています。個人的には今LlamaIndexを使っていますし、LangChainも使っています。LangChainは、すでにいろいろなAPIに対応していたり、例えば手元で動かすタイプのLlamaベースの新しいモデルもアダプタがあってすぐに組み込みやすくなっているので、そういう抽象化層を挟むのは設計上良かったりします。
ただ、タスクがLangChainの使い方に縛られることもあるので、LangChainを使ってもLangChainらしい機能を使わずに、素で結局クエリを書くのでもいいのかなと思っています。ただ、何にせよライブラリに挟んであげれば間で抽象化されるので楽にはなるのかなと思います。
個人的にはもちろんOpenAI以外もどんどん使っていきたいなと思っていて、それこそ「Bard」というかPaLM2が出たり、あとはanthropicの「Claude」ですよね。呼び方を覚えていないんですけど、そういったものが出てきたらどんどん使います。軽量モデルでファインチューニングするのもわりと興味があるので、例えばVicunaとかをちょこちょこ動かしてみては性能をチェックして、「んー。まだ足りないな」というのをずっと繰り返している感じです。
佐藤:うちも基本的に考え方は一緒です。新しいものが来ても大丈夫なアーキテクチャにしておくのがメチャクチャ大事かなと思いますし、一方で、その新しいものに置き換えていくぞというぐらい、技術検証をしまくるのが大事かなと思います。
まったく聞いたことがないものが毎日機械学習エンジニアから出てくる状態が日々実現できていて、それをやって成果が出たら「じゃあ置き換えるか」みたいなマインドに全員がなっておくのがすごく大事なのかなと思っています。アーキテクチャというか組織のマインドに近いところですが、そこが一番ボトルネックになるんじゃないかなと思います。
金杉:うちもほぼ同じで、いつでも捨てられるようにという感じで設計はしていますね。ChatGPTに投げたコマンドプロンプトをBardにも投げられるのかなとか。そういう差分はやはり気になるのですが、そこを気にし過ぎるとやはりスピード感を持ってできないと思っています。作って、ミスったら最悪捨てるぐらいの覚悟でやっていますね。
質問者4:ありがとうございます。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには