使用生成式AI進行軟體調試

原创 岱军 云云众生s
UMass Amherst的Baldur方法能夠自動產生用於驗證程式碼、防範漏洞的證明。

譯自Debugging Software Using Generative AI,作者 Jeffrey Burt 是一位資深記者,擁有三十多年的新聞工作經驗,過去二十多年專注於科技領域。 在過去的16年多里,他曾在eWEEK工作,並在之後成為自由科技記者。

自從OpenAI於2022年11月底推出其ChatGPT聊天機器人以來,生成式人工智慧工具和大型語言模型(LLM)的採用只有加速,深入滲透到各種形狀、大小和行業的組織中,而軟體開發人員並 未對其產生免疫。

生成式人工智慧的用例,如內容創作、對話式人工智慧和語言翻譯,在軟體開發中是多樣化且不斷增長的,涉及程式碼優化和生成、錯誤修復、文件編寫以及持續整合等方面。

根據卡內基美隆大學SEI部落格中的AI專家在2023年10月的一篇文章稱,開發人員越來越認為生成式人工智慧是一個有用的工具。

作者寫道:“關於使用LLM進行軟體開發的最初炒作已經開始冷卻,現在的期望更加現實。”,“對話已經從期望LLM取代軟體開發人員(即人工智慧)轉變為將LLM視為合作夥伴, 並集中在最佳應用它們的地方(即增強型智能)。”

LLM和軟體驗證
上個月,由馬薩諸塞大學阿默斯特分校的電腦科學家領導的一組人表示,他們正在利用生成式人工智慧和LLM的力量來解決驗證程式碼的棘手挑戰,以幫助防止軟體中的漏洞。

具體而言,該團隊專注於利用人工智慧開發一種方法,自動產生完整的證明以用於驗證軟體程式碼。 這是一項費時、昂貴且耗時的過程,通常透過手動程序完成。 更困難的過程是機器檢查:創建一個數學證明來展示程式碼是否符合預期,然後使用定理提供者確保證明的正確性。

Emily First在完成她的電腦科學博士學位後成為加州大學聖迭戈分校的博士後研究員,而她在馬薩諸塞大學阿默斯特分校攻讀博士學位期間的研究涉及LLM和軟體驗證,並成為她博士論文的一部分。 她指出,手動編寫證明所需的時間可能比編寫軟體程式碼本身還要多。

因此,根據馬薩諸塞大學阿默斯特分校資訊與電腦科學曼寧學院的教授、本文的高級作者Yuriy Brun的說法,實際上經過正式驗證的系統數量相當有限。

「這很難,」Brun告訴The New Stack。 “這就是我們介入的地方。我們試圖解決的問題是自動產生這些證明。”

不應該接受有錯誤的軟體
這樣做將有助於解決一個更大的問題:軟體中存在缺陷,這可能是煩人的,或者——如果被網路攻擊者利用或存在於可能對廣泛產生負面影響的複雜系統中——是危險 的。

「軟體是我們日常生活中重要的一部分,」布倫說。 「你什麼都做不了。你不能開車,不能坐電梯,都離不開軟體。不幸的是,今天的軟體通常是有漏洞的。我們幾乎期望在商店購買的任何軟體都會有一些錯誤。這只是 一個難以解決的問題,因此有很多不同的方法來嘗試提高軟體的品質。”

其中一個方法是證明軟體是正確的。 這是一種有效的方法,但也是最困難的方法之一。 在某些領域,這已經被實踐,例如在醫療領域用於某些醫療設備或由NASA使用,「因為如果你的太空船上有一個錯誤,你的軟體崩潰了,那將是代價高昂的, 所以實際上有開發人員和軟體工程師正式證明函數的正確性是值得的。」他說。

一些研究人員已經創建了能夠一行一行地寫證明的模型,先寫證明的前10行,然後讓模型基於已經寫的內容以及試圖證明的內容搜索,找出下一行最有可能是什麼。

建構Baldur
馬薩諸塞大學阿默斯特分校的研究人員將目光投向LLM,作為自動產生證明的可能解決方案。 然而,即使這也帶來了挑戰,最大的挑戰之一是這些模型並不總是正確的。 與其崩潰——從而讓開發人員知道有些事情出錯了——它們會“悄悄失敗”,生成一個錯誤的答案但將其呈現為正確的。 悄悄失敗通常是最糟糕的事情,布倫說。

EnterBaldur,這是馬薩諸塞大學阿默斯特分校團隊創建的一種新的基於人工智慧的證明方法。 研究人員使用了Google的Minerva LLM,該模型經過大量自然語言文本的訓練。 然後,它進一步在118GB的數學科學論文和包含數學表達式的網頁上進行訓練,然後在Isabell/HOL上進行了更多的訓練,這是一種用於編寫數學證明的語言。

然後,Baldur產生了整個證明,使用Isabelle,一個定理證明器,對整個世界進行檢查。 如果檢查器發現錯誤,有關錯誤的資訊會回饋到LLM中,以便讓它從錯誤中學習,然後產生另一個證明,減少或——希望是沒有錯誤。

這樣做給了Baldur「一些上下文訊息,以說,『關於狀態,關於你正在回答我的問題的問題,這裡有更多的信息,』」布倫說。 「當我們給它額外的資訊時,它能夠更好地回答問題。我們只修復了一次,但你可以想像多次修復,對於這些一次只能預測一個步驟的模型來說,即使它們使用大型語言 模型逐步預測,這也更加低效。”

Enter Thor
布倫及其團隊(當時還包括在Google工作的Markus Rabe和伊利諾伊大學厄巴納-香檳分校的助理教授Talia Ringer)研究了Thor,一個用於整合語言模型和自動定理證明器的框架。 獨立運作時,Thor能夠在57%的情況下產生證明,他說。

將其與 Baldur 結合——在北歐神話中是托爾的兄弟——他們成功地在65.7%的時間內創建了證明。 這兩種方法互相補充。

Thor「使用大型語言模型嘗試預測證明的下一個可能步驟,但它也使用了一些被稱為『錘子』的東西,」布倫說。 「錘子是這些數學工具,它們說,『我知道一堆數學標籤。讓我嘗試一下。讓我試試這個,試試這個,試試這個。』就像用錘子敲擊問題,嘗試不同的方法 ,看看是否有效。它同時嘗試所有這些方法。”

Baldur方法不同之處在於它創建整個證明而不是逐行進行,儘管存在重疊,他說:「有一些它們都能證明的事情。但透過嘗試一次性生成整個證明,我們能夠證明一組不同的事情 ,而不是嘗試逐步生成一件事。”

仍有更多工作要做
布倫承認錯誤程度仍然很大,但稱Baldur仍然代表了驗證軟體程式碼正確性的最有效和高效的方式。 AI技術不斷改進,因此他預期Baldur的能力也會提升。

在未來,研究人員計劃透過調整LLM訓練的數據來提高65.7%的數字。 對於驗證而言,目前並沒有太多的數據,因此建立數據集並不容易。 他們正在努力創建一個資料集,以便對模型進行微調。

他們還希望使開發人員能夠向模型提供回饋,這將進一步幫助模型在產生證明的過程中不斷成長。

「開發人員說,『好的,運作得很好,』」布倫說。 「但如果它沒有運行,開發人員通常可以查看[然後說],『我看到你在這裡嘗試了歸納,但你把它用在了錯誤的地方。』 它可以向模型提供一些反饋,然後模型 可以再次嘗試。這種迭代的方法很可能真正簡化開發人員的工作,但也使模型能夠證明它自己無法完成的事情。”

這創造了一種半自動化的方法。

「原始的迭代方法不涉及開發人員,」他說。 「它是在自己進行迭代,一次只做一件事,因為它是……自己進行所有操作,自己檢查。我們試圖重新引入軟體工程師到這個循環中,因此這是一種半自動化的方法,我們 在很多自動化方面做了很多工作,但然後我們從工程師那裡得到了一些反饋,以引導在我們無法自行完成整個過程的情況下進行處理。”

研究人員從2020年開始致力於這個挑戰,但Baldur的工作始於2023年5月,從在Google內部建構到評估和確保科學正確性,歷時約五個月。 該計畫得到了國防高級研究計劃局(DARPA)和國家科學基金會的支持。

雲端環境下的儲存服務類型和儲存技術

原创 twt社区
雲端環境下的儲存服務類型和儲存技術
一、儲存服務的類型

儲存服務的類型依資料類型的不同,一般分為區塊儲存、檔案儲存和物件儲存三類。

區塊儲存基於傳統的磁碟陣列實現,將儲存區域劃分成固定大小的區塊,以磁碟區的方式掛載到主機作業系統後,作業系統可將其格式化成檔案系統,或以裸資料的方式作為資料庫的 儲存。 區塊儲存方式不存在資料打包和解包過程,因此應用系統跟儲存系統耦合程度緊密,資料存取延遲低、效能高。

檔案儲存指的是儲存媒體上儲存的是目錄-子目錄-檔案這種形式的資料結構。 這種資料結構是我們自然人所能容易辨識的數據,絕大部分由身為自然人的程式設計師所編寫的各種軟體程式也使用這種方式來存取檔案。 因此文件儲存的特點是一方面可讀性高,另一方面存取資料需要先遍歷多層文件目錄。

物件儲存採用基於鍵值存取機制的扁平化儲存架構設計,它沒有多層樹級檔案目錄。 在物件儲存系統中,物件是資料儲存的基本單元,所有物件都有一個物件標識,透過物件標識OSD指令存取該對象,使用簡單,小IO效能好。

二、雲端環境下的儲存技術

隨著電子商務、雲端原生、微服務、分散式應用程式、DevOps等現代應用架構的流行,使用者開始將越來越多的傳統應用進行改造和重構,遷移到雲端環境。 那麼在雲端環境下有哪些儲存技術可供選擇使用呢? 以下針對雲端環境提供的區塊儲存、文件儲存和物件儲存三類儲存服務,簡單講講對應的儲存技術。

1. 塊存儲

雲端環境的區塊儲存技術主要包括使用集中式區塊儲存和分散式區塊儲存兩種技術路線。

1) 集中式區塊存儲

作為目前最流行的IaaS框架 ,OpenStack架構中有一個獨立的元件叫做Cinder。 Cinder是OpenStack中提供儲存服務的API框架,用來為後端不同的儲存結構提供統一的介面。 不同的區塊設備服務廠商在Cinder中實現其驅動支援。 後端的儲存可以是DAS、NAS、SAN、物件儲存或分散式檔案系統。 由於在雲端運算領域OpenStack受歡迎度非常高,因此眾多儲存廠商如NetAPP、IBM、 DellEMC、華為和眾多開源區塊儲存系統均提供了對Cinder的支持,這也為在雲端平台基礎架構層使用集中式 SAN儲存提供了技術基礎。

當使用者規劃在雲端平台下使用集中式區塊儲存時,需要先考慮兩個面向。

第一,自己使用的雲端平台是不是基於OpenStack開發的,如果不是,那可能沒有SAN的介面。 國內的主流雲端平台產品大都是基於OpenStack開發的,但也存在少量的自研雲端平台。

第二,基於OpenStack的雲端平台透過使用Cinder來對接FC-SAN集中式存儲,Cinder只提供框架,需要透過呼叫FC-SAN設備廠商提供的Driver來使用和管理。 這方面需要雲端平台廠商配合。 目前國內大部分基於OpenStack開發的雲端平台產品中已經整合主流儲存廠商的FC驅動,可以讓Cinder與儲存底層對接,得到更高且更穩定的效能表現。

2)分散式區塊存儲

分散式區塊儲存是分散式儲存架構下的一個儲存介面。 目前主流分散式儲存技術主要分HCI超融合基礎架構及SDS軟體定義分散式儲存。 主流SDS分散式儲存又分為Ceph系和非Ceph系。 在大規模雲端環境下,SDS軟體定義分散式儲存適配度更高。

2. 文件存儲

文件儲存技術依照底層硬體架構可分為集中式NAS儲存和分散式檔案系統。

集中式NAS儲存生態完善,在各大企業資料中心檔案共享服務中佔很大比例。 集中式NAS儲存設備由機頭和擴充櫃組成,整合度高,運作維護相對簡單。

分散式檔案系統與集中式NAS相比,差異在於提供了平行化和橫向擴展的能力。 分散式檔案系統依架構有無中心分為兩類,一種是有中心架構的分散式檔案系統架構,包括GFS、HDFS等。 另外一種是完全無中心的分散式儲存架構,包括CephFS、GlusterFS等。 其中CephFS和GlusterFS支援POSFIX 介面。

GFS和HDFS的預設最小儲存單元為64M、128M甚至更高,是適合大檔案尤其是GB等級的大檔案儲存場景的分散式儲存系統。

GlusterFS是採用無中心對稱式架構,沒有專用的元資料伺服器,元資料存在於檔案的屬性和擴充屬性中。 資料分片分佈,也更適合大檔案儲存。

CephFS是分散式儲存系統Ceph檔案儲存的接口,CephFS 建構在RADOS(Ceph的核心技術-分散式物件儲存)之上,繼承RADOS的容錯性和擴充性,支援冗餘副本和資料高可靠性。

3. 物件存儲

物件儲存採用基於鍵值存取機制的扁平化儲存架構設計,它沒有多層樹級檔案目錄,天生具有分散式的架構優點,擴充方便。

物件儲存使用簡單,客戶端呼叫API就能進行資料儲存與讀取,其介面就是簡單的GET、PUT、DEL等。 物件儲存提供了基於物件的存取接口,有效地合併了NAS和SAN的儲存結構優勢。

三、雲端環境下的各類儲存技術的適用場景

1. 塊存儲

分散式區塊儲存的優點在於擴充性,所以適用於雲端環境下大規模的虛擬機器、容器場景。 另外,MySQL、MongoDB等輕量級資料庫場景也可以選擇使用分散式區塊儲存。

對於IO密集型資料庫應用程式來講,目前最好的儲存模式仍是採用高效能低延遲的集中式高階儲存陣列。

另外,針對雲規模相對不大,但業務重要性較高的業務場景,可以選擇使用基於OpenStack的雲平台通過Cinder接口來對接集中式存儲,為該類重要應用獲得更高和更穩定的存儲性能 。

2. 文件存儲

集中式NAS支援POSFIX接口,與現有應用整合簡單,適合小規模應用環境的快速部署。

GFS適合儲存大文件,尤其是GB級別的大文件儲存的場景。 HDFS適合單次寫入多次讀取的大檔案串流讀取的場景。

GlusterFS基於無中心化架構,沒有元資料伺服器,具有高擴充性、高可用性、高效能,能夠處理千數量級的客戶端,且可配置性較強。

CephFS也支援POSFIX接口,它使用Ceph儲存叢集來儲存數據,因此能夠解決NAS 產品scale-out橫向擴展不足的缺點,與使用Ceph儲存的雲端環境最適配。

GlusterFS和CephFS可以作為在大規模雲端環境下取代NAS的通用分散式檔案系統儲存技術,也是現在分散式NAS的發展方向。

3. 物件存儲

物件儲存接近無限擴展能力使其可以真正意義上實現非結構化資料的海量儲存。 其扁平化的存入和讀取資料物件方式,使其使用方式簡單,應用經過標準 API 介面進行調用,十分契合互聯網大數據的儲存。 物件儲存適合儲存包括多媒體、音樂、圖片、影片監控檔案、軟體、鏡像、掃描件等種類在內的大量檔案。

另一方面也要注意,物件儲存不支援隨機讀寫操作,只能全讀全寫,其面向的是一次寫入,多次讀取的非結構化資料儲存的需求場景。

無線網路(WLAN)系統中無線AP頻道的劃分

通信弱電交流學習
什麼是WLAN?
WLAN是Wireless Local Area Network的簡稱,指應用無線通訊技術將電腦設備互聯起來,構成可以互相通訊、實現資源共享的網路體系。 無線區域網路本質的特點是不再使用通訊電纜將電腦與網路連接起來,而是透過無線的方式連接,從而使網路的建置和終端的移動更加靈活。

它是相當便利的資料傳輸系統,它利用射頻( RF)的技術,使用電磁波,取代舊式礙手礙腳的雙絞銅線所構成的局域網絡,在空中進行通信連接,使得無線局域網路能利用簡單的存 取架構讓使用者透過它,達到「資訊隨身化、便利性走天下」的理想境界。 上面說了這麼多,可能不是很清楚,舉個最簡單的例子,我家用無線網絡,無線路由器就是提供WLAN的最基礎設備,比如公司的無線辦公網絡,酒店的無線網絡,公共場所提共的 無線網絡,都是屬於WLAN的範圍。

什麼是頻道?

頻道通俗來說就是頻率,它決定了無線AP是在哪個頻率範圍內進行通訊的。

考慮到相鄰的兩個無線AP之間有訊號重疊區域,為確保這部分區域所使用的訊號頻道不能互相覆蓋,具體地說訊號互相覆蓋的無線AP必須使用不同的頻道,否則很容易造成各個 無線AP之間的訊號相互產生幹擾,進而導致無線網路的整體效能下降。

2.4G頻段的頻道劃分

2.4G 頻段的頻帶寬度有 83Mhz,被劃分為 13 個頻道,每個頻道頻寬 22Mhz,那就表示這些頻道必然有重疊的部分,以下是 2.4G 的頻道圖:

2.4G頻道圖

5.8G頻段頻道劃分

5.8G 頻段被劃分為13 個頻道,頻段不連續,36-64 頻道的頻帶範圍是5.150GHz-5.250GHz,149-165 頻道的頻帶範圍是5.725GHz-5.845GHz,頻道頻寬可調,可選擇20Mhz 或40Mhz,那就意味著這些頻道必然有重疊的部分,以下是5.8G 的頻道圖:



2.4G和5.8G頻段不重疊頻道
2.4G頻段不重疊頻道規劃方案

上述2.4G頻段的13個頻道中,選擇(1、6、11)、(3、8、13)或(1、5、9、13),可以看到這三組頻道每一組的三個 頻道是不重疊的,如下圖:

5.8G頻段不重疊頻道規劃方案

上述5.8G頻段中頻道頻寬可調,其中20MHz頻寬的頻道基本上沒有重疊,規劃優先考慮使用此頻道頻寬。

有沒有發現,我們監控常用的無線網橋也有這兩個頻段,在不同場所,選用不同的頻道是一個很關鍵的因素,比如,你網速達不到運營商給提供的速度,這可能就是 您沒有選好頻段和頻道引起的。

部署多少個無線AP及AP頻段選擇注意事項

對於面積小於150平方米的普通開放空間,如酒店公共休息區,小酒吧,咖啡廳,會議室,西餐廳等區域,預計用戶數量不超過30個時,每個場所放置一個無線AP即可滿足 需求。

如果是多阻隔且面積較大的環境,AP部署個數多了怕同頻段干擾導致訊號差不穩定,部署少了又怕覆蓋不全有訊號盲區,這時候可以選擇雙頻的AP產品來覆蓋。

無線AP的頻段分為2.4GHz和2.4GHz&5.8GHz,雙頻相較於單頻具備速度更快、幹擾更低的優勢,可以說更適用於現在和未來,當然雙頻的AP價格也更貴 。

正確選擇無線AP的安裝點

WiFi訊號的傳輸方式是以無線AP為中心,呈圓形向水平方向四周散射。 遇到牆壁等障礙物時可反射或改變方向。

單人房間安裝一個無線AP,盡量把無線AP放在大廳的中央位置,最好選擇放置於大廳的天花板上,若安裝兩個無線AP,可將其放置在大廳的兩個對角線上。

AP的無縫漫遊

AP的無縫漫遊功能在較大環境的組網中十分重要,舉例來說在一家商場A點連接無線上網,走到B點確是另一個無線AP在做覆蓋,這時候要重新輸入密碼連接 無線十分繁瑣,就牽涉到了無線AP的無縫漫遊問題。

無線AP每隔100ms發送一次偵測訊號,用戶端可據此判斷網路連線品質,然後決定接取哪一個無線AP。 當終端在多個無線AP間的漫遊時,由新的服務無線AP透過有線的形式通知原服務AP,已建立新的連線。 無線AP的漫遊協定不包含在802.11中,而IAPP(Inter access point protocol)很有可能成為標準的漫遊協定。

無線AP的發射功率

無線AP的發射功率決定發射出去無線訊號的強度和距離,發射功率越大,訊號強度越強,同時發射距離也相對較遠。 如果使用者環境相對簡單選擇一般發射功率的AP就行。 若環境複雜,終端接取用戶較多,選擇高功率AP效果較佳。

當然無線AP的功率越大輻射越大,國家對無線設備的最大發射功率也是有法規規定的。

了解外界的干擾物

一些和無線AP同頻段的電子設備會影響無線AP的訊號,這點是需要注意的,包括微波爐、防盜設施(商場門檢)、其它大功率的電子設備等,所以在部署AP時,應該遠離 幹擾源1—2公尺。

當AP與終端之間隔著一堵水泥牆時,有效傳輸距離不到5公尺。 隔著一面木板牆和玻璃牆時,有效傳輸距離大概在15公尺內。

其它注意點

部署時的選址要滿足施工要求,要了解無線AP覆蓋半徑的技術參數,無線AP要選擇耐高溫、防潮、支援PoE供電的,使用AC控制器集中管理,相鄰的AP的頻道設定也是不同 的。