見出し画像

noteのLLMワークフローを紹介します!!(技術選定編)

むっそ

こんにちは、note AI creativeの武藤です。

noteは毎日数万件の規模でコンテンツが集まるプラットフォームなので「この観点でLLMを使って評価できないだろうか？」という要望が多くあります。例えば下記のような要望です。

  • ビジネスカテゴリーの中で株の動向について解説している記事を探したい

  • スパムと感じられる記事をおすすめしていないかチェックしたい

  • いろんな側面でタグをつけて検索できるようにしたい

ChatGPTなどを駆使すれば下記のように簡単に記事を分類することができます。非常に便利な時代になりましたね…

# プロンプト
下記のnote記事を分類ラベル基準に従って分類してJSON出力してください。

# 分類ラベル基準
anime: アニメ関連
food: 食事関連
travel: 旅行関連
education: 教育関連
IT: IT関連
entertainment: エンタメ関連

# 出力フォーマット例
{"label": "food", "score": 5, "reason": "この文章は食事に関する説明が多いです。"}

# note記事
今期は全体的に豊作ですね。私はブルーロックが特に好きです。
ChatGPTに記事分類させた時の回答

記事数が少なければこういった分類は手動などで簡単にできますが、noteは毎日数万件の規模で、多種多様なラベルづけに対応する必要があります。

そのため、大規模データに対する多様なニーズにお応えできるように下記のようなLLMを使ったワークフローを構築する必要が出てきます。

理想のLLMワークフロー例

このようなワークフローを構築することで、データ抽出→前処理→LLM実行→情報集約といった一連のフローをフレキシブルに実行できるようになるわけです。ということでnoteでLLMワークフローを構築した話をしようと思います。

今回は前編として「技術選定編」を書いていきます。
後編では「構築/運用編」を書いています。後編の記事はこちらから↓



LLMワークフロー選定における前提・基準

LLMワークフローの技術選定において、まず会社の前提技術や条件を考えるのは必要です。なので、noteにおける前提と基準を書いてから技術選定の話に移ろうと思います。

LLMワークフロー選定における前提

  • noteのバックエンドは基本的にRuby on Railsのモノレポなレポジトリでシステム構築をしている。全社共通のRDBを運用管理していて、admin管理画面や各種API/バッチ処理を実装している。

  • 全社的な基盤としてAWSを活用。LLMはAzure/GCPなどと連携している。AWS上でワークフローを構築する前提なのでGCP/Azureなどのワークフローサービスについては候補としては含まない。

このような前提を踏まえてワークフロー選定基準を考えてみました。
(私の過去のMLOpsの辛みを反映している部分もあります)

LLMワークフロー選定における基準

1. noteのDBにCRUD操作しやすいか(重要度：高)
AWSアカウントやDBなど含めて0から作るのは時間がかかるので、現在note上で構築しているDBやテーブル、実装などを活かしつつワークフローやワークフロー管理/実行履歴画面などを構築したい

2. 開発しやすいか(重要度：中)
ワークフロー構築の辛みはローカル実行の難しさにあると個人的に感じている。ローカル環境での実行やVSCodeなどで実装しやすいかという観点は重要。

3. スケーラビリティ(重要度：中)
計算量が多い処理やGPUが必要な場合にインスタンスを調整できるか

4. 運用負担(重要度：中)
最先端の技術すぎてもネット上に解決策が載ってなかったりする可能性がある。またnote AI creativeは少人数の会社なのでインフラ面とアプリ面の両方で重い運用管理負担を背負うのはできるだけ避けたい。前例のあるシステムに相乗りするような実装ならば負担が軽減できる

5. コスト(重要度：中)
ワークフローの実行にコストがかかるような仕組み(インスタンス常時起動など)ではなく、サーバーレスのように使った時だけ稼働して課金されるような仕組みが良い。

LLMワークフロー技術を比較する

上記の選定基準をもとに実装可能なワークフロー技術を比較していきます。
細かい部分を書くと文章量が多くなるので、サマリーだけ書いていきます。

1. AWS Step Functions

下記のレコメンドシステムのように推薦/MLチームでStep Functionsを活用している知見はあります。またAWS Step Functions SDKなどを使えばワークフローの開発はスムーズにできそうな雰囲気はあります。

しかし、MLチームでStep Functionsを運用してて障害時のデバッグのしづらさに辛みがあったりAWSに結構詳しくないと使いこなせないので、今回は採用を見送りました。

2. Metaflow

下記のレコメンドシステムのように推薦チームでMetaflowを活用している知見はあります。
こちらの公式ドキュメントを見る限りだと、ローカル実行から各種クラウドサービスとの連携も考慮されておりワークフローとしては非常に有力な候補ではあります。

しかし、noteのRDBとのCRUD操作機能を0から作る負担があるのと、Argo Workflowsより運用負担が大きそうな点を考慮して、採用を見送りました。

ただ今回のような前提や基準がなかったらMetaflowを選んでいただろうな、というくらい良いフレームワークと思っています。

3. Argo Workflows

実はnote記事のインポート/エクスポート機能でArgo Workflowsを活用しております。

このような前例があるので、noteのDBと簡単に接続してCI/CDを回すことができて、さらにプロンプト管理画面や実行履歴画面なども作りやすそうです。

またArgo WorkflowsはKubernetesを運用管理しなくてはいけないのですが、Kubernetesの運用管理は弊社の優秀なSREにお任せできるので、note AI creativeとしてのインフラ運用負担はほぼ0に近いです。

今回のような前提や基準であれば、Argo Workflowsが一番だろうと判断してArgo Workflowsを採用しました。

4. Dify

Difyは誰でも簡単にAIツールが作れるワークフロープラットフォームです。
下記のようなワークフローを画面でポチポチ操作するだけで作れてしまう脅威のローコードツールです。

LLMワークフローが簡単に作れる

下記のようにAWS環境でDifyを構築することもできます。

ただDifyはローコードツール的な色合いが強く、noteのDBと接続して大規模データについてCRUD操作していくようなシステムには現状出来なさそうなので、今回の技術選定では見送りとしました。

しかしながら、この異常なほどの手軽さはプロンプトの検証段階で大いに活躍が期待できそうです。
なので検証/PoC段階のLLMワークフローとしてDifyを採用しました。

LLMワークフロー技術の選択

運用段階でも検証/PoC段階でも使える最強のLLMワークフローみたいなものがあれば採用したいですが、現状はArgo WorkflowsとDifyでうまくLLMワークフローのPDCAを回していくのが最善そう、という結論になりました。

  • 運用段階のLLMワークフローとしてArgo Workflowsを採用

  • 検証/PoC段階のLLMワークフローとしてDifyを採用

ワークフローの適材適所と役割分担を考える

ワークフローの選定を頑張って考えていきましたが、やはりワークフローの適材適所を考えることが重要だと思っています。

例えば、Argo Workflowsでプロンプトの検証を回そうとする場合、プログラム実装も必要なのでプロンプトチューニングのPDCAを回しにくいです。

しかし、Difyのような簡単に使えるワークフローがあれば、エンジニアやビジネスサイドでプロンプトのPDCAを回して、高速に最善のプロンプトを見つけることができるようになります。

このようにワークフローの適材適所を考えるとともに、さらに下記のように人の役割を分けることで、関係者と認識の齟齬なく安全にLLMワークフローを構築できそうと思っていますので、それぞれについてご紹介します。

1. 関係者と期待値調整してプロンプト検証する人
2. 検証済みのプロンプトを運用ワークフローに落とし込む人

役割分担の例

1. 関係者と期待値調整してプロンプト検証する人

AI に関するプロダクトや生産性向上を考えるときに、関係者がAIに対して過剰に期待していることが多いです。

この期待値を調整するために、例えばサンプルとなるデータをGoogleスプレッドシート上に記載してGoogle Apps ScriptからDifyを呼び出してどのくらい推論精度(タグ付け/要約 など)があるのかを示すと良いと思います。

この役割の人は下記のようなタスクができる人が良いかと思います。

・関係者と密にコミュニケーションする
・色々なアイデアを実践して分析して言語化する
・DifyとGASを組み合わせたアーキテクチャで実装する
・プロンプトチューニングの沼に負けずに物事を進める

2. 検証済みのプロンプトを運用ワークフローに落とし込む人

検証済みのプロンプトを実際の運用ワークフロー(Argo Workflowsなど)に落とし込む人には高いエンジニアリング能力が求められます。
詳細については後編で書いていこうと思います。

この役割の人は下記のようなタスクができる人が良いかと思います。

・MLOps的なワークフローを構築する
・DBテーブル、ワークフローリトライなどを設計する
・プロンプト管理/ワークフロー実行履歴画面などのフロントエンド実装
・AWS/Azure/GCPなど関係するサービスが多くなっても勉強して実装する

終わりに

今回は、会社の前提技術や基準をもとに適切なLLMワークフローを選定していく話と役割分担についてご紹介しました。

AIが便利になっていっても、上記で書いたような技術選定や役割分担はとても難しいなぁというお気持ちでございます。

あとこの記事を書いている途中で、下記のような資料を見つけたのですが、Argo WorkflowsとDifyで良い感じにHuman-in-the-loopでLLM-as-a-Judgeしていきたいなと思いました。


次回はArgo WorkflowsでどのようなLLMワークフローを設計/実装したのか紹介したいと思います。
読んでいただきありがとうございました！！！

▼noteエンジニアの記事が読みたい方はこちら

後編の記事はこちらから↓


いいなと思ったら応援しよう！