用户虚拟Agent代理 的实现思路，及反思传统个性化系统【2023Q4】
TLDR
虚拟Agent代理可以看成是个性化系统的下一个阶段，但用户对其效果期待是极高的。
虚拟Agent代理无法冷启动培训，大概率只能依托于有用户数据的场景/公司来实现。
讨论了虚拟Agent代理构建的算法策略上的要求和大致思路。
介绍了虚拟Agent代理用于改善平台对P用户的理解和通过实时博弈提升平台长期效率的思路。
花絮：本文第一稿撰写完毕后，遇到了灾难性的文稿全部丢失。在我重写的时候，由于各种原因导致本次行文会更加简略，我在这里向大家表示歉意。如果觉得哪里没理解，欢迎与我联系沟通。
1、用户虚拟Agent代理
本文讨论的“用户虚拟Agent代理”是指：了解用户的偏好和目标，并能够主动或被动的根据用户的偏好和目标来与环境、平台或其他角色交互。
可以分为以下几种：
【T1】 知名人物/大V的虚拟化身，甚至原型就不是真人。
【T2】为普通用户构建的虚拟Agent代理，场景是通用领域，用于代理用户实现某种搜索或者调研目标、与其他人或者Agent进行第一轮的交流等等。
【T3】为某个平台上的用户（C或者P）构建的虚拟Agent代理，用于7*24h快速地与平台进行自动交互，帮助用户实现用户（在平台上）的目标。例如在网约车/外卖平台上，帮助司机或者骑手（以下称为P）进行自动挑单。
本文主要讨论如何为大量用户进行虚拟Agent代理的构建，而【T1】一般都是针对性特化制作的，对于构建成本不太敏感，所以本文不讨论【T1】。
有谁希望与虚拟Agent代理沟通呢？能想到以下几种场景：
【S1】普通用户A希望与某个用户B沟通，但用户B没有时间/精力/意愿，很多场景下用户A能够跟B的虚拟Agent代理沟通好过没有。
【S2】用户A希望存在某个不会休息的虚拟Agent去与别人、别人的Agent、平台、环境等进行交互，完成自己的目标。
【S3】用户之间的沟通成本较高，平台希望能够通过构建每个用户的Agent，并让其相互沟通来发现可以匹配的用户。
2、虚拟Agent代理 vs 传统的个性化系统
一些读者到这里可能会想到一个问题：虚拟Agent代理跟之前互联网吹的个性化系统有什么本质差异？前面的场景中，除了单纯的沟通需求S1外，S2和S3确实都可以当作一个个性化推荐系统来开发，把这些功能放在前几年用来做宣传也没什么问题。
为什么之前传统的“有个性化推荐系统研发能力”的公司不做呢？除了不少非技术的原因外，还有个重要原因：传统的个性化推荐系统的效果并没有之前吹嘘的那么好，做不到能够实现S2、S3能力且准确率较高的方案。
在我看来，虚拟Agent代理可以看成是下一代的个性化系统设想。在大家的认知中，它相对于前辈有一些区别：
【D1】虚拟Agent代理一般是基于LLM的（或者是效果上对标LLM的），具备很强的语义理解能力。而传统的个性化推荐系统在这方面相对较弱。
【D2】更进一步说，大家对虚拟Agent代理的个性化准确性期待更高。当虚拟Agent代替用户行动或选择时，其行为应该是大概率符合用户期望的（例如至少50%），而传统个性化推荐系统能提升几个百分点就已经算可以接受了。
【D3】虚拟Agent代理应该是完全为单个用户建模的，而不是做了【一个】能实现“千人千面”的上帝视角Agent，并让它分别扮演不同的用户。这在算法策略的整体架构上是不同于传统个性化系统的设计的。
在我看来，上述几点在传统的个性化推荐系统时代其实都是可以去做、去追求的。
D1、D2由于当时的技术限制和研发成本限制，最终只能停留在一个对于用户来说颇为鸡肋的效果上，从商业角度上又不得已去大吹特吹。如果当时的系统真的实现了用户期待的千人千面的效果，那现在何来虚拟Agent代理的需要？
D3是一个实现思路的选择问题，之前其实就可以这么做，我也提过。而传统算法岗群体很拘泥于做一个大一统模型的路线上，这其实限制了他们做的系统对于长尾群体用户的个性化能力的提升。从技术上来说，我认为这个新视角的引入才是这个概念带来的价值。
这方面会在下一节之后继续讨论。
3、如何构建虚拟Agent代理（如何 了解用户）
3.1、策略的质量目标
在讨论如何做之前，先明确需要做到什么样的目标。毕竟不限制目标的话，用传统的个性化推荐系统就行了。
用户使用一个Agent代理（或者人类秘书或者徒弟）时，是希望他们给出的结果、消耗的资源是符合期望的，用户从中获得的收益超过它们消耗的成本和带来的问题。
对于Agent代理来说，用户获得的收益就是它们交付的结果能够符合用户期望的部分，或者至少让用户觉得是有用的。它们会因为行动有成本消耗，例如调用了付费的API、消耗了平台的算力、甚至购买了某些产品/服务。它们也会因为自己的错误行动而带来问题，例如跟别人说了错误的话、拒绝了不该拒绝的请求、在不能反悔的选择中做了错误的选择等等。
如果Agent代理对于用户的理解过差，总是做出不符合用户期望的行为，那么就会削弱它对用户的价值。动作符合期望率 或 解决问题率 低于一定程度的Agent代理对于用户来说可能完全没有正面价值。如果把低质量的Agent推送给用户，那么会让用户在很短的时间内建立对该品牌的负面认知，并弃用该产品。所以虚拟Agent代理的动作符合期望率和动作失败的负面成本都是关键指标，从第一版开始就必须达到一定的要求，并在后续重点提升。
在很多场景下，仅使用传统个性化推荐系统的方案和质量水平是无法达到这种目标的。所以现在大家才会重新提希望有一个能够足够了解用户的虚拟Agent代理。
3.2、冷启动不可行
在传统推荐系统中有所谓冷启动的阶段，在对用户了解很少的时候就能够给用户提供一个还勉强可用的服务。这件事在虚拟Agent代理场景下是可行的么？
我认为在T2的场景下不可行，即使在有LLM加成的情况下也不可行。以下稍微展开这点：
【1】无数据冷启动
先考虑无数据的情况：如果依托于LLM强大的通用知识能力，是否能不依赖这个用户提供大量数据就能够构建出一个行为拟合质量比较高的虚拟Agent代理？
我认为：肯定不行。（这件事在我看来是显然的……）
【2】靠用户极少量初期偏好选择来冷启动
那么退而求其次，是否能够让用户仅付出少量的时间与成本就能培育好他自己的虚拟Agent代理呢？
我认为也是不行的，尤其是T2通用场景，虽然不少人会觉得这是有希望的。这里解释一下：
通用场景最大的问题就是多样性，用户的偏好和知识背景也是很多元的。我认为无法靠1h内的用户主动说明来达到期望的效果。如果能强迫用户高质量的填3h的纯选择题问卷，说不定能有一个还能接受的冷启动效果，但这也是产品上无法承受的。
某些T3的专用场景确实可以低成本做一些快速配置作为冷启动，但用户体验和效果也算不上很好。
【3】跟人能力一样强的Agent 能解决冷启动的问题么？
实际上人类徒弟和秘书也不能有效的解决冷启动的问题。
所以我并不看好所有冷启动的思路。
3.3、整体思路
人之间是如何解决这个问题的呢？实际上师傅带徒弟、老板带助手也并非是“先针对性上课10h，然后再让他们尝试工作”的。而是让徒弟先进行观察，长期的观察，直到他找到一些感觉，然后再逐步少量的点拨。
人类徒弟作为一个很强的小样本学习器，也只能有这样的待遇。现在的监督学习算法的样本利用率要低的多得多，更不可能指望有更快速、更低成本的学习用户习惯方案。
综上在T2场景下，需要观察用户长期的历史行为来进行初步的用户偏好建模，达到一个勉强可用的效果之后，然后才能考虑让用户进行直接点拨。甚至在不少T3场景下，也需要靠这样的方式进行。
我把这个过程学习用户历史长期行为的类似“冷启动”过程称为【温启动】阶段，后续的用户直接点拨称作【知识编辑】阶段。当然这仅适用于已有大量用户历史行为的业务。
没有大量用户历史数据可学习的新产品、新公司该如何呢？我认为这是很难的，本文不在此方向继续讨论。也许还是应该先度过一个传统的个性化推荐系统产品阶段才行。
3.4、温启动 阶段
回顾本阶段目标：需要通过用户大量历史数据进行进行建模，而不是直接使用某种传统的冷启动方式，主要是因为后者的效果达不到预期。
最好的方式就是有大量用户在该场景的历史行为，直接用机器学习方式去学习它们。
但不少场景下并没有直接目标场景的历史数据，只有一些关联性的场景的历史数据。此时可以用类似迁移学习的方式，在这些数据上做一些模型、有强业务语义的特征、中间特征等，然后将它们迁移到新的场景中，期望能够提升在新场景上的预测准确率。
当然这个迁移的过程并不是随便做做就可以的，这需要旧数据拟合和新场景应用两端的模型结构都有针对性的设计才【可能】有可接受的效果。在第5节会略微讨论一下这方面。
3.5、知识编辑 阶段
在获得一个（在用户来看）效果尚可接受的温启动方案后，就可以上线并收集用户的反馈。可以预见用户会发现很多跟个人偏好不一致的情况，这时可能有如下2种反馈：
用户给出当前场景的期望行动选择，但不一定附带解释。
用户给出某种具有一定通用性的反馈，例如“符合某些条件的场景下都要那样，而不要再这样”。
用户对于反馈的生效速度也有较强的期望，如果用户反馈了几次都未见明显改善，那么也同样会消耗其耐心，并且对Agent的智力和产品的技术能力产生怀疑。如果用户发现产品对于他的反馈很慢，甚至很难看到有效的改变，那么会显著的降低其进一步点播Agent的意愿，最终由于Agent代理效果太差而放弃使用。所以必须慎重的看待反馈数据的生效速度这一项指标，尽量追求比较及时的Agent的策略更新速度。
这方面的具体实现方式也跟上一节的迁移学习方案一样需要算法团队拿出为场景仔细设计的特化方案，以下仅举2点抛砖引玉：
根据用户的反馈快速构造一个新的数据集来训练模型，这其中可能需要样本权重调节、新增合成数据等等。
给用户提供某些可以操控的控制选项，当用户希望调整Agent行为时候，可以看是否有对应的选项/标签/参数可以直接调节。
在第5节会进一步讨论这方面。
4、T3场景的特化讨论
T3场景的虚拟Agent代理其实并非现在才有的概念。我在2020年3月就提出过该种平台设计，当时的文章《【2020.3】O2O领域定价策略中的问题与思考：（5）展望抢单场景下的定价策略的终态》虽已删除，但可能还有一些读者仍对此有印象。
4.1、效率 与 博弈
考虑平台和平台上的内容生产者/服务提供者（P用户）之间的关系。无论是线上业务还是O2O业务，不同服务者的能力和偏好是有显著差别的，但线上平台目前并不能充分的了解P用户的个性。
虽然目前平台通过一些大的预测模型整体对P群体有一定预测能力，但对于个体P用户的预测能力仍然是较差的。这跟个性化系统对于具体C用户偏好的感知能力水平是一样的，甚至因为业务天然的数据量更少而更加差。现有系统对于每个用户偏好/能力的预测能力限制了平台的长期效率最优化。
如何更进一步的了解P用户的偏好呢？一种常见的方式是：给他们多个选择进行选择，学习其选择偏好。
基于此的一种建模用户偏好的方式是：平台为每个P用户提供一个虚拟Agent代理，来学习每个用户的偏好，帮助P用户进行任务选择或者抢单。这个方式可以优化用户得到的任务，用户的Agent代理直接影响其接收的任务。只要平台的标准是完善的，用户就没有多少额外造假的动力，用户有动力配合优化虚拟Agent代理并提供自己的真实反馈，他的Agent代理大概率代表了他的个人偏好。
这样会有进一步好处：平台可以应用需要更多交互频次的博弈/拍卖机制，来快速地与大量用户的Agent代理进行互动，优化整体的效率。在这个场景中Agent代理可以几乎实时地进行反馈，可以支持很复杂的多轮拍卖/博弈机制，这在此前是无法想象的。
这种方式为P用户提供了一个更容易与平台进行博弈的工具，但我觉得这个博弈是良性的。虽然看起来提高了P用户与平台博弈的能力，但原本P用户就不可能长期吃亏，他在长期会用脚投票，而当他流失时平台不会知道他究竟是为什么离开的，到底是不喜欢哪些任务而离开的。长期来看，“平台必须正视P用户的这些个性化需求”才是实现长期效率最优化的正确方式。
当然整体方案还需要有很多细节的考量和设计，仅举一例：如果出现一个任务谁都不想做呢？其实应该调整该任务的价格，而不是把他强塞给某个P用户。
这个博弈过程其实不止限于平台与P用户之间，在平台与C用户之间经常也是需要的。
5、算法策略实现思路（一窥）
本文已经较长，仅简单展开一点在算法策略上的实现思路。
总结一下，对于整体算法策略方案有如下要求：
【R1】能够从相关领域的历史数据中提取信息进行迁移
【R2】能够在目标领域上快速根据用户的最新反馈进行迭代
【R3】理解用户的语义级别（而非case级别）指导
【R4】能够使用自然语言与用户进行交互
其实只有【R3】、【R4】跟LLM有关，而前两点其实跟LLM关系不大，也是容易被人忽视的。本节主要讨论【R1】和【R2】，而且这两点也无法完全分开讨论。
从迁移知识的角度有两种常见思路：
把源场景的模型整体拿过来，用于预测新场景目标，或者预测新场景的一个中间环节。
源场景的模型是一个不完全黑盒的模型，可以明确其中某些组件的功能/包含的信息，将其迁移到新场景使用。
能有前者是幸运的，大部分时候在源场景的设计建模时，就要有目的性的构建成某种白盒或者半白盒的方式，同时考虑到要把哪些部分迁移到新场景使用。这些迁移的部分可以是模型的一部分（有某种独立的预测能力）、离散化的标签特征、数值类特征、稠密的embedding类特征等等，各种各样。
在新场景单纯的构建一个新模型并不难，难得是如何根据具体用户的反馈来快速对其进行更新。我认为仅靠大统一的模型很难实现，一方面模型的更新时效难以满足，另一方面也很难保证不会“因为提升主流用户的效果而牺牲小众用户的效果”。
一种思路是：要为每个用户构建一个独立的模型，它可以基于一个大的通用模型的输出，这个模型未必要很大，但仅为该用户的效果进行优化。这有如下好处：
模型可以快速更新，因为训练成本并不高。
模型仅为该用户优化，能够更好的满足与平台中主流用户偏好不同的用户。
在这一阶段用户也攒了大量数据之后，这个用户级的模型也可以比较复杂。但在早期，由于数据、迁移的知识等因素，它大概率是一个简单（计算量较小）的模型，甚至可以只是有一些可调整参数的规则集。
“简单”的模型有一个好处：可以把用户理解的特征和对应的参数暴露给用户，当用户想要细致调整某些参数时，他可以直接快速修改，例如科幻电影中机器人的【诚实度】指标。
确实一般来讲，通过迁移得到的原始特征 或 新场景模型的原始特征过多、过于细碎，并不适合用户直接进行干预。但【诚实度】启发我们：在用户强可操控的场景下，应该在基础特征上尽量包装出一些用户可理解的高级特征/意图，并由此构建模型。这样用户可以快速对模型进行干预，而不是需要大量耐心和时间通过数据样本逐步扭转模型的行为。
基于这些高级特征构建的模型未必只能选用很简单的模型，它也可以很复杂很黑盒，也可以是很多用户共享的复杂模型。用户只需要知道“我希望模型更诚实的时候，我就调高它的诚实度就好了”就足够了。在这个思路下，未必需要使用一个完全白盒的模型，只需要一个在某些位置白盒的模型方案，它可以有一些“用户可理解的控制旋钮”，有一些可以从其他场景迁移过来的知识输入。
由于用户尝试纠正Agent代理的行为时使用的是没有太多限制的自然语言，所以可以从大量用户的沟通中挖掘一些“用户可以理解，但系统中并未专门构建”的高级特征。模型的演化应该朝着尽量贴近用户能理解的控制方向进化。举个例子：用户不需要理解如何调整LLM的temperature参数，他只需要选择是“更有创造力”、“更平衡”还是“更精确”，这是New Bing Chat的UI设计。New Bing Chat无法准确预测用户当前的需求是什么性质，用户的选择偏好也未必是在时间上稳定的，所以这直接交给用户选择就好。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。
读者交流群见 公众号读者交流群 11.8
希望留言可以到知乎对应文章下留言。
《【2020.3】O2O领域定价策略中的问题与思考：（5）展望抢单场景下的定价策略的终态》发表于2020.3.21
本文一稿成文于2023.11.4
本文于2023.11.8首发于微信公众号与知乎。
知乎链接 https://zhuanlan.zhihu.com/p/665646253