Add the natural-coding definition files and the convergence algorithms
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,197 @@
|
||||
# 方法細節
|
||||
|
||||
(全文方法節底稿。演算法在執行前寫定;任何修訂記入
|
||||
`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 決策,於看到結果前寫定;待黃金標準
|
||||
編碼展開前補入。)
|
||||
Reference in New Issue
Block a user