pop-fem-audit/docs/methodology.md

方法細節

（全文方法節底稿。演算法在執行前寫定；任何修訂記入 decision-log.md。定義檔全文見 prompts/，執行紀錄見 runs/。）

自然編碼管線總覽

四步驟：自由標註（tag）→ 自然收斂（merge）→ 強制收斂 （cap）→ 全量編碼（code），另設「女性力量」單目標篩選 （screen）作黃金標準取樣的補漏網。歌詞只出現在 tag、code、 screen 與各仲裁步驟；merge、cap 及其仲裁、命名皆不接觸 歌詞。設計原則見 research-plan.md；本檔記載可重現的 演算法細節。

收斂步驟（merge、cap）的 2+1 比對與仲裁

兩次獨立執行對同一批輸入詞各產生一個分組。比對不做 「組對組」的匹配——兩個組是否為「同一組的變體」無原則性 答案——而是把比較化約為「詞對的共組關係」：

1. 共識塊（交集細分）：兩次執行都放在同組的詞歸為 同一塊。即以「(第一次的組, 第二次的組)」二元組為鍵 分桶，一桶一塊。此步為純集合運算。
2. 分歧塊對枚舉：每個塊完整落在各次執行的恰一組內， 故「兩塊在某次執行中是否同組」定義良好。逐塊對檢查： 兩次執行答案相同者為共識（同組或分開，直接定案）； 不同者列入分歧清單。
3. 逐對仲裁（自身 2+1）：分歧塊對送 LLM 仲裁 （01-02-02-merge-arb.md、01-03-02-cap-arb.md）。 仲裁者只看兩塊的內容詞，逐對二元裁決「是否同一 主題」；輸入不含執行別（避免「猜哪一次較可信」的 偏誤），不含共識部份，不含歌詞。仲裁自身獨立執行 兩次，逐對比對：兩次裁決相同即定案；相異的塊對送 終局票（01-02-03-merge-arb-arb.md、 01-03-03-cap-arb-arb.md，單次執行，依協定為終局） ——每個分歧塊對等同三票多數決，仲裁鏈至此終止。 送入仲裁的塊對即模型自身不穩定的邊界判斷，其裁決為 單次記錄性決定，不宣稱可再生；可重現性依計畫定義為 「程序透明＋可稽核」，裁決與其輸入全程歸檔。
4. 確定性重組：以每個「同組」裁決為一條邊，最終 分組＝圖的連通元件（union-find）。固定邊集的連通 元件唯一，與處理順序無關，故重組決定性成立。 遞移性後果照單全收：兩個共識「分開」的塊可能經第三 塊橋接而併入同組——此為等價關係語意的邏輯結論， 比對程式將此類「遞移導出的合併」逐筆記錄於歸檔， 供稽核。仲裁的結果空間因此大於「兩次執行擇一」： 可能比兩次都粗（多對皆裁同組），也可能比兩次都細 （多對皆裁分開）。
5. 一致率與保險絲：比對程式計算塊對層級的一致率並 記入歸檔。低於門檻（暫訂 50%，首輪實跑後校準）即 不進行仲裁——兩次分組面目全非說明定義檔約束不足， 依協定修訂定義檔並重跑該循環。
6. cap 的上限容忍：仲裁後組數可能略超 50（多對裁 「分開」時）。略微超過可接受，如實記錄，不強行 壓縮。
7. 組名定案（收斂不命名＋命名 2+1）：merge、cap 的 執行輸出不含組名（無名分組，陣列之陣列）——命名鏈 既然存在，收斂執行自取的名字只會製造兩次執行間 「同組不同名」的假分歧。組名承重——merge 的組名是 cap 的輸入詞，cap 的組名是 code 對歌詞編碼的類目—— 故與其他語意判斷同受 2+1。程序：(1) 最終分組定案後， 命名步驟（01-02-04-merge-name.md、 01-03-04-cap-name.md）獨立執行兩次，輸入為不透明 組 ID 對成員詞，對全部組自由命名，僅受格式約束 （小寫連字號、單次執行內不重複）；(2) 逐組比對：兩次 同名即定案（單次執行內名字唯一，故定名間必無撞名）； (3) 異名的組送擇一仲裁（01-02-05-merge-name-arb.md、 01-03-05-cap-name-arb.md）——匿名呈現兩候選，逐組 擇一，輸出限於候選並避讓已定名，機械可驗證。cap 的 輸入即 merge 定案後的組名清單。

收斂步驟的資料流（比對子命令的輸入輸出契約）

以 merge 為例（cap 完全同構，檔名換為 01-03 系）：

1. 兩次執行的原始輸出：runs/01-02-01-merge/run1/output.jsonl 與 run2/output.jsonl，各含一個無名分組（陣列之陣列）。
2. 比對子命令讀入兩份分組，先驗證兩者為同一輸入詞集的 完整分割（缺詞、多詞、重複即失敗），再計算共識塊與 分歧塊對，產出仲裁輸入檔——即 01-02-02-merge-arb.md 所收的 JSON：
   • blocks：塊 ID → 成員詞。塊 ID 的指派決定性： 全部塊先按「各塊字典序最小的成員詞」排序，依序編為 b1、b2、…；塊內成員詞亦按字典序排列。
   • pairs：分歧塊對清單，每對內部按塊 ID 序、清單 整體按 (第一元素, 第二元素) 字典序排列。
   • 僅分歧塊對入列；共識（同組或分開）不送仲裁，由 比對子命令直接寫入共識紀錄檔。 同時產出：共識紀錄（共識塊、共識同組對、共識分開對） 與塊對一致率（含保險絲判定）。
3. 仲裁輸入檔以 run-llm 跑兩次 （runs/01-02-02-merge-arb/run1、run2）；比對 子命令逐對比對兩份裁決，兩票相同即定案，相異的塊對 依同一契約組成終局票輸入檔（blocks 僅含涉事塊、 ID 沿用原編號），跑 runs/01-02-03-merge-arb-arb/run1。
4. 裁決套用子命令彙整三票結果，以 union-find 重組出 最終分組，並寫出：最終分組檔（無名，陣列之陣列， 組序與組內成員皆字典序）、遞移導出合併的紀錄、 收斂軌跡（原始詞 → 最終組）。
5. 最終分組轉為不透明組 ID（依組序編 g1、g2、…）進入 命名鏈（見第 7 條）；命名定案後，組名清單（字典序） 即下一步的輸入。
6. 以上中間檔全部隨 runs/ 歸檔；一切排序規則固定， 故給定相同的兩份執行輸出與相同的裁決，全流程輸出 逐位元組可再生。

編碼步驟（code、screen）的 2+1 比對與仲裁

• code：逐首比對兩次執行的標籤集合（引述不參與 比對）。兩次皆有的標籤為共識保留、兩次皆無為共識 不標；單邊標籤送仲裁（01-04-02-code-arb.md）——仲裁者 看歌詞全文與該標籤的引述（不含執行別），裁決保留者 附仲裁者自己的引述，剔除者不列。剔除集合＝送裁鍵減 輸出鍵，由程式推得。
• screen：輸出即引述陣列，非空＝有、空＝無。僅 「一有一無」的歌送仲裁（02-01-02-screen-arb.md）， 輸入為歌詞加主張「有」方的引述（不記名），輸出同為 引述陣列。
• 仲裁者的引述可能與原引述不同：仲裁是對歌詞的重新 判讀，其引述是該裁決自身的依據，非轉抄。

軌跡對映（診斷用）

沿收斂軌跡的機械對映：原始關鍵字 → merge 組 → cap 組， 純程式查表，決定性。以其結果與 code 直接編碼的差異率 作為「收斂軌跡扭曲」的診斷量，不作主結果。

全管線的交接契約

每一步的輸出如何變成下一步的輸入，皆為確定性程序，規則 明定如下（收斂步驟內部的交接見上節）：

• 歌詞輸入檔（tag、code、screen 共用）： export-llm-input 自工作儲存產出，每筆 {"id": "song-<ID>", "content": <歌詞>}，依歌曲 ID 升序。三個讀歌詞的步驟共用同一檔，SHA-256 記入各步 meta。
• tag → merge：兩次執行的全部關鍵字取聯集、逐字串 精確去重、字典序排列成 JSON 陣列，即 merge 的輸入。 進池同時寫出處記錄（關鍵字 →（執行別，歌曲 ID） 清單），供軌跡對映回到歌曲；出處記錄不進任何 LLM 輸入。
• merge 定案 → cap：merge 定案組名以字典序排成 JSON 陣列，即 cap 的輸入（見上節第 5 點）。
• cap 定案 → code 定義檔：定案組名以字典序逐行填入 01-04-01-code.md 的詞彙表節（逐字），檔案隨 git commit 後方可執行——code 的定義檔因此自我完備， 論文附錄可直接引用。
• code 兩次執行 → code-arb：逐首比對標籤集合 （鍵集合，引述不參與比對）；僅有分歧的歌入仲裁輸入 JSONL，依歌曲 ID 升序，每筆 id 沿用 song-<ID>、 content 為固定鍵序序列化的 {"lyrics": …, "disagreements": …}，disagreements 鍵按字典序。
• code 定案：每首歌的最終標籤＝共識標籤 ∪ 仲裁保留 標籤，寫入逐首紀錄檔（歌依 ID 升序、標籤按字典序， 各標籤附其定案時的引述與來源層——共識或仲裁）。
• screen 兩次執行 → screen-arb：僅「一有一無」的歌 入仲裁輸入 JSONL（依 ID 升序），content 為 {"lyrics": …, "evidence": <肯定方引述>}。
• screen 定案：命中集合＝兩次皆有 ∪ 仲裁裁定有。
• 命名鏈的輸入構成：-name 輸入的組 ID 依最終分組 之組序（上節第 5 點）編 g1、g2、…，組內成員字典序； -name-arb 輸入中每組的兩個候選名按字典序排列 ——不按執行別，避免順序洩漏何方所取；taken 為已 定案名的字典序清單。
• 女性力量候選集：於 cap 詞彙表定案後、黃金標準 編碼開始前，由研究者指認詞彙表中屬「女性力量」概念 域的組（指認及理由記入決策日誌），候選集＝code 定案 標籤含該等組者 ∪ screen 命中者。
• 序列化通則：所有中間檔為 UTF-8 JSON，鍵序與元素 序皆依上列規則明定，無時間戳、無隨機成分；解析一律 偵測重複鍵，違規即失敗。JSONL 一律以換行字元（\n） 切行——歌詞含 U+2028 等 Unicode 行分隔符， str.splitlines() 類的通用切行會截斷 JSON 字串 （實測踩中）。給定相同的 LLM 執行輸出， 全部交接產物逐位元組可再生。

執行與稽核

• 每一步驟以 run-llm <定義檔> <輸入檔> <歸檔目錄> 執行；獨立執行兩次＝重現命令清單上的兩行命令，各自 歸檔（runs/<定義檔名>/run1、run2），仲裁與命名 各為獨立步驟、獨立歸檔。
• 比對、裁決套用、重組、對映皆為確定性程式（子命令）， 其輸入輸出檔隨 runs/ 歸檔，JSON 解析一律偵測重複鍵， 違規即失敗。
• Batch API 的每筆請求自含全部脈絡且互不可見（平台 契約），歌與歌之間的獨立性由此成立；兩次執行的獨立 性由「兩次呼叫、兩個批次、兩份歸檔」的執行結構自明。

映射分析方法

（依 2026-07-30 決策，於看到結果前寫定；待黃金標準 編碼展開前補入。）