`Building LLM applications for production`を読んだ

最近は本業でも趣味でもLLMが自分の時間の多くを占めるようになってる。
LLMアプリケーション for プロダクション、何だかんだ考えることが多くて大変だな〜というので参考としてBuilding LLM applications for productionを読んだ。

感想としては記事の冒頭と最後にあった↓が全て。hard to make something production-ready with them。

・It’s easy to make something cool with LLMs, but very hard to make something production-ready with them.
・LLM limitations are exacerbated by a lack of engineering rigor in prompt engineering, partially due to the ambiguous nature of natural languages, and partially due to the nascent nature of the field.

We’re still in the early days of LLMs applications

引用: Building LLM applications for production

プロンプトエンジニアリングの曖昧さによる難しさ

Part1では、プロンプトエンジニアリングをプロダクションで行う難しさについて書かれてる。
雑に述べると、プログラミング言語と比べて、プロンプトエンジニアリングの柔軟さが開発者に取っては辛いという話。

柔軟さにはユーザーが出す指示の柔軟さととLLMが指示をどのように対応するかの2パターンがあると指摘している。
特に辛いのは後者。出力形式が曖昧である・必ず想定通りの形式で出力されないことはアプリケーションでのハンドリングを難しくさせる。

自分もこの点は一番悩まされてる。どうしても想定外の出力ケースが発生してしまい、それをどう回避するか、軽減するかに時間を使った。

同様に、出力の曖昧さにより引き起こされる可能性があるのは、ユーザーザーエクスペリエンスの不整合。
ユースケースやアプリケーションにもよるが、同じ入力で同一の出力が返ってこない場合に不都合あるケースは普通に存在する。
記事では、保険会社の見積もりを例に挙げているが、確かに入力は同じだが毎回見積もりが違うと、信用も何もあったものではない...

個人的には記事で言及されている以下一節で「なるほどね...」という気持ち。
可能な限り厳密にする工夫やユースケースやUXの工夫で軽減することは、きっとLLMアプリケーションを作る上での一つの工夫する領域や勘所な気はしてるのでやっていきではある。そして今後進展や進化はあるだろうと思うので期待。

A couple of people who’ve worked with LLMs for years told me that they just accepted this ambiguity and built their workflows around that.

引用: Building LLM applications for production

後は、プロンプトにはコードほど後方互換性がなかったり、属人性の問題を抱えるかもという話が。
モデルは進化したとしても、当該アプリケーションにとっては都合の悪い挙動の変更が起こり得る。 そして複雑なプロンプトは属人的になってしまうかもしれない。

後方互換性の話は、「as a 〇〇」が無効化されたらどうするんだ？という指摘。
自分もPromptBaseや有料で販売されてるプロンプトを買い漁ったりしてるけど、あるあるのas a系がダメになるかもしれないと考えると非常に悲しい。　 とはいえ本当に起きるか？はわからない。まだシンプルに事例がなくあり得るかもねという話で現実的にこれが起こったわけではないと認識してる。ので最終的にはそこまで心配する話ではないかもしれない。

プロンプトテクニック

Part1では、厳密性を高めるプロンプトの工夫についても紹介されてた。

• プロンプトの評価
• プロンプトの最適化

言って仕舞えば、few shotやりましょうという話。
プロンプトの評価に関しては、few shotが適切に行われているかを確認するのは大事。

- LLMがプロンプトで与えられた例を理解できているか
    - 同じ例を入力し、モデルが期待通りのスコアを出力するかどうかを確認する
    - プロンプトで与えられた同じ例でモデルがうまく動作しない場合
        プロンプトが明確でないことが原因である可能性が高い
        - プロンプトを書き直すか、タスクを小さなタスクに分割する   

引用: Building LLM applications for production

後はラベル付与のタスクをさせたい場合に、先にLLMに「4」というスコアを与えるようなテキスト例を挙げてもらい、これらの例をLLMに入力し本当に4が出力されるかどうかを確認するというtipsが書かれていた。

加えて、プロンプトのバージョニングとアウトプット精度の追跡が大事だと。
(ABテストやunit testやりたい)

プロンプトの最適化は、色んな論文やテクニックがあるが、何よりもOpenAI Cookbookを読むのが良い。 openai-cookbook

something newはないが、Chain-of-Thoughtや同じ入力に対して複数の応答を生成する、プロンプト分割するなどのテクニックが紹介されている。

コストとレイテンシー

コスト

より厳密性や複雑なタスクをこなそうと思えば思うほど、プロンプトあたりのコストは増加する。高性能なモデルを利用しても同様。

とはいえ、今までのMLで同様のことを実現するコストやリードタイムを考えると破格だと捉えるのが良いんだとは思ってる。
本業でも趣味でも、OpenAIがAPI提供しなければ作ってみようとも思わないし、そもそもMLエンジニアを採用するところから始めることになっていたのは想像に難くない。

As a thought exercise, in 2021, DoorDash ML models made 10 billion predictions a day. If each prediction costs $0.004, that’d be $40 million a day!

引用: Building LLM applications for production

とはいえこれは高いなーとは思う。これぐらいは普通なのかしれないが。。

レイテンシー

シンプルにAPI遅いよね...という話。
数秒は覚悟しないといけない。LLM使った開発を本格的にやり始めたらローディングの待ち時間を無駄に思うことが増えて、ローディング中に出来るミニゲームが流行るのではと思う程度にはローディング待ちしてる。

とはいえ記事では、今議論してるコストとレイテンシーの問題はすぐに時代遅れにだろうと指摘している。
ScribdのシニアマネージャーであるMatt Ross氏のユースケースにおいては、APIコストの見積もりは、この1年で2桁下がり、レイテンシーも大幅に減少しているようだ。

Similarly, many teams have told me they feel like they have to redo the feasibility estimation and buy (using paid APIs) vs. build (using open source models) decision every week.

引用: Building LLM applications for production

この辺りの進化の速さは一定頭に入れないと、判断を誤る可能性があるのはわかる。
コストとレイテンシーに限らず、LLM周りは最高にアメージングスピード。ビジネス向けChatGPTクローンをリリースする企業もあったが、数ヶ月で本家がビジネス用途向けを発表するという。

Prompting vs. finetuning vs. alternatives

プロンプトとファインチューニングの使い分けについて。 ファインチューニングの利点は以下二つ。

• モデル性能向上
• 予測にかかるコストを削減

記事では使い分けの判断に3つの観点を提示している。

• データの可用性
• パフォーマンス
• コスト

当然few shotで十分な場合はファインチューニングは不要かもしれない。
プロンプトに含められる例題では十分でないのであれば、ファインチューニングを組み合わせなければならない。プロンプトにはトークン制限がある。それも今後緩和・問題にならなくなる方向には進むんだとは思うが。

ファインチューニングに当たって必要な例題の数の目安として、記事では100個ほどで顕著な変化を期待することができると書いている。
そして一般的な傾向として、例数を増やすとプロンプトよりもファインチューニングの方がモデル性能が良くなるし、モデルの微調整に使用できる例数に制限はない。

個人的には今はプロンプトで可能な範囲で頑張ること割り切っていて、ファインチューニングは遊びで触ってる程度。
が遅かれ早かれ独自データを用いたファインチューニングには業務では挑戦するはず。
インフラやモデルを持たないアプリケーションレイヤーの企業にとって、自社が保持する独自データの活用は確実に差別化ポイントの一つ。とはいえアプリケーションレイヤーがどうなるかはまだよくわからない、乞うご期待だと思ってる。
Who Owns the Generative AI Platform?

プロンプトチューニング

プロンプトとファインチューニングの中間に位置するクールなアイデアとして提示されているのがプロンプトチューニング。

Starting with a prompt, instead of changing this prompt, you programmatically change the embedding of this prompt.

引用: Building LLM applications for production

らしい。プロンプトチューニングは記事を読むまで全然知らなかった。

For prompt tuning to work, you need to be able to input prompts’ embeddings into your LLM model and generate tokens from these embeddings, which currently, can only be done with open-source LLMs and not in OpenAI API. On T5, prompt tuning appears to perform much better than prompt engineering and can catch up with model tuning

引用: Building LLM applications for production

詳細はこれから以下論文を読む
https://arxiv.org/abs/2104.08691

その他

その他にも、stanford_alpacaの話やEmbeddings + vector databasesが取り上げられてる

Part2: Task composability

複数のタスクで構成されるユースケースを実現することの難しさについての章。
LangChainのAgentsを作ったとして、一連の動作を想定通り動かす and 精度上げるにはどうしたらいいのかという話だと理解してる。
真面目にLangChainでAgentsを使ったツールを書いてて思うが、精度や制御を徹底することの難しさは感じる(自分がtipsを知らないだけなのかもしれないが)

すべてのタスクが正しい結果を出すが、全体的な解答は正しくない事象を「コンポーザビリティ・ギャップ」と呼ぶらしいが、各々のTools・タスク間の挙動は問題なくとも、組み合わせやその順序による絶妙に噛み合わない可能性もあり得る。
ReActなんかは本当に新しいソフトウェアの形を感じて、これからどれだけ浸透するのかはわからないが面白そうな領域というのは素直に思う。
(とりあえずReactとGoogle検索結果で戦えるようになったらすごい)

提案としては、コントロールフローだけでなく、各コンポーネントをユニットテストすべきだし、各コンポーネントで、（入力、期待出力）のペアを評価例として定義し、プロンプトやコントロールフローを更新するたびに、アプリケーションを評価すべきだと述べている、アプリケーション全体の統合テストも行えると。

Part 3. Promising use cases

どのようなユースケースが有望なのか？についての章。
存在知らなかったのでハッカソンのシートが共有されてるのはめちゃくちゃ参考になって嬉しい。
GPT-4 Hackathon Code Results Langchain Gen Mo Hackathon

記事で取り上げられているユースケースは以下

• AI assistant
• Chatbot
• Programming and gaming
• Learning
• Talk-to-your-data
• Search and recommendation
• Sales
• SEO

全部面白そうだが、本業においてはTalk-to-your-dataとSearch and recommendationとSales。
個人的関心においては、AI assistantとLearning。
Programming and gamingはもはやエンジニアとしての必須科目感で、SEOはさらに信用できないコンテンツに溢れる世紀末感。

個人的には、そろそろWindowsのイルカのイメージを払拭するアシスタントをプロダクトに組み込めるだろう..というのはやりたみがある。

終わり

学びも多く良い記事だった。頷ける点もたくさん。
そして本当に↓の通りだなと改めて。

We’re still in the early days of LLMs applications

However, given so much happening, it’s hard to know which will matter, and which won’t.

引用: Building LLM applications for production