登录
首页 >  科技周边 >  人工智能

AI 输出质检流水线实战:规则检查、结构化结果和人工兜底

来源:17golang原创

时间:2026-06-13 09:51:01 394浏览 收藏

AI 应用上线后,最容易被低估的不是“能不能生成”,而是“生成后能不能稳定可用”。一段回复看起来很完整,但可能缺少来源、格式不符合页面字段、出现不该出现的承诺,或者和用户问题偏离太远。如果这些内容直接进入页面、工单或运营后台,后续返工成本会很高。

本文用“AI 生成帮助中心回答”的场景,搭一条轻量质检流水线:模型先产出草稿,程序按规则检查,再要求结构化结果,低分内容进入自动返修或人工兜底。思路参考了 OpenAI 官方关于结构化输出和提示工程的建议,但示例是面向普通业务系统的简化版本。

摘要

AI 输出质检不要只靠人工肉眼看,也不要只靠一句“请严格输出”。更稳的方式是把规则拆成可检查的字段:是否回答了问题、是否有来源、是否触发风险词、是否符合 JSON 结构、是否达到最低质量分。这样系统可以自动决定“直接通过、自动返修、人工复核”。

适合人群

适合正在做 AI 客服、知识库问答、内容生成、运营文案辅助、工单摘要的开发者。你需要了解基本 JavaScript、JSON 和接口返回处理。

目录

  • 为什么 AI 输出需要质检
  • 把模型输出接入质检流水线
  • 用结构化结果固定字段
  • 低分输出进入返修或人工兜底
  • 上线前检查清单

一、为什么 AI 输出需要质检

很多团队刚接入 AI 时,会把重点放在提示词上:写清楚角色、任务、语气、长度限制。这当然重要,但提示词不是保险箱。业务系统仍然需要在模型返回后做一层检查,尤其是以下几类场景:

  • 回答要展示给外部用户,不能出现过度承诺。
  • 回复必须带来源,否则客服无法追溯依据。
  • 内容要进入固定字段,比如标题、摘要、标签、风险提示。
  • 低质量内容不能直接发布,要进入返修或人工复核。

因此,AI 输出更像“候选内容”,不是最终内容。它应该先经过规则检查,再决定去向。

二、把模型输出接入质检流水线

一条最小可用的质检流水线可以分成四步:用户问题和模型草稿进入系统;规则检查器扫描格式、来源和风险;模型或程序返回结构化 JSON;最后根据结果决定通过还是返修。

AI 输出从用户草稿进入规则检查生成 JSON 结果再决定通过或返修的质检流水线

这张图里有两个关键点:第一,规则检查要靠近输出入口,不能等到发布前才发现问题;第二,质检结果要结构化,方便后续程序分支处理。

先写一个简单的规则检查器,模拟业务侧对回答文本做快速扫描:

const riskWords = ["保证赚钱", "百分百解决", "无需审核"];

function checkDraft(answer) {
  const issues = [];

  if (answer.length  answer.includes(word));
  if (risky) {
    issues.push({ type: "risk_word", message: `命中风险词:${risky}` });
  }

  return issues;
}

真实业务里,规则可以来自数据库配置,也可以按栏目、业务线、用户等级做不同阈值。最重要的是:规则要能解释,方便运营和开发一起调整。

三、用结构化结果固定字段

如果只让模型返回一段自然语言,后续程序很难稳定判断质量。更推荐让模型输出固定字段,例如 scorepassedissuesnextAction。官方结构化输出文档也强调,可以用 JSON Schema 约束模型返回的结构。

{
  "score": 82,
  "passed": true,
  "issues": [],
  "nextAction": "publish",
  "rewriteHint": ""
}

业务侧可以先定义一个结果对象,再把规则检查和模型自检结果合并:

function buildQualityResult(answer) {
  const issues = checkDraft(answer);
  const baseScore = 100;
  const score = Math.max(0, baseScore - issues.length * 25);

  let nextAction = "publish";
  if (score  0) {
    nextAction = "rewrite";
  }

  return {
    score,
    passed: nextAction === "publish",
    issues,
    nextAction,
    rewriteHint: issues.map((item) => item.message).join(";"),
  };
}

这样做的好处是清楚:页面只关心 passed,任务队列只关心 nextAction,运营后台可以展示 issuesrewriteHint

四、低分输出进入返修或人工兜底

不要把所有失败都丢给人工。更合理的策略是按分数和问题类型分流:

  • 分数高且无问题:直接通过。
  • 缺来源、太短、格式不齐:自动返修一次。
  • 命中风险词、事实不确定、用户投诉相关:进入人工复核。

AI 回复经过质量分门控后直接通过自动返修或进入人工复核的决策路径

返修不是简单地“再生成一次”,而是把质检结果写回提示词,让模型明确知道要改什么:

function buildRewritePrompt(question, answer, qualityResult) {
  return [
    "请根据质检问题修正回答。",
    `用户问题:${question}`,
    `原回答:${answer}`,
    `需要修正:${qualityResult.rewriteHint}`,
    "要求:补足来源,删除不确定承诺,保持回答简洁。"
  ].join("\\n");
}

自动返修建议限制次数,比如最多 1 到 2 次。多次仍然不过,就进入人工复核,避免系统在低质量内容上反复消耗。

五、接口返回建议

对接前后端时,可以把 AI 草稿和质检结果一起返回,方便页面展示状态。

{
  "draft": "这里是 AI 生成的回答正文...",
  "quality": {
    "score": 75,
    "passed": false,
    "issues": [
      { "type": "missing_source", "message": "缺少来源说明" }
    ],
    "nextAction": "rewrite",
    "rewriteHint": "缺少来源说明"
  }
}

前端可以用这个结构做三种状态:绿色表示可发布,橙色表示返修中,红色表示需要人工处理。这样运营同学不需要猜测模型为什么被拦下。

常见问题

1. 质检规则要不要全部交给模型判断?

不建议。长度、必填字段、风险词、JSON 格式这类规则更适合程序检查;语义完整度、回答是否贴题,可以交给模型辅助判断。两者结合更稳。

2. 分数阈值怎么定?

先从简单阈值开始,比如 80 分以上通过,60 到 79 分返修,低于 60 分人工复核。上线后根据真实误拦和漏拦情况调整。

3. 结构化结果还需要人工看吗?

需要。结构化结果解决的是“程序能读懂”,不代表内容一定正确。涉及投诉、法律、医疗、财务等高风险场景,人工兜底仍然要保留。

上线前检查清单

  • 是否定义了通过、返修、人工复核三种去向。
  • 规则是否能解释,方便运营和开发共同调整。
  • 结构化字段是否稳定,前端和队列是否只依赖固定字段。
  • 自动返修是否限制次数,避免反复消耗。
  • 人工复核是否能看到原问题、原回答、质检问题和返修建议。

参考资料

总结

AI 输出上线前,最好先经过一条明确的质检流水线。规则检查负责发现硬性问题,结构化结果负责让程序稳定分支,低分内容进入自动返修或人工复核。这样既能减少人工重复检查,也能避免低质量内容直接进入线上流程。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>