要約作成とは、長い文書を、全体の作業の要点をとらえた簡潔な要約に凝縮する機能です。テクノロジーの観点から見ると、要約は難易度の高い機能です。長いテキストの理解、重要なポイントやトピックの特定、全体の作業の意図を捉えた新しいテキストの生成など、幅広い機能が必要とされるからです。幸いなことに、大規模言語モデル（LLM）は、これらのタスクに適しています。アーキテクトは、LLMを使用して、ユーザーが長いドキュメントを詳細に読む必要性を最小限に抑えるソリューションを作成できます。その結果、生産性が向上し、より快適なユーザー・エクスペリエンスが実現します。
アーキテクチャー
- 検索拡張生成
- エージェント・アシストとの対話
- 生成検索
- エージェント型AI
- 文書の要約
- モダナイゼーションとコードの生成
- Ansible向けコード生成
- Z向けコード生成
- エージェントを活用したAI拡張型ソフトウェア開発
上記の図は、要約パターンの2つの形式を示しています。パターンの最も単純な形式は、Stuffバリアントです。このパターンでは、
- ドキュメントの内容が読み取られ、「埋め込まれ」ます。例えば、その全文がLLMのプロンプトへコピーされます。
- プロンプト・テンプレートは、ターゲット・モデルに要約を生成するよう指示するために、指示とキーワードでコンテンツを「ラップ」するためによく使用されます。
- 結果のプロンプトは訓練されたLLMに送信され、応答として要約が生成されます。
Stuffアプローチは小さなドキュメントには最適ですが、LLMのコンテキスト・ウィンドウに対して大きすぎるドキュメントや、ドキュメントのコレクションには適していません。幸いなことに、このような状況に対応するMap-Reduceバリアントがあります。このバリアントのMapフェーズでは、個々の文書および／または文書のサブセクションが、Stuffアプローチを使用してLLMプロンプトに埋め込まれます。ドキュメントおよび/またはチャンクの要約が返された場合、アプリケーションによって集約され、LLM (4)に送信され、より大きな作業および/またはドキュメント・セットの全体的な要約が生成されます。同じLLMをMapフェーズとReduceフェーズに使用することは可能ですが、多くの場合、Reduceモデルは、重要な詳細を失うことなく集計サマリーを生成するために微調整する必要があります。
概念的には、要約は機械翻訳タスクに似ており、LLMに長い文書を短い要約に「翻訳」してもらいたいと考えます。したがって、BARTやT5のようなエンコーダー・デコーダー・モデルは要約ソリューションに適しています。要約に適したLLMの大部分は、ニュース記事、Wikipedia、法律、科学出版物などの情報源から抽出された1つ以上の一般公開されているトレーニングセットを使用してトレーニングされますが、対象となるビジネスプロセスやインプット・データに適合する要約を生成する前に、通常ファインチューニングが必要です。
複雑なビジネスプロセスでは通常、さまざまなユーザー・グループの要約を生成するために、複数の微調整されたモデルが必要になります。例えば、保険金請求プロセスでは、請求の要約とルーティング、不正アクセス検知と調査、医療コンサルタントやエンジニアリング・コンサルタントなどのサービス・プロバイダーからのレポートの要約向けに微調整したLLMが必要になる可能性があります。
要約は、ユーザーが日常的に大規模なドキュメントを読んで理解する必要があるものの、ビジネスプロセスの後半までドキュメントの内容に関する深い知識を必ずしも必要としないあらゆるビジネス・シナリオの候補ソリューション・パターンです。
次のようなユースケースがあります。
保険金請求の審査。保険請求、特に複雑な商業およびグループの健康保険の請求は、提出と審査のプロセスの中で複数回精査されることがよくあります。多くの場合、最初に請求書を読み、請求を処理する適切な部門および鑑定人を決定します。独立した評価報告書を理解してそれに基づいて行動し、対象範囲を決定し、潜在的な不正行為を評価するには、さらに詳しい資料を読む必要があります。テキストから関連するポイントを抽出する要約ソリューションは、これらのプロセスを大幅に改善する可能性を秘めています。
契約。商業契約は複雑で理解しにくいことがよくあります。たとえ比較的単純な取引であっても。契約の重要な契約条件を平易な言葉で要約できる要約ソリューションは、複数の業界のビジネスパーソン、弁護士、パラリーガルにとって大きな恩恵となる可能性があります。
医療要約。患者記録から医療要約を作成することは、正しく行うためにかなりの専門知識を必要とする骨の折れる作業です。大規模な患者記録の主要要素を抽出し、記録のコーディング（ICD-10やその他の診断コーディング・スキームを使用）を支援できる要約ソリューションにより、抽象化プロセスの速度と一貫性の両方が向上します。
製品およびサービスのサポート。カスタマー・サポート・スタッフは、顧客とサポート・チームとの間の多種多様なやり取りに及ぶ問題解決の取り組みを選んだり再開したりするよう求められることがよくあります。要約ソリューションは、サポート・ケースを正確に要約することで、サポート・スタッフがケースの対応を迅速に行うために必要な時間を短縮し、理想的には、ケースの解決に必要な時間を短縮します。
要約ソリューションでは、アーキテクトがソリューションの機能要件および非機能要件を達成するために、多くの重要な決定を下す必要があります。
生成モデルの選択
上記で文書化したように、多くのLLMは「すぐに」テキスト要約を実行することが可能です。モデルに内在する機能がソリューション要件を満たしている場合、アーキテクトは、モデルのサイズ（これによりインフラストラクチャーの要件が左右される）、応答の品質、推論速度などの要素を考慮する必要があります。ファインチューニングが必要な場合は、チューニング用データの量と、選択した基本モデルを特定のニーズに合わせて調整するために必要なチューニング・プロセスの複雑さも考慮する必要があります。
評価メトリクス
生成AIソリューションのパフォーマンスを評価することは、そのタスクの定性的な性質（例えば、どのようにしてあるものが別のより「優れた」要約を生成したのか）のため、困難な場合があります。一般的な指標には、複雑さ、流暢さ、関連性、一貫性などがあります。BLUメトリクスとROUGEメトリクスもこれに含まれます。アーキテクトは、ソリューションの機能要件と全体的なビジネス目標に合致するメトリクスを選択する必要があります。