企业官网建设流程全解析

实际机器学习项目里，最难的问题往往不是模型选型，而是“系统出错时由谁来兜底”。Human-in-the-Loop（人在环路，HITL）指的就是在模型自动处理的过程中，把人类判断嵌入一个或多个关键环节，让人工审核、修正、决策成为系统能力的一部分。ML and AI Ottawa 的分享中，Petar Djukic 用The Human Is the Loop这个标题点明了一个容易被忽略的事实：很多自动化系统的稳定边界，并不完全由模型决定，而是由“人在什么时机、以什么方式介入”决定。这篇文章会从概念、工作模式、最小实现、主动学习、大模型应用、生产落地和排错路径几个层面，把 HITL 在工程上如何设计讲清楚。

1. 先把“人在环路”这个概念讲清楚

1.1 人和模型的关系不是“谁替代谁”

很多人第一次听到 Human-in-the-Loop，会误以为这是“系统不够智能，所以需要人工补位”的过渡方案。这个理解有偏差。HITL 是一种有意为之的系统设计，目标不是让模型替代人，而是让模型和人各自做擅长的事：模型负责大规模、快速、低成本的初判，人负责处理模糊、高风险、需要经验和上下文判断的部分。

通俗地说，“环路”指的是一个完整的机器学习闭环：数据收集、标注、训练、部署、预测、反馈、再训练。如果这个闭环里至少有一个环节需要人类参与，并且人的结果会影响后续模型行为，那这个系统就是典型的 Human-in-the-Loop 系统。与之相对的是 Human-out-of-the-Loop，完全由模型自动决策，人类只在一段时间之后根据报表做复盘。

1.2 大模型时代，为什么反而更需要人工介入

大模型普及之后，工程上有一个明显变化：模型输出从“有限类别”变成了“开放式文本”，从“可枚举错误”变成了“看起来合理但可能完全错误”。这一变化放大了人工介入的价值。

第一个原因是幻觉。大模型生成的内容在语法上往往非常流畅，但没有事实依据时它也会一本正经地编造。对于内部知识库问答、法律文书摘要、医疗建议这类场景，如果输出不经过人工核验就直接对外，后果很难控制。

第二个原因是 Agent（智能体）开始真正操作系统。AI Agent 不再只是回复一段文字，它可以调用工具、发邮件、改配置、操作数据库。一次错误的工具调用可能比一次错误回复造成更严重的后果。此时在关键动作前加入人工确认，是最直接的安全护栏。

第三个原因是质量反馈链路变长。传统模型质量可以通过离线测试集评估，但生成式模型的质量高度依赖场景、上下文和目标用户。很多质量问题只有真实场景里的人类使用者才能发现，所以必须有机制把人的反馈接回系统。

注意：HITL 不是为了“证明模型不行”，而是为了在高风险场景里给系统一个可控的兜底。设计目标是“人介入得恰到好处”，而不是“人越少越好”或“人越多越安全”。

1.3 人类在环路中通常会承担五类角色

不同系统里，人介入的方式差别很大。以下五类角色覆盖了大多数 HITL 设计：

这五类角色可以出现在同一个系统里。比如一个客服工单分类系统，运营人员可能前期参与标注，中期参与审核，后期参与模型效果评估。设计 HITL 时，要明确“当前这个阶段，人承担的是哪类角色”，因为角色不同，交互界面、数据结构和反馈链路都不同。

2. 四种常见工作模式：从全自动到全人工

2.1 人在回路中：关键决策必须人工确认

“人在回路中”是字面意义上的 in-the-loop，系统不会贸然执行关键动作，而是生成建议后等待人工确认。典型场景包括：

• 金融风控：模型给出“疑似欺诈”，但真正的扣款冻结必须人工确认。
• 医疗辅助：影像筛查出可疑区域，医生复核后签署报告。
• AI Agent 执行高权限操作：删除数据、发送对外邮件、调用收费接口之前，需要人工点击批准。

这种模式的特点是安全优先、过程可审计，代价是延迟变高、吞吐量受限。适合处理“一次错误代价远高于一次人工审核成本”的场景。

2.2 人在回路上：机器先跑，人处理异常

“人在回路上”对应的是监控者模式。模型默认自动处理所有请求，人类不参与每一个样本，而是盯着指标看：错误率是否上升、置信度分布是否异常、有没有引起用户投诉。一旦发现异常，人可以暂停自动流程、回滚模型版本、切换规则。

这种模式适合“大多数情况自动处理正确，但需要保留干预能力”的场景。比如内容审核，常规内容机器直接处理，命中高风险的样本自动拦截，运营人员只处理机器无法判定或用户申诉的内容。

2.3 人在训练回路：用人工反馈持续改进模型

这是 HITL 最容易被忽略的一种模式。人工审核的结果不仅用于“放过或拦下”，还应该变成下一轮训练或微调的数据。传统监督学习里，人工标注数据自然就是训练集的一部分。在大模型时代，这种模式表现为：

• 人工对模型输出点赞、点踩、修改。
• 偏好数据用于训练奖励模型，支撑 RLHF（基于人类反馈的强化学习）。
• 修正后的数据进入指令微调或 DPO（直接偏好优化）流程。

只要反馈持续写回数据管线，系统就不会停留在“人帮模型擦屁股”，而是真正在“人帮助模型变好”。

2.4 四种模式对比与选择依据

为了便于选型，可以把常见模式整理成一张表：

选择依据就三条：出错代价、出错频率、人工成本。出错代价高且频率可接受，选“人在回路中”；出错代价中等但频率高，选“人在回路上”；系统需要长期进化，则必须加“训练回路”。实际系统往往不是单一模式，而是组合模式：默认走自动流程，低置信度走人工审核，审核结果写回训练集。

3. 最小案例：给自动分类系统加人工审核环节

3.1 场景与目标

用一个可运行的例子说明 HITL 的落地过程。场景是一个客服工单自动分类系统，模型把工单文本分成troubleshoot（故障处理）和after_sales（售后问题）两类。设计目标不是让模型单独干完所有活，而是让它判断“自己有没有把握”：有把握就自动处理，没有把握就进入人工审核队列。

这个例子很小，但它包含 HITL 的核心三要素：模型初判、置信度判断、人工兜底。

3.2 环境准备与依赖

本地验证只需要 Python 3.10 以上环境，以及 scikit-learn。安装命令：

pip install scikit-learn

如果希望持久化审核结果，还需要一个关系型数据库或至少一个 JSON 文件。这里先用内存结构演示，后面会给出对应的 SQLite 表结构。

3.3 实现：预测、置信度判断、审核队列

先用少量已标注数据训练一个朴素分类器，然后定义一个路由函数：当置信度低于阈值时，把样本标记为“需要人工审核”。

import numpy as np from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.pipeline import make_pipeline # 模拟少量已标注工单 train_texts = [ "登录失败", "密码错误", "无法连接服务器", "接口超时", "什么时候发货", "怎么申请退款", "发票怎么开", "想改收货地址" ] train_labels = [ "troubleshoot", "troubleshoot", "troubleshoot", "troubleshoot", "after_sales", "after_sales", "after_sales", "after_sales" ] model = make_pipeline(TfidfVectorizer(), LogisticRegression()) model.fit(train_texts, train_labels) def predict_and_route(text, threshold=0.7): probs = model.predict_proba([text])[0] label = model.classes_[int(np.argmax(probs))] confidence = float(np.max(probs)) need_review = confidence < threshold return { "text": text, "predicted_label": label, "confidence": round(confidence, 4), "route_to_human": need_review, "reason": "low_confidence" if need_review else "auto" } samples = [ "我想改收货地址", "服务器一直超时怎么办", "退款多久能到账", "验证码收不到" ] for s in samples: print(predict_and_route(s))

这段代码的关键点有两个：

1. predict_proba返回每个类别的概率，取最大概率作为置信度。置信度低说明模型在两个类别之间摇摆，此时自动分类很容易出错。
2. route_to_human是 HITL 的开关。实际系统里，这里不是打印一段结果，而是把任务写入人工审核队列。

人工审核环节需要一个任务结构。使用dataclass可以把预测结果和人工反馈放在一起：

from dataclasses import dataclass, field from datetime import datetime, timezone import uuid @dataclass class ReviewTask: task_id: str text: str predicted_label: str confidence: float status: str = "pending" # pending / approved / corrected human_label: str = "" reviewer: str = "" created_at: str = field( default_factory=lambda: datetime.now(timezone.utc).isoformat() ) reviewed_at: str = "" @classmethod def from_prediction(cls, pred: dict) -> "ReviewTask": return cls( task_id=uuid.uuid4().hex[:12], text=pred["text"], predicted_label=pred["predicted_label"], confidence=pred["confidence"], )

把这个结构存入 SQLite，审核记录才能真正留痕：

CREATE TABLE review_tasks ( task_id TEXT PRIMARY KEY, text TEXT NOT NULL, predicted_label TEXT NOT NULL, confidence REAL NOT NULL, status TEXT NOT NULL DEFAULT 'pending', human_label TEXT, reviewer TEXT, created_at TEXT, reviewed_at TEXT );

3.4 运行验证与预期输出

运行上面的脚本，预期输出类似：

{'text': '我想改收货地址', 'predicted_label': 'after_sales', 'confidence': 0.8221, 'route_to_human': False, 'reason': 'auto'} {'text': '服务器一直超时怎么办', 'predicted_label': 'troubleshoot', 'confidence': 0.9012, 'route_to_human': False, 'reason': 'auto'} {'text': '退款多久能到账', 'predicted_label': 'after_sales', 'confidence': 0.6234, 'route_to_human': True, 'reason': 'low_confidence'} {'text': '验证码收不到', 'predicted_label': 'troubleshoot', 'confidence': 0.5118, 'route_to_human': True, 'reason': 'low_confidence'}

验证时不能只看是否跑通，还要看三类结果：高置信度自动处理的样本是否正确、低置信度是否确实进入了人工队列、人工修改后的结论是否和模型初判一致。这三类结果分别对应系统正常、兜底生效、反馈有价值的判断依据。

提示：用这个案例验证时，样本量很小，分类效果没有参考意义，重点是把“路由到人”的逻辑跑通。真实项目里，阈值需要通过大量历史数据校准，不能直接在代码里拍脑袋写死。

4. 用主动学习减少人工标注量

4.1 主动学习解决什么

人工审核成本高，HITL 的另一个核心问题是“如何让每一次人工介入都值回票价”。主动学习（Active Learning）就是为此设计的：模型从大量未标注数据中挑选“对模型提升最有价值”的样本，再交给人工标注，而不是随机抽样让人盲目标。

这个思路在客服工单、OCR 识别、异常检测、医疗影像等领域都很常用。人工还是那些人，但标注对象变了，标注效率会明显不同。

4.2 用不确定性采样挑选样本

最简单也最常用的采样策略是不确定性采样：模型对样本的预测越不确定，越值得让人工标注。在分类任务里，可以用预测概率的熵来衡量不确定性。

def entropy_of_predictions(probs): # probs: shape (n_samples, n_classes) return -np.sum(probs * np.log(probs + 1e-12), axis=1) def select_samples_for_human(pool_features, model, k=10): probs = model.predict_proba(pool_features) scores = entropy_of_predictions(probs) top_k = np.argsort(scores)[::-1][:k] return top_k, scores[top_k]

一轮主动学习的流程如下：

# 初始只有少量标注数据 labeled_X, labeled_y = load_initial_labeled_data() pool_X = load_unlabeled_pool() for round_idx in range(5): model.fit(labeled_X, labeled_y) # 从无标池里挑出最不确定的 20 条 selected_idx, scores = select_samples_for_human(pool_X, model, k=20) # 交给人工标注，返回新标注数据 new_X = pool_X[selected_idx] new_y = human_label(new_X) # 实际项目中是标注平台或审核队列 # 移出无标池，加入训练集 labeled_X = np.concatenate([labeled_X, new_X]) labeled_y = np.concatenate([labeled_y, new_y]) pool_X = np.delete(pool_X, selected_idx, axis=0)

这段代码说明了一个关键机制：每一轮人工标注都服务于模型下一次迭代，人工没有在“重复劳动”，而是在“补模型的知识盲区”。

4.3 采样策略对比

不确定性采样不是唯一的策略。工程上需要根据任务特点选择：

实际项目中常用组合策略：先用不确定性采样快速提升模型，再用多样性采样补覆盖。无论选哪种，都要做到“人工标注结果回流到训练集”，否则主动学习就退化成单纯的人工审核。

5. 大模型应用与 AI Agent 中的人类反馈设计

5.1 从 RLHF 到 DPO：人类反馈参与训练

大模型领域最典型的“人在训练回路”是 RLHF。其基本流程是：

1. 人类对模型多个输出进行排序或打分。
2. 用偏好数据训练一个奖励模型（reward model）。
3. 通过强化学习，让主模型输出更符合人类偏好的结果。

DPO（直接偏好优化）则跳过了训练奖励模型的步骤，直接利用偏好数据微调模型。它降低了训练复杂度，但同样需要高质量的人类偏好数据。

对工程团队来说，关键不是纠结 RLHF 和 DPO 谁更强，而是建立稳定的偏好数据收集机制：在应用里加“这个回答有帮助吗”按钮、人工修改最佳回答、记录编辑前后的 diff。这些看似简单的交互，就是训练人类偏好数据的来源。

5.2 生成结果的评估与抽检

生成式模型的离线评估很难穷尽所有场景，所以生产环境需要“自动评估 + 人工抽检”的组合。常见的做法是：

• 用规则或轻量模型做客观检查：是否包含违禁词、是否包含敏感信息、是否满足长度要求。
• 用“LLM-as-a-judge”让大模型给输出打分，适合做批量粗筛。
• 对高风险问题、低分结果、用户投诉样本，强制进入人工复核。

这里要注意一个坑：不能因为“大模型评分方便”就把所有评估交给大模型。自动评估可能有系统性偏好，比如总给长文本打高分。对重要输出，人工抽检比例不能为零。

抽检数据可以设计成如下结构：

{ "request_id": "req_12345", "prompt": "客户说账号被锁定，应该怎么回复？", "model_output": "您好，请提供您的账号信息，我们会协助处理。", "auto_check": { "contains_forbidden_words": false, "length_ok": true }, "llm_judge_score": 0.85, "human_review": { "status": "pending", "rating": null, "is_correct": null, "comment": "" } }

这个 JSON 把机器数据和人工反馈放在一起，下游可以很方便地把human_review字段抽出来，形成新的评估集或微调数据。

5.3 让反馈可追溯：请求、版本、操作人

大模型输出具有不确定性，同一个 prompt 在不同版本、不同温度下结果可能不同。如果人工反馈没有记录模型版本和请求上下文，后续分析“这个错误是谁引入的”会非常困难。

因此生产环境的反馈数据至少要包含四类信息：

1. 请求信息：prompt、上下文、用户输入。
2. 模型信息：模型名称、版本、参数（temperature、top_p）。
3. 输出信息：模型输出、置信度或辅助评分。
4. 人工信息：操作人、操作时间、审核结果、备注。

把这些信息落库后，每次模型升级都可以对照历史人工反馈做回归分析，判断新版本是否解决了旧问题，以及是否引入了新问题。这也是模型部署环节里很容易被忽略的一环：只比较准确率，不比较错误样本的变化。

6. 生产落地：审核队列、阈值与日志

6.1 审核队列的延迟与并发

从“需要人工审核”到“人工审核完成”之间，系统必须容忍延迟。审核队列要实现至少三个能力：

• 优先级：高风险工单优先排队，普通工单可以排队等。
• 超时处理：超过 SLA 仍未审核的工单，需要升级或回退到默认策略。
• 并发控制：多个人同时审核时，避免重复领取任务。

初期可以用数据库表加状态字段实现队列，任务数上来后再引入 Redis 或专业的任务队列。不要一上来就设计复杂的队列架构，重点是先保证“任务不会丢、状态能追踪、超时有人管”。

6.2 置信度阈值该怎么定

最小案例里的threshold是硬编码的，这只能用于演示。生产环境里确定阈值的过程是：

1. 收集历史预测结果和对应的人工审核结论。
2. 按置信度分桶统计每桶的准确率和人工审核率。
3. 用业务指标评估：如果误判一个轻则成本 10 元，重则造成客户流失，人工审核一次成本 2 元，那阈值要选在“自动放行错误成本”和“人工审核成本”交叉的位置。
4. 上线后持续监控，每隔一段时间重新校准。

阈值不是越高越好。阈值过高，所有样本都进人工，模型失去自动化意义；阈值过低，错误率上升，HITL 形同虚设。推荐做法是设置“自动放行阈值”和“强制人工阈值”两档：高于高阈值直接自动处理，低于低阈值直接拒绝或转人工，中间部分可以结合其他规则判断。

6.3 数据漂移时动态调整人工介入率

生产环境的数据分布会变。新产品上线、季节变化、用户结构变化，都会导致模型置信度不再可信。如果只盯着固定阈值，系统可能静默失效。

建议监控两个指标：

• 平均置信度：如果持续下降，说明输入分布和训练分布已经偏离。
• 人工审核通过率：如果人工大量修改模型结论，说明模型输出质量在下降。

当人工审核通过率明显低于历史基线时，应该触发告警，并临时提高人工介入比例。等模型重新训练发布后，再逐步回落到正常水平。这个“动态调整人工介入率”的能力，是生产级 HITL 和演示代码的重要区别。

6.4 审计与合规

凡是涉及人工审核的系统，都需要回答三个问题：谁审的、什么时候审的、改了什么。满足这个要求，需要做到：

• 审核任务不可删除，只能取消或关闭。
• 审核日志追加写入，不覆盖，不物理删除。
• 记录模型版本，方便回溯是模型问题还是人工误判。
• 对高危操作保留二次确认机制。

在医疗、金融、政务等场景，审计能力可能直接决定系统能否上线。

7. 常见坑和排查路径

7.1 四个高频问题

HITL 系统运行一段时间后，最常见的问题集中在四类。

第一个坑：人工审核结果没有回流。系统把人审当作“临时兜底”，审核完就丢，没有把修正数据写回训练集或微调流程。现象是模型长期不进步，同样的错误反复出现。解决方式是把人工审核表变成训练数据管道的一部分，每次审核完成都向后端数据仓库写一条结构化记录。

第二个坑：置信度分布不可信。模型对未知样本可能给出高置信度的错误预测，尤其在数据漂移之后。解决方式是持续统计“置信度分桶准确率”，建立置信度校准过程，不要把概率值直接当作真实可靠度。

第三个坑：标注口径不一致。两个审核员对同一类问题给出不同结论，导致反馈数据互相打架。解决方式是编写标注指南，定期做一致性测试，对分歧样本组织评审会。如果标注者之间的一致率长期低于 80%，先别急着重训模型，要先梳理标准。

第四个坑：人工介入变成了全量审核。系统上线后出于安全考虑，把所有请求都进人工队列，结果人力成本超预算，审核效率下降，排队任务越积越多。解决方式是重新按风险分层，把少量高风险请求走人工，常规请求走自动规则，同时监控兜底。

7.2 排查链路

遇到 HITL 相关异常，推荐按以下顺序排查：

尤其要注意第 2 步。很多 HITL 系统出问题，根源不在模型，而在路由规则：要么阈值不合适，要么新业务类别没有路由到人工。排查时先确认“该人工的有没有人工”，再讨论“人工审得对不对”。

8. HITL 设计检查清单与扩展方向

8.1 可复用的设计检查清单

在项目里引入 HITL 前，先对照下面这份清单逐项确认：

• 是否定义了“什么情况必须人工”，而不是只定义了“什么情况自动”。
• 是否用历史数据校准了置信度阈值，而不是硬编码。
• 人工审核结果是否有结构化存储，并包含操作人、时间、模型版本。
• 人工反馈是否回流到训练或微调数据管道。
• 是否监控了平均置信度和人工审核通过率。
• 是否有审核队列积压告警和 SLA 超时处理。
• 是否区分了高风险和低风险请求，避免全量人工审核。
• 是否对审核人员做了标注口径一致性培训。
• 是否保留了模型回滚路径，人工审核发现问题后能及时切换版本。
• 是否在日志和审计层面记录了“系统建议”和“最终决定”的区别。

这份清单既适用于新系统设计，也适用于已有系统自查。任何一个选项是不确定，都说明 HITL 链路里存在盲区。

8.2 扩展方向：从单点人工审核到 Agent 协作

HITL 的下一步不是“减少人工”，而是把人工从重复操作里释放出来，去做更高价值的判断。可以考虑几个扩展方向：

• 把人工审核和高风险 Agent 动作绑定：Agent 只能执行“计划类”动作，真正落地前走人工确认，形成 Agent 系统的安全审批层。
• 把规则引擎和 HITL 结合：简单业务走规则，复杂业务走模型，模型没有把握时自动升级到人工。
• 把人工反馈用于持续评估：每个季度从历史反馈里抽样构建评估集，替代一次性的人工抽检。
• 建立多级人工策略：不同项目、不同用户、不同金额对应不同审核深度。

对刚接触这个主题的开发者，最有价值的练习不是追求复杂框架，而是先把一个最小任务的“预测-路由-审核-反馈”链路完整跑通，理解每个环节的数据流转。等这条链路稳定后，再逐步引入主动学习、动态阈值和模型自动迭代。这样构建的 HITL 系统，才是真正可以在生产环境里长期运行的工程系统，而不是停留在概念层面的原型代码。