Topic-Graph Cross-References: A Deterministic Alternative to LLM Augmentation
Regex extraction covered only 33% of OSCAL controls. A topic-graph approach using the AI RMF Playbook's own 46-topic taxonomy lifted coverage to 78% — without an LLM in the loop.
我們第一次出 AI RMF OSCAL catalog v0.3 的時候,72 條 control 上的 regex 交叉參照抽取器只找到 31 條連結,分散在 24 條 control 上。也就是 33% 覆蓋率。三分之二的 catalog 完全沒有可被機器發現的關聯,對下游的 profile 作者和 OSCAL 工具來說,這個 catalog 的可用性會打折。
下一步看起來就該丟 LLM 上去。我們沒這麼做。下面解釋為什麼,以及我們改 ship 了什麼。
為什麼標準工作要選確定性,不選 LLM
會接到聯邦標準的 OSCAL catalog 必須可重現。NIST 的審查人員應該要能從公開的原始資料完整重生整個 catalog,輸出位元級一致。LLM 做不到。同樣輸入、不同 sampling,輸出不同。同樣輸入、不同模型版本,輸出不同。
還有可辯護性問題。如果我們列出 GOVERN-1.1 跟 MANAGE-4.3 之間的交叉參照,審查人員問為什麼,答案不能是「模型決定的」。必須是一條你讀得到、跑得起來的規則。
所以我們寫了 src/topic_cross_references.py。它用 AI RMF Playbook 自家的 46 個 topic 分類法 — 也就是 NIST 自己已經為每條 subcategory 發布的 topic 標籤。兩條 control 共享一個 topic,就是交叉參照的候選對象。沒有外部知識、沒有推論,純粹是在公開資料上跑圖遍歷。
保守的反頻率閾值
單純「有共享 topic 就連」會把 catalog 淹掉。Risk Management 出現在幾十條 control 上。所以我們用反頻率加權:稀有 topic 的訊號比常見 topic 強。
候選連結的資格條件:
- ●共享 3 個以上 topic,不問頻率;或
- ●共享 2 個以上 topic,其中至少一個是稀有的(出現在
<=5條 control 上);或 - ●共享 1 個以上極稀有 topic(出現在
<=3條 control 上)
另外設一個 top-K = 4 的上限,每條 source control 最多保留 4 條外連。這樣防止標籤密集的 subcategory 在自己鄰域裡稱霸。
數字
主題圖抽取新增 145 條連結,額外覆蓋 32 條 control。加上原本 regex 找到的 31 條,總覆蓋率來到 72 條 control 中的 56 條(78%)。catalog 把兩種來源的連結 ship 在不同欄位:主題圖來的會帶 text 欄列出共享 topic 名,下游用戶一眼就能看出這條連結是文字 pattern 比中的,還是分類法重疊算出的。
可重現、可辯護、之後做什麼
腳本本身約 120 行 Python。任何人 clone repo、跑 python src/topic_cross_references.py,可以重現完全一致的 145 條連結。閾值可調,但版本化在 source 裡。我們調的時候,跟已 publish 的 catalog 的 diff 一行一行可審查。
對 NIST OSCAL Team 的審查(thread usnistgov/OSCAL#2234)來說,這個差別很大。「我們用了 LLM」跟「我們用反頻率主題重疊、閾值如下」的差別,就是審查人員點頭跟審查人員追問的差別。
未來 LLM 擴充還是有空間 — 比如分辨真正的語意連結跟巧合的 topic 重疊。但這類用法應該疊在確定性基線之上,不是取代它。
Source: topic_cross_references.py · Catalog repo · OSCAL Team thread