在 LLM 应用和 AI Agent 大规模进入生产环境之后一个老概念正在被重新审视Human-in-the-Loop人在回路。ML and AI Ottawa 社区的 Petar Djukic 以 “The Human Is the Loop” 为题做过一次分享这个标题精准点出了当前工程实践的一个核心转向——不是让人被自动化取代而是在自动化系统中重新定位人的价值。如果只看表面很容易误以为“人在回路”只是把 AI 输出交给人工审核一遍再加个确认按钮。但真正落地时会发现它涉及采样策略、置信度阈值、反馈回写、权限审计、模型迭代等一整套工程链路。这篇文章会从概念边界、架构设计、代码实现到生产实践把 HITL 讲透并提供一套可直接运行的最小闭环示例帮助你理解为什么 AI 越强大“人”这个环节反而越不能省。1. 这篇文章真正要解决的问题1.1 一个正在被放大的工程矛盾过去几年机器学习团队追求的核心指标是“自动化程度越高越好”。模型能自动分类的就不要人工打标Agent 能自动执行的就不要每步确认。这种思路在规则明确的场景里没有问题但到了开放域生成、金融风控、医疗辅助、法律文书这类高风险场景完全自动化带来的错误会被成倍放大。我在实际项目中见过一个典型案例某个团队部署了一个客服意图识别模型离线准确率 0.93上线后把误判的对话直接推送给了人工客服结果客户投诉率反而上升。原因不是模型准确率不够而是系统缺少一个关键设计——在模型低置信度时将样本交给人来决策。如果准确率 0.93 的模型在 1000 条里出现 70 条错误而这些错误没有拦截机制那“自动化”就是在系统性地制造问题。这就是 HITL 要解决的核心矛盾如何在自动化效率和风险控制之间找到平衡而不是非此即彼。1.2 谁最应该读这篇文章如果你属于以下任意一类人这篇文章都值得读完正在做 RAG、Agent、智能客服、内容审核等 LLM 应用的开发者机器学习平台或数据团队的工程师需要设计标注与反馈闭环技术负责人或 AI 产品经理需要理解“人在回路”系统的成本和收益正准备把模型从离线实验推向生产环境但担心错误率失控的团队。1.3 本文会讲清楚什么围绕 Petar Djukic 的分享主题结合 AI 工程实践我会重点展开五件事HITL 和 Human-on-the-Loop 的本质区别为什么大模型和 Agent 时代HITL 的价值不降反升HITL 最小闭环的四个关键模块采样、审核、反馈、重训一套基于 Python FastAPI SQLite 的可运行示例生产环境部署 HITL 时最常见的坑和最佳实践。2. 人在回路概念演进与边界2.1 为什么“人在回路”不是旧话重提看这个视频标题有人可能会觉得这不就是上世纪 80 年代专家系统时代的“人机交互”吗内容没错但语境完全不同。传统机器学习中的 HITL最典型的是主动学习Active Learning。训练集只有少量有标签数据模型先从无标签数据里挑出最不确定的样本交给标注员打标再把新标签加入训练集重新训练。这个循环的价值在于降低标注成本模型越挑越准人工参与量越来越少。到了大模型时代HITL 的含义扩展了。它不只是“找人标注数据”而是覆盖了数据标注、模型对齐如 RLHF、Agent 任务规划审核、模型输出纠偏、法律合规审查等多个层级。Petar Djukic 的演讲标题强调的是更深一层人不是循环之外的一个审核按钮而是循环内部的关键决策节点。在 AI Agent 可以自主调用工具、操作数据库、发送邮件的情况下如果人不在循环里系统的鲁棒性、安全性和可解释性都会迅速崩塌。2.2 Human-in-the-Loop 与 Human-on-the-Loop这两个词常被混用但在工程上是两种截然不同的设计。维度Human-in-the-Loop人在回路Human-on-the-Loop人在回路上人的位置系统处理流程的必经环节系统之外的监督者决策时机每个关键样本或关键动作执行前异常发生时介入介入粒度单条数据 / 单个动作系统级 / 流程级典型场景低置信度样本人工审核监控告警、人对 Agent 的阶段性审批自动化程度中低高风险控制能力强中简单类比HITL 像是航班起飞前的安全员每一班次都要检查确认Human-on-the-Loop 像是塔台调度平时不干预遇到异常才喊停。实际生产系统里两者往往配合使用低置信度样本走 HITL高置信度样本走自动处理系统级异常再交给 Human-on-the-Loop 处理。2.3 HITL 在机器学习中的三个典型作用层从纵向看HITL 可以在三个层面发生作用第一层是数据层。模型训练前人工标注为模型提供基础标签模型训练后人工审核为模型提供纠正信号。这一层直接决定了模型能力的上限。第二层是推理层。模型在预测或生成时系统根据置信度、敏感词、业务规则等判断是否有人工介入。这一层决定的是在线系统的输出质量。第三层是规划层。这是 Agent 时代新增的。Agent 在执行多步任务时每一步都可能调用外部工具或修改真实数据人在关键动作前进行审批防止自动化扩大错误。我见过不少项目在数据层做了充分标注在推理层却完全没有人工介入机制。结果是模型离线分数很高上线后出现大量“正确但不符合业务要求”的输出。这三个层面至少要设计一个否则称不上完整的 HITL 系统。3. 大模型与 Agent 让 HITL 的门槛和收益同时变高3.1 Agent 是放大不是傻瓜化AI Agent 的核心能力是自主规划给定一个目标模型自己拆解成子任务、选择工具、执行动作、观察结果并调整计划。这听起来很美好但工程上要面对一个现实——Agent 的每一步都可能出错而且错误会随着步骤累积。举个例子一个 Agent 被要求“整理上季度销售数据并发送邮件给管理层”。它需要读取数据库、筛选数据、生成摘要、调用邮件服务。如果中间某一步 SQL 写错了或者摘要里包含了一个错误的数字后续所有步骤都会基于错误继续。如果没有人在关键节点介入这个错误会在五分钟内发送到几十个人的邮箱里。Petar Djukic 在分享中强调的一个重要观点正在于此Agent 的效率提升是乘法级别的但错误扩散也是乘法级别的。这意味着我们不能因为 Agent“聪明”就完全放开而是要在设计阶段就明确“哪些动作必须由人来批准”。这不是能力不足的妥协而是可靠的工程决策。3.2 HITL 可以部署在哪些环节HITL 不是一个独立的组件而是一种穿插在系统各环节的设计模式。常见部署点包括意图识别置信度低于 0.6 时转人工客服Agent 准备执行写操作删除、更新、转账前弹窗确认RAG 召回文档的相关性评分无法确认时由人来判断是否采纳内容生成涉及高危主题时进入人工审核队列模型定期评估时由人工对抽样结果打分作为质量基线。从工程角度看HITL 的粒度越细人工介入的频率就越高成本也越高。所以设计时必须定义清楚什么样的样本需要人什么样的样本不需要人。这个“选择函数”就是 HITL 的核心后面会详细展开。3.3 从成本角度看 HITL 的真实 ROI很多人第一反应是加人工环节流程变重成本变高。这个判断只说对了一半。HITL 的确会增加即时成本但它真正节省的是隐性成本错误决策造成的业务损失、用户流失、合规罚款、品牌声誉受损。以内容审核系统为例如果完全自动化漏判一条违规内容可能带来平台级风险如果全部人工审核成本又不可接受。HITL 的合理设计是高置信度的内容自动通过低置信度的内容进入人工队列置信度中等但涉及高危类型的内容强制人工。最终人工审核的比例可能只有 10% 到 15%但系统对风险的覆盖能力可以达到全量。所以评估 HITL 的 ROI 不能只看人工成本要看“用最小的人工介入覆盖最大的风险敞口”。这句话应该贴在每个做 AI 系统的团队墙上。4. HITL 工程落地的核心设计4.1 四个必备模块一个可工程化落地的 HITL 系统至少包含四个模块采样策略模块决定哪些样本需要人工介入审核工作台模块让人能查看上下文、作出判断、留下记录反馈回写模块把人的判断转换为结构化数据存入新数据源或数据库模型迭代模块利用反馈数据重新训练或微调模型降低后续人工介入率。这四个模块形成一个飞轮。采样策略挑出模型最需要人帮助的样本审核工作台提供判断工具反馈回写把判断变成数据模型迭代让模型学会之前不会的下一轮采样时介入率就会下降。如果缺少任何一个模块HITL 就会退化成“人海战术”。4.2 置信度阈值不是拍脑袋很多团队第一次做 HITL会把置信度阈值设为 0.5 或 0.6理由是“看起来差不多”。但从工程角度阈值应该来自对历史预测分布的分析。具体做法是取最近一段时间的高置信度样本抽样查看哪些预测是错的再取低置信度样本计算错误率。当一个阈值下错误样本占比高到不可接受时说明阈值应该上调。你也可以根据业务成本来确定比如一次错误审核的损失是 100 元一次人工审核的成本是 5 元那么在错误率预期超过 5% 的样本区间人工介入就是划得来的。更科学的做法是用“校准”思想。如果你的模型输出了 0.7 的置信度长期来看这批样本的准确率应该接近 70%。当模型校准良好时阈值可以自由伸缩当校准很差时置信度阈值就不可信需要靠其他指标如语义相似度、规则命中数辅助决策。4.3 反馈数据如何回写模型HITL 的最终目标不是永远靠人审核而是让人审得越来越少。这就需要在人审完后把数据喂回模型。实践中有两种常见方式第一种是离线定期微调Offline Fine-tuning。把人工审核过的数据积累成一批定期对模型做增量训练或微调。优点是流程稳定适合大多数团队缺点是反馈到生效有延迟。第二种是在线学习Online Learning 在线学习。每一条反馈实时进入模型更新适合大规模流式场景。但在线学习对工程要求高容易引入灾难性遗忘和模型漂移一般团队不建议直接上。更实际的做法是先用 SQLite 或 PostgreSQL 存审核记录每周做一次统计分析生成“模型错误报告”再用这份报告决定微调策略。这样做的好处是反馈数据不会散落在日志里而是成为有价值的数据资产。5. 代码实现一个最小 HITL 闭环这一部分我提供一个可运行的最小示例完整演示采样策略、审核接口、反馈回写三个核心模块。技术栈选 Python FastAPI SQLite简单直接适合在本地快速跑通。5.1 环境与依赖建议使用 Python 3.9 以上版本创建虚拟环境后安装以下依赖pip install fastapi uvicorn numpy pydantic版本请以实际环境为准本文重点演示通用思路不绑定特定版本。如果你只是想理解逻辑也可以只安装 numpy跑采样策略部分。5.2 采样策略模块文件路径hitl/sampler.pyimport numpy as np def should_request_human( probs: dict, threshold: float 0.6, margin_threshold: float 0.1 ) - dict: 判断一个预测结果是否需要人工介入。 参数 probs: 分类概率字典例如 {A: 0.7, B: 0.2, C: 0.1} threshold: 最高置信度低于该值时触发人工审核 margin_threshold: 最高置信度与第二高置信度的差值低于该值时触发人工审核 返回 包含是否需要人工介入、介入原因、置信度等信息的字典 if not probs: return {need_human: True, reason: empty_probs} items sorted(probs.items(), keylambda x: x[1], reverseTrue) top_label, top_prob items[0] second_prob items[1][1] if len(items) 1 else 0.0 margin top_prob - second_prob if top_prob threshold: return { need_human: True, reason: low_confidence, top_label: top_label, top_prob: round(float(top_prob), 4), margin: round(float(margin), 4), threshold: threshold, } if margin margin_threshold: return { need_human: True, reason: low_margin, top_label: top_label, top_prob: round(float(top_prob), 4), margin: round(float(margin), 4), margin_threshold: margin_threshold, } return { need_human: False, reason: auto_pass, top_label: top_label, top_prob: round(float(top_prob), 4), margin: round(float(margin), 4), }这段代码的思路是模拟经典主动学习中的不确定性采样不只看最高概率也看最高和第二高之间的差距。高置信度但差距极小的情况说明模型在两类之间摇摆这种样本也正是人工介入价值最大的样本之一。5.3 人工审核接口文件路径hitl/main.pyfrom fastapi import FastAPI, HTTPException from pydantic import BaseModel import sqlite3 import json import datetime from hitl.sampler import should_request_human app FastAPI(titleHITL Demo API) def init_db() - None: conn sqlite3.connect(hitl.db) conn.execute( CREATE TABLE IF NOT EXISTS audit_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, sample_id TEXT NOT NULL, model_output TEXT NOT NULL, reason TEXT NOT NULL, human_label TEXT, status TEXT NOT NULL DEFAULT pending, created_at TEXT NOT NULL, reviewed_at TEXT ) ) conn.commit() conn.close() app.on_event(startup) def startup() - None: init_db() class PredictRequest(BaseModel): sample_id: str probs: dict class ReviewRequest(BaseModel): record_id: int human_label: str app.post(/predict) def predict(req: PredictRequest) - dict: decision should_request_human(req.probs) if decision[need_human]: conn sqlite3.connect(hitl.db) conn.execute( INSERT INTO audit_records (sample_id, model_output, reason, status, created_at) VALUES (?, ?, ?, pending, ?) , ( req.sample_id, json.dumps(req.probs, ensure_asciiFalse), decision[reason], datetime.datetime.now().isoformat(), ), ) conn.commit() conn.close() return { need_human: True, reason: decision[reason], message: 已进入人工审核队列请调用 /review 接口处理, } return { need_human: False, label: decision[top_label], confidence: decision[top_prob], } app.post(/review) def review(req: ReviewRequest) - dict: conn sqlite3.connect(hitl.db) cur conn.execute( SELECT id, status FROM audit_records WHERE id ?, (req.record_id,) ) row cur.fetchone() if row is None: conn.close() raise HTTPException(status_code404, detail审核记录不存在) if row[1] ! pending: conn.close() raise HTTPException(status_code400, detail该记录已审核过不能重复审核) conn.execute( UPDATE audit_records SET human_label ?, status reviewed, reviewed_at ? WHERE id ? , (req.human_label, datetime.datetime.now().isoformat(), req.record_id), ) conn.commit() conn.close() return {message: 审核完成反馈已记录, record_id: req.record_id, human_label: req.human_label}这个接口做的事情很直白第一预测请求进来后先走采样策略判断是否人工介入第二需要人工介入的样本写入审核队列第三人工审核接口把人的判断写回数据库。它在真实系统中对应的是“审核工作台”的底层接口。5.4 反馈回写与数据分析文件路径hitl/feedback.pyimport sqlite3 from collections import Counter def get_pending_count() - int: conn sqlite3.connect(hitl.db) row conn.execute( SELECT COUNT(*) FROM audit_records WHERE status pending ).fetchone() conn.close() return row[0] def get_review_summary() - dict: 统计已审核样本中人工标签和模型预测的分布。 conn sqlite3.connect(hitl.db) rows conn.execute( SELECT model_output, human_label FROM audit_records WHERE status reviewed ).fetchall() conn.close() human_label_counter Counter() reason_counter Counter() for model_output, human_label in rows: if human_label: human_label_counter[human_label] 1 probs eval(model_output) # 演示用生产环境请用安全解析 top_label max(probs, keyprobs.get) reason_counter[top_label - (human_label or unknown)] 1 return { pending_count: get_pending_count(), human_label_distribution: dict(human_label_counter), model_to_human_transitions: dict(reason_counter), }这个模块回答了一个关键问题人审之后的数据怎么用。通过统计模型预测和人工标签的转换关系可以发现模型在高频错误点上的系统性偏差。比如模型频繁把“退款咨询”识别成“产品投诉”说明训练数据里这两类样本的边界不清晰微调时就需要补充边界样本。5.5 如何运行这套示例启动 API 服务uvicorn hitl.main:app --reload --port 8000调用预测接口模拟一个低置信度样本curl -X POST http://127.0.0.1:8000/predict \ -H Content-Type: application/json \ -d {sample_id: S001, probs: {退款咨询: 0.45, 产品投诉: 0.42, 其他: 0.13}}预期返回{ need_human: true, reason: low_margin, message: 已进入人工审核队列请调用 /review 接口处理 }接着查询审核队列并提交人工标签可以先在 SQLite 里查看记录再调用审核接口sqlite3 hitl.db SELECT * FROM audit_records;curl -X POST http://127.0.0.1:8000/review \ -H Content-Type: application/json \ -d {record_id: 1, human_label: 退款咨询}最后运行数据统计模块python -c from hitl.feedback import get_review_summary; print(get_review_summary())到这里一个最小 HITL 闭环就跑通了模型预测 → 采样策略判断 → 人工审核 → 反馈记录 → 统计报表。6. 运行效果与验证6.1 如何判断 HITL 真正生效很多团队把 HITL 实现了却不知道如何验证它是否真的在起作用。我建议从三个指标看第一人工介入率。介入率不是越低越好也不是越高越好而是要结合模型准确率看。初始介入率可能高达 20%随着反馈数据和模型迭代应该呈现下降趋势。第二人工审核的纠错率。意思是人工审核后变更了模型预测结果的比例。如果纠错率低于 2%说明采样策略选出的样本大部分是模型本来就答对的人工审核在空转。合理的纠错率一般在 5% 到 15% 之间具体取决于业务难度。第三高置信度区间的错误率。这个指标容易被忽略。很多团队只关注低置信度样本的审核却忘了定期检查那些“自动通过”的样本里是否有错误。建议每周抽取 2% 到 5% 的自动通过样本做人工复核确保阈值没有失效。6.2 预期输出参考按上面示例运行预期能看到预测接口返回need_human: trueaudit_records表新增一条pending记录审核接口更新后该记录状态变为reviewedhuman_label写入人工标签统计模块输出人工标签分布和模型到人工标签的转换关系。整个流程不复杂但已经具备生产系统的雏形。6.3 验证失败时先查哪里如果代码跑不通按以下顺序排查检查项说明依赖是否安装fastapi、uvicorn、numpy、pydantic 缺一不可数据库是否初始化启动时init_db()是否正常执行hitl.db是否生成SQLite 连接是否冲突多线程写入时 SQLite 可能报锁错误生产环境建议换 PostgreSQL是否在项目根目录运行hitl包结构依赖当前目录路径不对会导致 import 失败7. 常见问题与排查思路问题现象可能原因排查方式解决方案人工介入率长期偏高降不下来采样策略的阈值设置过严或模型校准差查看人工审核纠错率确认是否真的在纠错降低阈值或优先做模型校准如果纠错率极高说明模型本身能力不足应优先提升模型人工审核纠错率极低人在空转采样的样本不够“有难度”分析审核记录查看人工变更比例调整采样逻辑加入困难样本挖掘、对抗样本生成反馈数据存下来了但模型没有变好反馈数据没有结构化或微调时没有做数据清洗检查反馈数据是否带时间戳、业务标签、审核人 ID建立标准反馈表微调前做数据去重和噪声清洗审核队列堆积严重SLA 超时人工审核人力不足或触发机制太宽松查看队列长度和平均审核耗时设置超时自动降级策略优化阈值减少低价值样本进入队列HITL 在 Agent 场景“每步都要人确认”体验极差没有区分“关键动作”和“普通动作”梳理 Agent 每一步的副作用级别只对高危动作写操作、对外发送、删改强制人工确认普通动作自动执行第 5 条在 Agent 项目里尤其常见。如果一个 Agent 系统每一步都弹窗确认用户会直接放弃使用。更合理的做法是给动作分级读操作自动执行写操作必须人工确认高影响写操作需要双人确认。这个设计不是 HITL 的限制而是 HITL 的关键价值。8. 工程最佳实践与安全边界8.1 审核工作台的设计原则人工审核工作台不是简单的“对/错”按钮。设计时至少要提供三类信息原始输入模型看到的数据包括文本、图片、上下文模型输出预测标签、置信度、推理过程摘要辅助信息相似历史案例、规则命中记录、同类型样本的审核结果。否则审核员只能凭感觉判断审核质量无法保证。更重要的是每条审核记录都要留存审计日志谁审的、什么时候审的、依据是什么。这既是合规要求也是模型迭代时的追溯依据。8.2 权限与安全边界HITL 系统涉及人工决策权限管理必须谨慎。建议遵循最小权限原则普通审核员只能处理分配到自己名下的任务审核主管可以查看团队审核质量和效率但不能修改审核记录管理员可以配置采样阈值和审核流程但操作记录需要完整留存审核记录一旦提交不能物理删除只能标记“作废”并说明原因。对于涉及用户隐私的数据审核工作台不展示敏感信息或者对敏感字段做脱敏处理。API 接口要做好鉴权不能像上面示例那样裸跑在公网建议接入 OAuth 2.0 或企业内部 SSO。8.3 生产环境的数据库选型示例中用 SQLite 是为了演示方便。生产环境建议使用 PostgreSQL原因有三点支持并发写入多人同时审核不会锁库支持 JSON 字段模型输出可以直接存成 JSONB查询更灵活可以按时间分区审核数据量大了以后清理和归档更方便。如果使用 PostgreSQL上面的 SQL 语法基本不变只需要加一行CREATE EXTENSION IF NOT EXISTS uuid-ossp;并把主键改成 UUID更利于后续数据合并和迁移。8.4 从 HITL 走向 Human-on-the-Loop一个成熟的系统不应永远停留在“每条都审”的阶段而要走向渐进式自动化。当模型通过反馈数据变得足够可靠时可以把部分场景从 HITL 切换为 Human-on-the-Loop模型自动处理系统定期抽样并监控质量指标只有指标异常时才人工介入。这个演进过程需要谨慎每次扩大自动化范围时先灰度运行一段时间对比新策略和旧策略的质量指标确认无误后再全量切换。回滚方案要提前准备好一旦指标恶化能立刻切回 HITL 模式。9. 总结与后续学习方向Petar Djukic 的演讲标题 “The Human Is the Loop” 提醒我们在 AI 的高速发展阶段人并没有退出系统反而以更关键的方式嵌入系统。HITL 不是技术退步而是工程可靠性的必要设计。这篇文章从概念、架构、代码到生产实践完整呈现了 HITL 最小闭环的搭建过程。照着示例跑一遍你就能理解采样策略、审核队列、反馈回写这三个环节如何协作真正上手后再把权限、审计、灰度发布这些工程细节补齐就是一个可以上生产环境的 HITL 系统。如果继续深入建议按这个顺序学习先研究主动学习的不确定性采样方法熵、Margin、Least Confidence再读大模型 RLHF 中的人类反馈机制最后研究 Agent 工具调用场景下的关键节点审批设计。这三层对应数据标注、模型对齐、系统安全也是 HITL 在 AI 工程里的三个深层价值。建议先把这个最小示例跑通再结合你自己的业务场景画一张“哪里需要人、什么时候需要人、人审之后数据怎么用”的流程图。这张图画清楚了HITL 的设计就已经完成了一半。