醫療AI會考試不等於會看病，美國權威醫院研究登Nature：國考92分、臨床任務僅44.8分

來源：https://www.ithome.com.tw/news/176785

大型語言模型（LLM）近年在醫療領域表現驚艷，不少模型甚至能在美國醫師執照考試（USMLE）中，拿下接近專科醫師水準的成績。然而，美國麻省總醫院布萊根體系（Mass General Brigham）最新研究發現，這些在標準化考試表現亮眼的AI模型，面對真實醫療情境時，能力可能大打折扣。

該醫院研究團隊最近在《Nature Biomedical Engineering》上，發表一項名為BRIDGE的醫療AI評測框架。這套評測基準，專門評估大型語言模型對真實臨床資料的理解力，範圍涵蓋電子病歷、臨床病例報告和醫病對話等資料，且也涵蓋9種語言。

研究結果發現，表現最佳的模型在標準化醫學考試中拿下92分，但在BRIDGE測試中，平均得分只有44.8%，意味著目前醫療AI模型存在明顯的臨床理解落差。除了論文研究，團隊也同步公開模型排行榜，來供醫療機構和開發者比較不同模型在真實臨床任務的表現，目前已納入107款模型。

為何現有醫療AI評測方式不夠？

過去幾年，醫療LLM的能力大多透過醫學考試題庫來評測，比如美國醫師執照考試（USMLE）或專科考題。這類評測方式都有個共同特性：題目通常經過標準化設計，使用正式且結構化的醫學語言，答案也相對明確。

然而，Mass General Brigham研究團隊指出，這類測驗主要評估醫學知識和推理能力，無法完整反映臨床現場的複雜性。

因為，相較於考題，醫師每天接觸的是電子病歷、護理紀錄、醫病對話及各類非結構化文本，其中充滿醫療縮寫、不完整病史、跨科別資訊和各院不同的書寫習慣。AI若無法理解這些內容，即使具備豐富醫學知識，也難以真正融入臨床工作流程。

Mass General Brigham醫學部藥物流行病學與藥物經濟學部門研究員Jie Yang表示，有別於許多以醫學考題為核心的評測工具，團隊建立的BRIDGE更聚焦於真實臨床資料來源，就是希望更真實反映AI在醫療照護現場的能力。

用真實病歷和醫病對話，測試AI能力

BRIDGE最早在2025年公開上架，最近則正式通過同儕審查並刊登於權威期刊《Nature Biomedical Engineering》上。

有別於傳統的醫療AI基準測試，BRIDGE採用電子病歷、臨床病例報告和醫病對話等真實醫療文本，作為測試資料，而非醫學考試考題。

簡單來說，BRIDGE包含59個臨床資料來源，評估95款大型語言模型在病人照護全流程中的表現，涵蓋14個臨床專科領域，以及病人分流、醫療資訊擷取、疾病診斷、預後預測和醫療申報與編碼等能力。

結果顯示，即使是表現最佳的模型，在標準化醫學考試拿下92分，在BRIDGE評測中的得分卻只有44.8%。研究團隊認為，這代表目前醫療AI最大的挑戰不再是缺乏醫學知識，而是缺乏對臨床語境（Clinical Context）和真實醫療文本的理解能力。

BRIDGE還有另一個特色，也就是納入9種語言的臨床資料。由於目前大多數醫療AI模型，都以英文資料為主來訓練，因此非英語地區的模型能力與適用性，往往較少受到系統性評估。

研究團隊指出，多語言設計，可以發現AI模型在不同語言環境下的表現差異，進一步改善醫療AI在全球不同醫療場域中的應用表現，降低語言造成的照護落差。

醫療AI評測從「會考試」走向「會工作」

除了論文研究，團隊也同步公開模型排行榜，來供醫療機構和開發者比較不同模型在真實臨床任務的表現。

這次論文首先評測95款大型語言模型，截至目前，排行榜已收錄了超過107款模型。

從產業發展角度來看，BRIDGE反映的不只是單一評測工具的進展，而是醫療AI評估標準的改變。過去業界習慣以USMLE等醫學考試成績衡量模型能力，但隨著生成式AI逐步進入醫院工作流程，醫療機構更關心的是AI是否能看懂病歷、理解醫病對話、支援病人分流、協助醫療申報與臨床決策。

'

GitLab 19.1強化AI工作流程治理，新增事件觸發與模型白名單

來源：https://www.ithome.com.tw/news/176777

GitLab在19.1版更新AI代理與流程目錄AI Catalog，讓AI工作流程功能Duo Flows可依合併請求、工作項目與CI/CD管線狀態自動觸發，並加入多項治理設定。管理員也可限制AI代理、流程與模型在組織內的使用範圍，降低未經審核的AI自動化內容進入企業環境的風險。

過去Duo Flows主要靠使用者在GitLab介面中提及服務帳號、指派服務帳號，或把服務帳號加入為合併請求審查者來啟動，較難直接納入正式開發流程。GitLab 19.1新增事件觸發後，當系統偵測到合併請求出現程式碼衝突，或開發者將合併請求從草稿標記為準備審查，相關AI流程就能自動執行，用於產生衝突摘要、提出處理建議，或進行審查前檢查。

Duo Flows支援的觸發事件還包括合併請求取得所有必要核准，以及建立新的工作項目。GitLab也強化既有的管線事件，讓使用者可設定只在管線執行中、成功、失敗或取消等特定狀態觸發流程，避免每次狀態變更都執行AI工作。

GitLab新增設定，讓執行個體管理員與頂層群組擁有者限制AI Catalog的使用範圍。管理員可停用自訂AI代理與流程，讓使用者僅能使用GitLab提供的基礎內容，也可限制使用者只能啟用同一群組階層內的AI Catalog項目，避免未經審核的社群或第三方內容進入企業環境。

GitLab 19.1也把流程設定檢查提前到儲存階段。使用者在AI Catalog新增或更新流程時，系統會先透過Duo Workflow Service檢查設定內容，要是缺少必要輸入或使用不明的工具參數，介面會在儲存前顯示錯誤，降低自動化流程上線後才因設定問題造成干擾的機率。

另一項治理功能是AI模型白名單，目前以公開測試版提供。管理員可指定組織核准使用的AI模型，並設定預設模型，讓企業在資料駐留或內部審核要求下限制模型來源。GitLab表示，該功能初期適用於GitLab Duo Agentic Chat，之後會擴大到更多功能介面。

'

Google推出Brazos液冷設計，不需改建機房也能部署60kW AI機架

來源：https://www.ithome.com.tw/news/176782

AI運算需求快速成長，資料中心散熱正成為企業擴充AI基礎設施的新瓶頸。Google上周發表名為Brazos的液冷系統，不同於傳統需要建置冷卻水系統的液冷架構，Brazos採用Sidecar（側掛式）設計，將液冷設備整合為獨立模組，直接安裝於AI機架旁，讓既有風冷資料中心也能部署高密度AI伺服器，而不必進行大規模機房改造。

Google表示，Brazos已正式提供，並將透過合作夥伴推廣至產業市場，希望讓更多企業與資料中心業者採用這套設計。

Brazos將液冷系統縮小至機架等級

目前市場上的液冷方案，多數需要資料中心配置冷卻水管路、冷卻水分配單元（CDU）以及相關基礎設施，在部署上伴隨高額投資與長達數個月的施工時間。

Google的Brazos設計(上圖，來源：Google Cloud)是將完整液冷系統整合成側掛模組，並採用OCP的ORv3機架規格，由3個液冷模組搭配整合式機架歧管組成，每個模組占用11個OU高度，共同支援單一的AI機架散熱需求。

換言之，原本屬於資料中心層級的液冷設備，被縮小為可隨機架部署的模組化設備，使液冷部署從「改建機房」轉變為「增加一個AI機架」。

建立封閉液冷循環，不需連接資料中心冷卻水

Brazos系統的最大特色是，採用Google稱之為「self-contained liquid ecosystem」的自成一體的液冷生態系 。

AI晶片產生的熱量先由冷板吸收後，再透過封閉式液體循環送往側掛模組內建的Liquid-to-Air熱交換器，最後直接將熱量排放至資料中心的熱通道，整個過程不需連接建築物冷卻水系統，也不必新增冷卻水管路。

由於液體始終在封閉迴路內循環，IT設備與資料中心設施彼此隔離，不僅降低漏液風險，也讓既有風冷資料中心能以較低成本導入液冷AI設備。

對企業IT而言，這代表未來升級AI運算時，不必等待機房重新設計，只需新增具備液冷能力的AI機架，即可逐步擴充算力。

單機架支援60kW熱負載，維修採模組化設計

根據Google公布的資料，Brazos每個機架最高可支援60kW熱負載，可使用去離子水（DI Water）或25%丙二醇混合液（PG25）作為冷卻液，供電則採40至60V直流電，可直接連接標準機架匯流排（Rack Busbar）。

其在管理上，該系統支援Modbus over TCP，可整合既有資料中心監控平台，同時內建漏液偵測與壓力釋放機制，並符合UL、CSA及IEC 62368-1等安全規範。

Google也在設計上強調Brazos的維護便利性。整個側掛模組採用滑軌結構，可直接抽出維修，幫浦與風扇也採用熱插拔、現場可替換（FRU）設計，方便現場快速更換，降低設備故障造成的停機時間。

隨著新一代AI加速器功耗持續增加，資料中心升級的挑戰已從運算能力轉向基礎設施能力。液冷雖然被視為AI資料中心的重要技術，但如何兼顧部署速度與成本，仍是企業導入的主要考量。

Brazos反映出AI基礎設施的新思維，將液冷能力封裝成標準化、模組化產品，讓企業可以依需求逐機架擴充，而不是一次投入機房大改造。

'

資安研究人員揭露新型惡意軟體載入工具OXLoader，用於部署竊資軟體CastleStealer

來源：https://www.ithome.com.tw/news/176781

資安業者Elastic所屬威脅研究團隊於6月19日發布報告，揭露新型惡意軟體載入工具OXLoader，主要被用於部署竊資軟體CastleStealer。研究人員指出，這款惡意工具會避開於以俄羅斯為首的獨立國協地區，以及俄文環境執行，顯示攻擊者可能為俄語系，以經濟利益為目的的團體。

Elastic發現，OXLoader被偽裝成JavaScript執行平臺Node.js，或API監控工具API Monitor的安裝網站，濫用Google廣告引誘使用者下載與執行。OXLoader執行後會透過多階段解密程序載入後續惡意程式，並採用多種分層混淆與反沙箱檢查措施，以規避靜態分析與沙箱偵測，還會將惡意程式碼隱藏於Windows檔案的.reloc區段。完成環境檢查後，OXLoader會在記憶體中載入竊資軟體CastleStealer，竊取瀏覽器憑證與其他敏感資訊。

Elastic指出OXLoader目前仍處於早期運行階段，但其結合程式碼混淆、反沙箱措施、以及獨特的部署技術，顯示其為規避分析與偵測而精心設計的策略，值得密切關注。

'

沒有公雲帳單，私有雲如何落實FinOps？國泰世華銀行SRE用監控數據支援治理決策

來源：https://www.ithome.com.tw/news/176779

在臺灣第一場可觀察性技術研討會中，不少企業難得分享了自家運用可觀察性的實戰經驗，國泰世華銀行更將各項監控數據應用到私有雲資源的管理，導入了FinOps思維來創造可觀察性數據的新價值。

國泰世華銀行SRE團隊，手上掌握了很多數據，從基礎設施層面的CPU和記憶體使用率，服務層面的Latency、錯誤率、SLA，還有應用程式效能監控的Tracing資訊等。

一般維運團隊常見有三種監控數據的應用情境，像是系統出事而觸發告警，需要數據來找出問題，加快修復速度。其次是服務效能遇到瓶頸，需要分析監控數據，向主管說明問題來源，釐清責任歸屬並研擬改善方式。第三是要證明系統正常運作，像是例行系統健檢，需要確認指標正常。

國泰世華銀行SRE工程師沈依潔剖析，這些應用方式只是利用觀察數據來解釋或是證明系統狀態，但能不能創造更多價值？

從管理階層角度來看，老闆關心私有雲資源是否有效利用？這可以進一步細分成三個實務問題，第一是資源配置合理性，是否符合實際業務負載，其次是，服務資源是否長期高估？最後是，擴容需求是否基於真實數據，而非擔心出事而額外要求？

就算拿到了上述問題的相關數據，沈依潔指出，最關鍵的挑戰就是，私有雲沒有如同公雲般的帳單，很難直接判斷資源利用的有效性。

私有雲 FinOps 挑戰：沒有帳單，也沒有人為浪費行為負責

私有雲和公有雲最大的差異之一，是沒有像公有雲那樣清楚的帳單。在公雲環境中，服務上線後開始依用量計費，但私有雲資源是預先採購的設備，使用行為沒有帳單紀錄。「只要服務沒有出事，浪費的行為很安靜，沒有人可以察覺。」沈依潔表示，還有另一個挑戰是，「沒有人為省錢負責，也沒有人是資源浪費的擁有人。」

管理階層無法了解實際數據與成本，平台管理團隊以平台穩定為優先，節省資源不是第一目標，開發應用團隊則依需求提出規格，但不見得有人可以評估規格所用資源的合理性。若指派一個團隊負責FinOps，其他團隊就會認為不是自己的責任而難以落實。

「推動FinOps需要建立合作文化。合作的基礎不能各說各話，而是要用數據對齊決策。」沈依潔建議，第一步就是先定義什麼是「浪費」。

掌握大量數據的平台管理團隊可以擔任FinOps核心承接者，用數據來定義指標，建立透明化規則，再和開發團隊討論資源調整方式，依照共同的指標和規則來調整。如此一來，管理階層就能清楚知道每一個專案如何落實FinOps。

國泰世華銀行採用了業界常見的叢集節能工具kube-green，先從測試環境導入私有雲FinOps做法。

先從關閉測試環境的閒置空檔，長期則要清理閒置的服務

測試環境的特性是，所部署的系統還沒實際執行交易，不會影響顧客或產生營運風險。使用時間也大多集中於上班時段，很多開啟在測試環境中的服務只是備用系統，不會持續創造價值。

沈依潔表示，為了驗證系統，測試環境理論上得盡可能比照正式環境配置，因此，不適合採取「精準調整資源配置」的FinOps策略，反而是要採取「服務不用時可關閉」的做法。就像辦公大樓的餐廳，假日無人上班，就不用開店，可以省下電費與人力成本。

所以，國泰世華銀行導入了測試環境的排程休眠與智慧喚醒機制。可以指定時段將部署環境的副本參數數值歸零，仍然保留所有設定，需要啟用服務時，仍可以喚醒測試環境。「這樣做的好處是，離峰時段自動關閉服務，不需靠人手動開關，也不用每天提前上班啟動服務。」她解釋。

不過，並非所有測試環境的服務都能在離峰時段關閉，國泰世華銀行依照服務相依性與重要性，細分成三類服務，各有不同的休眠策略。

第一類是基礎與關鍵服務。這一類服務支援了其他服務的大量呼叫，因此設定為永不休眠，避免影響其他服務智慧喚醒後的測試流程。第二類則是一般服務，這些服務有明確的開發和測試節奏，使用時間集中在上班時段，晚上則有少數測試需求，因此採取假日休眠的做法，避免影響開發流程。最後一類是教育訓練用服務，通常只會在上班時段使用，因此可以在平日晚上與假日時間休眠。

不只關閉服務要有策略，喚醒服務也需要有一套做法，尤其不能同時喚醒平台上的所有服務。同時啟動所有服務，可能導致這些服務高度集中在特定運算節點上，造成整體節點的配置不均，也會因為啟動階段需要更多資源，而影響所用節點的運作。有些需要連結外部系統的服務，同時喚醒，對第三方服務會帶來較大的壓力。

在喚醒服務上，國泰世華銀行SRE採取了三個做法，第一是事先預留啟動資源，來確保服務啟動時有足夠彈性。其次是，採取分批喚醒策略，避免同時啟動造成分配不均或節點負載過高。另外，還要控制每一波服務啟動的數量與間隔，確保上班時段開始之前，所需服務全都備妥。

國泰世華銀行SRE針對測試環境中的閒置服務，設定了一套清理規則。以90天為限，超過這段時間沒有部署新版，沒有流量，也不是核心或基礎的服務，就會通知負責的開發團隊，確認是否需要保留或移除。

測試環境預設只會提供一份，開發團隊若因壓力測試需要大量副本，則要另外提出申請，使用後歸還。這個做法背後的目的是，建立測試環境資源是借用資源的觀念，不是永久配給制。

他們管理測試環境的FinOps目標是 ，在穩定提供測試服務的前提下，讓測試環境的節點數，長期低於正式環境。簡單來說，就是用更少的基礎設施，提供同樣的服務能力。

沈依潔比喻，測試環境的管理，就像是旅館經營，平台是旅館，服務則是旅客。盡可能提高住房率、降低空房率，就能避免不必要的擴建。長期治理則像是定期清理已經登記但沒人入住的房間，將空間釋放給真正需要的人。

正式環境的FinOps做法和測試環境不一樣

不過，相較於測試環境，正式環境才是導入FinOps更困難的挑戰。沈依潔解釋，正式環境除需要符合資安標準與合規要求之外，還必須維持服務的高可用性，核心服務更是需要達到7x24小時的穩定運作。其次，正式環境處理的是真實顧客資料與交易資料，也需要維持資料的一致性與即時性，不能有延遲或遺失。再加上，正式環境的流量變化劇烈，像是自家舉辦促銷活動，或是外部不可預測的事件，如匯率波動等都會導致流量驟增，必須保留即時調整的彈性。

沈依潔提醒，無法將測試環境的FinOps管理方式，直接套到正式環境。「要管理正式環境的成本，第一步是先定義『不能做的事』。」

像是，哪些是不能關閉的服務，或是必須7x24小時運作的核心服務。不能單看CPU峰值來調整，否則可能會造成其他資源的長期浪費，也必須保留彈性，避免服務遇到流量波動而受影響。

「正式環境的FinOps目標不是關閉閒置服務，而要讓資源運用得更精準。」沈依潔一句話點出關鍵，必須提供正式環境更精準的資源配置，讓資源設定更符合每一項服務實際的使用型態。

國泰世華銀行結合了不同維度的數據來綜合判斷，包括了數值型數據，服務類型標籤等。數值型數據像是維運團隊慣用的CPU用量、記憶體用量、長期用量。他們特別會觀察90天的長期使用行為，避免因為特殊壓測、單日異常或短期事件的誤導。服務類型的標籤則像交易類服務或查詢類服務。沈依潔解釋：「重點不是服務今天用了多少資源，而是它長期真正需要多少資源。」

國泰世華銀行SRE整合了多種數據，讓資源配置異動決策更有依據

為了更客觀地評估一項服務的配置能否調整，以及調整出錯時的風險，國泰世華銀行SRE還有一個特別的做法，他們將自己的維運經驗，轉換成可以通用各種服務的「服務重要性」指標。

國泰團隊結合三項資訊，包括服務可用性、可變更時間，以及變更時可接受的中斷時間，將這三項資訊轉換成分數來加權計算，像是可接受中斷時間越短，代表這項服務的重要性分數就越高，最後歸納出三種「服務重要性」等級，分別是Critical、High和Medium。

善用資源矩陣，找出必須關注和可調整的服務

國泰世華銀行SRE以資源使用率與流量作為 X、Y 軸，再加上服務重要性標籤，設計了一個資源矩陣圖，就能一目瞭然看到所維運服務的資源調整態勢。

若有項服務的重要性等級為Critical，資源使用率高且流量也高，SRE團隊就需要特別關注，甚至得評估資源可用性，考慮增加資源來維持穩定。反過來說，若有服務的資源使用率低、流量也低，重要性等級只達到Medium，配置變動風險相對較低，就可以和該服務的負責團隊討論，評估是否減少資源配置。甚至可以用來評估是否要關閉或是和其他服務整併，來釋放所占用的資源。

「透過數據、標籤與統一的調整標準，SRE可以和各個團隊用同一份數據與同一套指標來評估。」沈依潔表示，因為資源的調整不是憑感覺，而是符合服務真實使用狀況，可以讓大家對配置的調整更有信心。

導入這套資源透明化的做法後，國泰所擁有的正式環境，在不增加更多節點的情況下，依舊能上線更多新服務，不只延緩了硬體資源的投資，也減輕了不少平臺管理團隊的維運壓力。

SRE要將可觀察性數據變成治理依據

「SRE不是沒有數據，而是這些數據能不能創造更多價值？答案是可以。」沈依潔表示，可以主動運用監控數據，來建立標準與規則，讓它變成主動治理的依據，讓數據成為每一個執行決策背後的依據。

即使在私有雲中，沒有帳單，透過數據來定義出「浪費」，釐清哪些資源可以調整而哪些不能異動。「善用可觀察性讓浪費被看見，用數據做出決策，對平臺團隊而言，可以將維運工作從救火提升到治理層次。」 沈依潔強調。

'