这次我们来看一个 ML and AI Ottawa 社区的技术分享录像，主题是 "The Human Is the Loop"，分享者是 Petar Djukic。这个标题值得先拆解一下：它不是在讲“人机共荣”这类口号，而是在讲一个非常具体的工程问题——机器学习系统里，人到底应该出现在哪些环节，以及这些环节之间应该如何连接。
先说结论。很多 AI 应用和本地模型真正跑起来之后，瓶颈往往不是推理速度，而是“没人兜底”。模型输出的结果需要被检查、被修正、被确认之后才能进入业务；如果这条人工回路没有设计好，自动化流程就会变成不可控流程。Human-in-the-Loop（以下简称 HITL）的核心思想，就是把“人对模型结果的判断”当成系统的一等公民，而不是事后复盘时的备注。
这个主题对 CSDN 读者的最大价值在于：它不绑定某个具体框架，也不依赖某个新出的模型，而是给出一套可以套用到图像分类、文本审核、RAG 问答、智能体工具调用、OCR 复核等多个场景的工程方法。这篇文章会从概念拆解讲起，给出一个最小可落地的 HITL 闭环设计，包含置信度路由、人工审核队列、反馈数据回流三段核心逻辑，并提供代码骨架、接口调用示例、批量任务思路和常见排查清单。
1. 核心概念速览
先把这次分享里最能落地的一组概念整理出来。这个主题围绕的核心问题只有一个：什么时候让机器自动做，什么时候必须让人来做。
| 概念 | 说明 |
|---|---|
| Human-in-the-Loop | 把人工判断嵌入模型推理流程，让低置信度、高风险结果进入人工审核 |
| 置信度路由 | 模型输出置信度高走自动处理，置信度低走人工审核 |
| 反馈回流 | 人工修正后的结果作为新样本进入数据集，用于下一轮训练或评测 |
| 主动学习 | 优先挑模型最不确定的样本让人标注，用最少人力提升模型效果 |
| RLHF | 用人工偏好排序优化生成模型，是 HITL 在生成式模型上的典型形式 |
| Agent 审批闸门 | 智能体在执行关键动作前，先输出待确认操作，人批准后才执行 |
| 审计闭环 | 每一次人工判断都留痕，可回溯、可统计、可复盘 |
这几个概念对应的不是理论目录，而是系统设计时的取舍。置信度路由解决的是“自动化的量”：阈值设高了，人工任务堆积；阈值设低了，错误结果漏出去。反馈回流解决的是“自动化的质”：没有回流，人工审核就只是安检，模型永远不知道自己错在哪里。Agent 审批闸门解决的是“自动化的边界”：工具调用、代码执行、外部接口写入这类高风险动作，必须给人类一个确认入口。
从分享主题传递的观点来看，HITL 的重点并不是“尽量去掉人”，而是“在正确的时机把正确的人带进来”。这个判断和目前工程界的普遍做法一致，也符合合规审计对 AI 应用越来越高的要求。实践层面，任何一个自动化系统上线前都值得先问一句：如果这条流水线出错了，谁负责发现，谁负责修正，修正结果会不会回到系统里。
2. HITL 的四个典型落地场景
HITL 并不是一个单一功能，而是分布在机器学习系统不同阶段的一组模式。下面按场景拆开，每个场景都对应不同的技术选型和不同的数据流设计。
2.1 数据标注阶段的主动学习
最传统的 HITL 是数据标注，但更值得做的是主动学习版本：先用少量标注数据训练一个初始模型，然后用模型对未标注样本打分，按不确定性排序，把“模型最拿不准”的样本优先送给人标注。这样同样的标注预算，对模型效果的提升会更明显。
批次标注时，常见设计是按置信度把样本分成三档：高置信度且类别稳定的样本自动进入训练集；中置信度样本按比例抽检送标注；低置信度样本全部送人工标注。这套分流逻辑和后面讲的置信度路由完全一致，只是应用阶段从“训练前”移到了“推理中”。主动学习的核心收益是可以量化统计的，比如相同的错误率目标下需要标注多少样本、模型迭代几轮后不确定度下降多少。
2.2 生成式模型的 RLHF 与偏好标注
生成式模型里的 HITL 以 RLHF（基于人类反馈的强化学习）最为典型。人工对模型生成的多个候选结果做排序或打分，这些偏好数据被用来训练奖励模型，再通过强化学习微调策略模型。这个流程在内容生成、客服话术、代码补全等场景里都在使用，也是目前大模型对齐环节里最依赖人工的部分。
这是成本最高的 HITL 模式，因为它需要大量高质量人工偏好数据，而且标注标准很难统一。工程上最重要的是把标注指南写清楚，明确“什么样的回答算有帮助”“什么样算有害”，并定期做标注一致性检查。不同审核员之间的偏差如果过大，奖励模型学到的偏好就是混乱的，后续微调效果自然不稳定。
2.3 智能体的审批闸门
AI Agent 在调用工具、写文件、发消息、执行支付之类的高风险操作前，先输出“计划要执行的步骤”，等到人工确认后再真正执行。这套设计在业界通常叫 Human-in-the-Loop for agents，本质是把人工审批作为一个可编程的中间节点插进 Agent 的执行链路。
这种模式的关键参数有两个：哪些动作必须审批、哪些动作可以自动执行。务实的做法是维护一个动作白名单，白名单内的自动放行，白名单外的全部转人工。审批结果本身可以记录为 Agent 行为数据，用于后续策略调优。需要特别强调一点：审批闸门不能只做“确认按钮”，要把 Agent 打算执行的完整动作、涉及的目标资源、可能的后果都展示清楚，否则人工确认只是走过场。
2.4 线上推理结果的持续复核
模型上线后，HITL 并不会结束。对线上推理结果进行抽检和修正，是很多团队容易漏掉的一环。常见做法是把模型输出的置信度、业务反馈、用户纠错行为统一收集起来，周期性统计“模型错在哪一类样本上”，再决定是补充数据、调整提示词还是重新微调。
这个场景和前面三者不同之处在于：它不是一条独立的流程，而是要和监控系统、日志系统、数据仓库打通，属于典型的 MLOps 范畴。如果只做模型训练前的标注闭环，不做上线后的持续复核闭环，那模型在真实环境里的退化问题就很难被发现，往往要等到用户投诉才反应过来。
3. 从概念到工程：一个最小 HITL 闭环
把上面几个场景落到代码层面之前，先明确一个最小闭环的构成。这个闭环包含四段逻辑，缺一环都不完整。
- 模型推理：对输入样本给出预测结果和置信度。
- 路由判断：根据置信度、业务风险等级、动作类型决定是自动处理还是转人工。
- 人工审核：审核员看到待审队列，修改或确认结果，并填写修正原因。
- 反馈回流：人工修正结果进入数据库，成为下一轮训练、评测或规则调整的数据。
这个闭环设计和具体用什么模型无关，和用不用 GPU 也无关。哪怕你只用一个启发式规则加一个关系型数据库，也能把 HITL 跑起来。先有闭环，再上模型，是更稳妥的落地顺序。很多项目的问题是反过来的：模型选了最先进的，推理服务也搭起来了，但审核界面只有一个共享 Excel，反馈数据靠人工整理，最后闭环断在流程线上。
4. 环境准备与基础架构
这一节给出一套通用环境检查清单。因为不同项目的模型栈差异很大，这里不锁死版本，只列出需要确认的核心项。
- 语言运行时：Python 3.10+ 比较稳妥；如果项目基于 Node.js 或 Java，按项目自身要求准备。
- Web 服务框架：FastAPI、Flask、Spring Boot 都可以，本文示例用 FastAPI。
- 队列与存储：Redis 或关系型数据库都可以承担审核队列；小规模原型直接用 SQLite。
- 模型推理：本地部署需要确认 PyTorch、ONNX Runtime 或 TensorRT 等运行时；调用云 API 则确认鉴权方式和配额。
- 审核端：Web 后台、企业微信或钉钉表单、邮件确认链接都可以作为人工审核入口。
- 数据版本：训练数据和人工反馈数据建议放在支持版本管理的存储中，比如 DVC、Git LFS，或者对象存储加版本号。
如果本机只是做原型验证，最简配置就是一台 CPU 机器加一个 SQLite 数据库。HITL 的关键不在推理性能，而在数据流正确性。先跑通一条“推理 -> 路由 -> 审核 -> 回流”的最小链路，再考虑扩展成分布式队列、多审核组、多模型版本，这个顺序可以让排查问题的成本低很多。
5. 最小实现：置信度路由与人工审核队列
下面用 FastAPI 写一个最简版本，包含三段逻辑：接收推理结果、按置信度路由、提供人工审核接口。代码只做骨架演示，真实项目需要在数据库连接、鉴权、日志、异常处理上补全。
5.1 数据表设计
先定义两张表：一张是推理结果表，一张是人工审核记录表。
CREATE TABLE inference_records ( id TEXT PRIMARY KEY, input_text TEXT NOT NULL, model_prediction TEXT NOT NULL, confidence REAL NOT NULL, status TEXT NOT NULL DEFAULT 'auto_approved', routing_rule TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE human_review_records ( id TEXT PRIMARY KEY, inference_id TEXT NOT NULL, reviewer TEXT NOT NULL, original_prediction TEXT, final_decision TEXT NOT NULL, correction_reason TEXT, review_status TEXT DEFAULT 'pending_confirm', reviewed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (inference_id) REFERENCES inference_records(id) );status 字段是这个闭环的核心状态机，建议至少包含四个值：auto_approved 表示自动通过，pending_review 表示待人工审核，reviewed 表示已人工审核，corrected 表示人工修正过。review_status 字段用于标记反馈数据是否已被抽样确认，后续训练回流时只取 confirmed 的数据，避免把审核员的误操作学进模型。
5.2 置信度路由逻辑
路由函数放在推理服务和审核队列之间。示例按置信度、风险等级和动作类型三个维度判断。
def route_decision(confidence: float, risk_level: str, action_type: str) -> str: if action_type in {"write_file", "send_message", "execute_code", "payment"}: return "pending_review" if risk_level == "high": return "pending_review" if confidence >= 0.95: return "auto_approved" if confidence >= 0.80: return "sampling_review" return "pending_review"这个函数只是骨架，真实项目需要把阈值放到配置中心，并且用线上数据持续校准。阈值不是拍脑袋定的，而是看“漏过率”和“人工工作量”的平衡。以文本审核场景为例，如果置信度 0.9 以上的样本实际错误率仍然有 5%，那阈值就应该往上调；如果置信度 0.8 到 0.9 之间的样本基本全对，那就没必要浪费人力去审。
5.3 审核队列 API
审核端暴露三个接口：查询待审任务、提交审核结果、回调下游业务。
from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI() class ReviewRequest(BaseModel): inference_id: str reviewer: str final_decision: str correction_reason: str = "" @app.get("/api/review/queue") def get_review_queue(status: str = "pending_review", limit: int = 20): # 实际项目从数据库查询待审记录，按优先级和时间排序 return {"items": [], "total": 0} @app.post("/api/review/submit") def submit_review(req: ReviewRequest): # 1. 写入 human_review_records # 2. 更新 inference_records.status # 3. 触发回调，通知下游业务使用修正后的结果 return {"status": "ok", "inference_id": req.inference_id}人工审核提交后必须做两件事：更新状态、触发回调。如果只更新状态不触发回调，下游系统拿到的还是旧结果，闭环就是断的。回调要做到幂等，同一个 inference_id 被重复回调时不能产生重复副作用，否则审核员双击提交或者网络重试时就会出现双写。
6. 反馈回流与模型再训练
人工审核记录如果只是躺在数据库里，HITL 就没有闭环。要让修正数据发挥作用，至少要打通两条路：一条进入训练集，一条进入评测集。
反馈数据回流前要做清洗。审核员可能只改了标签但没写原因，可能在犹豫之后提交了错误修正，可能把本来正确的模型结果改错。所以反馈数据不能直接进训练集，先做一轮抽样复核，确认修正质量后再入库。这就是 human_review_records 里 review_status 字段的作用——标记该条修正是否已被抽样确认。
回流后的训练触发策略一般有三种：固定周期训练，每周或每月用累计反馈数据重新微调；错误率触发，统计修正率连续上升时启动增量训练；版本发布触发，每次模型版本升级前把反馈数据纳入训练集。对大多数中小团队来说，固定周期训练加版本发布触发的组合最稳定，错误率触发容易出现窗口抖动导致的频繁训练。
评测集也要同步更新。拿修正数据构造一个 hard case 集合，每次模型升级都用这组数据做回归测试，可以有效避免“新模型修好 A 类错误、引入 B 类错误”的情况。很多团队的评测集长期不更新，反馈数据只用于训练不用于评测，导致模型越训越偏。
# 修正数据导出示例：只导出已被确认的修正样本 def export_reviewed_samples(conn, batch_size=500): cursor = conn.execute( "SELECT input_text, final_decision FROM human_review_records " "WHERE review_status = 'confirmed' ORDER BY reviewed_at DESC LIMIT ?", (batch_size,) ) return [{"input": row[0], "label": row[1]} for row in cursor.fetchall()]7. 批量任务与审核工作流设计
当待审样本量大时，不能把所有任务一股脑丢给审核员，需要一套批量任务和工作流的分发机制。
7.1 批量任务生命周期
批量审核任务建议用独立的任务表或消息队列管理，生命周期分为 created、assigned、in_progress、done、expired。任务在 assigned 状态停留超过设定时限时，应该自动重新分配，避免个别审核员占用大批任务后离线，造成队列假死。
# 批量任务分发示例（伪代码） def dispatch_batch(batch_id, review_items, reviewer_group): for item in review_items: if get_workload(reviewer_group) < max_workload: assign(item, reviewer_group) else: enqueue_retry(item)批量任务的要点是控制单人工时长度。审核是很耗注意力的工作，连续审核超过一定时长，准确率会明显下降。工程上可以做两件事：限制单次领取数量，以及在同一批任务里混入已知标准答案做质量测试。质量测试样本的审核结果可以自动算出每个审核员的准确率，准确率低于阈值的审核员需要重新校准或检查其历史审核记录。
7.2 与自动化流程的接口约定
自动化系统调用人工审核队列时，建议定义统一的回调接口。模型服务在路由为 pending_review 后，把任务写入队列并返回一个 ticket_id，业务侧轮询或等待回调。
# 调用审核队列的 Python 示例 import requests pending_payload = { "input_text": "请把服务部署到生产环境", "model_prediction": "execute: deploy_to_prod", "confidence": 0.78, "risk_level": "high" } resp = requests.post( "http://127.0.0.1:8000/api/review/queue", json=pending_payload, timeout=10 ) ticket_id = resp.json()["ticket_id"]接口设计上，建议把“提交审核任务”和“查询审核结果”分成两个接口，而不是让调用方长连接等待。人工处理的不确定性很大，一次审核可能几秒钟也可能几小时，同步等待会浪费大量连接资源。用 ticket_id 轮询或者 webhook 回调，是更符合人工流程节奏的做法。
8. 资源占用与性能观察
HITL 系统的性能指标和普通推理服务不同。推理服务看吞吐和延迟，HITL 系统还要看队列深度、人工处理时长、漏过率和修正率。
建议重点观察五个指标：
- 人工处理时长（review latency）：从任务进入队列到审核完成的时间。
- 队列深度（queue depth）：待审核任务的堆积量。
- 自动通过率（auto-approval rate）：置信度路由后直接放行的比例。
- 人工修正率（correction rate）：审核员修改模型结果的占比。
- 漏过率（missed error rate）：抽样复核发现的、之前被错误放行的比例。
如果自动通过率长期偏低，说明阈值设得太严或者模型能力不足，应该先去优化模型而不是增加审核人力。如果修正率很低，说明审核任务大量是重复劳动，可以考虑用规则或聚类先滤掉一部分，让人把精力集中在真正有难度的样本上。本地部署推理服务时，显存、内存占用要结合具体模型版本和推理参数来观察，batch size 越大、输入长度越长，占用就越高，批处理参数需要以实际运行环境为准来调整。
HITL 场景里，模型推理性能和人工审核速度之间的匹配比单点性能更重要。模型一秒钟处理一百条，人工一天只能处理一千条，那队列就会持续积压。这种情况下与其优化推理延迟，不如优先优化路由策略，把自动通过率提上去。
9. 常见问题与排查方法
HITL 系统的常见问题往往不在模型，而在流程和数据处理上。下面整理了一份排查清单。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 待审队列一直堆积 | 人工处理速度跟不上模型产出 | 看队列深度和审核员处理时长 | 提高阈值增加自动通过率，或增加审核人力 |
| 自动通过率高但错误率也高 | 置信度校准不好 | 统计各置信度区间内的实际错误率 | 重新做置信度校准，调整阈值 |
| 审核员提交后下游结果没变 | 回调未触发或幂等处理缺失 | 查看回调日志和接口访问记录 | 增加消息队列和重试机制 |
| 反馈数据训练后模型变差 | 修正数据本身有噪声 | 抽样复核修正质量 | 增加 review_status 确认机制 |
| 批量任务中途卡住 | 审核任务超时未处理 | 检查 assigned 状态是否过期 | 增加过期重分配逻辑 |
| 依赖安装失败 | 包版本冲突或缺少运行时 | 查看 pip/conda 报错日志 | 使用虚拟环境并固定版本 |
| 审核标准不一致 | 缺少标注指南或审核员间差异大 | 周期性做一致性评测 | 补充标准文档并先做校准 |
| 模型推理显存不足 | 批处理数或上下文过长 | 观察推理日志和资源监控 | 降低 batch size 或换更小模型 |
| 审核记录丢失 | 数据库事务未提交或写入失败 | 检查写入日志和事务逻辑 | 使用事务并增加异常告警 |
排查时先从数据流角度走一遍：样本从哪里进来，路由规则是否命中，队列是否写入，审核结果是否更新，回调是否执行，回流数据是否被消费。只要这六步里任何一步断了，整个闭环就会失效。建议在每一步都打结构化日志，字段至少包含样本 ID、时间戳、操作人、状态变化，这让问题定位成本大幅下降。
10. 最佳实践与合规边界
HITL 系统的工程质量，很大程度上取决于流程纪律，而不是模型选型。下面几条是实践中反复出现的经验。
第一，把人工审核当成产品功能来设计，而不是临时工具。审核界面要展示模型的原始输出、置信度、相似案例，方便审核员快速判断。没有上下文、只有孤立标签的审核界面会让错误率明显上升。审核操作要尽量简单，一键确认、一键修改、填写原因，减少不必要的操作路径。
第二，反馈数据必须留审计痕迹。谁审的、什么时候审的、原始预测是什么、改成什么、为什么改，这些信息全部要记录。这既是质量追溯的基础，也是合规审计的基础。人工反馈数据是模型训练的重要资产，但如果无法追溯来源和标准，这份资产的质量就无法保证。
第三，涉及人脸、声音、个人隐私和版权素材时，必须确认授权后再进入人工审核流程。人工审核会接触真实用户数据，这个环节的泄露风险比模型权重泄露更高。需要做数据脱敏、最小权限访问和访问日志记录。原始数据可以脱敏后送入审核队列，敏感字段单独存储并加密，审核员只能看到完成任务所必需的信息。
第四，警惕自动化盲目扩大。在做 Agent 审批闸门时，一个动作能否从白名单放行，要看它失败后的影响范围。影响可控的可以放行，影响不可控的必须保留人工确认。白名单不是一成不变的，每次放行一个动作前，要评估它被恶意利用或者误触发的可能性，并且记录详细的审批理由。
第五，定期做审核质量评估。用已知标准答案的测试样本混入审核队列，统计审核员的识别准确率。这既考核流程质量，也能发现审核指南中的歧义。审核准确率下降时，先检查是不是指南改了、样本难度变了、还是审核员疲劳了，定位准确后再针对性调整。
11. 总结与下一步
"The Human Is the Loop" 这场分享最值得记住的一点是：人不是 AI 流程的外挂，而是闭环的必要组成部分。对于准备落地 AI 应用或 Agent 系统的团队，可以先从最小闭环做起——实现推理、路由、审核、回流四段逻辑，用真实业务数据跑两周，再决定要不要优化模型。
建议第一次试验时优先验证三个问题：置信度路由的阈值是否合理、人工审核队列是否稳定、反馈数据能不能回流到训练或评测。最容易踩的坑是把精力全放在模型调优上，审核队列和反馈回流却只做了个半成品。一个能稳定记录人工修正并定期回流训练集的简单系统，比一个推理效果更好但没有反馈闭环的系统更有长期价值。
后续可以扩展的方向包括：把主动学习策略接入标注流程、把 HITL 审核记录接入模型可观测性平台、在 Agent 系统中完善审批闸门，以及在多团队协作时建立统一的审核标准。先把人工这条路走通，自动化才有意义。
