如何检查两位 Reddit 评论编码员之间的一致性

设置你的评论样本

先用已知的采集工具收集公开帖子串。Reddit Comments 公开构建版本 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`。数据集状态值只有 `ok`、`deleted` 和 `removed`。把不可用、已删除或已移除的文本、缺失的 ID 以及采集失败留在可用编码单元之外。把它们保留在单独的缺失判定台账中。在工作表中清点各自不同的已知 ID，每个 ID 只计一次，而不是去寻找一个 unique-comment 输出字段。

当前 1.0.7 公开构建版本的 AskMarketing 对照返回了 3 个各自不同的已知评论 ID 和非空白正文，而不是已保存的 LocalLLaMA 样本。处理结果 isComplete 为 true，同时输入为 partial/capped，这说明它是试点样本，而不是完整帖子串覆盖。Parent、depth 和 hiddenBranchesRemaining 为 null，本编码员方法不使用它们。

独立编码与一致性检查的八个步骤

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 个单元有两项已知的独立判定，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，也不要发明一个通用的通过阈值。

复核分歧并修订规则

在独立一轮之后，结合来源上下文阅读分歧。对于那条愿望评论，这条规则既可以读成当前缺陷，也可以读成期望的功能。记录该分歧并澄清规则文本。裁定是后来的共同决定，不属于原始一致性统计量。

原样保存最初的独立判定表和一致性表。为修订后的规则标注版本，并在新样本或明确声明的重新编码样本上测试它。在更广泛地应用该编码之前，先交付一致性表、缺失判定台账和具体的规则更改。