🤞

LLMプロダクト開発の勘所

2024/12/24に公開

メリークリスマス!(公開当日でないみなさま、こんにちは!)
株式会社ココナラ AI・LLM推進チーム所属の大瀧です。

2022年11月30日にChatGPTが公開されてから2年が経過し、プロダクト組み込みにおける問題などが語られるようになってきた頃合いだと思います。

ココナラのエンジニアリングチームも積極的にLLMを使った機能開発を行い、大小さまざまな成功失敗を経験してきました。

この記事では「未開拓な領域で私たちが学んだこと」をまとめて、皆さまに向けたクリスマスプレゼントとしてお届けします。

「普段、機械学習を触らないエンジニアさん」を想定読者として書いていますが、機械学習を普段から触る方にも喜んで頂けたらうれしいです。

※普段から機械学習を触る方はお気付きだと思いますが、この記事タイトルは「あ かんところ 対策の共有」と読み替えられます。

株式会社ココナラアドベントカレンダー24日目の記事です。
https://qiita.com/advent-calendar/2024/coconala_engineer


LLMを使った機能の開発では、フェイズごとにさまざまな問題が発生します。

ココナラに入社する以前の内容も含めて、発生する問題 + 対処方法という形でまとめてみました。

何かの形で、皆様のお役に立てばうれしく思います。


ヒアリング・要件定義フェイズ

問題:期待値コントロールに失敗し、工数を溶かしてしまう

  • 他社の話を伺っても、LLM API利用プロジェクト失敗要因のうち、かなりの割合を占めているように見えます
  • 特にLLMを触り始める方は要注意で、企画者/実装者本人の期待も過度に高くなっていることがあります

💊対処方法:目が輝かなくなるまで、LLMを触る

  • もしもLLMをあまり触ったことがないのであれば、まずは触り倒しましょう
  • ある程度触れば、すぐに思い通りでない出力が得られ、失望に似た感情が生まれるハズです。そこが、本当のスタート地点です
  • これは私個人のモットーですが、目が輝かなくなって初めて冷静な判断ができます。まずは目が輝かなくなるまで触りましょう

問題:レスポンス速度がUX設計の勘定に入っておらず、大きな手戻りが発生する

  • モデルや入出力の大きさによっては、LLM APIから結果を取得するまでの時間が思ったよりも長くなることがあります
  • 何かを入力したら即結果が得られる前提で機能を設計してしまうと、いざ動作を確認するぞ!と触ったタイミングで大きめな手戻りに繋がる可能性があります

💊対処方法:試作フェイズで、レスポンス速度を計測する

  • どうしてもレスポンス速度を速くする必要がある場合は、小さなモデルを利用したり、入出力を小さくするなどの工夫を講じる必要があるかもしれません
  • Stream処理にすることで、体感の待ち時間を短くできる場合もありますが、ユーザーが次の行動に移るまでの待ち時間は変わらない点には注意が必要です
    • 作った機能がどれだけかわいくとも、シビアに評価しましょう。エンジニアは特に、BOTやAIに優しく接しがちだと言われています

問題:出力に失敗すると破綻するUXになっており、リリース後に改修工数が発生する

  • さまざまな理由で、LLM APIは失敗します
  • 失敗の形もさまざまで、リソースが確保できなかった、Rate Limitに到達した、返したけど想定外の値になっているなどなど...
  • 失敗時にアプリケーションが停止しないのはもちろん、失敗時にも動作するUXを設計する必要があります

💊対処方法:失敗時にも、ユーザーを不安・不快にさせないUXを設計する

  • LLM API利用有無に関わらない基本的な部分ではありますが、特に重要になるポイントだと思います

問題:APIとして提供されている内容 = Webアプリとして提供されている内容と誤解したまま試作し、プロジェクト後半に追加工数が発生する

  • 感度が高い方だと「なんてことはない」項目ですが、意外と後々発覚したりする内容です
  • 例えば「LLM APIにQiitaのURLを入力すれば、記事内容を要約できそうだ」と思っていたが、まるまるLLMが妄想した内容だった...が、後から発覚すると悲惨です

💊対処方法:LLM APIとしてどんな機能が提供されているのか、しっかり調べてから利用する

  • 外部APIを利用するならほぼ必須とも言える内容ですが、LLMが急速に普及した今、特に重要な項目だと言えます
  • 「そんな機能提供していたのか」という方向で驚くこともあるので、日々の情報収集を怠らないようにしましょう

執筆時点のSNSで、時々話題になる機能を列挙しておきます。何かの助けになれば幸いです。


試作フェイズ

問題:JSONで出力する際の性能低下を失念したまま試作し、本番で試作時の性能が出ない

  • プロダクトに組み込みやすく重宝されるJSONモードですが、推論性能が低下するという報告もあります
  • Webアプリで動作確認して実装フェイズに進んだけど、本番で精度が出ない...というのが悪いパターンで、シビアな出力品質を求める機能の場合は大打撃になります

💊対処方法:試作段階から、JSONモードで実行する

  • 身も蓋もない対処方法ですが、「動作時と、なるべく同じ条件で検証する」というのはエンジニアリングにおける奥義でもあります
  • Vertex AI Studioでは、JSONモードでの実行結果確認などが容易に行えます。とても便利です
  • 列挙した要素からの選択(Enum)を強制できるLLMについても、出力バリエーションの制限を動作ベースで確かめておくことをオススメします

問題:効率が悪い状態で試行錯誤を行い、試作に予想以上の時間がかかってしまう

  • データを取得してプロンプトを組み立ててLLM APIに投げるケースでは、意外とデータ取得部分が試作のボトルネックになることがあります
  • 試行錯誤のために頻繁に変更したい箇所以外は、なるべく処理が発生しないようにしておきたいです

💊対処方法:キャッシュやワークフロー管理ツールを利用して、試行錯誤を高速化する

  • 自前でキャッシュを作るのも悪くはないのですが、ただでさえ煩雑になりがちな試作フェイズでは、なるべく勝手に管理してくれる環境を整えておくと良いでしょう
  • 私は gokart を利用しています

問題:簡易的な推薦アルゴリズムの作成に文章生成APIを利用して、金銭コストが高くなる

  • LLMを利用して推薦を行う論文はたくさん出ていますが、金銭コストが高額になる内容だったり、実行時間が長い内容だったりが多いように思います
  • Embedding APIは安く高速ですが、短文に弱かったり、自社のプロダクトの特性上望ましくない結果になることが少なくありません

💊対処方法:関係のある文章を練り込んでEmbeddingを作成してみる

例:充電ケーブル

充電ケーブル
---
XXX社製TypeCケーブル 高耐久
YYY社製ライトニングケーブル MFI認証済み
...

番外:会社が導入しているソフトウェアとの相性問題も、時々疑う

  • これは本当にレアケースだとは思いますが、ストリーム処理部分などで問題が発生することがあります
  • 「Cloud Runは既にStream処理に対応しているのになぜ...と調査した結果、相性問題だった」を実際に経験しましたが、なかなかの調査難易度でした

運用フェイズ

問題:モデルを変更すると出力が大幅に変化し、要件を満たせなくなる

  • LLM APIは、大抵の場合モデルの提供期間が定められています
  • 凝ったプロンプトであればあるほどモデル変更時に挙動が変わる可能性が高く、モデルマイグレーション時に多くの工数が必要となる可能性があります
    • 文章を生成させている場合は品質の確認も困難で、出力にこだわっている機能の場合、マイグレーション工数は思ったよりも大きなものになるかもしれません

💊対処方法:モデルマイグレーション工数を積んでおく

  • 記事執筆時点では、モデルマイグレーションを包括的にサポートするデファクトツール・サービスは存在していないように見受けられます
  • プロンプト自動改善の仕組みをはじめとする技術動向を追いつつ、モデルマイグレーション時のコストと導入効果を天秤にかけてLLM APIの利用を検討するのが良いと思います

明日は、我らがムーさんによる「ユーザー価値提供につながる開発とは?」です。

ココナラでは積極的にエンジニアを採用しています。

採用情報はこちら。
https://coconala.co.jp/recruit/engineer/

カジュアル面談希望の方はこちら。
https://open.talentio.com/r/1/c/coconala/pages/70417

Discussion