【编程思路】AI 文本检测报告里的可信度和限制字段怎么建模

werdedeage

最近整理一个 AI 文本检测报告的前端展示和 API 返回结构时，发现最容易写歪的地方不是“分数怎么显示”，而是报告对象里要不要把可信度、限制说明和句级信号一起建模。

先说明范围：这里讨论的是检测报告的数据结构、状态边界和 UI 展示，不讨论绕过检测、判定他人违规，也不把检测结果当成作者身份或学术问题的证明。AI 检测只能作为概率信号，可能有误报和漏报，尤其不能作为高影响决策的唯一依据。

我现在倾向于把报告拆成几层：

1. 输入限制层：文本长度、文件大小、文件类型先做硬校验。
2. 评分层：AI-generated score、likely-human score、verdict、risk 分开存，不用一个分数字段包打天下。
3. 证据层：evidenceStrength、analysis bullets、sentenceHighlights 单独展示，避免只给用户一个结论。
4. 限制层：limitations 必须跟着报告、复制摘要和打印导出一起出现。
5. 决策层：业务上只标记“可作为信号”，不标记“可作为证明”。

关键代码草稿如下，重点是让报告对象自己携带限制和人工复核提示：

[code=javascript]
const LIMITS = {
  minChars: 300,
  maxChars: 100000,
  maxFileMb: 12,
};

function normalizeDetectorReport(raw) {
  const aiScore = Number(raw.aiGeneratedScore ?? raw.aiScore ?? 0);
  const humanScore = Number(raw.likelyHumanScore ?? raw.humanScore ?? 0);
  return {
    verdict: String(raw.verdict || "review_required"),
    risk: String(raw.risk || "unknown"),
    aiGeneratedScore: Math.max(0, Math.min(100, aiScore)),
    likelyHumanScore: Math.max(0, Math.min(100, humanScore)),
    evidenceStrength: String(raw.evidenceStrength || "low"),
    analysis: Array.isArray(raw.analysis) ? raw.analysis.slice(0, 8) : [],
    sentenceHighlights: Array.isArray(raw.sentenceHighlights) ? raw.sentenceHighlights : [],
    limitations: [
      "AI detection is probabilistic.",
      "False positives and false negatives are possible.",
      "Do not use this report as the only basis for high-impact decisions.",
    ],
  };
}

function buildReviewDecision(report) {
  const normalized = normalizeDetectorReport(report);
  return {
    canUseAsSignal: true,
    canUseAsProof: false,
    shouldShowLimitations: true,
    needsManualContext: normalized.risk !== "low" || normalized.evidenceStrength !== "strong",
    summary: [
      normalized.verdict,
      "AI score: " + normalized.aiGeneratedScore,
      "Human score: " + normalized.likelyHumanScore,
      "Evidence: " + normalized.evidenceStrength,
    ].join(" | "),
  };
}
[/code]

这里有几个边界我觉得需要提前写清：

- 输入文本太短时不应该硬算出一个看似精确的结论，至少要有最小长度限制。
- PDF/DOCX 如果是在浏览器端抽文本，服务端收到的是抽取后的文本，不要把它说成服务端能原生解析所有文档。
- risk、verdict、score、evidenceStrength 不应混成一个字段，否则 UI 很难解释“高分但证据弱”的情况。
- 复制摘要、打印报告、导出报告时也要带上限制说明，否则用户容易只传播结论。
- 报告应该提醒人工上下文复核，不能鼓励把分数当作惩罚或处分依据。

想请教大家：这类概率检测报告，你们会把 limitations 作为报告对象的必填字段，还是放在 UI 固定文案里？如果后续有复制摘要和打印导出，我更倾向于前者，但会让 API 返回结构变重一些。