Add the natural-coding definition files with single-pass convergence

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-04 23:23:25 +08:00
co-authored by Claude Fable 5
parent aa65f6a3b3
commit cbc91047b5
12 changed files with 393 additions and 29 deletions
+123
View File
@@ -0,0 +1,123 @@
# 方法細節
(全文方法節底稿。演算法在執行前寫定;任何修訂記入
`decision-log.md`。定義檔全文見 `prompts/`,執行紀錄見
`runs/`。)
## 自然編碼管線總覽
四步驟:自由標註(tag,兩次進池)→ 自然收斂(merge,
單次)→ 強制收斂(cap,單次)→ 全量編碼(code,2+1),
另設「女性力量」單目標篩選(screen,2+1)作黃金標準取樣
的補漏網。歌詞只出現在 tag、code、screen 與其仲裁步驟;
merge、cap 不接觸歌詞。設計原則見 `research-plan.md`
本檔記載可重現的演算法細節。
## 詞彙表建構(merge、cap)——單次記錄性程序
merge 與 cap 各以單次執行完成,執行內自行為各組命名,
輸出具名分組(組名 → 成員詞)。不做重複執行與仲裁。
- **定位**:詞彙表是研究的儀器,不是量測。詞彙表凍結
入庫後,下游全部量測(編碼 vs 黃金標準)以同一把尺
進行,內部一致;建構過程的抽樣變異屬「揭露的儀器
選擇」,不污染量測。此與質性研究慣行一致——codebook
建構本為單次的詮釋程序,信度檢驗施於編碼應用層。
- **取捨紀錄**:曾設計逐對仲裁鏈(共識塊、分歧塊對三票
多數、命名 2+1;完整版本保存於分支 `tag-algo-13`)。
棄用理由:逐對多數決雖降低單對變異,但遞移閉包會放大
結構層變異,淨縮減未經證實;其複雜度成本卻是確定的;
且縮減的是儀器變異——對論文主張無關緊要的量。
- **確定性驗證**(違規即依協定修訂定義檔重跑):輸出須
為輸入詞集的完整分割(缺詞、多詞、重複即失敗);組名
唯一且符合格式;cap 組數 ≤ 50。
- **收斂軌跡**:原始關鍵字 → merge 組名 → cap 組名,
兩份執行輸出本身即完整記錄。
## 編碼步驟(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 的輸入;原始關鍵字不下傳。
- **cap → code 定義檔**:cap 輸出的組名以字典序逐行填入
`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 定案**:命中集合=兩次皆有 ∪ 仲裁裁定有。
- **女性力量候選集**:於 cap 詞彙表定案後、黃金標準
編碼開始前,由研究者指認詞彙表中屬「女性力量」概念
域的組(指認及理由記入決策日誌),候選集=code 定案
標籤含該等組者 ∪ screen 命中者。
- **序列化通則**:所有中間檔為 UTF-8 JSON,鍵序與元素
序皆依上列規則明定,無時間戳、無隨機成分;解析一律
偵測重複鍵,違規即失敗。JSONL 一律以換行字元(\n)
切行——歌詞含 U+0085 等控制字元時,
`str.splitlines()` 類的通用切行會截斷 JSON 字串
(實測踩中)。給定相同的 LLM 執行輸出,全部交接產物
逐位元組可再生。
## 執行與稽核
- 每一步驟以 `run-llm <定義檔> <輸入檔> <歸檔目錄>`
執行;2+1 步驟的兩次執行=重現命令清單上的兩行命令,
各自歸檔(`runs/<定義檔名>/run1``run2`),仲裁為
獨立步驟、獨立歸檔;單次步驟(merge、cap)一行命令、
一份歸檔。
- 進池、比對、裁決套用、對映皆為確定性程式(子命令),
其輸入輸出檔隨 runs/ 歸檔。
- Batch API 的每筆請求自含全部脈絡且互不可見(平台
契約),歌與歌之間的獨立性由此成立;兩次執行的獨立
性由「兩次呼叫、兩個批次、兩份歸檔」的執行結構自明。
## 映射分析方法
(依 2026-07-30 決策,於看到結果前寫定;待黃金標準
編碼展開前補入。)