LLMプロダクトや機能を開発する際に知っておいてほしいこと - 従来のプロダクト開発との違い
こんにちは、Algomaticの大田（OTA57）です。
生成AIで世界を沸かせるべく色々やってます。
先日LLM赤裸々ナイトというイベントを開催しました。
そこで話した内容で、「LLMプロダクトや機能開発の進め方のベストプラクティス」というテーマが興味深かったので個人的な考えを記します。
以下ツイートもしたのですが140字では伝わらないなーと思ったのでnoteにもしてみます。
LLMプロダクトや機能開発に取り組んでいるPMの方や、その決裁者・レポートラインにあたる方が従来のプロダクト開発と何が違うかを知っておいてほしいという強い思いがあります。
今日の #LLM赤裸々Night では
— naotoota | Algomatic CoS (@OTA57) August 15, 2024
LLM系のアプリや機能開発は5-6割の完成度のものを作るのは爆速なだけで、その後はかなり地道なR&D的要素があり、10割の完成度を考えると従来の機能開発のほうが早いこともあるみたいなことを考えた。
他にもインパクトの軸とかもあるので、どう取り入れるかはとても難しい pic.twitter.com/DFWJEpOwzm
端的にいうと「試行錯誤するフェーズが前に来るか後に来るかの違い」です。
動くものやデモを作るのはとても早く作れるようになりました。
ですが、それを安定的な機能としてリリースするには試行錯誤がとても重要です。
従来は動くようになればあとはバグを取り除くだけという考えで良かったのですが、そこからが本番というところが大きく異なります。
みたいな話を以下で詳しく話せればと思っています。
※ Github CopilotやCursorのように開発工程にLLMを使うという話ではなく、LLMプロダクトや機能の開発に関する話です。
文中で「LLM開発」や「LLMを用いた開発」という言葉が出てきますが、それらもLLMプロダクトや機能の開発という意味です。
従来のプログラム、LLM以前の機械学習、LLMの挙動特性・開発プロセスの違い
そもそもプログラムの挙動の特性自体が従来のプログラム、機械学習、LLMのそれぞれで大きく異なります。
挙動の特性が異なるということは考え方や開発アプローチも異なるべきです。
ここを理解せずに従来の考えで機能開発に取り組むと罠に引っ掛かる確率が高いと思います。
1. 従来のプログラミング
従来のプログラミングでは、開発者が明示的にロジックを記述し、入力に対する出力を厳密に定義します。
開発プロセス：要件定義、設計、実装、テストという線形的なプロセスが一般的。
入力と出力の関係：一対一の関係が基本。同じ入力に対しては常に同じ出力が期待される。
開発/改善にかかる時間：機能の複雑さに比例して増加。
適用分野：明確なルールや計算が必要な領域（会計システム、データベース管理など）。
この方法では、「バグ」は明確に定義され、期待される出力との差異として容易に特定できます。
2. LLM以前の機械学習
機械学習の導入により、データから学習してパターンを見出すアプローチが可能になりました。
開発プロセス：データ収集、前処理、モデル選択、学習、評価、チューニングの繰り返し。
入力と出力の関係：確率的な関係。同じ入力でも確率的に異なる出力が生成される可能性がある。
開発/改善にかかる時間：初期開発に時間がかかるが、データの追加や調整で継続的に改善可能。
適用分野：パターン認識、予測、分類（画像認識、レコメンデーション、異常検知など）。
この段階では、「バグ」の概念が曖昧になり始め、代わりに精度や性能指標が重視されるようになりました。
3. LLM（大規模言語モデル）
LLMの登場により、開発アプローチは劇的に変化しました。
開発プロセス：プロンプト設計、ファインチューニング、統合、継続的な評価と改善。
入力と出力の関係：高度に柔軟で創造的。同じ入力でも文脈や設定により大きく異なる出力が生成される。
開発/改善にかかる時間：基本的な機能は非常に短時間で実装可能。ただし、精緻化や特定のタスクへの最適化には時間を要する。
適用分野：自然言語処理全般、創造的タスク、複雑な推論（文章生成、対話システム、コード生成など）。
LLMでは「バグ」の概念がさらに曖昧になり、代わりに出力の質、一貫性、適切性などが評価の中心となります。
この進化を理解することで、LLMプロダクトや機能の開発が従来の手法とは根本的に異なることが分かります。LLMは単なる機械学習の延長ではなく、全く新しいパラダイムを提供しています。この新しいアプローチでは、迅速なプロトタイピングと継続的な改善が可能になる一方で、出力の予測可能性や制御の難しさという新たな課題も生まれています。
LLMプロダクトや機能開発の特徴
LLM（大規模言語モデル）を活用したプロダクトや機能の開発は、従来のソフトウェア開発や機械学習とは大きく異なる特徴を持っています。これらの特徴を理解し、適切に活用することが、成功するLLMプロダクトの開発には不可欠です。
1. 迅速なプロトタイピング
LLM開発の最も顕著な特徴の一つは、従来の機械学習系の開発と比べて、驚くほど迅速にプロトタイプを作成できることです。
従来の機械学習系の開発では、個別にモデルを開発する必要があったため、最初に動くものを作るまでに相当な時間と労力が必要でした。
LLMの場合、LLMが汎用的にたようなタスクに対応できたり、多くのLLMプロバイダーがAPIを提供しているので、適切なプロンプトと少量のコードで、複雑な機能を持つプロトタイプを数時間、場合によっては数分で作成できます。
この迅速さにより、アイデアを素早く検証し、ユーザーフィードバックを早期に得ることが可能になります。
ただし、この迅速さゆえに、プロトタイプの完成度と本番環境での実用性を混同しないよう注意が必要です。
例えば、こういった記事を自動生成するプロダクトor機能を考えてみましょう。
ChatGPT等でプロンプトをゴニョゴニョすれば人によっては数分で記事を自動生成するプロンプトを生み出せると思います。
従来ならモデル開発のためのデータ収集から必要だったのでとても迅速にプロトタイピングが作れるようになりました。
2. 柔軟な出力と「バグ」の概念の変化
LLMの出力は高度に柔軟で、時に予測不可能です。これは従来の「バグ」の概念を大きく変えます。
従来のプログラミングでは、予期せぬ出力は明確に「バグ」として定義されていました。
LLMでは、同じ入力に対して毎回異なる出力が生成される可能性があり、これは必ずしも「バグ」ではありません。
代わりに、出力の質、一貫性、適切性、創造性などが評価の基準となります。
この特性により、開発者はエラーハンドリングよりも、出力の品質管理と改善に注力する必要があります。
先の記事の自動生成の例だと、とある入力に対して正しく記事が生成されたとしても、入力を変えたときに同じように記事が正しく生成されるとは限りません。これをバグと捉えるてしまうとリリースが遠くなってしまいそうな気がしますね。
3. 継続的な改善と評価の重要性
LLM開発では、初期のプロトタイプ作成後も継続的な改善と評価が極めて重要です。
従来の開発では、要件を満たせば「完成」と見なされることが多かったです。
LLM開発では、モデルの出力を常にモニタリングし、フィードバックを基に継続的に改善する必要があります。
この過程には、プロンプトの調整、ファインチューニング、出力のフィルタリングなどが含まれます。
継続的な改善は、LLMの性能向上だけでなく、新たな用途や機能の発見にもつながる可能性があります。
プロダクトや機能の評価に関しては以下の記事が参考になります。
先の記事の自動生成の例でもどの状態を「完成」と呼ぶのかは人によってしまうと思います。良さげか否かの判断も人によるので、軸を定めない限りは一向に「完成」しません。
4. ユーザー体験（UX）の重要性
LLMを用いた製品では、技術的な性能とユーザー体験のバランスが特に重要です。
LLMの柔軟性と創造性は、ユーザーに新しい体験を提供する可能性を秘めています。
同時に、予測不可能な出力は、ユーザーを混乱させる可能性もあります。
したがって、LLMの能力を最大限に活用しつつ、ユーザーにとって理解しやすく使いやすいインターフェースを設計することが重要です。
ユーザーフィードバックを積極的に収集し、LLMの出力とユーザーの期待のギャップを埋めていく努力が必要です。
LLMプロダクトのUXに関しては以下でも弊社のメンバーがnoteを書いています。
これらの特徴を理解し、適切に対応することで、LLMの潜在能力を最大限に引き出し、革新的で価値あるプロダクトを開発することが可能になります。従来の開発手法にとらわれず、LLMの特性に適した新しい開発アプローチを採用することが成功への鍵となるでしょう。
冒頭のツイートでは、軸の定義をあえて曖昧に書いたので誤解を生むこともあったかと思いますが、
要するに従来のように、要件を満たし、バグがなくなれば「完成」と考える"完成度"の軸において、LLM開発は時間の経過に対する完成度の進み方が異なってくるよね、ということが言いたいわけでした。
そもそも「完成」に関する考え方を改める必要があるということです。
LLM開発における新たな課題
LLM（大規模言語モデル）を用いた開発は、多くの可能性を秘めている一方で、従来の開発とは異なる新たな課題も生み出しています。これらの課題を理解し、適切に対処することが、成功するLLMプロダクトの開発には不可欠です。
1. 進捗の可視化と報告の難しさ
LLM開発では、従来の開発手法で用いられてきた進捗管理や報告の方法が必ずしも適していません。
従来の開発：機能の実装状況や完了したタスクの数で進捗を測定。
LLM開発：機能の「完成」が曖昧で、継続的な改善が必要。
このため、以下のような課題が生じます：
上層部や利害関係者に進捗を説明する際、「進んでいないように見える」という誤解を招く可能性がある。
従来の進捗報告方法（例：ガントチャート、バーンダウンチャート）がLLM開発の実態と合わない。
解決策として、例えば以下のようなアプローチが考えられます：
出力品質の向上や、ユーザーフィードバックの改善など、質的な指標を重視した報告方法の採用。
短期的な目標と長期的な改善計画を明確に区別し、それぞれの進捗を別々に報告する。
2. 従来の開発マインドセットからの脱却
多くの開発者や管理者が、LLM以前の開発経験や知識をベースに判断を下そうとするため、以下のような課題が生じます：
LLMを従来の機能開発の延長線上にあるものとして扱い、その独自の特性を活かしきれない。
従来の「完璧な製品を作ってからリリース」という考え方が、LLM開発の迅速な反復サイクルを阻害する。
LLMの柔軟性や創造性を、従来のシステムの「不安定さ」や「バグ」と混同してしまう。
これらの課題に対処するためには：
チーム全体でLLMの特性と可能性について学習し、共通理解を形成する。
「完璧」を目指すのではなく、「十分に良い」状態で早期にリリースし、継続的に改善していく文化を醸成する。
LLMの出力の多様性を「特徴」として捉え、それを活かす方法を探求する。
3. ユーザーフィードバックの重要性と収集方法
LLM開発では、ユーザーフィードバックが特に重要ですが、その収集と解釈には独自の課題があります：
LLMの出力が多様であるため、ユーザーの体験も多様になり、一般化が難しい。
ユーザーの期待値が従来のシステムとは異なるため、フィードバックの解釈に注意が必要。
LLMの改善サイクルが速いため、タイムリーなフィードバック収集が求められる。
これらの課題に対処するためにはの一例：
定量的データ（使用頻度、滞在時間など）と定性的データ（ユーザーインタビュー、アンケートなど）を組み合わせた多角的な評価方法の採用。
リアルタイムフィードバック機能の実装（例：各出力に対する「親指アップ/ダウン」ボタン）。
ユーザーの期待値や満足度の変化を継続的に追跡し、LLMの進化に合わせて評価基準を調整する。
加えて、どのバージョンに対する評価なのかが明らかになっていることも重要と考えます。リリースサイクルによっては、例えば本番のシステムプロンプトと開発中のシステムプロンプトが大きく異なってしまう可能性もあり、すぐにフィードバックデータが意味をなさなくなってしまいます。
4. テストと評価指標の重要性
LLM開発においては、従来の開発以上にテストと評価指標の設定が重要です。
従来の開発：初期段階ではスピードを優先し、テストカバレッジを犠牲にすることもありました。
（個人的にはt-wadaさんの質とスピードのお話も大好きでこの選択はなるべくしたくない派です）LLM開発：テストケースや評価指標を事前に定めることが極めて重要となってきます。
LLMにおいては出力が厳密に定義されていないため、従来のTrue/False形式のテストは適さず、スコア形式の評価が一般的となります。
またテストケースなしでのリリースは、コンパスなしで大海原へ出航するようなもので迷子になってしまうケースが往々にしてあると思います。
テストと評価指標を設定することの利点：
意図に沿わない出力に対する対応の優先順位付けが可能になる。
「やらないこと」を決める基準となる。
継続的な改善の方向性を示す指針となる。
評価指標に基づくアプローチ例：
定めた評価指標が基準を満たしている場合は対応不要と判断することもできる。
評価指標自体や基準の見直しが必要かを検討するのも必要。
このアプローチにより、無駄な対応を減らし、効率的な開発と改善が可能になります。
再掲ですが、LLMプロダクトの評価に関しては以下の記事がとても参考になります。
これらの新たな課題に適切に対応することで、LLMの潜在能力を最大限に引き出し、革新的で価値あるプロダクトを開発することが可能になります。従来の開発手法や考え方にとらわれず、LLMの特性に適した新しいアプローチを積極的に採用していくことが、成功への近道となるでしょう。
まとめと宣伝
LLM（大規模言語モデル）を用いた開発は、ソフトウェア開発の新たなパラダイムをもたらしています。従来の開発手法や機械学習とは大きく異なる特性を持つLLMは、私たちに新たな可能性と同時に新たな課題を提示しています。
LLM開発の成功には、これらの特性や課題を十分に理解し、適切に対応することが不可欠です。従来の開発手法の良さを活かしつつ、LLMの特性に合わせた新しいアプローチを積極的に採用することが重要です。
また、LLM開発はテクノロジーの進化だけでなく、組織文化や開発プロセスの変革も必要とします。迅速な反復、継続的な学習、そしてユーザーとの密接な対話を重視する文化を醸成することが、LLMを活用した革新的なプロダクトの開発につながるでしょう。
弊社Algomaticではこういった既存サービスへのLLM機能の導入や、LLMを使った新サービス立ち上げの伴走支援サービスもやっておりますのでもしご興味ある方はお問い合わせください。
また、LLM技術は日々進化しています。開発者やプロダクトマネージャーは、常に最新の動向をキャッチアップし、自身のプロダクトやプロセスを柔軟に適応させていく必要があります。LLMがもたらす可能性は計り知れません。この新しい技術を正しく理解し、適切に活用することで、これまでにない価値を持つプロダクトを生み出すことができると思います。
ちなみに、そんな最新の動向のキャッチアップを全メンバーが息を吸うようにやっている会社があります。
そう、弊社Algomaticです。
本記事では従来のIT事業会社がLLMを使い始めるに知っておいてほしいことといった観点で思考を書きました。
弊社は生成AIネイティブにさまざまなサービスを作ろうという目的で集まっているので、上に書いたような思想は全員が持っています。
生成AIを使ったサービスをどう世の中に届けるか、といったところに集中したい！といった方にはとっても魅力的な環境だと思います。
ビビッときた方は以下に採用情報を載せておきますのでぜひお話ししましょう！
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？