『ご要望に合わせたチャット：ソフトウェア要件に応用した生成AI（LLM）の旅』
Chat tailored to your needs The journey of applying generative AI (LLM) to software requirements
デジタル時代において、大企業は既存のシステムやプロセスの理解不足に苦しんでいます。知識はシロに閉じ込められ、さまざまなチームや専門家の間に散在しています。この分散は技術的負債の成長に大きく寄与し、組織の俊敏性と生産性を徐々に妨げる静かな殺人者となります。Curiosity Softwareでは、過去5年間、構造化された要件（ビジュアルモデルを通じて）の作成と数百のDevOpsツールへの接続に取り組んできました。これにより、Generative AIの実装時には非常に有利な立場にいると考えています。モデルとDevOpsアーティファクトは、組織のソフトウェア開発環境を通じて流れるデータへのアクセスの中心的なハブとして機能することができます。
技術的負債と知識の欠落という一般的な課題に立ち向かうための私たちの使命の一環として、私たちはソフトウェア要件とビジネスロジックにLarge Language Models（LLM）を適用する旅に出ました。私たちの目標は、組織のソフトウェア要件のための知識ハブを作成し、知識を発見し技術的負債を返済するために照会できる状態にすることでした。
Large Language Models（LLM）の領域を理解する
私たちの経験と洞察を議論する前に、Large Language Modelsの概要を簡単に説明しましょう。LLM（例：OpenAIのGPT-4）は、人間の言語を理解し生成することができます。彼らは、様々なトピックと言語スタイルを含む膨大なデータコーパスから学習します。
これらのLLMは、Transformerとして知られる深層学習モデルで動作し、セルフアテンションメカニズム（ニューラルネットワーク）の層を使用してデータ内の文脈を分析し理解します。トレーニング中、彼らは数え切れないほどの文や段落を読み、文の次に何が来るかについて予測を行います。これらの予測は、これまで読んだ内容に基づいています：
LLMの素晴らしい点は、人間のようなテキストを生成する能力です。これは、大規模なデータコーパスでトレーニングされ、モデル内のパラメータまたは重みの数が非常に多い（GPT-4は数千億個）場合に発揮されます：
この人間のように反応する驚異的な能力は、アルゴリズムに固有の知能だけでなく、人間の言語が最初に思われていたほど複雑ではないという発見にも帰因しています。
ニューラルネットワークを十分な数の人間の言語のインスタンスにさらすことで、LLMはパターンを見分け、適切に応答することができます。LLMがトレーニングされるデータのサイズと品質が増すにつれて、LLMの能力は指数関数的に成長します。
構造化データはLLMの成功に不可欠
現在のソフトウェア組織にとって、LLMを活用する能力は以前にも増して近づいています。ローカルPC上で実行可能な非常にコンパクトで専門化されたモデルがあり、GPT-3.5と同等のパフォーマンスレベルを提供しています。
しかし、LLMの最も重要な要素は利用可能なツールではなく、LLMがトレーニングされたデータです。そのため、現在の組織はソフトウェア領域で構造化されたデータが不足しているため、LLMの成功を妨げる主要な障害となっています。
ソフトウェア要件は通常、構造化されていないテキスト形式で保存され、さらには不完全で曖昧な情報が欠落していることもよくあります。テストケースも同様であり、テキストベースのテスト手順のリストとして保存されることがしばしばあります。
この構造化データの問題を克服するためには、革新と慎重な考慮が必要です。情報抽出、自然言語理解、機械学習などの技術を使用して、構造化されていないデータを構造化されたデータに変換することができます。このプロセスには、しばしば人の手による介入が必要です。
LLMをトレーニングする代替策は、構造化されていないテキストデータにトレーニングしようとするのではなく、最初から構造化された要件を作成するか、構造化されていないデータを中間形式の構造化された要件に変換することです。
これは、モデル化された要件が言語モデルのトレーニングのためのAI対応要件の作成に力を発揮する場所です。モデルを使用して既存のデータを構造化し改善し、既存のSDLCアーティファクトをモデルと統合して中央の知識ハブにすることができます。
ソフトウェア要件のモデリングとは何ですか？
モデルベースのテストは、対象の機能のモデルを使用してテストケースを生成します。これらのモデルは通常、システムの動作、機能、または操作を示す視覚的なフローチャートとして表現されます。
このようなモデルを使用することで、曖昧さを減らすことができ、開発者とテスターの両方が要件を理解しやすくなります。さらに、モデリングにより、テストケース、データ、自動化の自動生成が容易になります。ソフトウェア要件の変更はモデルを変更することで反映することができ、動的で更新されたテスト資産を実現します。
フローチャートは、複雑なプロセスをわかりやすい方法で視覚化する手法です。各ステップをボックスやシンボルとして表示し、それらの間の矢印でユーザーやデータのフローを示します。これにより、プロセスのシーケンスと意思決定ポイントが明確に表示され、操作の順序が強調されます：
通常、モデルベースのテストを活用している組織は、再利用可能なモデルのライブラリを作成し、それらを接続してより豊かなエンドツーエンドのシナリオを高速で構築することができます。コンポーネント化のプロセスにより、チームはテスト資産の作成をはるかに速く進めるだけでなく、効率的なアプローチで変更に対応することもできます。
フローチャートはLLM向けに構造化されています
フローチャートは本質的に構造化されています。大規模な言語モデルのトレーニングにおいては、フローチャート形式の構造化データは非常に強力な結果を生み出すことができます。
さらに、フローチャートは直感的で解釈しやすいため、クエリに理想的です。制御の流れや意思決定プロセスが明確に描かれており、モデルがプロセスの次のステップを予測することが容易です。
さまざまなステップ間の関係を推論する能力により、フローチャートはクエリングとLLMのトレーニングの両方に特に価値があります。以下は、シンプルなモデルにクエリを実行するためにLLMを使用する例です。以下のモデルは、学生の普通預金口座申請プロセスを描いたものです。
プロンプト: 学生が学生用普通預金口座の申請を承認されるためには何歳以上でなければなりませんか？
レスポンス: 18歳以上です。
プロンプト: 学生が学生用普通預金口座の申請を承認されるためにはどうすればよいですか？
レスポンス: 学生用普通預金口座の承認を受けるためには、まず学生が個人情報を入力する必要があります。その後、18歳以上であることを確認するために年齢を検証します。年齢が18歳以上であることが確認されたら、学生は学生の身分を証明するために入学証明書を入力する必要があります。これらの基準がすべて満たされ、申請が成功した場合、学生は学生用普通預金口座の承認を受けます。
ソフトウェア要件との対話
LLMがフローチャート（モデル）のクエリと推論を行う能力と、CuriosityがDevOpsツールに組み込んださまざまなコネクタの範囲を考慮すると、私たちはLLMをフローチャートとDevOpsアーティファクトに適用することを目指しました。異なるDevOpsアーティファクト全体からのデータをモデルと組み合わせ、LLMのための中央の知識ハブを作成することを目指しました。
私たちは、ソフトウェア要件（JIRAから取得したもの）と組織のTest Modellerワークスペースに保存されたモデルの配列にLLMを適用してトレーニングしました。このプロジェクトでは、銀行アプリケーションのための一連のタスクを持つJIRAプロジェクトと、テキストベースの問題に作成されたモデルがあります。これらのモデルは追加の構造をオーバーレイし、要件を完全にし、LLMが必要とするデータを作成します。
以下は、例のチケットです。
上記の「壁のテキスト」ユーザーストーリーと下記の視覚的な要件を比較すると、クレジットカードの申請ロジックを理解するのがはるかに簡単になることがわかります。これは、フローチャートの固有の構造と視覚的な性質によるものです。
Test Modellerワークスペースに同期されたフローチャートとJiraチケットのコレクションは、LLMのための知識ハブを提供します。クエリを実行すると、LLMはそれ以外の分散したSDLCアーティファクト全体に格納されている情報を活用し、推論することができます。たとえば、複数のJiraチケットに格納されているデータなどです。
では、例として、銀行ソフトウェアの要件とモデルにトレーニングされたLLMを使用してこの知識ハブをクエリするいくつかの例を見てみましょう。
例1：シンプルな質問
まずはじめに、期待される結果を持つシンプルな質問から始めましょう。識別子が与えられた場合のJIRAチケットの詳細を教えてください。
プロンプト: JIRAチケットCB-13の詳細は何ですか？
チケットの概要が返ってくるかどうかを確認します。
例2：モデルを使った暗黙の推論
この例では、少し深く掘り下げて、LLMがフローチャートを理解し、それから答えを推論することができる質問をします。具体的には、クレジットカード申請プロセスについてです。
プロンプト: クレジットカードの申請を完了するために必要なクレジットスコアは何ですか？
LLMはクレジットカード申請プロセスのフローチャートをキャプチャし、モデルを解釈しました。そして、この解釈を使用して、必要なクレジットスコアを700以上と計算しました。
例3：モデルと要件を使った暗黙の推論
このプロンプトでは、質問に答えるためにLLMが複数の情報源を中断する必要があります。モデルと対応する要件を参照します。
プロンプト：お客様はいつクレジットカードを申し込むことができますか？
例4：複数要件の推論
このプロンプトでは、クロス要件クエリに答えるために、複数の要件を理解し推論する必要があります。応答で、3つのユーザーストーリーが参照され、個人が良いクレジットスコアを持っている場合にのみ製品が利用可能であることが答えられます。
プロンプト：クレジットが良い場合、どの商品を申し込むことができますか？
デモ：LLMを使用して構造化フローチャートデータをクエリする
私がこの記事を書く際に使用したJiraのユーザーストーリーから情報を中央の知識ハブに同期させ、クエリを実行する様子をご覧ください：
LLMを採用してソフトウェアの提供を向上させる
Curiosity Softwareは、Large Language Models（LLMs）（たとえばOpenAIのGPT-4）を活用してソフトウェアの要件とビジネスロジックを理解し、管理することで、技術的負債に対処することに注力しています。
LLMsは構造化データを重視しているため、モデルベースのテストは非構造化データの完了と曖昧さの除去に最適なツールです。モデルはビジュアルフローチャートを使用してソフトウェアの要件を表し、それによって明確さを提供します。同時に、DevOpsツールとアーティファクトからの情報を中央の知識ハブに同期することもできます。
このアプローチにより、テストケース、データ、自動化の自動生成も可能になります。Curiosity Softwareでは、さまざまなDevOpsツールから抽出されたソフトウェア要件の幅広いスペクトルでLLMsをトレーニングしています。これらの要件は、組織のTest Modellerワークスペースにモデル化されます。これにより、クエリされたときに全体のSDLCの説明を提供する共同パイロットとダッシュボードが作成され、リスク、リリース、テストカバレッジ、コンプライアンスなどの意思決定をサポートします：
さらに、前回の記事で説明したように、Generative AIを使用してモデルを生成することもできます。これにより、フィードバックループが完了します。人間はGenerative AIと協力して、フローチャートやより広範なSDLCアーティファクトのデータに基づいてモデルを作成し、改善することができます。その結果、開発者に正確な仕様を提供しながら、彼らが作成するコードを検証するためのテストも生成されます。
AIによるソフトウェア要件のこの応用は、ソフトウェア開発プロセスの効率と効果を向上させ、組織のビジネスプロセスの知識ハブとして機能し、最終的に技術的負債に対抗するのに役立ちます。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
