cover_image

淘宝直播AI提效探索的一些心得

直播技术团队 大淘宝技术 2025年03月14日 06:50
图片



本文围绕直播团队在过去半年中基于AI技术在工程侧提效的探索展开，详细介绍了服务端、前端、数据科学、测试和数据研发等职能团队如何结合AI能力进行创新尝试。文章不仅总结了现阶段取得的阶段性成果，还深入分析了AI能力的优势与局限性，例如文本生成的涌现能力、固定思维过程以及对世界的有限理解等。通过具体案例，如任务拆分、输入提炼和人“机”交互设计，作者分享了如何合理设计AI能力与现有研发链路的适配方案，以实现更高效的解决方案。此外，文章还探讨了RAG实践、FT调优等技术的应用，并表达了对未来进一步探索和合作的期待。



图片
写在前面

淘宝直播团队在最近半年的时间里基于AI做了一些工程侧提效的探索，分别是在服务端、前端、数科、数据研发和测试领域都一些尝试，截止到目前为止，虽有一些阶段性成果，但是还是处于持续的摸索和迭代的过程，本身工具或者产品的效果不是本文要突出的重点，笔者作为项目组的忠实协同者、观察员兼秘书，对于项目在推进过程中，如何去定义问题、设计方案、回收结果再重复review迭代有一个三方的视角，从项目的PM和组员身上也学到了不少知识，想着把这些过程的观察和自身的收获，做个阶段性的心得体会总结，会以观点和案例的方式给到大家做参考，并且期待更进一步的沟通交流。

下表是我们几个方向的探索的一些概述：

职能

团队

结合AI能力期望探索的方向

现阶段尝试切入点

服务端

根据需求和视觉稿，生成技术方案文档；同时根据技术方案文档生成核心服务代码和功能逻辑代码；

1.生成基础平台或者中间件调用代码；

2.面向小需求，结合当前场域相关服务API，直接生成可微调、可调试的代码；

前端

根据需求和视觉稿，生成前端样式代码、逻辑代码和胶水代码；

1.面向简易的UI视觉，生成样式、逻辑和胶水代码；

2.面向表格类后台页面，生成交付代码；

测试

根据需求、视觉交互、方案文档生成测试用例，并且按照测试用例进行执行，生成测试报告

结合需求、视觉稿和技术方案文档，按照功能进行切片聚合，生成测试用例

数据

科学

智能分析业务报表数据和实验数据，支持业务自助化取数，并提供数据智能分析、业务洞察建议和趋势预测能力，生成数据分析洞察报告；

针对AB实验数据，给出智能化解读和后续的实验可能优化方向建议；

数据

研发

基于需求理解，通过筛选组合数据指标、维度、标签生成SQL，完成应用层模型自动化开发；

将需求的感性理解抽象为数据规则，并配合产品基座+AI能力实现基于规则的代码生成和自动化研发流程等


图片

AI能力


谈及当下AI所能提供的能力，其实主要是指基于LLM的Generative AI的能力范畴，当然未来可能是AGI。


开头先来考个古，被誉为第一位计算机程序员的Ada Lovelace，在1843年关于查尔斯·巴贝奇分析机的笔记中，洛夫莱斯指出，这台机器“没有任何创造新事物的企图”，只能执行“我们已知如何命令它去做的任何事情”。这一观察揭示了计算系统的一个基本限制：它们的操作依赖于人类的输入，其创造力也有一定的界限。


图片

Ada Lovelace


她对计算机器的本质提供了早期且深刻的见解，这些见解在当今关于人工智能，特别是大语言模型（LLMs）的讨论中仍然具有相关性；基于LLMs的Generative AI本质上是在做文本预测生成，尽管这些模型能够生成看似原创且有洞察力的文本，但它们从根本上来说仅限于操纵和重组其训练数据中已有的信息。


人和AI的区别在于，人在阅读或听到一段文字时，他们不仅仅是在处理词语，而是将这些词语与对世界的更广泛理解联系起来，从中汲取个人经历、文化背景以及深刻内化的因果关系和逻辑；相比之下，LLMs尽管在计算上非常复杂，但缺乏真正的“世界观”，它们不具备对世界复杂性的内在理解（当然未来AGI的概念下可能可以），也不具备支配事件的因果关系或人类通过一生的经历所获得的常识，相反，它们的知识反映了其训练数据的庞大内容。它们根据从这些数据中提取的模式和结构来识别和生成文本，而不是基于任何内在的理解，因此LLMs更像是工具，其所展现的能力反映的是它们所训练的数据。


LLMs具有涌现和泛化能力，即在模型规模突破临界之后，开始具备从训练数据中发现新的、更高级的特征和模式，并且可以将模式应用到未经训练过的数据上，外在表现为上下文学习能力（In-Context Learning）、按指令执行能力（Instruction Following）、逐步推理能力（Step-by-Step Reasoning）和知识推理和迁移能力（Transfer Learning）。


AI在展现强大能力的同时，也有一些局限性：

  1. 随时间增加的错误（Increasing Errors Over Time）：想象一下你正在尝试预测句子中的下一个词，每次尝试时都有很小的可能出错。随着你继续预测更多的词，这些小比例的错误会累积起来，出错的可能性也会增加。这意味着你想要生成的文本越长，出现错误的机会就越高。这就像蒙着眼睛试图走直线一样；你走得越远，偏离路线的可能性就越大。

  2. 固定的思维过程（Fixed Thinking Process）：当这些AI模型生成文本时，它们是一次生成一个词，并为每个词使用固定数量的计算能力。这就像在对话中，无论话题多么复杂，你都只有几秒钟的时间来思考接下来要说哪个词。如果我们希望模型“更深入地”思考下一个词，我们不能简单地告诉它这样做；我们只能让它生成更多的词，这是一种试图从模型中获取更深层次思考的间接方式。这种固定的过程限制了模型的规划或前瞻性思考的能力。

  3. 缺乏真正的规划（Lack of True Planning）：这些模型不会规划；它们是基于训练过程中见过的过去例子做出反应的。如果它们似乎在创建计划，通常是因为它们之前见过非常相似的情况，并模仿了那种回应。

  4. 对世界的理解有限（Limited Understanding of the World）：语言模型是通过文本数据进行训练的，这意味着它们只知道可以用文字表达的内容。然而，许多人类知识和日常常识无法完全通过文字捕捉。例如，知道如何骑自行车、游泳或认出朋友的脸，涉及的感觉和运动技能是无法仅从文本中学到的。这意味着虽然AI可以帮助写作和生成想法（比如克服写作障碍），但在需要深厚事实知识或对世界有物理理解的任务上，它会遇到困难。

  5. 过度估计AI的智能（Overestimating AI's Intelligence）：这些模型可以生成流畅且语法正确的文本，这很容易让人认为它们比实际更聪明。然而，它们的智能能力是表面的。它们无法真正理解世界是如何运作的，这意味着我们距离能够与人类智力在更广泛意义上匹敌的AI还有相当长的距离。


图片
心得体会


当前的探索和应用是工程技术团队的开发为主导，角色的优势是非常了解研发工程链路的现状和细节，在探索的过程中是以当前主流大模型的能力和叠加一些上层偏Prompt Engineering和ICL(In-Context Learning)的方式增强的能力为基础，通过对当前链路局部或变革式的重新设计，然后在LLM能力之上做解决方案的落地。


因此在这个过程中，对于AI能力的认知，以及对于自身研发链路的细节的了解，合理设计AI能力和链路拆解任务的适配，是最终解决方案是否有效和方案是否可以长期演进迭代的关键。


▐  任务拆分


案例1

我们在做实验分析的项目中，分析报告会涵盖下面几项比较重要的维度，比如下图所示整体实验结论、分指标结论、非重点指标以及均匀性检测，同时还有最后比较关键的建议或洞察，在这里如果基于实验的相关前置统计数据，一股脑的给到大模型，让它去做几个维度的结论生成，效果会很差，因为我们针对每个维度都会有一些prompt，在这样长序的输入下，大模型非常容易丢失一些context，返回的结果可能只能覆盖部分内容，同时在整体返回时长上也比较久，在这里我们做了任务的拆分，每个维度一个task，然后做了并行的调用编排。


图片

图片


案例2

该案例是在B侧后台页面生成的链路中，虽然我们看到后台的页面是一个以表格或图表为主，看似元素比较固定和简易，但是如果整张视觉稿扔给LLM，最终结果也是非常“感人”的，本质上的原因有两个：1. 和案例1一样，整个页面的生成任务，还是偏大，需要拆分；2. 这里的拆分不全是基于视觉分块的切分，是需要结合背后组件能够解决的问题粒度进行合理拆分，才能保证最终生成的效果有一定保障。


这里我们的处理方式是引入一个图像的算法模型做初步切分（框出的部分就是不同的task），同时在插件里面增加可以人为的调整区块大小和数量。


图片


▐  任务设计


主要是在明确我们的项目或者节点下的目标诉求，面向当前AI的能力，去做诉求和能力的匹配设计。


案例1

数据研发AI提效探索中，其中有一段实现是通过业务需求的描述输入，来生成数据SQL，因为意识到如何直接让大模型理解需求，然后在基于底层的基础表和字段的描述去做SQL的生成，会有很大的不确定性和错误率（最大的SQL行数可能近千行），因此这里通过沉淀ADS模型，AI只需要把需求关联到特定的ADS模型，并且根据描述去生成相关的模型配置参数。


图片


案例2

C侧前端会场交互页面多排样式的任务设计，如果将下图所示的模块视觉稿给到大模型，出来的效果会差强人意，同时在UI还原度上还会劣化（原始的视觉稿理解是基于Imagecook来做的），这里首先要做任务拆分，然后针对下面的红包的排列这部分的任务要做个设计，需要先切出一个红包来做UI和结合当前组件库的代码的生成，然后再通过单卡的实现和1x3的排列样式组件来生成下一步的代码。


图片


▐  输入提炼


案例1

在测试用例生成链路中，前置比较重要的输入有需求文档、技术文档和视觉稿，对于我们自己正常处理来说，需要人为的去组织不同文档当中的相同部分，同时利用脑子里面的一些知识，然后才能完全理解需求中变更或者新增的功能点以及对应的改动点，然后针对功能和改动去写TC，这么难的过程，我们不能把LLM当成一个黑盒，然后把三类主要的输入文档扔给LLM，寄希望于他们能给与我们奇迹般的输出，这里前置的文档预处理就显得非常重要，这里主要有这么几个目标：1. 对文档做精简；2. 多模态的内容（视觉稿的图、表格、uml图等）的理解；3. 相关联信息的聚合（prd、视觉稿、技术文档中针对同一功能的描述做聚合）等，目前我们是锚定这几个目标去做，但是还在克服过程中的一些问题，下面的预处理流程可供参考。

图片


▐  人“机”交互


从目前AI的能力以及我们当前工程链路中抽象出来的问题来说，不太能直接去匹配上，那这里，人就要在AI能力缺口上，做粘合，一个完全脱离人去做独立任务完成的智能Agent是一个愿景和目标，但是当下来说，如果在过程中有人为的低成本介入的辅助能大大提升最终交付的结果，这样的设计个人认为还是非常关键的。


案例1

C侧前端项目，在大模型基于CSS样式和技术方案描述之后生成的第一版代码之后，即在后续要生成逻辑代码、胶水代码之前，设计了一个实时修改和渲染的交互，在这个交互中，可以以所见即所得的方式调整ui的布局，以及给结构绑定组件，然后进入到下一步的结合这里一部的输入和RAG知识库做代码的生成，效果会提升很多。


图片


案例2

在测试用例项目中，由于基于prd、技术文档和视觉稿三者的信息是不充分的，这里的客观不充分主要来源于两点：1. 三类文档本身编写的时候标准不一，详细程度也会浮动很大；2. 潜在的名词定义和用例，所谓来源于对业务的本身理解之后的隐藏知识；同时可能比较通用的解法是说我们去完善我们的知识库，或者我们把一些领域知识、业务知识SFT到模型中，当然，前两者可能在解决方案上更有系统性，但是测试用例编写这块的知识诉求范围其实很大，如何去收集相关的数据，以及如何去完善确保数据cover的知识面的完整性，这是一个充满不确定和庞大的工程。


在这里我们做了一个问答交互设计，大模型在基于输入的PRD、技术方案的理解后提出问题，测试开发去回答问题，然后再将问题和答案当成后续模型交互的上下文输入。


图片

▐  回答约束


当前LLM能力的局限性中Increasing Errors Over Time说明了随着回答长度的增加，出现“幻觉”的可能性就越大，这个在统计上也是能说清楚的，因此我们要在可判断范围内去约束模型生成的结果长度，来降低无效信息或是错误信息输出的可能。


案例

在测试用例生成的项目中，在对于输入文档做预处理之后，我们会生成类似这样的目录结构，叫做AB实验/开关，不过下面的例子有点小极端，给的是prd模板中的默认提升文案，但是就针对这样我们认为毫无信息量的文字，LLM也能充分发挥，生成了这么一些看似很“全”的测试用例，但是明显这样的结果会让整体效果大打折扣；这里我们的做法可以粗略地针对文字的输入的内容，做输出tc条数的限制，能够有效地约束LLM，产出更加高质量的回答。


图片


图片


▐  能力结合


不要迷信大模型能力，找到最适合AI能做的事情，让AI去做，以及不适合AI做的事情，我们可以找到非AI的解决方案去做，然后做方案的串联，这可能是更有效的方式。


案例1

C侧前端项目中处理UI还原问题时，使用Imagecook来做视觉稿到Css样式的第一步处理，因为LLM对于Sketch文件处理不好，或者说LLM其实对于这类UI图的样式还原效果都不太好。


图片


案例2

在数科AB实验项目中，在分析实验流量均衡性的时候，直接使用python 函数来实现。


图片


▐  RAG实践探索


RAG是目前我们在探索AI应用过程中的利器，不过大部分的使用都是比较粗放的，比如扔进去一些语雀文档到知识库，也没有做合适的chunking，也没有特定去关注index embedding，也没有去做前置query变化增强以及检索召回优化；但是有一些方向上，对于知识库的依赖会有不太一样的方式，因为文档不是既定的，知识是每日都在更新增加的，如何去建立一套增量的知识发现、沉淀和录入的链路，对于该方向上的AI实践应用显得非常关键。


案例

这个案例取自服务端代码生成项目上，其实内部的aone copilot在通用任务上做的非常好用了，官方统计的采纳率也达到了25%，是个非常不错的code copilot的产品，但是对于业务侧的开发来说，这类copilot生成的代码，属于基础实现代码，因为不太能很好的结合当前业务下沉淀的服务、方法来做代码生成，因此我们需要把这部分所谓的服务、方法、工具等接口信息和使用case给到LLM，它才能结合这样的context去做最终代码的生成；下面两幅图描述的是我们对于知识的扫描和知识的录入设计的链路。


图片


图片


▐  FT祛魅


FT和in-context learning的区别，个人理解可以类比：调色盘（FT） 和 几种调色规则（ICL）；  亦或是拿一个场景做类比，ICL就好比一个直播的同学和一个非直播领域下的同学聊直播，先给介绍主播是什么概念，直播品是什么概念，然后往下聊，不然这几个概念和名词听不懂；FT就好比两个直播域下的同学聊直播，主播、直播品的概念都能非常好的get到，不需要额外说明，就可以非常好沟通交流。


就像前面说的，工程技术同学去探索AI应用，有自身的优势，但是同时也有一些技能和认知上的局限，那对于模型相关的FT调优、模型部署以及MLOps这一套都是没有接触的，所以就会有两种比较普遍的表现：1. 认为FT很难，cover不了，尽量不去做，能prompt调优下，或者能RAG持续建设下去做提升就行；2. 认为FT很强，遇到LLM返回结果不太合理，那咱们就FT下吧，给模型增强下能力；这两种描绘的都算比较极端哈，明确好当前的问题，做出合理的设计，充分权衡后，把FT当成一种常规的解决方案来看就行。


图片

结语


直播AI提效应用探索的半年，磕磕绊绊地在前进的路上行进，后面在垂直应用下探索更好的实践的同时，也想着可以参与一些横向的基础能力的建设，同时也期待在相同或相似问题域下，和其他小伙伴做更深入的交流和合作。


图片
参考资料


  • Introduction to Large Language Models：https://learning.oreilly.com/library/view/llms-in-enterprise/9781836203070/text/ch002.xhtml#limitations-compared-to-human-level-intelligence

  • The Business Opportunities of Today：https://learning.oreilly.com/library/view/the-early-career-professionals/9798868804564/html/623057_1_En_5_Chapter.xhtml

  • Understanding Language Models：https://learning.oreilly.com/library/view/the-early-career-professionals/9798868804564/html/623057_1_En_3_Chapter.xhtml


图片

团队介绍


淘宝直播作为全球领先的直播电商平台，正在重新定义人与商品、人与内容的连接方式。我们致力于打造沉浸式、互动式的购物体验，让数亿用户在这里发现好货、感受乐趣。无论是时尚穿搭、美食评测，还是科技新品发布，淘宝直播都在引领电商行业的创新潮流。同时淘宝直播也在推进打造行业领先的AI数字人技术，实现虚拟主播、智能互动、个性化推荐等创新功能。






继续滑动看下一个
大淘宝技术
向上滑动看下一个