こんにちは。AI・LLM事業部エンジニアの@koseiと申します。note.layerx.co.jp
AI・LLM事業部ではお客さまの幅広い業務を効率化するためのプラットフォーム型のプロダクト「Ai Workforce」を開発しています。
Ai Workforceは「AIワークフロー」（以下、WF）という、LLMやルールベース処理を組み合わせた一連のアルゴリズムを持っており、業務ごとに異なるWFを作ることで多様なユースケースを実現しています。WFは複数のLLMの呼び出しを組み合わせて構成されており、その１単位を本記事では「タスク」と呼ぶことにします。
私は普段お客さまごとのWFの開発や、Ai Workforce自体の開発を行っています。
今回は、LLMが100%の正解は出せない前提で、どのようにお客さまの実務に価値を届けるか、WF開発で試行錯誤してきた中で感じたことや学びについて書いてみようと思います。
LLMを用いたアプリケーションを作られる際の参考になれば幸いです。
あらまし
- 複数サンプルでの検証やE2Eでの検証を怠らない。WF修正時の影響は予測しづらいため、こまめに影響範囲の検証を。
- LLMの誤答による業務への悪影響は体験の設計で変わる。精度測定箇所の後続作業に注意。
- LLMの間違いをリカバリーしやすいWFを構築する。例えば、高いカバレッジで出して編集可能な形にする
複数サンプルでの検証やE2Eでの検証を怠らない
当たり前かもしれませんが、以下の二点から、LLMを応用するアプリケーションにおいて改めて重要性を認識しています。
1. LLMを用いたシステムでは依存関係や影響範囲の予測がしづらい
例えばLLMを呼び出すタスクが複数ある場合や、プロンプトが長くなってきた場合において特に顕著です。
あるLLMを呼び出すタスクをチューニングした際、そのタスクの結果に依存している後続のLLMタスクの結果が意図せず変わってしまったり、過去に書いた長いプロンプトの全体像を把握しづらいため、競合する指示を入れたままにしてしまうといったミスが起きやすいです。
2. 施策の実行コストが低く、目先の課題が解決したように見えて満足してしまいがち
特定の対象（例えば処理対象のファイルや質問クエリ）の課題に対処する際、プロンプトエンジニアリングや別のLLMタスクの追加など、比較的すぐに行える施策で目の前の課題を解決できる場合が多いです。また、お客さまはドメイン理解が深く、改善アイデアがたくさん出てくるため、試せる施策の数も大量にあります。
一方で、ある施策の反映後も他のファイルやクエリでも使える汎用性を保っているか・ロバストかどうかは、WFを見ただけではわからないことがほとんどです。
例えば私が体験したケースとして、請求書から全ての商品と金額を抽出するようなユースケース（実際のお客さまのケースではなく、説明用に改変しています）において、商品数の多い請求書の場合、LLMの出力に全ての商品が収まらないという課題がありました。
そのため、商品をグルーピングする「カテゴリー」（上記例では「ソフトウェア」と「特許取得」）の記載が請求書にあることを用いて、先にカテゴリーを抽出し、その後カテゴリーごとにそこに属する商品を全て抽出させるように修正することで、対象のファイルでは解決しました。
しかしながら一部のファイルにおいて「ページをまたがるカテゴリーでどうしても抽出漏れする」ケースがあることが発覚しました。今回の施策を行う前までは正確に抽出できていたものです。
上記のように複数のサンプルでの検証をしないと、ある施策が潜在的に別の課題を引き起こす可能性があります。結果として、全体的な精度がそこまで変わらず（むしろ低下することも多い）処理とプロンプトだけが煩雑になっていってしまいます。
タスクの追加や組み替え、出力内容の大幅な変更があるタイミングでは、チェックポイント的に処理フロー全体で複数サンプルにおけるテストをできると良いのではないかと思います。
LLMの誤答による業務効率への悪影響は体験の設計で変わる
ユースケースによって「人間が正誤を認識し、正しい答えを業務のアウトプットとして出すまでのコスト」は異なり、お客さまの業務効率に大きく影響します。
この部分はWFや体験の設計で改善できる部分が多いのでは無いかと考えています。
例えば請求書PDFから商品と金額を抽出した上で勘定科目に分類するようなユースケースがありました。（実際のお客さまのユースケースではなく、説明用に改変しています）
業務のアウトプットとして必要なのは「その請求書における勘定科目ごとの合計金額」だったため、最初は素朴に以下の流れで作りました。
ユーザーは「勘定科目ごとの集計・内訳」を見て抜け漏れや余計な品がないか・分類を間違えていないかチェックし、その計算を反映します。（例：ソフトウェアが本当は支払手数料に入るべきだった場合、無形固定資産の合計額から1,000を引いて支払手数料に1,000を加算する）
その際、最終的な計算結果や内訳を表示するだけでは、以下の課題がありました。
①人間が修正した結果を別途Excelなどで計算する必要がある
②勘定科目ごとの表示は請求書と見た目上の順序が異なり、抜け漏れや取りすぎを人間が検知しにくい（特に商品数が多い場合）
抽出や分類の「精度」自体がよくても、その修正作業の手間が大きいため、結果として業務全体での効率化を得難い形になっていました。
そのため、Excel形式で出力し、集計の計算はExcelの関数で行うことにしました。
以下のようなエクセルファイルがAi Workforceから出力されるイメージです。
G~K列に請求書から抽出・分類したデータを表示し、M列以降に業務で得たい最終的なデータをExcel上の関数で計算しています。
これによりJ列「LLMによる分類結果」の値をプルダウンで修正すれば分類ミスの修正は完了するようになりました。
LLMの間違いをリカバリーしやすいWFを構築する
抜け漏れの検知も修正作業のうち負担の大きい部分でした。
抽出されたデータと請求書を目視で比較する必要があり、特に請求書に100個以上の商品がある場合は目視で検出するのは認知負荷が高く、作業負担も大きい状態でした。
そこで、ワークフローを「取り漏れがほとんど無い抽出→LLMによるフィルタリングタスク」という２段階に分けました。
Excel上には「取り漏れがほとんど無い抽出」の結果を全て表示しています。フィルタリングタスクで除外されたものは、表示はされていますが勘定科目の集計には使われてません（グレーにハイライトされている行）
これによりユーザーはグレーでハイライトされた箇所をチェックすれば抜け漏れをすぐに検知できるようになりました。
このように、最終的にLLMで価値を出すためには、精度向上以外でも体験やWFの作り方で工夫すべきことがあります。
精度はあくまで提供価値の指標の一つとして、ビジネスインパクトを考慮した設計と評価が重要です。
例えば以下のように「正解」「失敗（人間がカバー）」「失敗（顧客の離脱）」のような正誤のパターンに分けて、各パターンごとに重みをつけてみても良いと思います。
出典：https://platform.openai.com/docs/guides/optimizing-llm-accuracy
上記表の言葉を借りると、失敗した場合の価値への影響（VALUE）を減らすような設計を心がけたいです。
おわりに
LLMは不確実な要素も多く、まだまだ誰もベストプラクティスがわかっていません。
LayerX AI・LLM事業部では、LLMを徹底的に使い倒し、お客さまのビジネスで最終的なアウトカムを出すための方法を模索・開発し続けています。
試行錯誤して色々試したい、という方は是非一度カジュアル面談でお話ししましょう。
Xの@LayerX_techアカウントではLayerXの様々な取り組みを発信していますので、是非こちらもフォローしてください！
