金芝-大模型加持如何改變需求工程任務.pdf

《金芝-大模型加持如何改變需求工程任務.pdf》由會員分享，可在線閱讀，更多相關《金芝-大模型加持如何改變需求工程任務.pdf（31頁珍藏版）》請在三個皮匠報告上搜索。

1、大模型加持如何改變需求工程任務金芝北京大學金芝北京大學教授IEEE/CCF/AAIA Fellow，高可信軟件技術教育部重點實驗室常務副主任，國家杰出青年科學基金獲得者。兼任國務院學位委員會學科評議組成員（軟件工程），中國計算機學會監事長，中國人工智能學會知識工程與分布智能專委會副主任。研究領域包括需求工程、代碼表示和軟件自動化。出 版 專 著 和 教 材 5 部，發 表 論 文 300 余 篇，5 次 獲 ACM SigSoftDistinguished Paper Awards。研究成果曾獲教育部科技進步一等獎、CCF技術發明一等獎、和北京市技術發明二等獎。獲CCF杰出成就（夏培肅）獎、I

2、EEE TCSVC 杰出領導力獎、中創軟件人才獎等。演講嘉賓目 錄CONTENTS1.需求工程2.痛點和挑戰3.語言模型的能和不能4.探索和討論什么是需求工程PART 01需求工程每一個“人造物”都是一個內部環境與外部環境的“接口”。這里內部環境指人造物本身的設計組成。外部環境指人造物的周遭及其作用環境。對這個接口的描述即是需求。軟件就是一種人造物，軟件的需求就是描述了軟件的外部環境描述與軟件內部設計描述的接口需求工程 軟件需要被塑造和創造 軟件是人造物，起初軟件并不存在 設計思維是：在開發軟件之前要考慮 為什么？哪里？哪個？什么？什么時候？如何？為什么需要軟件 哪里需要軟件 需要解決哪些問題

3、 軟件希望做什么 如何開發軟件 您期望該軟件的表現如何 軟件需要遵循哪些社會規律軟件目的性質量社會性功能性需求工程設計思維和設計創新https:/ 02表達和表達的內涵主觀的含糊的不充分的矛盾的(主觀上的/物理沖突）可能不現實的可放松的/強制遵循的約束確定的/不確定的行為友好的/惡意的使用環境友好的軟件需求工程軟件需求工程向下：技術可向下：技術可實現實現向上：滿足用戶期望向上：滿足用戶期望行業問題的行業問題的軟件解決方軟件解決方案案結構化、形式化、結構化、形式化、軟件架構軟件架構/行為行為/質質量等的需求規約量等的需求規約行業問題行業問題現實世界場景現實世界場景自然語言需求自然語言需求溝通不足

4、知識不足技術手段不足問題認識不足問題和解決方案的思維差異問題描述離散化 vs 軟件描述系統性行業需求條目（m*n）軟件規約條目行業需求”What I want”vs 軟件規約”How I can”軟件解決方案本身的問題：可靠性、安全性、保密性、隱私性、性能、基礎設施依賴性、目標驅動的構造Zave&Jackson 1997從現實問題出發：問題驅動分析“存在的即是合理的”“軟件是客觀世界的計算機化”“客觀世界和軟件系統的關系”忠于現實，將現實映射到系統。從軟件構造出發：E.W.Dijkstra 結構化程序“人的智力是有限的”“軟件開發是一件復雜的工程”“對一個龐大復雜的問題，要從程序結構上進行簡化

5、，從而得到一個結構清晰的程序”。https:/www.cs.utexas.edu/users/EWD/index13xx.html語言模型的能與不能PART 03語言模型的能與不能：語言模型語言是人類表達和交流的突出能力語言建模是推進機器的語言智能的主要方法之一語言建模旨在對詞序列的生成可能性進行建模，從而預測未來或缺失標記的概率大語言模型從大量文本數據中學習出處理和生成人類語言的能力大語言模型在自然語言處理任務方面取得了長足的進步大語言模型有可能應對溝通挑戰和知識差距語言模型的能與不能：語言模型的基礎能力 語言生成 語言建模：基于前序字符預測下一個字符 條件文本生成：給定條件下，生成滿足特定

6、任務需求的文本，如機器翻譯、文本摘要、問答等 代碼綜合：生成滿足特定條件的形式化語言文本，特別是計算機程序 知識利用 封閉文本問答：基于給定上下文，不利用外部資源，通過問答檢測語言模型的事實性知識 開放文本問答：語言模型給出答案的時候可以利用外部知識源 知識補全：將語言模型作為知識庫，補充和預測缺失的知識單元 復雜推理 知識推理：依賴邏輯關系和涉及事實性知識的證據，回答給定問題 符號推理：操作形式化規則設置中的符號，滿足一些特定的目標，其中，操作和規則可能是語言模型在訓練時沒有見過的 數學推理：在理解數學知識、邏輯和計算的基礎上，進行問題求解和生成證明語句語言模型的能與不能：激發語言模型的能力

7、 提示工程：設計和制定提示或說明，向大語言模型提供明確的指令，以指導他們生成準確和上下文相關的響應。目的：引導大語言模型朝著預期的輸出方向發展，提高其能力并使其與特定任務或目標保持一致。提示設計策略：基于指令的提示：向大語言模型提供明確的指令，指定響應的所需格式、上下文或樣式。對于需要特定輸出結構的任務特別有用?；谑纠奶崾荆合虼笳Z言模型提供相關示例，演示了所需的行為。通過提供正面和負面的例子，使模型學會概括和產生適當的響應。多輪對話提示：通過提供一系列對話輪次來模擬對話上下文，使大語言模型能夠生成保持連貫性和上下文連續性的響應。語言模型的能與不能：需求工程走上前臺“given the ex

8、pected progress in component reuse and automated programming technologies,will there be anything else left in software engineering,than requirements engineering?”-Axel Van Lamsweerde,ICSE2000W X Zhao,K Zhou,J Li,et al.,A Survey of Large Language Models,arXiv2303 18223v13https:/ vs 軟件描述系統性行業需求條目（m*n）

9、軟件規約條目行業需求”What I want”vs 軟件規約”How I can”軟件解決方案本身的問題：可靠性、安全性、保密性、隱私性、性能、基礎設施依賴性、語言模型的能與不能 溝通和信息獲取、理解用戶意圖 需求獲取涉及大量行業應用領域文檔的理解，LLM可以提供高效的數據和信息處理能力 需求信息獲取的多源性，帶來語言和文化多樣性挑戰。LLM能有效應對該挑戰輔助信息提取 作為大規模知識庫、進行缺失知識補全。假設語言模型擁有 行業知識：學習了行業文檔 設計知識：學習了設計文檔 完成需求描述從自然語言表示到結構化和形式化表示 從自然語言文本到結構化或形式化表示的轉換（類似翻譯）輔助進行初步的交叉檢

10、查，如完整性和一致性等表達和表達的內涵主觀的含糊的不充分的矛盾的(主觀上的/物理沖突）可能不現實的可放松的/強制遵循的約束確定的/不確定的行為友好的/惡意的使用環境友好的軟件需求工程軟件需求工程向下：技術可向下：技術可實現實現向上：滿足用戶期望向上：滿足用戶期望行業問題的軟件解決行業問題的軟件解決方案方案結構化、形式化、結構化、形式化、軟件架構軟件架構/行為行為/質質量等的需求規約量等的需求規約行業問題行業問題現實世界場景現實世界場景自然語言需求自然語言需求溝通不足知識不足技術手段不足問題和解決方案的思維差異問題描述離散化 vs 軟件描述系統性行業需求條目（m*n）軟件規約條目行業需求”Wha

11、t I want”vs 軟件規約”How I can”問題認識不足軟件解決方案本身的問題：可靠性、安全性、保密性、隱私性、性能、基礎設施依賴性、表達和表達的內涵主觀的含糊的不充分的矛盾的(主觀上的/物理沖突）可能不現實的可放松的/強制遵循的約束確定的/不確定的行為友好的/惡意的使用環境友好的軟件需求工程軟件需求工程向下：技術可向下：技術可實現實現向上：滿足用戶期望向上：滿足用戶期望行業問題的軟件解決行業問題的軟件解決方案方案結構化、形式化、結構化、形式化、軟件架構軟件架構/行為行為/質質量等的需求規約量等的需求規約行業問題行業問題現實世界場景現實世界場景自然語言需求自然語言需求溝通不足知識不足

12、技術手段不足問題認識不足問題和解決方案的思維差異問題描述離散化 vs 軟件描述系統性行業需求條目（m*n）軟件規約條目行業需求”What I want”vs 軟件規約”How I can”軟件解決方案本身的問題：可靠性、安全性、保密性、隱私性、性能、基礎設施依賴性、語言模型的能與不能：需求蘊含設計，設計引出需求 不是從需求域到設計域的單向變換 符合客戶期望的系統與行為：定義問題上下文、給出設計者對問題領域的理解；需求蘊含設計決策 設計引出進一步的需求，可能是細化的需求，也可能是由于技術的引入產生的新需求系統由誰使用（操作員？操縱員？值長？）系統需要做什么（提醒？確認？記錄？反饋？制度優化？）系

13、統要具備哪些性質（安全？高性能？易伸縮？易擴展？易用？）涉及哪些信息/數據/知識（設備、人員、工況、限值、規程）質量需滿足何種指標要求（響應時間、定位精度、可靠性指標）如何使用該系統（主動?交互式？響應式？無感？流程嵌入）對解決方案有何額外限制（自主？先進性？穩定性？兼容性？）核電裝置和監控臺語言模型的能與不能對復雜軟件而言需求到設計不是一蹴而就的，也不是簡單的單向變換Implementation DependenceLevel of DetailProblem descriptionsSolution descriptions探索和討論PART 04探索和討論：需求相關的提示模式探索和討論：

14、人機協作體系架構設計 構建軟件系統需要支持增量式系統化的方式，采用體系結構為中心方法（ACSE）賦予架構師角色，在 ACSE 流程中整合模式和風格（知識）、推薦系統（智能）和分布合作（協作）探討 ChatGPT 作為 DevBot 在協作式軟件架構過程中的作用。探索和討論：AI Agents協同目標建模 嘗試解決需求精化問題 語言模型：推薦特定行業問題及問題求解目標 語言模型：在特定行業目標精化策略指導下，利用推理能力，推薦精化子目標 仍處于需求和問題空間，未觸及軟件解決方案設計探索和討論：AI Agents協同嵌入式系統建模 嘗試大語言模型在嵌入式需求提取的潛力，包括利用大語言模型語言理解和

15、知識推理能力 基于大語言模型的人機協作式和Agent自主協作需求信息提取，探索大語言模型支持下的自動化需求信息提取和建模自主RE-Agents人機協作探討和討論：語言模型改變需求工程任務 LLM 很大程度上依賴于全面的提示和可用的上下文信息來生成有意義的輸出 稍微不同的提示可能會產生非常不同的輸出，若采用LLM作為需求代理，需要根據需求工程任務設計有針對性的提示，并對提示工程進行徹底的實證評估 有經驗的需求工程師在制定提示、解釋和獲得高質量輸出方面更成功 凸顯經驗和培訓在需求工程團隊中的重要性，理解需求任務的本質，提升提示工程的效能 LLM具有需求解釋和補全能力，但“幻覺”問題如何避免？LLM可以為不同的利益相關者輔助解釋和生成文本，這可能是減少不同項目團隊固有溝通障礙的關鍵。但，管理很多“誤報”的候選需求需要小心，以確保工程師不會因許多不相關或不準確的需求而增加工作負擔（大語言模型的“幻覺”問題）LLM 的固有問題 例如輸出中的系統性不準確或刻板印象（受訓練數據的影響），以及有限的上下文長度，例如，ChatGPT限制為 32K 個令牌，可能使處理大型文檔或在會話中維護任務上下文變得困難。需求工程需要對應用領域有很好的理解，以抽取和說明正確和完整的需求 LLM 對特定領域知識的訓練可能有限，需要通過專家、其他來源或微調的 LLM 來整合領域知識THANKS