如何檢查兩名 Reddit 留言編碼員的一致性

設定你的留言樣本

先用一個已知的收集工具，收集公開討論串。Reddit Comments public build 1.0.7 接受 postUrls，數量為 1 至 50 個已知的公開 Reddit 帖文 URL，以及 maxCommentsPerPost，範圍為 1 至 500。更換樣本討論串，並把已儲存上限由 250 改為 3，以作先導。

覆核 OUTPUT 欄位，包括 `commentsSaved`、`duplicatesSkipped`、`hiddenBranchesRemaining`、`completionReason`、`status`、`isComplete`、`inputResults`，以及每個輸入的 `commentsFound`、`commentsSaved`、`status` 和 `reason`。把處理完成與完整討論串覆蓋分開看待。

抽取數據集欄位，包括 `postId`、`commentId`、`body`、`authorName`、`status`、`statusReason` 和 `observedAt`。數據集 status 的值只有 `ok`、`deleted` 和 `removed`。把未能取得、已刪除或已移除的文字、缺失的 ID，以及收集失敗，放在可用編碼單位之外。把它們保留在另一份缺失決策紀錄。在你的工作表中點算不同的已知 ID，每個 ID 只計一次，而不是尋找一個 unique-comment 輸出欄位。

現時的 1.0.7 公開版本中，AskMarketing 對照傳回 3 個不同的已知留言 ID，以及非空白 body，而不是已儲存的 LocalLLaMA 樣本。處理結果 isComplete 為 true，與 partial/capped 輸入並存，證明這是先導樣本，而不是完整討論串覆蓋。Parent、depth 和 hiddenBranchesRemaining 的值是 null，這個編碼員方法不會使用它們。

獨立編碼與一致性檢查的 8 個步驟

1. 寫明你的研究問題，以及一個狹窄的二元規則版本，例如 explicit_current_failure，並附上正例、反例和含糊例子。
2. 為兩名編碼員選擇同一個有限的公開樣本，並在私人工作登記冊中登記已知留言 ID 和來源 URL。
3. 以明確原因，把不可用文字從合資格樣本中移除，並記入缺失決策紀錄。
4. 給每名編碼員相同的文字和語境、相同的規則版本，以及一份獨立的決策表，讓他們在看不到對方工作的情況下獨立標記，並允許 unknown。
5. 按已檢查的留言單位 ID 合併兩份決策表，並把 unknown、absent 和無效決策保留在缺失決策紀錄。
6. 只用以已知決策配對的單位建立二乘二表，並計算觀察一致性、期望一致性和 Cohen's kappa。
7. 在獨立輪次之後，於來源語境中覆核分歧，以澄清規則，並使裁決與最初的統計分開。
8. 原樣儲存原來的獨立決策表，為修訂規則標示版本，並在新的樣本，或已明確聲明為重新編碼的樣本上測試它。

撰寫規則並進行獨立編碼

寫明你的研究問題和一條狹窄的二元規則。在本指南中，編碼是 explicit_current_failure。若文字陳述一項現存的產品故障，標 yes；若文字沒有陳述該故障，標 no。為編碼員提供正例、反例和含糊例子。當文字或目標無法判定時，允許 unknown。

為兩名編碼員選擇同一個有限的公開樣本。在私人工作登記冊中保留已知留言 ID 和來源 URL。把一整則留言定義為一個編碼單位。以明確原因，把不可用文字從合資格樣本中移除。給每名編碼員相同的文字和語境、相同的規則版本，以及一份獨立的決策表。在這一輪中，編碼員不得看到彼此的決策。編碼員可以標 unknown；不要強迫他們選擇 yes 或 no。

計算一致性與 kappa

按已檢查的留言單位 ID 合併兩份決策表。記錄編碼員 A 的決策、編碼員 B 的決策、規則版本，以及兩項決策是否都為已知。某一來源在其中一份決策表中缺失，這不是一項分歧。只用以已知決策配對的單位建立二乘二表。

觀察一致性寫作 p_o，是主對角線上兩個相符單元格計數之和除以 n。期望一致性寫作 p_e，是對應編碼員邊際比例的乘積之和。當分母非零時，Cohen's kappa 的計算是（p_o 減 p_e）除以（1 減 p_e）。這個期望來自這些編碼員邊際，不是來自一個已知的總體真實標籤。

虛構審計例子與決策紀錄

以下所有留言、決策和計數都是原創虛構。假設有 22 個合資格文字單位。20 個單位有 2 項已知的獨立決策，1 個單位的編碼員 A 為 unknown，1 個單位的編碼員 B 為 absent。只有 20 個單位進入一致性表。

虛構缺失決策紀錄

這份紀錄說明，22 個合資格來源單位之中，有 2 個被排除的決策缺口，剩下 20 個已配對且已知的單位進入一致性表。缺失決策不是分歧，並且留在 n 等於 20 的分母之外。

主要一致性表（20 個已配對單位）

編碼員 A 的邊際顯示 10 個 yes 和 10 個 no。編碼員 B 的邊際顯示 9 個 yes 和 11 個 no。20 項已配對決策之中有 17 項相符，因此觀察一致性 p_o 等於 0.85。

期望一致性 p_e 的計算是（10 除以 20，乘 9 除以 20）加上（10 除以 20，乘 11 除以 20），結果等於 0.50。

Cohen's kappa 是（0.85 減 0.50）除以（1 減 0.50），結果等於 0.70。

3 項已配對分歧，以及 2 個被排除的決策缺口，仍然分開。這個虛構例子沒有為任何真實客戶標上標籤，也沒有證明這個編碼是正確的。

例子留言文字與規則處理

• 雙方同意為 yes 的留言：「日曆同步每天早上都會失敗。」（直接陳述一項現存缺陷）。
• 雙方同意為 no 的留言：「日曆的顏色是藍色。」（沒有陳述缺陷）。
• 含糊的願望留言：「我希望日曆同步可以用。」（這可以表示一項現存缺陷，或一項想要的能力；它沒有證明作者在要求一項功能。保留 unknown 或含糊選擇，以及其後的語境或規則澄清，不要強加意圖）。

診斷表一（高一致性、低 kappa）

編碼員邊際：編碼員 A 有 19 個 yes 和 1 個 no。編碼員 B 有 19 個 yes 和 1 個 no。單位總數 n 等於 20。觀察一致性 p_o 等於 0.90。期望一致性 p_e 等於 0.905。kappa 等於負 1 除以 19，約為 -0.05263。

診斷表二（kappa 未定義）

編碼員邊際：編碼員 A 有 20 個 yes 和 0 個 no。編碼員 B 有 20 個 yes 和 0 個 no。單位總數 n 等於 20。觀察一致性 p_o 和期望一致性 p_e 都等於 1。這使 kappa 未定義。不要把一個未定義的值稱為完美 kappa，也不要發明一個通用的合格門檻。

覆核分歧並修訂規則

在獨立輪次之後，於來源語境中閱讀分歧。對於該願望留言，這條規則可以理解為一項現存缺陷，或一項想要的功能。記錄這項分歧，並澄清規則文字。裁決是其後的共同決定，不屬於原來的一致性統計。

原樣儲存原來的獨立決策表和一致性表。為修訂規則標示版本，並在新的樣本，或已明確聲明為重新編碼的樣本上測試它。在更廣泛套用這個編碼之前，先交付一致性表、缺失決策紀錄，以及具體的規則變更。