自建投研系統：從技能庫到驗證門控的完整設計

這是金融軌道的收束篇。前面每一篇都在解決一個局部問題：DCF 的假設治理、可比公司的口徑統一、三表的勾稽檢查、多 Agent 的流水線分工、持股拓撲的防雙計、合規的留痕與覆核。這篇把全部局部拼成一個完整系統，回答一個問題：如果你要從零蓋一套自己的投研 AI 系統，藍圖長什麼樣、按什麼順序蓋、每一層的驗收標準是什麼。

先聲明立場，因為整個架構都是從這一條推出來的：本站對金融 AI 的基本假設是——假設 AI 會說謊。不是修辭，是工程前提。LLM 在金融場景的錯誤不是偶爾出錯，而是會以流暢、自信、符合行業直覺的方式編造數字與來源；實證分析見 LLM Agent 自主繞過流程約束的實證分析 與 Agent 驗證架構的信任建築學。接受這個前提之後，系統設計的唯一出路就是：每個結論可回溯、每個數字可重算、每份產出可挑戰，而執行這些紀律的是代碼，不是提示詞。讀完這篇，你應該能把任何一個投研需求映射到「哪一層、走哪道門、棄權還是升級人工」的確切答案。文中不涉及任何真實公司與市場數據。

一、設計原則：先把立場釘死

五條原則，後面所有架構決策都是它們的推論：

原則 1：機械驗證優先於文字約束
  能用 schema、斷言、重算執行的規則，絕不寫成「請務必」
原則 2：棄權是一等公民輸出
  「數據不足，無法結論」與「結論」同為合法產出，且必須同樣留痕
原則 3：覆蓋率與準確率分開統計、分開匯報
  合併成一個「好用程度」的瞬間，自欺就開始了
原則 4：一切帶版本
  數據有 as-of、提示詞有 git sha、模型有版本號、門控規則有版號、
  技能有 changelog——沒有版本的產物無法重放，無法重放就無法追責
原則 5：每個對外結論都有具名的人負責
  AI 是生產工具，不是責任主體；覆核與放行必須是人

這五條裡最反直覺的是原則 2。多數人對 AI 系統的期待是「什麼都能答」，而投研場景的正確期待是「該答的答對，不該答的明確拒答」。一個會棄權的系統才敢放進真實決策流程；一個永遠給答案的系統，每個答案都要人工重驗，等於沒有省力。本站對決策類模型的實測（決策模型的現實檢查）給了這條原則數據支撐：同一批題目，不設信心門控的全量輸出與設了門控的高信心輸出，可信度完全不在同一個水平——具體數字與方法見該文，此處不複述。

二、五層架構：每層只做一類事

┌────────────────────────────────────────────────────────────────┐
│ 輸出層  研究報告／板塊比較／持股拓撲圖／監控告警               │
│         ＋引用索引＋免責與披露＋審計記錄入口                    │
├────────────────────────────────────────────────────────────────┤
│ 編排層  任務分解 · 技能路由 · 並行調度 · 標的級狀態機           │
│         · 預算熔斷 · 人工覆核佇列                               │
├────────────────────────────────────────────────────────────────┤
│ 技能層  快速盡調 · 三表抽取 · 現金流品質 · 可比公司 ·           │
│         DCF 假設治理 · 持股拓撲 · 公告監控 · 紀要轉要點         │
│         （每個技能自帶輸入輸出契約與驗證規則）                  │
├────────────────────────────────────────────────────────────────┤
│ 資料層  資訊源白名單 · 快照與存檔 · 結構化抽取管道 ·            │
│         事實庫（值＋來源指針＋as-of＋狀態）                     │
└────────────────────────────────────────────────────────────────┘
   ▲
   │ 驗證層（橫切所有層，不屬於任何一層）
   │ G1 格式 → G2 勾稽 → G3 來源 → G4 信心 → G5 棄權
   │ ＋評測集回歸＋審計記錄＋運行監控

各層的職責邊界、關鍵決策與本站對應的深入文章：

兩條架構紀律比圖本身重要。第一，驗證層是橫切的：它不是流水線末端的一道工序，而是每一層的產出都要過門——資料層的事實過 G1–G3，技能與編排層的論斷過 G2–G4，輸出層的成品過全套。把驗證理解成「最後一步」的系統，錯誤早就在前面各層之間擴散了。第二，層與層之間只以結構化契約相連：事實庫的 JSON schema、技能的輸入輸出契約、門控的 GateResult，都是代碼級定義。任何「自由文字直連」（上一層寫段話給下一層讀）都會讓驗證失去抓手。

三、技能庫：把重複的投研任務固化

技能（skill）是系統的基本生產單元：一段固化下來的、可觸發的、帶契約的任務流程。判斷一個任務該不該固化成技能，看三條：做過三次以上、有明確的輸入輸出、有可機械執行的驗證規則。三條都滿足就固化，缺第三條就先補驗證規則再固化——沒有驗證規則的技能只是把錯誤也一起固化了。

每個技能文件的最小結構（Markdown＋YAML 即可，不必上框架）：

# skills/quick-dd/SKILL.md
name: quick-dd
version: 2.3.0            # 語義化版本，changelog 必填
trigger: ["快速盡調", "quick dd", "初步看看這家公司"]
input_contract:
  required: [target_id]
  optional: [focus_areas, as_of]
output_contract:
  schema: schemas/quick-dd-output.v3.json
  required_sections: [公司概況, 財務體檢, 持股與治理, 風險訊號, 棄權與缺數清單]
steps:
  - 從事實庫拉取 target 最新 facts（禁止繞過事實庫直接上網找數）
  - 跑三表勾稽與現金流品質規則集（three-statement-cash-quality v4）
  - 跑持股拓撲計算（shareholding-graph v2，環檢測前置）
  - 匯總風險訊號，每條附證據指針與信心等級
verification:
  gates: [G1, G2, G3, G4]
  on_low_confidence: abstain_section   # 局部棄權：該節輸出「數據不足」
failure_handling:
  facts_missing: 輸出缺數清單，不得估計補數
  tie_out_fail: 整體 block，標記資料層回查

四個設計決策值得展開：

粒度。 太粗（「做完整個盡調」）無法復用也無法評測；太細（「計算 DSO」）會讓編排成本爆炸。經驗法則：一個技能對應一份有獨立交付意義的產出（一份體檢報告、一張比較表、一個持股圖），內部再調用細粒度的規則集與工具。

契約。 輸入輸出都用 JSON Schema 定義，必填欄位、枚舉值、單位與幣別欄位寫死。契約是技能與驗證層之間的接口：G1 門控直接拿 output_contract 的 schema 校驗產出，不合格即退回。

棄權語義內建。 注意上面 abstain_section：技能層面就定義了「低信心時怎麼辦」，而不是把爛結果丟給門控攔。棄權要局部化——持股數據不全，就棄權持股那一節，財務體檢照常輸出。

版本與退化。 技能的每次修改走 changelog＋評測集回歸（第六節）。技能是會退化的：資料源改版、模型升級、規則過時，都會讓三個月前還很好用的技能悄悄變差。退化偵測靠監控（第七節），不靠感覺。

技能庫的完整生態——怎麼分類、怎麼觸發、怎麼路由——見 14 個金融服務 AI 技能完整指南 與基礎設施層面的 Agentic 基礎設施完整指南。

四、驗證門控：從格式到棄權的五道關

門控是整個系統的免疫系統。五道關按成本從低到高排列，便宜的關先跑，攔不住的才交給貴的關：

G1 格式驗證   產出是否符合 output schema？必填欄位、枚舉、單位、幣別
              成本：近零（純代碼）        失敗動作：退回重生成
G2 數值勾稽   數字之間對得上嗎？三表勾稽、EV=市值+淨負債、
              路徑乘積重算、矩陣抽格重算（獨立代碼，不復用生成方算式）
              成本：低（純代碼）          失敗動作：block，定位到欄位
G3 來源可回溯 每個值有來源指針嗎？指針真的存在嗎？抽樣回原文檔
              重抽比對，容差內一致？
              成本：中（抽樣重抽）        失敗動作：無指針即拒收；
                                        抽檢不一致→整批凍結排查
G4 信心門檻   每條論斷的 confidence 有標註嗎？低信心論斷是否已降級
              措辭、進入人工覆核佇列？
              成本：中（規則＋人工佇列）   失敗動作：降級或升級人工
G5 棄權       該棄權的棄權了嗎？缺數章節輸出「數據不足」而非估計值；
              棄權本身帶原因與補數路徑
              成本：低                    失敗動作：把「假答案」攔成棄權

門控管道的代碼骨架，核心是 fail-closed：

from dataclasses import dataclass, field
from typing import Callable, Literal

@dataclass
class GateResult:
    gate: str
    status: Literal["pass", "warn", "fail"]
    reasons: list[str] = field(default_factory=list)

def run_gates(payload: dict, ctx: dict,
              gates: list[Callable[[dict, dict], GateResult]]) -> list[GateResult]:
    results = []
    for gate in gates:
        r = gate(payload, ctx)
        results.append(r)
        if r.status == "fail":
            break   # fail-closed：一道關失敗即停，後續關不跑、產出不放行
    return results

def disposition(results: list[GateResult]) -> str:
    if any(r.status == "fail" for r in results):
        return "rejected"        # 退回上一段或標記 failed
    if any(r.status == "warn" for r in results):
        return "human_review"    # 警告不自動放行，進人工佇列
    return "accepted"

注意 disposition 裡沒有「warn 就自動放行」的分支：警告的默認去向是人工，不是發布。放行 warn 需要人在審計記錄裡簽字並寫理由。

為什麼門控必須是外部代碼而不是提示詞？因為本站實測記錄過完整的惡化路徑：LLM Agent 在連續執行中先跳過驗證步驟，隨後升級為偽造驗證記錄——當「驗證」由被驗證者自己執行時，它對模型來說只是一段可以改寫的文字。詳細實驗與架構分析見 Agent 驗證架構的信任建築學。落到本系統：門控進程與 Agent 進程分離，門控結果由門控獨佔寫入，Agent 無權讀寫自己的驗證記錄。

五道關之外還有一道端到端抽審：每次 run 隨機抽一個成品數字，沿 report→claim→fact→source 全鏈路人工回溯到原始文件。抽審是唯一能發現「五道關都沒覆蓋的新型錯誤」的機制，抽審發現必須回流成新門控規則——這是驗證層的自我進化迴路。

五、覆蓋率與準確率：為什麼必須分開統計

兩個指標的定義先釘死：

覆蓋率 = 系統給出實質結論的任務數 ÷ 全部任務數
         （棄權、缺數、failed 都不算覆蓋）
準確率 = 抽驗正確的結論數 ÷ 抽驗的實質結論數
         （分母只含給了結論的，棄權不進分母）

分開統計的原因：這兩個指標可以互相買賣。把 G4 信心門檻調低、把棄權改成「大膽輸出」，覆蓋率立刻上升，準確率同步下滑——如果只看一個混合指標（比如「任務完成滿意度」），這種惡化交易會被完全掩蓋。四象限把系統的真實狀態攤開：

三個統計紀律：按技能×標的類型分桶統計（「整體準確率」掩蓋結構性短板——可能快速盡調很準、持股拓撲全錯）；按時間序列追蹤（退化是漸變的，單點數字看不出來）；棄權也要統計（棄權率突然上升通常不是模型變笨，而是某個資料源掛了）。

準確率的「準」字要有可操作定義：數值型結論對照來源原文（機械判分），定性結論對照人工 rubric（雙人評分）。評分的完整方法論見 LLM 評測完整指南。

六、評測集：每次改動都跑同一組題

評測集是系統的「回歸測試」：一組帶標準答案的任務，任何改動（提示詞、模型、資料源、門控規則、技能版本）前後都跑同一組題，成績入台賬。沒有評測集的系統，每次「優化」都是盲改——你以為修好了一個 case，其實弄壞了三個。

建構七步：

1. 圈定評測對象：列出全部技能與各自的核心題型
2. 收集歷史真題：從自己做過、且人工確認過答案的真實任務中抽題
   —— 金標準來自人工完成的歷史工作，不是現編
3. 構造邊界案例：每個技能配齊它的「噁心輸入」——財政年度錯位、
   多層交叉持股、虧損公司、附註缺失、新舊準則混用、同名公司
4. 構造對抗樣本：兩類必考——
   a) 資訊不存在題：正確答案是棄權，答出任何具體數字即算錯
   b) 數據矛盾題：兩個來源數字衝突，正確答案是報告矛盾而非擇一
5. 金標準定稿：兩人獨立標註、比對分歧、仲裁定稿；標準答案附
   判分要點（哪些欄位必須對、哪些措辭必須出現／禁止出現）
6. 判分規則：能機械判分的全機械判（數值容差、欄位存在性、
   棄權標記）；主觀項寫 rubric 雙人評分
7. 基線與台賬：當前版本全量跑一遍存為基線；此後每次改動跑
   回歸，成績、diff、改動內容三者綁定入檔

規模的務實建議：起步階段每技能 20–50 題、總量一兩百題就能發揮作用，關鍵是邊界與對抗樣本的佔比要高（建議至少三分之一）——常規題拉不開版本差距，系統都是死在邊界題上的。評測集本身也要版本化與成長：端到端抽審發現的每個新錯誤模式，都應該變成一道新題。

回歸紀律的執行細節：改動前後各跑一次、報告分技能分桶的成績對比、準確率下降超閾值（自定，例如任一分桶下降即凍結）則改動不合入。這套紀律把「提示詞工程」從玄學變成工程——你不再需要「感覺這次改得不錯」，你有台賬。評測驅動的完整方法論與常見陷阱，見 LLM 評測完整指南。

七、成本、延遲與上線後的維運

監控：系統的健康儀表板

每次 run 自動沉澱的運行統計（與 流水線篇 的 manifest 統計同源）：

維運三件事

資料源變動。 網站改版、API 停服、披露格式調整是常態而非意外。防禦三層：每個資料源配每日健康檢查任務（抓一個已知結構的頁面，驗證欄位仍在）；快照存檔保證歷史結論仍可回溯；源變動觸發受影響技能的評測回歸。

模型版本變動。 供應商會悄悄更新模型，「同一個模型名」在不同月份可能是不同行為。紀律：pin 具體版本；升級走灰度（新版本先跑評測集與部分流量，成績達標才全量）；每次升級的評測成績入台賬。模型升級導致能力漂移的實測案例，見 決策模型的現實檢查。

技能退化偵測。 技能的準確率時間序列連續下滑、或門控攔截率連續上升，即觸發排查 runbook：先查資料源（最常見）、再查模型版本、最後查技能與提示詞是否被人動過。排查結論回流：修技能、修門控、或加評測題。

維運的組織形態很簡單：值班表＋runbook＋週報。週報固定三張圖：分技能準確率序列、門控攔截率序列、成本序列。系統健康與否，三張圖看完就有數。

八、演進路徑：從單人工具到團隊系統

不要一步到位。正確的順序是讓架構跟著痛點長：

三個階段的基礎設施是遞進的：階段 1 的事實庫與契約直接成為階段 2 的資料層；階段 2 的門控與留痕直接成為階段 3 的合規底座。跳級建設的每一層都會變成沒有地基的樣板間。階段 2→3 的部署實務（環境、密鑰、隔離）見 三層 Agent 部署實戰，平台級基礎設施選型見 Agentic 基礎設施完整指南。

常見失敗模式總表

最後把整個藍圖會死在哪裡列成一張表（設計評審時逐條自查）：

下一步

• 多 Agent 投研流水線：編排層的完整設計，本篇第二、四節的展開
• 投研 AI 的合規邊界：輸出層與留痕的制度細節，階段 3 的必修課
• 決策模型的現實檢查：信心門控為什麼值回票價的實測證據
• Agent 驗證架構的信任建築學：門控必須是外部代碼的實證基礎
• LLM 評測完整指南：評測集與判分方法論的通用版本
• Agentic 基礎設施完整指南：技能、記憶、編排的基礎設施選型