Last updated on
【勉強会参加ログ】LLMアプリケーション開発の極意
まとめ
- スモールステップで進めるのが重要
- LLMアプリケーション開発においては、人手も含めて精度を評価しつつ自動化を目指していく流れがとられている
- プロンプトチューニング・評価の負荷が高い
- ドメインエキスパートの評価の負荷を軽減しつつ、LLMが評価できる部分は任せていくのが肝
- プロンプトの生成・改善をエンジニア以外ができるようにするなどの工夫をしないと開発が進まなくなっていく
- AIエージェントでやらせるのか、AIワークフローでやるべきなのか判断する
- 定形・非定形な業務によってとるべきアプローチが変わる
勉強会参加メモ・ログ
「営業AIエージェント アポドリの作り方」
- 人の代わりに営業活動を行うAIエージェント
- 営業リストを元に商談をとるまでをAIが実施する
- 3つのフェーズ
- ワークフローを言語化するフェーズ（課題の探索）
- 実際にエンジニアチームも営業代行に参加したとのこと
- 人手でやっていたことを徐々にAI化
- 精度アップのサイクル
- 人手→AIが直し→目視→人手で直す→AIで直す
- 顧客数の増加フェーズ
- 複数社対応の安定化
- あらゆる手作業を極力自動化していく
- オペミス等のリスクが高いため
- あらゆる手作業を極力自動化していく
- プロンプトの外部化
- 顧客ごとにプロンプトを作るのは人手が足りない
- プロンプトをDifyに切り出してエンジニア以外が対応できるようにした
- 複数社対応の安定化
- リリース後
- より高品質なアウトプットのための取り組み
- AIの出力をAIで評価することが必要になっていく
- AIエージェント作りにおいて評価が重要なポイントとなる
- エンジニアが介在せずにプロダクトを成長させていく仕組みを作る
- AIの出力をAIで評価することが必要になっていく
- より高品質なアウトプットのための取り組み
- ワークフローを言語化するフェーズ（課題の探索）
- ドメインの理解がAIエージェント作りに重要
- ゼロから開発するならのプロセス
- 顧客課題の探索
- LLMの検証
- システム化
- 人とハイブリッドにしてもいいかも とのこと
- 評価と改善の仕組み化
- ドメインエキスパートを巻き込む
- 製品として安定化
- 大規模実行すると課題が発見されることがある
- リリース
- お客さんへ伝える工夫が必要
- AIエージェントが新しすぎるため
- お客さんへ伝える工夫が必要
- 継続的改善と提供価値の新規開発
- 課題をAIで解決したら事業が変わるのか？ と精査する必要がある
- LLMで検証
- LLMによって多様なアウトプットを検証する
- 例
- 人物の名前→ローマ字から漢字に変換するときなど
- プロンプトで改善できるのかをチェックする
- 人物の名前→ローマ字から漢字に変換するときなど
- 人手を挟んでスモールステップを挟むべき
- 人手を介してでも価値検証するべき
- この過程でドメイン理解が進んでいく
- AIを使えば勝手にハイクオリティなアウトプットが出せるわけではない
- 適切なワークフローへ分解し緻密な指示、継続的な改善が必要
「現場で動くAIワークフロー チューニングを効率化する工夫」
https://speakerdeck.com/layerx/real-world-ai-workflow-tuning-tips
- AIワークフロー VS AIエージェント
- AIエージェントは入力の予測ができない・網羅しきれない「非提携な業務」向け
- 確率的な動作をするため、エンジニアリング難易度が高い
- AIワークフローは定型化された業務に対し、動作や出力が予測可能であるタスクと相性がいい
- AIエージェントは入力の予測ができない・網羅しきれない「非提携な業務」向け
- AIワークフローの精度評価のサイクルをどう高速化するか
- 課題：正解データの作成の負荷の高さ
- 期待値を取っておき、成果物と差分を取れるようにする（GitHubのDiffみたいにしている）
- 生成された文章は人間がみて評価する必要性が出ている
- 代表的な評価メトリクスが発表されている
- 課題：評価作業の負荷の高さ
- プロンプトを変更すると全く関係ない部分が変化してしまう
- 間接的な精度評価
- 文章に必ず入っていて欲しい単語の数を測っている
- 直接的に評価はしない
- 文章に必ず入っていて欲しい単語の数を測っている
- 課題：正解データの作成の負荷の高さ
質疑応答
- 1つのプロンプトチューニングから評価はどの程度行うのか？
- 目的に応じて回数が異なる
- 財務諸表の読み取りなどは難易度が高くなる
- 入力のフォーマットによっては数十回評価するサイクルを行うこともある
- 目的に応じて回数が異なる
- ファイル等のデータ取得はRAGを利用しているのか？
- 最近はコンテキストウィンドウが増えてきたのでRAGを使わない時も増えてきた
- 必要なデータを取得してきてその部分だけをコンテキストに含めるパターンも存在
- モデルの刷新とプロンプトチューニングのバランスの取り方
- 良いプロンプトの中身はモデルが進歩しても重要
- ドメイン知識に依存したものであるため
- 4oからo4への変更（リーズニングモデルへの変更）時にアプローチが変わることもある
- CoTが不要になった
- 指針となるプロンプトは変わらない
- 良いプロンプトの中身はモデルが進歩しても重要
- 技術選定の考え方
- ADRを残している
- 課題解決に一番良いと思われるライブラリが選ばれている
- 後ほど使用する技術を大きく変えることになった場合に備えているか？
- LayerXが今直面している課題
- アーキテクチャを変える必要がある
- 今のトレンドでどれが残りそうか考えながら選んでいる
- LayerXが今直面している課題
- LLMの評価にドメインエキスパートの負荷が高すぎるのでは？
- 確認する作業がやりやすいように出力させている
- どこを参照して回答出力したのかわかるように出力させている
- ドメインエキスパートが評価する量を減らすために、LLMにも評価させている
- 正しく評価できる部分はLLMで対応し、難しい部分はドメインエキスパートが判断する