LY Corporation 以 Granite Guardian 3.1 2B 微調模型偵測 OpenChat 名稱與簡介中的有害內容
LY Corporation Tech Blog · 2026-08-25
原本的問題
LINE 的 OpenChat 功能讓使用者輸入聊天室名稱與簡介後即可建立公開聊天室，每天在多國產生大量新建與編輯紀錄，需要審核是否違反社群守則。目標是在既有自動審核的地區擴大可信賴範圍，並在標準較嚴、仍高度依賴人工複核的地區提升準確度。舊版模型採用傳統分類頭（classification head）架構，判斷精度不足以支撐擴大自動化範圍。
採用的方法
新模型以 IBM Research 釋出、Apache 授權的 Granite Guardian 3.1 2B（約 20 億參數、預訓練於安全審查任務的 decoder-only 模型）為基礎。核心作法是不使用分類頭，改比較模型對「這段輸入是否有害」回答「Yes」或「No」等預先定義 token 的生成機率，藉此取得比傳統分類更穩定的判斷訊號。團隊以 LoRA（Low-Rank Adaptation）微調降低訓練成本，並將任務設計成同時預測懲罰代碼（penalty code）與懲罰原因（penalty reason）的多工學習，loss 只計算在模型回應區段。
訓練資料來自過去人工審核、且僅套用目前準則的紀錄；同一筆 metadata 出現不一致審核結果時，某懲罰等級出現兩次以上就採用最嚴重的一個，否則保守採用次嚴重等級，懲罰原因則以出現頻率為主，頻率相同再以類似 TF-IDF 的稀有度加權決定。推論階段分兩步：先由候選 token 機率預測懲罰代碼，再依代碼生成懲罰原因，最後套用信心門檻決定是否交由自動化處理。
實際效果
評估指標為 F1 score，特別著重「無問題」這一多數類別的判斷正確率。三個評估地區的正常類別 F1 皆較舊版模型顯著提升，候選 token 機率分類法優於傳統分類頭做法。提高信心門檻可換取精確度，但會降低可自動處理的比例，需依各地區審核標準權衡取捨。
Inside MSIX 依 RuntimeBehavior 屬性將封裝行程分為三類
Microsoft Inside MSIX devblog · 2026-08-25
原本的問題
Windows 上以 MSIX 封裝的行程並非單一種執行模型，開發者過去常把所有封裝行程當成同一類看待，因而誤判其安全性、DLL 搜尋順序或解除安裝行為。本文延續前一篇《Is This a Packaged Process?》，依 AppxManifest.xml 裡的 RuntimeBehavior 屬性，把封裝行程明確分成三種類別。
採用的方法
- Universal（
RuntimeBehavior=windowsApp）：自 Windows 8.1 起支援，建構於 WinRT 應用程式模型，以CoreApplication（歷史上曾用CoreWindow）進入，執行於 AppContainer 隔離環境。 - Centennial／Desktop Bridge（
packagedClassicApp）：自 Windows 10 1607（RS1）起支援，本質是有WinMain()／main()進入點、使用 HWND 的傳統 Win32 程式，可選擇跑在 AppContainer；DLL 搜尋機制精簡為 8 種（非封裝行程為 18 種），並啟用 Flexible Virtualization 以支援乾淨解除安裝，Windows 設定（windows.immersivecontrolpanel）即屬此類。 - Win32alacarte（
win32App）：自 Windows 10 2004（20H1）起支援，同為 HWND 型 Win32 程式，但保留完整 18 種 DLL 搜尋機制、不啟用 Flexible Virtualization，設計上以相容性優先於理想行為。
三者可視為一條「相容性—良好公民」光譜：未封裝行程落在相容性一端，Win32alacarte 居中，Centennial 與 Universal 偏向良好公民行為。要判斷某行程屬於哪一類，關鍵就是讀取其 RuntimeBehavior 屬性值。
實際效果
| 類型 | RuntimeBehavior | DLL 搜尋機制數 | Flexible Virtualization |
|---|---|---|---|
| Universal | windowsApp | 限 AppContainer 內 | 不適用 |
| Centennial | packagedClassicApp | 8 種 | 啟用 |
| Win32alacarte | win32App | 18 種 | 停用 |
這個分類讓開發者能依 RuntimeBehavior 值預期行程的 DLL 劫持風險與解除安裝乾淨程度，不必逐一實測。疑難排解或相容性評估時，先確認行程屬於三類中的哪一種，往往比逐項檢查安裝行為更快定位問題根源。
原始來源：Inside MSIX devblog
Visual Studio 八月更新：模型思考強度控制與 Git Worktree 支援
Visual Studio devblog · 2026-08-25
原本的問題
Visual Studio 2026 Stable Channel 本次更新聚焦兩個既有痛點：一是 AI 輔助開發時模型設定與用量不透明，開發者難以依任務調整推理深度或掌握方案用量；二是多分支並行開發時，靠 git checkout 切換分支的流程會打斷正在進行中的建置與暫存變更。
採用的方法
- 模型思考強度控制：在 Model picker 或展開的 Language Models 視圖中，可將支援模型的推理層級設為 Low（簡單問答）、Medium（一般開發任務）或 High（複雜演算法、架構決策與除錯）。
- 組織層級自訂 Agent：GitHub 組織或企業管理者可發佈客製 Agent 供成員在符合條件的 repository 中共用，picker 會顯示 Agent 說明與來源，並可點選檢視其定義檔。
- Copilot 用量透明化：從 prompt 輸入框的 context window 可直接查看方案用量，並透過「View all Copilot usage」連結到完整用量頁面，逼近上限時會收到提示通知。
- Git Worktree 支援：於 Repository 視窗右鍵選單「New Worktree From」建立新的工作目錄，可基於新分支、既有分支或歷史 commit，並選擇在目前或新開的 Visual Studio 執行個體開啟；worktree 會同時顯示在 Repository 視窗、分支選取器與儲存庫選取器中，不需要時可由選單刪除。
- Git Submodule 管理：Git Repository 視窗新增獨立的 Submodule 區塊，開啟方案或資料夾時自動偵測，可直接新增、更新、刪除子模組；預設為 read-only，須在 Tools > Options > Source Control > Git 中啟用才能編輯。
實際效果
Git Worktree 支援讓同一份 repository 能以多個獨立工作目錄同時對應不同分支，避免切換分支時中斷正在進行的建置或暫存變更。這項功能的起點是 Visual Studio Developer Community 上一則公開的 Git worktree 功能請求。模型思考強度分級與用量透明化則讓 Copilot 的推理成本與資源消耗變得可預期、可調整。