Settle the coding by a majority of three runs instead of an arbitration
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude Opus 5
@@ -528,3 +528,19 @@
|
||||
首次執行有 2 首無輸出）。即：禁止在輸出裏推理不只改變
|
||||
格式，也改變了裁決——少了邊寫邊自我否定的過程，模型
|
||||
傾向保留。此為儀器行為的一部分，不作修補。
|
||||
- **步驟 3 由「兩次執行＋一次仲裁」改為「三次執行＋
|
||||
多數決」**：仲裁者所見只有標出該碼的那一次所附的引述，
|
||||
另一方無物可呈，輸入本身即單邊。實測仲裁保留送裁標籤
|
||||
的 87.2%，而中立的第三票所隱含者約 50%——爭議 1,699 個
|
||||
碼，保留半數時定案表為 14,715 個碼，恰為單次執行平均的
|
||||
14,716——故仲裁使定案表的編碼密度較任一次單獨執行高出
|
||||
約 4%；`women-power` 送裁 7 個、保留 7 個。改為三次條件
|
||||
相同的執行後，這層不對稱消失，儀器亦得以「多數決」一語
|
||||
如實描述，不再夾帶研究者設計的裁決框架。第三票取全量
|
||||
而非只補問前兩次的分歧：兩者計票結果相同（2-0 與 0-2 的
|
||||
標籤第三票翻不動），但只補問分歧會使該票在縮減的碼表下
|
||||
取得，與前兩票條件不同。連帶：`03-01-code` 改名
|
||||
`03-code`（步驟 3 只剩一個次步）、仲裁的定義檔與歸檔
|
||||
刪除、`compare-codings` 刪除——其唯一用途是建構仲裁
|
||||
輸入。已花費的兩次仲裁執行保留於 `run-costs.md` 供總
|
||||
支出核算。
|
||||
|
||||
+42
-33
@@ -7,10 +7,10 @@
|
||||
## 自然編碼管線總覽
|
||||
|
||||
三個步驟：步驟 1 自由標註（兩次執行進池）→ 步驟 2 詞彙表
|
||||
建構（詞向量分群，確定性）→ 步驟 3 全量編碼（2+1）。歌詞
|
||||
只出現在步驟 1 與步驟 3；步驟 2 完全不接觸歌詞，也不呼叫
|
||||
LLM。設計原則見 `research-plan.md`；本檔記載可重現的
|
||||
演算法細節。
|
||||
建構（詞向量分群，確定性）→ 步驟 3 全量編碼（三次執行＋
|
||||
多數決）。歌詞只出現在步驟 1 與步驟 3；步驟 2 完全不接觸
|
||||
歌詞，也不呼叫 LLM。設計原則見 `research-plan.md`；本檔
|
||||
記載可重現的演算法細節。
|
||||
|
||||
編號的所指為**研究程序的工序**，不是定義檔：步驟 1 與
|
||||
步驟 3 有定義檔（`prompts/`），步驟 2 沒有——它是單一
|
||||
@@ -91,19 +91,29 @@ LLM。設計原則見 `research-plan.md`；本檔記載可重現的
|
||||
把該主題的顯著性人為抬高。兩者的落點差異本身即可報告
|
||||
的結果。
|
||||
|
||||
## 步驟 3 編碼的 2+1 比對與仲裁
|
||||
## 步驟 3 編碼的三次執行與多數決
|
||||
|
||||
- **步驟 3-1 code**：逐首比對兩次執行的標籤集合（引述不
|
||||
參與比對）。兩次皆有的標籤為共識保留、兩次皆無為
|
||||
共識不標；單邊標籤送仲裁。
|
||||
- **步驟 3-2 arbitration**：仲裁者看歌詞全文與該標籤的引述
|
||||
（不含執行別），裁決保留者附仲裁者自己的引述，剔除
|
||||
者不列。剔除集合＝送裁鍵減輸出鍵，由程式推得。
|
||||
- 仲裁者的引述可能與原引述不同：仲裁是對歌詞的重新
|
||||
判讀，其引述是該裁決自身的依據，非轉抄。
|
||||
- 送入仲裁的標籤即模型自身不穩定的邊界判斷，其裁決為
|
||||
單次記錄性決定，不宣稱可再生；可重現性依計畫定義為
|
||||
「程序透明＋可稽核」，裁決與其輸入全程歸檔。
|
||||
- **三次執行**：同一份定義檔、同一份輸入檔，獨立執行
|
||||
三次，三份歸檔並列（`runs/03-code/run1`、`run2`、
|
||||
`run3`），彼此無先後主從之別。
|
||||
- **多數決**：一首歌的一個標籤，三次執行中至少兩次標出
|
||||
即收入定案編碼。三票不平手，裁決規則因此無例外條款，
|
||||
計票由確定性子命令完成（見交接契約）。
|
||||
- **第三票取全量**：只對前兩次分歧的標籤補問第三票，
|
||||
計票結果相同；仍採全量執行——全部歌曲、全部關鍵字
|
||||
——使三票在同一條件下取得。
|
||||
- **定案表只記歌曲與標籤**：引述留在三份執行歸檔，定案
|
||||
表不轉抄。定案即三票的計票結果，每一票各自的引述
|
||||
依據於其歸檔逐筆可查。
|
||||
- **對邊緣標籤的作用**：兩次執行只分得出「兩次皆標」與
|
||||
「僅一次標」；三次執行還分得出 3-0 與 2-1，故「定案
|
||||
編碼中有多少比例僅以一票之差成立」成為可報告的量。
|
||||
至於判定本身，兩次執行相左的標籤在何種協定下都由第三
|
||||
個判斷定奪，票數不使不確定性消失：某標籤於單次執行被
|
||||
標出的傾向若恰為一半，任何票數皆為擲幣。三票之效在
|
||||
傾向偏離一半處——多數決將判定推向該傾向本身（單次
|
||||
0.7 者為 0.78，0.9 者為 0.97），程序重跑的一致性因而
|
||||
高於單次執行，唯獨恰半處無從改善。
|
||||
|
||||
## 女性力量候選集
|
||||
|
||||
@@ -140,15 +150,14 @@ LLM。設計原則見 `research-plan.md`；本檔記載可重現的
|
||||
固定鍵序序列化的 `{"lyrics": …, "keywords": [...]}`，
|
||||
依歌曲 ID 升序。碼表以參數傳入而非填進定義檔——定義
|
||||
檔只規定任務形狀，換詞彙表、換演算法都不必改它。
|
||||
- **步驟 3-1 兩次執行 → 3-2**：逐首比對標籤集合（鍵
|
||||
集合，引述不參與比對）；僅有分歧的歌入仲裁輸入
|
||||
JSONL，依歌曲 ID 升序，每筆 `id` 沿用 `song-<ID>`、
|
||||
`content` 為固定鍵序序列化的
|
||||
`{"lyrics": …, "disagreements": …}`，disagreements
|
||||
鍵按字典序。
|
||||
- **步驟 3 定案**：每首歌的最終標籤為共識標籤加上仲裁
|
||||
保留的標籤，寫入逐首紀錄檔（歌依 ID 升序、標籤按
|
||||
字典序）。
|
||||
- **步驟 3 定案**：`tally-codings <執行歸檔 1> <執行歸檔
|
||||
2> <執行歸檔 3> <輸出 CSV>` 讀三份執行歸檔的
|
||||
`output.jsonl`，逐首取標籤鍵集合（引述不參與計票），
|
||||
三份歌曲清單不一致即失敗、不出檔。某首歌的某個標籤
|
||||
於三份中出現至少兩次即寫出一列，產出
|
||||
`results/codings.csv`，欄位 `Song`、`Keyword`，一列
|
||||
一個標籤，歌依 ID 數值升序、同一首歌的標籤按字典序，
|
||||
換行為 CRLF（同專案其他 CSV）。
|
||||
- **序列化通則**：所有中間檔為 UTF-8，欄序、鍵序與元素
|
||||
序皆依上列規則明定，無時間戳、無隨機成分；JSON 解析
|
||||
一律偵測重複鍵，違規即失敗。人讀為主的產物採純文字或
|
||||
@@ -159,15 +168,15 @@ LLM。設計原則見 `research-plan.md`；本檔記載可重現的
|
||||
## 執行與稽核
|
||||
|
||||
- LLM 步驟以 `run-llm <定義檔> <輸入檔> <歸檔目錄>`
|
||||
執行；2+1 步驟的兩次執行＝重現命令清單上的兩行命令，
|
||||
各自歸檔（`runs/<步驟>/run1`、`run2`），仲裁為獨立
|
||||
步驟、獨立歸檔。
|
||||
- 確定性步驟（進池、分群、比對、裁決套用、對映）為
|
||||
子命令，其輸入輸出檔同隨 `runs/` 歸檔；因無執行變異，
|
||||
歸檔目錄下不分 `run<N>` 層。
|
||||
執行；一步的 N 次執行＝重現命令清單上的 N 行命令，
|
||||
各自歸檔（`runs/<步驟>/run1`、`run2`，編碼步驟另有
|
||||
`run3`）。
|
||||
- 確定性步驟（進池、分群、計票、對映）為子命令，其
|
||||
輸入輸出檔同隨 `runs/` 歸檔；因無執行變異，歸檔目錄
|
||||
下不分 `run<N>` 層。
|
||||
- Batch API 的每筆請求自含全部脈絡且互不可見（平台
|
||||
契約），歌與歌之間的獨立性由此成立；兩次執行的獨立
|
||||
性由「兩次呼叫、兩個批次、兩份歸檔」的執行結構自明。
|
||||
契約），歌與歌之間的獨立性由此成立；各次執行的獨立
|
||||
性由「一次呼叫、一個批次、一份歸檔」的執行結構自明。
|
||||
- 每次 `run-llm` 執行的 token 用量與費用記入
|
||||
`run-costs.md`，被取代的執行一併保留供總支出核算。
|
||||
|
||||
|
||||
@@ -24,8 +24,8 @@ pop-fem-audit/
|
||||
│ ├── songs.csv # 歌曲報表（人讀；進 git）
|
||||
│ └── artists.csv # 歌手報表（人讀；進 git）
|
||||
├── prompts/ # LLM 定義檔（逐字作為 system prompt）
|
||||
│ └── <步>-<次步>-<task>.md # 01-tag.md、03-01-code.md、
|
||||
│ # 03-02-arbitration.md
|
||||
│ └── <步>-<次步>-<task>.md # 01-tag.md、03-code.md
|
||||
│ # （步內僅一個執行時省略次步）
|
||||
│ # 不帶版本號，版本即 git 歷史
|
||||
│ # （編號的所指是工序：確定性
|
||||
│ # 的步驟 2 無定義檔仍佔一號；
|
||||
@@ -54,7 +54,7 @@ pop-fem-audit/
|
||||
│ │ │ │ # into the codes (step 2)
|
||||
│ │ │ └── run_llm.py # API 執行器：一份定義檔＋一份輸入
|
||||
│ │ │ # →歸檔至指定目錄（Batch API）；
|
||||
│ │ │ # 比對與仲裁編排由獨立子命令承擔
|
||||
│ │ │ # 多次執行的計票由獨立子命令承擔
|
||||
│ │ ├── config.py # pydantic-settings 設定（.env）
|
||||
│ │ ├── database.py # SQLAlchemy engine / session / Base
|
||||
│ │ ├── models.py # SQLAlchemy ORM 資料模型
|
||||
@@ -62,7 +62,7 @@ pop-fem-audit/
|
||||
│ └── tests/ # 單元測試（unittest）
|
||||
├── runs/ # 現行執行的完整稽核紀錄（進 git；
|
||||
│ │ # 重跑同一 run 須明示 --replace）
|
||||
│ ├── <步驟名>/ # 仲裁自成一步，居自己的目錄
|
||||
│ ├── <步驟名>/ # 一步一個目錄（如 03-code）
|
||||
│ │ └── run<N>/ # LLM 步驟：每個 run 一份自我
|
||||
│ │ ├── prompt.md # 完備歸檔（定義檔快照）
|
||||
│ │ ├── output.jsonl # 該次執行原始輸出
|
||||
|
||||
+19
-17
@@ -13,13 +13,14 @@
|
||||
- **執行原則**：主會話只做討論；所有分析由 deterministic script
|
||||
執行。LLM 步驟以 Python script 呼叫 Anthropic Messages API
|
||||
（個人 Console 帳號、Batch API 五折），定義檔逐字作為 system
|
||||
prompt。2+1 協定適用於語料層的逐首判斷（編碼）：
|
||||
「同一定義檔獨立執行兩次＋一次仲裁」，仲裁只裁程式算出
|
||||
的分歧。自由生成步驟（自由標註）兩次執行全數進池、不
|
||||
仲裁——自由詞彙兩次輸出不共享比對單位，無物可裁。詞彙
|
||||
prompt。語料層的逐首判斷（編碼）採「同一定義檔獨立
|
||||
執行三次＋多數決」：三次條件相同，某首歌的某個標籤
|
||||
三次中至少兩次標出即收入定案，計票由確定性子命令
|
||||
完成。自由生成步驟（自由標註）兩次執行全數進池——
|
||||
自由詞彙兩次輸出不共享比對單位，無可計之票。詞彙
|
||||
表建構不經 LLM，改由詞向量嵌入＋確定性分群產生——詞彙
|
||||
表是揭露的儀器選擇，非量測；信度檢驗施於編碼層（詳見
|
||||
`methodology.md`）。仲裁或驗證結果不符預期則修訂定義檔
|
||||
`methodology.md`）。驗證結果不符預期則修訂定義檔
|
||||
重跑該循環。
|
||||
- **提示詞只定格式、不定語意**：研究對象是通用 LLM 以其
|
||||
網路語料知識背景所做的自然編碼，編碼結果本身是批判對象。
|
||||
@@ -32,8 +33,8 @@
|
||||
自足設計：同語料、同模型、僅提示不同，對照黃金標準。
|
||||
其他工具性環節於階段 3 以校準樣本實測 Sonnet 4.6 vs Opus 5
|
||||
的一致率後決定是否升級。
|
||||
- **信度與效度分工**：2+1 協定量測穩定性（intra-rater
|
||||
reliability，報告一致率／kappa）；效度靠理論 codebook 與
|
||||
- **信度與效度分工**：三次獨立執行量測穩定性（intra-rater
|
||||
reliability，報告兩兩一致率／kappa）；效度靠理論 codebook 與
|
||||
人工黃金標準終審。可重現性定義為「程序透明＋可稽核」：
|
||||
公開定義檔、記錄 model ID 與執行時間、保存全部原始輸出。
|
||||
|
||||
@@ -93,7 +94,7 @@
|
||||
|
||||
1. **自由標註（步驟 1）**：逐首歌請模型標註 thematic
|
||||
keywords，附歌詞引述；提示零語意內容。獨立執行兩次，
|
||||
兩次輸出全數進池（記錄執行別），不仲裁。粒度鎖定
|
||||
兩次輸出全數進池（記錄執行別）。粒度鎖定
|
||||
thematic keywords：前導研究三粒度比較（keywords 過碎、
|
||||
themes 過早抽象）之繼承，於執行前鎖定，防止事後擇優。
|
||||
2. **詞彙表建構（步驟 2）**：兩次執行的關鍵字取聯集去重
|
||||
@@ -102,9 +103,11 @@
|
||||
演算法
|
||||
結構保證。頻次不入收斂：頻率的分析角色由步驟 3 編碼
|
||||
承擔；池中頻次含跨執行噪音。
|
||||
3. **編碼（步驟 3）**：以定稿詞彙表對全部歌曲 2+1 編碼
|
||||
——模型讀歌詞、逐標籤附引述；逐首計一致率，分歧逐首
|
||||
仲裁（仲裁者看歌詞與該標籤引述）。此為主儀器，
|
||||
3. **編碼（步驟 3）**：以定稿詞彙表對全部歌曲編碼——
|
||||
模型讀歌詞、逐標籤附引述；同一定義檔獨立執行三次，
|
||||
逐首計兩兩一致率，某首歌的某個標籤三次中至少兩次
|
||||
標出即收入定案（`tally-codings` 計票，詳見
|
||||
`methodology.md`）。此為主儀器，
|
||||
「女性力量」候選集由此浮現；亦是對前導研究「映回後
|
||||
未對照歌詞」限制的明文改良。沿收斂軌跡的機械對映
|
||||
（純程式）保留為零成本診斷副產品，量測收斂軌跡的
|
||||
@@ -121,9 +124,8 @@
|
||||
|
||||
定義檔命名 `prompts/<步>-<次步>-<task>.md`——步為研究
|
||||
程序的工序序，次步為步內執行順序（僅一個執行時省略），
|
||||
讀者依編號先後依循：01-tag.md、03-01-code.md、
|
||||
03-02-arbitration.md。檔名與目錄名補零只為排序，正文
|
||||
一律寫「步驟 1」「步驟 3-2」。
|
||||
讀者依編號先後依循：01-tag.md、03-code.md。檔名與目錄名
|
||||
補零只為排序，正文一律寫「步驟 1」「步驟 3」。
|
||||
編號的所指是工序而非定義檔，因此確定性的第 2 步雖無
|
||||
定義檔仍佔一個編號，其歸檔為 `runs/02-cluster/`。檔名不帶
|
||||
版本號——版本即 git 歷史，失敗的版本不保留，需要回看的
|
||||
@@ -137,11 +139,11 @@
|
||||
|---|---|---|---|
|
||||
| 0 | 基礎建設：git init、目錄結構、.gitignore、決策日誌、runner script（含 Batch API）、codebook v0 骨架 | script + 討論 | 7/30–7/31 |
|
||||
| 1 | 資料準備：`run_llm` 改走統一設定 → `build-db`（解析榜單成 songs/chart_entries/artists/song_artists）→ `import-lyrics`（pilot 2018–2025）→ `fetch-lyrics`（2016–17 與缺漏，Lyrics.ovh / LRCLIB）→ `fetch-artists`（Wikidata 快照）→ `export-llm-input` | 子命令 | 7/31–8/3 |
|
||||
| 2 | 自然編碼管線：tag ×2 進池 → 詞向量分群 k=100 → 併入 women-power → 詞彙表定稿 → code 2+1（全 883 首，附引述） | API + script | 8/4–8/7 |
|
||||
| 2 | 自然編碼管線：tag ×2 進池 → 詞向量分群 k=100 → 併入 women-power → 詞彙表定稿 → code ×3 進多數決（全 883 首，附引述） | API + script | 8/4–8/7 |
|
||||
| 3 | 黃金標準：依 codebook 人工逐首判定 genuine/peripheral/fake，附引用歌詞證據表（LLM 只做摘錄，不給判定建議）；先以 10–15 首校準樣本試編並修訂 codebook 後凍結；同批校準樣本實測 Sonnet 4.6 vs Opus 5 一致率 | 人工 + script 輔助 | 8/5–8/9 |
|
||||
| 4 | 受控比較（盲點實驗）：條件 A（詞彙層提示）vs 條件 B（框架感知提示），各 2+1，對照黃金標準計算假陽／假陰率 | API | 8/8–8/11 |
|
||||
| 4 | 受控比較（盲點實驗）：條件 A（詞彙層提示）vs 條件 B（框架感知提示），各 ×3 進多數決，對照黃金標準計算假陽／假陰率 | API | 8/8–8/11 |
|
||||
| 4' | 映射分析：自然編碼結果（第 4 步）與黃金標準交叉表；軌跡對映 vs 直接編碼的扭曲診斷（分析方法先寫入 methodology.md 再看結果） | script | 與 4 並行 |
|
||||
| 5 | pussy 修辭分析：script 找含詞歌曲 → LLM 分類（METONYM/ANATOMICAL/COWARD/OTHER + 說話者/指涉對象）2+1 → 人工核定 | script + API | 8/9–8/11 |
|
||||
| 5 | pussy 修辭分析：script 找含詞歌曲 → LLM 分類（METONYM/ANATOMICAL/COWARD/OTHER + 說話者/指涉對象）×3 → 人工核定 | script + API | 8/9–8/11 |
|
||||
| 6 | 統計與圖表：一致率（kappa）、污染率、類型分布、年度趨勢、映射交叉表 | scripts | 8/11–8/12 |
|
||||
| 7 | 撰寫全文＋內部審稿（subagent 以審稿人視角挑毛病，特別是嘻哈女性主義／respectability politics 一題） | 討論 + subagent | 8/11–8/14 |
|
||||
|
||||
|
||||
Reference in New Issue
Block a user