一文解读 AIGC 驱动高绩效商业的落地与思考
本文根据神策数据智能业务负责人郭荣锋《AIGC 驱动高绩效商业的实践》的主题演讲整理所得，主要围绕神策对 AIGC （即 AI-Generated Content，人工智能生成内容）业务应用的理解、AIGC 的落地实践及心得体会等方面展开。
以下为本文的要点：
· 懂业务并且能够与 AI 进行对话的人，将成为公司的超级个体，发挥更大的价值
· 神策数据通过构建数据分析 copilot 和用户运营 copilot，为公司的关键角色提供支持，使其成为超级个体
· 提升 AIGC 应用效果的关键点是企业数据，AIGC 时代下，企业数据愈发重要
一、对 AIGC 业务应用的理解
关于 AIGC 的范式，我们认为一方面是LUI （即 Language User Interface，自然语言用户界面），另一方面是专家模型。比如画画，我们想画一幅“美丽的清晨”，LUI 理解需求「美丽的清晨」，画画模型把图画出来；比如让 AI 模仿孙燕姿的嗓音演唱 XX 歌曲，LUI 理解需求「演唱 XX 歌曲」，唱歌模型完成演唱。现在的大模型能比较好地理解自然语言，LUI 相对比较成熟；但目前并不是所有行业或场景都有对应的 AI 专家模型，也有一些通过传统方法来实现。随着 AIGC 能力的发展，各种 AI 专家模型会越来越成熟。引用陆奇博士的话，现在正处于「模型」无处不在的新范式拐点上，接下来的时代就是模型的世界。
从企业经营的角度看， LUI + 专家模型将带来什么样的影响？确实，它可以提升员工在特定场景下的工作效率，比如自动写会议纪要等；但从其他的视角看，有没有可能有更大的价值？
我先分享一个故事。我有个出版行业的朋友，主要给书做插画，她是自己这个小公司的 CEO，没有经过一天画画训练的她，应用 AIGC 以后成为公司里最有创造力、最有生产力的人。我问她为什么，她说：画画分成两个环节，第一个环节是设计，即要画成什么样，第二步是画出来，利用训练有素的肌肉记忆把想要的画画出来。她虽然不懂画画技巧，但多年的行业经验让她很懂客户需求和插画设计，又因为她拥有丰富的绘画知识，因此她能清晰地把设计需求表达出来给 AI，然后由 AI 完成具体创作。既懂业务又具备和 AI 对话的能力，让她变成了最厉害的生产力和最棒的创作人员。
在这个故事里，LUI + 专家模型代替了只能提供基础技能价值的画师，懂业务 & 懂得和 AI 对话的业务负责人或者资深画师和 AI 互通，直接开展业务，发挥了更大价值，成为公司内的超级个体，公司业务的效率和质量自然也有了提升。因此，从企业经营角度看，可以通过构建 LUI + 专家模型来服务公司内关键角色，打造企业内超级个体，提升业务经营效率和质量。
二、AIGC 的落地实践
关于 AIGC 业务的落地，一方面是在普通场景下如何提升工作人效？另一方面是如何赋能公司中有业务能力的人，发挥其价值，让他们成为公司的超级个体，驱动业务发展。
在感知、决策、行动、反馈构成的业务闭环中，业务负责人员作为关键角色比较关注和能发挥价值的是感知和决策，我们将这两个环节设为 AIGC 应用的重点，以帮助他们发挥价值，成就超级个体。
当前企业的工作流程大多是由分析师产出数据报表和报告，业务负责人看到数据报表，针对异常数据表现，数据分析师再进行分析和汇报，业务人员难以直接接触数据，从而限制了他们对业务全局的洞察力。此外，洞察数据后进行用户运营决策时，如何更好地理解过往策略，并基于当下目标制定新的运营策略，也有较高的门槛。针对这些情况，我们可以通过 AIGC 去赋能业务负责人。
在感知环节，重点是数据分析模型与 AI 深度融合，构建数据分析专家模型，支持对话式指标查询，在一问一答中快速查看想要的数据，帮助超级个体便捷获取数据，理解业务现状（what）；支持对话式数据分析，专家模型对指标及形成进行解读，帮助进行业务归因（why）。在决策环节，重点是营销模型和 AI 融合，构建营销专家模型，支持会话式受众圈选和营销策略生成。
我们构建了一个智能助手，目前是 Demo 阶段，从数据分析场景开始，现在是浏览器插件的形式。以事件分析场景为例，在输入框中用自然语言输入要获取的数据指标，比如最近 7 天搜索点击的用户数，GPT 模型将自然语言转化为请求查询 JSON 并发起查询，并进行图形化展示。我们为什么采用 text2json 而不是 text2sql？因为这样有两个好处，一方面更容易理解，便于业务人员判断查询；另一方面更容易进行人为干预，比如生成的查询 JSON 不对，或者想换种计算方式或者查询条件看看指标怎么样，都可以快速调整。
这个要怎么实现？首先要让 GPT 理解我们数据的 schema 以及任务，所以我们要做的事情是把我们 schema 传给 GPT，但因为存在长度限制，我们要解决的第一个问题就是如何让 prompt 更短，我们先从报表的上千个字段中筛选出进入到 prompt 的字段。其次，筛选出来的 schema 会有很多的字段，字段多了也会影响 GPT 的正确率和精准度，因此需要跟 GPT 进行交互，让它挑选出哪些字段与产品有关。最后再通过 GPT 进行 JSON 的生成，而对于复杂的查询，可以先让它生成一个结构，在这个结构下把内容填充进去。因此，这个查询的过程相对比较复杂。
此外，还可以辅助进行 SQL 的编写，有些分析用 JSON 查询不好做，就用 SQL 来做自定义查询。在输入框中用自然语言写入想要的查询，GPT 模型将自然语言转化为 SQL，并发起查询。如果 SQL 不对的话，还可以做修改，或是通过多轮对话的方式对其进行优化。
在分析模型外，我们还做了帮助问答助手，帮助业务人员更快速学会用产品。用户可以用自然语言问一些产品问题，GPT 基于我们的产品帮助手册来回答问题。比如输入 Session 分析可以做什么，上面就列出了回答，并引用了我们产品帮助文档的参考。GPT 做查询并基于查询做摘要生成，摘要效果和相关性比传统的搜索效果要好。比如：查询「概览和书签有什么关系」，在这个场景中，GPT 摘要详细对比描述了概览和书签的定义以及关系，而普通的搜索没有这样的能力。
三、关于 AIGC 实践的认知总结
上面介绍了我们围绕 AIGC 开展的一些应用，接下来探讨一下我们遇到的问题和实践过程中得到的认知。
首先来谈谈模型精准性。相比于摘要生成模型、图片生成模型，数据分析模型非常要求精准性。摘要生成的好坏、图片生成的好坏可以直观判断，而数据指标的对错难以直观判断，因此对精准性要求很高。而影响模型精准性的因素有哪些呢？
第一，模型的应用方式，我们要知道 prompt 怎么写影响性能和效果，比如要不要 step by step，要不要自我校准，JSON 生成要不要先生成结构等。
第二，模型的推理能力。最常见的有最近 7 天、同比、环比以及一些聚合统计的逻辑不对，比如「在过去 7 天做过成功拍照事件行为且次数超过 10 次的用户数」这一类的查询。
第三，prompt 长度约束问题。我们的事件、属性等组合起来可能有大几百，甚至上千个字段，不能将所有的表信息塞到 prompt 中，要先进行一次事件和属性的选择。
第四，字段理解问题。要让 GPT 理解事件和属性，就要给模型足够的信息，比如事件 show_take_photo_guide_popup，我们要让模型知道这是「首次拍照后弹窗引导」。
第五，业务理解问题。业务理解有两类，一类是业务指标的理解，比如转化率，不同公司的转化率定义（分子、分母）不一样，需要让模型知道业务指标的含义；另一方面是具体字段和属性的选择，有些元数据的描述很相近，比如统计照片上传成功数量，需要确定用「照片上传成功」事件还是用「服务端照片上传成功」事件。
如何解决以上问题？一方面我们需要等大模型能力的提升，或是自己去做某个领域的模型。另一方面关于字段理解和业务理解，如何积累数据变得很关键。在 LUI 的情况下，数据完备性非常重要。除了更多的数据积累，还需要知识，比如语义相近的两个字段到底选哪一个？这不是数据，而是需要知识才能解决的问题，因此要构建企业的元数据知识图谱。比如企业中已有的 1000 张报表，到底哪些字段和属性已经用过，这些字段、属性、指标之间构成了什么关系？这些可以构建出来，并用来做事件和属性的选择推理。
我们再来看看产品的设计与评估。LUI 之后，产品的设计将从场景和功能驱动，变成用户问题驱动。这随之带来两方面的影响，一方面是用户引导的方式发生改变，需要引导用户变得会问问题、正确地问问题，用户引导贯穿提问前、提问中、提问后；另一方面产品的评估方式发生变化，由「有没有某个功能」变成「能否正确回答某些问题」。这些问题的解决一方面要提高对用户的引导能力，另一方面需要建设行业问题以及相关问题的知识库。
基于前面的讨论，我们总结了 AIGC 应用方法。企业在进行决策时，是由技术可行性和业务需求双向决定的。从业务上来说，不能因为要做 AIGC 而做 AIGC，一定要有业务上的抓手，需从场景和业务应用出发。从技术上来说，数据是重要的，它可以提升大模型在特定场景下的精准性。总结起来就是：应用场景是抓手，数据是核心，大模型是支撑。