LLMを利用したサービス開発におけるポイント

LLMを用いたサービス開発におけるプロンプトチューニング、設計・実装、モデル選定、精度評価、監視の重要性と具体的な方法について解説しています。開発効率化や不具合低減のための新技術導入の重要性も強調されています。

現在では、サービスのあらゆる場面でLLMを用いて開発する機会が増えていることと思います。
LLMを利用したサービス開発における基本的なポイントについて記載しましたので、参考にしていただければと思います。

プロンプトチューニング

LLMを利用するにあたり、プロンプトとして誤解が無いように指示を書かなければならないため、仕様を言語化する必要があります。

例えば、「月末の天気を出力して」と命令する場合、月末とはどこの期間を指すのか、出力は該当するすべての日の天気をリストで出すのかなど多くの曖昧さが内在します。 LLMは曖昧な命令でも答えてくれることが良いところでもありますが、曖昧に書き過ぎてしまうと意図しない挙動になる可能性が高まるため、仕様を議論し可能な限り明確な言語化をしておくことが重要です。

また、プロンプトチューニングでどこまで精度を高めることができるのかがわからないという問題もあります。小学生にどんなに教えても、大学の問題は解けないように、プロンプトチューニングをいくら頑張っても達成できない精度があります。チューニングをしていく中で解決できる限界ラインの感覚を掴み、開発チーム間で共有することがスムーズな開発に繋がると思います。

また、過度にチューニングに頼るのではなく、ロジックで解決できる部分は基本的にコーディングでカバーし、そうでないところだけをLLMに任せるような分担も重要です。

設計、実装

LLMを利用するためのライブラリが次々と出てきていますが、構築しているシステムがそうしたライブラリを活用できる環境（プログラミング言語、システム設計など）かどうかも大事な視点です。

例えば、チャットボット開発であれば、LangChainのライブラリを使用できるPythonを使用するなどの選択が考えられます。

新出のライブラリや技術が使用できるかどうかは開発効率化や不具合の低減、新規機能の導入などに繋がるため、世の中の流れに置いていかれないためにも、新たな技術を取り入れやすい環境の検討、設計思想は特に重要になります。その他には、LLMは必ずしも命令通りに動くとは限らないため、意図しない挙動をした時のハンドリングも考える必要があります。指示通りの応答ができていない場合にエラーとしてハンドリングしたり、不適切な応答をした場合にガードレールを行う仕組みを構築することになります。

モデル選定

新たなLLMモデル開発が非常に盛んなため、バージョンアップや新モデルリリースが頻繁に行われます。

それ以外にも古いバージョンが廃止になったりすることもあるため、クラウドLLMを利用する場合は、モデル切り替えが不可避になってきます。そのため、モデルの切り替え判断や切り替え実装の作業が度々発生します。

切り替え判断を素早く行うためには、精度を定量的に自動評価できる仕組みづくりが大切です。ただし、複数のモデルを平等に評価するためにはどうしたら良いかという難しい問題があります。

プロンプトが意図せず特定のモデルに理解しやすい表現になっている可能性があるため、同一のプロンプトで複数のモデルを評価することが必ずしも平等とは言えません。
そのモデルにおける最適なプロンプトにチューニングして比較することが平等だと思いますが、最適にチューニングできているか判断することは現実的に不可能なため、どこかで折り合いをつけて比較する必要があります。
同一のプロンプトで比較し、速度に関しては単純な比較、精度に関してはポテンシャル（チューニングでどれくらい精度が上がりそうかの見込み）を含めて比較するのが現実的かと思います。

また、切り替え実装に関しても、システムの実装がモデルに過度に依存しないように、共通のインタフェースを間に挟む実装にすることで、実装量を減らすような工夫をすると良いと思います。

新たなモデルに置き換えを検討する前に、システムで使用が前提になっている機能がそもそも利用できるモデルかどうかの確認も必要です。

例えば、構造化出力はすべてのモデルで対応していないことがあるため、構造化出力が必須なシステムであれば、選定の土俵にも上がりません。その他にもパラメータやコンテンツフィルタの仕様などもモデルによって差異がある可能性があるため、あらかじめ公式のページを確認することをお勧めします。

また、クラウドの場合、新モデルのリリースされているリージョンが限定されている場合があり、遠方のリージョンのみの場合モデルの速度に影響を与える可能性があるため、リージョンが増えてきてから本番環境に切り替えるといった判断も必要かもしれません。

一つのクラウドLLMに依存すると、障害があった場合にシステムが機能しなくなってしまうため、他のクラウドのLLMも切り替えられるようにしておくリスク管理も検討しておくのが重要です。

精度評価

期待値を正確に決めることができるのであれば、期待値との一致テストを作成すれば良いですが、LLMには応答のぶれがあるため、期待値を決めることが難しい場合があります。
そのような場合は、特定のキーワードを含んでいればOKとしたり、LLMに点数をつけさせて評価させるといった方法（LLM as a judge）があります。
テストデータの作成に関しては、対話のケースをすべて網羅することはできないため、重要なケースに絞ってテストを作成し、運用テストの中で出てきた不具合例をケースを随時テストデータとして追加していくのが現実的に思います。

また、一度の自動テスト実行にどれくらいの時間とコストがかかるのかも把握しておくことも大切です。テストデータが増えてきた場合は、並列実行するなどでテスト時間を削減する工夫が有効です。ただ、APIの場合はrate limitがあるため、無制限に並列化することはできず、リソース配分の調整も課題になってきます。

監視

プロンプトチューニングや機能追加を行うと、知らず知らずのうちにトークン量が増えていたり、精度や応答速度が落ちていたりすることがあります。同一のインプットに対して、トークン量や精度、応答速度の変化を定期監視したり、実装修正前後で精度比較を行ったりしておかないと、何が原因で今の状況になっているのかのトレースがし辛くなってしまいます。開発チーム全体で、動作を監視する重要性の意識を持って取り組むことが大切です。