業務でのLLM活用検討とプロンプティングの難しさ
業務でのLLM利活用を想定した取り組みの中で、プロンプティングの難しさに直面したので、試したことをまとめます。
目次
業務でのLLM利活用について
LLMで業務効率化が図れないかなと考える中(以下リスト)で、色々なサービスベンダーが既に出している(汎用性が高い)領域も多くあったので、実際の現場に近い担当者が独自で開発した方が良いものってないかなという視点で、開発ターゲットを選定してみました。
| 活用案 | 活用するまでのハードル | 理由 |
| 社内ナレッジを活用したChatBot | 低~高 | Google Vertex AI等 複数ベンダーが提供しているサービスがあり、サービスをそのまま使える為 ハードルが低いが、求められる出力レベルによってはハードル高い |
| 議事録の自動作成 | 低い | 複数ベンダーが提供しているサービスがあり、サービスをそのまま使える為 ハードルが低い |
| ソースコードの理解/作成支援 | 低い | 複数ベンダーが提供しているサービスがあり、サービスをそのまま使える為 ハードルが低い |
| 書類の自動チェック | 高い | 複数ベンダーが提供しているサービスがあるが、社内ナレッジ向けにカスタマイズが必要であり、ハードルが高い |
この中で、社内ナレッジを活用したChatBot作成事例や作成フローの紹介は色々なページで紹介があるので、書類の自動チェックをLLMに実施させる方法は事例がなかなか見当たらなかったので、トライしました。
「書類の自動チェックする」システムの作成
現状、書類（開発書類）は抜け漏れなく記載されているかどうかを人がチェックしていますが、このチェックを自動化して効率化を図りたいと考えました。
| 現状 | 望むべき未来 | ソリューション案 |
| 人が一つ一つ書類をチェック | 自動で書類がチェックされてその結果が返ってくる | LLMを活用する |
書類が正しく書けているかどうかは、「文章の正しさ」や「一貫性があるかどうか」が関係するため、LLMを使うのが適切と考えました。
とりあえずやってみる
結論から言うと、とりあえず何も考えずに以下のようなプロンプトを与えてチェックをしてみたのですが、うまくいかないことが非常に多くありました。
使用するモデルと実施方法
Gemini Pro-1.5を使おうか迷いましたが、試した時点で一番最新だったGPT-4oを使いました。APIとしての使い方ではなく、アプリでの使い方のため、TemperatureやTop_pなどの設定はできません。続けて会話をすると履歴の中に答えが混ざってしまうので、1回聞くごとに違う会話ウィンドウで聞くということを繰り返しています。（面倒ですが、GPT-4oを試したかった）
用意したデータ
Google Geminiに架空のプロジェクト書類とチェックリストを作成してもらい、チェックリストに対してNGが出るような文章も作成してもらいました。
作成したプロジェクト書類
要件仕様書 プロジェクト概要 プロジェクト名: 新規Webアプリケーション開発 プロジェクト番号: DEV24-01 目的: 中小企業向けにカスタマイズ可能な在庫管理システムを提供する。 期間: 2023年6月1日から2023年12月31日 機能要件 在庫登録機能: 商品の追加、編集、削除ができる。商品ごとにカテゴリ分けが可能。 在庫検索機能: 商品名、カテゴリ、価格帯など複数の条件で検索可能。 在庫報告機能: 指定期間内の在庫動向を報告書として出力。在庫過多や不足があった場合のアラート機能。 ユーザー管理機能: ユーザー登録、ログイン、権限管理。 非機能要件 パフォーマンス: 画面の応答時間は2秒以内。 セキュリティ: GDPRに準拠したデータ保護。 スケーラビリティ: 最大1000ユーザー同時アクセスをサポート。 利害関係者 エンドユーザー: 在庫管理を行う中小企業の従業員。 開発チーム: ソフトウェアエンジニア、プロジェクトマネージャー。 クライアント: XYZ株式会社。 リスク評価 - リスク1: プロジェクトの遅延 - 対策: 定期的な進捗確認と問題の早期発見 - リスク2: セキュリティ脆弱性 - 対策: 定期的なセキュリティテストと脆弱性の迅速な修正 - リスク3: ユーザーの要件変更 - 対策: 変更管理プロセスを設け、変更要求を適切に評価・対応 承認プロセス - ドキュメントレビュー: プロジェクトマネージャー、クライアント代表者、主要な技術者がレビューを行う。 - 承認手順: レビュー完了後、各担当者が承認のサインを行う。 - 文書管理: 全てのドキュメントはプロジェクト管理システムに保存され、変更履歴を追跡可能にする。 変更管理プロセス - 変更要求の提出: 利害関係者は公式な変更要求書を提出する。 - 変更評価: 提出された変更要求は、技術的・スケジュール的・コスト的な影響を評価される。 - 変更承認: 評価結果に基づき、承認または却下が行われる。 - 変更実施: 承認された変更は、プロジェクト計画に反映され、実施される。 ワークブレイクダウン構造(WBS) 1. プロジェクト管理: 2023年6月1日 - 2023年6月14日 - 計画策定: 2023年6月1日 - 2023年6月7日 - リスク管理: 2023年6月8日 - 2023年6月14日 2. 要件定義: 2023年6月15日 - 2023年7月5日 - 利害関係者インタビュー: 2023年6月15日 - 2023年6月21日 - 要件ワークショップ: 2023年6月22日 - 2023年6月28日 - 要件文書化: 2023年6月29日 - 2023年7月5日 3. 設計: 2023年7月6日 - 2023年7月20日 - アーキテクチャ設計: 2023年7月6日 - 2023年7月12日 - データベース設計: 2023年7月13日 - 2023年7月20日 4. 開発: 2023年7月21日 - 2023年9月15日 - フロントエンド開発: 2023年7月21日 - 2023年8月10日 - バックエンド開発: 2023年8月11日 - 2023年9月15日 5. テスト: 2023年9月16日 - 2023年10月15日 - 単体テスト: 2023年9月16日 - 2023年9月30日 - 結合テスト: 2023年10月1日 - 2023年10月15日 6. デプロイメント: 2023年10月16日 - 2023年11月15日 - デプロイ計画: 2023年10月16日 - 2023年10月30日 - 実装: 2023年10月31日 - 2023年11月15日 7. サポートとメンテナンス: 2023年11月16日 - 2023年12月31日 - テクニカルサポート: 2023年11月16日 - 2023年12月15日 - バグ修正: 2023年12月16日 - 2023年12月31日
作成したプロジェクト書類のチェックリスト
要件仕様書作成のチェックリスト 1. プロジェクトの目的が明確に記述されているか？ 2. プロジェクト番号に誤りはないか？ 3. すべての主要機能がリストアップされ、詳細に説明されているか？ 4. 非機能要件（パフォーマンス、セキュリティ、スケーラビリティなど）が網羅されているか？ 5. 全ての利害関係者が識別され、そのニーズが適切に反映されているか？ 6. リスク評価は行われ、対策が計画されているか？ 7. 承認プロセスが記載されており、文書の管理方法が定義されているか？ 8. 変更管理プロセスが設定されており、要件の変更に対応できる体制が整っているか？ 9. プロジェクトの時間枠とマイルストーンが設定されているか？
用意したプロンプト(Zero-shot)
まずは、何も考えずにZero-shot(ただ聞いてみる)プロンプトを与えてみる。
英語化だけ対応。
systemprompt役割のプロンプト
#YourRole:You are the process manager and need to check the development document, User Input Document [I1].
The checks are performed based on the input Check Perspective [I3], and the Project Summary Information [I2] is used to check [I1].
The Project Summary Information [I2] is always the correct text and gives the prerequisite that the Project Summary Information [I2] is never incorrect.
Please refer to #Process for the processes to be checked and the output for each process.
#Process:
[P1~] is a process and the corresponding output is [O1~]. The final result should be answered according to the Output Format.Please conduct output in Japanese.
[O1]:None
[P1]:Obtains the contents of user input documents [I1], project summary information [I2], and check item information [I3].
[O2-1]:consideration process
[O2-2]:judgment result(options [No problem(問題なし)/Problem(問題あり)/No judgment(判断困難)])
[P2]: Please conduct the judgment from the viewpoint of [I3] step by step and output the examination process [O2-1] and
the final judgment result [O2-2]. For the judgment result [O2-2], select from [No problem]/[Problem]
if the judgment can be made, and output No judgment if the judgment is difficult,
so that the output is a selection from three options.
If the information in [I2] is required for judgment, please use the information in [I2].
#Output Format(only japanese)
チェック観点[I3]:
判断結果[O2-2]:
判断理由[O2-1]:
user prompt役割のプロンプト
Input Document[I1]: {添付書類}
Project Summary Information[I2]: {[プロジェクト情報]
プロジェクト名 = 新規Webアプリケーション開発
プロジェクト番号 = DEV24-01}
Check Perspective[I3]: {「作成したプロジェクト書類のチェックリスト」の項目を順番に入力する}LLMへのプロンプトの渡し方は、「system prompt役割のプロンプト」と「user prompt役割のプロンプト」を前後にくっつけて、Input Documentとして上で示した「作成したプロジェクト書類」を.docx形式で添付して渡しています。
結果(Zero-shot)
上で示した「作成したプロジェクト書類」に関しては全て「問題なし」として結果が返ってきました。まずはOK！
次に、実際の使い方として、問題がある書類に対して指摘をしてもらえると嬉しいので、あえてNG(問題のある)文章を作成して、判断をさせてみました。
その結果を以下表にまとめています。
「NG理由」に問題ありと指摘して資料変更箇所を記載し、「LLM出力」に結果を示しています。
| 対応CheckList番号 | NG資料番号 | NG理由 | LLM出力: 判断結果[O2-2] | LLM出力:判断理由[O2-1] | LLMが判断できなかった観点 |
| --- | ------ | ------ | -- | ----- | ----- |
| 1 | NG1 | プロジェクトの目的が削除 | 〇問題あり | プロジェクトの目的が記載されておらず、範囲が不明確である | - |
| 1 | NG2 | プロジェクト目的を「より良いシステムを提供するため」と非常に曖昧なワードに修正。 | ✕問題なし | プロジェクトの目的（より良いシステムを提供するため）と記載されている | 記載内容で判断できていない |
| 1 | NG3 | プロジェクトの目的が「中小企業向け」と「大規模企業向け」と2つ記載されている | ✕問題なし | プロジェクト目的が記載されている | 重複や矛盾が誤りであると判断できていない |
| 1 | NG4 | 目的が「社員の満足度向上と企業のブランド価値を高めること」と記載されており、プロジェクトで他に記載されている内容と無関係な内容が記述されている。 | ✕問題なし | プロジェクトの目的と範囲は、「社員の満足度向上と企業のブランド価値を高めること」と明確に記述されている | 記載内容で判断できていない |
| 2 | NG5 | プロジェクト番号に誤りがある | 〇問題あり | プロジェクト概要情報ではプロジェクト番号が「DEV24-01」とされているが、要件仕様書には「DS1212」と記載されており、一致していない。 | - |
| 2 | NG6 | プロジェクト番号が記載されていない | 〇問題あり | プロジェクト概要情報ではプロジェクト番号が「DEV24-01」とされているが、要件仕様書にはプロジェクト番号の記載がない。 | - |
| 3 | NG7 | 主要機能の一つである「在庫報告機能」が削除されており、すべての主要機能がリストアップされていない。 | ✕問題なし | 在庫登録機能、在庫検索機能、ユーザー管理機能の主要機能がリストアップされ、それぞれ詳細に説明されている。 | 記載内容で判断できていない |
| 3 | NG8 | 主要機能の説明が「管理ができる」「検索ができる」など非常に曖昧であり、詳細に説明されていない。 | ✕問題なし | 主要機能（在庫登録機能、在庫検索機能、在庫報告機能、ユーザー管理機能）がリストアップされ、詳細に説明されている。 | 記載内容で判断できていない |
| 3 | NG9 | 「顧客管理機能」というプロジェクトとは無関係な機能が追加されており、主要機能が正確にリストアップされていない。 | ✕問題なし | 顧客管理機能、在庫登録機能、在庫検索機能、在庫報告機能、ユーザー管理機能の全ての主要機能がリストアップされ、詳細に説明されているため。 | 記載内容で判断できていない |
| 4 | NG10 | 非機能要件のセクション全体が削除されており、パフォーマンス、セキュリティ、スケーラビリティなどの要件が全く記載されていない。 | 〇問題あり | 非機能要件に関する記述が見当たりません。パフォーマンス、セキュリティ、スケーラビリティなどの非機能要件が網羅されていないと判断されます。 | - |
| 4 | NG11 | 非機能要件の記述が「良好であること」「標準に準拠すること」「将来の拡張に対応できること」と非常に曖昧であり、具体的な要件が詳細に説明されていない。 | 〇問題あり | パフォーマンスについての記述はあるが、セキュリティやスケーラビリティについての具体的な要件が記載されていない。 | 記載内容で判断できていない |
| 5 | NG12 | エンドユーザーが利害関係者リストから削除されており、全ての利害関係者が識別されていない。 | ✕問題なし | 要件仕様書には、開発チーム、クライアントの利害関係者が識別されており、それぞれのニーズが反映されています。 | 記載内容で判断できていない |
| 5 | NG13 | 利害関係者のニーズが「一般的な要件を持つ」「プロジェクトを開発する」「プロジェクトを依頼する」と非常に曖昧であり、そのニーズが適切に反映されていない。 | ✕問題なし | 要件仕様書には、エンドユーザー、開発チーム、クライアントの利害関係者が識別されており、それぞれのニーズが反映されています。 | 記載内容で判断できていない |
| 6 | NG14 | リスク評価のセクション全体が削除されており、リスク評価が行われていない。 | ✕問題なし | ワークブレークダウン構造（WBS）の中にリスク管理が含まれており、リスク評価が行われ、対策が計画されています。 | 記載内容で判断できていない |
| 6 | NG15 | リスク評価は行われているが、リスクの対策が記載されていない。 | ✕問題なし | リスク評価が行われており、リスクに対する対策が計画されています。 | 記載内容で判断できていない |
| 6 | NG16 | リスクの説明が「何か問題が発生する可能性がある」と非常に曖昧で、具体的なリスク評価と対策が記載されていない。 | ✕問題なし | リスク評価が行われ、具体的な対策が計画されているため。 | 記載内容で判断できていない |
| 7 | NG17 | 承認プロセスのセクション全体が削除されており、承認プロセスが記載されていない。 | 〇問題あり | 添付された要件仕様書には、承認プロセスや文書の管理方法についての記載が見当たりません。 | - |
| 7 | NG18 | 承認プロセスの記述が「適切な担当者が承認を行う」と非常に曖昧で、具体的な手順が記載されていない。 | ✕問題なし | 承認プロセスおよび文書管理方法が明確に記載されています。 | 記載内容で判断できていない |
| 7 | NG19 | 文書管理の記述が「すべてのドキュメントは適切に管理される」と非常に曖昧で、具体的な管理方法が記載されていない。 | ✕問題なし | ドキュメントレビューと承認手順が明確に記載されており、すべてのドキュメントは適切に管理されると定義されています。 | 記載内容で判断できていない |
| 7 | NG20 | 承認手順に「各担当者が承認のサインを行う」と「チーム全体で承認の投票を行う」という矛盾した手順が2つ記載されている。 | ✕問題なし | 承認プロセスおよび文書の管理方法が明確に記載されている。 | 重複や矛盾が誤りであると判断できていない |
| 8 | NG21 | 変更管理プロセスのセクション全体が削除されており、変更管理プロセスが記載されていない。 | 〇問題あり | 要件仕様書には、変更管理プロセスについての具体的な記載が見当たりません。 | - |
| 8 | NG22 | 変更管理プロセスの記述が「変更は適切に管理される」と非常に曖昧で、具体的なプロセスが記載されていない。 | ✕問題なし | 「変更管理プロセス」が詳細に記載され、要件の変更に対応できる体制が整っていることが確認できます。 | 記載内容で判断できていない |
| 8 | NG23 | 変更承認の手順に「評価結果に基づき、承認または却下が行われる」と「チーム全体で変更の投票を行う」という矛盾した手順が2つ記載されている。 | ✕問題なし | 変更管理プロセスが設定され、変更要求の提出から評価、承認、実施までの手順が詳細に記述されている。 | 重複や矛盾が誤りであると判断できていない |
| 9 | NG24 | プロジェクトの時間枠とマイルストーンのセクション全体が削除されており、時間枠とマイルストーンが設定されていない。 | ✕問題なし | プロジェクトの期間が「2023年6月1日から2023年12月31日」と設定されており、マイルストーンについても期間内の重要な出来事として言及されている。 | 記載内容で判断できていない |
結果は結構ダメでした・・・この表は全て問題がある文章に対するチェック結果であり、全ての項目で「問題あり」として判断してほしいですが、「問題なし」と判断される部分が殆どでした。
「○○が記述されていますか？」という質問に対し、対象のワードが無い場合は、「記載がないので問題あり」と判断してくれるのですが、
「記載がダブっている」「対象ワードに関する説明は特になく、ワードが記載されているだけ」という状況でも「問題なし」と判断してしまいました。うーん・・・難しい
改良してやってみた
上でやった方法では、判断基準の例を与えていなかった為、LLMの持つ独自の判断基準で判断された？
判断基準を記載するなど、回答の精度を上げるためのプロンプティングを実施。
プロンプティングの技術や最新論文の情報などは、以下ページを参考にした。感謝です。
qiita.com
qiita.com
www.promptingguide.ai
これらページを踏まえた結果、以下手法を導入した。
- Few-shotで判断基準の例を示す
- magic world「Take a deep breath and work on this problem step-by-step. 」を加える
※今回のタスクはChain-of-Thought(CoT)をするレベルのタスクでもないので、CoT手法は取り入れていない
※Self-Consistency(複数出力して、その結果の多数決を行って最終的な出力にする手法)も試してみましたが、あまり効果はなさそうだった
修正したプロンプト(Few-shot)
systemprompt役割のプロンプト
##Role You are the process manager and you are responsible for reviewing the User Input Document [I1], a development document, in light of Check Perspective [I3]. Take a deep breath and work on this problem step-by-step, using the Project Summary Information [I2] if necessary. Assume that the Project Summary Information [I2] is always the correct text and that the Project Summary Information [I2] is never incorrect. Please refer to the judgement results and base your decision on the example. Please output the result based on the Output format. ##Process: [P1~] is a process and the corresponding output is [O1~]. The final result should be answered according to the Output Format. [O1]:None [P1]:Obtains the contents of user input documents [I1], project summary information [I2], and check item information [I3]. [O2-1]:Consideration process [O2-2]:judgment result(options [No problem/Problem/No judgment]) [P2]: Please conduct the judgment from the viewpoint of [I3] step by step and output the examination process [O2-1] and For the judgment result [O2-2]. For the judgment result [O2-2], select from [No problem]/[Problem]. Please refer to the example for checking. ##judgement results #example1 [O2-2]ユーザーインプット資料[I1]の内容には、目的やプロジェクト番号、承認者、各種プロセスが複数記載されており重複があり、一貫性が無く誤っている可能性がある。 [O2-1]問題あり #example2 [O2-2]ユーザーインプット資料[I1]の内容には、目的や機能要件、非機能要件の記載があるが、目的にそぐわない機能要件と思われる項目が存在し、適切に資料が記載されているか分からなかった。 [O2-1]判断困難 #example3 [O2-2]ユーザーインプット資料[I1]の内容には、チェックすべき項目に関する詳細な記載がなかった。WBSにチェックすべき項目の名前とスケジュールが存在したが、それ以外詳細な記載がなかったので、問題ありと判断した [O2-1]問題あり #example4 [O2-2]ユーザーインプット資料[I1]の内容には、「良い結果になるように頑張る」とだけ記載されており、具体的な方法が記載されていない為、問題ありと判断した。 [O2-1]問題あり #example5 [O2-2]「適当に実施する」 「適切に管理する」 と記載されているだけで、どう適切なのか、どう適当なのか、具体的な方法が記載されていない場合は問題ありです。 [O2-1]問題あり ##Output Format(only japanese) チェック観点[I3]: 判断結果[O2-2]: 判断理由[O2-1]:
systemprompt役割のプロンプトのみを修正しています。
結果(Few-shot)
上で示した「作成したプロジェクト書類」に関しては全て「問題なし」として結果が返ってきました。まずはOK！
次に、実際の使い方として、問題がある書類に対して指摘をしてもらえると嬉しいので、あえてNG(問題のある)文章を作成して、判断をさせてみました。
その結果を以下表にまとめています。
「NG理由」に問題ありと指摘して資料変更箇所を記載し、「LLM出力」に結果を示しています。
全て何かしらのNG要素を入れた資料なので、全て「問題あり」と回答してくれることを期待しています。
| 対応CheckList番号 | NG資料番号 | NG理由 | プロンプト修正前のLLMチェック結果 | プロンプト修正後のLLMチェック結果 |
| --- | ------ | ------ | -- | ----- |
| 1 | NG1 | プロジェクトの目的が削除 | 〇問題あり | 〇問題あり |
| 1 | NG2 | プロジェクト目的を「より良いシステムを提供するため」と非常に曖昧なワードに修正。 | ✕問題なし | 〇問題あり |
| 1 | NG3 | プロジェクトの目的が「中小企業向け」と「大規模企業向け」と2つ記載されている | ✕問題なし | 〇問題あり |
| 1 | NG4 | 目的が「社員の満足度向上と企業のブランド価値を高めること」と記載されており、プロジェクトで他に記載されている内容と無関係な内容が記述されている。 | ✕問題なし | ✕問題なし |
| 2 | NG5 | プロジェクト番号に誤りがある | 〇問題あり | 〇問題あり |
| 2 | NG6 | プロジェクト番号が記載されていない | 〇問題あり | 〇問題あり |
| 3 | NG7 | 主要機能の一つである「在庫報告機能」が削除されており、すべての主要機能がリストアップされていない。 | ✕問題なし | 〇問題あり |
| 3 | NG8 | 主要機能の説明が「管理ができる」「検索ができる」など非常に曖昧であり、詳細に説明されていない。 | ✕問題なし | 〇問題あり |
| 3 | NG9 | 「顧客管理機能」というプロジェクトとは無関係な機能が追加されており、主要機能が正確にリストアップされていない。 | ✕問題なし | 〇問題あり |
| 4 | NG10 | 非機能要件のセクション全体が削除されており、パフォーマンス、セキュリティ、スケーラビリティなどの要件が全く記載されていない。 | 〇問題あり | 〇問題あり |
| 4 | NG11 | 非機能要件の記述が「良好であること」「標準に準拠すること」「将来の拡張に対応できること」と非常に曖昧であり、具体的な要件が詳細に説明されていない。 | 〇問題あり | 〇問題あり |
| 5 | NG12 | エンドユーザーが利害関係者リストから削除されており、全ての利害関係者が識別されていない。 | ✕問題なし | 〇問題あり |
| 5 | NG13 | 利害関係者のニーズが「一般的な要件を持つ」「プロジェクトを開発する」「プロジェクトを依頼する」と非常に曖昧であり、そのニーズが適切に反映されていない。 | ✕問題なし | 〇問題あり |
| 6 | NG14 | リスク評価のセクション全体が削除されており、リスク評価が行われていない。 | ✕問題なし | 〇問題あり |
| 6 | NG15 | リスク評価は行われているが、リスクの対策が記載されていない。 | ✕問題なし | 〇問題あり |
| 6 | NG16 | リスクの説明が「何か問題が発生する可能性がある」と非常に曖昧で、具体的なリスク評価と対策が記載されていない。 | ✕問題なし | 〇問題あり |
| 7 | NG17 | 承認プロセスのセクション全体が削除されており、承認プロセスが記載されていない。 | 〇問題あり | 〇問題あり |
| 7 | NG18 | 承認プロセスの記述が「適切な担当者が承認を行う」と非常に曖昧で、具体的な手順が記載されていない。 | ✕問題なし | 〇問題あり |
| 7 | NG19 | 文書管理の記述が「すべてのドキュメントは適切に管理される」と非常に曖昧で、具体的な管理方法が記載されていない。 | ✕問題なし | 〇問題あり |
| 7 | NG20 | 承認手順に「各担当者が承認のサインを行う」と「チーム全体で承認の投票を行う」という矛盾した手順が2つ記載されている。 | ✕問題なし | 〇問題あり |
| 8 | NG21 | 変更管理プロセスのセクション全体が削除されており、変更管理プロセスが記載されていない。 | 〇問題あり | 〇問題あり |
| 8 | NG22 | 変更管理プロセスの記述が「変更は適切に管理される」と非常に曖昧で、具体的なプロセスが記載されていない。 | ✕問題なし | 〇問題あり |
| 8 | NG23 | 変更承認の手順に「評価結果に基づき、承認または却下が行われる」と「チーム全体で変更の投票を行う」という矛盾した手順が2つ記載されている。 | ✕問題なし | 〇問題あり |
| 9 | NG24 | プロジェクトの時間枠とマイルストーンのセクション全体が削除されており、時間枠とマイルストーンが設定されていない。 | ✕問題なし | 〇問題あり |
1つを除き、その他すべてについては、例を参考に適切に判断ができるようになりました。
出力例を示すFew-shotの手法はかなり有用だなと感じました！
プロンプティングの難しさについて
修正後のプロンプトで、唯一ジャッジを誤った以下チェック項目について、これを適切に判断させるのは非常に難しいなと感じました。
内容自体は適当な記載ではなく、物によっては正解となりうるセンテンスなのですが、機能要件などの他の個所との関係を見るとちょっと変だなと判断できる部分です。
| Check困難だった項目 |
| 目的が「社員の満足度向上と企業のブランド価値を高めること」と記載されており、プロジェクトで他に記載されている内容と無関係な内容が記述されている。 |
試しに、「上の項目のようなセンテンスが記載されていたら、問題ありと判断してね」、とFew-shotで記載すると、問題ありと判断できますが、それだと個別の対応となってしまいます。
そこで、「他の文脈も踏まえて、記載事項に不自然なつながりがあれば、問題ありと判断してね」、と記載をしてみたのですが、問題ありと判断がしてくれず、もう少し明確に判断基準を指し示す必要があるなと感じました。
ただ、結構難しい・・・
結果を踏まえたプロンプティングのポイント
上記結果を踏まえ、
- 判断基準を事例として紹介するのは非常に有効
- 判断が必要な個所については、判断基準を明確に記載する。
どこにでも書いていそうな内容ですが、、身をもって感じました
今回の目的である、人が行っていたチェックをLLMに実施させるというタスクでは、人の判断観点が多く、例えば、「妥当な記載なのか？」「一貫性があるかどうか？」というのは、明確に文章でどう妥当性を判断させるのか、プロンプトの与え方が難しいなと感じました。(チェックを完全にLLMに移管するという目的を果たすのは結構難しい・・・・)
もう少しLLMの自由度に依存してもよいタスクの方が、開発しやすいですね。
ちょっと、そういうタスクも探してみようと思いました。
まとめ
今回の試行錯誤を通じて、LLMを業務に活用する際のプロンプティングの難しさを実感しました。
また、LLMの利活用にはまだ多くの課題があるものの、適切なプロンプト設計によって可能性が広がることを確認しました。
今後もLLMを活用した業務効率化のため、新しいタスクを探し、試行錯誤を続けていきたいと思います。
