見出し画像

LLMを使ったtoCプロダクト開発って具体的に何するの？(エンジニア編)

kiiita

現在、LLM(OpenAI API)を活用したプロダクトを新規立ち上げ中なんですが、LLMを使うと言っても実際にどんな開発をするのかイメージがつきづらいかと思います。

「LLMを使った開発に興味は多少あるんだけど、実際にプロダクトに導入していく場合にどんなことをするの？」という質問をちょこちょこいただきます。

加えて、LLMを活用した新規事業/新規機能は、現状だとtoBのプロダクトが多いですが、我々の場合はtoCのプロダクトを開発しているため、事例も少なく、開発内容のイメージがつきづらいかもしれません。

プロンプトエンジニアリングのようなことをやるのか、LLMのAPIを使って何かゴニョゴニョやるのか、モデルのfine-tuningをやるのか…よくわからないですよね。

私たちが今開発しているLLM x 求人検索のプロダクトで、LLMを使ってどのような開発をしているのかをお伝えできればと思います。

やりたいことがたくさんあるので、LLMに興味がある方はぜひ一緒にやりましょう！まずはカジュアルにお茶やZoomでも😀


前提

前提として、LLMを使ったプロダクト開発は、エンジニアリングを始め、UIデザインやユーザー体験のベストプラクティスやロールモデルがまだまだありません。

各方面、手探りで仮説検証を繰り返して行って、自分たちでベストプラクティスを見つけに行くイメージが近いです。

Illustrated with Midjourney

もちろん、システム開発においてはLangChainのような参考にできるライブラリがでてきていますが、サービスに組み込んだ時のベストプラクティスはわかっていません。

今立ち上げているプロダクトの開発メンバーも、今年になってからLLMをキャッチアップし始めたばかりなのでほぼ素人です。

なので、右も左もわからない事が多いけど、自分たちで色々試してベストプラクティス見つけにいくのが楽しめるフェーズかなと思います。

チームメンバーでも「ああじゃないかこうじゃないか」を相談しながらなんとか前に進めて行ってる感じです。

前置きが長くなりましたが、私たちのチームのエンジニアがやってきたこと・これからやることを具体的にご紹介します。

LLMの出力精度を最大化する設計と技術選定

最初から少し抽象的な話になりますが…

今回のプロダクトにおいては、LLMをフル活用し、そこから得られる出力の精度を上げることがIssueの効果的に解決に直結すると考えています。

要件・仕様が肥大するにつれ、「機能Aの精度は良くなったけど機能Bが悪くなった」といったことが起こ得ます。これを両方の精度を担保できる設計や技術選定がかなり重要ではないかと感じています。

また、Issueを解決するにあたり「方法Xだと要求の70%くらいまでは実現できるが、方法Yを使えば90%くらいまでいけるかも。そのためにはこういうアプローチだと実現できるかもしれない」のような解決策の仮説をエンジニアが持つことで、ユーザー体験をガラリと変えられる可能性があると思っています。

設計や技術選定がLLMの出力精度に大きな影響を与えるため、そのあたりを考えるのがこのプロダクトの開発をする面白さの1つかもしれません。

では、もう少し具体的に見ていきます。

プロンプトエンジニアリング

もしかしたら先入観があるワードかもしれません。このワードは、LLMが盛り上がり始めた頃に頻繁に出てきた言葉でもありました。「あなたはプロの◯◯です」と書いて、Bot(LLM)の初期設定をするといった内容を見たことがある人も多いかと思います。

このプロンプト自体は日本語や英語のような自然言語で書くので、これまでのソフトウェアエンジニアリング・プログラミングとはちょっと違うな、と思う方も多いかもしれません。

では、ソフトウェアエンジニアとしてプロンプト関連で実際に何をやるかというと、自然言語でプロンプトを書くこと以外にやることが結構あります。

前提として、プロンプトの精度を上げることがユーザー体験の向上に直結するので、プロンプトの精度を上げる必要があります。ただ、上述の自然言語で書いたプロンプトを修正するだけでは精度の改善には限界があります。

そこで、プロンプトの精度を上げるために必要になるのが、OpenAI APIの処理の最適化です。

具体的には、APIをリクエストする適切なタイミングを模索したり、消化token数が増えてきた時にtokenの処理を節約する等です。

実例を挙げると、今開発中のプロダクトでは次のような箇所でプロンプトを使っています。

  • キャラクター設定

  • 検索クエリ生成

例えば、検索クエリ生成に関して日本語でプロンプトを書き、それをAPIに投げるだけでは求める精度に至りません。

そこで、プロンプトの改善はしつつも、この処理をするタイミングや順番を工夫することで精度を上げることができます。

この辺はエンジニアとしても楽しめるポイントのうちの1つなのかな、と思います。

Chat APIを使った対話システムの設計

チャットUIのサービスなので、以下のような開発をしています。

  • APIの制約に応じた要件の実現方法の模索

  • 利用token数と要件実現のバランス調整

  • プロンプトが長い場合・token数が増えてきた場合の要件実現方法の模索

  • ユーザー情報(長期記憶)を利用した対話UXの改善

ChatGPTを使った時に経験したことがある方もいるかもしれませんが、チャットが長くなればなるほど以前話した内容が忘れられて、またこちらから伝えないといけないといったことがあります。

この原因の1つに利用できるtoken数(≒文字数)の上限制約があります。あまり工夫せずに実装すると、token数に収まらない部分は処理されず、結果として対話の精度が少し落ちたりします。

また、上述のプロンプトもtoken数にカウントされるので、プロンプトを長くしすぎると対話に使えるtoken数が減ったり、プロンプトの精度が落ちたりします。

なので、上限制約がある中でユーザーの体験がよくするための設計が必要になります。

解決方法は模索中ですが、利用目的によってAPIで使うモデルを分けてtokenを分散させたり、対話の内容をchunkに分割して要約を繰り返すことで重要な部分の記憶を保持したり、ユーザーのメタデータをうまく活用することで対話のショートカットをしたり等があります。

Function Calling

今開発しているプロダクトではFunction Callingを導入しています。

次に挙げる例は、既に導入しているものとこれから使ってみたいと思っているものが混在していますが、Function Callingを使える部分はこんなイメージです。

  • 検索

  • 要約

  • アクション候補の提示

  • 推薦理由の提示

  • 検索クエリ生成

様々な処理においてFunction Callingを活用できそうだなと思いつつ、Function Callingで呼び出せる関数をたくさん用意してしまうと、呼び出す関数の選定で精度が落ちたりします。

これがプロダクトに組み込んでいくリアルな難しさなのかなあと思います。チュートリアルや簡単なデモの場合、要件の複雑度は低いです。

一方、プロダクトの場合は徐々に要件が増えていくので、その中でOpenAIのAPIをどう使っていくのか、どうすれば出力の精度を担保しながらスケーラビリティのある設計にできるのかを模索する必要があります。

Embedding

OpenAIのAPIのうちの1つにEmbeddingがあります。比較的カジュアルに使えるため、この機能を活用してユーザー体験を底上げできないかチームで探索中です。

LLMやその機能ドリブンでのプロダクト開発は、プロダクトアウトなので本質ではないとよく言われますが、それは理解しつつも「このIssueにはこの技術が最適だ」という連結部分を担えるのが、LLMを使ったプロダクトの面白さだと思います。

Notionのプロダクトボードに貼られたIssueを眺めながら、「あ、このIssueだったらこの技術使ったら割といい感じに解決できるのでは？」という視点を持てるのはエンジニアだからこそだと思っています。

つまり、技術がユーザーのIssue解決に大きな一役を担う可能性が高いプロダクトだと思っています。

運用系

その他にも運用面で対応すべきことも多々あります。例えば次のようなものです。

  • インジェクション対策

  • Rate limit対策

ユーザーが悪意のある値をチャットで送信し、プロンプトに何らかの操作を加える可能性があるので、その対策をしたり、APIのリクエスト数やtoken数に上限があるので、APIを分散させる設計をしたり、1ユーザーがめちゃくちゃtokenを使ってコストが無駄に使われないように制限をするなど、色々と対策が必要です。

DevOps / LLMOpsの改善

Illustrated with Midjourney

LLM関連プロダクト開発における大きなテーマの1つだと思っています。

LLMを使ったプロダクトの特徴として、Input/Outputの種類が膨大である点が挙げられます。つまり、テストにかかるコストがこれまでに比べてかなり大きくなります。

これから改善していきたいねとチームで話しいるのは以下のような点です。

  • プロンプトエンジニアリングの開発効率を改善するための仕組み・基盤づくり

  • CI/CD

  • 分析基盤作り

  • LangSmithのようなライブラリの利用検討

このあたりの仕組みづくりは開発効率だけではなく、プロダクトの品質にも直結するので、結構大きなテーマと認識しています。

R&D

その他にも、まだ技術検証があまりできていないけど試してみたい！みたいなトピックもたくさんあります。例えば以下のようなものです。

  • AI Agent

  • LangChain or not

  • Fine-tuning

冒頭にも書きましたが、次々と出てくる新しい技術をキャッチアップしつつ、Issueに対して使えそうなものを色々試していきたいと思っています。

LLMに興味があり、実際にプロダクト化する過程に関わってみたいという方はぜひ一緒にプロダクトを作りましょう！

下記タイトルはフルスタックとありますが、フロント/サーバー/AI,MLのいずれかの経験があって、LLMに興味がある方であれば問題ないです。

フルリモート、フルフレックスで働いているチームになります。

Twitterはこちら: @kiiita


この記事が参加している募集

#仕事について話そう

110,545件

この記事が気に入ったらサポートをしてみませんか？