失败的 “Human in the loop”实践回顾
Human-in-the-loop (HITL) refers to a system or process in which a human actively participates in the operation, supervision or decision-making of an automated system. In the context of AI, HITL means that humans are involved at some point in the AI workflow to ensure accuracy, safety, accountability or ethical decision-making[detail]
1
HITL本意是人机交互得到更好的产出，但是这有两个前提：一是模型欠缺某些知识或者模型本身推理较弱；二是人的参与对产出有积极的影响。在我的实践中，HITL的效果经常不如纯粹的workflows。下面是我的实践。 某一天我接到了一个理账任务，具体是上游会给我客户的月结单流水以及相关的票据，我需要利用llm的能力将其输出为基于会计准则的报表。为此我设计了一个skill，里面指导了llm怎么利用脚本/接口解析文件（省token），怎么优化判断结果，怎么固化输出等等。然后在做的时候我遇到了一些问题：
1）在服务包装情况下，llm的中间输出对业务来说是黑盒，流水和票据的关联，科目的判断，对业务来说是不可知的。在这种情况下，业务对结果是不可审计的。 2）上传的资料是残缺的，llm判断缺少客户的背景，部分流水和票据的对应是缺失的，此时llm不愿做出判断。部分流水与票据关联的置信度较低，模型的多次独立判断的结果会出现波动。 3）在业务几乎完全脱离的情况下，他还承担此次任务的责任吗？ 为了解决这些问题，我做了下面几个设计： 1）在llm开始摸数据的初期，先收集整理缺失的背景数据/票据信息，然后输出一个访谈报告，交由业务推进与客户访谈。记作HITL(A)。 2）在llm准备出表之前，收集整理置信度较低的记录输出待复核清单，这些记录的科目判断交由人工处理。记作HITL(B)。 在理想情况下，A解决了客户的大背景以及其需求。B一方面部分解决了llm输出可解释性，可靠性以及稳定性；另一方面由于人的参与，也解决了责任归属的问题。但是在实践中，这些功能彻底变味了，A跟B不同程度的变成了业务上的冗余以及llm的掣肘。
2
在加了这两个模块之后，workflows变成了下面这样：上传文件 –> 根据拿到的访谈报告进行客户访谈(A) –> 上传访谈记录 –> 填写待复合清单(B) –> 上传待复核清单 –> 下载输出报表。由于加入了A和B，业务那边除了时间成本还引入了额外的复杂度。对于大部分客户来说，访谈是为了明晰自己的账务和自己的目的，所以除了关于流水的解释外，往往提出了自己额外的需求，例如做亏损，某笔金额需要怎么调整等。这些操作在llm层面很多是没有事实依据的，所以这些就很有可能变成低置信条目进入待复核，进而导致待复核的目录扩大。在待复核阶段，不同于预期的“人的参与”解决了“不确定的对错”，反倒是引入了“确定的错误”。为了填写待复核，理想情况下业务需要再次人工阅读原始的资料，理清相关的流水票据再给出科目判断。但是在实践中，业务往往只根据流水摘要和金额画像直接批量的写入科目，并没有清查资料，导致了大量的错误科目。而且由于解决清单的长尾问题，交由人工填写的清单首先是进行大量的删减，只取出高占比金额流水；其次还基于摘要进行了聚类。前者损失了部分数据，后者损失了部分颗粒度。种种因素，都导致了业务的冗余以及错误的引入。 抽象来看，总结为以下问题： 1）AB引入了额外的复杂度 2）AB带来的收益不足以cover引入的复杂度 3）AB由于设计和人的因素，甚至可能是负收益 具体来看，即： 1）A既是业务的冗余也是数据的冗余。对于业务来说访谈不仅需要花额外的时间跟客户对接，又要反馈客户额外的需求。这不仅将出表后的客户反馈提前到了出表前，还不可避免还要经受客户对表的进一步反馈。正所谓多一事不如少一事。另外，对于数据来说，在llm的今天，结合资料进行客户的画像构建根本不是难事。 2）引入的错误既是设计的妥协又是人的失责。为了降低人在B的负担，设计层面主动删掉了长尾，并因为构建聚类损失了颗粒度，这不可避免的引入了错误。在人的阶段，由于业务人员的专业能力参差导致待复核条目更加不可控，甚至引入比“llm去猜”更多的错误。
3
至此，HITL的实践算是失败了。为了继续推进，首先先回顾下之前的问题。此时这些问题有了新的视野： 1）llm的中间输出确实黑盒，但是业务根本不在意（至少此时）中间llm具体是怎么判断的，只要最终的结果看着像那么回事即可。 2）背景的缺失是伪命题，因为原始资料中信息足以让llm构建出客户公司画像。部分流水跟票据的对应关系缺失是真实存在的，但是讽刺的是就算是缺失的情况下，llm的判断基本上也比人的判断更好，这本质是人的问题。 3）责任归属仍然是悬而未决的问题。具象化描述这个问题是：当输出的报表出现问题时，该客户对应的业务反而会向技术寻找答案。技术理论上只会提供技术，而不会对产出的报表的偶发质量波动负责。 总结一下这几个问题。黑盒问题虽然技术上还存在，但是业务不关心；信息缺失仍事实存在；责任问题目前已经搁置了。所以目前只剩下信息的问题了。 之前提到，信息的缺失包括背景的缺失和关联的缺失。对于背景的缺失，之前也提到可以通过构建公司画像来解决。目前的解决办法为llm在workflow的初期就开始基于注册文件，往期审计报告，流水的整体谱系以及支出明细等信息构建公司画像，这个画像描述了公司的业态，资金模式，账期边界人员薪酬等信息。对于关联的缺失，目前采用外挂小型知识库进行推演。关联的缺失对于人和llm来说处理的方式没有本质差异，只是处理的过程有差异。人可以基于人的历史经验对残缺的信息进行推导，比如说小企业每月固定的数万的支出，大概率就是人员的薪资。基于此，目前一方面是利用提示词优化来加强llm来进行信息推理，一方面通过外挂知识库来加强其推理。
4
此后，业务逐渐稳定了，只需要后续继续补充会计知识即可，部门的周处理量翻了几十倍。 回顾这次实践可以看出，影响HITL主要是人的因素，人的因素既体现在工程上又体现在认识上。在实践中，参与交互的人往往是业务而不是技术。因此，技术必须暴露出来一个HITL窗口，这个窗口需要透明化双向的需求和反馈。窗口设计的质量直接影响了HITL的效率。同时，由于业务对HITL的认识不足或者其本身的不足，同样会对HITL的效果产生巨大影响。